spezifisches

PSV3 Soldering Iron Hack - Part 2

2023-08-03T00:00:00Z

This is the sequel to PSV3 Soldering Iron Hack - Part 1 where I already introduced the result of this whole project: a quite usable replacement firmware. Now let's see how we got there (so I guess it's rather a prequel).

I already showed my annotated board layout:

Traced and annotated PCB layout, top layer (as always, click to enlarge).

It was really helpful to create this image to get a first level of understanding about what's going on in this soldering iron. I made photos of the top and the bottom of the PCB,^[1] added them as semi-transparent image layers in GIMP and traced the signals and parts in additional layers by hand/mouse.

Based on that image I created a reverse engineered schematic (PDF) in KiCad, which has also been a handy reference while developing the new firmware. For purposes of documentation though in this post I believe a kind of top-down block diagram is a better starting point.

Soldering Tip

Let's start with a view of the parts around the soldering tip:

A closer view at the business end.

On the left you can see two contacts for the T12 soldering tip and connecting to those, the 20 V high-side heater driver MOSFET, and the operational amplifier for the tip's thermocouple temperature measurement.

My choice of T12-compatible soldering tips: T12-K (knife shape), T12-BC2 (beveled shape), T12-D24 (chisel shape)

Hakko T12 compatible soldering tips are used by many cheap soldering irons and soldering stations (and by a few good ones). It's an active soldering tip so the heat is generated close to the tip leading to fast heat up times. Temperature measurement is also already integrated using a thermocouple. Both are connected in series between two pins (here marked -/+ while E is for Earth and not connected in this low voltage soldering iron):

Inside a T12 soldering tip. Credit: Marius Taciuc

Heating

To heat the soldering tip we just apply our supply voltage to the pins (-/+ in the image above, TIP_A/B in the schematic below). This happens to always be 20 V in our case.

Soldering tip heating circuit

On the left we have a pin of the microcontroller (signal TIPHEAT_DRV) controlling a simple driver stage with a small N-MOSFET (Q2 here, its marking is 72K) which controls a P-MOSFET (Q1 here) that switches 20 V (VBUS) going to the tip on or off.^[2]

During the heating phase we can model the soldering tip as a simple resistor. With a multimeter I measured its resistance to be ~8 Ohm (on my T12-B2 tip). So we can expect a theoretical maximum output of 50 W given the fixed supply voltage.

To regulate the heating element to get a stable temperature level we're switching the tip power with PWM to achieve a finer grained average output power. The desired output power is calculated by a PID controller (adapted from IronOS) that runs at 10 Hz which coincidentally is the same as the PWM frequency we're using.^[3]

Temperature measurement

Inside the tip there's a thermocouple connected in series with the heating element and thanks to the Seebeck effect, we can measure a voltage between the - and + pins which is related to the tip's temperature. But this works only when the heating element is turned off — otherwise you would just measure the 20 V that the power MOSFET connects to those pins.

Therefore we need to turn the heat off regularly for a fixed minimal amount of time; we need to wait for the temperature to stabilize a bit before taking ADC voltage samples. IronOS implements a bit more finesse at this point by filtering the measurements but it seems to work well enough to just increase the ADC sample time by a bit (like the stock firmware does, too).

Thermocouple amplifier, from tip (left, TIP_A) to ADC input (right, TIPTEMP_MEAS).

With only e.g. ~11.3 mV at 450 °C the voltage of the thermocouple in our operating range is too small to measure directly with the ADC of our microcontroller. That's why we have a non-inverting amplifier op amp circuit to boost this voltage (e.g. to ~2.5 V at 450 °C).

Temperature conversion

Funnily enough there is a bit of a disagreement whether the type of the thermocouple in T12 tips is Type K, C, N, or whatever. I can't say which one is correct but either way it is going to be a linear temperature relationship between voltage and temperature in our operating range. So I made a round of rough measurements to get some input data for the PID controller.

Still from calibration video

I used the temperature mode of a Voltcraft VC-523 multimeter, held it to the soldering tip, printed the raw ADC values in big numbers on the OLED display and filmed a video showing both the multimeter's and the iron's displays. Then I noted a bunch of temperature/ADC value pairs and did a linear regression in GNU Octave (soldering_tip_linear_reg.m, raw data), which leads to the following graph with values converted to microvolts:

Quick and dirty first calibration run (blue: measurements, red: regression curve)

To implement my conversion function in the firmware I skipped the intermediate step and used ADC values directly to get the temperature in degrees Celsius with: T/°C = 0.2037 * x/(ADC units) - 73.8

This worked for a start and using this I was able to get pretty consistent temperature control, i.e. I set the soldering iron to hold 320 °C and the multimeter agreed within a few degrees with that.

But there are a few problems to consider with my calibration:

Specialized devices to calibrate soldering iron temperatures exist (e.g. search on Aliexpress for "soldering iron calibration") — I don't know how using my multimeter's thermocouple compares to those.
It matters where on the tip you measure. I tried to hold the sensor in a consistent position on the side of the tip where the solder would be but results in a different place will not be the same. (Maybe putting it in oil would be better?)
I didn't consider cold junction compensation. So I probably have at least a fixed offset in my temperature control depending on the room temperature, thus I should probably subtract room temperature from the values. But then again this soldering iron doesn't have a separate sensor to measure ambient (or handle) temperature. Maybe this could be a setting in the GUI, though.

Finally, comparing these results with IronOS' temperature curve of a T12-style tip they're pretty similar in the range I care about most (i.e. above 300 °C) except for a static offset, which may be due to my missing cold junction compensation or due to measuring errors on my side. On the low end (below 200 °C) there are bigger disagreements. In any case I would trust their measurements more than mine, so I'm going with their interpolation table instead of my regression function for now.

USB supply control

On the right half of the board the CH224K Low-cost USB-PD Sink Controller (datasheet) runs the show and configures the USB power supply over the USB-C pins DM/DP/CC1/CC2. USB Bus Voltage VBUS then powers the soldering tip and it's also the input voltage for an XL1509 3.3 V buck regulator (datasheet) that powers everything else on the board.

Hardware blocks around the USB connector.

USB-PD controller

The CH224K gives two options to configure the voltage it requests from the USB power supply: A resistor connected to pin CFG1 or high/low logic levels setting pins CFG1/2/3, which would be quite interesting if they were connected to a microcontroller.

CH224K voltage configuration options (source: datasheet)

Sadly, on this board the CFGx pins are not connected to anything, so 20 V is always chosen for VUSB. I'm thinking about connecting a 56 kΩ resistor to CFG1 though to select 15 V and give the P-MOSFET a longer life.

Microcontroller

The microcontroller is an STM32 clone named CHIPSEA 32F030P6F6. It seems to behave pretty well and I didn't have any problems with the ADC or otherwise.

Schematic around the microcontroller

This design has some annoying quirks though:

The OLED I2C display isn't connected to the also available hardware I2C pins but to random I/O pins, so we have to use bit-banging to control the display.
The tip heat driver (TIPHEAT_DRV in my schematic) is connected to PA3 which doesn't have PWM — the only timer channel on this F030 line is TIM15_CH2 and this particular footprint doesn't have Timer 15.
There is no way to reset the "STM32", e.g. for SWD debugging and also no UART/etc. output, so we need to test by pin wiggling until the display works

OLED display

To find out how to talk with the OLED display I hooked up a logic analyzer to its I2C bus. As we can quickly see from all the I2C writes to address 0x3c it probably uses a SSD1306-compatible protocol, so in the best case we only need to replicate the used initialization sequence and can then use the u8g2 display library to render our display content and do the rest of the communication.

The bottom side of the PCB pretty much only contains this display (and the 3 buttons).

Bad code

I had already found the display initialization code in the dumped stock firmware (of course I could have also used the logic analyzer to dump it, but I didn't trust it due to the weird NACK behavior mentioned below):

In the stock firmware: First part of the OLED initialization

Funnily enough the stock firmware sends each of the bytes during the initialization in a separate I2C transmission (including start + stop condition, address byte, register byte) which takes needlessly long. You can just send the whole sequence in one transmission instead (and u8g2 does this btw.).

Another weird behaviour is that, going by the logic analyzer traces, the display doesn't seem to send ACKs — after every byte the bus master (i.e. the microcontroller) should let go of the SDA line and the slave should pull it low to indicate acknowledgement of that byte.

Logic analyzer trace of I2C traffic with stock firmware: NACKs everywhere! (Red 'N' markers in the bottom row.)

It turns out that the reason why the OLED display doesn't seem to send ACKs is because it can't — the stock firmware leaves the I2C SDA and SDL pins in push-pull mode the whole time. This means the high state on SDA is actively driven high by the microcontroller. When the OLED display tries to drive it low during the ACK/NACK period, we get some in-between voltage on the SDA line that can be seen with an oscilloscope (which my logic analyzer decoded as high).^[4]

Also, as you can see in the initialization code above, they toggle PA9 before starting the display initialization sequence. While this pin is probably meant to be hooked up to the display reset line, it isn't connected to anything on this board.

Better code

After some searching in the excellent u8g2 sources (and a lot of trial & error) I found the ssd1306 128x32 univision initialization which is pretty much the same as the one used on our soldering iron (plus display inversion/rotation settings which are done elsewhere in the stock firmware).

The bit-banging driver was quite slow though on an STM32. One reason is that it uses Arduino I/O functions like digitalWrite() which seem to be very slow in stm32duino (there are some pin and port lookups which probably take a few cycles each time). Once I switched to using the low-level I/O functions though I was able to get from ~26 kHz to ~89 kHz I2C clock speed.

With some further optimizations I finally got around 170 kHz. All together the whole display content is now rendered and transmitted in around 49 ms, which is well within the 100 ms PID controller and measurement period, so they don't interfere too much with each other (and due to the way I2C works, it shouldn't matter anyway if a clock cycle here or there is a bit longer).

Stock Firmware

I already showed in the previous post how to dump the stock firmware using an STLink USB stick.^[5] For analysis in Ghidra I found ghidra-stm32f0 quite useful — it's a loader that sets up memory regions and register names so you don't see reads and writes with addresses like 0x04001000 everywhere. (Be aware though that it labels many interrupt vector table entries that don't exist on our low-spec STM32F0 and are actually already code. Also it's missing a lot of timer and ADC peripherals that we're using but it's better than nothing.)

Stock firmware main function: hardware setup, welcome screen, main screen

Initially I wanted to know how they're implementing their temperature controller but it wasn't that interesting anymore after the ported code from IronOS worked so well. There are always bits and pieces of display code or peripheral setup in between so the decompiled code is actually quite a slog to get through.

Custom Firmware

For my custom firmware I started with a custom PlatformIO board that I derived from an existing one using another MCU of the F030 line. A board with this specific STM32F030F6P6 with 32 kB Flash and 4 kB RAM didn't exist so I had to create one. Peripheral initialization was a bit tricky because contrary to my expectations, stm32duino doesn't handle most of the clock setup of GPIOs/etc., so I ended up using STM32Cube to generate setup code for the system clocks and also the ADC and GPIO setup for me.

The core of my custom firmware is pretty simple: UI stuff (buttons + display) happens in the Arduino loop() function every 100 ms:

Main loop routine

And soldering tip control is interrupt-driven by Timer 3 (TIM3), which resets every 100 ms (that interrupt turns the heat on) and is using 3 compare interrupts (1. heat off, 2. temperature measurement, 3. PID calculation):

TIM3 Interrupt Timing: Heating PWM, temperature measurement, PID update

The time at which the heat turns off is given by the desired duty cycle that the PID routine calculates. As discussed before, after turning off the heat we wait a fixed time for the temperature reading to stabilize (currently 10 ms, but this could be made shorter), and then take the ADC temperature reading.

In the current state the GUI is pretty simple. It only consists of one screen, you can press SET to turn the soldering iron on or off, then it goes to stand-by after 60 s. And you can set the target temperature using the + and - buttons from 150 to 450 °C.

Custom firmware on full power on the reassembled soldering iron, SWD wires peeking out.

Of course, as already noted, I was able to take the PID controller code from IronOS with a few little changes and it gives really good results without even tweaking the parameters (using the ones from the Pinecil V2).

Results and further improvements

I'm reasonably happy with the firmware at this point. It takes around 15 seconds to get from room temperature to 320 °C (and this, according to my limited measurement capabilities, really is 320 °C), while the stock firmware was way off with its temperature control, giving only around 280 °C when 320 °C are set. Temperature control during soldering is also rock solid.

Additionally, it might be a good idea to connect the USB-PD controller to a resistor to select a USB voltage of 15 V in order to improve the life-time of the P-MOSFET which is currently operating at its limit V_GSmax of 20 V. But this would come at the cost of longer heat-up times. Alternatively, you could replace that MOSFET with one of the few that withstand a V_GS of 25 or even 30 V.

Furthermore, cold junction compensation is currently being ignored and we can't probably do much without modifying the hardware. But we should at least be able to configure a fixed temperature calibration offset in the GUI like in IronOS.

Finally, it would be nice to get a soldering iron temperature calibration tool to make a more trustworthy calibration curve.

Footnotes

The bottom side of the PCB isn't very interesting so I'm skipping it here. You can look at it here. It pretty much only contains 3 buttons, the OLED display (we don't need to know more than that it's connected by I2C), and a small N-MOSFET driving the bigger P-MOSFET that switches the heat. ↩︎
The N-FET is needed because the microcontroller can't switch the gate of Q1 directly. ↩︎
IronOS implements another trick to get faster heat up times, but we don't (yet): They're using a lower 5 Hz PID rate and PWM frequency during the initial heating phase to get higher power output by allowing for a higher PWM duty cycle. The duty cycle can be higher because overhead of the time needed for temperature measurement to settle is constant (see next section). The trade-off for this higher output power is less accurate temperature control. ↩︎
The proper way to do handle this would be for the microcontroller to either configure the pin as open-drain (instead of push-pull) or to switch the pin from output to input. The latter one is also useful if you actually want to know what the slave responded. ↩︎
I haven't yet decided whether I want to publish that dump but if you're interested in (probably also shoddy?) soldering station firmware dumps, you can find some at https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/Original_FW. ↩︎

PSV3 Soldering Iron Hack - Part 1

2023-07-26T00:00:00Z

Intro

There are some good and inexpensive soldering irons available nowadays. Thanks to USB power supplies with Quick Charge 2.0/3.0 or Power Delivery support you basically only need a microcontroller for temperature control, a FET switching the heating element, a way to measure the soldering tip's temperature and a way to communicate with the USB supply.

The one I call 'Pen Solder V3' (top, cable attached for flashing) and a Miniware TS80P for comparison

The cheapest ones^[1] with a reasonable shipping time to Germany can be had for around 20€ (incl. taxes) on Aliexpress. Inspired by a Hackaday post about an iron containing "an STC8H3K62S2, [and] an 8051-based MCU running at a blistering 11 MHz" I sought to buy a similar looking device that was advertised like this:

Article title: Portable T12 Electric Soldering Iron PD 65W DC 72W CNC Metal Body Temperature Adjustable Solder Welding Station Fast Heating

Thanks to a sale coupon the total price including free shipping came down to 18.46€. Never mind that the article's description is a bit weird considering the two different shown wattages neither of which are achievable with the supplied soldering tip (T12-B2) — it's an 8 Ohm tip so with 20V supply its maximum is actually 50W. Also I think by DC 72W they might mean when supplied through a DC barrel jack with more than 20V which other models have but this one doesn't.

Main screen (and only screen) of the custom firmware

TLDR: The hardware turned out to be different than expected from the Hackaday post (no 8051 but an STM32 clone) but after a bit of reverse engineering the PCB layout and parts of the original firmware I came up with a well working replacement firmware which performs quite similar to my Miniware TS80P with IronOS soldering-wise — The "secret" is that thanks to the power of Open Source I could adapt some of IronOS' temperature measurement and controller code with settings from the Pinecil which uses similar TS100 soldering tips.

My replacement firmware is available at: https://github.com/spezifisch/T12PenSolder (GPLv3 license). Read on to see how you can flash it and, in the next post how this soldering iron works.

Flashing

Okay, you have this soldering iron and want to use this firmware?

The simplest way is to download a release build from my repository and flash it using an STLink adapter (the cheapest kind with a colourful aluminium case will suffice).

Opening the case

To open the soldering iron you need to unscrew the tip and remove 2 Torx screws: one in the back holding the rear cap and one in the front under the silicone grip holding the front cap. Remove both caps.

To get the PCB out you need to press two pins on opposing sides down at the same time and pull the USB-C side of the PCB out of the case. I found it easier to push the two pins down using the shown IC extractor tool:

IC puller pointing at one of the mentioned pins

Connecting SWD

Once you're in you need to connect some cables to the test pads labeled on the board: VSS, CLK, DAT. These correspond to GND, SWCLK, and SWDIO on your STLink adapter, respectively. Do not connect VDD (the 4th test pad). It's cleaner to supply the board in a more stable manner using an USB-C supply instead.

SWD pins

Once that's hooked up you should make a backup of the stock firmware with:

st-flash --hot-plug read t12-f0.bin 0x8000000 32768

The program st-flash is available in the stlink-tools Debian package or more generally on Github. The flag --hot-plug is needed here because the reset pin isn't connected to your adapter.

Then flash the custom firmware with:

st-flash --hot-plug write pensolderv3_v1.0.bin 0x8000000

Alternatively you can build the firmware yourself by cloning my repository, opening that directory with VSCode with PlatformIO installed, and just pressing Upload.

Finally power cycle the iron and this screen should greet you if all went well:

Custom firmware showing splash screen on startup

Outro

That's all for this post. In the next part I will write a bit more about hardware details and the stock firmware. In the meantime have a look at my reverse engineered schematic and its annotated PCB layout:

Annotated PCB (click to enlarge)

Footnotes

Quick aside: Of course I can't write this without a short mention of the Pine64 Pinecil. Its price is around 3x higher (40-60€, see below) but still inexpensive compared to something like the Ersa SMD soldering stations I'm used to. The Pinecil V2 is listed for $26 but including shipping to Germany it's $38 with "custom tax and VAT not included".

So with an import VAT of 19% it's around 41€ and you need to drive to your customs office or pay Deutsche Post service fees if they handle the import taxes. So let's say it comes out to around 45€ and possibly a road trip to customs. Another option would be a local German reseller where I saw it for 58€ incl. shipping.

Another aside: I'm very happy with the Miniware TS80P (the other soldering iron you see in the photo). It's handy, light, and awesome for SMD work but its tips are pretty expensive (~20€) compared to the cheapest T12 tips (~4€). ↩︎

GT-ACQI-22WO digital alarm clock hack

2023-06-20T00:00:00Z

Nowadays when opening a cheap clock you will probably be greeted by the dreaded epoxy blob with a lot of traces going from it to the display or LEDs. Thankfully the designers of the Globaltronics GT-ACQI-22WO used a discrete display controller and no epoxy at all, so we have an easy starting point for our soon to be ESP32-enhanced clock! (As soon as I saw this, I went back to the store and bought the other one they had left in the clearance sale.)

Clock display attached to ESP32 board, RTC and temperature/humidity sensor

Display

The display board named DIY-1941LED pretty much contains the whole clock: The main PCB has white LEDs on its front-facing side which are separated by plastic dividers. They shine through a mask to form the displayed symbols and segments.

Here I shone a flashlight through the mask

The back side of the main PCB has an unidentified sanded off microcontroller, a display controller (AIP1640), a passive buzzer, a coin cell holder to keep the RTC running, and connections from the power supply (flex cable socket) and to the button PCB (white/red cables).

Display PCB (from left to right): Buzzer, CR2032 cell holder, display controller, 32 kHz crystal, unidentified microcontroller, display/power supply connector

All the LEDs (except one) are connected to the display controller, which is a Wuxi I-core Elec AiP1640 (English/Chinese datasheet). It can control up to 16 grids with 8 LEDs each (7 segments + 1 decimal dot) - on this board only the first 11 grids are used.

It has an SPI interface and luckily I read somewhere that it's compatible with the TM1640 which is pretty common and supported in some libraries. This was almost plug & play. By going through all the segments and dots in sequence (controlled by an ESP32) I got this mapping between grid/segments and the display:

