Hi,
I am using the RAK4631-LPWAN-Tracker example and want to extend it to receive data from Chirpstack and store it locally in a persistent manner.
In particular, I want to be able to change the devEUI in the generic device firmware to the correct value for the particular device.
I want then to be able to restart the device with an instruction from Chirpstack.
Presumably there is some way to access local storage on the device?
Thanks in advance
Alan
@Alangward
I am not sure, but it sounds quite unusual to connect the device with one DevEUI to a LoRaWAN server and then change the DevEUI with a downlink.
You can have a look into this flash function I wrote to store LoRaWAN parameters into the RAK4631 flash memory.
For the Chirpstack side to send an DevEUI and restart the node, I have no experience how to do this.
Hi Bernd,
Thanks for getting back to me, your flash function looks like exactly what I need.
The rationale behind what I want to is that I want to distribute a significant number of devices and have them set up by ‘normal’ people. So, the plan is to flash the same instance of firmware in all the devices and then as they are needed provide a mechanism for the ‘installer’ to easily set up the specific parameters for that device. One of those parameters would be the actual devEUI. They would need to also set up the device in Chirpstack so that the device could then join (again).
I see in your function’s code this call: sd_nvic_SystemReset
Can I assume that will restart the device so that it activates any new parameters?
Thanks again
Alan
Yes, sd_nvic_SystemReset resets the module and on the next start it connects with the saved parameters.
In the same example, I have as well a (not complete yet) AT command interface for USB. That could be as well a possibility to setup devices by installers.
How will you prevent more than one device being turned on at the same time - anywhere in the geographic distribution of your product - so you can’t tell installers to only turn on one at a time (which they will forget to tell their minion or the minion will try anyway) but any & all installers using the same backend to provision the device …
I’m not anticipating any magic smoke release, but I can see the ChirpStack retreating to the far corner of the servers RAM and having a cry.
So so much easier to use a serial to flash setup system as they are made or put a simple I2C EUI64 module on the board.
Hi Nick,
Thanks for the reply.
Any insight into how I can configure these devices is very welcome. It is early days yet and at the moment I have to change the source code to set the devEUI. Clearly that is not a tenable way forward.
Maybe we should use the process I have been thinking of earlier in the process when the devices are being assembled. If we do that one at a time then there shouldn’t be any real issues?
Clearly we will have to flash the firmware to each device over serial, but that would be identical for every device.
Apart from a serial command to set the DevEUI to be saved in flash or a chip, the other possibility is to script the compilation & download of the firmware. If you put the DevEUI in an include file, the compiler will only need to compile that file, link the files and then can be downloaded via the boot loader.
Hi Nick
Sorry about the slow reply.
I’m trying to avoid any staff other than the developers having access to the source code or the IDE, so I had already discounted that style of approach. I had thought of something fairly similar myself, but discarded it. I think I’ll press on with the mechanism I started this thread with, but as part of the assembly process rather than ‘in the field’.
Thanks, Alan
The Big Black Box of Boring as it is known is a small computer in the corner of the office with a small screen, some push buttons to navigate the menus and a serial lead. The chances of any users figuring out what’s going on inside the box is slim to none, but they are well informed on the state of Eastenders & Corrie.
RAK modules use the AT commands as we are plugging in to UART1. Arduino style modules either use a serial AT commmand-a-like or compile for each device, the latter being what makes it the Big Black Box of Boring as that takes slightly longer to run.
Alternatively batch run it on a developer computer as all you really need is the hex/bin file to be pushed through the command line programmer software.
Your original idea will break badly the day you have two customers installing at the same time or two installers from the same company or any other combination of having the same device credentials working at the same time, which may well end up with customers A creds being using on customer B’s device, but I think I’ve already said that.