I can imagine, Rising HF chose not to put the BOOT0 pin on to the outside so we can’t get to the ST boot loader for de-bricking via that route. I’ve got in a pickle a couple of times and had to use many fingers & STM32CubeProgrammer to retrieve a module - but not often enough to end up with notes.
The LoRa-E5 does look attractive, from the spec sheets, but the device is not what is seems. Make an error in programming and you might well be stuffed. Perhaps the manufacturer should post warnings about it, as in be careful how you program this device, you might implement a self destruct mechanism.
Well, I have managed to save the OTAA session state to FRAM, and a sketch that imposes what is saved in FRAM as a session after reset does appear to work, the credentails are accepted ant the node keeps transmitting payloads.
However, the original sketch starts out at SF12 and the ADP quickly brings that down to SF8, then SF7, in about 3 transmissions. But with the sketch that recovers the session details from FRAM, whilst the re-newed transmissions start at SF12, the node does not appear to accept from the Gateway the downlinks to change down SF as you would expect with ADP.
The node does carry on transmitting at SF12 and the FUP code increases the sleep period appropriatly. I realise I could save the session SF in use and recover it, but why does ADP not appear to be working ?
I haven’t done this YET - and as I have a few hundred as one of the only realistic items available in the supply chain, I’ll be careful - they are a bugg3r to get off once they are on a board.
And to add to not having Boot0 actually available, although Seeed have labeled an input as Boot0 (it’s for getting in to their updater as it comes from them), there isn’t a switch between LP & HP antenna outputs so it’s always on HP so in the EU we burn about 30-40mA more than we need on a Tx. That’s relatively inconsequential over the lifecycle of the battery - but it probably makes the difference between 3/4 years and 4/5 years.
RAK did the same with their STM32WL module but I’m told they have resolved it for their SIP.
Saving & restoring the current value should help:
That change does not appear to work, LMIC.dn2Dr starts anew at 3 = SF9BW125, and just stays there.
The change to save the OTAA session stuff to FRAM works well enough and at least when ‘testing’ you dont have to re-join every time you re-program the node.
On reset and recovery of the OTAA session, the node starts up at SF12 and the Gateway does send downlinks, but either the node is ignoring them or not acting on them.
Easy enough to set the SF to the last used on recovery of the session, but not good that the node appears to be ignoring the downlinks.
Do you save the downlink counter? If not your node will be ignoring the downlinks.
LMIC.seqnoUp and LMIC.seqnoDn are saved and restored.
Forcing the reset node to SF7 does stop the downlinks.
On a node reset, I can force the data rate to what ADR had set, SF7125, but still the Gateway sends downlinks.
Looking at the node up times, a transmission straight after join has an up time of around 7800mS. After a node reset and session recovery the node up time is around 3500mS.
So is it likley that the downlinks are being ignored because the node is not listening for them ?
Not at all, I suspect they are just formatted in a way that LMIC does it’s best with but between it & the LNS they don’t quite make it.
I regularly end up with nodes that are fully configured & tweaked yet still get downlink commands. I’m slowly working towards additions to LMIC to fully explain what it is hearing and what it is doing about it to try to debug this. But it can happen with LoRaMAC-node as well, so I think the LNS is as much a culprit as the device.
1 Like
OK, but in the case of the node with the recovered session its awake for some 4000ms less than the just joined node, so something is up.
And I presume its not desirable to have a downlink sent after ever uplink …
I don’t profess to understand it either but it has been an ongoing irritation since the move to v3.
So much so that I diverted from the planned tasks of the morning to resurrect the test code base that I’d worked on earlier in the year so that I can dip in & out of running tests to accumulate info & learn more about decoding MAC commands.
It’s not just LMIC that suffers, I use LoRaMac-node on Murata ABZ and STM32WL modules a lot and see similar issues that seem to just appear out of no where - or start on join (like setting the Rx1 window) and never ever go away.
Well, if you think about it, after the first join and ADR has settled, there must be some configuration\status stored in variables that is governing how the node subsequently behaves, listens for downlinks and for how long etc.
Now my code at such a low level is not that good, but I note the library code has not used private: to hide variables so one might assume that all the variables the library code is using are accessible from an external sketch, so you might then assume that in principal, you could save and restore the whole lot.
Whats needed to debug, is to be able to print stuff out within the library code, that does not appear to be possible with the SAMD21, Serial. is not recognised, but notes in the code suggest the use of Serial. is possible with an AVR processor.
To facilitate this I’m running it on an ATmega4808 / RFM95 combo
Think I have solved the problem of the ADR being ignored.
The basics of saving the session keys and status to FRAM and the recovery are working, but when the RecoveredState starts up in SF12, ADR does not adjust back down to SF7. The Gateway is sending downlinks but the node either does not listen for them or is ignoring them. In the case of the node with in RecoveredState mode its awake for some 4000ms less than the node in FreshJoined mode.
I added a large pile of LMIC.****** variable prints, about 60 of them to see what was going on.
Comparing the FreshJoined prints with the RecoveredState prints, LMIC.rxDelay is 5 for FreshJoined mode and 1 for RecoveredState. Now if rxDelay is how long the software says the node should listen for an RX and it is in seconds, it would explain the 4000mS difference in awake time between FreshJoined mode and RecoveredState. So I change the sketch and impose an rxDelay of 5 after the RecoveredState code restores the session state from FRAM.
Now ADR on the RecoveredState node works, the ADR is not as fast as the new OTAA join, but it changes from SF12 down to SF7 in about 4 transmissions, and then stays at SF7. There are still downlinks, about 1 in 5 similar to what @DavidTaylor_DPI reported I believe. Not sure if that number of downlinks is something to worry about.
Whilst the node code is primarily intended for a Seeeduino XIAO, the combination of Low Power Sleep, BME280 sensor, FRAM, Cayenne payload and the recovery of the OTAA session from FRAM, will fit on an Atmega328P, aka Arduino Pro Mini. Tight on Flash, but a significant pruning of the Serial debug messages should cure that.
I have some of them, but already have a node for the plug in LoRa boards that uses an ATMega1284P, plenty of memory there.
May-be you should check what the initial join accept provides as parameters and save all of them, not rely on RX1 being 5 seconds. There are other parameters like the additional frequencies (apart from the 868.1/3/5MHz used by join) you need to recover (and not use at join time) as well.
1 Like
Yes, them, but presented like an ADR request as that’s the way to set the channels on join - I think - still figuring that one out.
Are those the ones stored in LMIC.*******
band_t bands[MAX_BANDS];
u4_t channelFreq[MAX_CHANNELS];
Is there an more general purpose library, that does what cayenneLPP.h does but in a more flexible manner ?
CayenneLPP works, but there appears to be no scope for general purpose counters, flags etc.