Tour Easy: PTT Switch Replacement

The PTT switch on Mary’s Tour Easy became intermittent:

Tour Easy - failed PTT switch
Tour Easy – failed PTT switch

It’s been sitting there for least five years, as witnessed by the sun-yellowed hot melt glue blob, which is pretty good service from a switch intended for indoor use. The 3D printed button never fell off and, in fact, was difficult to remove, so that worked well.

I took it apart and cleaned the contacts, but to no avail, so her bike now sports a new switch with a similar rounded dome:

Tour Easy - new PTT switch
Tour Easy – new PTT switch

I clipped the wires a bit beyond the terminals and soldered the new switch in place, so it’s the same cable as before.

Now, to see how long this one lasts …

Rail Trail Tree Clearing

Trees along the Dutchess Rail Trail fall over for no obvious reason and sometimes block the path:

DCRT Fallen Tree - 1 - 2019-08-29
DCRT Fallen Tree – 1 – 2019-08-29

But my tool hand is strong:

DCRT Fallen Tree - 2 - 2019-08-29
DCRT Fallen Tree – 2 – 2019-08-29

The DPW folks can haul off the trunk, as it’s more than I can move.

Floor Sweepings from eBay

Ordered 100 stainless steel M3 washers from a “US Seller”, received this:

M3 stainless steel washers - short count
M3 stainless steel washers – short count

Yeah, it looked a bit short to me, too.

The chopped and bent washers in the upper right corner suggest the seller got floor sweepings from his source, which is about what you’d expect for a bottom-dollar vendor.

The seller refunded half, which wasn’t particularly generous, but I wasn’t ready to go to the mat for two bucks.

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.

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
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":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S8 S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: [8 16]
FRAME_BITS: [8 32]
CHANNELS: [1 2]
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]
TICK_TIME: ALL
--------------------
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
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 …

CNC 3018-Pro: Table Riser

With the 3018-Pro used for drag engraving on CDs and hard drive platters, there’s no need for all the clearance below the Z-axis carriage required for the OEM motor and ER11 collet chuck. A chunk of laminate countertop and a hunk of Celotex foam insulation produce a nicely flat surface 47 mm above the platform:

CNC 3018 Table Riser
CNC 3018 Table Riser

It’s surprisingly flat:

Table Flatness Measurement - 2019-08-30
Table Flatness Measurement – 2019-08-30

Those are millimeters of clearance between the gray plastic clamp around the diamond drag tool holder (about which, more later) and my trusty bench block, measured at 50 mm intervals across the platform. The lower figures appeared after tightening the upper-left screw by a little over 1/6 turn = 0.2 mm, making the entire platform flat & aligned within ±0.1 mm.

Yeah, not bad for a scrap countertop!

The four M6 socket head cap screws pass through the stack into T-nuts in the platform:

CNC 3018 Table Riser - screw clearance
CNC 3018 Table Riser – screw clearance

The countertop was thick enough to allow countersinking the screws slightly below the surface:

CNC 3018 Table Riser - screw countersink
CNC 3018 Table Riser – screw countersink

I transfer-punched the screw clearance hole locations into the Celotex and drilled it with an ordinary twist drill. It wasn’t pretty, but nobody will ever notice.

Two sheets, maybe 1 mm thick, of closed-cell foam below the Celotext provide enough squish to align the top surface without straining anything. The screws are firmly tight, so they shouldn’t work their way loose under minimal engraving loads.

Taping the CDs to the surface works well for now, although a simpler version of the fixture may be in order.

CNC 3018-Pro: Probe Camera Case for Anonymous USB Camera

The anonymous USB camera I used with the stereo zoom microscope not only works with VLC, but also with bCNC, and it has a round PCB with ears:

CNC 3018-Pro - Probe Camera - PCB
CNC 3018-Pro – Probe Camera – PCB

Which suggested putting it in a ball mount for E-Z aiming:

CNC 3018-Pro - Probe Camera - ball mount
CNC 3018-Pro – Probe Camera – ball mount

Black filament snippets serve as alignment pins to hold the ball halves together while they’re getting clamped. They’re epoxied into the upper half of the ball, because who knows when I’ll need to harvest the camera.

The clamp mount descends from the Tour Easy Daytime Running Lights, with more screws and less fancy shaping:

USB Camera - Round PCB Mount - solid model - build
USB Camera – Round PCB Mount – solid model – build

The clamp pieces fit around the ball with four M3 screws providing the clamping force:

USB Camera - Round PCB Mount - solid model sectioned
USB Camera – Round PCB Mount – solid model sectioned

The whole affair sticks onto the Z axis carrier with double-sided foam tape:

CNC 3018-Pro - Probe Camera - alignment
CNC 3018-Pro – Probe Camera – alignment

It barely clears the strut on the -X side of the carriage, although it does stick out over the edge of the chassis.

After the fact, I tucked a closed-cell foam ring between the lens threads and the ball housing to stabilize the lens; the original camera glued the thing in place, but some fiddly alignment & focusing lies ahead:

Alignment mirror - collimation
Alignment mirror – collimation

It’s worth noting that the optical axis of these cheap cameras rarely coincides with the physical central axis of the lens. This one requires a jaunty tilt, although it’s not noticeable in any of the pictures I tried to take.

All in all, this one works just like the probe camera on the MPCNC.

The OpenSCAD source code as a GitHub Gist: