Posts Tagged Improvements
Tour Easy Daytime Running Light: Annotation
Posted by Ed in Machine Shop, Recumbent Bicycling, Software on 2017-08-17
The flashlight mount need not be symmetric after applying all the rotations, so recording how it’s aimed and which end goes forward seemed appropriate:
Fairing Flashlight Mount – Mount Annotation
Optionally, with rounded ends just for pretty:
Fairing Flashlight Mount – Mount Annotation – rounded
Because the rounding comes from resized spheres, the plate gets a ridge along the top to (maybe) lock the nylon screws / wing nuts in place:
Fairing Flashlight Mount – Mount – rounded
Or discourage them from turning, which would be OK, too. After the second tightening, they don’t seem to come loose, so this may be overthinking the problem.
All in all, they look pretty good in cyan PETG:
Fairing Flashlight Mount – rounded
Believe it or not, that’s aimed so the top edge of the beam is roughly horizontal to keep the hot spot out of oncoming traffic. They’re plenty bright, even on the “low power” setting.
The flashlight mounting balls produce a decorative brim that ought to be useful for something:
Slotted ball on platform
Maybe earrings?
The OpenSCAD source code as a GitHub Gist:
Tour Easy Daytime Running Light: Improved Ball Mount
Posted by Ed in Machine Shop, Recumbent Bicycling, Software on 2017-08-11
The original ball around the flashlight consisted of two identical parts joined with 2 mm screws and brass inserts:
Flashlight Ball Mount – flattening fins
Providing enough space for the inserts made the ball bigger than it really ought be, so I designed a one-piece ball with “expansion joints” between the fingers:
Fairing Flashlight Mount – Finger Ball – solid model
Having Slic3r put a 3 mm brim around the bottom almost worked. Adding a little support flange, then building with a brim, kept each segment upright and the whole affair firmly anchored.
Fairing Flashlight Mount – Finger Ball – solid model – support fins
Those had to be part of the model, because I also wanted to anchor the perimeter threads to prevent upward warping. Worked great and cleanup was surprisingly easy: apply the flush cutter, introduce the ball to Mr Belt Sander, then rotate the ball around the flashlight wrapped with fine sandpaper to wear off the nubs.
The joints between the fingers provide enough flexibility to expand slightly around the flashlight body:
Flashlight Mount – finger ball
I made that one the same size as the original screw + insert balls to fit the original clamp, where it worked fine. The clamp ring applies enough pressure to the ball to secure the flashlight and prevent the ball from rotating unless you (well, I) apply more-than-incidental force.
Then I shrank the ball to the flashlight diameter + 10 mm (= 5 mm thick at the equator) and reduced the size of the clamp ring accordingly, which made the whole mount much more compact:
Flashlight Mount – LC40 – finger ball – side
Here’s what the larger mount looks like in action:
The flashlights allegedly puts out 400 lumen in a fairly tight beam. The fairings produce a much larger and brighter glint in full sunlight than the flashlights, so I think they’re about the right brightness.
The OpenSCAD source code for the new ball as a GitHub Gist:
Sandisk 64 GB High Endurance Video Monitoring Card: Verification
Posted by Ed in Photography & Images on 2017-08-09
The Sandisk Extreme Pro 64 GB MicroSDXC (whew) card in the Sony HDR-AS30V had been working fine, but recently the camera crashed in mid-ride after spitting out an unreadable video file. I reformatting the card, which seemed to restore its good humor, and preemptively dropped $36 on a fancy Sandisk High Endurance Video Monitoring Card from a Nominally Reputable Amazon seller:
Sandisk – 64 GB MicroSDXC cards
The package & card production values seem high enough to make me think it’s genuine, despite the white-label thing SanDisk has goin’ on; it matches their website pix closely enough.
Popping it into a USB 3.0 adapter, plugging that into the new-to-me Dell Optiplex 9010’s front-panel USB 3.0 port, and unleashing f3probe produced encouraging results:
sudo f3probe -t /dev/sde
[sudo] password for ed:
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.
WARNING: Probing normally takes from a few seconds to 15 minutes, but
it can take longer. Please be patient.
Probe finished, recovering blocks... Done
Good news: The device `/dev/sde' is the real thing
Device geometry:
*Usable* size: 59.48 GB (124735488 blocks)
Announced size: 59.48 GB (124735488 blocks)
Module: 64.00 GB (2^36 Bytes)
Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
Physical block size: 512.00 Byte (2^9 Bytes)
Probe time: 4'26"
Operation: total time / count = avg time
Read: 2'42" / 4197135 = 38us
Write: 1'41" / 4192321 = 24us
Reset: 1.00s / 1 = 1.00s
Just for completeness, I unleashed f3write to fill it with pseudorandom data:
time f3write /mnt/part Free space: 59.46 GB Creating file 1.h2w ... OK! Creating file 2.h2w ... OK! … snippage … Creating file 59.h2w ... OK! Creating file 60.h2w ... 99.99% -- 5.40 MB/s -- 1sf3write: Write to file /mnt/part/60.h2w failed: Input/output error real 180m36.861s user 0m40.520s sys 6m44.024s
Dividing 64 GB by 180 minutes says the write speed works out to 5.9 MB/s, about a third of the “up to 20 MB/s” in the card’s specs. Huh.
Reading & comparing the data goes faster:
time f3read /mnt/part
SECTORS ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/ 0/ 0/ 0
Validating file 2.h2w ... 2097152/ 0/ 0/ 0
… snippage …
Validating file 59.h2w ... 2097152/ 0/ 0/ 0
Validating file 60.h2w ... 965376/ 0/ 0/ 0
Data OK: 59.46 GB (124697344 sectors)
Data LOST: 0.00 Byte (0 sectors)
Corrupted: 0.00 Byte (0 sectors)
Slightly changed: 0.00 Byte (0 sectors)
Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 23.87 MB/s
real 42m31.288s
user 0m47.444s
sys 0m30.232s
So it reads lickety-split, but writes much more slowly. Fortunately, the HDR-AS30 camera pops out a 4 GB file every 22.75 minute = 2.9 MB/s, so the card has a smidge of headroom while writing.
The specs claim “up to 10,000 hours” of Full HD recording. If so, I’m looking at a card good for “up to 40 years“ of riding at 1 hour/ride and 250 ride/year. For 36 bucks, how can ya go wrong?
I’ll take it for a few rides to see what happens …
The packaging includes a link to a Windows / Mac data recovery program, plus the serial number required to activate the download. I’ll continue to eke out a miserable existence with ordinary Linux disk / file maintenance tools, as I’m no longer enthused about “free” programs requiring secret handshakes for activation on a single computer with an OS I no longer use, particularly a program that auto-pumpkinates after a year:
Please fill in the data accurately as this information will be needed to reactivate the software if you ever need to move the software to a different computer.
Your expectations & preconceptions may vary.
Quartz Resonator Test Fixture: Cleanup
Posted by Ed in Amateur Radio, Electronics Workbench on 2017-08-08
Isolating the USB port from the laptop eliminated a nasty ground loop, turning off the OLED while making measurements stifled a huge noise source, and averaging a few ADC readings produced this pleasing plot:
Resonator 0 Spectrum
Those nice smooth curves suggest the tester isn’t just measuring random junk.
The OLED summarizes the results after the test sequence:
LF Crystal Tester – OLED test summary – Resonator 0
Collecting all the numbers for that resonator in one place:
- C0 = 1.0 pF
- Rm = 9.0 kΩ
- fs = 59996.10 Hz
- fc = 59997.79 Hz
- fc – fs = 1.69 Hz
- Cx = 24 pF
Turning the crank:
CC 2017-11 – Resonator 0 Calculations
I ripped that nice layout directly from my November Circuit Cellar column, because I’m absolutely not even going to try to recreate those equations here.
Another two dozen resonators to go …
Torchiere Lamp Shade
Posted by Ed in Home Ec, Machine Shop, Software on 2017-08-02
A pair of torchiere lamps lit the living room for many, many years:
Torchiere Lamp Shade – original
During their tenure, they’ve gone from 100 W incandescent bulbs to “100 W equivalent” CFL curlicues to “100 W equivalent” warm-white LED bulbs. The LEDs aren’t up to the brightness of the original incandescents, but you can get used to anything if you do it long enough.
After so many years, the plastic shades / diffusers became brittle:
Torchiere Lamp Shade – original broken
That’s after a bump, not a fall to the floor. So it goes.
Some casual searching didn’t turn up any likely replacements. The shade measures 14 inch = 355 mm across the top, far too large for the M2’s platform, but maybe a smaller shade in natural PETG would work just as well.
ACHTUNG! This is obviously inappropriate for the original incandescent bulbs and would be, IMO, marginal with CFL tubes. Works fine with LEDs. Your mileage may vary.
OpenSCAD to the rescue:
Torchiere Lamp Shade – section
That’s a section down the middle. The top is 180 mm across, leaving 20 mm of general caution on the 200 mm width of the platform. The section above the sharply angled base is 90 mm tall to match the actual LED height, thereby putting them out of my line-of-sight even when standing across the room.
I ran off a short version, corrected the angles and sizes for a better fit, tweaked the thickness to fuse three parallel threads into a semitransparent shell, and …
Torchiere Lamp Shade – M2 platform
Producing what looks like thin flowerpot required just shy of seven hours of print time, as it’s almost entirely perimeter, goin’ down slow for best appearance. The weird gold tone comes from the interaction of camera flash with warm-white CFL can lights over the desk.
If you hadn’t met the original, you’d say the new shade grew there:
Torchiere Lamp Shade – no epoxy
It’s definitely a Brutalist design, not even attempting to hide its 3D printed origin and glorying in those simple geometric facets.
Those three threads of natural PETG makes a reasonably transparent plate, clear enough that the bulb produced an eye-watering glare through the shade:
Torchiere Lamp Shade – no epoxy – lit
So I returned it to the Basement Laboratory, chucked it up in the lathe (where it barely clears the bed), dialed the slowest spindle speed (150 rpm according to the laser tach, faster than I’d prefer), and slathered a thin layer of white-tinted XTC-3D around the inside:
Torchiere Lamp Shade – lathe spinning
For lack of anything smarter, I mixed 2+ drops of Opaque White with 3.1 g of Part A (resin), added 1.3 g of Part B (Hardener), mixed vigorously, drooled the blob along the middle of the rotating shade, spread it across the width using the mixing stick, smoothed it into a thin layer with a scrap of waxed paper, and ignored it for a few hours.
If the lathe perspective looks a bit weird, it’s perfectly natural: I raised the tailstock end enough to make the lower side of the shade just about horizontal. Given the gooey nature of XTC-3D, it wasn’t going anywhere, but I didn’t want a slingout across the lathe bed.
The lit-up result isn’t photographically different from the previous picture, but in person the epoxy layer produces a much nicer diffused light and no glare.
I might be forced to preemptively replace the other shade, just for symmetry, but we’ll let this one age for a while before jumping to conclusions.
The OpenSCAD source code as a GitHub Gist:
Optiplex 9010: Xsetwacom vs. Dual Monitors
Posted by Ed in PC Tweakage, Software on 2017-07-31
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 HEAD-0:
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 …
Raspberry Pi vs. Music via NFS
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:
Install rpcbind and 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.
Set up /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 …
Blowback