[solved]RN2483 - Problems after wakeup from sleep

End Devices (Nodes) Hardware
9

no, i did not send the command mac resume. Is this command necessary?

10

I’m not 100% sure (it’s a while that I worked with this module) but it could be resetting the timer(s)
I assume you’ve installed the latest firmware

12

I tried to insert a resume after wake up and before new sleep call, but the behavior is the same.

13

ok sorry… :thinking:

and the uart is available ‘normally’ … how is the RN2483A connected / communicate ?
instead of sending more data, can you send a non Tx command ?

14

Yes, i communicate with an STM32 MCU over UART and also over USB/UART with the PC. No problem as long the module is not in sleep mode

16

Here is my code for waking up the modul:

void wakeupRN2483(void)
{
MX_USART2_UART_Init_28800(); // 28800 Baud
HAL_Delay(500);
/********************** RN2483 wake up *********************/
if (HAL_UART_Transmit(&huart2, byte080, 1, 50) != HAL_OK) // low signal 226µs at least
{
Error_Handler();
}

  MX_USART2_UART_Init_57600();			// 57600 Baud

  HAL_Delay(500);

  if (HAL_UART_Transmit(&huart2, byte55, 1, 50) != HAL_OK)		// send 0x55
  {
	  Error_Handler();
  }
  HAL_Delay(5000);

}

17

After wakeup and during sending next sleep command i got an strange answer like the scope image shows…2019-10-08_21h34_21

18

To summarize the whole thing again:

  1. Sending sensor data to ttn server (every 3 minutes) over hours -> OK
  2. Put device in sleep mode with sys sleep 864000000 -> OK, current consumption -> OK
  3. Wake up from sleep mode with pull the Rx line to low for 300µs (57600 baud) and sending 0x55 for auto baud rate detection -> OK
  4. Sending new sensor data to ttn server -> OK
  5. Put device in sleep mode with sys sleep 864000000 again -> NOT OK - the module response with FE 1E 1E 1E E6 … during command sleep is sending (see scope image above):disappointed_relieved:

The modules version is RN2483 1.0.1 Dec 15 2015 09:38:09

19

that’s one of the first production modules (with hardware faults) … latest is the rn2483A with 1.05

old topic

20

ok, that means i can throw it in the waste basket?

21

I don’t know if this IS related to your problem ( I have this module somewhere, I could try to emulate (tomorrow).

did you try to start all over ?.. a sys factoryRESET (the famous helpdesk tip… switch off/on :upside_down_face: ) / flash newer firmware

  • found the comm. tool… shiny now the old module itself

2483tool

22

I can try a factory reset tomorrow…

1 Like
23

No, by no means. As long as the module is flashed with the newer firmware it will work nicely for all spreading factors apart from SF12. (And even that won’t be a problem first few years)

24

Ok, i am using SF 12. So i will change it to 11 and flash a new firmware.

25

Now i flashed newest firmware and changed spreading factor to 11. But the result ist unfortunately the same.

26

I also changed the timing for wakeup condition (break 300µs + 0x55) like in the picture. The answer from the modul is OK. 2019-10-11_07h38_18

27

Problem captured and solved. In a function i had send the sleep command twice.

3 Likes
28

Make sure the mac state is idle before sending sleep. Otherwise the RN2903 hangs. I don’t know whether the RN2483 suffers from the same problem.

29

Im actually having similar problem - to save power on the uC im turning the UART off which causes the RX line on RN2483 to go low - Im unable to wakeup the module once I bing the line up again and send the ‘0x55’ char. Any suggestion here?

30

Try, before enabling the UART, set the RX pin as an input with internal pull-up enabled.