markpenner.space - Blog

Controlling a Quest M6 Roaster with Phidgets and C++

Mark Penner — Mon, 25 May 2026 00:00:00 +0000

I have a Quest M6 coffee roaster. It is a small electric drum roaster that comes with manual phase-control dimmers for the fan and heater. I set up some Phidgets with thermocouples to report the bean temperature and roasting environment temperature to Artisan. When I adjusted the heater setting I would also manually enter the setting change in Artisan. I got to thinking it would be nice if I could just enter the desired change in Artisan and that would also set the heater. So the journey begins.

Since I was already using Phidgets for temperature readings, I got a Digital Output Phidget that can output a PWM (pulse-width modulated) signal. The Digital Output Phidget doesn't have a zero crossing detector to synchronize with the AC grid power, so I planned to use a zero-crossing SSR to switch at a frequency much lower than the 60 Hz grid. Unfortunately I hadn't read the specifications carefully enough, and realized after I got it and started testing it out that the minimum PWM frequency from the Digital Output Phidget is 100 Hz. It doesn't really work to use a 100 Hz signal to switch 60 Hz power at the zero crossings. What to do now?

I could have gotten a different device at this point, like a TC4 or a Yocto-PWM-Tx. However, I didn't really feel like spending more money, and I had gotten an idea to make what I already had work. I could bit bang the PWM instead of using the Digital Output Phidget's PWM functionality. All it would take is a little programming to communicate with Artisan and to turn the output on and off with the right timing.

Artisan can talk directly to Phidgets, but it can also talk to other devices. One of the protocols it can talk is JSON over WebSockets. I could build a WebSocket server that would talk to the Phidgets, and Artisan could talk to my server.

I thought briefly about using this as an opportunity to learn Go or Rust or Zig or some other language, but I wanted something quickly and I knew performance (low latency specifically) would matter, so I went with C++. I'm not an expert C++ programmer, but I have enough experience that I was confident I could do what I needed to do. My experience with C++ has largely been with KDE applications and libraries, so it was an interesting change to build a server program instead.

There is a C library for communicating with Phidgets, so that was easy enough to interface with from C++. I made a wrapper class to handle the details of working with the Phidgets C API. For WebSocket and JSON support, I chose Boost.Beast and Boost.JSON. I hadn't worked with Boost libraries directly before, since I had worked mainly with Qt-based software, but I have been happy so far. Beast can do much more than I am using it for. There are several different APIs you can use and it was a bit hard to wrap my head around them all at once. I'm using the synchronous API for now since it seemed the easiest to understand.

I implemented pulse-width modulation by starting a thread and passing the duty cycle in as a reference to a number between 0 and 1, stored in a std::atomic so I could change it atomically from a different thread. The PWM thread runs a loop turning the output on, sleeping for the period duration multiplied by the duty cycle (between 0 and 1), then turns the output off and sleeps for the period multiplied by 1 minus the duty cycle. I'm not sure if there's a better way to implement this than sleeping the thread, but it's working for me.

Then I got to thinking again. I was using a fixed length period of 0.83 seconds to cover 50 full cycles of 60 Hz, so when the duty cycle was at 0.5, the heater would be on for 25 cycles and off for 25 cycles. The period could be made shorter on average be implementing a duty cycle of 0.5 as 1 cycle on, 1 cycle off, and 0.75 would be 3 cycles on, 1 cycle off, etc. This is pulse-density modulation instead of pulse-width modulation.

The duty cycle setting comes from Artisan as a number between 0 and 100, so rather than converting that to a floating point number between 0 and 1, I simplified the fraction of the duty cycle over 100, e.g. 75 over 100 becomes 3 over 4, which means 3 cycles on and 4 - 3 = 1 cycle off. The heater control thread received a pair of integers instead of a single floating point number, and multiplied them by 1/60th of a second (full wave of 60 Hz power) to get the on and off durations.

An electric heater responds so slowly that shortening the period like this doesn't make much difference in controlling it. The main advantage was that it was usually switching fast enough that the watt meter I plugged my roaster into read the average wattage being used. However, the ceiling lights dim when the heater is on full power, and switching like that makes them flicker annoyingly. For now I decided to go back to PWM at a fixed period of 1.67 seconds (100 cycles of 60 Hz), which is slow enough that the lights dimming and brightening doesn't bother me. The watt meter reading now jumps up and down instead of reading an average, but I don't rely on it anymore anyway, so that's alright.

