RN2483A Problems - No serial communication

End Devices (Nodes) Hardware
19

Hello the RN2483 has a strange behavior . After issue the sleep command for 24 seconds - the UART interface fails when I issue mac tx uncnf 1 01.I use a library from ttn for rn2483.

– STATUS
EUI: 0004A30B001E845E
Battery: 3243
AppEUI: A60100D07ED5B371
DevEUI: 0004A30B001E845E
Data Rate: 0
RX Delay 1: 1000
RX Delay 2: 2000
– JOIN
Model: RN2483
Version: 1.0.3
Sending: mac set deveui 0004A30B001E845E
Sending: mac set adr off
Sending: mac set deveui 0004A30B001E845E
Sending: mac set appeui A60100D07ED5B371
Sending: mac set appkey 0000000000000000000000000000AAA1
Sending: mac save
Sending: mac set rx2 3 869525000
Sending: mac set ch drrange 1 0 6
Sending: mac set ch dcycle 0 799
Sending: mac set ch dcycle 1 799
Sending: mac set ch dcycle 2 799
Sending: mac set ch dcycle 3 799
Sending: mac set ch freq 3 867100000
Sending: mac set ch drrange 3 0 5
Sending: mac set ch status 3 on
Sending: mac set ch dcycle 4 799
Sending: mac set ch freq 4 867300000
Sending: mac set ch drrange 4 0 5
Sending: mac set ch status 4 on
Sending: mac set ch dcycle 5 799
Sending: mac set ch freq 5 867500000
Sending: mac set ch drrange 5 0 5
Sending: mac set ch status 5 on
Sending: mac set ch dcycle 6 799
Sending: mac set ch freq 6 867700000
Sending: mac set ch drrange 6 0 5
Sending: mac set ch status 6 on
Sending: mac set ch dcycle 7 799
Sending: mac set ch freq 7 867900000
Sending: mac set ch drrange 7 0 5
Sending: mac set ch status 7 on
Sending: mac set pwridx 1
Sending: mac set retx 7
Sending: mac set dr 5
Sending: mac join otaa
Join accepted. Status: 00000001
DevAddr: 6486152A
– LOOP
ok

Sending: sys sleep 24000
– LOOP

Sending: sys sleep 24000
– LOOP

Sending: sys sleep 24000
– LOOP

Sending: sys sleep 24000

20

Are you sure that the RN2483 is awake when you issue the tx command?

21

Hello,

here is the code I use:

the build in libary command : ttn.sendBytes(payload, sizeof(payload)); does not have this problem.
But I want to use loraSerial.println(“mac tx uncnf 1 01”); because the ttn.sendBytes(payload, sizeof(payload)); take to much to execute and increases my wake up time for my device.ttn.sendBytes(payload, sizeof(payload)); takes 3 seconds to run.

// ttn.sendBytes(payload, sizeof(payload));
loraSerial.println(“mac tx uncnf 1 01”);
String str = loraSerial.readStringUntil(’\n’);
debugSerial.println(str);
loraSerial.println(“mac pause”);
str = loraSerial.readStringUntil(’\n’);
debugSerial.println(str);

delay(10);
ttn.sleep(24000);
delay(10);
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);
delay(100);
loraSerial.println(“mac resume”);
str = loraSerial.readStringUntil(’\n’);
debugSerial.println(str);
//loraSerial.write(0x55);

22

It’s a little unreliable to put the module in sleep mode for 24s and set the MCU wait to approximately 24 seconds, theoretical. As first thing to be sure the RN2483 is back in operation I would wait a few more seconds. Also, I don’t understand the necessity to use “mac pause/resume”

23

Tie the TX pin of the RN2483 to MCU D2 or D3. Then attach the interrupt before calling the SLEEP_FOREVER instead of SLEEP_8S after putting the RN2483 to sleep. So, if you want both RN2483 and module to sleep say 24s, both will sleep at the same time using this approach. What you are doing currently is not efficient.

24

This piece of code can be helpful in understanding what he meant:

void loop() {
…
…
…
//taskSendTTN();
…
…
…

// Radio enter power down state
sleepRadio();

// MCU enter power down state
sleepController();
}

void sleepController() {
attachInterrupt(1, awake, CHANGE);
LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
detachInterrupt(1);
if (loraSerial.available()) loraSerial.read();
}

