Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Tag: Improvements
Making the world a better place, one piece at a time
With three identical Raspberry Pi streaming players tootling around the house, it finally dawned on me that they should fetch their Python program directly from The Definitive Source, rather than a local copy.
Tweak the auto-startup in /etc/rc.local:
mount -o ro mollusk:/mnt/bulkdata/Project\ Files/Streaming\ Media\ Player/Firmware/ /mnt/part
sudo -u pi python /mnt/part/Streamer.py &
There’s probably a way to redirect all of the stdout and stderr results to a file for debugging, but the obvious method doesn’t work:
sudo -u pi sh -c "python /mnt/part/Streamer.py 2>&1 > /tmp/st.log" &
That redirects stdout from the subprocess call to set up the mixer, but doesn’t catch Python’s print output.
Using the Python logging library would get most of the way to the goal, although stdout from things like the mixer would still vanish.
Continuing with the network theme, one could netboot the RPi players, but that requires more sysadmin hackery than I’m willing to do, what with the good being the enemy of the best.
The two upper curves show the first two charges for those eight cells back in 2010.
The lower curve(s) started out with the wrong endpoint voltage (purple part of the middle curve), so I restarted the test (green curve) and edited the graph image to splice the two curves together into the purple/red curve.
Although the capacity measured in mA·h isn’t much lower, the voltage depression reduces the available energy and trips the “low battery” alarm much earlier. In round numbers, the old cells were good for a few pictures, even hot off the charger, and didn’t have much energy left without being recharged before use.
A quartet of Panasonic Eneloop Pro cells just arrived from BatterySpace, a nominally reputable supplier, all sporting a 14-05 date code suggesting they’re just shy of two years old. The packaging claims 85% charge retention after a year, so they should have a bit more than half of their rated 2.45 A·h “minimum” (or 2.55 mA·h “typical”, depending on whether you trust the label on the cell or the big print on the package) capacity remaining (although we don’t know the original state of charge, done from “solar power”). The lower curves say they arrived with 1 A·h remaining:
Panasonic Eneloop – First Charge
However, the terminal voltage on those bottom curves would have any reasonable device reporting them as dead flat almost instantly, so you really can’t store Eneloops for two years: no surprise there.
One pass through the 400 mA Sony charger produced the upper curves, with the dotted red curve from Cell A lagging in the middle. After that test, another pass through the charger brought Cell A back (upper solid red line) with the others, so I’ll assume it took a while to wake up.
A pair of these in the camera will produce 2.2 V through 2.2 A·h, far better than the aged-out Sanyo Eneloops.
Charging them at 400 mA = C/6 certainly counts as a slow charge. I’ve been charging the Sanyo cells in slow chargers in the hope that they’ll remain happier over the long term.
It seems that two years is about as long as the NP-FS11 batteries last, as shown by the two lower curves from the ones I rebuilt in December 2013 with cells from 2011:
Sony NP-FS11 2011-2016 Packs
The two middle curves with those same colors show the “back then” performance of those batteries: they’re shot in both total capacity and terminal voltage.
I bought enough cells back in 2011 to leave two cells unused until now, which I built into a pack and charged. The green curve in the middle shows the result: those cells haven’t lost anything over the last five (!) years, as their performance still matches the other two batteries when they were new.
The red curves come from a pair of batteries made with fresh new cells from batteryspace.com. They’re nominally 650 mA·h cells, so the NP-FS11 configuration (two parallel cells) should produce 1300 mA·h; surprisingly, they show 1500 mA·h with a nice voltage curve.
So, although the 2011 cells work as well as their (now defunct) siblings, that pack can’t deliver the same capacity as the new cells. I expect I’ll rebuild it with 2016 cells in about a year.
For whatever it’s worth, rebuilding these batteries goes much faster when I don’t have to saw them open. The Kapton tape wrapped around the case halves secures them well enough; there’s no need for fancy gluing.
NP-FS11 Battery Rebuilds – 2016-03
Yeah, I should make better labels. It’s hard to form a deep emotional attachment to the poor things, though.
Here’s a case where something performs better than expected; I don’t always buy cheap junk from the usual eBay vendor…
Although Mary liked the illumination from her OttLite (an old 13 W fluorescent Folding Task Lamp), neither of us liked its tiny base and tippy nature. It recently fell / was dropped / jumped to its doom, smashing the CFL tube and wreaking havoc on the tiny plastic studs holding its large cast-iron weight and steel base in position. Given that the CFL ballast had started humming a while ago, I took it apart to see whether I could salvage anything from the rubble.
Remove:
Four screws under the fuzzy felt feet
One screw under the label on the back
A final screw that becomes visible only after disemboweling the hinge assembly by unscrewing the obvious endcaps:
OttLite LED Conversion – hinge screw
Pull the hinge end of the white inside panel away from the outer stand at enough of an angle to disengage all three latches holding it to the base, then remove it just enough to let you start cutting wires around the ballast…
I rebuilt the thing with a pair of 24 V 150 mA warm-white LED panels (good industrial surplus, not the usual cheap eBay crap) powered by a 19 V laptop adapter (from IBM, no less) through a (cheap eBay) boost converter sticky-foam-taped where the fluorescent ballast used to live:
OttLite LED Conversion – boost supply wiring
The power supply had only two conductors, the central wire surrounded by twisted shielding, and didn’t require a fussy interface. Hooray for simple bulk power supplies; I lopped off the connector and soldered the wires directly to the boost converter.
The original lamp wiring has a 120 VAC switch inside the hinge that turned the lamp on as you raise the arm holding the CFL tube: exactly what I need for its new use. That eliminated figuring out how to crack the arm apart to rewire it.
I harvested the base from a(nother) defunct CFL bulb:
OttLite LED Conversion – harvested CFL base
By soldering wires directly into the pins, I could reuse the existing CFL socket in the lamp arm, the existing wiring, and the switch.
The LED panels dissipate 3-ish W each:
OttLite LED Conversion – LED panel layout
They’re mounted on a 0.1 inch aluminum sheet from the heap that required exactly one saw cut to fit into the space available, so I defined it to be perfect. The 4-40 screws holding the panels in place continue through the plate and 3/8 inch aluminum standoffs into a quartet of knurled inserts epoxied into eyeballometrically match-drilled holes in the lamp arm:
OttLite LED Conversion – epoxied threaded inserts
The faint yellowish discoloration from the CFL tube’s heat and UV is much more visible in real life, but nobody will ever see it again. The scrawled blue (+) and (-) marks give the socket polarity; it’s not mechanically polarized and a bit of care is in order. The black rectangle is actually a shiny metal sheet intended to reflect heat from the CFL tube’s base away from the plastic arm.
I set the boost converter to 23.5 V, at which point the LED panels draw about 100 mA each and get just over uncomfortably warm after an hour or two:
OttLite LED Conversion – in action
The panels run 120 °F = 50 °C and the SMD LEDs probably exceed 150 °F = 65 °C. The scant surplus doc touted “No heatsink required” and the single-sided FR4 PCB insulates the LEDs from the aluminum sheet, but I still smeared some heatsink compound behind the panels in the hopes of spreading the heat out a bit.
I glued the shattered base studs back in place with IPS #3, surrounded them with generous epoxy fillets, plunked the cast iron weight in place atop some waxed paper to mold the epoxy to fit (and let me remove it again, if needs be), screwed everything together, and stuck a foam sheet over the steel base plate. It’s as tippy as before, but at least the LEDs won’t shatter if when it falls. It really needs a larger base; a polycarbonate plate might work, if only I could figure out how to attach it.
All in all, the lamp looks good and the warm-white LEDs with DC drive don’t produce that horrible fluorescent flicker.
The lamp now sports a label identifying it as a NisLite; because P-Touch labeler.
After taking the incandescent lamp socket off its base, I drilled the tapped (yeah, in plastic) 6-32 holes out to a firm press fit for the knurled 6-32 inserts, buttered the inserts with epoxy, and pressed them firmly in place:
Lamp Base – epoxy knurled insert
Fast forward a day and they’re stuck in there like they were glued. You can see a bit of the epoxy around the right rim of the insert; I wiped a bit more off around the other one.
Putting The Right Amount of epoxy on the insert requires dialing back my “The bigger the blob, the better the job” enthusiasm, but wasn’t all that difficult. It’s certainly more tedious than just ramming the inserts into a printed hole and might actually produce better retention. I doubt that will make the least difference for (almost) anything I build.
That shredded plastic can’t possibly be a Good Thing; the endcap contained plenty of loose shreds.
Perhaps I’m overly critical, but I think the only way these fixtures could have a UL approval certificate was that somebody else didn’t notice their certificate went missing. Most likely, of course, the fixtures sent for approval looked lovely and bore no relation to the junk actually sold to Lowe’s / Home Depot.
The least horrible way to get events from the keypad turned out to be a simple non-blocking poll from Python’s select library, then sucking the event input queue dry; the main loop now does what might be grandiosely overstated as cooperative multitasking. Well, hey, it reads lines from mplayer’s output pipe and processes keypad events and doesn’t stall (for very long) and that’s multi enough for me.
It extracts the stream title from the ICY Info line, but I still haven’t bothered with a display. It may well turn out that this thing doesn’t need a display. The stream title will be enclosed in single quotes, but it may also contain non-escaped and non-paired single quotes (a.k.a. apostrophes): the obvious parsing strategy doesn’t work. I expect titles can contain non-escaped semicolons, too, which will kill the algorithm I’m using stone cold dead. Some try - except armor may be appropriate.
This code does not tolerate a crappy WiFi connection very well at all. I eventually replaced a long-antenna WiFi adapter with an actual Ethernet cable and all the mysterious problems at the far end of the house Went Away. Soooo this code won’t tolerate random network stream dropouts very well, either; we’ll see how poorly that plays out in practice.
The hackery to monitor / kill / restart / clean up after mplayer and its pipes come directly from seeing what failed, then whacking that mole in the least intrusive manner possible. While it would be better to wrap a nice abstract model around what mplayer is (assumed to be) doing, it’s not at all clear to me that I can build a sufficiently durable model to be worth the effort. Basically, trying to automate a program designed to be human-interactive is always a recipe for disaster.
The option for the Backspace / Del key lets you do remote debugging by editing the code to just bail out of the loop instead of shut down. Unedited, it’s a power switch: the Pi turns off all the peripherals and shuts itself down. The key_hold conditional means you must press-and-hold that button to kill the power, but don’t run this on your desktop PC, OK?
Autostarting the program requires one line in /etc/rc.local:
sudo -u pi python /home/pi/Streamer.py &
AFAICT, using cron with an @REBOOT line has timing issues with the network being available, but I can’t point to any solid evidence that hacking rc.localwaits until the network is up, either. So far, so good.
I make no apologies for any of the streams; I needed streams behind all the buttons and picked stuff from Xiph’s listing. The AAC+ streams from the Public Domain Project give mplayer a bad bellyache; I think its codecs can’t handle the “+” part of AAC+.
All in all, not bad for a bit over a hundred lines of code, methinks…
More fiddling will happen, but we need some continuous experience for that; let the music roll!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Smell of Molten Projects in the Morning 