You can see the code at https://codeberg.org/mrp/ossicle. There is currently some stuff hard coded for my own use: my Phidget setup and the port the WebSocket server runs on. If others want to use it and would rather have that configurable some other way than recompiling, open an issue or PR. I may try reimplementing it in a different language for a learning experience sometime, but I'm happy with the project for now.

I'm very happy with how easy the Quest M6 is to modify for projects like this. It is very well built, easy to understand, and easy to work on. It works great in stock condition as a manual roaster and also makes a good base for modifications.

Kwave Nightly Flatpak

Mark Penner — Mon, 06 Jan 2025 22:25:00 -0600

If you want to keep up with the latest Kwave updates, you can now try out the nightly flatpak. It gets published each time code is pushed to the master branch, so it may sometimes have bugs, but also new features. To try it out, add the repository by running flatpak remote-add kwave-nightly https://cdn.kde.org/flatpak/kwave-nightly/kwave-nightly.flatpakrepo and install Kwave with flatpak install kwave-nightly org.kde.kwave. If you use Discover, go to Settings, click Add Source and paste https://cdn.kde.org/flatpak/kwave-nightly/kwave-nightly.flatpakrepo in to add the repo, and then search for Kwave.

The process for publishing stable versions to Flathub has also started. The current plan is to wait for the next stable version (25.04) to publish Kwave on Flathub.

Kwave Update - October 2024

Mark Penner — Mon, 28 Oct 2024 00:00:00 +0000

Kwave is an audio editor based on the KDE Frameworks. It was started in 1998 by Martin Wilz, and Thomas Eschenbacher has been the main developer since 1999. In recent years development has slowed. I wanted to do some software development and contribute to KDE, and I'm interested in audio, so towards the end of 2023 I started working on Kwave.

Kwave had not been ported to Qt 6 and KDE Frameworks 6 yet, so that's what I started working towards. My first merge requests were to update deprecated code. (MR Convert plugin desktop files to json, MR Port away from deprecated Qt API, MR port away from deprecated I18N_NOOP macros, MR bump KF5_MIN_VERSION and update where KMessageBox API has been deprecated, MR port QRegExp to QRegularExpression)

With that preparatory work done, I worked at porting Kwave to Qt 6 and KDE Frameworks 6. Most of that work was straight-forward. The biggest changes were in Qt Multimedia, which Kwave can use for playback and recording. I finally got that done and merged in August 2024, just after version 24.08 was branched, so that change will get released in version 24.12 in December 2024. (MR port to Qt6 and KF6)

Next I did some code cleanup. (MR use ECMGenerateExportHeader, MR add braces to avoid ambiguous else, MR call KCrash::initialize() after KAboutData::setApplicationData())

Laurent Montel added the FreeBSD job to the Continuous Integration configuration, but the build failed initially. I've never ran FreeBSD, but with a few tries and pushing changes to trigger CI, I managed to get the CI to pass. I'm glad Laurent took the initiative here, because the FreeBSD job uses clang, so with the existing Linux job using gcc, CI makes sure Kwave builds with both compilers now. (MR Add freebsd)

I applied for a KDE Developer account and got approved on August 24, 2024. Now I could commit changes myself instead of having to remind others to do it.

Carl Schwan cleaned up some code and updated the zoom toolbar to use standard icons, which enabled removing the built-in zoom icons. (MR Modernize ZoomToolbar) That was the incentive I needed to remove the rest of the built-in icons and use standard icons instead, which helps Kwave fit the users theme better. (MR use icons from current theme) I also reordered the playback toolbar in a way that seemed more logical to me. (MR update player toolbar)

I investigated a bug: Kwave Playback settings dialog loads incorrectly until you switch playback methods and fixed it in MR: make sure a valid method gets selected when PlayBackDialog opens

I have some more work in progress, and I plan to continue working on Kwave. I will try to blog about what I'm doing, but I'm not going to commit to any regular schedule.

Get Involved

Kwave depends on the rest of KDE. It is built on the Frameworks, and the KDE sysadmin team keeps the infrastructure running. You can help KDE by getting involved, or at least donate.

If you would like to help improve Kwave, use it and try out its features! If you have questions or ideas, discuss them. If you find bugs, report them. If you want to get involved with development, download the source code and start hacking!

If you think my own work on Kwave is worth something and you can afford it, you can donate to me through Liberapay, Stripe, or PayPal.

How to build a Debian metapackage for personal use

