ThomasThis HaD project begins with my latest STM8 eForth log.
Richard's nRF24L01 library for STM8 eForth was a very good starting point for experimenting with the most prolific of all transceiver devices (in the meantime I learned that genuine nRF24L01+ chips are rare, and the best one can hope for is the "quite OK" SI24R1. For simplicity I'll refer to it as nRF24L01, and I also try to get a set of radio modules with genuine chips to test compatibility.
The cool thing about using STM8 eForth is that it's far more than a programming language on a nimble µC: it's also an operating system and a programming environment. I'd like to explore how to install features, "software apps", over the air.
For obvious reasons, a wireless sensor should consume very little energy, and selecting a µC with an RTC and very low energy needs in halt state is an important requirement. I'll start with cheap CR2032 coin cells, but other power supplies will be considered (e.g. a "solar garden light" style power supply with a single NiMH cell). I designed a STM8L051F3P6 breakout board that will be the foundation for my first experiments. As a PCB design tool I use KiCad 5.0.0.rc2, and the first set of PCBs I ordered it from @oshpark.
While I wait for the PCBs to arrive, I'll be working with an STM8L051F3P6 breakout I made some time ago, and I'll try to design a first sensor PCB with a humidity/temperature sensor.
@Wassim uses a BME280 chip in his Home Smart Mesh project. The page Humitidy Sensor Shootout offers a great overview, and the Bosch chip appears to be one of the best. It also offers a barometric pressure sensor, let's see what can do be done with it.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Hi Wassim, participating in "lessons learned" is always good :-) @richard and I are currently in "learning mode", and using ultra-cheap stuff is half the fun. It's quite likely that we'll be ending up using more modern devices, like you did, but right now the nRF24L01 clones do what they're supposed to do: bridge about 10m reliably.
I'm also thinking of using something more powerful for accessing something "cloud based". Two years ago I experimented with ESP8266, MQTT and Node-RED on the GCP with Docker, only to go in a completely different direction: Least-Cost REPL devices. It's been fun :-)
As for power consumption: I'd like to explore "extra low power Forth". Maybe it will work, maybe not. It will be beyond the well-trodden path, and it's already been serendipitous :-)
Are you sure? yes | no
Hi @Thomas,
The STM8L indeed was the trigger of my mesh project, and is as of Today "in production" for almost two years, still the only low power sensor logging x5 locations from the Flat. Since a year now, I moved the RF repeaters and the Raspi dongle to STM32 (Though the STM8 version was working quite well), and started messing up again with low power with nRF51 beacons, then jumped again on a low power design with an nRF52 using the exact same sensor modules BME280 and MAX44009. The git push from just yesterday shows the low power measures https://github.com/nRFMesh/nRF52_Mesh that reached for the moment ~ 20 uA but I think there's potential for better. With the STM8L, I could only achieve ~ 100 uA so the CR2032 hold around ~2 to 3 months. That does not exclude that you might achieve better with it.
For the STM8L, using the BME280, please note that I did not dare implement the calibration with 64 bit variables :) into the 8 bit uC, my trick is that I first download the calibration params for a specific node ID, then the uC simply sends the raw data from the sensor over the air (8 bytes from registers), once on the raspberry pi, there the id matching happen and the calibration to convert to the right temperature happen, which make it not usable in the mesh device to device, that is the main reason that pushed me to the nRF52 replacement.
Regarding nRF24L01+ modules, please don't waist your time, I did burn quite some time and investment before realizing the issue of bad transceivers. Now I do have a test (have a look on my IoT_Frameworks github in the STM32 project rf_bridge). I send a python command from cli (hci_client) "test_channel(target=24,channel=10,nb_ping=100)"
and that allows to compare modules. For example, you place one module that you trust at the distance where the signal drops from 100 to 99, and then test the DUT on that location. The bad ones would have only 20 ~ 30 and the awful 0 or 1, with that you can save yourself the time of soldering them before realizing that they don't work. Even the PA + LNA perform worst due to non shielding, only the PA+LNA shielded modules are good.
For the simple nRF24L01+, I do order now from Amazon instead of Ali, it has to be more expensive, there I could send it back with bad reviews in case they're not good, but actually that's where I got the best transceivers from.
Are you sure? yes | no