In V3, ABP uplink messages are missing

[MedadNewman]

For reference, the Semtech LoRaMAC-node reference code implements the preservation of the state(fcount, keys, channels etc) to EEPROM. It is enabled by default. It has an implementation for B-L072Z-LRWAN1 dev board which uses the CMWX1ZZABZ-091 module.

No need to roll your own EEPROM preservation code.

The code can be found here.

GitHub - Lora-net/LoRaMac-node: Reference implementation and documentation of...

[HON_WASP]

Thanks, Descartes.
We will include these recommendations into our next design cycle.
We have added these into our design hardware modification tracker.

[HON_WASP]

@descartes

The overriding issue is if you turn things off, there still needs to be something to turn things back on, like a TPL5110, which draws 20uA and you can’t program the time range or put a RTC which draws ~1uA and is programmable for wake up.

We are just using energy budget based operations for now.
Inclusion of RTC is necessary with a battery to backup in periods of longer starvation.

[HON_WASP]

@descartes

But I guess you are, as Jac suggests above, gambling on enough power to run a sensor / uplink cycle and have enough left over to save the relevant info and just not do anything when the sun doesn’t shine. If you have solar and even if you regularly uplink, you will have power to charge a battery or use a supercap for RAM retention.

Indeed, the device performs operations based on energy budget available from buffer capacitors.
We conditionally perform LoRa operations based on the energy budget for the current transaction.

[HON_WASP]

@MedadNewman

For reference, the Semtech LoRaMAC-node reference code implements the preservation of the state(fcount, keys, channels etc) to EEPROM. It is enabled by default. It has an implementation for B-L072Z-LRWAN1 dev board which uses the CMWX1ZZABZ-091 module.

No need to roll your own EEPROM preservation code.

The code can be found here.

THank you @MedadNewman ,
We have bookmarked the repository.
We shall explore this recommendation to resolve the current frame counter issues.

[HON_WASP]

Is there a build process documentation for - B-L072Z-LRWAN1 ?
We would like to test it out as our design is based on the B-L072Z-LRWAN1 as reference.

[descartes (Nick McCloud)]

@MedadNewman

Semtech LoRaMAC-node reference code implements the preservation of the state

Good spot! I shall have to look.

@HON_WASP

Is there a build process documentation for - B-L072Z-LRWAN1 ?

Yes, it’s called “the documentation” that’s included with the code.

[descartes (Nick McCloud)]

@descartes

@MedadNewman

Semtech LoRaMAC-node reference code implements the preservation of the state

Good spot! I shall have to look.

Bizarre - implemented in the NUCLEO-L053R8 and the NUCLEO-L073RZ projects for AT Slave in the STM32CubeExpansion_LRWAN_V2.1.0 code, but not for B-L072Z-LRWAN1 and not for any LoRaWAN end node project - which rather implies the expectation that an end node will stay on all the time whereas an AT slave can be turned off.

And the LoRaMAC-node doesn’t have an AT slave. And the project is really centred around using VSCode.

And my clients wonder what all those ‘extras’ on the invoices are - I think this is a good case in point.

[HON_WASP]

@descartes

Bizarre - implemented in the NUCLEO-L053R8 and the NUCLEO-L073RZ projects for AT Slave in the STM32CubeExpansion_LRWAN_V2.1.0 code, but not for B-L072Z-LRWAN1 and not for any LoRaWAN end node project - which rather implies the expectation that an end node will stay on all the time whereas an AT slave can be turned off.

If the source code for B-L072Z-LRWAN1 does not implement state preservation, then we need another alternative provision or direct efforts into implementing state preservation.

What would be the best way to put our effort into this?

[cslorabox]

@HON_WASP

What would be the best way to put our effort into this?

Take time to understand how little is different between the Nucleo and the Murata module (same processor core, potentially different SPI and GPIO pins used to talk to the radio).

Extract the functionality from the AT example and move it to the stand alone one. Or keep the AT example, which fit your original intent to use dual processors.

Personally I’d look at the 1SJ module instead as that also gets you the newer lower power radio, but those are less consistently available and less documented, so the project while ultimately better is going to be harder still, probably for where you are right now you need to pick a path of least resistance.

You’ve decided to do something unusually difficult (energy harvesting) but that also means that every other part of your system is going to be as difficult as normal, if not more so.

[HON_WASP]

That sounds a better plan!
We shall take up Nucleo example to trace the functional calls and replicate into the stand alone example.

Thanks Much!!

[MedadNewman]

@descartes

