Hello,
We are trying to register device as “ABP Device” with frame counter check disabled.
There are no uplink messages received after first message.
The device resets frame counter on every uplink transmission.
How to fix the issue?
Is the Issue persistent for all ABP devices that reset frame counters?
THanks
Regards
Raju
That’s not at all proper behavior for a LoRaWAN node.
Disabling frame counter checks exists for systems people are working on that might reset their frame counter every time new firmware was flashed, or at the outside ones that do so on re-application of power.
But a node that constantly resets its frame counter is going to cause the network to wastefully transmit a configuration downlink after each one…
You really need to make your node behavior in accordance with the LoRaWAN spec if you’re going to use it on TTN.
Hi cslorabox,
we have a APB device that is pre-configured with network and app session keys.
We would like to check the performance of device for various scenarios.
Currently, we do not want to drive efforts into Frame Count state retention.
Why is V3 not supporting the frame counter reset that was working in V2?
Thanks
There’s a huge difference between occasionally resetting the frame counter, vs. doing it for every single uplink as you are presently attempting.
Neither is legitimate LoRaWAN behavior, but the latter is really abusive.
Hello cslorabox,
May I know of its possible to utilize the reset frame counter to test the uplink along with the system? Or
Is it a Bug in the V3 console that does not support reset of frame counter ?
Thanks
It’s possible to use it correctly with a node whose frame counter resets infrequently
But you are using it abusively when your frame counter resets for every packet.
Even if it worked, you’d be wasting network downlink bandwidth since every attempt by the network to properly configure your “groundhog day” node would have to be repeated.
Please STOP abusing the community network. If you want to utterly ignore not just the letter but the very intent of the LoRaWAN spec, use your own infrastructure - both gateway and server.
Hi cslorabox,
You got your point across when you made your first reply.
But, you are failing to answer the query.
'I have an ABP device that does not consume any downlink bandwidth.
I hope you will be able to provide me with any information on the requested query.
Thanks
What you are not understanding is that all devices in V3 consume downlink bandwidth, as the network sends them MAC commands to configure operational details.
Your groundhog day device will require these to be repeated every time.
Please stop abusing the community network.
There is no obligation for anyone to answer a query but it becomes “complicated” when someone is using a community network and not even trying to meet the most basic technical standards. There’s not much incentive to help someone cause a negative impact on the community network.
There are many posts on here about setting the f_cnt reset using the CLI which you may find useful, as well as many requests from TTI that people use OTAA as even when you save the f_cnt in NVM, you will have to contend with a range of MAC downlinks that are best dealt with by OTAA.
As the majority of nodes are powered all the time, how have you a device that can’t save it’s f_cnt?
Yes,
I concur to your request to not abuse the network.
I shall make FCnt retention compliant to spec.
Then, I believe to test the network, Frame count resets is unfeasible.
Not true, as I said above there are plenty of solutions using the CLI to be found in the docs and on the forum, I think there has been at least a couple this week.
More pertinently, if you tell us more about your device maybe we can help you with saving the f_cnt.
Thanks, descartes.
We are using CMWX1ZZABZ-091 Murata Module and example code from ST LoRaWAN expansion package “end node” example.
Our device turns off the LoRa module on every LoRa Transmission.
May I know what do we have to update in the “end node” example to retain f_cnt ?
Thanks
Why? Is there some particular reason it turns off? But if you have a separate MCU, does it stay awake?
You’ll need the Cube EEPROM pack as some examples that you can then integrate in to the LRWAN code.
Correct,
There is another MCU in the system. (for application)
Thanks, I will take a closer look into the EEPROM pack for examples aiding towards retention of state.
Thank you , descartes.
I appreciate your assistance on the right approach forward.
Then you could use something like the RN-modules from microchip and set them to sleep mode between transmissions. Saving state is complex, you need to save the counters, but also spreading factor used, transmit power setting, frequencies used and depending on the location where the nodes will be used the used airtime in the bands to avoid breaking the law by exceeding allowed airtime.
Can it not be run on the Murata module?
We have partitioned the communication and application code into two MCUs.
Application runs only when needed to save a lot of power.
We have just wired the Murata Module to send information only when power is available from the Application MCU.
Yes,
That is true.
I would like to have a logic to handle that complex state retention for a LoRa connectivity.
Why?
Why?
Without any context we will find it very hard to advise.
The “normal” format for a typical battery powered device is one MCU that handles everything in blocking mode - ie it wakes, reads sensors, sends, waits for any downlink, goes to sleep, so we don’t have to do anything with saving values which is sufficiently problematic that we do get questions on the forum about what to save & why it’s not working well. But also there needs to be something to wake up, so it may as well be the RTC on the MCU.
There are also many devices around that use a module like the Murata as an AT device that is only for handling the LoRaWAN - I have a design using an ATmega4808 + RAK4270 that does this - but I tell the RAK module to sleep, I don’t turn it off. This uses a few more µA in sleep as it has two MCU’s sleeping, not one, but for certain development & deployment situations this suits.
Apart from supply issues, the Murata module is one of the industry standard devices that is very capable and has a very low sleep current. So if you are not too far down the design path, you may want to reconsider your architecture.
To get the very best help on the forum, please give us more detail on your application & requirements.