Custom boards based on LoRa-E5 and RAK3172

Hi there,

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
image

RAK3172
image

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)

Have fun

9 Likes

Hi @Charles,

Nice boards!

Can you share some information about their power consumption?

@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

What about the future stm32duino support?

1 Like

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?

image

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. :crossed_fingers:

may be it will also be supported by generic node code, see this one I opened few days ago.

Also I made these boards enabled with stm32customtargets from mbed

3 Likes

A new one is born, wanted to use it with cell coin but not sure it will works due to high power consumption in transmit mode

Sans titre

Any advice on this one will be welcome, now fully supported by mbed-os with latest release.

2 Likes

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.

1 Like

Yeah 100% agree I’m afraid these one can’t “by design” that is really a bad surprise :open_mouth:

Whats ironic, is that I bet the vast majority of LoRa modules are used at no more 14dBm, the legal limit in a lot of places.

Its probably just marketting, a module that produces 20dbm\22dBm sounds so much more capable than one that is ‘limited’ to 14dBm.

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!

1 Like

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.

1 Like

Nice!

It would be interesting to test if higher capacity capacitors (e.g. 1000 uF) would make a difference (but they do have a larger footprint).

Another possible coin cell candidate is CR2477 with 67% more capacity than CR2450. I have no experience with these though.

@bluejedi yes got some CR2477 also from ruuvi tags was my idea to test. For now got soldered 2x330uF + 1x100uF not so far from 1000uF :slight_smile:

ok guys, we can follow the over consumption issue there, matching, of course but needed firmware configuration also. Thanks to RAK team

2 Likes

From the RAK forum:

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.

Was aware of that. :wink:

However mintenj mentioned:

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).