STM32 Radio Nodes Mini

STM32 Radio Nodes Mini are here and available for sale in my shop and on Tindie.com

I created this board to use it as base for various battery powered sensors I use at, and around my house. It is evolution of my Radio Mini Node based on ATmega328P, but instead of ATmega, it's using STM32F103 (basically well known BluePill). It suited for RFM69HCW(CW) or various LoRa RFM9X(RFM95/96) modules. It can have an u.UL connector for pigtail, or it has a solder pin for simple wire antenna. It comes with micro USB charging for 3.7V Li-ion cells with capacity ranging from 500mAh to 2000mAh. Quite good are 102050 (1000mAh) or 102550 (1500mAh) with JST-PH2.0 connector, that are almost matching the size of this board. It also includes battery voltage measurement connected to MCU analog pin. USB port can be used for programming, or as serial port. It has also standard ST-LINK SWD port. There are RESET and BOOT0 push buttons for convenience. Then there is also external RTC quartz crystal which allows indefinite sleeps instead of ATmegas maximum 8 seconds. It has LED on PC13. Also on top, there's a place to mount various temperature/humidity sensors like HTU21D. PCB comes with mounting holes to fit in various places.

Specification is as follows, it's STM32Duino BluePill compatible board with STM32F103C8:

• Size 24 x 49 mm (0.95 x 1.92 in)
• STM32F103C8 - FLASH 64KB, SRAM 20KB, Max. 72MHz @ 3V3.
• 8MHz main crystal, RTC 32.678kHz crystal.
• USB charging designed for 3.7 Li-Ion battery (500 - 2000mAh). Great thermal dissipation.
• Included, but not soldered, JST PH2.0 battery connector.
• Charging state (Hi-Z) available on pin PA8 via NO(Normally Open) PCB jumper.
• Voltage measurement on PB1 pin via 2:1 voltage divider, consuming 2,1uA @ 4.2V.
• LED on PC13, with NC(Normally Closed) PCB jumper.
• ST-LINK SWD 4-pin connector (3V3, SWDIO, SWCLK, GND).
• RESET and BOOT 0 push buttons. BOOT 1 (PB2) pulled-up by 100k resistor.
• SPI1 routed to RFM69/RFM9X modules. PA4(CS), PA5(SCK), PA6(MISO), PA7(MOSI)
• NO PCB jumper for Radio Reset routed to PB11.
• NC PCB jumper for Radio Interrupt(DIO0) routed to PA3
• PCB footprint for HTU2XD, SHT2X, SI70XX humidity/temperature sensor routed to I2C.
• Optional HTU21D humidity and temperature sensor.
• RFM69HCW 868Mhz as soldered on option.
• Optional u.FL antenna connector.
• Optional high quality 20cm u.FL to SMA pigtail.
• Optional rubber SMA 868/915MHz antenna.

The consumption of the board alone is around 60uA while MCU is in deep sleep, when clocked at default 72MHz. With soldered on RFM69HCW radio module and temperature/humidity HTU21D, the consumption raises to around 120uA while sleeping. This is about the same as a normal Li-Ion 1500mAh self-discharge current. It is enough to keep the node sending packet every 10 minutes for many months with a 1000mAh battery.

New Radio Mini Node

There was a little happening on development side of OHS lately. The gateway line 2.0.x
works very stable. No issues found in software or hardware. Arduino based nodes are also reliable. Basically it works as intended, "install and forget". 

But the word is changing and so are the evolution of chips. ATmegas, and also other components are becoming hard to get, and the prices of ATmega tripled. While using STM32 Cortex M4 chips for gateway, I realised they are great replacements, allowing us to do stuff not imaginable on AVR. For example STM32duino, I've been watching the progress of it for long time, and also, I have some blue/black pills on hand. So I decided to give them a try also on OHS environment. I've created a STM32 Radio Node Mini, which render is shown on picture. 

It is 50*24mm board with STM32F103C6T6 Cortex M3 running up to 72MHz with 64KB of flash and 20KB SRAM. Basically well known bluepill. It's meant to be used as radio node, so on back there is place to mount RFM69 or LoRa RFM95/96 module. It has a u.UL connector or place for wire antenna. Board has also 3.7V Li-ion battery charger, and battery measurement resistor divider connected to MCU ADC pin. It is programmable directly via USB port, or it has SWD. There is also RTC quartz crystal which allows indefinite sleeps instead of ATmegas maximum 8 seconds. It has LED on PC13, and also on top a place to mount various temperature/humidity sensors like HTU21D. PCB comes with mounting holes to fit in various places.

Currently I'm having those fabricated, and as soon as I have some of them tested and I'm ready with proper software, I will report more.

Gateway 2.0.4 pinout

Just short update, using nice tool called pinion with few hiccups,  I've created quite nice diagram for pin-out of OHS gateway 2.0.4.

