Posts Tagged Improvements
Streamripper Setup
The Intertubes occasionally clog up while streaming low-bit-rate audio, for no reason I can fathom, leading to discontent in the User Community when it affects quiet classical music played in the dead of night. Given that the stream from far-off Switzerland consists entirely of public-domain performances, I set up Raspbian Lite on a headless Raspberry Pi 1 Model B+ in a spot where it won’t be disturbed:
Raspberry Pi 1 for streamripper
Connecting to the Pi with a screen session, so as to allow disconnection & reconnection without anguish, I fired streamripper thusly:
streamripper http://relay.publicdomainproject.org/classical.mp3.m3u -xs2 -o larger -u "MPlayer2" -m 30 -r -R 6 --with-id3v1
The -r -R 6 options set up a relay stream on http://ripper.local:8000 for the benefit of my local streamers, so only one trickle of bits crosses the Atlantic.
The total CPU load amounts to a percent or two, tops, so a single-core 700 MHz Pi has no trouble keeping up.
Because streamripper slings bits in more-or-less real time, the local servers don’t get any track title data when they start up, so the OLED display doesn’t update immediately. This is less of a problem than you might think, as we’re generally not hanging on the display to find out exactly which Vivaldi bassoon concerto is playing.
Given a suitable collection of tracks, I’ll set up an icecast server as the classical music “station” for the streamers, but that’s an adventure for another day. I also want to splice separate movements back into continuous symphonies, the way they’re suppose to be heard.
Refurbished LED Panels
Posted by Ed in Electronics Workbench on 2018-09-18
A recent Squidwrench meeting produced a treasure trove of discarded LED lighting, including a shoplight-style fixture in a narrow, finned aluminum extrusion. It was in “known-bad” condition, so I extracted the four LED panels, connected each one to a widowmaker cord, and determined I had two good ones, a mostly working one sporting some dead LEDs, and a corpse.
The working panels showed the power supplies produced about 19 V across two parallel strings of six LEDs, with each string running at 350 mA for a total of 700 mA = 13 W. I wired up a quartet of 6 Ω power resistors to check out the power supplies from the suspect panels:
LED Panel – power supply test setup
The supply in the background is truly dead. I can’t tell whether it killed the LEDs or the gaggle of failing LEDs dragged it down with them.
Some multimeter probing revealed enough live LEDs to restore the partially working panel. A rather sweaty interlude at the SqWr hot-air rework station transplanted the good LEDs, whereupon combining it with the live supply gave me a third fully functional panel:
LED Panel – restored
I did the test firing in the Basement Laboratory, because I’m nowhere near crazy enough to deploy a widowmaker line cord on the SqWr Operating Table in public.
I bandsawed the last working LED from the gutted donor panel:
LED Panel – single LED test
The SMD LEDs mount on traces applied to and electrically insulated from the aluminum sheet, so unsoldering them required way more heat than you (well, I) might expect at first glance. A snap-on condenser lens over each LED concentrates the light into a nice cone, producing a narrow sheet of light from each panel.
The elaborate aluminum extrusion seems much too heavy for the individual panels, but those open-frame supplies definitely need more than casual protection. Now that LEDs are more common than when these panels came off the assembly line, I should probably replace the supplies with enclosed constant-current drivers and be done with it.
GIMP Menu Verbiage
GIMP seems to set up its menu structure during installation, with sensible, if lengthy, hardcoded addresses and menu names for your remote (network) scanner based on its host and USB port location:
(proc-def "xsane-net-3a-plex760-2e-local-3a-genesys-3a-libusb-3a-002-3a-002" 2 … snippage … (menu-path "<Image>/File/Create/Acquire/XSane/net:plex760.local:genesys:libusb:002:002")
Should you happen to plug the scanner into a different PC or USB port, perhaps while replacing a failed system, then you must change those hideous strings all by yourself.
So, for example, plugging the aforementioned scanner into a randomly chosen USB port on a new-to-me Dell Optiplex 9020 showing up as plex9020.local on the network produces this identification string:
[ed@shiitake ~]$ scanimage -L device `net:plex9020.local:genesys:libusb:003:003' is a Canon LiDE 120 flatbed scanner
GIMP’s ~/.gimp-2.8/pluginrc file defines the device address:
(proc-def "xscanimage-net-3a-plex9020-2e-local-3a-genesys-3a-libusb-3a-003-3a-003" 2
The -3a- string seem to be an escape sequence for the colon symbol separating parts of the address. Why we need so many different escape sequence standards mmm escapes me at the moment.
The menu-path string defines the text appearing in the GIMP UI, so you can use a somewhat more readable generic name:
(menu-path "<Image>/File/Create/Acquire/xscanimage/Plex9020-scanner")
The ~/.gimp-2.8/menurc file contains GIMP’s keyboard accelerators, which (apparently) must match the revised proc-def strings:
; (gtk_accel_path "<Actions>/plug-in/xscanimage-net-3a-plex9020-2e-local-3a-genesys-3a-libusb-3a-003-3a-003" "")
A keyboard accelerator for the scanner wouldn’t save any appreciable amount of time or effort, so (I think) the semicolon marks it as Disabled in the UI.
It is remarkably easy to make a one-character typo while doing this, particularly if you’re using sed to change All. The. Strings. at once.
There is, AFAICT, no documentation, which almost certainly means I don’t know where to look.
SANE Scanner vs. Xubuntu 18.04
Posted by Ed in PC Tweakage on 2018-09-12
I recently bumped the desktop PC with the scanner from an old Mint to Xubuntu 18.04, which killed a day with all the system and UI tweakage.
The old guides for setting up a networked SANE scanner became inoperative with systemd ruling the configurations, so, after some flailing around, I found a newer guide referencing a guide for USB scanners and pointing to a deeper guide for network sharing in the age of systemd.
The USB guide points out the existence of Access Control Lists for the various device files, which I didn’t know was a thing. AFAICT, you must still be in the scanner group for remote access to happen.
I lost track of the changes during all the flailing around, but it definitely didn’t Just Work.
I’m sure all this will change before I must do it again.
Streaming Radio Player: I2C Display
Posted by Ed in Electronics Workbench, Software on 2018-09-10
Although I2C on the Raspberry Pi fails with devices using clock stretching, cheap I2C OLED displays seem to work well enough to not generate any problems search-able with the obvious keywords:
RPi I2C OLED
Given a picture of the header pinout, the wiring is trivially easy:
RPi I2C OLED – RPi header detail
Using yellow for the ground hurts a bit, but that’s what I get for peeling the SPI cable down to four wires. The pin directly adjacent to the green wire is also ground, should that be easier to reach.
Tweaking the Luma driver to use I2C doesn’t require much:
#from luma.core.interface.serial import spi from luma.core.interface.serial import i2c ... snippage ... # reduce SPI bus from default 8 MHz to (maybe) avoid OLED failure-to-start #serial = spi(device=0,port=0,bus_speed_hz=1000000) # use I2C bus to avoid SPI timing spec failure serial = i2c(port=1,address=(0x78 >> 1)) # PCB label = 0x78, low bit = R/W
The OLED PCB lists the I2C address with the R/W bit
And then It Just Works, with one gotcha. Although the Python program shuts itself and the system down, the wall wart continues to supply power and, because the I2C bus doesn’t include a Reset line, the OLED display doesn’t know the RPi has gone away. So you must issue a command to turn it off before shutting down:
device.cleanup() # ideally, switches to low-power mode rc = subp.call(['sudo','shutdown','-P','now'])
Now, to discover what works … oddly … with these displays.
Monthly Science: Monarch Caterpillars!
After several years of seeing few-to-no Monarch butterflies, last year we managed to save a single Monarch egg, raise the caterpillar, and release it:
Monarch on Milkweed – left
This year, we’ve seen more, if not many, Monarchs in flight. They’re not abundant, but perhaps there’s hope.
A Monarch evidently laid eggs in our milkweed patch, with at least two offspring surviving:
We decided to let them seek their own destiny; may the odds be ever in their favor …
Shapely Fire Hydrant
Posted by Ed in Machine Shop, Oddities on 2018-08-25
A Sigelock Spartan hydrant spotted in Franklin PA:
Sigelock Spartan fire hydrant – Franklin PA
It’s certainly the shapeliest hydrant I’ve ever seen.
Of course, you need a special tool to remove the main cap, after which some internal lockwork releases the side caps, after which you can spin the valve stem recessed under the top cover. One hopes all those little bits continue sliding and releasing after a few decades, but … the status quo apparently isn’t all that good, either.
Blowback