Archive for July, 2017
Having replaced the Dell Optiplex 980 (running from an eBay NOS power supply) with an off-lease Optiplex 9010, I was mildly surprised to find two Displayport outputs from the built-in Intel graphics chipset. Not being a gamer, I don’t care much about graphic performance, but plugging two 2560×1440 monitors into the jacks and having them Just Work was delightful. Indeed, Dell even managed to
fix work around the error in the U2711 firmware requiring me to power-cycle the damned thing before booting the PC; now I can just turn the PC on and It Just Works.
Mysteriously, the incantation required to limit the Wacom tablet to the left-hand landscape monitor now uses
DP1 instead of
xsetwacom --verbose set "Wacom Graphire3 6x8 stylus" MapToOutput "DP1" xsetwacom --verbose set "Wacom Graphire3 6x8 eraser" MapToOutput "DP1" #xsetwacom --verbose set "Wacom Graphire3 6x8 Pen stylus" MapToOutput "HEAD-0" #xsetwacom --verbose set "Wacom Graphire3 6x8 Pen eraser" MapToOutput "HEAD-0"
I’ll leave the “HEAD-0 incantations as comments, so as to have a hint the next time …
Every now & again, streaming music from distant servers fails, for no reason I can determine. In that situation, it would be nice to have a local source and, as
mplayer works just fine when aimed at an MP3 file, I tried to set up a USB stick on the ASUS router.
That requires getting their version of SAMBA working with the Raspbian Lite installed on the streaming players. After screwing around for far too long, I finally admitted defeat, popped the USB stick into the Raspberry Pi running the APRS iGate in the attic stairwell, and configured it as an NFS server.
To slightly complicate the discussion, there’s also a file server in the basement which turns itself off after its nightly backup. The local music files must be available when it’s off, so the always-up iGate machine gets the job.
On the NFS server:
nfs-common, both of which should already be included in stock Raspbian Lite, and
nfs-kernel-server, which isn’t. There were problems with earlier Raspbian versions involving the startup order which should be history by now; this post may remind me what’s needed in the event the iGate NFS server wakes up dead after the next power blink.
/etc/exports to share the mount point:
/mnt/music *(ro,async,insecure,no_subtree_check) # blank line so you can see the underscores in the previous one
Plug in the USB stick, mount, copy various music directories from the file server’s pile o’ music to the stick’s root directory.
Create a playlist from the directory entries and maybe edit it a bit:
ls -1 /mnt/part/The_Music_Directory > playlist.tmp sed 's/this/that/' < playlist.tmp > playlist.txt rm playlist.tmp
Tuck the playlist into the Playlists directory on the basement file server, from whence the streamer’s
/etc/rc.local will copy the file to its local directory during the next boot.
On every streamer, create the
/mnt/music mountpoint and edit
/etc/rc.local to mount the directory:
nfs_music=192.168.1.110 <<< snippage >>> mount -v -o ro $nfs_music:/mnt/music /mnt/music # blank line so you can see the underscores in the previous one
In the Python streaming program on the file server, associate the new “station” with a button:
'KEY_KP8' : ['Newname',False,['mplayer','-shuffle','-playlist','/home/pi/Playlists/playlist.txt']],
The startup script also fetches the latest copy of the Python program whenever the file server is up, so the new version should Just Work.
I set the numeric keypad button associated with that program as the fallback in case of stream failures, so when the Interwebs go down, we still have music. Life is good …
The display on Mary’s favorite little calculator (remember calculators?) faded away and, of course, this appeared when I popped the back:
A touch of vinegar, some scrubbing, and new cells restored it to good health.
That was easy …
The LEDs adorning the 0D3 rectifier tube became unreliable:
After failing to plug in a different USB power supply, a close look at the USB connector showed the problem:
I tried applying the world’s smallest dot of epoxy to the fracture, probably slobbered epoxy along the pins while reinserting it, and the Nano still doesn’t light up.
Given that knockoff Nano boards cost a touch over two bucks delivered, it’s not clear transplanting a connector from one of the never-sufficiently-to-be-damned counterfeit FTDI USB adapters makes any sense.
The nice 1-¼ inch stainless socket-head cap screws replace the 1 inch pan-head screws that engaged maybe one thread due to the additional spacer between the USB port and the upper hard drive platter I added for good looks.
I tried a few iterations of an aluminized Mylar (*) disk with various sized pinholes over the RGB trio to crisp up the filament shadow, because the SK6812 LED casts a more diffuse light than the W2812 LEDs:
Even the ⅛ inch pinhole made the bulb too dim, so I settled for a fuzzy shadow:
The firmware has a tweak forcing the white LED to PWM=0, because this bulb looks better in saturated colors.
(*) Here on earth, aluminized Mylar is nonconductive.
Some weeks ago, the APRS + voice adapter on my radio began randomly resetting during our rides, sending out three successive data bursts: the TinyTrak power-on message, an ID string, and the current coordinates. Mary could hear all three packets quite clearly, which was not to be tolerated.
I swapped radios + adapters so that she could ride in peace while I diagnosed the problem, which, of course, was both intermittent and generally occurred only while on the road. The TinyTrak doc mentions “… a sign of the TinyTrak3 resetting due to too much local RF energy”, so I clamped ferrite cores around All! The! Cables! and the problem Went Away.
Removing one core each week eventually left the last core on the GPS receiver’s serial cable, which makes sense, as it plugs directly into the TT3. The core had an ID large enough for several turns (no fool, I), another week established a minimum of three turns kept the RFI down, so I settled for five:
Prior to the RFI problem cropping up, nothing changed. Past experience has shown when I make such an assertion, it means I don’t yet know what changed. Something certainly has and not for the better.
I swapped the radios + adapters and all seems quiet.
Pending more test rides, the flashlight fairing mount works well:
Despite all my fussing with three rotational angles, simply tilting the mount upward by 20° with respect to the fairing clamp aims the flashlight straight ahead, with the ball nearly centered in the clamp:
That obviously depends on the handlebar angle and the fairing length (which affects the strut rotation), but it’s close enough to make me think a simpler mount will suffice: clamp the flashlight into a cylinder with a slight offset angle, maybe 2°, then mount the cylinder into a much thinner ring clamp at the 20° tilt. Rotating the cylinder would give you some aim-ability, minus the bulk of a ball mount.
Or dispense with the separate cylinder, build the entire mount at the (now known) aim angle, clamp the flashlight directly into the mount, then affix mount to fairing strut. Rapid prototyping FTW!
For now, it’s great riding weather …
The OpenSCAD source code as a GitHub Gist: