RN2483A Problems - No serial communication

End Devices (Nodes) Hardware
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
39

Inspired on weradis (Willem) feedback I got it working with a delay of 26.
The pass thru script below works with my RN2483A chip and an Arduino Pro Micro 3.3V 8MHz.

#include <SoftwareSerial.h>
int MCU_RX_Pin = 10;
int MCU_TX_Pin = 9;

SoftwareSerial mySerial(MCU_RX_Pin, MCU_TX_Pin);

void setup() {
Serial.begin(57600);
while (!Serial) {
}

// wakeUP_RN2483 and set data rate
pinMode(MCU_TX_Pin, OUTPUT); //TX pin of MCU to RN2483
digitalWrite(MCU_TX_Pin, LOW); // Send a break to the RN2483
delay(26);
digitalWrite(MCU_TX_Pin, HIGH);
mySerial.begin(57600); // set the data rate for the SoftwareSerial port
mySerial.write(0x55); // Send magic character for autobaud
}

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

3 Likes