Thanks descartes.
I am operating on energy harvesting methods.
So, it is imperative to save the values and commit to a transmission only when sufficient energy budget is available.
If, in case there is energy deficiency, the MCU and LoRa module will lose power causing power on reset on the next attempt at transmission.
Which ones?
Solar Cells based energy.
During overcast, absence of sufficient luminosity risks regeneration.
What’s wrong with a LiPo battery to store excess energy?
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.
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.
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.