2023-03-23 05:07 AM
Hi fellas,
We are planning for LoRa based FUOTA updates using STM32 MCUs. The LoRa Transceiver we are planning to use is SX1302. In I-CUBE-LRWAN blog, they told its meant for STM32L0/1/4 series alone. Can we use some other series like STM32G0 series, for cost reasons? If not, what is the actual reason for it? As STM32G0 also has SPI interface, which can be interfaced to our Transceiver.
Also, as another hiccup, SX1302 has only HAL support, which works in Linux based Processor and no implementation idea has been given in terms of Controller? Any suggestions regarding that?
Solved! Go to Solution.
2023-03-23 06:38 AM
Well, here you have to distinguish between different requirements: the SX1302 is not a transceiver for mobile use, but a baseband chip for LoRaWAN network gateways.
The I-CUBE-LRWAN package, on the other hand, is intended for the mobile nodes with SX1272, SX1276 and SX126x, which is also mentioned in its data brief db2961. The requirement to use particularly little energy to operate the nodes, so that e.g. a 2032 battery actually lasts 10 years, inevitably results in the orientation towards the ultra low power STM32L0, STM32L1 and STM32L4. The STM32G0s require significantly more power than the optimised STM32L, but with some work, the library should be able to be tailored to the STM32G0.
Finally, regarding the Github project, for which not STMicroelectronics but Semtech is responsible: a gateway requires a lot of computing power and is also relatively energy-hungry. However, the project seems to be several years old, so that newer developments such as the STM32H7 or STM32MP1 could probably not yet be taken into account.
Hope this helps a little in demystifying LoRaWAN and the software and hardware required?
Regards
/Peter
2023-03-23 06:38 AM
Well, here you have to distinguish between different requirements: the SX1302 is not a transceiver for mobile use, but a baseband chip for LoRaWAN network gateways.
The I-CUBE-LRWAN package, on the other hand, is intended for the mobile nodes with SX1272, SX1276 and SX126x, which is also mentioned in its data brief db2961. The requirement to use particularly little energy to operate the nodes, so that e.g. a 2032 battery actually lasts 10 years, inevitably results in the orientation towards the ultra low power STM32L0, STM32L1 and STM32L4. The STM32G0s require significantly more power than the optimised STM32L, but with some work, the library should be able to be tailored to the STM32G0.
Finally, regarding the Github project, for which not STMicroelectronics but Semtech is responsible: a gateway requires a lot of computing power and is also relatively energy-hungry. However, the project seems to be several years old, so that newer developments such as the STM32H7 or STM32MP1 could probably not yet be taken into account.
Hope this helps a little in demystifying LoRaWAN and the software and hardware required?
Regards
/Peter
2023-03-23 09:03 PM
Hello Peter,
It's really helpful to note the databrief of I-CUBE-LRWAN, which we have missed.
Is there any suggestions from your end regarding interfacing SX1302 (which we are planning as LoRa gateway) to STM32 MCU's apart from its defacto suggestion for a MPU powered with Linux based distros?
Regards,
GanesanGuru
2023-03-24 12:51 AM
Depending on the requirements, an STM32 based on Cortex-M7 may be sufficient for a gateway. Depending on the required frequency range and thus the frontend to the SX1302, you can either use the kit P-NUCLEO-LRWAN2 (868/915/923 MHz) or P-NUCLEO-LRWAN3 (433/470 MHz) as a starting point for your development.
You can find the kits and more information on our LoRaWAN overview website.
Regards
/Peter
2023-03-27 03:56 AM
Hi Peter,
Again, there is a small doubt Peter. Can we able to interface STM32L4 Series to Semtech sx1261 Transceiver, directly using SPI interfaces and perform a FUOTA efficiently? Is there any practical / real-time implementations avaible, so that I can refer those?
Regards,
GnaesanGuru
2023-03-27 04:33 AM
Well, you would have to use an STM32 with dual bank flash so that FUOTA can be written to the second bank until a check to be implemented shows OK beyond doubt and switch to this second bank.
But - this is indeed still a challenge, since the maximum data rate for LoRa is not only limited (300bps in extreme cases), but also the duty cycle is 0.1-1% depending on the band used.
A FUOTA of e.g. 512KB can therefore take up to 512k*8/300/0.001=13'981'013 seconds in the worst case, assuming 300bps and duty cycle of 0.1%, i.e. 161d 19h 36min 53sec ~ approx. half a year - provided the transmission is error-free. If there was anything wrong with the block, you would have to wait another half year for completion, unless you have split the block into smaller chunks and built in a protocol to eliminate errors.
An implementation of FUOTA over LoRa is nevertheless mentioned in the AN5554 for the STM32WL, which already supports on-chip LoRa. Maybe you can implement this on your transceiver?
Good luck!
/Peter