Close
0%
0%

Data Logger Shield

Shield for NUCLEO-F103RB that logs pulse data from up to four devices. Includes WiFi, microSD storage, LCD with buttons, and USB UART.

Public Chat
Similar projects worth following
Features:
* Pulse counting from up to four devices via SMA connectors (3.3V to 16V logic levels).
* Data acquisition through UART using a DB9 connector.
*User interface with a 128x160 RGB LCD and four navigation buttons (up/down/left/right) for GUI control, with automatic dimming in low light.
* UART over USB for data transfer.
* microSD card for permanent data storage.
* WiFi for remote data transfer.

GitHub: https://github.com/RobertGawron/HardwareDataLogger/tree/feature/rev_3_0

Hardware

Due to the availability of low-cost, high-quality PCB manufacturing, home-etched PCBs have become largely obsolete. While the PCB design for this project may be difficult to etch at home, it is still possible. Subparts of the circuit can be assembled on a breadboard, making the process much easier, and the modular software design allows for easy reuse of these components.

Software

NUCLEO-F103RB Board

The NUCLEO-F103RB serves as the main microcontroller, handling data acquisition, processing, storage, and user interaction. In future iterations, the NUCLEO-F103RB will be replaced by an STM32 chip directly integrated onto the PCB.

  • Toolchain: C++17, C, STM32 VS Code Extension, CMake.
  • More info.

ESP8266

The ESP8266 is currently used for data transfer via WiFi and will support FOTA (Firmware Over-The-Air) in the future.

  • Toolchain: TBD, currently using Arduino IDE.
  • More info.

DevOps

It's good to let the machine handle the tedious work of checking code quality, freeing up more time for the useful and interesting parts of software development.

  • Toolchain: Unit tests (Google Test, Google Mock), code coverage (LCOV), static code analysis (Cppcheck), dynamic code analysis (Valgrind), Docker (for both local development and CI), GitHub Actions (CI).

Simulation

Embedded development is cool, but constantly flashing the target device for non-hardware-related logic, like the human-machine interface, can be time-consuming and frustrating. To streamline this, a simulation was developed that isolates the firmware not directly tied to hardware, adds stubs for drivers, and includes a GUI. This allows all high-level aspects, such as what’s displayed on the LCD, user interaction via buttons, and data parsing, to be tested without the need for hardware.

While this simulation handles the firmware, speed of execution isn't a concern since it focuses solely on high-level logic. For hardware or driver-related issues, traditional methods like using an oscilloscope or logic analyzer are still necessary, as the simulation cannot be used.

Below is a screenshot from the simulation. Note that this is from an earlier version when the device was designed to work exclusively with a Geiger counter. The current simulation doesn't work.

Documentation

