Welcome to the last in a planned series of teardowns resulting from the mid-2024 edition of “the close-proximity lightning strike that zapped Brian’s electronics devices”, following in the footsteps of a hot tub circuit board, a three-drive NAS, two eight-port GbE switches and one five-port one, and a MoCA networking adapter…not to mention all the gear that had expired in the preceding 2014 and 2015 lightning-exposure iterations…
This is—I’m sad to say, in no small part because they’re not sold any longer (even in factory-refurbished condition) and my accumulated “spares” inventory will eventually be depleted—the third straight time that a SiliconDust HDHomeRun Prime has bit the dust:
Legacy vulnerability
The functional failure symptoms—a subsequent access inability from elsewhere over the LAN, coupled with an offline-status front panel LED—were identical in both the first and second cases, although the first time around, I couldn’t find any associated physical damage evidence. The second time around, on the other hand…
This third time, though, the failure symptoms were somewhat different, although the “dead” end (dead-end…get it? Ahem…) result was the same; a never-ending system loop of seemingly starting up, getting “stuck” and rebooting:
Plus, my analysis of the systems’ insides in the first two cases had been more cursory than the comparative verbosity to which subsequent teardowns have evolved, so I decided a thorough revisit was apropos. I’ll start with some overview photos of our patient, as usual accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes:
See those left-side ventilation slots? Hold that thought:
Onward:
Two screws on top:
And two more on the bottom:
will serve as our pathway inside:
Before diving in, here’s visual confirmation:
that the “wall wart” still works (that said, I still temporarily swapped in the replacement HDHomeRun Prime’s PSU to confirm that any current-output deficit with this one wasn’t the root cause of the system’s bootup woes…it’s happened to me with other devices, after all…)
Getting inside
Onward:
Now for that inner plastic sleeve still surrounding three sides of the PCB, which slips right off:
This seems to be the same rev. 1.7D version of the design that I saw in the initial November 2014 teardown, versus the rev. 1.7F iteration analyzed a year (and a few months) later:
Once again, a heatsink dominates the PCB topside-center landscape, surrounded by, to the left, a Macronix MX25L1655D 16 Mbit serial interface flash memory (hold that thought) and a Hynix (now SK Hynix) H5PS5162FFR 64 Mbit DDR2 SDRAM, and above, a Realtek RTL8211CL single-port Ethernet controller. Back in late 2014, I relied on WikiDevi (or, if you prefer, DeviWiki) to ID what was underneath the heatsink:
The chip is Ubicom’s IP7150U communications and media processor; the company was acquired in early 2012 and I can’t find any mention of the SoC on new owner Qualcomm’s website. Here’s an archive of the relevant product page.
I confess that I had subsequently completely forgotten about my earlier online sleuthing success; regardless, I was determined to pop the heatsink off this time around:
Next, some rubbing alcohol and a fingernail to scrape off the marking-obscuring glue:
Yep, it’s the Ubicom IP7150U 
Here’s an interesting overview of what happens when you interact with the CPU (and broader system) software via the SiliconDust-supplied Linux-based open source development toolset and a command line interface, by the way.
I was also determined this time to pry off the coax tuner subsystem’s Faraday cage and see what was underneath, although in retrospect I could have saved myself the effort by just searching for the press release first (but then again, what’s the fun in that?):
Those are MaxLinear MxL241SF single-die integrated tuner and QAM demodulator ICs, although why there are four of them in a three-tuner system design is unclear to me…(readers?)
Grace Hopper would approve
Now let’s flip the PCB over and see what’s underneath:
What’s that blob in the lower right corner, under the CableCard slot? Are those…dead bugs?
Indeed!
I’d recently bought a macro lens and ring light adapter set for my smartphone:
Which I thought would be perfect to try out for the first time in this situation:
That optical combo works pretty well, eh? Apparently, the plants in the greenhouse room next door to the furnace room, which does double-duty as my network nexus, attract occasional gnats. But how and why did they end up here? For one thing, the LED at this location on the other side of the PCB is the one closest to the aforementioned ventilation slots (aka, gnat access portals). And for another, this particular LED is a) perpetually illuminated whenever the device is powered up and b) multicolor, whereas the others are either green-or-off. As I wrote in 2014:
At the bottom [editor note: of the PCB topside] are the five front-panel LEDs. The one on the left [editor note: the “buggy” one] is normally green; it’s red when the HDHomeRun Prime can’t go online. The one to its right is also normally green; it flashes when the CableCARD is present but not ready, and is dark when the CableCARD is not present or not detected. And the remaining three on the right, when green-lit, signify a respective tuner in use.
Hey, wait…I wonder what might happen if I were to scrape off the bugs?
Nope, the device is still DOA:
I’ll wrap up with one more close-up photo, this one of the passives-dominated backside area underneath the topside Ubicom processor and its memory and networking companion chips:
And in closing, a query: why did the system die this time? As was the case the first time, albeit definitely not the case the second time, there’s no obvious physical evidence for the cause of this demise. Generally, and similar to the MoCA adapter I tore down last month, these devices have dual potential EMP exposure sources, Ethernet and coax. Quoting from last month’s writeup:
Part of the reason why MoCA devices keep dying, I think, is due to their inherent nature. Since they convert between Ethernet and coax, there are two different potential “Achilles Heels” for incoming electromagnetic spikes. Plus, the fact that coax routes from room to room via cable runs attached to the exterior of the residence doesn’t help.
In this case, to clarify, the “weak link” coax run is the one coming into the house from the Comcast feed at the street, not a separate coax span that would subsequently run from room to room within the home. Same intermediary exterior-exposure conceptual vulnerability, however.
The way the device is acting this time, though, I wonder if the firmware in the Macronix flash memory might have gotten corrupted, resulting in a perpetual-reboot situation. Or maybe the processor just “loses its mind” the first time it tries to access the no-longer-functional Ethernet interface (since this seemed to be the root cause of the demise the first two times) and restarts. Reader theories, along with broader thoughts, are as-always welcomed in the comments!
—Brian Dipert is the Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.
Related Content
- The whole-house LAN: Achilles-heel alternatives, tradeoffs, and plans
- Lightning strikes…thrice???!!!
- Computer and network-attached storage: Capacity optimization and backup expansion
- A teardown tale of two not-so-different switches
- Dissecting (and sibling-comparing) a scorched five-port Gigabit Ethernet switch
- Broke MoCA II: This time, the wall wart got zapped, too
The post Debugging a “buggy” networked CableCARD receiver appeared first on EDN.
