Turning off RN2483 resets up/down frames


#1

Hey Lads,

For a while i have been tinkering with powermanagement with the RN2483 chip and i thought the best solution would be to remove the power when the module is not used.

When i do that i can still send packages but all my data will have frame 0 and will only appear in the messages section on the staging website when i reset the frames up count.

Why is this? and how does anyone have a better way for lowering the power to almost 0 for the rn2483


Why does deleting my device solve the problem?
Ic880a on rpi3 does not receive data from rn2483
(Hylke Visser) #2

This is a security measure against replay attacks (see this wiki page). I believe the RN2483 has a command sys sleep <length> that will put it in low-power mode for <length> milliseconds; this might be what you're looking for.


(Arjan) #4

6 posts were split to a new topic: Why doesn't Microchip allow for running our own code on the RN2483?


#8

Thanks for the help,

I switched to using sys sleep to reduce the power usage. It works great but when i increase the sleep timer to 60000 i do not get a "OK" rx when the RN2483 wakes up. But when i reduce the timer to 20000 i do get a "OK" rx.
Anyone know why the module does this?


#9

try to give sys reset first

4294967296 mSeconds
429496.7296 S econds
71582.8 M inutes
1193.05 H ours
49.7 days max !


#10

at 20000 ms it wakes up and sends OK but when i do 60000 it stays in sleep.
a reset is not suited for the situation iam using it for.
How would i do a break condition so that i can wake it up. I cant seem to find the command in the user guide.


#11

well, I can't duplicate it.

you didn't put a zero to much and be sure to wait one minute @ 60000 ? :wink:


#12

Would you mind try something like this to force wakeup from sleep (this is my autobaud routine)

  Serial.begin(Your baud rate);
  Serial.write((uint8_t)0x00);
  Serial.write(0x55);
  Serial.print("\r\n");

Don't forgot the last line, I spend too much time to find out why it was not autobauding (it's not indicated in the datasheet that you need to send CRLF)


#13

yes thats also possible (and neccesary!) if you control your RN2483 with an MCU.


#14

Also datasheet does not says what is maximum speed we can use ;-( never succeded at 115200 with autobaud)


#15


#16

Thanks for the response, i will try this later today.


#17

I too have been experimenting to reduce power on the RN2483 and associated board based on BBC Micro:Bit. I power off the whole device and just leave a separate RTC chip running to wake up power to the whole device on an alarm.
With this I get under 1 microamp in sleep mode. However, when I wake up, the RN2483 has forgotten the frame counter and the state(Joined). So I have to rejoin the network and the frame counter is reset.
I could keep the RN2483 on battery power, and just power off the Micro:Bit, but then I will be around 11 microamps in sleep.
Unlike to OP, I do see all the messages in the staging website, all with frame counter 0
My duty cycle is low, so I am not near the 0.1% join rate, but can anyone think of a workaround ?


(Arjan) #18

Most likely, the OP's node is using Activation by Personalisation. For Over-the-Air activation, the counters are automatically reset on the server when re-joining (which is perfectly safe, as then new secret keys will be used which makes replaying old messages impossible).


#19

Thanks, That would explain the difference.

I tried doing a "mac save", but as expected this does not save state information. Also a reset to the reset pin clears the join and frame state as well
The rejoining gives an additional MQTT event, but that is not a problem for me.
I guess my question is whether rejoining every time for low duty cycle node is OK?
Thanks to Charles for his code snippet. It helped with a different problem I have to get out of an unintentional autobaud state when changing serial pins in Micropython
Using the packaged RN2483 and the packaged Micro:Bit with Micropython is interesting, and to some extent meets my original goal to find a more sharable "on-ramp" for TTN and Open IOT, but sometimes, I get the urge to get back to bare metal SX1276, M0 and C++.


(Arjan) #20

Why is that expected? I never used the RN2483, but since version 1.0.0 it should save the frame counters and session keys. Maybe call sys reset after sleep?

The mac save command must be issued after configuration parameters have been appropriately entered from the mac set <cmd> commands. This command will save LoRaWAN Class A protocol configuration parameters to the user EEPROM. When the next sys reset command is issued, the LoRaWAN Class A protocol configuration will be initialized with the last saved parameters.

The LoRaWAN Class A protocol configuration savable parameters are:

  • band: Band
  • fcntup: Uplink Frame Counter
  • fcntdown: Downlink Frame Counter
  • dr: Data Rate
  • rx2dr: Data Rate parameter for the second receive window
  • rx2freq: Frequency parameter for the second receive window
  • adr: Adaptive Data Rate state
  • deveui: End-Device Identifier
  • appeui: Application Identifier
  • appkey: Application Key
  • nwkskey: Network Session Key
  • appskey: Application Session Key
  • devaddr: End Device Address
  • ch: All Channel Parameter
    • freq: Frequency
    • dcycle: Duty Cycle
    • drrange: Data Rate Range
    • status: Status

OTAA - save Keys and?
#21

I cant seem to wake up the module using this code. Anyone else know how to manually wake up the module when it is in sleep mode?


#22

You are correct, I was reading the earlier version of the data sheet. Version 1.0 saves more parameters as you describe. I am running Ver. 1.0.1

However, a power down, a reset from the reset pin, or a "sys reset" command, do all seem to require rejoining afterwards before data can be transmitted. This rejoin seems to reset the frame counter.


#23

Send a "mac save" before removing power. All the radio state, including frame counters, gets stored to EEPROM and reloaded when power is re-applied.
Make sure you have firmware 1.0.1. The original 0.9.5 didn't store the frame counters.


#24

Step 1: make sure you don't have firmware 1.0.2