Long time here without designed a public LoRaWAN node board, so with new STM32WL all in one modules based on STM32WL55 available, I went further for investigation in custom node design for testing. Since one of my first Low Power LoRaWAN node with Arduino (OMG 4 years ago) and 1uA consumption has been so popular may be this one will also
So I made 2 boards based on 2 popular modules, one for LoRa-E5 module from Seedstudio and one for RAK3172 module from RAK Wireless. Easy to provide, easy to hand solder and so cheap, love them.
To my surprise, they works out of the box, they have plenty of flash and RAM so itās really a huge progress in 4 years and now we can put awesome code on it such as mbed-os based firmware, so nice. Iām also pretty sure it could be easy to run Generic Node firmware on these one with some changes, so if someone does, just let me know here. I also know @disk91 was thinking adding STM32WL to his excellent sdk
Iām sharing here, Iām pretty sure they would interest the community:
LoRa-E5
RAK3172
See readme on their dedicated repo github
Of course Iām not using these board with original AT modem but with custom firmware. I switched now to mbed-os and boards have been added to stm32customtargets for those who want to play with mbed-os.
Here my experience on these 2 modules:
Smaller (LoRa-E5)
Thicker (LoRa-E5)
Easier Soldering (LoRa-E5)
Available # of GPIO (RAK3172)
on board Ipex (u-FL) connector (RAK3172)
No STM32WL RF_LP path, both works only with RF_HP (mainly due to BOM and size constraints)
TXCO (LoRa-E5) RAK3172 must be configured/drived with No TXCO
Price (RAK3172) $5.99 against $9.90 for LoRa-E5 ($8.90 by 10+)
With original FW they can both do interesting LoRa tests (but not tested this one)
@bluejedi this is the next step I need to do, module are announced from 1 to 2 uA sleep mode but looks like nasty bug not fixed on mbed lorawan example. So for now Iām still looking for the best (and easier) pro framework to use with.
I also got some sample with STM32WL framework but to be honest itās not easy to work with due to the number of files and folders used. Also Generic Node SE source code looks great so Iām thinking using it if we can set these CPU targets into
I wonder if stm32duino will add LoRa support for the STM32WL. In the main README under Nucleo boars it says no. But maybe itās Nucleo specific and available for the generic micro?
If they do support the WL55 for LoRa, hopefully they will bring the I-NUCLEO-LRWAN1 up to date (from 2018) and perhaps provide support for the B-L072Z-LRWAN1.
With regards the āhigh power consumptionā in TX mode, my recollection is that the vast majority of LoRa modules use the PA_BOOST output so as to allow for operation above 14dBm. There are some modules that use the RFO outputs which would give much lower TX power consumption, cant say I recall a module that uses both and gives you the choice.
In fact the STM32WL is able to do both, just that they limited to maximum due to components price and space I can imagine (makes sense since who can more, can less) but Iām not sure it was anticipated that leaving max (HP only) and using 14dB had the incidence of twice consumption.
I still donāt understand on hardware view how it is possible that same power (14) can consume 40mA in LP mode and 80mA in HP mode, consumption is always related to power not? Thatās what we learn from decade (Ohm law), Iām pretty sure I miss something.
Suspect its a combination of things - RF PAās tend to be inefficient so delivering same power with or without PA obviously adds that overhead, (IIRC I think the PAs are also fed with an additional, seperate regulated pwr feed - with its own losses!) also PA (and any associated VReg) will be been optimised for max eff at the higher or poss highest Tx output powers to minimise device heating etc., where at lower Tx those inefficiencies are a larger proportion/contribution overall. Also if output is +14dbm max you have no headroom to allow for typical losses associated with connectors and cables etc. such that the full 14 allowed by Regs (~16dbm EIRP with stadard Ant) is achievable. Its not uncommon to see folk running āhotā for the PA_Boost output at say 16-18dBm with lossy RF path via balun/matching, cables, connectors, 0 or <0dbi Atnt etc. to still hit 14 (16 EIRP) outputā¦that then forces market to use PA_Boost o/p and hence the module manufacturers pander to that demand!
As @Jeff-UK has mentioned PAs tend to be very inefficient, so as well as consuming the power for 20dBm, the PA might need the standard RF output to be running at 10dBm or more.
it appears the power consumption should be 45.5mA for the HP PA at 14dBm when optimized for 14dBm, but 92mA when optimized for 22dBm. It would only be 23.5mA if the RAK3172 could connect the LP PA rather than the HP PA.
So the RAK3172 module design is actually flawed for 14 dBm operation, making it use twice as much (45.5 mA) current than what would be possible (23.5 mA) with the STM32WLE5CC chip?
Yes for twice, and no for numbers.
At 14dBm it should have a consumption of 45mA and it has 90mA because FW does not take into account the design choice of RFO_HP only (which by the way is a smart idea to reduce BOM and PCB size) and that the same with Seeed LoRa-E5. Both have taken ST base code without changing it for this specific feature.
RAK is now working on it and will release an update soon I think. I posted on seeed forum also and in the meanwhile I made a PR to fix that for mbed-os
My suspicion is that with default AT FW for both of these boards we are much higher than 14dBm power but I have no idea how to measure that (except that my RSSI looks very low for EU868) So if anyone has material to check that, I would be interested to know because Seeed claims CE/RED certification for this module.
Which the RAK3172 cannot because they donāt provide LP PA on the module.
For BOM and PCB size this may be smart but if this means using 45.5 mA instead of 23.5 mA that would be possible if it would have supplied LP PA (RFO_LP or whatever its exact name) that means it uses twice as much power (45.5 mA) than what would have been possible with the STM32WLE55 chip. From battery operation perspective that would be a design flaw because using some 100% more power than necessary (if I understand correctly).
