Abstracts

New CV

Sun, 12 Oct 2025 20:55:49 +0300

I didn’t update my CV for quite some time. And somehow I lost the LaTeX source code on some of the previous computers. That’s a pity of course, but also a perfect opportunity to improve both the content and the design. I still wanted concise and well structured presentation, simple and pleasant design, original and maintainable implementation. Therefore I kept LaTeX, despite considering the aspiring typst.

The amount of information that I’d like to present, is constantly growing. So I have to prioritize what’s to be included and what’s less relevant or impressive. To improve the density, the text is typeset in two columns. The font is better to be changed to Noto Sans. At least it’s more accurately printed on my laser printer.

The same source file can be used to produce both English and Ukrainian PDF. Indeed, CV isn’t a free-form text, rather a listing of short phrases and abbreviations. I suppose it’s worth maintaining both translations in one place.

I’ve gone an extra mile to preserve the source code this time. First of all, there’s the repository: CV. Second, it’s convenient to attach the source files to the PDF itself. It can be retrieved later in some viewers or using CLI programs like pdfdetach:

sakhnik@vivo ~/w/sakhnik.com (master) [1]> pdfdetach -list assets/sakhnik.pdf 
2 embedded files
1: Makefile
2: sakhnik.tex
sakhnik@vivo ~/w/sakhnik.com (master) [1]> pdfdetach -saveall assets/sakhnik.pdf
sakhnik@vivo ~/w/sakhnik.com (master) [1]> ls -l sakhnik.tex Makefile
-rw-r--r-- 1 sakhnik sakhnik  172 oct 12 21:16 Makefile
-rw-r--r-- 1 sakhnik sakhnik 9131 oct 12 21:16 sakhnik.tex

It is still possible to compile the CV with texlive.net web API. I’ve committed and updated script to the repository.

The actual CV will be always available on the About page. Here is today’s version:

Hello Meshtastic

Sat, 26 Apr 2025 16:18:34 +0300

A couple of weeks ago, my 9-year daughter got lost in a forest during an orienteering training session. It happens sometimes, and children are assumed to follow the predefined algorithm to return to the base. But something was off this time: she didn’t take a compass or a phone with her. Neither could I locate her following the planned route. Luckily, she was able to focus and return by herself, although a tired more than usual. So there came an idea to me. An electronic tracker could help locate younger students and spare our rescuing efforts. Quick research showed that there are different options for a ‘GPS Tracker’.

Here are my requirements:

GPS/GNSS receiver for precise geolocation
LoRa radio for telemetry
Basic screen with directions to other nodes relative to the north, sun or moon
Battery power for ~10 hour autonomy.
Affordable cost

Of course, a smartphone is a viable option, despite it’s impractical to carry on a training course, and the cellular service isn’t everywhere available in the forests. So a purposed gadget, designed to be carried as a necklace would be much more preferable.

My choice is Heltec Wireless Tracker, which costs ~20$. I figured out how to draw shapes and print text on the display, how to receive geolocation coordinates, how to transmit and receive through the LoRa radio. But then I realized that there’s no need to develop my own system because Meshtastic already offers everything I need. It’s a communication system primarily, but it allows sharing and displaying precise location of the neighbour nodes on the map in a private channel. It already has mobile app, a convenient infrastructure for maintenance and support.

So the only thing left for me was to order and package some 2000 mAh LiPo battery and create an enclosure. I did it with OpenSCAD this time: repo. The total cost turned out to be ~1000 ₴.

Meshtastic is an open source project, so it can be customized for our use case. For example, to display the direction to the sun and the moon to help navigation when the compass isn’t available.

References:

Meshtastic in Ukraine
Meshtastic pet tracker — similar story and application

Liberating Tuya WiFi plug

Fri, 12 Jul 2024 17:32:53 +0300

I use Home Assistant nowadays to manage electric equipment at home. This is a remarkable leap forward since my first automation attempts last year. I’ve been using ESPHome as custom firmware for Sonoff S26 plugs, which are based on ubiquitous microcontroller ESP8266. But now it’s easier to find cheaper Tuya 20A smart sockets for as low as 150₴ (under 4$) a piece. They are even equipped with power meter. But the challenge is that they use LibreTiny chip BK7231N. Here’s what I learnt do.

First of all, I tried tuya-couldcutter. While it could potentially help with my Aubess 20A plug, it failed with my specific version. Probably, Tuya patched the vulnerability. So I have to open the case to attach a serial programmator.

To do that without destroying it is a challenge. Unlike Sonoff, these plugs don’t have any screws. Parts of the case are glued and the glue can be broken by applying pressure gradually to deform the case slightly. Some people use clamps. I succeeded using entrance door as a leverage.

The pins of the board C2BS (datasheet) are easy to identify. I use IC clamps from AliExpress to attach the programmator.

ESPHome configuration could be bootstraped using an online tool UPK2ESPHome. And finally, to install the firmware, it’s enough to run esphome run tuya-1.yml. Conveniently, it suggests how to connect the programmator, and how to reset the microcontroller while the flasher waits for connection (grounding the pin CEN). It could take a couple of attempts because of unstable connections but succeeded eventually.

Now beyond of obvious use of smart switches with Home Assistant, there are a couple of unexpected opportunities. First of all, this is an embedded software platform in an elegant case, connected to WiFi network and conveniently powered from a standard AC socket. Second, BK7231N is capable of BLE communications. So potentially, esphome-jk-bms could be ported from ESP32 to create a cheap and convenient battery monitor.

This day in photo gallery

Sun, 27 Aug 2023 08:20:01 +0300

Some time ago, I ditched Google Photos in favour of pigallery2. See, how I expose Shotwell media gallery. Yet one feature was still left to be wished for. Google prepares appealing summaries periodically: what happened this day three-five years ago. And it shouldn’t be too complicated in GNOME Shotwell, I thought. Just go and select random photos from the database based on the date. Here’s how this idea was implemented.

First of all, I researched pigallery2 features and discovered that it can render markdown files. So if I generated one and put into a directory, it’d be served alongside the photos from the same domain. This simplifies referencing full-resolution photos a lot.

Then I spent some time coding in Python. The program would iterate over years into the past until, let’s say, the year 2000. For every year, a random set of photos are selected for the current day, ordered by time, grouped by event. And the links to the chosen photos with thumbnail previews are carefully laid out into a markdown file. The code has been kept in a local Fossil SCM repository, and this time I exported it to GitHub for publicity: daily.py

Finally, a systemd timer (or a cron job) could be used to run the program each day early in the morning. Here’s how I did it: systemd.

There’s more that could be enhanced in the future:

Notes could be extracted from the Shotwell database and rendered as markdown files for pigallery2
It should be researched how to attach generic files like GPX tracks to the events in Shotwell.

As usual, here’s an illustration:

Reserve power

Sun, 07 May 2023 15:00:39 +0300

This is the story of how I spent the winter building reserve power sources to deal with blackouts. When the Russians began to interfere with our power grid, we started experiencing load shedding. This became a major inconvenience for our work, our children’s studies, and our daily lives. I talked to a friend, who advised me to use a hybrid solar inverter with a lithium-ion accumulator to store energy when it’s available and then recuperate it during power outages.

Switching

I purchased a couple of hybrid inverters on AliExpress and waited about a month for them to arrive. When they finally came, I was visiting my parents and had to look into the switching panel to figure out how to connect the wires correctly. There were a couple of different layouts with different inputs (single-phase, three-phase), available space, and requirements. I did four installations in total, all very different. But here is the summary of my experience:

This circuit appears to be the most flexible in the required scenarios:

The grid is online and can power the house including the accumulator charging
The grid is semi-functional, some phases are missing, yet the house could be powered by one phase
The grid is off-line, a gasoline generator is used to power the house and store the excessive energy
The generator is shut down, and the inverter is powering the house using the stored energy.

Possible combinations

The first switch is a three-pole reserve selection I-0-II. When it’s in position I, the house is connected to the grid directly. When it’s in position II, the house is connected to the reserve power source: generator, inverter output or even a single selected phase.

The second switch is a single-pole selection I-0-II, which can be used to take the power directly from the selector, or from the inverter output.

The selector is a rotary phase selection plus reserve I-0-II-0-III-0-IV-0. It allows selecting one phase from the grid or generator output.

So there are multiple use cases of the circuit, but let’s consider the most common ones.

Case 1: power grid is online

This is the normal state when cheap and powerful electricity from the grid is available. The current flows like before my intervention into the panel. It’ll allow charging the battery by selecting one of the phases and switching on the supply to the inverter input.

Case 2: some phases are missing

In case there’s some failure in the grid resulting in at least one phase available, the house could still be powered from the grid. This is suitable if the load is moderate because of multiple reasons. But yet, just one switch and a selector notch away from powering the whole house instead of just a part of the house.

Case 3: generator working, but the inverter is bypassing the power

Although it’s possible to use the gasoline generator directly, it’s more efficient to store the excess energy into the battery. The reason is that the internal combustion engine isn’t very scalable, and a significant portion of the fuel is required to just idle it. Adding more load, of course, will increase fuel consumption, but not necessarily proportionally. Moreover, the generator requires downtime maintenance: either to just refuel it or to change the oil and clean the filters.

Case 4: no external power, the inverter works off the battery

So this is the last resort when nothing else works: no grid, no generator. The inverter doesn’t produce much noise, except for the cooling fans kicking in depending on the actual load. The limitation here is the capacity of the battery. 120 Ah is more than enough to last for a couple of hours for powering lights, communication, and pumping water occasionally.

Showcase

Parent’s house

The house is powered by a single phase from the grid. A DC circuit breaker and Anderson power plug were added later.

Parent-in-law’s house

Three-phase supply from the grid. Led batteries were used this time because they require less maintenance than lithium ones, and the grid electricity was more available at the time. This was the first three-phase connection and an additional box was needed to host the switches and the selector.

Our apartment in Kyiv

This one is a one-phase supply. The space was very limited, but still enough to add two components.

Cottage house

This time I enjoyed the benefit of available cable from the switcher panel to the utility room. The electric heater hasn’t been used and is unlikely to be utilized in the future. So I just repurposed the wires.

Portable power source

After two installations, just one inverter was left for two different places. And I realized at this point, that it’s possible to reuse both the inverter and the battery making them portable. Indeed, it only required four wires to connect the inverter: AC in, AC out, neutral and protective equipment (earthing). I chose an off-the-shelf 16A 4-wire plug assigning pins in the following way:

Pin	Wire colour	Assignment
PE	█ blue	Neutral
1	█ black	AC in
2	█ yellow	PE
3	█ red	AC out

Not only can the inverter be connected to a house via such a plug, but also an extension cable could be prepared. Now the inverter could power some equipment outdoors for some time with the charge in the battery, and even allow recharging the battery from a generator.

Issues

Special care should be taken of the generator connection. Usually, generators for F-type plugs allow connecting the load either way N-L or L-N. And this doesn’t matter for appliances. But in our case, it’s essential to match neutral and line with the switching circuit. I haven’t looked into what would happen in the case of an incorrect connection. My mitigation plan so far was to use asymmetric type F plugs, and double checking the line status with a one-contact test light or non-contact voltage detector.

Enter IOT

Sun, 01 Jan 2023 10:56:28 +0200

Here is one simple and cheap way to automate electric boiler activation. There are lots of “smart power plug” available on OLX. Especially the ones from tuya. For example, I was able to purchase one for 300 ₴ (~$8). It came without any written instruction or even an identification. However, there are lots of guides and manuals on the web, and it was a matter of error and trial to get it creating a WiFi hotspot. Then after connecting to it, the Android application Smart Life can be used to configure plug’s connection to the LAN WiFi. That’s just enough to start manually controlling the plug like turning it on and off on schedule.