UML diagrams will be added later using PlantUML.

  • Next HW revision idea

    Robert Gawron5 days ago 0 comments

    I have been thinking about what I would like to achieve in the next HW version (other than finally getting everything to work), and I came up with two ideas:

    - Make the device as small, cheap, and power-efficient as possible.

    - Make the device modular, meaning that in the future, I could keep parts like the LCD or SD card but simply swap out the PCB responsible for data acquisition.

    I plan to use it indoors, and PCB manufacturing costs next to nothing nowadays, so I will go with the second option.

    I want to create a "mainboard" that will have a 3.3V power supply from USB and several slots to connect cards. One card could be a power supply, another could be for pulse counter acquisition, etc.

    I was considering using PCI as the slot type, but it's a hassle dealing with the footprints. Instead, I’ll use two side connectors, similar to what the Raspberry Pi uses.

    I'm adding picture of a mainboard PCB because it's always better to have post with pictures lol.

  • Diving into CMake and Docker (and a few other tools)

    Robert Gawron7 days ago 0 comments

    Last week, I was working on cleaning up the CMake files and setting up Docker. It was quite difficult because I don't know either of them well, but in the end, it works pretty well.

    Personally, I really like the idea of Docker because, in a file, you can configure your environment and - here’s where the magic is - this file is treated as configuration/code. Meaning, it’s parsed and checked by a machine. It’s not a README that’s never up to date, but something that gets “compiled,” and you get errors if something is wrong. Some DevOps guys would probably laugh at this description, but it’s true :)

    I’ve also experimented a bit with hpp2plantuml, a tool to generate UML class diagrams based on existing code. I wasn’t happy with the results as it omitted a lot of connections that exist in the code, but the setup is easy, and what it generates is accurate (it’s just not complete). I even have a build for that!

    Another tool I checked out is include-what-you-use. Setting it up isn’t trivial, at least on Linux, as it needs to be downloaded and compiled manually - the old-school way. It also requires, AFAIK, Clang as a compiler, meaning you need to have a build version using Clang. I haven’t yet paid much attention to what it generated, so I can’t say if it’s useful for embedded projects. BTW, it was developed at Google.

    I also removed the build for Valgrind because I intentionally don't use either the standard library or dynamic allocation, so it was kind of silly to include that tool.

  • HW rev3.0 (but the project is still unfinished)

    Robert Gawron09/14/2024 at 13:00 0 comments

    I have made a new version and it was working (well, not all of it was/is working but major parts yes). This is also the first time the project has its PCB so it looks much better than previous version.

    What you see is NUCLEO board (white PCB at the bottom), my PCB (red one) and the LCD with its own blue PCB (LCD comes with this  blue PCB but I think that maybe I will desolder it and solder it directly into my board, I don't know).

    The NUCLEO and the logger PCB are connected via SMD pin headers that.. I forgot to buy. I've used standard troug-hole pin headers, but I didn't solder them quite well (it's a different footprint) and that make a lot of problems with missing connections. I've sped three hours at least on that.

    ESP8266 and STM32 talsk to each other via UART, that's make me happy, that was my main goal for this version. I can dim the LCD, although the algorithm is rather primitive. Buttons works too. I will add debouncing in the software later.

    The LCD doesn't work now, probably because some pins did unconnected again, but it was working so I know that HW design is good. Same with SD card.

    I won't have access to my tools, so I made a small PCB with an SD card and a connector for the LCD display to overcome the current problems with the PCB. It's based on the existing Arduino shield, fun fact it's red too. 

    I tried to use a lot of modern features in the code (which doesn’t compile, by the way). I have unit tests (Google Test, Google Mock), static analysis (Cppcheck), and dynamic analysis (Valgrind, though it doesn’t really make sense for this project, but the diagrams look cool). I’ve got test coverage, and I’ve also added docs and docs coverage. The downside is that CMake (yes, I’m using CMake now too!) looks like garbage. I’ll have to take a look at that.

    I’ve switched to Visual Studio Code. It’s 2024, no more Eclipse-based garbage.

    What do I plan?

    I want to get rid of the NUCLEO board and use the STM32 chip directly on my board. This will solve the connector issues and make the device smaller and cheaper.

    My second goal is to use Grafana for result visualization. It’s an awesome open-source tool for displaying measurements, with a web API, and it can run on a Raspberry Pi.

  • Draft of support for ESP32

    Robert Gawron09/03/2021 at 12:57 0 comments

    This is the latest hardware version (rev 2.0). The ESP module has been added, and it has been successfully flashed. Several hardware changes have also been made to the PCB design.

  • SD card support

    Robert Gawron08/30/2021 at 20:49 0 comments

    SD card works OK, here are interesting things that I've learned:

    • There are two protocols to communicate with SD card - SPI (slower, but easier) and SD bus, some cards will not work with SPI
    • The SD card can draw up to 100mA when writing data!
    • As usual, it's good to add small resistors in series to all pins that are accessible from external, user can insert or remove card, so all data ports can be considered to be accessible from external. This is to prevent ESD damages. For SD card those resistors are in range 40-50R.
    • It's good to add pull-up resistors to all data lines, otherwise some cards will not work. There are chips on the market with pull-ups and in-series resistors.

    Info from: [1], [2]

    The prototype is now a bit bigger than before, because I've decided to cannibalize data logger board for Arduino - back when a shipment from China was for free (in Europe) I'v bought a couple of them - just in case. I don't really need therm since I don't do a lot of Arduino, and this saves me on buying SD card slot and RTC clock. I will add an RTC clock to the design. 

    The SD slot was a bit problematic, finally I've de-soldered it to see bottom side and how the card is really connected. It's weird for me because they didn't ignore pin #9, it's accessible even when AFAIK it's unused. So the pinout is like this 9, 1, 2, ..., 8, extra pins for check write protection. 

    In the next step I plan to setup ESP32, it will involve probably soldering new breadboard to the prototype :)

  • Reduce amount of elements on PCB, but keep functionality

    Robert Gawron08/27/2021 at 16:39 0 comments

    I've got a small success in  reduction of  amount of components on the PCB, I tested it on the breadboard -presented before- and i works fine.

    First, I tried to remove the pull-up resistors for switch buttons, below is the original diagram. BTW note that on this schematic there is no low pass RC filter, the filter is used for key de-bouncing, it's used in many open hardware projects, but this can be done in software too.

    Below is actualized version.

    This is possible because STM32 has possibility to configure GPIO as having internal pull-up resistor (it can be an internal pull-down too), so this resistor is still on the schematic, but now I'm using the one build-in into the microcontroller.

    Below you can see it on CubeMx.

    Note: I still didn't decide to which GPIO connects the key-left and key-right, so those are not configured.

    Another IMHO cool optimization is in setting the brightness of the LCD, originally I've planed to use discrete solution that would be driven by PWM.  The ST7735S LCD module has a separate pin for LCD brightness, I was thinking that the actual current for backlighting is needed to be provided to this pin. This is not true, it's just a logic signal, that goes to the SOT-23 chip on ST7735S. 

    The previous version is presented below.

    All the bottom part might be removed, because very little current is in real taken from GPIO port and there is no need for buffering transistors Q3, Q4. The buffering is done by small chip on the LCD module. Below is the current version.

    I've also been able to communicate with the LCD.  Fun fact is that initially I used this lib for ST7735S, but I didn't notice that it's for 80x160 displays. Mine is 128x60. Fortunately, I've found this lib for ST7735 - this one handles my LCD well. From the other side, invocations of HAL functions are a bit hardcoded with business logic, so in order to bring my PC variant for simulation of the device to live, I will have to do a bit of refactoring. 

    My next steps will be checking circuit for SD card.

  • Bread-board circuit for testing LCD and keyboard

    Robert Gawron08/25/2021 at 14:51 0 comments

    I've created a draft of the device using bread-board to check if I correctly connected LCD to stm32 nucleo and to have something to do driver development before ordering PCB. In addition I've added to the board up/down/left/right keys.

    Connections changes to original schematic:

    LCD connection:

    • RST - PC7
    • DC - PA8
    • CS - PB2

    Keys:

    • up - PC3
    • down - PC2
    • left - PC14 (TODO: move it somewhere else)
    • down PC15 (TODO: move it somewhere else)

    I've also tried to solder the part responsible for dimming the LCD but having only MOSFETs in SOT-23 package, it seems to much to work.

View all 7 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates