Dear,
We noticed an issue with LoRa E5 transmit in EU868, looks like using only RFO_HP has some side effect, and need some firmware changes to avoid over current consumption.
STM did not handle this typical case in their source code (RFO_HP only) so everyone using their code without changes is subject to this bug. So RAK3172 has same issue and I already put all details on RAK forum in post and they are currently fixing FW for that. Hope you’ll be able to do the same.
Hi challard, thanks for the link!
Strictly speaking, this is not a bug, but a feature since it requires both:
Software changes alone will reduce output power, which is not what we want, right? But if one has to make changes to hardware for optimal 14dBm output from HP path, then why not use LP path altogether? Maybe that’s the reason why both HP and LP exist? Because their chosen PA requires different matching network for lower power?
Anyway, what I decided to do is to compensate for power loss in the software, so that observed transmission power does not change. I’ve got less current than in stock firmware, but still more than one would expect from optimized hardware.
Here is what I’ve measured before and after the patch:
| LoRaWAN power | PHY tx power, dBm | ST firmware, mA | Patched, mA |
| ------------: | ----------------: | --------------: | ----------: |
| 0 | 14 | 86 | 60 |
| 1 | 12 | 77 | 59 |
| 2 | 10 | 70 | 46 |
| 3 | 8 | 63 | 44 |
| 4 | 6 | 59 | 42 |
| 5 | 4 | 52 | 39 |
| 6 | 2 | 46 | 36 |
| 7 | 0 | 41 | 32 |
One caveat: LoRaWAN middleware defines Max EIRP as 16dBm for EU868 region and antenna gain as 2.15dBi and asks SUBGPHY to transmit floor(16 - 2.15) = 13dBm at TX_POWER_0 (default). This is not correct IMHO, since it is allowed to transmit 14dBm(25mW) via dipole antenna in Europe. So, I corrected Max EIRP to 16.2, it is included in the patch.
Patch is made for STM32CubeWL Firmware Package V1.1.0 / 16-June-2021, but should also work for 1.0.0. Just look inside, there are couple of small changes. It will be overwritten by code generation from CubeMX, so be aware.
All that is relevant for slower bitrates, since in DR5 it is already possible to build a sensor device which would run for 10 years on 2 AAA batteries. This is with the default settings for EU868 and ST firmware. Effect for DR5 from this optimization will be marginal because TX uses just a part of the total power budget. Current consumption for RX, sensor and idling will be the same.
A word about measuring transmitted power. I used RSSI on my own gateway and HackRF One. This is by no means precise measurement, I just compared signal strength before and after the patch. Would be nice if somebody with proper equipment could confirm that max transmitted power is within the legal EU boundaries.
Thick disclaimer: I provide this patch for educational purposes only as part of my own R&D activities, do whatever you want with it, I am not responsible for anything.
Apparently, I cannot upload the patch here, so I just copy-pasted it below.
Subject: [PATCH] Optimized settings for txpower below 14dBm
---
.../stm32_radio_driver/radio_driver.c | 23 ++++++++++++++++++-
.../LoRaWAN/Mac/Region/RegionEU868.h | 2 +-
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/Middlewares/Third_Party/SubGHz_Phy/stm32_radio_driver/radio_driver.c b/Middlewares/Third_Party/SubGHz_Phy/stm32_radio_driver/radio_driver.c
index d91579c..bea62ec 100644
--- a/Middlewares/Third_Party/SubGHz_Phy/stm32_radio_driver/radio_driver.c
+++ b/Middlewares/Third_Party/SubGHz_Phy/stm32_radio_driver/radio_driver.c
@@ -669,7 +669,27 @@ void SUBGRF_SetTxParams( uint8_t paSelect, int8_t power, RadioRampTimes_t rampTi
SUBGRF_WriteRegister( REG_TX_CLAMP, SUBGRF_ReadRegister( REG_TX_CLAMP ) | ( 0x0F << 1 ) );
// WORKAROUND END
- SUBGRF_SetPaConfig( 0x04, 0x07, 0x00, 0x01 );
+ int32_t TxConfig = RBI_GetTxConfig();
+ if (TxConfig == RBI_CONF_RFO_HP) {
+ // We are in rfo_hp ONLY but it's not optimal settings for other than +21dBm or +22dBm
+ // See Section 5.1.2 of Application Note
+ // https://www.st.com/resource/en/application_note/an5457-rf-matching-network-design-guide-for-stm32wl-series-stmicroelectronics.pdf
+
+ if (power <= 14) {
+ // compensate for power loss because of impedance mismatch
+ if (power > 10) {
+ power += 6;
+ SUBGRF_SetPaConfig(0x02, 0x03, 0x00, 0x01);
+ } else {
+ power += 4;
+ SUBGRF_SetPaConfig(0x02, 0x02, 0x00, 0x01);
+ }
+
+ }
+ } else {
+ SUBGRF_SetPaConfig(0x04, 0x07, 0x00, 0x01);
+ }
+
if( power > 22 )
{
power = 22;
diff --git a/Middlewares/Third_Party/LoRaWAN/Mac/Region/RegionEU868.h b/Middlewares/Third_Party/LoRaWAN/Mac/Region/RegionEU868.h
index f0efe44..749d3f1 100644
--- a/Middlewares/Third_Party/LoRaWAN/Mac/Region/RegionEU868.h
+++ b/Middlewares/Third_Party/LoRaWAN/Mac/Region/RegionEU868.h
@@ -122,7 +122,7 @@ extern "C"
/*!
* Default Max EIRP
*/
-#define EU868_DEFAULT_MAX_EIRP 16.0f
+#define EU868_DEFAULT_MAX_EIRP 16.2f
/*!
* Default antenna gain@Alexander_Dvorkovyy,
thanks for this patch, I did not implemented the power compensation but looks fine and makes sense (and also why you have more consumption than I)
Of course official answer from Seeed with real measurement would be fine so we can really know how to correct and fix this issue.
I wanted to keep the maximum range (=tx power) and reduce current consumption (=extend battery life).
Without power compensation you have to sacrifice range for lower current. This is were I started, and thought it would be interesting only for some niche applications - where range is not so close, but not too far and battery life is important. Even then it is questionable what can you really achieve in practical terms - like battery life on real device, with total current consumption and how much range you can trade for it. Tricky.
With power compensation it is a no-brainer: you transmit same power (no need to sacrifice range) with less current. Btw, this is by my definition means a better matching of RF part.
It is possible to achieve currents as low as 20mA during transmission (and power the module with a coin cell battery?), and the range will still be practical, like tens of meters easily. If that’s your goal, then you know the place in the Middleware which needs to be tweaked 
BUMP… I am interested to know if this has been addressed or changed, updated or clarified ? here or anywhere else.
I have followed the thread on Things Network Lora Boards
C’mon SeeedStudios LORA is a great opportunity to level up your products. IMO
GL :-p
Hi. FYI Seed had released the LoRa-E5-LE version of the chip which claims to have only RFO-LP. 14dBm with claimed ~25mA power consumption.