The design is small sized around 2.5 mm x 2.5 mm only.
We cannot bulk it with batteries or have a wire connected for power supply.
That will severely impact reliable storage of persistent LoRaWAN stack data as well. You risk inconsistent data if there is energy loss while saving state.
Good luck writing it. You need thorough understanding of your LoRaWAN stack and the the protocol to do this right.
Have you noticed the TTN Conference session on devices using energy harvesting? https://www.youtube.com/watch?v=vU1VYgzqs6I&t=3
Correct,
we predetermine energy budget available before enabling LoRa Radio activity.
Correct,
This is a heavy duty.
Accordingly, as previously recommended by descartes, we shall use EEPROM emulator pack from ST to maintain necessary RAM retention under flash pages.
Obviously not, as both the IC packages and the antenna are bigger than that.
You probably mean centimeters.
At which point you’re into the realm where you can use a small coin cell for RAM state retention, or use a capacitor and a non-volatile mram or something - of course that requires taking time to actually understand how LoRaWAN works.
Any search for compactness and low power also points to using a single processor, not two.
Yes, its 2.5 cm x 2.5 cm x 2.5 mm Cube.
Will look for options in this space to support state retention or management.
We shall update on finding those options
Thanks
I believe @cslorabox would be best placed to comment on implementing the EEPROM code - it’s something I’m rather hoping a current project using the ABZ will move to a PCB revision so we can put some FRAM on rather than do that.
And given a LIR2450 button cell, 24mm x 5mm providing 120mAh at 3.6V, will support sleep for months and can be recharged and with appropriate battery management / solar output circuitry with a supercap to support the Tx, you can wake, check for power levels, run the sensors, uplink etc etc.
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.
But any solution for wake up on a schedule will require power to be consumed.
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.
1 Like
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.
1 Like
Thanks, Descartes.
We will include these recommendations into our next design cycle.
We have added these into our design hardware modification tracker.
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.
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.
THank you @MedadNewman ,
We have bookmarked the repository.
We shall explore this recommendation to resolve the current frame counter issues.
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.
Good spot! I shall have to look.
Yes, it’s called “the documentation” that’s included with the code.
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.
1 Like
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?
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.
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!!
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.
1 Like