Hat for Raspberry Pi to monitor environmental conditions (my sandbox for learning modern DevOps tools).

It’s 2024, and technologies from web development have made their way into the embedded world too-things like containerization, automated deployment, and more. This project is a small hat for the Raspberry Pi that gathers measurements for temperature, humidity, and air pressure. I created it as a learning tool to explore these concepts while using Docker, Ansible, and Grafana.

The picture below shows the hat. I thought it was so simple that I wouldn't make any mistakes during assembly, but, as usual, I did. The PCB turned out to be too long and collides with the USB port of the Raspberry Pi. That’s why I had to connect it using jumper wires. It works, but it doesn’t look very cool.

I didn’t choose these sensors for any particular reason—they were just parts I had on hand from the good pre-COVID times when software components and sensors were still cheap :)

View on GitHub View on Hackaday

The circuit is shown below. It consists of two sensors that communicate via I2C with the Raspberry Pi, along with a small LCD that also uses I2C. The LCD displays the measurement data as well.

Some people say that if your Raspberry Pi starts slowing down, it’s a sign that the SD card is about to fail, so it’s time to back up. I noticed mine was slowing down, checked the kernel logs, and everything looked fine, so I figured I was safe. The next day, the SD card was dead. So yeah, it’s definitely a good idea to back up in such cases.

This happened before I got into Docker and all the containerization stuff, so I was just developing scripts directly on the Raspberry Pi—and I think I lost them. It’s funny how I started this project to learn about containerization as a reliable way to deploy code, and I kicked things off with such a fail!

From the software point of view, the project will consist of three components:

• Python software for gathering data from the sensors
• InfluxDB for storing the measurements
• Grafana for data analysis and presentation

I think each of these components will have its own Docker container. In addition, I’ve already created a Docker container for cross-compilation (since my PC has x86 architecture and the Raspberry Pi uses ARM architecture). It was quite a struggle to get that working. I plan to automate the installation using Ansible.

If you’re interested in the details, the full project is available on GitHub and Hackaday. Feel free to explore, make your own modifications, and maybe even improve on what I’ve done. And if you find it useful, don’t forget to share it!

Read More

Hardware Data Logger based on STM32 Nucleo and ESP Module

It's been a while since I last posted here, but here I am with something new. This project started when I was cleaning up the repo for a semiconductor radioactivity detector. For that project, I made a small shield for the STM32 Nucleo that included a button and a display.

It was used to present measurements in real time on the display and send them to a Raspberry Pi for further processing. I thought this could be turned into a separate project and reused, and I'll be presenting the results of that in this post. Here is the link to the GitHub of this new project that I describe in this post.

I started working on a new version and came up with these specs:

• Keep the STM32 Nucleo as the main microcontroller
• Add an ESP module for remotely uploading data to a Raspberry Pi or any other device
• Use a much larger color display
• Include four buttons for interacting with the device
• Add 4 BNC connectors for gathering data from other devices
• Include an SD card slot for local data storage
• It also has a light sensor to dim the display at night.

The picture below shows the version that includes these specifications. Fun fact is that I traveled with this device in my carry-on luggage and was worried there might be issues at security, since it kind of looks like a movie bomb, but everything went fine.

Based on the that version, I created a dedicated PCB. I thought assembling the PCB would be pretty simple, but unfortunately, I forgot to buy all the components, which made it much harder than I expected. In this version, I used SMD female pins to connect to the Nucleo board. However, since I didn't have them on hand, I used THT pins instead. The footprint was different, and I didn’t solder them well, which put a lot of stress on the Nucleo board when connecting the shield.

View on GitHub View on Hackaday

It kept breaking repeatedly, and I didn’t expect such a small issue to cause so many problems. The LCD no longer works—probably something broke again—but the rest of the setup is functioning. In this version, the STM and ESP communicate with each other, but only in a limited way.

The device was designed in KiCad, and the circuit is shown below.

The firmware was developed using STM32CubeMX (for peripheral configuration), CMake, and C++17. I didn’t use anything from the standard library or dynamic memory allocation.

I’ve also included several tools for checking code quality: unit tests (Google Test, Google Mock), code coverage, static code analysis (cppcheck), and even dynamic code quality checks (which don’t make much sense in my case since I explicitly avoid using dynamic memory allocation, but I wasn’t thinking about that at the time). There are also Doxygen comments and coverage reports to flag any missing documentation.

I used ChatGPT (paid version) for most of this configuration. It’s amazing but can also help you quickly generate garbage. It speeds things up when you're headed in the right direction, but if you're doing something silly, it will just help you do it faster. You can check out how the CMake files are written in this project to get an idea of what I mean.

The current version is not finished, and I think I’ll abandon it in favor of a new version. I plan to drop the Nucleo board and place the STM chip directly on the PCB. This will solve the connector issues and make the device smaller and cheaper.

Another idea I have is to use some slots (similar to the ones used for connecting RAM to a PC motherboard, though I haven’t researched the names or footprints yet). This way, I could have one main PCB with the STM, ESP, display, etc., and use detachable boards for acquisition modules.

This is just the beginning, and there’s plenty of room for improvement. If you're curious to see where it goes, don't forget to watch or star the project on GitHub!

Read More