Hello People!
I have a RAK3172 breakoutboard and want to know how much space is availible in the
memory of this module. Is there a possibility to read the availible memory space? In the API i only could find the read and write function but nothing about the memory space.
Kind regards,
Marnick
Hi @Marnick ,
I am not aware of any memory check API for RUI3 that you can perform on run time. However, you can view the ROM and RAM usage upon compilation.
Hello @carlrowan Thanks for your answer. But its not possible to read the ROM and RAM in runtime? Or do you know another trick to do this?
Kinds regards,
Marnick
I am not sure if there is a workaround on this. Can you give more context on what you are trying to achieve? Maybe there’s another way to work on it aside on reading memory usage?
I want to know how much bytes are still available in the microcontroller for using. This microcontroller has not really much memory so this is important to know.
I got also another problem, When iam using OTAA the adaptive datarate is not working, with ABP its working. The data is succesfull processed but the datarate is not changing automaticly. Do you have any idea of this problem?
Hi @Marnick ,
I am not sure exactly what your application is but probably you can assess how much memory you’ll be using based on the routines you implement (did you use Flash as storage, do you have huge functions with local variables, are you jumping from function calls to function calls, etc)? In my previous work, we allocate only 70% memory use upon compilation on the initial release of FW to a new product. This gives margin to cover bug fixes, feature updates, etc. Hoping, the 30% is enough.
Hi @Marnick ,
Do you have other details you can share? Maybe some logs on the network server like this.
Also maybe the comparison on DR change on OTAA and ABP? You should be able to set DR using AT+DR=x initially then if ADR is enabled via AT+ADR=1, it should receive ADR request, implement it, then reply if successful.
Yes i can set the datarate and after that iam setting the AT+ADR=1. the configurations are okay. Below my settings.
Hello @carlrowan. I dont have big functions. Iam using some flash storage for my custom made AT commands but thats all. in some functions iam jumping from function call to function call.
But what i make up out of your story, you suggest that i count my bytes to see how much space i have left?
Hi @Marnick ,
Can you confirm if the network server sent a ADR request to the device then the device acknowledge it? Also, is the confirm message working ok?
This is strange since at ABP, ADR is working.
Hi @Marnick ,
The memory space you need is determined at the compilation time. So we basically know if the code we are using is taking too much ROM and RAM (if it is still enough or we are hitting some dangerous limits).
During run-time, you use the ROM/flash to store some parameters. The size you use here is predictable since you define the flash size you need in your application. As for RAM, if your functions doesn’t use large local variables and doesn’t perform unpredictable iterative/recursive routines (for example are digital filters with varying input), then you can likely predict that you are not prone so some kind of stack/heap problems.
This is are just my insights based on the info I get so far.
this is my succesed processed data message, i deleted some information like keys.
`{
"name": "ns.up.data.process",
"time": "2023-05-09T14:33:04.602843323Z",
"identifiers": [
{
"device_ids": {
"device_id": "",
"application_ids": {
"application_id": "test-2stools"
},
"dev_eui": "",
"join_eui": "",
"dev_addr": ""
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
"raw_payload": "gE2mDCaABgAC/XurKwKMRBw=",
"payload": {
"m_hdr": {
"m_type": "CONFIRMED_UP"
},
"mic": "AoxEHA==",
"mac_payload": {
"f_hdr": {
"dev_addr": "",
"f_ctrl": {
"adr": true
},
"f_cnt": 6
},
"f_port": 2,
"frm_payload": "/XurKw==",
"full_f_cnt": 6
}
},
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 8,
"coding_rate": "4/5"
}
},
"frequency": "916600000",
"timestamp": 3541664988
},
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "",
"eui": ""
},
"timestamp": 3541664988,
"rssi": -29,
"channel_rssi": -29,
"snr": 11.3,
"uplink_token": "ChoKGAoMODAwMjljYzc4ZTc0EggAAIACnMeOdBDcieaYDRoMCKCz6aIGEP2Y+LoBIOD2u92JpRY=",
"channel_index": 7,
"received_at": "2023-05-09T14:33:04.283191048Z"
}
],
"received_at": "2023-05-09T14:33:04.393510095Z",
"correlation_ids": [
"gs:conn:01GZXJB5DR8P0J5J7190ZNNHFT",
"gs:up:host:01GZXJB5J5KBHN95W291R0J3HT",
"gs:uplink:01H00EW6M8ZHRVBTV5WZFJT8ZP",
"ns:uplink:01H00EW6M95CTJQ82QFNHDCBNV",
"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H00EW6M981DWWJQQ6161S186"
],
"device_channel_index": 7,
"consumed_airtime": "0.092672s"
},
"correlation_ids": [
"gs:conn:01GZXJB5DR8P0J5J7190ZNNHFT",
"gs:up:host:01GZXJB5J5KBHN95W291R0J3HT",
"gs:uplink:01H00EW6M8ZHRVBTV5WZFJT8ZP",
"ns:uplink:01H00EW6M95CTJQ82QFNHDCBNV",
"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H00EW6M981DWWJQQ6161S186"
],
"origin": "ip-10-101-12-161.us-west-1.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": "01H00EW6TT91QJKESS6NAH7HEB"
}`
and this is the scheduled downlink message. Here its saying the downlink message is unconfirmed, should this be the problem?
`{
"name": "ns.down.data.schedule.attempt",
"time": "2023-05-09T14:35:04.806513474Z",
"identifiers": [
{
"device_ids": {
"device_id": "",
"application_ids": {
"application_id": "test-2stools"
},
"dev_eui": "",
"join_eui": "",
"dev_addr": ""
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.DownlinkMessage",
"raw_payload": "YE2mDCYgDQBQZtb+",
"payload": {
"m_hdr": {
"m_type": "UNCONFIRMED_DOWN"
},
"mic": "UGbW/g==",
"mac_payload": {
"f_hdr": {
"dev_addr": "",
"f_ctrl": {
"ack": true
},
"f_cnt": 13
},
"full_f_cnt": 13
}
},
"request": {
"downlink_paths": [
{
"uplink_token": "
}
],
"rx1_delay": 1,
"rx1_data_rate": {
"lora": {
"bandwidth": 500000,
"spreading_factor": 8,
"coding_rate": "4/5"
}
},
"rx1_frequency": "926900000",
"rx2_data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 12,
"coding_rate": "4/5"
}
},
"rx2_frequency": "923300000",
"priority": "HIGHEST",
"frequency_plan_id": "AU_915_928_FSB_1"
},
"correlation_ids": [
"gs:conn:01GZXJB5DR8P0J5J7190ZNNHFT",
"gs:up:host:01GZXJB5J5KBHN95W291R0J3HT",
"gs:uplink:01H00EZVT32FZNJXW68XFNNEKJ",
"ns:downlink:01H00EZW76WTMFCR38DXK9F7TE",
"ns:transmission:01H00EZW76X20KHV7JZJNZ83W6",
"ns:uplink:01H00EZVT5DAC76B8CTHQJNX4J",
"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H00EZVT5CJ7A437DYQJ4MTB3"
]
},
"correlation_ids": [
"gs:conn:01GZXJB5DR8P0J5J7190ZNNHFT",
"gs:up:host:01GZXJB5J5KBHN95W291R0J3HT",
"gs:uplink:01H00EZVT32FZNJXW68XFNNEKJ",
"ns:downlink:01H00EZW76WTMFCR38DXK9F7TE",
"ns:transmission:01H00EZW76X20KHV7JZJNZ83W6",
"ns:uplink:01H00EZVT5DAC76B8CTHQJNX4J",
"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H00EZVT5CJ7A437DYQJ4MTB3"
],
"origin": "ip-10-101-12-161.us-west-1.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": ""
}`
Hello @carlrowan i know that i have some iteratives that can cause RAM problems so thats the problem but if there is no option to read the RAM then i need to do a MCU reset.
Another thing, when the MCU reset or power supply falls down i want to keep the uplink framecounter because otherwise the TTN network counter is higher then the module and thats not working. I can write the uplink framecounter in the memory but cannot write this value back to the uplink framecounter function to set this as initial value. Is there a way to write the framecounter from the flash memory to the counter function? Or do you have another solution to keep the module i connection with the networkserver?
Hi @Marnick ,
The unconfirm downlink shouldn’t be an issue. But as a look on the scheduled downlink, it seems there is no ADR request coming from the network server. Here’s the screenshot of what I mean.
Hi @Marnick ,
If you reset the device that operates in OTAA, it will rejoin so framecounters will all go back to zero.
However, if you are in ABP, the case is different. There is no mechanism at the moment to configure the framecounters in RUI3. The next thing you can do is disable the frame counter checks in the network server. You will be prone though to replay attacks (if ever a hacker will do such thing). So it is advise not to disable it and just use OTAA. ABP has inherent risk since sessions keys are embedded directly. However, for prototyping and experimentation stage, ABP should be fine.
Hi @carlrowan,
I see! i figured out the problem. In TTN the framecounter for OTAA was disabled. So now ADR is working! thankyou!
So there is no option to keep the framecounter after reset or power off the module. I think thats a problem because we are using a battery powered system where energy consumption is really important. the join method cost energy we dont want to waste. Do you have other suggestions for this problem?
Maybe this is an idea for a next firmware release?
Good to know it is working now. I am not aware of that kind of behavior. It is a new lesson to me as well. I seldomly disable frame counters. Only when using ABP.
Ideally, you will only join once to a network. That’s how the LoRaWAN architecture was designed to work. Joining multiple times is not healthy to the network since it occupies downlink air space (when gateway sends a downlink, it can’t listen to that channel). If the device operates in OTAA, there is no need to track the frame counters. It will only be needed on ABP (which is not encourage to do since session keys are hard coded). As LoRaWAN matures, join servers will be imposed making ABP likely to be a thing of the past and only designed for experimentation/development.
At this point, I can only give practical principles. I cannot guarantee if RUI3 will support framecounter configuration in the future and currently it is not in the road map. If framecounters will always be tracked, there might be a point that it might reach wear limit on flash memory since every transmission needs to perform flash write (each transmission increments the frame counter which also updates the count in flash).
