Tag: Linux

電力番長 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.

Post-Mortem: Antivirus Integration on a 1 GB Nextcloud VPS (failed due load)

Failing Experiments Are Useful

Today I tried to push my togo-lab.io setup (see 2nd block at my landing page for all services) a bit further than strictly necessary. So maybe you noticed some outages.

Why I did this? Not only for production security reasons, but also out of curiosity: How far can I go with limited resources? I want to understand where the real limits for my setup are.

In this experiment, I wanted to see whether a single small VPS could reasonably host Nextcloud, a Matrix server, and Gitea, and still handle antivirus scanning for file uploads. At first glance it looked tight, but maybe possible. In practice, it pushed this small VPS over the edge.

That outcome was useful for my learning and understanding. When things fail or become unstable, I usually learn much more than when everything works smoothly. As a technician, breaking things on purpose for learning is, for me, typically the fastest way to understand them.

The following section is a post-mortem of that experiment: what it revealed, what I learned from it, and what would be required if I want to add antivirus scanning in the future.

Context:
This server hosts multiple self-managed services on a small VPS (1 GB RAM, 1 vCPU):

  • Nextcloud (primary collaboration platform)
  • Matrix server
  • Gitea
  • Supporting stack (PHP-FPM, MariaDB, Redis, Apache/Nginx, Fail2Ban)

The goal was to add antivirus scanning for uploaded files in Nextcloud, as preparation for future collaborative use.

Initial Goal

Enable server-side antivirus scanning for Nextcloud uploads using ClamAV, with the following constraints:

  • Lightweight
  • Automated
  • No interactive maintenance
  • Suitable for a self-hosted environment

This is a reasonable baseline requirement once multiple external contributors are involved.

Attempted Approaches

1. ClamAV Daemon (clamd) + Nextcloud (Socket Mode)

What was tried

  • Installed ClamAV daemon

  • Tuned clamd.conf aggressively (single thread, reduced parsers, size limits)

  • Added strict systemd memory limits

  • Disabled background scans

  • Socket-based integration with Nextcloud

  • **changes to the default /etc/clamav/clamd.conf

          # === VPS-safe limits ===
      MaxThreads 1
      ConcurrentDatabaseReload no

      # File size limits (Nextcloud uploads)
      MaxFileSize 50M
      MaxScanSize 75M
      StreamMaxLength 75M

      # Archive / recursion limits
      MaxRecursion 10
      MaxFiles 5000

      # Timeouts
      ReadTimeout 120
      CommandReadTimeout 120

      # Disable low-value / memory-heavy scanners
      ScanHTML false
      ScanMail false
      ScanSWF false
      ScanHWP3 false
      ScanXMLDOCS false

      # Reduce bytecode impact
      Bytecode true
      BytecodeTimeout 20000

      # Reduce RAM further (Nextcloud upload use-case)
      PhishingSignatures false
      PhishingScanURLs false
      DisableCache true
      ExtendedDetectionInfo false

  • best I got, via free -h

