I’d like to thank all of you who commented or emailed about the SiliconDust HDHomerun Connect Quatro review posted in November of last year. I’m truly amazed at the amount of interest it garnered.
And there’s some great news for those of you who have the Quatro or been on the fence about getting one – the issue reported in that review has been addressed with the 20180327 firmware!
The HDHR5 Quatro now performs on par with the HDHR4 Connect. In fact, for certain types of impairments, it may perform a bit better.
The 20180327 firmware addresses the issue with transient RF impairments. This is important since the possibility of concealing a reception error during playback is related to the amount of damage the compressed bitstream sustained.
For more on error concealment have a look at this post.
Recap: Transient RF Impairments
To recap the primary issue raised in the November post, the Quatro had a tendency to drop a large number of transport packets when a transient RF impairment occurred. A transient impairment is a very brief disturbance in the broadcast that may be caused by, for example, flicking a light switch or a bath fan (these can cause inductive surges). They may also be caused by objects somewhere between you and the broadcast tower, such as a plane or tree.
When one of these transients occur, a few to a few dozen transport packets may be affected. On the whole the damage is not extreme – in fact due to the way that ATSC is data randomized, it’s often the case many of the bits in each packet are good. Odds are that error concealment can significantly mitigate the visual artifacts caused by a transient impairment.
The issue with the early Quatro firmware, however, was that it would drop an excessive number of packets. While the fourth-generation HDHR4 would emit up to a few dozen error’d packets and recover, the Quatro would emit a few error’d packets, then stop emitting packets for a while. Analyzing a number of transport stream captures suggests that the Quatro would recover at an ATSC data field boundary. These boundaries occur every 312 packets, so if you’re unlucky and the impairment happened at the beginning of a data field, you could lose the entire field.
With the 20180327 firmware, the HDHR5 Quatro behaves the same as the HDHR4: packets which could not be successfully demodulated or error corrected are emitted with the Transport Error Indicator bit set in the transport packet. No extra packets are dropped. The HDHR5 now recovers at roughly the same point where the HDHR4 does.
While testing the new firmware it was also observed that the HDHR5 may be resilient to some transient impairments that cause the HDHR4 to emit a few error’d packets. At first I thought this might be due to cabling. When the signal becomes marginal, a slight difference in cable quality can push a demodulator over the edge. However the HDHR5’s apparent robustness survived a cable swap between the HDHR4 and HDHR5. This needs to be looked into further to see if it is consistent across HDHR5s. (I’ve also observed similar slight differences in performance among the various HDHR4s I have. The difference can’t be explained by cabling or power supplies, and may simply result from manufacturing tolerances.)
Equally important is that at no time during evaluation of the new firmware was there an instance where the HDHR5 performed worse than the HDHR4.
Recap: Weak Signal Test
The purpose of the weak signal test was to see when the HDHR5 would unlock from a weak signal by progressively attenuating the signal. It turned out that the HDHR5 was more or less on par with the HDHR4 – it appeared to unlock with just a tad less attenuation.
What was more concerning at the time was that as the attenuation was just before hitting the unlock attenuation, the HDHR5 would stop emitting packets for an extended period (hundreds of milliseconds). Now this is a terribly weak signal and we’re deliberately pushing things to a point where the demodulator will have a very rough time making sense of the signal. However while the HDHR4 emitted packets (many of them with the TEI bit set), the HDHR5 emitted none.
A more thorough investigation with real broadcasts suggests that this is more a difference in behavior between the Panasonic demodulator in the HDHR4 and the MxL692 in the HDHR5. With the 20180327 firmware, the range of dropped packets correlates well with the range of packets that the HDHR4 emits with TEI set. The damage is extensive enough that it would be the rare exception that error concealment could make use of the correctly received bits. So while it sounds bad that HDHR5 stopped emitting packets, in these cases it has no practical effect.
With the release of the 20180327 firmware, the HDHR5 Connect Quatro’s performance meets or exceeds that of its predecessors. It has begun taking the place of HDHR4s in Koherence’s projects and is recommended for anyone looking for a network-connected OTA receiver.