RAK11300 Save values to EEPROM

We want to change the packet sending period using the downlink commands.
Can you tell me if we can use EEPROM to store the new value LORAWAN_APP_INTERVAL?

Or maybe there are already methods to change this parameter?

thanks in advance :slightly_smiling_face:

Hi @mykhalych90
The RAK11300 doesn’t have an EEPROM, but I wrote some code that can store the devices settings in the internal flash.
RAK11300-AT-Command example firmware has an AT command firmware and saves all LoRaWAN settings in the flash.
Saved settings:

// OTAA Device EUI MSB
uint8_t node_device_eui[8] = {0x00, 0x0D, 0x75, 0xE6, 0x56, 0x4D, 0xC1, 0xF3};
// OTAA Application EUI MSB
uint8_t node_app_eui[8] = {0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x02, 0x01, 0xE1};
// OTAA Application Key MSB
uint8_t node_app_key[16] = {0x2B, 0x84, 0xE0, 0xB0, 0x9B, 0x68, 0xE5, 0xCB, 0x42, 0x17, 0x6F, 0xE7, 0x53, 0xDC, 0xEE, 0x79};
// ABP Device Address MSB
uint32_t node_dev_addr = 0x26021FB4;
// ABP Network Session Key MSB
uint8_t node_nws_key[16] = {0x32, 0x3D, 0x15, 0x5A, 0x00, 0x0D, 0xF3, 0x35, 0x30, 0x7A, 0x16, 0xDA, 0x0C, 0x9D, 0xF5, 0x3F};
// ABP Application Session key MSB
uint8_t node_apps_key[16] = {0x3F, 0x6A, 0x66, 0x45, 0x9D, 0x5E, 0xDC, 0xA6, 0x3C, 0xBC, 0x46, 0x19, 0xCD, 0x61, 0xA1, 0x1E};
// Flag for OTAA or ABP
bool otaa_enabled = true;
// Flag for ADR on or off
bool adr_enabled = false;
// Flag for public or private network
bool public_network = true;
// Flag to enable duty cycle
bool duty_cycle_enabled = false;
// In milliseconds: 2 * 60 * 1000 => 2 minutes
uint32_t send_repeat_time = 120000;
// Number of join retries
uint8_t join_trials = 5;
// TX power 0 .. 10
uint8_t tx_power = 0;
// Data rate 0 .. 15 (validity depnends on Region)
uint8_t data_rate = 3;
// LoRaWAN class 0: A, 2: C, 1: B is not supported
uint8_t lora_class = 0;
// Subband channel selection 1 .. 9
uint8_t subband_channels = 1;
// Flag if node joins automatically after reboot
bool auto_join = false;
// Data port to send data
uint8_t app_port = 2;
// Flag to enable confirmed messages
lmh_confirm confirmed_msg_enabled = LMH_UNCONFIRMED_MSG;
// Fixed LoRaWAN lorawan_region (depends on compiler option)
uint8_t lora_region = 1;
// Flag for LoRaWAN or LoRa P2P
bool lorawan_enable = true;
// Frequency in Hz
uint32_t p2p_frequency = 916000000;
// Tx power 0 .. 22
uint8_t p2p_tx_power = 22;
// Bandwidth 0: 125 kHz, 1: 250 kHz, 2: 500 kHz, 3: Reserved
uint8_t p2p_bandwidth = 0;
// Spreading Factor SF7..SF12
uint8_t p2p_sf = 7;
// Coding Rate 1: 4/5, 2: 4/6, 3: 4/7, 4: 4/8
uint8_t p2p_cr = 1;
// Preamble length
uint8_t p2p_preamble_len = 8;
// Symbol timeout
uint16_t p2p_symbol_timeout = 0;

But we use WisBlock, and examples for WisBlock

There are no AT-commands.

Or have I misunderstood something)

We want to send downlink command from network server to Wisblock, process it in “void lorawan_rx_handler(lmh_app_data_t *app_data)”, get from it new value of LORAWAN_APP_INTERVAL, and save it to settings.
So that the next reboot would also use the new value of LORAWAN_APP_INTERVAL.

I pointed you to example code how to save values in the internal flash and how you can implement AT commands.

we don’t need AT commands

you mean to use this method?

but in new examples there are fixed issue with timer

The first code you showed is taken from the WisBlock-API, which right now works on RAK4631 and RAK11300 is still under testing.
The timer part of WisBlock API is not yet adapted for RAK11300.

I do not have an example to change the send frequency over downlink commands. But it is quite simple to implement it in the RX callback function. You just have to parse the downlink payload, read the new timer value and apply it.

For saving the timer interval, I hoped the example code I pointed you to would help.
Basically, it uses the last sector of the RAk11300 flash to store parameters.
The code I mean can be found here RAK11300-AT-Command-Firmware/flash.cpp at main · RAKWireless/RAK11300-AT-Command-Firmware · GitHub

and one more question
what max value for LORAWAN_APP_INTERVAL?
we want to set the interval to 2 hours or more,
but when we set 7 200 000 - there are no packets after 2 hours(

I have to run a test for that. Didn’t try 2 hours between two packets yet.

ok, thank you
wait for result

:face_vomiting:

MBed timer seems to be messed up.
Setting the timer to two hours, I get nothing as well.

That is a problem somewhere in the RP2040 BSP (we just use that, we do not maintain it) and it is not the first time I have problems with it.

That needs some more digging and investigating.

1 Like

60 minutes works :thinking:
image

yes, yes, 1 hour - works ok
Perhaps the reason is in the type of the variable (long, int, long int…)?

The time is defined as an uint32_t
That means
4294967295 milliseconds
4294967 seconds
7157 minutes
119 hours

I think there is a bug in the MBed timers that cause an overflow.
Problem is that I cannot debug the BSP, we just take the Arduino-MBed for RP2040 and put our device in it. We don’t maintain the BSP.

there is error:

4294967 seconds = 71582 minutes = 1193hours

and what about this? here are microseconds
that mean max 4294967295 microseconds~ 71.58 min,

I will try to set 70min and then 72 min to check

yes, the reason in timer var size
so, 71 min - all ok

when I set LORAWAN_APP_INTERVAL to 72 min - packets start to be sent every 25 seconds:
4 294,967 seconds - 72 * 60 = - 25.033 seconds

and when I set the LORAWAN_APP_INTERVAL to 73 minutes - the packets are sent after every 1min 25 seconds:
4 294,967 seconds - 72 * 60 = - 85.033 seconds

so timer max is uint32_t 4294967295 microseconds

Looks like I need a new calculator, but you are right.

The attach function is defined as void attach(Callback<void()> func, std::chrono::microseconds t);

But in mbed_chrono.h I found

 * Standard std::chrono::microseconds is signed 64-bit. For some purposes

so it is limited actually to 32bit (negative times make not really sense).
And the whole mbed stuff is pre-compiled, so no option to fix it.

so it can’t be fixed?
and the maximum sending frequency can be only 71 minutes for PAK11300?
is it through the BSP for RP2040?

does other WisBlock Cores have the same issue?

I cannot fix it, the guys who maintain the Arduino-MBed BSP should be able to fix it.

Every WisBlock Core has different MCU, which means different BSP.
I didn’t test on the RAK11200 (ESP32 BSP), But I had the RAK4631 set to 6 hours (soil moisture sensor) and it worked.

It is bad news :frowning_face:
is it possible to create a ticket on Arduino-MBed BSP team?