ahah you beat me, I didn’t even noticed this very interesting line in the datasheet in green below
Yes I think it’s correct with optimized hardware it should be possible and yes it’s a design flaw for EU868 in this case. Would be interesting to have though from @elsalahy and @cndrxn of generic node team
I got caught out by the high power consumption of the LoRa-E5 as well. I’m working on a solar-powered air quality monitor and originally designed it to make use of the RN2483, but as they’re out of stock until 2022 I redesigned it to use the LoRa-E5.
When I got the boards everything went fine until I tried to transmit a message, when everything would reset. I realised it’s probably a power issue, as the LDO regulator I was using (H7333-A) delivers a maximum output current of 250mA. I’m driving both the LoRa-E5 and a MDBT42Q (nRF52832 BLE module) from the same regulator, which in theory should work, as the max power consumption is now 92mA and 12mA respectively, but decided to replace the LDO regulator with a 500mA one and it then worked just fine.
@Charles I found your SeeedStudio forum post but I see there’s no response yet. And also no response on their GitHub repo either 
Looks like I should’ve got with RAK Wireless instead, as it appears like they actually want to fix the problem.
Thank you, @Charles. Your boards looks awesome.
It is indeed the very reason why we’ve implemented both HP and LP RF paths on the Generic Node. In most of the use cases +14 dBm (LP) output is more than enough and it provides huge energy savings.
FYI, there’s another STM32WL module available from Move Solutions and it’s called MAMWLE-C1. It’s a bit pricier, but breaks out all the available GPIOs and has support for both LP and HP RF outputs.
A while back I’ve designed a Feather breakout for it:
Thanks @cndrxn , good to know, would be interested to have some Penguino for testing, let me know how if you know.
BTW I ordered 2 Generic Node, did you had a chance to confirm approx 25mA at 14dBm EU868 ?
Cool - will these appear on Tindie? Would be super useful if the SAMR34 & the RAK4260 boards were available, first one I’d definitely need populating - there is stock on Microchip Direct but having started on a design to use the more small-manufacturer-friendly WLR089U those are now on Oct '22!
for making boards availble (Tindie!?)
Thanks. I’ve soldered couple of MAMWLE Penguinos recently, and yes @descartes they will be available on Tindie soon. I’m having hard time finding some parts to prepare more RAK4260 versions.
@Charles, GN runs at +2.8V therefore the current consumption will be slightly higher. We’re seeing ~35mA @+14dBm on VDDRF, and you always have the possibility to switch to HP output for longer range (US only).
It was the SAMR34 that most interests me as I can get them at present.
How do you manage to place the BGA?
With my shaky hands it takes couple of tries while holding my breath 
. It’s not too hard if you have good solder paste application. I’m using laser-cut and electropolished steel stencil.
SAMR34 version will be available at limited numbers then EOL.
Hi Gerrit, I suspect your LoRa-E5 is not the main culprit regarding the power consumption. I also use the LoRA-e5 in a solar powered air quality monitoring systems and the LDO I use is also limited to 250mA. I have lots of these units deployed in the field. In my case I monitor CO, CO2, O3, SO2, NO2, particulate sizes, VOCs, temperature and RH, drive an OLED, status LEDS etc. All sensors are sampled simultaneously (therefore worst current consumption). None of these units have any dropout problem. Perhaps you had a faulty LDO or output capacitor on the output of the LDO?
That’s definitely possible, or the HT7333-A doesn’t meet the specs in its datasheet. I’ve swapped the LDO out for a 500mA one on two boards now, but will experiment with other boards that still have the 250mA one in place.
Can you share more details on your solar powered air quality monitoring system? Mine is still a work-in-progress, but I’ve already open-sourced it here: GitHub - OpenAirMonitor/OpenAirMonitor: Main repo for the OpenAirMonitor
The product was developed as part of a geographically dispersed system for monitoring Wildland Fires and for studying the effects of fires on communities. The background of it is here in this blog: https://www.brushelectronics.com/blog/ and the resulting commercial product is here: thingy.us
There are a few different options for presenting the data, managed, unmanaged, some hosted, some not. This graphic is from a unmanaged site in Western Australia that is hosted on customers own hardware. For confidentiality reasons I edited the graphic and removed some gauges, as well as status and location information. 
Looks remarkable like a Dunsborough profile to me 
Dunsborough yes, but the location is not specific enough to identify the property where the node is deployed.
I forgot to add, I liked the look of your board (very nice) and have a small suggestion. If you moved the radio to a small board, something like the board the seeed Lora-E5-Mini, then you can locate just the radio outside of the Air Quality sensor. This way you can put the sensor to best fit the environment you are monitoring, and have the radio somewhere best suited for maximum signal strength. This is much better than running an aerial cable to a remote aerial as there are no losses in signal strength as a result of the antenna cable. For the same TX/RX power budget you get better TX and RX signal strength.
stm32duino Verson 2.1.0 is released! GitHub - stm32duino/Arduino_Core_STM32: STM32 core support for Arduino
FYI:
The name STM32duino is incorrect, ambiguous and confusing.
The correct name of this Arduino core is “Arduino Core STM32”.
See my following post in the Big STM32 topic for more information and below quote from this post.
The world of (names of, supported functionality, compatibility of and references to different) Arduino cores for STM32 is not transparant and confusing.
Much different than Arduino for AVR, SAM(D) and ESP32.
In the Arduino IDE it is currently listed as “STM32 MCU based boards by STMicroelectronics”.
In PlatformIO it is called “framework-arduinoststm32” (as part of the platform “ST STM32”). Until recent PlatformIO used it’s own implementation of Arduino support for STM32 instead of ‘Arduino Core STM32’. I’m not sure whether that has changed but I assume not.
There is no consistency in naming of different Arduino cores for STM32 (and references to those cores) which can be confusing. My advise is to use the offical name of the Arduino cores. In this case: “Arduino Core STM32”.
I have create a repository GitHub - glompos21/LoraWAN_RAK3172 at tutorial with a small guide on what changes have to be done after autogenerate code with STM32CubeMX for the RAK3172. I have also included the ioc with I2C enabled. RAK4172 uses a single core ARM-M4 STM32WLE5CCU.
It has been a while since this was posted. Any progress on using a coin cell?
I use 2CR2450 to power the Lora-E5 module, after set the TX power to 8dbm, the battery only can last 10days. Now I try to add a super cap for buffer. You can choose murata CR2450R battery which is improved for peak current(50mA), but these battery is not easy to get on the market. But in general, using coin cell is not a good idea for Lora end device.