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
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.
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
Which snapped together exactly like it should:
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
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
Nothing one can’t fix with nibbling & filing, but I long for parametric designs …
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
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
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
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.
Done!
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
Than the more recent metal-top packages, which surely have inert-gas fill under the lid:
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.
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:
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
null
Discard all samples (playback) or generate zero samples (capture)
sysdefault:CARD=CODEC
USB Audio CODEC, USB Audio
Default Audio Device
front:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Front speakers
surround21:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
4.0 Surround output to Front and Rear speakers
surround41:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
IEC958 (S/PDIF) Digital Audio Output
dmix:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Direct sample mixing device
dsnoop:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Direct sample snooping device
hw:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Direct hardware device without any conversions
plughw:CARD=CODEC,DEV=0
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
+00%|00%+
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 …
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.
Another alignment camera contestant from the Big Box o’ Junk Cameras:
Logitech Pro 5000 Ball Camera – overview
It’s a Logitech QuickCam Pro 5000 with a native 640×480 resolution. For no obvious reason, it seems to work better on a Raspberry Pi than the Logitech QuickCam for Notebooks Deluxe I ripped apart a few weeks ago, where “better” is defined as “shows a stable image”. I have no explanation for anything.
Remove the weird bendy foot-like object by pulling straight out, then remove the single screw from the deep hole visible just behind the dent in the top picture:
Logitech Pro 5000 Ball Camera – disassembled
The stylin’ curved plate on the top holds the microphone and a button, neither of which will be of use in its future life. Unplug and discard, leaving the USB cable as the only remaining connection:
Logitech Pro 5000 Ball Camera – USB connector
Inexplicably, the cable shield is soldered to the PCB, so the connector doesn’t do much good. Hack the molded ball off of the cable with a diagonal cutter & razor knife, taking more care than I did to not gouge the cable insulation.
A glue dot locks the focusing threads:
Logitech Pro 5000 Ball Camera – focus glue
Gentle suasion with a needle nose pliers pops the dot, leaving the lens free to focus on objects much closer than infinity:
Since the PiHole runs all the time, it now hosts an FTP server to stash snapshots from the cameras onto a 64 GB USB stick. I installed ProFTPD, which Just Worked with a few configuration tweaks:
UseIPv6 off
ServerName "PiHole"
DefaultRoot /mnt/cameras
RequireValidShell off
ftp_snapshot=true
ftp_host="192.168.1.2"
ftp_port=21
ftp_username=$(/bin/hostname)
ftp_password="make up your own"
ftp_stills_dir=$(/bin/hostname)
The last line uses a separate directory for each camera, although they quickly ran into the FAT32 limit of 64 K files per directory; reformatting the USB stick with an ext3 filesystem solved that problem.
The Smell of Molten Projects in the Morning 