Mark Penner — Sat, 23 Sep 2023 00:00:00 +0000

Why build your own metapackage?

I don't like having lots of manually installed packages that I'm not sure I need on my Debian system. One way I get such packages is when I'm compiling software such as FreeCad, and I install the build dependencies with a command like the one that is listed here. (That command doesn't actually work on Debian unstable, I got my list of packages to install from here.) When you run a command like that, all those packages are marked as manually installed. I had the idea to build a metapackage that depends on those packages, so if I decide I won't be building FreeCad again I can uninstall the metapackage and if nothing else depends on those packages they can be removed with sudo apt autoremove.

Most of this is based on the packaging intro tutorial on the Debian wiki. Check that out if you want more details. This howto will give just enough information to get this metapackage built, because that is the extent of my experience so far. ;-)

Install the packages you will need

sudo apt install build-essential devscripts debhelper

(Here you might think about building a metapackage for building metapackages. Very meta.)

Make the directory structure and switch into it

mkdir -p ~/deb/build-dependencies/debian/; cd ~/deb/build-dependencies/

In this structure, deb/ will be where the final .deb file will end up. Under that, build-dependencies/ is the package directory, which since this is a metapackage, will be empty except for the debian/ directory, where the package metadata files will go.

Generate a changelog in the right format

dch --create -v 1 --package build-dependencies

