Posts Tagged Repairs

Raspberry Pi Boot vs. Avahi vs. DHCP

Sometimes, one of our homebrew streaming media players will emerge from reset without starting up properly. The system board LEDs blink more-or-less normally, but the WiFi activity monitor seems … odd. This post documents the results of some exploratory surgery hinting at a possible solution.

I set the router’s DHCP server to assign a fixed IP address to each of our homebrew streaming media players based on its MAC address. That seemed less horrible than setting a static IP address in each player’s configuration, although I could see advantages to either approach. For streamer1, the player discussed here, the IP address is 192.168.1.101; that’s a non-routable address used only on our network behind the router.

During the Raspberry Pi’s boot, the default /etc/rc.local script finds and displays its IP address:

_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

The /var/log/boot log showed this after one boot:

--- snippage ---
         Starting LSB: Raise network interfaces....
---
[  OK  ] Started LSB: Raise network interfaces..
         Starting ifup for wlan0...
[  OK  ] Started ifup for wlan0.
[  OK  ] Reached target System Initialization.
[  OK  ] Listening on Avahi mDNS/DNS-SD Stack Activation Socket.
---
[  OK  ] Reached target Sockets.
---
[  OK  ] Reached target Basic System.
         Starting Avahi mDNS/DNS-SD Stack...
         Starting Regular background program processing daemon...
[  OK  ] Started Regular background program processing daemon.
         Starting dhcpcd on all interfaces...
---
[  OK  ] Started Avahi mDNS/DNS-SD Stack.
---
[  OK  ] Started dhcpcd on all interfaces.
[  OK  ] Reached target Network.
---
         Starting /etc/rc.local Compatibility...
         Starting Permit User Sessions...
[  OK  ] Reached target Network is Online.
         Starting LSB: Start NTP daemon...
My IP address is 169.254.14.12
[  OK  ] Started Permit User Sessions.
connect: Network is unreachable
[  OK  ] Started /etc/rc.local Compatibility.
         Starting Terminate Plymouth Boot Screen...
         Starting Hold until boot process finishes up...

That mysterious IP address is a Link-local address, about which Wikipedia says: “If a host on an IEEE 802 (Ethernet) network cannot obtain a network address via DHCP, an address from 169.254.1.0 to 169.254.254.255 may be assigned pseudorandomly.”

So, having the router hand out IP addresses doesn’t quite work the way I expected. The Pi awards itself a link-local IP address before getting one from the DHCP server, presumably because the vast Linux startup Pachinko machine has a race condition. Alas, the pseudorandom LL address doesn’t fit in the 192.168.0.0/16 network handled by the router: the Pi can’t connect to the network.

My code in /etc/rc.local starts the streaming player immediately after the default code displaying the IP address, thus joining the race condition: if the player starts up before the DCHP server assigns the proper IP address, it can’t connect to the music server out on the Interwebs. My code includes a retry loop with a five second delay which eventually connects, at least most of the time, but sometimes gets wedged.

The most reasonable fix seems to involve forcing a static address on each Raspberry Pi, so it can immediately connect to the network, without any negotiation, and get on with the business at hand.

Rather than configuring that in  /etc/network/interfaces as before, the New Hotness adds a stanza to  /etc/dhcpcd.conf:

interface wlan0
static ip_address=192.168.1.101/8
static routers=192.168.1.1
static domain_name_servers=192.168.1.1

En passant, I killed off IPV6 with this line in /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6=1

The router doesn’t support IPV6 and there’s no point in using it. Bonus: less log clutter. Double Bonus: startup happens faster!

All of which may help the NTP client update the system clock sooner, perhaps preventing time jumps like this:

2017-02-14 08:42:24,183 INFO: Player setup for: BR1
2017-02-14 08:42:24,184 INFO: Volume control knob: /dev/input/volume
2017-02-14 08:42:24,225 INFO: Starting mplayer on Ambient -> http://185.32.125.42:7331/maschinengeist.org.mp3
2017-02-14 08:42:27,175 INFO: Track name: [Arcticology - Nocturnal Sounds]
2017-02-14 08:42:27,194 INFO: Track unmuted
2017-02-15 04:25:00,386 INFO: Track name: [Oöphoi - Suspended Matter]
2017-02-15 04:25:00,413 INFO: Track unmuted

The timestamps in the first five lines date back to the previous shutdown. The Pi remains plugged in and powered while it’s reset, which apparently preserves the system clock variables, albeit without a hardware clock ticking along: time stands still between shutdown and restart.

In this case, the IP address situation worked itself out before the player started, but the NTP clock reset on the sixth line happened at least three seconds after the log began.

This chunk of /var/log/syslog has more detail:

 highlight="1,5,6,7,8,15,21"]
Feb 14 08:42:24 streamer1 dhcpcd[693]: wlan0: leased 192.168.1.101 for 86400 seconds
Feb 14 08:42:24 streamer1 dhcpcd[693]: wlan0: adding route to 192.168.1.0/24
Feb 14 08:42:24 streamer1 dhcpcd[693]: wlan0: adding default route via 192.168.1.1
Feb 14 08:42:24 streamer1 avahi-daemon[387]: Registering new address record for 192.168.1.101 on wlan0.IPv4.
Feb 14 08:42:24 streamer1 dhcpcd[693]: wlan0: deleting route to 169.254.0.0/16
Feb 14 08:42:24 streamer1 avahi-daemon[387]: Withdrawing address record for 169.254.14.12 on wlan0.
Feb 14 08:42:24 streamer1 avahi-daemon[387]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 169.254.14.12.
Feb 14 08:42:24 streamer1 avahi-daemon[387]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.1.101.
Feb 14 08:42:25 streamer1 dhcpcd[693]: wlan0: no IPv6 Routers available
Feb 14 08:42:25 streamer1 ntpd_intres[728]: DNS 0.debian.pool.ntp.org -> 206.71.252.18
Feb 14 08:42:25 streamer1 ntpd_intres[728]: DNS 1.debian.pool.ntp.org -> 45.33.13.54
Feb 14 08:42:25 streamer1 ntpd_intres[728]: DNS 2.debian.pool.ntp.org -> 204.9.54.119
Feb 14 08:42:25 streamer1 ntpd_intres[728]: DNS 3.debian.pool.ntp.org -> 216.229.4.66
Feb 14 08:42:26 streamer1 ntpd[720]: Listen normally on 6 wlan0 192.168.1.101 UDP 123
Feb 14 08:42:26 streamer1 ntpd[720]: Deleting interface #3 wlan0, 169.254.14.12#123, interface stats: received=0, sent=0, dropped=4, active_time=3 secs
Feb 14 08:42:26 streamer1 ntpd[720]: 216.229.4.66 interface 169.254.14.12 -> (none)
Feb 14 08:42:26 streamer1 ntpd[720]: 204.9.54.119 interface 169.254.14.12 -> (none)
Feb 14 08:42:26 streamer1 ntpd[720]: 45.33.13.54 interface 169.254.14.12 -> (none)
Feb 14 08:42:26 streamer1 ntpd[720]: 206.71.252.18 interface 169.254.14.12 -> (none)
Feb 14 08:42:26 streamer1 ntpd[720]: peers refreshed
Feb 15 04:20:10 streamer1 systemd[1]: Time has been changed
[/sourcecode]

Given the timestamp resolution, NTP (or systemd) apparently resets the clock three seconds after the IP address changes. That may be as good as it gets, if only because the NTP daemon must find its servers, evaluate their status, then whack the local clock.

After forcing the static address, things look better, but it’s too soon to be sure. Many things can clobber streaming, not all of which happen on this side of our router.

Advertisements

,

Leave a comment

Vacuum Tube Lights: Plate Wire Plug