total used free shared buff/cache available
Mem: 960Mi 926Mi 68Mi 31Mi 101Mi 33Mi
Swap: 1.0Gi 843Mi 180Mi – – – 
    $ swapon --show
    NAME      TYPE  SIZE   USED PRIO
    /swapfile file 1024M 848.5M   -2`

Observed behavior

  • clamd resident memory usage: ~500–600 MB
  • Heavy swap usage even after tuning
  • Periodic stalls, SSH lag, partial service unresponsiveness
  • OOM kills during database reload or startup

Conclusion Even heavily tuned, resident ClamAV is not viable on a 1 GB VPS that already runs multiple services.

2. ClamAV Executable Mode (clamscan on upload)

What was tried

  • Disabled clamd entirely
  • Used Nextcloud Antivirus for Files app in Executable mode
  • Scanning only on upload
  • Strict size limits
  • No background scans

FYI Final authoritative configuration in NextCloud App “Antivirus for Files”

  • Mode: ClamAV Executable
  • Path to clamscan: /usr/bin/clamscan
  • Extra command line options (comma-separated): --no-summary,--infected,--max-filesize=50M,--max-scansize=75M
  • Stream Length: 104857600
  • Block uploads when scanner is not reachable: Yes
  • Block unscannable files: No
  • Background scans: effectively off (unchecked)

Observed behavior

  • Technically functional
  • No permanent memory footprint
  • However:
    • Uploads caused noticeable CPU + IO spikes
    • PHP-FPM workers stalled under load
    • Combined service activity still led to instability

Conclusion Even non-resident scanning adds too much peak load for this VPS when combined with:

  • Nextcloud
  • Matrix
  • Gitea
  • Database and cache services

Final Decision

Antivirus disabled (for now)

The Nextcloud Antivirus app is currently disabled.

Reasons:

  • System stability has higher priority than partial security measures
  • Trusted users only
  • Strict file permissions
  • Regular backups
  • No public upload endpoints

After disabling AV and rebooting:

  • System became stable
  • Swap usage normalized
  • All services responsive:
    • Nextcloud
    • Matrix
    • Gitea

Post-Mortem Summary

Item Result
Configuration error ❌ No
ClamAV bug ❌ No
Nextcloud bug ❌ No
VPS resource limit ✅ Yes
Wrong architecture ✅ Yes (for this size)

Meaning:

  • This was not a misconfiguration.
  • It was a capacity mismatch.

Lessons Learned

  1. 1 GB VPS is already at the limit for:

    • Nextcloud
    • Matrix
    • Gitea
      combined.

  2. Antivirus scanning is loadwise not “free”, even in executable mode.

  3. Security features that trigger CPU + IO spikes must be sized for worst-case concurrency, not idle averages.

  4. Adding AV without increasing resources creates negative security by destabilizing the system.

When Antivirus Will Be Re-Enabled

Antivirus scanning will be mandatory once this instance is used for real group collaboration.

That will require one of the following options:

Option A — VPS Upgrade (actual preferred)
  • Upgrade to ≥ 2 GB RAM
  • Re-enable ClamAV (daemon or executable mode)
  • Keep all services on one host
Option B — Service Split
  • VPS 1: Nextcloud
  • VPS 2: Matrix + Gitea
  • Antivirus enabled only on Nextcloud host

Current Security Posture (Interim)

  • If, than only trusted users
  • No public upload endpoints
  • Strict permissions
  • Fail2Ban + firewall
  • Frequent backups
  • Fast restore tested

This is acceptable temporarily, but not a final state.

Closing Notes

This experiment was intentional and valuable, learned a lot, also during configuration and tuning.

It clarified:

  • the real resource cost of antivirus scanning
  • the practical limits of small VPS setups
  • and the architectural decisions required for future growth

When collaboration expands, the infrastructure will be expanded accordingly. So clamav and configuration stays, but Nextcloud App is disabled for now, but not uninstalled.

Controlling my Siglent SDG2042X from Linux

As part of rebuilding my electronics test bench for future projects at ToGo-Lab, I wanted a simple way to control my Siglent SDG2042X remotely from my Ubuntu box. So I wrote a small PyQt5 GUI script.

In its current state, the script lets you:

  • Select waveform, amplitude, frequency, and DC offset
  • Run sweeps, bursts, or arbitrary waveforms
  • Save and recall up to 10 presets (you can also recall directly from the generator)
  • Use the ARB Manager to download waveforms from the generator or upload new ones (not fully tested yet!) – it also shows the waveforms currently stored
  • Send direct SCPI commands through a built-in CLI
  • Grab screenshots from the generator display (saved in the same directory as the script)

Use it as-is or tweak it for your own setup. Programming in Python and PyQt5 isn’t my main profession -(I’m more of a hardware guy) so if you try it and find bugs (there will be some), I’d love to hear from you.

Script source and details: ToGo-Lab Git Repository

The program talks to the SDG2042X over a simple socket connection on port 5025 using SCPI commands. You can call the script with the -ip parameter (try also --help). This is handy if you launch it via a .desktop file.

The functions are straightforward, so there’s no detailed documentation yet. I hope most of the features are self-explanatory. Each GUI tab covers one main function. See more details in the Gitea repo:

  • Basic: Waveform, frequency, amplitude, offset, phase, and output control
  • Burst: Configure burst mode, trigger source, cycles, and delay
  • Sweep: Set up linear or logarithmic sweeps, start/stop frequency
  • ARB Manager: List, upload, and download arbitrary waveforms (still experimental)
  • SCPI CLI: The command-line interface for direct SCPI communication
  • Presets: Store and recall up to 10 custom setups; presets are saved in a text-based .dat file. This tab is especially useful: You can adjust settings directly on the generator, then read them back and save them as presets. The file is easy to edit manually if needed.

You can take screenshots at any time. They’re stored as .bmp files in the working directory, with the date and time included in the filename.

Update 2025-10-25

My SDG2042X Python control GUI keeps moving forward. Today I spent a lot of time reviewing and rewriting parts of the code. My focus was on stability & usability, and making the tool to fit better into my idea of a remote controlled test bench setup.

Today’s update:

Context-aware Basic Tab The parameter fields now change automatically depending on the selected waveform. So if you choose SINE, SQUARE, RAMP, PULSE, NOISE, ARB, or DC, you’ll only see the options that actually matter, others are grayed out.

Improved SCPI Reliability I added a new query_retry() function and a socket drain, which makes communication with the generator more reliable. This prevents annoying timeouts when running queries like OUTP? or BSWV?. The default socket timeout has also been set now to 4 seconds to give things a bit more breathing room (especially the screenshots are very slow). This makes it a little bit laggy but with shorter time I get sometimes errors. Adjust with care if you want a shorter response time.

Config System There’s now an SDG2042x.config file where you can define paths for presets and screenshots (simple text file). The pathes for presets and schreenshot directory are accessable from the “Config” tab.

Screenshot from 2025-10-25 15-45-33
Screenshot SDG2042X

Old meter (MXD-4660A), new tricks.

I pulled my veteran DMM, a Voltcraft MXD-4660A, from the drawer to set up my workbench (adding a serial-to-USB converter) and gave it a second tour of duty with QtDMM on Ubuntu. After a bit of searching online what to use under I found the QtDMM project at http://www.mtoussaint.de/qtdmm.htmlm , but appears abandoned. The active fork, I think, is at https://github.com/tuxmaster/QtDMM.

Here’s the final install and setup for my lab computer running Ubuntu 22.04 (Jammy):

Build & Install QtDMM on Ubuntu 22.04 (Jammy)

1) Prerequisites

  • Enable Universe and base tools:

    sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository -y universe
sudo apt update

  • Compilers, build tools, VCS:

    sudo apt install -y git build-essential cmake ninja-build pkg-config

  • Qt6 SDK

    sudo apt install -y qt6-base-dev qt6-tools-dev qt6-tools-dev-tools qt6-l10n-tools libqt6serialport6-dev

  • HID API

    sudo apt install -y libhidapi-dev libhidapi-hidraw0

  • OpenGL headers for Qt6Gui/Widgets

    sudo apt install -y libopengl-dev libgl1-mesa-dev libglu1-mesa-dev mesa-common-dev

  • Serial access without sudo:

    sudo usermod -aG dialout "$USER"

  • Log out and back in to apply group membership

2) Get the source and make the script executable

git clone https://github.com/tuxmaster/QtDMM.git
cd QtDMM
chmod +x compile.sh

3) Build

  • Clean build (optional). Also verifies prerequisites are present. 
    ./compile.sh clean || true
rm -rf build CMakeCache.txt CMakeFiles
./compile.sh
  • Artifacts land in ./bin/: 
    ./bin/qtdmm --version
  • Verify it runs. If not, see Troubleshooting below

4) Install for all users (see §5 for a .deboption)

Preferred:

sudo ./compile.sh install
# now on PATH:
qtdmm --version

5) Alternative: make a .deb

Keeps your system clean and is easy to remove later.

./compile.sh pack
sudo apt install ./QtDMM_*amd64.deb

6) Uninstall

If installed via .deb:

sudo apt remove qtdmm

If installed via compile.sh install:

# run from the same build dir used for the install
sudo xargs rm < build/install_manifest.txt

Troubleshooting:

If you hit errors, try a clean build reset instead of first searching forums. I learned the hard way to make a clean install as a belt-and-suspenders reset, that deletes built objects but keeps the CMake cache.

  • “|| true” lets the sequence continue even if the clean step fails due to a broken config.
  • “rm -rf build CMakeCache.txt CMakeFiles” force-removes any stale out-of-source build dir and any accidental in-source CMake cache:
  • “Final ./compile.sh” does a fresh configure and build: 
cd ~/QtDMM
./compile.sh clean || true
rm -rf build CMakeCache.txt CMakeFiles
./compile.sh

Let’s check if it’s running

  • As your regular user, start QtDMM from the command line or via the Ubuntu Dock (search for “QtDMM”):
  • Hint: How to create a Desktop shortcut launcher for ubuntu 22.04
    QtDMM - Running

  • Configure settings for MXD-4660A:
    Setup Voltcraft MXD-4660A

    Final test setup (send a known signal) and the result: MXD getting some imput from generator to prove reading
    QtDMM running, getting Data


Question to readers: Is there Linux software for the old Hameg HM1507-3? I’m currently using a Windows XP VM with very old software.