Posts Tagged RPi

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/ 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 …

Leave a comment

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+ 

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 …

, ,

Leave a comment

Raspberry Pi “Moster” Heatsink Retaping

A pair of colorful laser-cut stacked acrylic Raspberry Pi cases with “Moster” (*) heatsinks arrived, with the intent of dressing up the HP 7475A plotters for their next Show-n-Tell:

Moster RPi Heatsink - assembled case
Moster RPi Heatsink – assembled case

Unfortunately, the thermal tape on one of the CPU heatsinks was sufficiently wrinkled to prevent good contact with the CPU:

RPi taped heatsinks - as received
RPi taped heatsinks – as received

The seller sent a replacement copper slug with tape on one side. Presumably, they glue it to the heatsink with thermal silicone:

Moster RPi Heatsink - silicone adhesive
Moster RPi Heatsink – silicone adhesive

Of which, I have none on hand.

So I did what I should have done originally, which was to drop a few bucks on a lifetime supply of thermally conductive heatsink tape, apply it to the bare side of the slug and stick the slug to the heatsink with their tape:

Moster RPi Heatsink - replacement adhesive tape
Moster RPi Heatsink – replacement adhesive tape

The blue stuff is the separation film, with the tape being white. It doesn’t match the black tape on the other side, but seems gooey enough to work.


Despite the heatsink hype, ball grid array chips dissipate most of their heat through their pads (and perhaps a central thermal pad) into the PCB, so sticking a heatsink atop the package is largely decorative, along the lines of hotrod ornamentation.

The epoxy packages used in previous Raspberry Pi iterations had better thermal conductivity to their top surface:

RPi 3 B - epoxy CPU
RPi 3 B – epoxy CPU

Than the more recent metal-top packages, which surely have inert-gas fill under the lid:

RPi 3 B - metal CPU
RPi 3 B – metal CPU

Pix cropped after being pilfered from the Official Raspberry Pi site.

Yes, the heatsink does conduct some heat into the air, even if not nearly as much as you might want.

(*) I’m pretty sure “Moster” was a typo in the original eBay listing which took on a life of its own to become something of an unofficial trademark. All of the search results ship from Duluth, Georgia (USA), regardless of the nominal seller; feel free to draw your own conclusions.

, ,


Ripping Vinyl Records on a Raspberry Pi

Having already set up a Raspberry Pi streaming radio player for the living room, it seemed reasonable to also use it for recording audio from the long-disused turntable. A pair of RCA cables from the amplifier’s TAPE 2 REC outputs to the Behringer UCA202 USB audio interface got the audio where it needed to be:

RPi streamer - Behringer UCA202 USB audio box
RPi streamer – Behringer UCA202 USB audio box

Fiddle with the amp to select the phonograph, poke the TAPE 2 button to send audio to/from the UCA202, fire up an SSH session, kill the streaming audio program, and figure out what audio hardware is out there:

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Not much else to choose from on a Raspberry Pi, so see what the UCA202 can do:

$ arecord --dump-hw-params 
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "default":
FRAME_BITS: [8 32]
RATE: [8000 48000]
PERIOD_TIME: [1000 65536000]
PERIOD_SIZE: [16 524288]
PERIOD_BYTES: [64 524288]
PERIODS: [2 1024]
BUFFER_TIME: (666 131072000]
BUFFER_SIZE: [32 1048576]
BUFFER_BYTES: [64 1048576]
arecord: set_params:1233: Sample format non available
Available formats:
- S8
- S16_LE

Given those limited choices, 16 bit little-endian at 48 kHz seems like a no-brainer.

Find out all the ALSA device names:

$ arecord -L
    Discard all samples (playback) or generate zero samples (capture)
    USB Audio CODEC, USB Audio
    Default Audio Device
    USB Audio CODEC, USB Audio
    Front speakers
    USB Audio CODEC, USB Audio
    2.1 Surround output to Front and Subwoofer speakers
    USB Audio CODEC, USB Audio
    4.0 Surround output to Front and Rear speakers
    USB Audio CODEC, USB Audio
    4.1 Surround output to Front, Rear and Subwoofer speakers
    USB Audio CODEC, USB Audio
    5.0 Surround output to Front, Center and Rear speakers
    USB Audio CODEC, USB Audio
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
    USB Audio CODEC, USB Audio
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
    USB Audio CODEC, USB Audio
    IEC958 (S/PDIF) Digital Audio Output
    USB Audio CODEC, USB Audio
    Direct sample mixing device
    USB Audio CODEC, USB Audio
    Direct sample snooping device
    USB Audio CODEC, USB Audio
    Direct hardware device without any conversions
    USB Audio CODEC, USB Audio
    Hardware device with all software conversions

They all point to the same hardware, so AFAICT the default device will work fine.

Try recording something directly to the RPi’s /tmp directory, using the --format=dat shortcut for “stereo 16 bit 48 kHz” and --mmap to (maybe) avoid useless I/O:

$ arecord --format=dat --mmap --vumeter=stereo --duration=$(( 30 * 60 ))  /tmp/Side\ 1.wav
Recording WAVE '/tmp/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
                                  +02%|01%+                                   overrun!!! (at least 1.840 ms long)
                                  +02%|02%+                                   overrun!!! (at least 247.720 ms long)
                                +# 07%|06%##+                                 overrun!!! (at least 449.849 ms long)
                                 + 03%|02%+                                   overrun!!! (at least 116.850 ms long)

Huh. Looks like “writing to disk” sometimes takes far too long, which seems to be the default for MicroSD cards.

The same thing happened over NFS to the file server in the basement:

$ arecord --format=dat --mmap --vumeter=stereo --duration=$(( 30 * 60 ))  /mnt/part/Transfers/Side\ 1.wav

Recording WAVE '/mnt/part/Transfers/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

                               +   09%|07%  +                                 overrun!!! (at least 660.372 ms long)

                                +# 08%|06%# +                                 overrun!!! (at least 687.906 ms long)

So maybe it’s an I/O thing on the RPi’s multiplexed / overloaded USB + Ethernet hardware?

Trying a USB memory jammed into the RPi, under the assumption it might be better at recording than the MicroSD Card:

$ arecord --format=dat --mmap --vumeter=stereo --duration=$(( 30 * 60 ))  /mnt/part/Side\ 1.wav
Recording WAVE '/mnt/part/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
                                  +01%|01%+                                   overrun!!! (at least 236.983 ms long)

Well, if it’s overrunning the default buffer, obviously it needs Moah Buffah:

$ arecord --format=dat --mmap --vumeter=stereo --buffer-time=1000000 --duration=$(( 30 * 60 ))  /mnt/part/Side\ 1.wav
Recording WAVE '/mnt/part/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
                               +## 10%|06%# +                                 overrun!!! (at least 359.288 ms long)

When brute force doesn’t work, you’re just not using enough of it:

$ arecord --format=dat --mmap --vumeter=stereo --buffer-time=2000000 --duration=$(( 30 * 60 ))  /mnt/part/Side\ 1.wav
Recording WAVE '/mnt/part/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

Sampling four bytes at 48 kHz fills 192 kB/s, so a 2 s buffer blots up 384 kB, which seems survivable even on a Raspberry Pi.

The audio arrives at 11.5 MB/min, so an LP side with 20 min of audio will require about 250 MB of disk space. The USB memory was an ancient 2 GB card, so all four sides filled it halfway:

$ ll /mnt/part
total 1.1G
drwxr-xr-x  2 ed   root 4.0K Dec 31  1969  ./
drwxr-xr-x 17 root root 4.0K Jun  7 19:15  ../
-rwxr-xr-x  1 ed   root 281M Sep  1 14:38 'Side 1.wav'*
-rwxr-xr-x  1 ed   root 242M Sep  1 15:01 'Side 2.wav'*
-rwxr-xr-x  1 ed   root 265M Sep  1 15:27 'Side 3.wav'*
-rwxr-xr-x  1 ed   root 330M Sep  1 15:58 'Side 4.wav'*

Side 4 is a bit longer than the rest, because I was folding laundry and the recording stopped at the 30 minute timeout after 10 minutes of silence.

Now, to load ’em into Audacity, chop ’em into tracks, and save the lot as MP3 files …



Raspberry Pi vs. MicroSD: Another One Bites the Dust

The Raspberry Pi running the MPCNC recently seized up with baffling symptoms, which generally indicates the poor little MicroSD card serving as a “hard disk” has failed:

Defunct Sandisk Ultra 32 GB MicroSD
Defunct Sandisk Ultra 32 GB MicroSD

I managed to open a terminal emulator, whereupon all of the non-built-in shell commands couldn’t be found.

Proceed as before: binary-copy the entire MicroSD card to another one, pop it in the RPi, and it’s all good again.

For the record, the new card is an unused Samsung Evo Plus. I do not understand the difference between the “Evo Plus” and “Evo+” branding, other than to suspect one of being a very good fake.

In round numbers, MicroSD cards seem to last a year under what seems like not-too-demanding service; I’m not running the MPCNC all day, every day.

, ,