After replacing the WS2812 LED in the 21HB5A socket, I drilled out the hole in the disk platter for a 3.5 mm stereo jack, wired a nice knurled metal plug onto the plate lead, and it’s all good:

21HB5A - Audio plug cable

21HB5A – Audio plug cable

The plug had a rather large cable entry that cried out for a touch of brass:

Audio plug - brass trim turning

Audio plug – brass trim turning

Fancy plugs have a helical spring strain relief insert about the size & shape of that brass snout; might have to buy me some fancy plugs.

This time, I got the alignment right by clamping everything in the lathe while the epoxy cured:

Audio plug - brass trim gluing

Audio plug – brass trim gluing

I flipped the drill end-for-end, which was surely unnecessary.

It’s now sitting on the kitchen table, providing a bit of light during supper while I wait for a WS2812 controller failure. Again.

, ,

Leave a comment

Cheap WS2812 LEDs: Leak Tests vs. Failures

Applying the Josh Sharpie Test to three defunct WS2812 LEDs produced one failure:

Failed WS2812 LED - leak view 2

Failed WS2812 LED – leak view 2

The other side shows where the ink stopped seeping under the silicone:

Failed WS2812 LED - leak view 1

Failed WS2812 LED – leak view 1

I don’t know if I melted the side of the LED or if it came that way, but, oddly, there’s no leakage on that side.

This LED matches the layout of Josh’s “crappy” LEDs, as does the entire lot below, although I suspect that’s more coincidence than anything else; there aren’t that many different layouts around.

Flushed with success, so to speak, I ran the Sharpie around all the unused LEDs from that order:

WS2812 LEDs - leak test

WS2812 LEDs – leak test

I tested the process on the three LEDs in front, then wiped the ink off with denatured alcohol.

A closer look shows the ink all around the silicone-to-case border, with plenty of opportunity to seep in:

WS2812 LEDs - leak test - detail

WS2812 LEDs – leak test – detail

After wiping the ink off, none of the 31 unused LEDs showed any sign of poor sealing.

I haven’t been keeping good records of the failures, but right now I have twelve functional WS2812 LEDs attached to various glass doodads. That leaves 7-ish failed LEDs out of the 15-ish with long term use (not counting four recent replacements).

In round numbers, that’s a 50% failure rate…

I should wire up the remaining sheet of LEDs as a test fixture, let them cook for a while, and see what happens.

1 Comment

Screw Cutting Fixture vs. Lathe Ways

A length of aluminum hex bar became a nice 10-32 screw trimmer:

Screw cutting fixture - 10-32 - first cut

Screw cutting fixture – 10-32 – first cut

The hex neatly fits a 5/8 inch wrench, so I can tighten the jam nuts enough to run the lathe forward, part off the screw, and clean up the end just fine.

Unfortunately, the second test cut didn’t work nearly so well:

Screw cutting fixture - 10-32 - wrecked

Screw cutting fixture – 10-32 – wrecked

With the cross-slide gib adjusted to the snug side of easy, the cut put enough pressure on the parting tool to lift the way on the tailstock side about 4 mil = 0.1 mm. The parting tool submarined under the cut, dislodged the fixture, and didn’t quite stall the motor while the chuck jaws ate into the aluminum.

Well, that was a learning experience.

After tightening the cross-slide gib to the far side of hard-to-turn:

  • Put a longer screw in the fixture
  • Grab it in the tailstock drill chuck
  • Crunch the hex end of the fixture in the spindle chuck
  • Remove the screw through the spindle (*)
  • Put a slight taper on the end of the fixture threads with a center drill
  • Deploy the live center to support the fixture

Like this:

Screw cutting fixture - 10-32 - rechucked

Screw cutting fixture – 10-32 – rechucked

Turns out that angling the bit by 10° dramatically reduces chatter. If I had BR and BL turning tools, I’d be using them with the QCTP set to 0°, but they weren’t included in the set that came with the lathe.

It’s a good thing I’m not fussy about the diameter of that cylindrical section:

Screw cutting fixture - 10-32 - reshaped

