{"id":2693,"date":"2024-11-17T14:00:09","date_gmt":"2024-11-17T13:00:09","guid":{"rendered":"https:\/\/www.nico-maas.de\/?p=2693"},"modified":"2024-12-07T17:36:59","modified_gmt":"2024-12-07T16:36:59","slug":"rak3172t-in-arduino","status":"publish","type":"post","link":"https:\/\/www.nico-maas.de\/?p=2693","title":{"rendered":"RAK3172T in Arduino"},"content":{"rendered":"

Updated on 2024-12-01 with latest fixes of STM32LoRaWAN v0.3.0<\/strong><\/p>\n

As the RAK11300<\/a> did not really match my requirements (it uses way too much energy), I looked further and found the RAK3172<\/a> which is based on an STM32WLE5CCU6 - an STM32 chip which usually include good powersaving modes. As with the RAK11300, I did not want to go down the Wisblock way and designed my own breakout board:<\/p>\n

\"\"<\/a><\/p>\n

This was actually not complicated as the RAK3172 has all needed components on board. I just added an H7333 LDO for powering it from 18650 cells and two additional features: First, the i2c port was aligned with the pinout the the usual BME280 breakouts from your typical websources - so that I could directly plug those in. Secondly, I made a solderbridge that allowed this i2c port to be 3v3 powered either directly by the LDO or by an port of the STM32. The later option I actually now use in normal operations, as this allows the system to really cut the BME280 from power so that it does not drain energy while the setup is in sleep mode \/ not actively measuring.<\/p>\n

As core I wanted to go with the stm32duino Core <\/a> as it already had the STM32WLE5CC supported. The only thing missing was the fact that I actually bought the TCXO enabled 3172T variant and this was not yet supported - and so I got my first PR<\/a> on the stm32duino repo.<\/p>\n

For the radio library I was thinking about chosing the RadioLib again and made a lot of research already on how to get it implemented, but at that time, RadioLib was working around their LoRaWAN implementation quite a lot - and shooting for a moving target was getting me nowhere, so I tried out STMs own implementation<\/a>.<\/p>\n

Update 2024-12-01<\/strong>
\nThe following two paragraphs detail workarounds for issues with STM32LoRaWAN v0.2.0 which have been resolved for good three days ago with release of v0.3.0 and are thus only interesting in the historical context of me setting up those sensors initially in ~June 2024.<\/strong><\/p>\n

(Fixed with PR #47):<\/strong>
\nThis did work out quite well, however, there is to this day a bug with the timers which prevents the chip from ever waking up again - a workaround for it is given in the issue<\/a> in case you want to try it too ( calling rtc.begin(true) after modem.begin() makes it work! ).<\/p>\n

(Fixed with PR #44 \/ #39):<\/strong>
\nI also had an additional issue, I left the RAK3172T sleep usually for 10 minutes, wake up, do a measurement and transmitting it back - then go to sleep again. This worked in my testing until 28 "wake-ups" - then on the next sleep, the chip would never wake up again. I am not sure what is causing this, but I went down the road of just counting the wake-ups and restarting the chip after the 24 or so, just to have a safe margin.<\/p>\n

Again, this was not a project I spend too much time with, I just wanted something to replace my breadboard wired mess of two CubeCell HTCC-AB01 - which absolutly did not stay unchanged in place since a short test back in 2021 and were working like this ever since (and suffering from disconnect whenever looked at from a wrong direction ;))<\/p>\n

\"\"<\/a><\/p>\n

So - yeah, if I were to have time I would probably look and test RadioLib support.<\/p>\n