Month: April 2026

Project 0003: SDG2042X GUI v0.2.* — first patch round and bug tracker setup

The current work on my Linux GUI for the Siglent SDG2042X is about findig bugs before piling more features on top.

Version 0.1 already did the basics: Waveform control, burst and sweep settings, ARB handling, presets, a small SCPI console, and screenshot support. But no software without bugs. So besides the first code fixes, I also set up a proper issue tracker for the project in Gitea (this was also a point in my gitea learning 2Do List). The repository now has labels, issue templates, a small board workflow, and the first full review list entered as issues. For this first round, I started with the items that looked most worth fixing immediately: #1, #2, & #12. I also did #6 as it was a little bit annoing thing.

The code side for those is already done in v0.2 in this git. What is still open is real verification against the actual SDG hardware before I close them.

Current issue list

Find this in the Gitea: https://gitea.togo-lab.io/tgohle/0003-SDG2042X-PyQt-GUI-for-Linux/issues

Status of the project is now (18.04.2026):

I wrote and ran a small test script for issues #1, #2, #6, and #12, plus a final hardware check on the SDG itself: https://gitea.togo-lab.io/tgohle/0003-SDG2042X-PyQt-GUI-for-Linux/src/branch/master/script/archive/V0.2 That gives me enough confidence to close all four issues and move this first bug-fix round a step further toward done.

  • bug tracker is set up in Gitea, including milestone for v0.2
  • the full first review list is in the tracker
  • the first four fixes (1,2,6 & 12) are already coded and l loaded up to this git
  • tested with script, passed.
  • hardware verification for issue 2 done

Not exciting, but necessary: the tedious grind of bugfix work, so the front end becomes handy enough that it does not get in the way of my other hobby projects.

Further bug and issue work will only tracked in the issue tracker.

Update 20.04.2026 Bug-fix round for the SDG2042X Linux GUI

A productive bug-fix day on the SDG2042X GUI for Linux.
The focus was on medium-severity issues around ARB handling, sweep robustness, preset handling, and input validation.

  • #15 — ARB download response parser fails on real SDG
  • #10 — Sweep fallback from WAV to SPAC is timing-fragile
  • #9 — Preset recall ignores current channel selection
  • #8 — Preset file path selection is not propagated back to Main
  • #3 — human_to_eng() silently accepts ambiguous m suffix

Details in the closed section of the gitea: https://gitea.togo-lab.io/tgohle/0003-SDG2042X-PyQt-GUI-for-Linux/issues?type=all&state=closed

Version progression during this round

  • v0.2.1 → Bug #15
  • v0.2.2 → Bug #10
  • later working copy → Bug #9 and Bug #8
  • v0.2.6 → Bug #3

Summary

This round cleaned up several of the more annoying reliability and usability problems in the GUI: better ARB handling on real hardware, safer sweep fallback, more reliable preset behaviour, and stricter input validation where silent misinterpretation would be risky. Overall, a good step toward making the GUI more dependable as an actual bench tool instead of just a nice front-end.

Setting up Nordic’s Power Profiler Kit II (Linux)

For some of the next TōGō-Lab projects I’m thinking about, I want some gear that lets me look properly into the very low-power usage of my builds instead of just guessing. Besides some more expensive gear like the Joulescope, I finally bought Nordic’s Power Profiler Kit II, which looked like a very good fit for the kind of measurements I want to do. Nordic positions the PPK2 as a standalone power-measurement and power-optimization tool for embedded hardware, with support for real-time current measurements and use with both Nordic boards and external hardware.

As typical for some lab gear, it runs nicely under Windows, in my case in a virtual Win10 setup. But I wanted it on my actual Linux workbench machine, where the rest of the lab IT frontend for my tools lives. That part was a bit more difficult than expected. Nordic gives you an AppImage, but it is a little bit tricky to get it running.

Because the blog will malformat the command lines find the installation lab notes as markdown file in my Gitea as project #0006:
https://gitea.togo-lab.io/tgohle/0006-Setting_up_Nordic_PowerProfilerKitII_Linux

For the official side, Nordic’s product page for the kit is here, the official PPK2 setup documentation is here, and the official nRF Connect for Desktop installation documentation is linked here.

Nordic Power Profiler Kit II Test Setup
Nordic Power Profiler Kit II Test Setup
nRF Connect for Desktop v5.2.1
nRF Connect for Desktop v5.2.1

Test Measurement:

nRF Connect Power Profiler App, working Measurement
nRF Connect Power Profiler App, working Measurement

電力番長 Denryoku Banchō – a MightyWatt Linux CLI

Since I’m currently in the process of redesigning and updating the setup of my electronics lab, I no longer want to keep Windows around just to run my electronic load I own now for 10 years: The famous MightyWatt.

So this fork moves the project where it fits better to my actual lab setup: Into my Linux environment, closer to my usual tools, and I hope much easier to automate. The current focus is the CLI backend. That is the useful part for headless operation, scripting, CSV logging, JSON-driven test runs, and remote access. A GUI may come later, but only as a second layer. First the engine, then maybe the dashboard. The name 電力番長 (Denryoku Banchō) fits that idea well: the CLI sits on the hardware, owns the usb link, and acts as the boss in the background.

But first: A big thank you is due to the original MightyWatt developer, Jakub Polonský (kaktus85) whose MightyWatt repositories remain the foundation this work builds on. The original GitHub project pages are here: MightyWatt (that’s the one I own) and MightyWatt R3.

My Linux-native fork lives here: 0005-DenryokuBancho on ToGo-Lab Gitea which you also can access it via one of my landing pages.

This blog post will be updated as the project progresses. Beta 0.1 is now available in my Gitea repository. It is already running, but it still needs proper testing in the next stages of the project.