Now imagine I’d like to do something that’s not a stock functionality. For example, when the power is cut for some load shedding, and comes back a bit later, I’d like to make sure the water boiler stays switched off for extra minutes before turning on. This would allow the grid to ramp up the power supply without causing immediate overload. An incentive for custom automation!

I took the first Python library that popped in the search: tinytuya. It has detailed instructions on how to register as a developer, discover the device id and get the necessary key to control the device. I ended up customizing one of the examples to ensuring the switch is on:

#!/usr/bin/env python

import tinytuya, time

while True:
    try:
        d = tinytuya.OutletDevice(dev_id="<id>", address="<addr>", local_key="<key>", version=3.3)
        status = d.status()
        if status['dps']['1']:
            break
        print("Turn on")
        d.turn_on()
        time.sleep(60)
    except Exception as e:
        print(f"Exception {e}")
        time.sleep(10)

The script then is wrapped into a systemd service:

[Unit]
Description=Boiler power on
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=sakhnik
Group=users
ExecStart=/usr/bin/python /home/sakhnik/work/boiler/boiler.py
StandardOutput=journal

[Install]   
WantedBy=default.target

The service should be started by a timer:

[Unit]
Description=Start boiler deferred after boot

[Timer]
OnBootSec=15min

[Install]
WantedBy=timers.target

And the timer needs to be enabled:

systemctl daemon-reload
systemctl enable boiler.timer

Now, the switch relay can be configured to start in the switched off state after powering up in the Smart Life app. When the power is restored, the switch is initially off and the computer is booting up. After 15 minutes, the timer kicks off the boiler service running the program, which turns the switch on. It’s a one-time action, so one can continue managing the switch manually.

There are disadvantages in this system too. For example, the privacy. Although, there’s very little harm that can be done, I don’t particularly like to share my internal network layout with Tuya. I’d rather prefer to have a direct access to the plug without engaging complex external servers. I’ve just heard that this might be possible with some other smart plug producers. Looking forward to explore.

Fixing video/audio synchronization in a downloaded material

Mon, 21 Nov 2022 17:04:33 +0200

As we’ve started to be impacted by the power blackouts, we resorted to downloading videos whenever possible to watch them later when convenient. The browser addon Video DownloadHelper hits right the spot for that. But it turns out that the video frame rate may be rogue in some cases. There can be a ridiculous number as high as 16k fps. My solution is to transcode the file forcing the frame rate to the desired value, which is actually detected correctly by the addon on the web page. In our case it was 30 FPS. Here’s the bash script invoking FFmpeg three times to extract audio and video tracks, and multiplex them back into an mp4 container:

#!/bin/bash -e