The -v 1 switch sets the package version to 1. This will make a debian/changelog file. I got a warning neither DEBEMAIL nor EMAIL environment variable is set. Press Enter to accept the warning and your editor will pop up to edit the created file. You can delete the (Closes: #XXXXXX) bit and edit the last line that has your name and email address if you want. The email address does not need to be valid (since I won't be uploading this to Debian), but there does need to be something there else the package won't build.

The copyright file needs to exist, but it can be empty

touch debian/copyright

Now the interesting file: `debian/control`

The first part, Source: build-dependencies, is the source package metadata. The second part, Package: freecad-dependencies, is the binary package metadata. The binary package is what you actually install, and you can make more than one binary package from one source package by providing several Package: binary-package-name sections.

Source: build-dependencies
Maintainer: Mark Penner
Section: misc
Priority: optional
Build-Depends: debhelper-compat (= 13)

Package: freecad-dependencies
Architecture: any
Depends: cmake,
         libboost-date-time-dev,
         libboost-dev,
         libboost-filesystem-dev,
         libboost-graph-dev,
         libboost-iostreams-dev,
         libboost-program-options-dev,
         libboost-python-dev,
         libboost-regex-dev,
         libboost-serialization-dev,
         libboost-thread-dev,
         libcoin-dev,
         libdouble-conversion-dev,
         libglew-dev,
         liblz4-dev,
         libopencv-dev,
         libeigen3-dev,
         libgts-bin,
         libgts-dev,
         libkdtree++-dev,
         libmedc-dev,
         libmetis-dev,
         libocct-data-exchange-dev,
         libocct-ocaf-dev,
         libocct-visualization-dev,
         libpyside2-dev,
         libqt5opengl5-dev,
         libqt5svg5-dev,
         libqt5xmlpatterns5-dev,
         libqt5x11extras5-dev,
         libshiboken2-dev,
         libspnav-dev,
         libvtk9-dev,
         libx11-dev,
         libxerces-c-dev,
         libzipios++-dev,
         lsb-release,
         occt-draw,
         pybind11-dev,
         pyqt5-dev-tools,
         pyside2-tools,
         python3-dev,
         python3-matplotlib,
         python3-ply,
         python3-pyside2.qtcore,
         python3-pyside2.qtgui,
         python3-pyside2.qtsvg,
         python3-pyside2.qtuitools,
         python3-pyside2.qtwidgets,
         python3-pyside2.qtxml,
         python3-requests,
         qtbase5-dev,
         qttools5-dev,
         qtwebengine5-dev,
         swig
Description: FreeCad build dependencies
 Metapackage to install dependencies for building FreeCad.

`debian/rules` is a Makefile with instructions to build the package

#!/usr/bin/make -f
%:
	dh $@

Remember Makefiles use tabs not spaces!

Build the package

debuild

The package will be built and placed in the directory above the one you're in. (deb/freecad-dependencies_1_amd64.deb is the built binary package on my machine.)

Install

Now if all the dependencies are already installed, you can run sudo debi to install the package. It will find the package in the directory above and install it with dpkg. However, dpkg will not install dependencies for you. Since I made this package specifically to install dependencies, I ran sudo apt install ../freecad-dependencies_1_amd64.deb. That installed all the dependencies, and also the dependencies of dependencies.

Celebrate a cleaner manually installed packages list!

If any of those packages were already installed, you can mark them as automatically installed with:

sudo apt-mark auto cmake libboost-date-time-dev libboost-dev libboost-filesystem-dev libboost-graph-dev libboost-iostreams-dev libboost-program-options-dev libboost-python-dev libboost-regex-dev libboost-serialization-dev libboost-thread-dev libcoin-dev libdouble-conversion-dev libglew-dev liblz4-dev libopencv-dev libeigen3-dev libgts-bin libgts-dev libkdtree++-dev libmedc-dev libmetis-dev libocct-data-exchange-dev libocct-ocaf-dev libocct-visualization-dev libpyside2-dev libqt5opengl5-dev libqt5svg5-dev libqt5xmlpatterns5-dev libqt5x11extras5-dev libshiboken2-dev libspnav-dev libvtk9-dev libx11-dev libxerces-c-dev libzipios++-dev lsb-release occt-draw pybind11-dev pyqt5-dev-tools pyside2-tools python3-dev python3-matplotlib python3-ply python3-pyside2.qtcore python3-pyside2.qtgui python3-pyside2.qtsvg python3-pyside2.qtuitools python3-pyside2.qtwidgets python3-pyside2.qtxml python3-requests qtbase5-dev qttools5-dev qtwebengine5-dev swig

Now if when I try to compile FreeCad I need other packages installed, I can just add them to debian/control, build the package again, and reinstall.

Blogging With Hugo and Org-mode

Mark Penner — Wed, 02 Aug 2023 00:00:00 +0000

This blog was originally generated with Hugo. I'm leaving this post up for the record, but it is no longer how I build this site.

I set it up a bit differently than many tutorials, so I thought I would describe what I did and why. I did not use a theme; I just wrote a few layouts and a short CSS file for a brutalist design. I wanted to be able to understand and control my design rather than try to figure out how to get what I wanted out of an existing theme.

I like the expressivity and clarity of Org mode syntax rather than Markdown. Thankfully, Hugo can read Org files good enough for me. go-org, the library Hugo uses to parse Org files, is intended "to support a reasonable subset of Org mode". There is also ox-hugo, an Org exporter to Hugo Markdown, but I have not tried it yet.

(Update 2024-10-26: I've been using Markdown also. Org mode is nice, but Markdown is more common, and since I've been using Markdown in other places where org mode can't be used, I find it easier to stick with one syntax. Hugo handles both fine, so there's no need to convert files.)

I'm not sure how much I will blog, but probably not a lot. My main motivation for starting a blog is to write down things I have learned. Hopefully some of what I write will be helpful to others, but I also want something for myself to refresh my memory later. I have learned a lot from people that write down things they have learned, whether they are experts or not. I want to do my part to keep that tradition strong.

Of course, it's also possible there will be long periods of silence occasionally interrupted by posts about my intentions to start blogging again. ;)

(Update 2023-11-24: I switched to using srht.site to host this. Source here, including the .build.yml file to build and deploy the site using builds.sr.ht. Below is how I was hosting it at first, which I'll leave up in case it's useful to someone. I decided to save the money I was spending on a VPS since I wasn't using it for much.)

I am using a Linode VPS (virtual private server) to host the website (among other things). I have the source in a git repository with this post-receive hook to deploy the site after a successful git push:

#!/bin/bash

GIT_REPO=/var/lib/git/markpenner.space.git
WORK_DIR=/tmp/work_dir
TARGET=/var/www/html
BACKUP=/tmp/backup_html

echo "Post receive hook starting"
set -e

rm -rf $WORK_DIR $BACKUP

echo "Making temporary directories."
mkdir -p $WORK_DIR $BACKUP

rsync -aqz $TARGET/ $BACKUP
trap "echo 'A problem occurred.  Reverting to backup.'; rsync -aqz --del $BACKUP/ $TARGET; rm -rf $WORK_DIR $BACKUP" EXIT

echo "Pulling into temporary directory."
git clone $GIT_REPO $WORK_DIR

echo "Removing existing site."
rm -rf $TARGET/*

echo "building new site"
hugo -s $WORK_DIR -d $TARGET

echo "Removing temporary directories."
rm -rf $WORK_DIR $BACKUP
trap - EXIT