Bizarre - implemented in the NUCLEO-L053R8 and the NUCLEO-L073RZ projects for AT Slave in the STM32CubeExpansion_LRWAN_V2.1.0 code, but not for B-L072Z-LRWAN1 and not for any LoRaWAN end node project - which rather implies the expectation that an end node will stay on all the time whereas an AT slave can be turned off.

I would not recommend using the STM32CubeExpansion pack at all. Best to use the Semtech version direct from Github. While the ST version is easier to use, it uses a very old version of the Semtech LoRaMAC-node stack, which likely does not have the latest features. The EEPROM state preservation feature was added to the Stemtech code in the v4.4.7 release and its likely its not been packaged into the ST version.

The original Semtech version has an implementation for the B-L072Z-LRWAN1. I compile and develop on Visual Studio code on Ubuntu 20.04. Its virtually impossible to get it working on Windows. Too much complication. The readme on the repo has info on compiling and uploading code to the dev board.

[descartes (Nick McCloud)]

@MedadNewman

I would not recommend using the STM32CubeExpansion pack at all.

Nope, me neither, I’d recommend Microchip Studio / SAMR34. It lets me do everything for a simple device in two pages of A4 all in the same file if I so choose.

@MedadNewman

While the ST version is easier to use,

Both code bases are prime examples of “easy to use if you happen to have written the code base” so it’s all a bit relative. But after a few weeks of playing hunt the file to edit, you start getting numb and stop caring.

@MedadNewman

it uses a very old version of the Semtech LoRaMAC-node stack, which likely does not have the latest features.

v2.1 has LoRaMAC-node v4.4.7, so I suspect it’s as up to date as it’s going to get before the switch to LoRaWAN v1.1, coming soon. Only laggards would only just be moving to v1.0.3. Oh. Wait. That’s us.

The NVM routines should really be provided as stubs - next thing we’ll know is that the LoRaMAC code base will have peripheral & sensor code and a mini-scheduler principally to drive the Blinkenlights. Oh. Wait. Never mind, it already has.

Clearly IBM felt the need to compete with their own mini-RTOS/scheduler in LMIC as well. But then separation of concerns and simplicity aren’t really in vogue. More mahoosive Swiss Army knife - the one with the hoof pick & USB drive - big & clunky and very inefficient to use as a tool.

@MedadNewman

its likely its not been packaged into the ST version.

The Semtech reference boards cover a range of vendors and the BSP files are separated out from the LoRaWAN code which is probably why the EEPROM functionality wasn’t picked up by ST as I’m sure they’d prefer us to use the 330Mb CubeMX zip file with no examples for any MCU older than two years.

Not that I’m getting bitter & twisted. Oh. Wait. That already happened.

[HON_WASP]

Hi @MedadNewman, @descartes
We found that state preservation is available for NucleoL073 board.

We see two different approaches here -

1. Modify B-L072Z-LRWAN1 source files to match NucleoL073 state persistence feature.
2. Modify NucleoL073 source files to match B-L072Z-LRWAN1 board settings.

We see that option-2 is path of least resistance.

Do you concur on this?

Thanks

[descartes (Nick McCloud)]

@HON_WASP

Do you concur on this?

No, option 2 is a huge fundamental set of changes to an already complex code base.

Option 1 could be as simple as copying a 2 or 3 files over.

[HON_WASP]

Thanks, @descartes

We would be looking at copying only “NVM” routine files into B-L072Z-LRWAN1 source files.

[cslorabox]

@descartes

No, option 2 is a huge fundamental set of changes to an already complex code base.

It’s not trivial but both situations have the same processor connected to the same radio, only via different pins, so there are only a limited number of places that’s going to show up - SPI bus number, pin assignments, and maybe the choice of debug UART.

[HON_WASP]

Correct.
We shall explore the pin and peripheral assignments.

We have checked the source code for B-L072Z-LRWAN1 and it does have NVM usage for state preservation.
(

• // Restore data if required*
• nbNvmData = NvmDataMgmtRestore( );*
  )

It needs modifications to handle power-on reset and resume scenario.

[MedadNewman]

@HON_WASP

• Modify B-L072Z-LRWAN1 source files to match NucleoL073 state persistence feature.
• Modify NucleoL073 source files to match B-L072Z-LRWAN1 board settings.

Might I suggest a 3rd approach, perhaps an even lower resistance path :

• Acquire a NucleoL073 dev board and test on that

Regards
Medad

[HON_WASP]

We shall try out implementation using B-L072Z-LRWAN1 source files.
It has the same initialization sequence for LoRa as NucleoL073.

We suppose both are equal upon compilation for respective targets in LoRa parameter management using state persistence.

Thanks @MedadNewman @descartes @cslorabox