PiHole with DNS-over-HTTP: Revised

More than a year later, the PiHole continues to work fine, but the process for installing the Cloudflare DoH machinery has evolved.

(And, yes, it’s supposed to be DNS-over-HTTPS. So it goes.)

To forestall link rot, the key points:

cd /tmp ;  wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz
tar -xvzf cloudflared-stable-linux-arm.tgz 
sudo cp cloudflared /usr/local/bin
sudo chmod +x /usr/local/bin/cloudflared
sudo cloudflared -v
sudo useradd -s /usr/sbin/nologin -r -M cloudflared
sudo nano /etc/default/cloudflared
CLOUDFLARED_OPTS=--port 5053 --upstream --upstream 
sudo chown cloudflared:cloudflared /etc/default/cloudflared
sudo chown cloudflared:cloudflared /usr/local/bin/cloudflared
sudo nano /etc/systemd/system/cloudflared.service
Description=cloudflared DNS over HTTPS proxy
After=syslog.target network-online.target

ExecStart=/usr/local/bin/cloudflared proxy-dns $CLOUDFLARED_OPTS

sudo systemctl enable cloudflared
sudo systemctl start cloudflared
sudo systemctl status cloudflared

Then aim PiHole’s DNS at It used to be on port #54, for whatever that’s worth.

Verify it at, which should tell you DoH is in full effect.

To update the daemon, which I probably won’t remember:

wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz
tar -xvzf cloudflared-stable-linux-arm.tgz
sudo systemctl stop cloudflared
sudo cp ./cloudflared /usr/local/bin
sudo chmod +x /usr/local/bin/cloudflared
sudo systemctl start cloudflared
cloudflared -v
sudo systemctl status cloudflared

And then It Just Works … again!

MPCNC: bCNC Probe Camera Refresh

For the usual inscrutable reasons, updating bCNC killed the USB camera on the MPCNC, although it still worked fine with VLC. Rather than argue with it, I popped a more recent camera from the heap and stuck it onto the MPCNC central assembly:

bCNC - USB probe camera - attachment
bCNC – USB probe camera – attachment

This one has a nice rectangular case, although the surface might be horrible silicone that turns to snot after a few years. The fancy silver snout rotates to focus the lens from a few millimeters to infinity … and beyond!

If you think it looks a bit off-kilter, you’re absolutely right:

bCNC - USB probe camera - off-axis alignment
bCNC – USB probe camera – off-axis alignment

The lens image reflected in a mirror on the platform shows the optical axis has nothing whatsoever to do with the camera case or lens snout:

bCNC - USB probe camera - off-axis reflection
bCNC – USB probe camera – off-axis reflection

Remember, the mirror reflects the lens image back to itself only when the optical axis is perpendicular to the mirror. With the mirror flat on the platform, the lens must be directly above it.

Because the MPCNC camera rides at a constant height over the platform, the actual focus & scale depends on the material thickness, but this should be typical:

bCNC - USB Probe Camera - scale - screenshot
bCNC – USB Probe Camera – scale – screenshot

It set up a Tek Circuit Computer test deck within 0.2 mm and the other two within 0.1 mm, so it’s close enough.

The image looks a whole lot better: cheap USB cameras just keep improving …

Raspberry Pi Shutdown / Start Button

While adding the usual Reset button to a Raspberry Pi destined for a Show-n-Tell with the HP 7475A plotter, I browsed through the latest dtoverlay README and found this welcome surprise:

Name:   gpio-shutdown
Info:   Initiates a shutdown when GPIO pin changes. The given GPIO pin
        is configured as an input key that generates KEY_POWER events.
        This event is handled by systemd-logind by initiating a
        shutdown. Systemd versions older than 225 need an udev rule
        enable listening to the input device:

                ACTION!="REMOVE", SUBSYSTEM=="input", KERNEL=="event*", \
                        SUBSYSTEMS=="platform", DRIVERS=="gpio-keys", \
                        ATTRS{keys}=="116", TAG+="power-switch"

        This overlay only handles shutdown. After shutdown, the system
        can be powered up again by driving GPIO3 low. The default
        configuration uses GPIO3 with a pullup, so if you connect a
        button between GPIO3 and GND (pin 5 and 6 on the 40-pin header),
        you get a shutdown and power-up button.
Load:   dtoverlay=gpio-shutdown,<param>=<val>
Params: gpio_pin                GPIO pin to trigger on (default 3)

        active_low              When this is 1 (active low), a falling
                                edge generates a key down event and a
                                rising edge generates a key up event.
                                When this is 0 (active high), this is
                                reversed. The default is 1 (active low).

        gpio_pull               Desired pull-up/down state (off, down, up)
                                Default is "up".

                                Note that the default pin (GPIO3) has an
                                external pullup.

        debounce                Specify the debounce interval in milliseconds
                                (default 100)

So I added two lines to /boot/config.txt:


The fancy “Moster heatsink” case doesn’t leave much room for wiring:

RPi Shutdown Restart Switch - GPIO 3
RPi Shutdown Restart Switch – GPIO 3

The switch button is slightly shorter than the acrylic sheet, so it’s recessed below the surface and requires a definite push to activate. It’s not as if it’ll get nudged by accident, but ya never know.

I’ll eventually migrate this change to all the RPi boxes around the house, because it just makes more sense than any of the alternatives. Heck, it’ll free up a key on the streaming radio player keypads, although I must move the I²C display to Bus 0 to avoid contention on Pin 3.

For reference, the Raspberry Pi header pinout:

Raspberry Pi pinout
Raspberry Pi pinout

I don’t know if I²C Bus 0 has the same 1.8 kΩ pullups as Bus 1, though; a look at the bus currents will be in order.

HP 7475A Plotter Data Sniffing: socat Serial Port Tee

Some hints and examples provided the socat incantation required to sniff serial data between my Superformula demo program (on the Raspberry Pi) and my HP 7475A plotter:

socat /dev/ttyUSB0,raw,echo=0 SYSTEM:'tee /tmp/in.txt | socat - "PTY,link=/tmp/ttyv0,raw,echo=0,wait-slave" | tee /tmp/out.txt'

The out.txt file collects data from the program to the plotter, the in.txt file holds data from the plotter to the program, and both files contain exactly and only the serial data, so some interpretation will be required.

With that in hand, tweak the .chiplotle/config.py file to aim Chiplotle at the virtual serial port:

serial_port_to_plotter_map = {'/tmp/ttyv0' : 'HP7475A'}

This is dramatically easier than wiring a pair of additional hardware serial ports onto the RS-232 connection between the two:

HP 7475A - serial port adapters - hardcore
HP 7475A – serial port adapters – hardcore

The adapter stack instantly become a custom cable, although I miss Der Blinkenlights.

The HPGL output to the plotter (out.txt) comes from the Chiplotle driver with no embedded linefeed / carriage return characters, as HPGL uses semicolon command terminators, making it one humongous line impervious to the usual text utilities. In addition, several plotter configuration commands have prefix ESC (0x1b) characters without semicolon separators. Each LB (label) command within the stream ends with a 0x03 ETX character.

While one could fix all those gotchas with a sufficiently complex sed script, I manually separated the few lines I needed after each semicolon, then converted the raw ASCII control characters to displayable Unicode glyphs (␛ and ␃), making it legible for a presentation:

head -c 1000 out.txt
LBStarted 2020-01-09 18:03:57.494617␃;
LBPen 1: ␃;
LBm=1.9 n1=0.71 n2=n3=0.26␃;
<<< snippage >>>

The corresponding responses from the plotter to the program (in.txt) are separated by carriage return characters (␍) with no linefeeds (␊), so the entire file piles up at the terminal’s left margin when displayed with the usual text tools. Again, manually splitting the output at the end of each line produces something useful:

<<< snippage >>>

The first number gives the size of the serial FIFO buffer. An inexplicable ten OW; commands from deep in the Chiplotle driver code return the Output Window size in plotter units. No other commands produce any output until the plot finishes, whereupon my code waits for a digitized point from the plotter, with the (decimal) 18 indicating a point isn’t ready.

All that at 9600 bits per second …

Raspberry Pi: Adding a PIXEL Desktop Launcher

The Raspberry Pi’s Raspbian PIXEL Desktop UI (not to be confused with the Google Pixel phone) descends from LXDE, with all the advantages & disadvantages that entails. One nuisance seems to be the inability to create a launcher for a non-standard program.

The stock task bar (or whatever it’s called) has a few useful launchers and you can add a launcher for a program installed through the usual Add/Remove Software function, as shown by the VLC icon:

LXDE launcher icons
LXDE launcher icons

Adding a bCNC launcher requires a bit of legerdemain, because it’s not found in the RPi repositories. Instead, install bCNC according to its directions:

… install various pre-requisites as needed …
pip2 install --upgrade git+https://github.com/vlachoudis/bCNC 

Which is also how you upgrade to the latest & greatest version, as needed.

You then launch bCNC from inside a terminal:

python2 -m bCNC

The installation includes all the bits & pieces required to create a launcher; they’re just not in the right places.

So put them there:

sudo cp ./.local/lib/python2.7/site-packages/bCNC/bCNC.png /usr/share/icons/
sudo cp .local/lib/python2.7/site-packages/bCNC/bCNC.desktop /usr/share/applications/bCNC.desktop

The bCNC.desktop file looks like this:

[Desktop Entry]
Comment=bCNC Controller

Set Terminal=false if you don’t want a separate terminal window and don’t care about any of the messages bCNC writes to the console during its execution. However, those messages may provide the only hint about happened as bCNC falls off the rails.

With all that in place, it turns out LXDE creates a user-specific panel configuration file only when you change the default system panel configuration. Add a VLC launcher to create the local ~/.config/lxpanel/LXDE-pi/panels/panel file.

With that ball rolled, then add the bCNC launcher:

nano .config/lxpanel/LXDE-pi/panels/panel
… add this stanza …
Plugin {
  Config {
    Button {

Log out, log back in again, and the bCNC icon should appear:

LXDE launcher icons - additions
LXDE launcher icons – additions

Click it and away you go:

bCNC - Running from LXDE Launcher
bCNC – Running from LXDE Launcher

At least you (and I) will start closer to the goal when something else changes …

Among the Forgotten

Spotted in a museum:

Kiosk - Floppy Disk Seek Failure
Kiosk – Floppy Disk Seek Failure

It’s been quite a while since BIOS boot sequences started with the floppy drive. Combined with a CMOS backup battery failure, I’d say this poor PC has been chugging along for two decades.

On another floor:

Kiosk - Windows Updates
Kiosk – Windows Updates

Isolating a Windows kiosk from the Interwebs is an excellent design principle, but Windows Update really wants to phone home. The kiosk’s presentation ran Adobe Flash 10, so it’s been confined for maybe a decade.

Looks like it’s time for another fundraising drive to replace the PCs with Raspberry Pi controllers. The real expense, of course, goes into rebuilding the presentations using whatever tech stack is trendy these days.

Makergear M2: Octopi Camera Mount

Octopirint / Octopi works wonderfully well as a controller / G-Code feeder for my Makergear M2. After putting up with an ungainly mass of tape for far too long, I printed Toddman’s Pi Camera Mount:

Pi Camera - M2 Mount - Slic3r
Pi Camera – M2 Mount – Slic3r

Which snapped together exactly like it should:

Makergear M2 - Pi Camera Mount
Makergear M2 – Pi Camera Mount

A strip of double-sided foam tape attaches it to the Pi’s case, which is Velcro-ed to the M2’s frame. The cable may be too long, but avoids sharp bends on the way out of the case.

The whole lashup works fine:

Pi Camera - M2 Mount - Octopi timelapse
Pi Camera – M2 Mount – Octopi timelapse

That’s a second set intended for the CNC 3018-Pro, but it didn’t fit quite as well. The B brackets are slightly too long (or their pivots are slightly too close to their base) to allow the C plates to turn 90° to the mount:

Pi Camera - M2 Mount - Config 2 diagram
Pi Camera – M2 Mount – Config 2 diagram

Nothing one can’t fix with nibbling & filing, but I long for parametric designs …