https://vysocan.github.io/OHS_20x.html

It offers nice visuals with highlighting of pins and grouping by type. It has to be hosted out of blogger, as blogger does not allow embedding your own CSS, JS and pages easily.

Authentication added.

New firmware version 1.3.9 has been just released. It includes few minor improvements, and as main new feature an authentication, that was added to web interface.  How it works is pictured on right side. Every new client connection is asked for user and password that must match with internal values. Default user is: admin, and default password is: pass. Both then can be changed in Settings.

At first I was thinking to use obsolete HTTP basic authentication, to make it simple. But it is very obsolete, and also not supported by vanilla HTTPD from lwip contrib package. I was thinking how to add an authentication for a longer time. There are several methods to be used. First would be creating a single page application with authentication message encrypted in URL as parameters. Witch would require a bigger re-work on the HTML page generation. Now HTTPD has several pages, on which user can set tens of options for each section on a page. Quite a difficult task.  Second, to use a cookie to store some secret after user authenticate successfully on browser side, and request the browser to send this secret with each request. But lwip's HTTPD does not support cookies. 

Well I deiced for second option. I created a simple patch to HTTPD  to handle cookie generation and reception. First is done as part of dynamic header option for pages that are not statically liked, that is not generated via makefsdata program. Then, I added an additional callback, that is preceding request for every fs_open (file system open function). This allows an application to verify received cookie and then, if needed, rewrite the page( or file) requested to something else, for example login page.

I think it is nice and neat addition to lwip's HTTPD, so I will try to push it upstream, hoping it will get accepted.

New pre-compiled version is as always available GitHub, together with all sources. Enjoy!

P.S. Finally this is new version for my "production" home gateway. Resetting it after 163 days. Quite satisfied 💪

Forum migration

 Nabble forum was migrated to new server http://ohs.356.s1.nabble.com

Thanks to Nabble for support and keeping this small forum up and free. 

Summer vacation and 1.3.8 continuity test

Summer vacation is almost over, I hope for everyone it was spent in nice and restful manner. I personally, was traveling abroad and also much in my country to visit places I've wanted to see for longer time. After long stay-at-home period of covid 19, it was very welcome and pleasant.

But as always, there is the the other side of vacation, I did not do do much development for OHS. The last one which bothered me about lwip's MQTT was solved, and it took longer time. Also as I think about it now, the current firmware has all the major functionality I wanted initially. And it is in state that it simply works. Yes! Look at the picture, I have now running the last 83 days without interruption.

So what will come next? I have few ideas:

• There is a big task ahead to integrate SSL/TLS layer.
  
• Based on above create "push" notification as new alert delivery path.
• Add authentication to web interface.
  
• Create examples for OHS integrated scripting language (modified TCL).
• ...

If you have some other idea let me know.

 

Solving lwip troubles.

Some time after the introduction of lwip core locking into ChibiOS port, I started to notice that MQTT still tends to disconnect and connect right after. Same problem as before core locking. This is not very good that all other lwip process seems to work well, but MQTT is keep on reconnecting. Well lwip is a big and complex library to jump in and decode all possible problems, and I decided to start with MQTT client part only. There are quite a few debugging facilities in lwip and I turned on many to start seeing the whole picture.

Nice informative way to see information about lwip is to enable LWIP_STATS. There are many options what to see, like to examine possible memory problems by defining:
#define LWIP_STATS_DISPLAY 1
#define MEMP_STATS 1
#define PBUF_STATS 1
#define SYS_STATS 1

And adding:

#ifdef LWIP_STATS
  stats_display(); // Show lwip statistics
#endif

into while (true) lwip thread.

I started to torture again OHS application fir frequent radio packets resulting into MQTT publish messages. All was fine even with heavy usage of web interface and MQTT subscribe. But after 5 days the statistics started to show an error on MEMP TCP PCB and the in used number of same did not cease even after no other TCP communication then MQTT was used. I increased the number of MEMP_NUM_TCP_PCB to 50 and started again. 5 days later the same problem.

Examining MQTT library or searching forums did not help much. In logs I found that the client receives an empty pbuf which is forcing the client to disconnect. Mosquitto broker then does not see the keep alive periodic packet and also closes the connection. But I started to measure the exact time when the MQTT get out of pbufs, and it a bit surprised me that it happens exactly after 4.9 days. To be precise after 2^32 / 10000 = 429496,7296 seconds. There are timers in lwip that make various time dependent tasks, like removing used pbufs or dhcp. Deep diving into it I found out that the problem is not in lwip, but in ChibiOS port. The sys_now() function does not overflow on u32_t boundary but actually much earlier, causing the timers wait forever.

A patch of the sys_now() function seems to fix the problem completely. It comes with new OHS version 1.3.8 with a few cosmetics enhancements described in particular commits on GitHub. 

It is recommended to upgrade if you use MQTT.