Screw cutting fixture – 10-32 – reshaped

I knew the craptastic lathe ways needed, mmmm, improvement and it’s about time to do something.

(*) By concatenating all my ¼ inch socket extension bars into an absurd noodle capped with square-to-hex adapter holding a Philips bit.

, ,

3 Comments

Cheap WS2812 RGB LEDs: Continuing Failures

Three more knockoff Neopixels failed in the last few weeks, including one that can’t possibly suffer any thermal stress:

Halogen bulb brass cap - overview

Halogen bulb brass cap – overview

I wrapped the halogen bulb in a shop towel, laid the ersatz heatsink against an anvil (actually, it was a microwave transformer on the Squidwrench operating table), whacked a chisel into the epoxy joint, and met with complete success:

Failed WS2812 LED - ersatz heatsink

Failed WS2812 LED – ersatz heatsink

Having epoxied the PCB and braid in place, there was nothing for it but to drill the guts out of the brass cap:

Failed WS2812 LED - drilling

Failed WS2812 LED – drilling

Which produced a pile of debris in addition to the swarf:

Failed WS2812 LED - debris

Failed WS2812 LED – debris

The brass cap emerged unscathed, which was just about as good as I could possibly hope for.

The base LED in this 21HB5A also failed:

21HB5A on platter - orange green

21HB5A on platter – orange green

Soooo I had to unsolder the plate lead and Arduino connections to extract the bottom PCB; fortunately, that was just a press-fit into the base.

I should mount a 3.5 mm stereo jack on the platter and run the plate lead into a nice, albeit cheap, knurled metal plug, so I can dismount both the tube and the plate lead without any hassle. Right now, the tube can come out of the socket, but the plate lead passes through the platter.

For whatever it’s worth, all of the dead WS2812 LEDs pass the Josh Sharpie Test, so these failures don’t (seem to) involve poor encapsulation.

3 Comments

X10 Transceiver Case Plastic: End Of Life, Redux

Another X10 RF transciever, this one made for IBM (!) a long time ago, emerged from the heap with its case falling apart: the plastic bosses that should anchor the screws had broken off, then cracked radially. Given that I was probably going to toss it anyway, for reasons that will soon be obvious, I tried repairing the bosses just for practice.

Stuffing the boss fragments into close-fitting brass tubes, with a dash of IPS #3 on the broken faces, put them back together reasonably well:

HD501 X10 Transceiver - plastic boss gluing

HD501 X10 Transceiver – plastic boss gluing

More IPS #3 and a pair of clamps stuck the bosses back on the case:

HD501 X10 Transceiver - plastic boss assembly

HD501 X10 Transceiver – plastic boss assembly

Note the dark smudge on the inside of the case. Even though nothing on the PCB looked particularly overheated, Soot Is Sign of Bad Electrical Health.

And it turned out neither the bonds nor the plastic were up to the task. A day after successfully reassembling the transceiver, the bosses failed along new cracks and crumbled into different fragments.

I applied a Kapton tape belly band around the case halves, verified that the transceiver no longer produced reliable X10 commands, and executed ++recycle_pile.

So it goes.

Leave a comment

Kenmore Progressive Vacuum Cleaner Carpet Brush Disassembly

The beater bar found and ingested a remarkably long strip of carpet yarn, resulting in a sudden stop and an acute need for disassembly. In the unlikely event that happens again:

  • Remove hose
  • Release latch to lay hose fitting flat
  • Remove two obvious screws
  • Pry rear latches adjacent to hose fitting to release rear of top cover
  • Pry side latches to release middle of top cover
  • Pull rear of top cover away from base
  • Disengage latches along front of beater bar

Those places, neatly marked for future reference, with the top cover against the floor:

Kenmore Progressive vacuum - carpet brush - disassembly latches

Kenmore Progressive vacuum – carpet brush – disassembly latches

With the cover off, the beater bar lifts out and you can easily unwind the mess.

Leave a comment