Display PCB front. Labels corresponding to TM1640 datasheet. Within a 'grid' the segments are in the usual order for 7-segment displays except for the segments marked above. (Bolt LED not shown on paper.)

I mentioned one LED before that isn't connected to the display controller. This is the status indicator of the wireless charging IC, which is a bolt symbol that is located below the "zZ" snooze indicator. The bolt LED is connected between Ground and the middle pin (labelled "LED") of the 5 pin flex cable that goes to the power supply board. Its 1 kΩ series resistor sits on the power board and I think it's supplied by the charging IC's internal (around) 5 V regulator.

One notable mention is the transistor which drives the passive buzzer, located below the microcontroller. This means we can just hook it up directly to our ESP32.

Another less notable mention for me is the input for a thermistor because I will not be using it. Anyway the thermistor's 2 pins are connected with the 5 pin flex cable, go through a voltage divider and to the microcontroller.

Buttons

The button PCB with the label DIY-1941K contains 6 push buttons which are arranged into a small scan matrix. I traced the connections of the PCB from photos and this is what I came up with:

Button PCB with crudely hand-drawn markings. Lines with same color are connected.

Which leads to the following schematic:

Button scan matrix schematic

Power Supply

The power supply board has labels DIY-1941C/LZX16-1001 V1.1 and does multiple jobs:

A thermistor is located at the back of the clock which is connected by two wires to the supply board.
On the back it has connections for a USB-C power input and a USB-A (5V/2A) power output.
It controls the Qi wireless charging coil near the top of the clock.
It connects to the display's main board with a 5 pin flex cable.

Power Supply PCB while still connected to its big coil inside the case.

The easiest part are the 2 pins of the thermistor which are simply routed through to 2 pins of the display connector. These pins are labelled RT+/-.

The USB-C's VBUS line goes to the wireless charging IC and to a switching regulator. I think there is some USB Power Delivery thing going on here where the input voltage isn't always 5V. The D+/D- data lines are connected to the IC but I didn't look into that further.

The switching regulator puts out 5 V which go to the USB-A socket and to the display connector.

Labelled power supply board. The bottom edge is located at the back of the clock.

Most of the rest of the PCB is dedicated to the wireless charging feature around an Injoinic IP6806 (datasheet). It looks pretty similar to the Typical Application Schematic in section 6 of the datasheet. Except for the 3 possible LED outputs of which only LED1 is used which goes to the display connector as we already saw above.

Side note: The IP6806 has a thermal shutdown feature (datasheet, p. 8) using an NTC. But they put the NTC next to the display connector on the PCB in a seemingly useless position. I would have assumed that it should be measuring the parts with the most power losses like probably the H bridge in the charging IC or the charging coil.

Hardware Modifications

The goal of my modifications is to control the display from a custom ESP32 board so I can get features like NTP time synchronization and better display modes (e.g. night mode, events from and temperature/humidity reporting to HomeAssistant).

Also I want to remove wireless charging because I don't need it and in fact think it's quite annoying that the bolt symbol LED keeps blinking if I put something on top of the clock because of the foreign object detection.

Display Board Mods

Modified display PCB with attached cables going to my ESP board (click to make larger)

I unsoldered the nameless microcontroller to get access to the two SPI pins (DIN/SCLK) of the display controller and the buzzer driver. Those signals now go through a cable to my ESP32 board.
I also connected cables to Ground and the anode of the bolt LED.
I salvaged the 32 kHz crystal and the coin cell holder.
I unsoldered the button cables, extended them and put a connector on it for my board.
Also after taking the photos I shortened the legs of the two electrolytic capacitors.
Note that while I attached DIN, SCLK and BUZ to the microcontroller's pads I later noticed that you can more easily use test pads instead which are marked in the image above.

Display assembly with crimped connectors.

Power Supply Board Mods

Power supply modifications.

I removed the big coil and capacitor so I have more space for my ESP32 board. I hoped that the IP6806 would detect the open lines and shut down but probing with an oscilloscope I found that it still puts a 100-something kHz square signal on the coil pads.
Thus not wanting to create unnecessary RF emissions I unsoldered the 1206-sized ferrite to cut power to the charging IC. The ferrite sits between USB-C VBUS and the IC and removing it doesn't affect the 5V switching regulator which powers our display and the USB-A port.
With the IP6806 now completely disabled I scratched the solder resist off the USB-C connector's D+/D- traces and soldered tiny 32 AWG wires to them which go to the USB-UART converter on my ESP32 board. To my surprise this just worked and now I can flash the ESP32 using the USB-C socket.

Here a close-up of the mods:

Power supply modifications, close-up.

ESP32 Board

Here is the schematic of my perfboard:

ESP32 perfboard schematic

The board looks like this:

Power supply (left), ESP board (right), and display unit (above). You can see the thin twisted orange cable between supply and ESP board for USB.

It consists of a bunch of standard components:

ESP32 board with CP2102 USB-serial IC
DS3231 RTC with I2C. Note that you'll have to remove a resistor when using this board with a non-rechargeable coin cell.
AHT21 temperature/humidity sensor with I2C.
1 kΩ resistor for our special bolt LED
10-µF-or-so electrolytic capacitor

You can find KiCAD schematics in my repository.

ESP perfboard attached to plastic frame.

I screwed the perfboard to the plastic frame holding the power supply board using a self-tapping M2 screw. This is already pretty stable but for good measure I put in some foam to rest the right side of the board on.

The power supply board and ESP board are now installed inside the case.

The black plastic frame looks a bit twisted on the picture but it's actually held in place really solidly through the round pin which creates a bridge to the display unit when put together.

AHT21 temperature/humidity sensor board is sitting in the back of the case. I taped the wires of the stock thermistors to the side.

For the temperature/humidity sensor I made a small cutout at the back so it touches outside air. That board is also attached using a self-tapping M2 screw in an existing hole.

Backside of the clock. Note the small square cutout with the AHT21 sensor.

Software

I used ESPHome for this project to simplify integration into HomeAssistant. realthk noted in an issue that he implemented TM1640 support based on ESPHome's TM1637 code and it works pretty well with the AiP1640 on this clock.

Some special handling for all the symbols and pseudo-segments on the display needed to be added. The rest is pretty much writing an ESPHome configuration.

Source code of my project can be found at: https://github.com/spezifisch/esp32-acqi-clock. To build and flash it you can use ESPHome's build instructions.

The first things I added was playing the mario theme using the RTTTL module of ESPHome and add a very low light night mode for the clock without blinking dots:

First version of distraction-free night mode. The display controller actually has 4 brightness levels. A higher brightness is shown here.

And of course a mode to show humidity which we can now measure, too:

Mode showing humidity (in %RH) instead of day and month.

The software is still work in progress but basic clock display works and I can use it on my night stand. My next steps will be modding the other clock and I think it should be possible to use the ESP32's hardware SPI instead of the bit-banging implementation in the current TM1640 module.

Pokemon Go Plus autocatcher DIY

2023-04-03T00:00:00Z

This is a post about the software and hardware side of my recent project, building a mobile device that works like a Pokemon Go Plus with extra features. It is based on an Yohanes' ESP32 implementation of its protocol which uses the results of the reverse engineering efforts done by several people since 2017.

A Pokemon was just caught as indicated by the green LED

TLDR: My fork of pgpemu is released under BSD-3-Clause license. My 3D printable case is available at my pgpemu-case repository with its FreeCAD sources under CC BY-NC-SA 4.0. This post is based on my READMEs for those repositories.

A Short History

The Pokemon Go Plus (support page) was released in 2016 and its selling point was basically that you can play a mobile game without looking at a mobile phone. It is a low power Bluetooth LE device that operates from a coin cell. You pair it with your Pokemon Go app on your phone and then it vibrates and blinks when an in-game action can be taken. You then have to react manually by pressing a button.

To avoid having to press that button some people built clips that just always press it or just tied a coin with some rubber band to the device to achieve the same. Others wired the vibration motor output to the button so it presses itself automatically.

Meanwhile compatible devices cropped up like Datel/Codejunkies' Go-tcha series which can automatically simulate a button press. They emulate a Go Plus on their own custom hardware with extra features.

Also notable are a range of clone devices like the Pocket Egg/Pair which contain the same Bluetooth SoC as the original Go Plus (twice for the Pair) with the same firmware as an original. The pins which are used for button and LEDs in the original are wired to a microcontroller which then automatically presses the button for you.

Reverse Engineering

Public reverse engineering was done by BobThePigeon_ (2017), Yohanes Nugroho (2018: one, two), and Jesus Bamford (2019) who also implemented an OTA bootloader exploit (2019) to dump a Go Plus without needing to modify its hardware.

The bottom line is that the Bluetooth connection between Pokemon Go Plus (the wearable) and Pokemon Go (the app) is authenticated with a handshake protocol using mutual challenges and responses based on shared secrets. Due to the mentioned reverse engineering efforts the protocol for this is known to the extent that you can implement it on your own hardware using pgpemu which my project is based on.

However, it is currently not known if you can generate valid secrets yourself from scratch. That's why to my knowledge every clone (like Pocket Eggs and fake Go Pluses) and every emulator (like Go-tchas and pgpemu) uses secrets dumped from a genuine Go Plus. Since the secrets seem to be tied to the wearable's MAC address, the clones and emulators have a limited set of MAC addresses or even only one each with known dumped secrets. This sharing of MAC addresses leads to some interesting issues as Yohanes already noted in his article.

Note that if the secrets can't be generated from the MAC address alone the app needs to get it from somewhere. If that is done using the usual RPC mechanism in Pokemon Go, it should be contained in their protobuf files.

I haven't disassembled any Go-tchas yet but all the hardware clones I examined shared the same MAC address but different ones for each product line.

It will be interesting to see whether the newly announced Pokemon Go Plus+ will use a new protocol. The current security mechanisms worked well enough to deter widely available/usable Open Source emulators long enough and considering that Datel will probably crack it quickly anyway, there don't need to be a lot of changes. Curiously enough the current protocol already has enough reserved bits left in their button messages to implement the new functions like throwing another type of Pokeball in a backward compatible manner.

Software