if [[ $# -lt 1 ]]; then exit 1; fi

fname=$1

extract_video() {
  ffmpeg -loglevel error -i $fname -map 0:v -c:v copy -bsf:v h264_mp4toannexb -f h264 -
}

extract_audio() {
  ffmpeg -loglevel error -i $fname -vn -acodec copy -f adts -
}

ffmpeg -fflags +genpts -r 30 \
  -i <(extract_video) \
  -i <(extract_audio) \
  -map 0:v -c:v copy -map 1:a -movflags faststart $fname-fixed.mp4

Anonymous pipes are used here to pass the video and audio streams into the multiplexing command.

Compiling LaTeX documents on texlive.net

Tue, 23 Aug 2022 20:56:15 +0300

I’ve just realized that I’m not ready to install a multi-gigabyte TexLive distribution in the 32 GB file system of my Chromebook-based laptop. And I need to update the CV sometimes. Luckily, there’s a web service available exactly for that: texlive.net. It turned out capable of rendering my resume using XeLaTeX via their test web page, but it didn’t work immediately when I tried using their API directly. Here’s how I did that eventually.

According to their documentation, the parameters need to be sent in an HTTP POST multipart/form-data request. It’s convenient to employ curl to do the job. And it worked on simple test documents. But when I tried with the real CV, the compilation failed consistently while using the package hyperref. Comparison of the Firefox network capture with curl --trace-ascii revealed that the test web page sends bigger Content-Length for practically the same parameter set. Aha! The service must be sensitive to the line endings format. It expects \r\n for some reason, and my file was authored using Unix convention with just \n.

So there’s my script to note:

#!/bin/bash -e

# Compile xelatex document using the API of https://texlive.net

name="$1"
texlive="https://texlive.net"

# The compilation will fail if the document doesn't use DOS line endings CRLF
headers=$(curl -s -i \
    -F "filecontents[]=@${name}" \
    -F "filename[]=document.tex" \
    -F "engine=xelatex" \
    -F "return=pdf" \
    ${texlive}/cgi-bin/latexcgi)

location=$(echo "$headers" | grep -Po '(?<=Location: )(/latexcgi/.*?)(?=\r)')

if [[ "$location" == *.pdf ]]; then
    curl -s -Lo ${name/.tex/.pdf} ${texlive}${location}
else
    curl -s -L ${texlive}${location} >&2
    exit 1
fi

nvim-ui progress

Sun, 24 Jul 2022 22:39:11 +0300

A year and a half passed since I set off to create a simple Neovim UI in C++ in my spare time. The project nvim-ui became an exciting journey with quite a bit of discovery, experience and notable conclusions to share.

SpyUI in nvim-gdb

First of all, the idea emerged when SpyUI was implemented to support maintenance of my Neovim plugin nvim-gdb. SpyUI would allow just mirroring and capturing the UI progression during automatic tests or actual use cases to simplify bug hunting. Not surprisingly, Neovim itself actively uses a UI client for automatic testing. The script was embarrassingly simple suggesting that a full-fledged UI shouldn’t be too difficult either.

+----------------------------------------+
|                                        |
|~                                       |
|~                                       |
|~                                       |
|[No Name]             0,0-1          All|
|/src/test.cpp:17                        |
|/tmp/nvim-gdb/test/src/test.cpp:17:190:b|
|eg:0x5555555551e6                       |
|(gdb)                                   |
|<port -- gdb -q a.out 21,1           Bot|
|                                        |
|"/tmp/nvim-gdb/test/src/test.cpp"       |
+----------------------------------------+

The essential summary of the SpyUI was the data model that Neovim maintains to share the UI state. The grid is a matrix of text cells with their highlighting ID associated: [[(text, hl_id)] * width] * height. So the first idea is to assemble the grid matrix based on the Neovim messages, and process it further for the best appearance and performance. For instance, concatenate the adjacent cells with the same hl_id into words, and skip the invisible spaces at all: [[(stride, word, hl_id)]] * height.

nvim-ui in SDL2

So the first attempt was with SDL2. Surely, it’d allow achieving superb performance by with hardware acceleration! Pango and Cairo from the GNOME stack were used to render the text into bitmaps, and the bitmaps were transformed into textures. The prepared textures could be reused multiple times if that specific piece of text didn’t change. One more way to relieve the CPU usage was throttling of grid flushes. Really, there’s no need to do rendering more frequently than 25 FPS.

It worked decently so the version 0.0.1 was released just to get things started. Then soon the version 0.0.2 followed with a couple of bugs fixed, a bit of development infrastructure automatated.

But there was also a significant drawback discovered (issue #20). Let’s call it texture noise. And I couldn’t find any way to fix it. Apparently, it’s attributed to the GPU rendering.

Porting to GTK 4

After a bit of research, I decided to try using GTK 4 directly. That’s because Pango and Cairo are already part of GTK, first of all. Then GTK would also allow using ready widgets for configuration dialogs, for instance, for font selection. And a lot more. But what’s most important, the toolkit recommends using stock widgets for all the custom drawing whenever possible. That means that what was a “texture” in SDL2 could now easily be implemented as a GTK label! Moreover, all the styling could be conveniently done using CSS, leaving behind very low level coding.

This is the time when the application got the menu, and the ability to connect to a remote Neovim instance. The performance was OK, except when there was a lot of little labels to be created at once. For example, when getting a listing of digraphs with :digraphs, around 1,500 labels would be created and placed on the grid on every PgUp/PgDn. This caused a noticeable delay of 0.3 seconds.

Enter Gir2cpp

That version wasn’t released immediately because I realized that GTK’s C API is a bit cumbersome and unpleasant. For example, one should know in beforehand that the class GtkEntry implements the interface Editable:

auto t = gtk_editable_get_text(GTK_EDITABLE(entry));

instead of the conventional

auto t = entry.get_text();

Bringing in gtkmm seemed an overkill for just a handful of widgets I was intending to use. But one idea seemed particularly appealing: cppgir uses GObject introspection to generate C++ wrappers. Unfortunately, I failed to build the code with it properly. It didn’t seem too complicated to create an custom ad-hoc generator of C++ wrappers for GObject-based libraries. So there’s another auxiliary side project that could potentially has it’s own application: gir2cpp.

It’s just a Python library that needs to be properly configured with the white and black list of desired symbols to be wrapped in C++. Unfortunately, I wasn’t able to find a way to seamlessly integrate it into the Meson build system. Perhaps because it actually isn’t known what exactly files are going to be generated given the required configuration. So it’s utilized as a preconfiguration step before the Meson build system is invoked: prepare-gtkpp.sh.

However quick and dirty the approach is, the code improved significantly:

Texture t{row, Gtk::Label::new_("").g_obj()};
t.label.set_markup(text.c_str());
t.label.set_sensitive(false);
t.label.set_can_focus(false);
t.label.set_focus_on_click(false);
t.label.get_style_context().add_provider(_css_provider.get(), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
_grid.put(t.label, 0, y);

Dealing with the performance issues

Fine-grained labels/textures are perfect to minimize the redrawing work, but display a couple of significant drawbacks. The most annoying one is that there can be lots of labels to update when listing messages (see :digraphs). Another one is the horizontal alignment of separate textures, especially thin vertical lines in the adjacent lines in telescope.

So I tried to simplify the renderer to create only one big label for one grid row. This makes the data model a bit more complex, but simplifies the code a lot: [[(text, hl_id)] * cols] * rows → [[(word, hl_id)]] * rows. Specifically, the text layout is now done using Pango markup. This turned out to be a great idea for both the UI appearance and responsiveness and code maintainability.

Perspective

So here we are after 1.5 years of experimentation. There’s an ongoing project, a Neovim UI with the following features:

Simplicity of the idea and C++ implementation
Decent appearance and performance
Solid foundation for implementing more features
A good sandbox for further experiments.

To be continued.

Record and replay debugging

Fri, 08 Jul 2022 17:49:31 +0300

It was a year ago in a nvim-gdb issue #151 that I discovered rr. It promised to allow recording a program execution once, and debugging that run multiple times exactly the same way. Finally, there turned up an occasion to try it in the real life, and to implement the suggestion in the issue.

The task at hand was to investigate how FFmpeg calculates the video frames presentation timestamps for some compressed video stream. That’s what can be seen by executing ffprobe:

ffprobe -loglevel -8 -i test.mp4 -select_streams v -show_entries packet=pts | grep pts | head
pts=1
pts=4
pts=2
pts=3
pts=7
pts=5
pts=6

It looks like the sequence of frames is I-P-B-B-P-B-B etc. It makes perfect sense. But where does the number 1 for the first frame come from? It can be traced by following the memory assignment backward in the history. So let’s record the execution of ffprobe:

$ rr record ffprobe -loglevel -8 -i stream.mpd -select_streams v -show_entries packet=pts                
rr: Saving execution to trace directory `/home/sakhnik/.local/share/rr/ffprobe-4'.
[PACKET]
pts=1
[/PACKET]
[PACKET]
pts=3
[/PACKET]
[PACKET]
pts=2
[/PACKET]

Then the debugging can be started by just typing rr replay. But it’s worth doing that in nvim-gdb to enable proper code navigation and highlighting. There’s a demo of how I did it: