[solved]RN2483 - Problems after wakeup from sleep

straight after transmitting… no delay ? and ’ mac tx cnf ?

after transmitting (mac tx uncfn), i am waiting 200ms. Transmission is successfully reveived by ttn.

a mac resume after forced waking up ?

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

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

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

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 ?

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

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);

}

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

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

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

old topic

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

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. toolshiny now the old module itself

2483tool

I can try a factory reset tomorrow…

1 Like

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)

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

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

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

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

2 Likes