Starting from Yohanes' latest pgpemu commit of 2020 I reworked the code quite a bit to make it more easily maintainable. My goal was to make the emulated device more realistic and harder to detect. You can read about the details in my README.

The most notable features are:

connect up to 4 devices simultaneously
parse LED patterns to auto-press the button only when needed
button press delay and duration are randomized
the handshake nonces are now randomized and saved per connected device
serial menu to reconfigure autocatch/autospin/etc. on the fly
secrets are saved in their own partition to make development easier

Some limitations still are:

The battery reading is always the same value. I might add a real measurement of my battery voltage to address this.
The ESP32 can only have one MAC address at a time. So you get problems connecting it to multiple accounts on the same phone at the same time in split screen or windowed mode.
You need a Go Plus to dump the secrets to begin with.

Currently I'm using the button to start Bluetooth advertising when I want to connect an additional phone.

The RGB LED doesn't show the same patterns as a normal Go Plus but a simplified version which is less blinky:

green - Pokemon was caught
yellow - New species of Pokemon was caught
pink - Pokemon fled
blue - got items from Pokestop
red - Pokemon box full or item bag full
steady blue - Bluetooth is advertising

Electronics

ESP32

As ESP32 board I used a Devkit C compatible one I had lying around. Another choice would have been something like the DFRobot FireBeetle which already integrates a LiPo charger or a DFRobot Beetle which is way more compact.

Note that the Devkit-like boards sometimes have brownout issues due to their capacitor placement and count. I added a 0805 10µF ceramic capacitor directly to the ESP32 module like mentioned in the linked post.

LiPo Charger and Battery

I used a TP4056 charger module with DW01A battery protection IC and a USB-C connector.

Note that TP4056s are a bit tricky to handle safely. In short, you need to disconnect any load (like the ESP32 board) when charging or it will potentially charge the battery forever, creating a fire hazard. That (and saving power) is what my toggle switch is for.

Also note that the DW01A is only providing overcurrent protection on this charger board.

In order to still make it reasonably safe I chose a 1800mAh battery with its own protection circuit which also provides overcharge and over-discharge protection I would otherwise not have safeguards against.

Another choice for battery management would have been an MCP73871-based board as described in this article.

Supply

The ESP32 has an operating range from 3.0V - 3.6V (see datasheet p.46).

The LiPo battery that I chose has a safety circuit which ensures the voltage is >=3.0V and <=4.28V (see battery datasheet section 6.1.0) but the TP4056 charger only charges until 4.263V anyway (see TP4056 datasheet p.2). Also note that we're charging with 1A (the charger uses R_prog = 1k2 by default) and the battery supports this according to the datasheet.

Now I considered generating the ESP32's voltage using either:

a boost regulator: battery -> boost 5V -> 3.3V with LDO on the ESP32 board -> ESP32
a modern LDO with 0.3V dropout voltage directly: battery -> LDO 3.3V -> ESP32
a standard silicon diode to get the battery's range into the ESP32's range: battery -> diode with 0.7V forward voltage -> ESP32

I went with the diode to reduce part count so I get between 2.3V and 3.5V which is safe for the ESP32 and it's working fine.

Note: As explained above, you can't have the device switched on while charging. However, you can connect the ESP32's Micro USB while charging with the switch in the off position. Looking at the ESP32 board schematic the AMS1117 output would be connected with your diode's cathode so you won't get backward currents into the battery or USB port.

Case

At first I tried designing a case for my battery-powered gadget in Tinkercad. I did some light work with Tinkercad before and was amazed how well it actually works for a CAD running in your browser.

The previous case which I remixed in Tinkercad

But having used SolidWorks before I was quite confused after I looked up how cumbersome it is to just split a part into two and I still can't quite wrap my head around how to align different parts on the first try.

Long story short, I went on using FreeCAD with the Assembly4 addon which after a day of adjustment provided a very familiar experience.

The device in FreeCAD

Assembly

At the bottom the TP4056 is tied in place using a cable tie. There is a small stub above the USB-C port to keep it from going up. On the side with the cables I added a small block that keeps the charger from being pushed into the case.

The battery is glued to the bottom of the case with a small piece of double-sided adhesive tape to keep it in place. I also added a small piece of foam above the battery (not pictured) and some isolating tape covering the pointy parts of the perfboard. There should be enough space for possible LiPo bloat.

The bottom layer with battery and charging board

The perfboard rests on top of that on the small holders at the sides. I used 45° angles so the holders don't sag down when printing. This turned out quite well.

The top layer of the case with the perfboard

The lid uses a clip mechanism that I reused from the design I based my previously mentioned old case on, so the gadget can be almost fully disassembled without tools (except for the cable tie around the charger). The lid pushes down tightly on the corners of the perfboard to keep it from moving up.

The finished device, charging

I had to pay special attention to the thin wall around the Micro USB port when printing. The wall needed to be quite thin there so plugs can fit. But my 3D printer software decided to slice away this part because the wall was thinner than the extrusion width but the "thin wall" option there remedied this problem. From now on I'll make sure to look at the slicer's output before starting the print.

Closeup of the ESP32 development board's Micro USB port

There also was a recession around the charger's USB-C in my first print but I realized that it wasn't necessary because USB-C plugs seem to be longer leaving more space.

Closeup of the charger board's USB-C port

And that's it! I can now throw this device into my backpack and run around playing a mobile game without having to play it. When Pokemon Go gets old for me I will just need to grind away the Pokeball shape on the lid.

Govee RGB Strip (H619A) Part 1 - Investigation

2023-03-13T00:00:00Z

I recently got a Govee H619A RGB LED strip. It is 5 meters long and its LEDs are grouped into segments which can be controlled individually. The main components are a controller box with 3 buttons, a 24V/1A wall wart, and the strip itself. The strip is divided into 20 segments with 6 RGB LEDs each. And of course there is a mobile app for remote control.

top: the first segment of the RGB strip with its IC (left) and 6 RGB LEDs showing #2d2d2d; bottom: logic analyzer probes on data output (and GND)

TLDR: The RGB strip is controlled with the WS2812 protocol using 5V logic level and 24V supply. The Bluetooth and WiFi hardware is cheap closed source stuff and quite boring.

Motivation