void sleepRadio() {
ttn.sleep(sleepRadioTime);
if (loraSerial.available()) loraSerial.read();
}

Alex

25

That is because the module waits for possible response and the controller needs to wait for the modules responses. If you issue another command within those three seconds the behavior is undefined, the command may well be ignored or an error generated.
After issuing the transmit command you need to wait for two response strings before proceeding with the next command.

26

Hello,

By working before with the RN2483 I managed to get the duration of the TX to 410 ms In that duration the Tx and sleep command were issued. . Now with the RN2483A the UART interface fails for some reason with the same code.Waiting 3 seconds for the RN to send some printout via serial will not make the module battery friendly.

Regards,

Dan

27

As final suggestion… use the functions provided by the library to avoid any strange behavior and exploit all the features of the protocol as the downlink.

If you do not know all the details of the protocol and the operation of the RN2483 module it does not make much sense to go for attempts, such as the use of the"mac pause/resume" … that you have not explained us yet.

Alex

28

You might have been able to do this with firmware <1.0.3 but as it violates the API you can not rely on it to stay working. It will probably result in the stack going to an undefined state at some point in time.
When it comes to power consumption, yes it consumes more power. About 10ma for 3 seconds. Not an enormous amount… if it is too much you could look into using the rfm95 and your own LoRaWAN stack. Then you can tweak all you want.

29

Is there already a good solution?
I also have two RN2483A chips on Dr. Azzy board with pass thru script on Arduino Nano 3.3V and FTDI232 with 3.3V. Both boards are not accessible via serial communication. Similar setup worked with “old” RN2483 chips I had.

I tested with both 57600 and 9600 but both doesn’t work properly.
And I double checked my TX-RX wiring. :wink:

Any help is appriciated!

Best regards,

Peter

30

there is no problem with rn2483A as far as I know and have seen in combination with the TTN library.
the RN is connected to a hardware uart port

31

I use softserial with this script:
#include <SoftwareSerial.h>

SoftwareSerial mySerial(11, 10); // RX, TX

void setup() {
// Open serial communications and wait for port to open:
Serial.begin(57600);
delay(5000);
Serial.println(“Testing soft serial connection”);

mySerial.begin(57600);
}

void loop() { // run over and over
if (mySerial.available()) {
Serial.write(mySerial.read());
}
if (Serial.available()) {
mySerial.write(Serial.read());
}
}

Directly connecting the RN2483A to the FTDI232 works with 57600.
So I’m doing something wrong or my chinese Nano knockoff or cables are part of the problem.

32

if (mySerial.available()) {

while (mySerial.available()) {

if (Serial.available()) {

while (Serial.available()) {

33

Adding those statements can help?

34

changing if in while could help…

35

Same problems, the response is some garbage as output.
But…I made a stupid mistake that solved it almost.
I confused the Arduino Pro Mini for Arduino Nano board.
Using the Arduino Pro Mini board with 8MHz 3.3V works better.
The first command sys get ver gives a good response.
Another command first gives garbage, but another attempt with same command gives good result.
So now I know it is working (with bad quality) and can try to move on. :wink:
Thanks BoRRoZ!

36

Guys, I ran into the same problem after upgrading to 1.0.3 and waking from sleep. After some testing I found that break sequence needs to be way longer as before to activate the auto baudrate mechanisme.

The sodaq library uses the following sequence to send a break character, which is a ‘0’ at 300 baud which should keep the serial line low long enough …

    this->_loraStream->begin(300);
    this->_loraStream->write((uint8_t)0x00);
    this->_loraStream->flush();
    sodaq_wdt_safe_delay(50);

I replaced that bit with the following code

    this->_loraStream->end();
    pinMode(PIN_SERIAL1_TX, OUTPUT);
    digitalWrite(PIN_SERIAL1_TX, LOW);
    sodaq_wdt_safe_delay(25);
    digitalWrite(PIN_SERIAL1_TX, HIGH);

I increased the delay and when I arrived at 25 milliseconds the RN2483 woke up and the auto baudrate was working again. This is about 5 * longer as I used before.

Not the cleanest way as it removes the serial port abstraction.

37

breakcondition

38

Yes I’m aware of this, the point is that with the older (1.0.1 or older) firmware sending a null character at 300 baud activates the autobaud mechanism, with 1.0.3 it didn’t …

1 Like