I was planning recently to build the new version of this device that would mainly fix the problem with the power supply - originally, I used batteries for powering the circuit and for the polarization of the chamber. This was due to the fact that the device uses hundreds of GOhms resistors in the feedback loop and is super sensitive to power supply noise.

While the approach was good and the prototype was built and tested, for real-life use this is far from a good solution. Opamps will draw current from the batteries, so over time their voltage will decrease, and it will impact the amplitude of the output signal. On the other side, the good thing is that the polarization of the ionization chamber takes very little power - those batteries will last.

The idea was that the amplifier would be powered with a cheap wall-mounted power adapter, and to limit noise, an extra power stabilizer would be added between them (with a bunch of LC filters). The polarization of the chamber via batteries would stay as it is.

But then there was another problem - the ionization chamber needs a dual power supply. Or does it? To be honest, I didn’t pay attention - this is something I need to rethink.

But let’s say that it needs a dual power supply. I added the TPS60403DBV (DC/DC capacitor-based converter) for a negative voltage.

Now came the issue. I had used the L78L33 - an IC that is rather poor regarding noise parameters. I had already struggled with a similar noise-sensitive project where I had used the NCP1117, and finally... I decided not to mount the whole device, because due to poor power supply decisions, it was doomed to fail.

In the next revision, I will use the TPS7A4700 because its noise performance is awesome and... I already have it, so I don’t have to pay to buy it. Good old times when TI used to send free samples.

But that’s not the end!

I still soldered the digital part (STM8 microcontroller, ADC, UART, and debugger sockets) and flashed the firmware on it. This way, at least I have a small PCB (much smaller than the previous one) where I can test the firmware.

To the ADC, instead of the signal from the amplifier, I connected a potentiometer (the other two pins of the potentiometer connected to Vcc and GND). This way, I can check the voltage between Vin+ and Vin- and verify if it is correctly calculated by the firmware and correctly gathered by the PC app.

Fun fact: it wasn’t - and I ended up rewriting the whole firmware. There were a lot of things I didn’t originally understand from the ADC datasheet. And neither did I notice them, despite having access to an oscilloscope with I2C decoding. Well, I’m as lazy as any other embedded developer.

But now life has changed - I bought a cheap Chinese clone of a logic analyzer and connected it to the Sigrok tool. I find it more convenient. What’s even cooler is how easy it is to decode and copy the transmission, and then... you guessed it: ask AI what I did wrong. It’s absolutely amazing how much this speeds up troubleshooting.

I also used some DevOps tools to facilitate work and find bugs:

• Docker (I love it!)
• Linters: CodeChecker for C (Clang and GCC tools), Prospector (for Python), and lintr (for R)
• Unit tests for firmware in CMocka (I didn’t use GoogleTest because it's oriented toward C++, and the firmware is written in C), and in pytest (for the PC application)
• Code formatter: Uncrustify for C, Black for Python, and Styler for R

All of it is on the GitHub page, so you can take a look. It's all made with CMake (with some shell scripts, etc., because not everything is possible in CMake). It’s really cool and it works - you can check it out and maybe reuse something in your project.

To summarize, the good thing is that the hardware issues were identified before wasting time on full assembly, some parts of the design were still assembled and tested and will be used later, and the firmware is in a much better state than before.

And the bad thing is that I still don’t have a new working hardware version.