You control the RGB strip with the app using Bluetooth (directly) or WiFi (through ~~cloud~~ other people's servers). But of course you have to create a Govee account first. Then you just enter your WiFi network key inside the app (thankfully optional though pushed onto you). And then the thing - which also contains a microphone, did I mention? - is controllable from anywhere. Great! What could go wrong?

The target

In any case that controller board needs to go and be replaced by something like an ESP32 with a Free firmware.

I then want to use it via HomeAssistant without the Govee Cloud API and as such without needing to trust some random company and hope that their servers are maintained forever. Well, there is the Govee Bluetooth integration but it doesn't support their RGB strips and I really don't want to go down that road working with their proprietary BLE high level protocol.

Internals

The controller is easily opened as the back plate is just clipped in place:

Highlighted: Beken BK3269 Bluetooth SoC, Supply (goes to a barrel jack), Data output (goes to the RGB strip)

The 24V supply is connected through a high-side shunt (around 0.1 - 0.2 Ohm as far as my multimeter can measure) to the RGB strip. The ground line between supply and strip is connected directly.

Oscilloscope probe on the data output pin (to the RGB strip)

Probing around with the oscilloscope the most action happens on the data output pin (labelled in the previous image). The bit timing should be pretty easily recognized if you know about the WS2812 protocol. (I didn't.)

Other than that there is some communication on the test pads labelled RX and TX between the Bluetooth and the WiFi module when you change the LED pattern using the app.

RGB strip data output

I hooked my fx2lafw Logic Analyzer to the data pin and captured some communication. The signal is quite fast so you need a sample rate on the upper end of what the analyzer supports (16 MHz gives good results).

Data frame timing

Every 20 ms there is a burst of bits. Occasionally there is a longer delay though.

Data byte timing

I added the WS281x protocol decoder in PulseView for the screenshot so you can already see the color values for the individual segments of the strip. Here all segments except for the 18th are off and the other one is showing a dimmed white.

Data bit timing

At this point I saw what looked like On-Off keying and it dawned on me that this might be the WS2812 (or rather WS281x, I guess) protocol so I looked it up and sure enough the bit timing matched within tolerance (0.8 µs high, 0.4 µs low; and 0.4 µs high, 1 µs low). And then I finally found its protocol decoder is already included in PulseView.

Compare the measured timings to the WS2812B datasheet:

Bit timings from WS2812B datasheet

Funnily enough, once I knew what protocol I was looking for I searched online for "govee ws2812" and I found a Reddit thread from Sep. 2020 with photos of WS2811 ICs in a Govee light.

Side note: Bluetooth SoC

The Bluetooth SoC is a Beken Corporation BK3269. The nearest thing Beken have on their website is the product description of the BK3266 which is described as a device for audio applications.

It's connected to the microphone, the 3 front buttons, the RGB strip, and the WiFi module.

Side note: WiFi module

The WiFi module seems to play only an auxiliary role. From a quick check with the oscilloscope it seems to be talking with the Bluetooth SoC using 3.3V level UART.

Govee H619A, FCC ID: 2AQA6-H619E

According to the FCC documents the WiFi controller should be a Realtek RTL8720CF (datasheet available here) which is also shown in the internal photos in FCC document 5627324.pdf (p. 4) with the correct markings on the chip, containing the crab and all. But this doesn't match the markings on my model which are W701 L3198I.

Extracting audio samples from Rave Generator 2 VST plugin

2022-11-01T00:00:00Z

Rave Generator 2 is a widely used free VST plugin that's basically a sampler/rompler with a bunch of included classic rave and hardcore samples. These instantly take you back to an era of dirty pitched up samples from orchestra stabs and piano chords. The FAQ file already sets the scene:

Q: i like the sound of RaveGenerator but it aliases like hell, what can i do ?
A: enjoy the dirty sound of the 90's rave.

You can get the plugin on the Wavosaur blog for Linux/Windows/Mac.

Who needs an Alpha Juno if you have this?

Motivation

One problem with the Linux version is that it requires Qt4 libraries which are so old that they're not included anymore in most distros. In case of Debian Bullseye you can work around this by copying them from old packages or build them yourself.

But if you're using Bitwig's Flatpak version you're out of luck because you can't easily install Qt4 (if you don't want to build a custom Flatpak package of Bitwig containing Qt4).

The half-working thing

Adding the plugin in Flatpak-Bitwig leaves you with a half-working thing where you can select presets of combinations of samples but you can't access or rearrange individual samples. The main UI is inaccessible because trying to open it just gives the following log messages about missing libraries:

UIRaveGenerator2VST: error while loading shared libraries: libQtCore.so.4: cannot open shared object file: No such file or directory
VST plugin did not create it's window inside the plugin window

The mentioned workarounds seem like a hassle. I waved my fist at a cloud and opened Ghidra.

Finding the samples

Start of Sample::pathToBuffer()

When searching for known sample names I quickly found this function (Sample::pathToBuffer) which takes a resource name string like :/Resources/sounds/stabs2/foo.wav and returns a pointer to WAVE data containing the wanted sample.

The string's syntax reminded me of Qt's QResource so I ran dgchurchill/extract-qt-resources on the plugin file (RaveGenerator2VST-x64.so). But it couldn't detect any files in there.

There are 83 individual samples in there which would have been too many to do manually so I wrote a script using Ghidra-Jupyter-Kotlin for quick prototyping (and so I could do some Kotlin).

The notebook

I uploaded the Jupyter Notebook to Github Gist (mirror). You can just open it and follow the instructions at its top and ignore the rest in here if you don't care about a description of what it does.

So first we have a container for information we want to gather for each sample:

resourceName - the identifier used in the binary, e.g. ":/Resources/sounds/instrus/Pump Bass.wav"
fileName - a valid file name like "sounds/instrus/Pump Bass.wav"
waveAddr - Ghidra's pointer to the WAVE data
rootNote - the note which the sample plays when playing it back with the original speed, e.g. D3 (i.e. the note D in the 3rd octave)

data class RGSample(var fileName: String? = null,
                    var resourceName: String? = null,
                    var waveAddr: GenericAddress? = null,
                    var rootNote: String? = null) {
    fun valid(): Boolean {
        return fileName != null && resourceName != null && waveAddr != null
    }
}

pathToBuffer parser

In a loop we then go through each line (i.e. assembler instruction) of the pathToBuffer function body:

val samples = mutableListOf<RGSample>()
var currentSample = RGSample()

for (codeUnit in currentProgram.listing.getCodeUnits(pathToBuffer.body, true)) {
    if (monitor.isCancelled) {
        return
    }
    
    val mnem = codeUnit.mnemonicString
    if (mnem == "LEA") {
        // load resource name
        val resourceNameAddr = codeUnit.getAddress(1)
        val resourceName = getDataAt(resourceNameAddr).getValue() as String
        currentSample.resourceName = resourceName
        currentSample.fileName = resourceName.removePrefix(":/Resources/")
        
        if (debugPathToBuffer) {
            println("${codeUnit.address}: ${resourceNameAddr} ${resourceName}")
        }
    } else if (mnem.contains("MOV") && codeUnit.toString().contains(" RAX,")) {
        // set function return value
        val wavePtr = if (mnem.startsWith("CMOV")) {
            getDataAt(codeUnit.getAddress(1)).getValue()
        } else {
            codeUnit.getAddress(0)
        } as GenericAddress
        
        currentSample.waveAddr = wavePtr

        // [... rootNote handling excluded for clarity ...]

        // this sample is done
        samples.add(currentSample)
        
        if (debugPathToBuffer) {
            println("${codeUnit.address}: wave address ${wavePtr}")
        }
        
        // next sample
        currentSample = RGSample()
    }
}

The LEA instructions here always load a resource name string to compare against the function's input parameter.

The comparison's result is checked and if successful the address of the wanted WAVE data is copied into the RAX register as a return value. These instructions are MOVs, or CMOVNZ in the last occurence.

Luckily the compiler produced pretty much the same code for each of the cases so we can get away with a very simple parser: store the resource name of the checked sample in currentSample.resourceName and the next MOV RAX,... line will be the corresponding data pointer which we store in currentSample.waveAddr.

In the end we have a list of sample names and data pointers in samples which we can use to write the data to external files.

adjustRootNote parser

Okay, we now know where the samples are but I saw that some sample sounds are recorded in a note different from C3 which I assume to be the default root note (because it usually is). It would be nice to have the root note in the file name so I can set it accordingly in my sampler. And so that I actually get a C when I'm pressing C on my keyboard.

start of Sample::adjustRootNote() (left) and C code for Sample::setRootNote() (right)

Also in the Sample class there's an appropiately named adjustRootNote() function which handles the cases for the 22 samples which have different root notes.

The parser code here is pretty similar to the one for pathToBuffer() so here's just an essential differing part:

/*...*/ if (mnem == "JZ") {
    if (debugAdjustRootNote) {
        println("${codeUnit.address}: $codeUnit")
    }
        
    // follow the jump target for the case of the resource name matching
    val jmpTarget = codeUnit.getAddress(0)
    for (nestedCU in currentProgram.listing.getCodeUnits(jmpTarget, true)) {
        if (debugAdjustRootNote) {
            println("NEST ${nestedCU.address}: $nestedCU")
        }

        if (nestedCU.mnemonicString.startsWith("J")) {
            // stop at the jump back to avoid cycles
            break
        } else if (nestedCU.toString().startsWith("MOV ESI,")) {
            if (currentResource == "") {
                println("ERROR: we missed the root note name")
            }

            // ex: MOV ESI,0x38
            // get argument to call of Sample::setRootNote()
            val rootNoteRaw = nestedCU.getScalar(1).getValue()
            val rootNote = getRootNoteString(rootNoteRaw)

            // write root note
            if (debugAdjustRootNote || infoAdjustRootNote) {
                println("got root note: ${currentResource} -> ${rootNote}")
            }

            rootNotes[currentResource] = rootNote
            currentResource = ""
        }
    }
}

The switch statement in this function is structured a bit differently than the previous one. While in pathToBuffer() the instructions for the case of a matching resource string came immediately after the comparison, here the unsuccessful case and the check for the next case follow.

In case of a successful match of the resource string we have a jump to a small set of instructions which call Sample::setRootNote(int note) with the appropriate note value (explained later).

That's where the code shown above comes to play which follows this jump, extracts the 2nd argument to the MOV ESI, ... instruction which contains the argument to the function call to setRootNote(), and stores it in the HashMap rootNotes which gets added to the samples list from before.

setRootNote analysis

So what does this note parameter in setRootNote(int note) mean? I translated the function's decompiled C code to Python to show what's going on:

# Sample::setRootNote() rewritten in Python
factor = 1.0

if note > 60:
    for i in range(note - 60):
        # pitch down one semitone
        factor /= 1.059463094359
elif note < 60:
    for i in range(60 - note):
        # up by one semitone
        factor *= 1.059463094359

So if the root note is above 60 (C3) the "factor" gets scaled down by 1.059463094359 for each semitone that it's above 60. The symmetric case is done for a note lower than 60.

You can easily search the Internet for the term 1.059463094359 and see that it's the 12th root of 2 which is the frequency ratio between two adjacent notes (e.g. C and C# or B and C) in the equal-tempered scale in western music.

We can therefore conclude that the "factor" modifies the playback speed of the sample so that a sample recorded in C# is played at 1/1.059463094359 the original speed when you're pressing C on the keyboard.

Using this background we can write a function to translate these note values to readable strings:

fun getRootNoteString(arg: Long): String {
    // Sample::setRootNote(int) pitches the note up or down by the given number of semitones away from 60 (= C3)

    // convert that number to a readable note, assuming C3=60, B2=59, C#3=61,...
    val octave = (arg / 12).toInt() - 2
    val semitone = (arg % 12).toInt()
    val notes = arrayOf("C", "C#", "D", "D#", "E", "F", "F#", "G", "G#", "A", "A#", "B")
    
    return "${notes[semitone]}${octave}"
}

Conclusion

Now we have everything in place to export the samples with meaningful file names for use in another sampler.

In case you missed it above here is the Jupyter Notebook (Github) (mirror) you need to get the WAVE files.

Also I found no full list of samples contained in Rave Generator 2 on the Internet, so here it is in case someone looks for those:

:/Resources/sounds/instrus/Get Up Bass.wav
:/Resources/sounds/instrus/Hardcore Hoover.wav
:/Resources/sounds/instrus/Hi Voltage.wav
:/Resources/sounds/instrus/Juno Bass.wav
:/Resources/sounds/instrus/Juno Hoover.wav
:/Resources/sounds/instrus/m1organ.wav
:/Resources/sounds/instrus/Maniak Techno.wav
:/Resources/sounds/instrus/Mayday Dream.wav
:/Resources/sounds/instrus/Omnibus.wav
:/Resources/sounds/instrus/Pizzicato Dance.wav
:/Resources/sounds/instrus/PsychotropiCZ.wav
:/Resources/sounds/instrus/Pump Bass.wav
:/Resources/sounds/instrus/Rave CutBass.wav
:/Resources/sounds/instrus/Rave Cycle.wav
:/Resources/sounds/instrus/Square Bass.wav
:/Resources/sounds/jx1/JX1 C4+C5.wav
:/Resources/sounds/stabs2/Awesome3.wav
:/Resources/sounds/stabs2/BizarreInc1.wav
:/Resources/sounds/stabs2/Black Riot 2.wav
:/Resources/sounds/stabs2/Cubic22.wav
:/Resources/sounds/stabs2/DeeLiteOrgan.wav
:/Resources/sounds/stabs2/Dist Brazil.wav
:/Resources/sounds/stabs2/DJ Professor.wav
:/Resources/sounds/stabs2/Enjoy.wav
:/Resources/sounds/stabs2/FidelFattiPiano.wav
:/Resources/sounds/stabs2/HappyHardcoreStab.wav
:/Resources/sounds/stabs2/Hit House 2.wav
:/Resources/sounds/stabs2/Landlord 2.wav
:/Resources/sounds/stabs2/Poltergeist.wav
:/Resources/sounds/stabs2/Powerrr.wav
:/Resources/sounds/stabs2/Rave Action.wav
:/Resources/sounds/stabs2/RedTwo.wav
:/Resources/sounds/stabs2/Short Rave.wav
:/Resources/sounds/stabs2/SpeedSoul.wav
:/Resources/sounds/stabs2/Sweat.wav
:/Resources/sounds/stabs2/Take On Higher.wav
:/Resources/sounds/stabs2/Toxic Two.wav
:/Resources/sounds/stabs2/Wave Of Future.wav
:/Resources/sounds/stabs2/Wild Child1.wav
:/Resources/sounds/stabs2/Wild Child2.wav
:/Resources/sounds/stabs2/Wild Child3.wav
:/Resources/sounds/stabs2/Zentral.wav
:/Resources/sounds/stabs3/Belgian Rave.wav
:/Resources/sounds/stabs3/Break Boys.wav
:/Resources/sounds/stabs3/CLS.wav
:/Resources/sounds/stabs3/Cool Stab.wav
:/Resources/sounds/stabs3/CZorgan Alex Party.wav
:/Resources/sounds/stabs3/Distorgan2.wav
:/Resources/sounds/stabs3/Expansion.wav
:/Resources/sounds/stabs3/Gabbers.wav
:/Resources/sounds/stabs3/Hardcore Hoover.wav
:/Resources/sounds/stabs3/Hound Stab.wav
:/Resources/sounds/stabs3/House Nation.wav
:/Resources/sounds/stabs3/Magic Feet.wav
:/Resources/sounds/stabs3/Mayday.wav
:/Resources/sounds/stabs3/Organonox.wav
:/Resources/sounds/stabs3/Party Children.wav
:/Resources/sounds/stabs3/Piano Chord.wav
:/Resources/sounds/stabs3/Rotterdam Hoover.wav
:/Resources/sounds/stabs3/SL2.wav
:/Resources/sounds/stabs3/Synth15 Stab.wav
:/Resources/sounds/stabs3/Techno8.wav
:/Resources/sounds/stabs3/Tremoradelterra.wav
:/Resources/sounds/stabs3/Twilight Bep.wav
:/Resources/sounds/stabs3/Wavez.wav
:/Resources/sounds/stabs3/Week End.wav
:/Resources/sounds/voices/Acieed.wav
:/Resources/sounds/voices/Ayeaaaa First Choice.wav
:/Resources/sounds/voices/Charly.wav
:/Resources/sounds/voices/Dish you.wav
:/Resources/sounds/voices/Energize.wav
:/Resources/sounds/voices/Fast.wav
:/Resources/sounds/voices/Go 2.wav
:/Resources/sounds/voices/Godftaher The Joint.wav
:/Resources/sounds/voices/jieeeeeeeaaaaaaaah.wav
:/Resources/sounds/voices/Kick Out The Jam.wav
:/Resources/sounds/voices/Loon.wav
:/Resources/sounds/voices/Neneh Cherry.wav
:/Resources/sounds/voices/ooooooooh2.wav
:/Resources/sounds/voices/ooooooooh.wav
:/Resources/sounds/voices/Party.wav
:/Resources/sounds/voices/Patti.wav
:/Resources/sounds/voices/Paw.wav

CO2 Sensor Reverse Engineering - Part II

2022-08-25T00:00:00Z

After finding out how to decode the CO2 sensor measurements in the previous post I wanted to look at other salvageable components of the "BreeRainz DM1308A".

Battery Management

On the bottom side of the main PCB there is a battery management IC I didn't mention: HM4052 from Shenzhen Huazhimei Semiconductor Co., Ltd. It's quite interesting because it combines a 3.3V buck regulator with battery charging and safety functions without the need for an external microcontroller for configuration. It just works: You plug in USB and the battery is charged with a rate configured with an external resistor and your device is powered by USB. You unplug it and your 3.3V come from the battery.

Temperature/Humidity Sensor

The gadget also shows the temperature and humidity on the display. What kind of sensor is it using?

TLDR: It's a Sensirion SHT31 connected via I2C.

Logging the communication

Again the following PulseView traces show the communication between the microcontroller and the sensor:

Initially after power-on the microcontroller sends 22 36 to I2C address 0x44.

Then it waits around 500 ms and sends another command (E0 00) to 0x44 and reads a response from the same address. Then it sends the first command again.

The Protocol

Luckily with I2C the addresses are pretty telling: There are a few known devices using this address and of those the Sensirion SHT 31 fits the bill perfectly. The datasheet contains all the information we need.

Datasheet: Measurement command

So the 22 36 from the command means that 2 measurements per second should be taken with the "high" repeatability setting.

Datasheet: Data fetch command

And this shows that E0 00 is the "data fetch command" which gives us 16 bit temperature and humidity measurements, each one with a CRC checksum.

Datasheet: Humidity and temperature value conversion

And this is how we get human-readable measurements after reassembling the bytes in the right endianness into 16 bit values.

Decoding our logs

We can now decode the measurements in our logic analyzer traces above.

In the screenshot we got the following response bytes:

44 67 86 A6  93 CA 7D
^^       ^^        ^^
AR ^^^^^ CRC ^^^^^ CRC
   temp.     humid.

Converting them this gives us:

# temperature in °C
>>> -45 + 175*(0x67*256 + 0x86)/(2**16 - 1)
25.769054703593497

# humidity in %RH
>>> (0x93*256 + 0xca) * 100/(2**16 - 1)
57.73098344396124

Don't you love this summer.

We now have a temperature and humidity sensor for our own gadget! But we should really check the checksums, too. Their CRC parameters are given in the datasheet.

CO2 Sensor Reverse Engineering

2022-08-23T00:00:00Z

I recently bought the cheapest CO2 measurement device with an NDIR sensor that I could find: "BreeRainz DM1308A" for 25€ on Amazon.

Credit: BreeRainz on Amazon

I hoped to find something like the popular MH-Z19 inside which currently costs around 35€. My plan was to buy the cheaper device, save some bucks and to unsolder its CO2 sensor and use it in a DIY gadget with an ESP32.

TLDR: The device contains a CO2 sensor which is pin-compatible to MH-Z19 but with a different serial protocol. It's a bit obscure but you can find a datasheet and protocol description. The module is named HC8 (not to be confused with the Bluetooth module HC08) and it also has a PWM output (which isn't used in this gadget).

Disassembly

I totally wrecked the enclosure prying it open because I didn't know there were screws behind the front glass of the display.

In the back you can see a 3.7V/1600mAh LiPo battery, a Micro USB charging port (actually you can also connect a PC to flash the display controller), and a temperature/humidity sensor (Sensirion SHT3x, or at least compatible).

In the front there's the main PCB on top of the display.

Main PCB: 1=on/off switch; 2=connector for temperature/humidity sensor; 3=CO2 sensor; 4=Levetop LT268A display controller/microcontroller; 5=W25Q32JV 32MBit SPI flash; 6=bootloader switch; 7=LiPo battery connection (removed); 8=display connector

All the peripherals are connected to the display controller (Levetop LT268A) which is quite an interesting device. From the manufacturer's page:

LT268x/269 are Serial-Uart TFT Controller designed for small size MCU panels, integrated Cortex M4 32bit MCU core architecture. The main function is to provide Uart serial communication, so that the host computer MCU can easily transfer the content to be displayed to the TFT driver through simple command. [...]

The internal frequency of the LT268x/269 is 150MHz, including 512Kbytes Flash and 256Kbytes SRAM, provide Uart serial communication and SPI Flash interface. The external SPI Flash can be used to store pictures, animations, fonts and other information.

Pretty nice for a thing whose only job it is to receive a CO2 concentration via UART, temperature and humidity data via I2C and to display those.

Out of curiosity I dumped the SPI flash with a CH341A (flashrom -p ch341a_spi -r dump.bin) but this shouldn't be my focus here as there isn't much inside: Only roughly 1 MByte is used, probably for the displayed images as the display controller datasheet suggests. binwalk also couldn't find anything useful.

Finding out the CO2 sensor's protocol

Back to the CO2 sensor. How do we get its measurements? Fortunately RX, TX, and GND were labelled on the PCB, so I hooked up a logic analyzer (FX2 evaluation board with sigrok firmware and PulseView) to find out.

The CO2 sensor communicates using UART with 9600 Baud, 8N1. After switching the device on it initially sends a packet starting with 42 4D and some bytes containing the CO2 measurement and a checksum.

Command packet (look at RXD/TXD and ignore the other traces)

The display controller then sends 64 69 03 5E 4E to request a measurement. This also causes the sensor to leave the default mode where it automatically sends measurement data every second.

Response packet

The CO2 sensor then responds with a packet starting with 64 69 03 and the CO2 measurement in a similar format.

This doesn't look like the MH-Z19 I hoped for.

What is it?

So here's how I found the datasheet for the CO2 sensor:

I just searched for the sequence of bytes (64 69 03 5E 4E) the display controller sends. There was a single search result with a PDF. And its server was not reachable. Luckily Google still had a cached version of its content.

By the way you can also see part of the sensor's pinout in the image results in the screenshot above.

So here is the answer: The CO2 sensor is called HC8 and it's manufactured by 广州海谷电子科技有限公司 (Guangzhou Haigu Electronic Technology Co., Ltd.).

The datasheet contains this nice explanation (translated with DeepL, slightly edited for clarity):

The working principle of the non-dispersive infrared absorption (NDIR) gas sensor is based on the [Lambert-Beer law.] The absorption characteristics of infrared spectrum are calculated and confirmed through the relationship between gas concentration and absorption intensity (Lambert-Beer law). [...] Molecules composed of heterogeneous atoms such as CO2 and CO have absorption spectra in the infrared wavelength region. Its absorption intensity follows the Lambert-Beer law. When the light wave corresponding to the characteristic absorption wavelength of a certain gas passes through the measured gas [...] its intensity will be significantly weakened, and the degree of intensity attenuation is related to the concentration of the gas, and the relationship between the two follows [...] the Lambert-Beer law. The basic principle structure of the NDIR sensor is shown in the figure below.

Specs

Some interesting parts of the specifications which will be useful when implementing a DIY gadget around this sensor:

Measuring range: 400~5000 ppm
Resolution: 1 ppm
precision: ±(50ppm+5% *reading)
Response time T90: <120 seconds (s)
data update time: <3 (standard 1s) seconds (s)
Preheat time:
    <25s (operational)
    <2min (90% accuracy)
    <10min (maximum accuracy)

Protocol

Some relevant parts of the datasheet:

The sensor has two output modes, active output and query output. After one query, the active output stops.
It needs to be powered on again to restore.
After power-on, the sensor actively outputs data: the output frequency is 1S once.

Data format in "active output" mode:

The output format is 16BYTE.
Data header: BYTE0 = 0X42; BYTE1=4D
BYTE6 data is high, BYTE7 data is low, indicating CO2 concentration.
BYTE15, data checksum. BYTE15= BYTE0+BYTE1+…….+BYTE13;

Example: 42 4D 0C 51 09 A2 07 2B 01 35 05 81 20 08 20 AD;
CO2 concentration = BYTE6 X 256 + BYTE7 = 07X256 + 2B = 1853;

It's interesting here that the checksum in this mode is just the sum of the previous bytes which isn't as robust as CRC.

Data format in "query output" mode:

Query reads:
Read CO2ppm value, return 522ppm
Send: 64 69 03 5E 4E
Return: 64 69 03 01 0A 02 00 00 00 00 00 00 9B F0

14 BYTEs are returned.
BYTE4, BYTE5 represent the concentration of CO2, converted into decimal not only the concentration value, BYTE5 is the upper 8 digits, BYTE4
for the lower 8 bits.
0x0A is the low byte of the 16bit integer, 0x02 is the high byte, and together it is 522
BYTE12, BYTE13 are CRC check data

And this one uses CRC. The datasheet also contains example code for the CRC check. So I'm going with this mode for my own gadget.

We can also now decode the response packet I showed in the screenshot before. Its bytes were:

64 69 03 01 B6 02 00 00 00 00 00 00 90 D1
^^^^^       ^^^^^                   ^^^^^
header       ppm                     CRC
      ^^^^^       ^^^^^^^^^^^^^^^^^
        ?         seems always zero

To get the CO2 air concentration in parts per million (ppm) we do:

> 0x02 * 255 + 0xb6
  (2 × 255) + 182 = 692

So it's 692 ppm!

Salvaging the CO2 sensor

The CO2 sensor's pinout of the top row is from left to right: +5V, GND, NC (not connected), PWM; bottom row: NC, RX, TX, NC

Now that I knew enough I unsoldered the CO2 sensor, connected it to my PC using an FT232 board with 3.3V and supplied the sensor itself with 5V.

As a quick test I wrote a small Python script which uses pyserial and uses the "active output" mode of the sensor:

#!/usr/bin/python

import datetime
import serial
from binascii import hexlify

with serial.Serial("/dev/ttyUSB0", 9600, timeout=5) as ser:
    while True:
        b = ser.read(16)
        ts = datetime.datetime.now().isoformat()

        b_hex = ""
        if b:
            b_hex = hexlify(b)
        
        if len(b) == 16:
            header = b[:2]
            ppm = b[6:8]
            csum = b[14:16]
            
            header_hex = hexlify(header)
            ppm_hex = hexlify(ppm)
            csum_hex = hexlify(csum)
            ppm_value = int(ppm[0]) * 256 + int(ppm[1])
            print(f"{ts} packet({b_hex}) header={header_hex} csum={csum_hex} ppm={ppm_hex} = {ppm_value} ppm co2")
        else:
            print(f"{ts} packet({b_hex})")

I left it running for a bit and it settled at around 950 ppm CO2 inside the room. I then started soldering something else next to the CO2 sensor and it quickly picked up:

2022-08-21T13:25:08.014641 packet(b'424d0b0a093f03b2012e0000e20623db') header=b'424d' csum=b'23db' ppm=b'03b2' = 946 ppm co2
2022-08-21T13:25:09.037387 packet(b'424d0b0a093f03b2012e0000e20623db') header=b'424d' csum=b'23db' ppm=b'03b2' = 946 ppm co2
2022-08-21T13:25:10.044122 packet(b'424d0b07093b03b2012e0000e20623d4') header=b'424d' csum=b'23d4' ppm=b'03b2' = 946 ppm co2
2022-08-21T13:25:11.050926 packet(b'424d0b07093b03b2012e0000e20623d4') header=b'424d' csum=b'23d4' ppm=b'03b2' = 946 ppm co2
2022-08-21T13:25:12.057797 packet(b'424d0b07093b03b2012e0000e20623d4') header=b'424d' csum=b'23d4' ppm=b'03b2' = 946 ppm co2
2022-08-21T13:25:13.064491 packet(b'424d0b02093a03b4012e0000e20623d0') header=b'424d' csum=b'23d0' ppm=b'03b4' = 948 ppm co2
2022-08-21T13:25:14.071280 packet(b'424d0b02093a03b4012e0000e20623d0') header=b'424d' csum=b'23d0' ppm=b'03b4' = 948 ppm co2
2022-08-21T13:25:15.077977 packet(b'424d0b02093a03b4012e0000e20623d0') header=b'424d' csum=b'23d0' ppm=b'03b4' = 948 ppm co2
2022-08-21T13:25:16.084777 packet(b'424d0afb093003b8012e0000e20623c2') header=b'424d' csum=b'23c2' ppm=b'03b8' = 952 ppm co2
2022-08-21T13:25:17.107521 packet(b'424d0afb093003b8012e0000e20623c2') header=b'424d' csum=b'23c2' ppm=b'03b8' = 952 ppm co2
2022-08-21T13:25:18.114331 packet(b'424d0afb093003b8012e0000e20623c2') header=b'424d' csum=b'23c2' ppm=b'03b8' = 952 ppm co2
2022-08-21T13:25:19.121116 packet(b'424d0afb093003b8012e0000e20623c2') header=b'424d' csum=b'23c2' ppm=b'03b8' = 952 ppm co2
2022-08-21T13:25:20.127911 packet(b'424d0aeb092d03c1012e0000e20623b8') header=b'424d' csum=b'23b8' ppm=b'03c1' = 961 ppm co2
2022-08-21T13:25:21.134689 packet(b'424d0aeb092d046c012e0000e2062364') header=b'424d' csum=b'2364' ppm=b'046c' = 1132 ppm co2
2022-08-21T13:25:22.141476 packet(b'424d0aeb092d046c012e0000e2062364') header=b'424d' csum=b'2364' ppm=b'046c' = 1132 ppm co2
2022-08-21T13:25:23.148319 packet(b'424d0ada092504de012e0000e20623bd') header=b'424d' csum=b'23bd' ppm=b'04de' = 1246 ppm co2
2022-08-21T13:25:24.171109 packet(b'424d0ada092504de012e0000e20623bd') header=b'424d' csum=b'23bd' ppm=b'04de' = 1246 ppm co2
2022-08-21T13:25:25.177861 packet(b'424d0ada092504de012e0000e20623bd') header=b'424d' csum=b'23bd' ppm=b'04de' = 1246 ppm co2
2022-08-21T13:25:26.184629 packet(b'424d0ac30924057d012e0000e2062345') header=b'424d' csum=b'2345' ppm=b'057d' = 1405 ppm co2
2022-08-21T13:25:27.191431 packet(b'424d0ac30924057d012e0000e2062345') header=b'424d' csum=b'2345' ppm=b'057d' = 1405 ppm co2
2022-08-21T13:25:28.198240 packet(b'424d0ac30924057d012e0000e2062345') header=b'424d' csum=b'2345' ppm=b'057d' = 1405 ppm co2
2022-08-21T13:25:29.205051 packet(b'424d0ab60925061d012e0000e20623da') header=b'424d' csum=b'23da' ppm=b'061d' = 1565 ppm co2
2022-08-21T13:25:30.211891 packet(b'424d0ab60925061d012e0000e20623da') header=b'424d' csum=b'23da' ppm=b'061d' = 1565 ppm co2
2022-08-21T13:25:31.218762 packet(b'424d0ab60925061d012e0000e20623da') header=b'424d' csum=b'23da' ppm=b'061d' = 1565 ppm co2
2022-08-21T13:25:32.241478 packet(b'424d0ab60925061d012e0000e20623da') header=b'424d' csum=b'23da' ppm=b'061d' = 1565 ppm co2
2022-08-21T13:25:33.248238 packet(b'424d0aac092406b6012e0000e2062368') header=b'424d' csum=b'2368' ppm=b'06b6' = 1718 ppm co2
2022-08-21T13:25:34.254979 packet(b'424d0aac092406b6012e0000e2062368') header=b'424d' csum=b'2368' ppm=b'06b6' = 1718 ppm co2
2022-08-21T13:25:35.261803 packet(b'424d0aac092406b6012e0000e2062368') header=b'424d' csum=b'2368' ppm=b'06b6' = 1718 ppm co2
2022-08-21T13:25:36.268576 packet(b'424d0aab09220710012e0000e20623c0') header=b'424d' csum=b'23c0' ppm=b'0710' = 1808 ppm co2
2022-08-21T13:25:37.275443 packet(b'424d0aab09220710012e0000e20623c0') header=b'424d' csum=b'23c0' ppm=b'0710' = 1808 ppm co2
2022-08-21T13:25:38.282322 packet(b'424d0aab09220710012e0000e20623c0') header=b'424d' csum=b'23c0' ppm=b'0710' = 1808 ppm co2
2022-08-21T13:25:39.305054 packet(b'424d0aa909240743012e0000e20623f3') header=b'424d' csum=b'23f3' ppm=b'0743' = 1859 ppm co2
2022-08-21T13:25:40.311911 packet(b'424d0aa909240743012e0000e20623f3') header=b'424d' csum=b'23f3' ppm=b'0743' = 1859 ppm co2
2022-08-21T13:25:41.318726 packet(b'424d0aa909240743012e0000e20623f3') header=b'424d' csum=b'23f3' ppm=b'0743' = 1859 ppm co2
2022-08-21T13:25:42.325456 packet(b'424d0aaa0925074a012e0000e20623fc') header=b'424d' csum=b'23fc' ppm=b'074a' = 1866 ppm co2
2022-08-21T13:25:43.332344 packet(b'424d0aaa0925074a012e0000e20623fc') header=b'424d' csum=b'23fc' ppm=b'074a' = 1866 ppm co2
2022-08-21T13:25:44.339140 packet(b'424d0aaa0925074a012e0000e20623fc') header=b'424d' csum=b'23fc' ppm=b'074a' = 1866 ppm co2
2022-08-21T13:25:45.346040 packet(b'424d0aaa0925074a012e0000e20623fc') header=b'424d' csum=b'23fc' ppm=b'074a' = 1866 ppm co2
2022-08-21T13:25:46.352791 packet(b'424d0aaa0927074e012e0000e2062302') header=b'424d' csum=b'2302' ppm=b'074e' = 1870 ppm co2
2022-08-21T13:25:47.375527 packet(b'424d0aaa0927074e012e0000e2062302') header=b'424d' csum=b'2302' ppm=b'074e' = 1870 ppm co2

Around 10 minutes later the soldering fumes (do they actually contain CO2?) seemed to have dispersed:

2022-08-21T13:33:53.650576 packet(b'424d0b08094003e7012e0000e206230f') header=b'424d' csum=b'230f' ppm=b'03e7' = 999 ppm co2 
2022-08-21T13:33:54.657334 packet(b'424d0b08094003e7012e0000e206230f') header=b'424d' csum=b'230f' ppm=b'03e7' = 999 ppm co2 
2022-08-21T13:33:55.664082 packet(b'424d0b08094003e7012e0000e206230f') header=b'424d' csum=b'230f' ppm=b'03e7' = 999 ppm co2 
2022-08-21T13:33:56.670883 packet(b'424d0b08094003e7012e0000e206230f') header=b'424d' csum=b'230f' ppm=b'03e7' = 999 ppm co2
2022-08-21T13:33:57.677658 packet(b'424d0b08093f03e7012e0000e206230e') header=b'424d' csum=b'230e' ppm=b'03e7' = 999 ppm co2
2022-08-21T13:33:58.700458 packet(b'424d0b08093f03e7012e0000e206230e') header=b'424d' csum=b'230e' ppm=b'03e7' = 999 ppm co2
2022-08-21T13:33:59.707267 packet(b'424d0b08093f03e7012e0000e206230e') header=b'424d' csum=b'230e' ppm=b'03e7' = 999 ppm co2
2022-08-21T13:34:00.713988 packet(b'424d0b08094003e7012e0000e206230f') header=b'424d' csum=b'230f' ppm=b'03e7' = 999 ppm co2
2022-08-21T13:34:01.720828 packet(b'424d0b08094003e7012e0000e206230f') header=b'424d' csum=b'230f' ppm=b'03e7' = 999 ppm co2
2022-08-21T13:34:02.727688 packet(b'424d0b08094003e7012e0000e206230f') header=b'424d' csum=b'230f' ppm=b'03e7' = 999 ppm co2
2022-08-21T13:34:03.734467 packet(b'424d0b08094103e7012e0000e2062310') header=b'424d' csum=b'2310' ppm=b'03e7' = 999 ppm co2
2022-08-21T13:34:04.741267 packet(b'424d0b08094103e7012e0000e2062310') header=b'424d' csum=b'2310' ppm=b'03e7' = 999 ppm co2

I then opened the window with a good draft and it quickly approached the outside CO2 air concentration:

2022-08-21T13:41:47.796995 packet(b'424d0b4e095401a3012e0000e2062323') header=b'424d' csum=b'2323' ppm=b'01a3' = 419 ppm co2 
2022-08-21T13:41:48.803683 packet(b'424d0b4e095401a0012e0000e2062320') header=b'424d' csum=b'2320' ppm=b'01a0' = 416 ppm co2 
2022-08-21T13:41:49.810507 packet(b'424d0b4e095401a0012e0000e2062320') header=b'424d' csum=b'2320' ppm=b'01a0' = 416 ppm co2 
2022-08-21T13:41:50.817180 packet(b'424d0b4e095401a0012e0000e2062320') header=b'424d' csum=b'2320' ppm=b'01a0' = 416 ppm co2 
2022-08-21T13:41:51.823981 packet(b'424d0b4e0954019f012e0000e206231f') header=b'424d' csum=b'231f' ppm=b'019f' = 415 ppm co2 
2022-08-21T13:41:52.846689 packet(b'424d0b4e0954019f012e0000e206231f') header=b'424d' csum=b'231f' ppm=b'019f' = 415 ppm co2 
2022-08-21T13:41:53.853479 packet(b'424d0b4e0954019f012e0000e206231f') header=b'424d' csum=b'231f' ppm=b'019f' = 415 ppm co2 
2022-08-21T13:41:54.860302 packet(b'424d0b4e0954019e012e0000e206231e') header=b'424d' csum=b'231e' ppm=b'019e' = 414 ppm co2 
2022-08-21T13:41:55.867120 packet(b'424d0b4e0954019e012e0000e206231e') header=b'424d' csum=b'231e' ppm=b'019e' = 414 ppm co2 
2022-08-21T13:41:56.873917 packet(b'424d0b4e0954019e012e0000e206231e') header=b'424d' csum=b'231e' ppm=b'019e' = 414 ppm co2 
2022-08-21T13:41:57.880692 packet(b'424d0b4e0954019e012e0000e206231e') header=b'424d' csum=b'231e' ppm=b'019e' = 414 ppm co2

Nice!

Also since I was wondering, usual CO2 levels are:

400 ppm: average outdoor air level.
400–1,000 ppm: typical level found in occupied spaces with good air exchange.
1,000–2,000 ppm: level associated with complaints of drowsiness and poor air.
2,000–5,000 ppm: level associated with headaches, sleepiness, and stagnant, stale, stuffy air.

Source: Wisconsin Department of Health Services

A blog with Eleventy on Codeberg

2022-08-22T00:00:00Z

I was looking for a quick way to write down some project notes. This inevitably led me to Static Site Generators and I especially looked at Netlify CMS and Jekyll. But I didn't want to rely on 3rd party services and CDNs to serve some simple pages with occasional images.

In the end I picked a very simple Eleventy configuration based on https://github.com/11ty/eleventy-base-blog which doesn't include any resources from 3rd parties at all.

Codeberg Caveats

Codeberg's Terms of Service are quite restrictive compared to Github or Gitlab in allowing only free software licensed projects and excluding "stale mirrors" and reserving the right to remove inactive repositories. (Completely understandable if you don't have unlimited resources like Microsoft/Github.) But they explicitly allow "really small & personal stuff like your journal, config files, ideas or notes" even for private repositories so I think this site is covered by that policy.

Using the base template the output files are generated in the _site directory:

// These are all optional (defaults are shown):
dir: {
    input: ".",
    includes: "_includes",
    data: "_data",
    output: "_site",
},

According to codeberg.pages the files are expected to be either in the root directory of the pages repository or in a pages branch of any other repository.

I didn't like the idea of polluting my source repository with generated data so I came up with this solution using a Git submodule:

rm -rf _site
git submodule add git@codeberg.org:spezifisch/pages.git _site
pnpm build

Now all the generated data is located inside another repository which I can purge as I like if it gets too big.

To use this repository conveniently I added a custom script to my package.json:

  "scripts": {
    /* ... */
    "publish": "eleventy && git submodule foreach 'git add . && git commit -am deploy && git push origin main'",
  },

Using pnpm run publish I can now rebuild my site, commit whatever changed and push it to my pages repository so it is immediately publicly accessible.

Update: The command has since gotten a bit more complicated. It would be nice to have a cleaner solution than this.

spezifisches

PSV3 Soldering Iron Hack - Part 2

Soldering Tip #

Heating #

Temperature measurement #

Temperature conversion #

USB supply control #

USB-PD controller #

Microcontroller #

OLED display #

Bad code #

Better code #

Stock Firmware #

Custom Firmware #

Results and further improvements #

Links #

Footnotes #

PSV3 Soldering Iron Hack - Part 1

Intro #

Flashing #

Opening the case #

Connecting SWD #

Outro #

Footnotes #

GT-ACQI-22WO digital alarm clock hack

Display #

Buttons #

Power Supply #

Hardware Modifications #

Display Board Mods #

Power Supply Board Mods #

ESP32 Board #

Software #

Pokemon Go Plus autocatcher DIY

A Short History #

Reverse Engineering #

Software #

Electronics #

ESP32 #

LiPo Charger and Battery #

Supply #

Case #

Assembly #

Govee RGB Strip (H619A) Part 1 - Investigation

Motivation #

Internals #

RGB strip data output #

Side note: Bluetooth SoC #

Side note: WiFi module #

Extracting audio samples from Rave Generator 2 VST plugin

Motivation #

Finding the samples #

The notebook #

pathToBuffer parser #

adjustRootNote parser #

setRootNote analysis #

Conclusion #

CO2 Sensor Reverse Engineering - Part II

Battery Management #

Temperature/Humidity Sensor #

Logging the communication #

The Protocol #

Decoding our logs #

CO2 Sensor Reverse Engineering

Disassembly #

Finding out the CO2 sensor's protocol #

What is it? #

Specs #

Protocol #

Salvaging the CO2 sensor #

A blog with Eleventy on Codeberg

Codeberg Caveats #

Soldering Tip

Heating

Temperature measurement

Temperature conversion

USB supply control

USB-PD controller

Microcontroller

OLED display

Bad code

Better code

Stock Firmware

Custom Firmware

Results and further improvements

Links

Footnotes

Intro

Flashing

Opening the case

Connecting SWD

Outro

Footnotes

Display

Buttons

Power Supply

Hardware Modifications

Display Board Mods

Power Supply Board Mods

ESP32 Board

Software

A Short History

Reverse Engineering

Software

Electronics

ESP32

LiPo Charger and Battery

Supply

Case

Assembly

Motivation

Internals

RGB strip data output

Side note: Bluetooth SoC

Side note: WiFi module

Motivation

Finding the samples

The notebook

pathToBuffer parser

adjustRootNote parser

setRootNote analysis

Conclusion

Battery Management

Temperature/Humidity Sensor

Logging the communication

The Protocol

Decoding our logs

Disassembly

Finding out the CO2 sensor's protocol

What is it?

Specs

Protocol

Salvaging the CO2 sensor

Codeberg Caveats