April 7, 2018: Please take a look at the follow-up to this review.
Koherence’s projects have long been powered by SiliconDust HDHomerun tuners. At present 13 HDHR4s are feeding the three production Entangles, and a venerable HDHR Rev 2 handles other sundry tasks. The RF and power supply cabling has started to become quite…entangling…so the announcement of the four-tuner HDHomerun Connect Quatro was received with much anticipation. As soon as a (not quite local) Best Buy got it in stock, I was off to get one for evaluation!
|The Good||The Bad|
Those of you familiar with HDHomerun products won’t have any problems spotting the Quatro on a store shelf.
The package dimensions and artwork are in line with the HDHomerun Connect’s. Inside you’ll find the usual power supply and Ethernet cable accompanying the HDHomerun itself. SiliconDust provides a slightly beefier power supply for the Quatro. While the Connect ships with a 5v 1A power supply, the Quatro comes with a 5v 1.5A supply. Regrettably the new Quatro power supply’s form factor isn’t as accommodating as the Connect’s. The Connect power supply was long and slim, and, provided your power strip’s outlets were oriented properly, you could easily slot several in side-by-side. The Quatro’s power supply is more rectangular and unfortunately just wide enough that you can’t plug anything into adjacent outlets, at least with the power strips I have. This may not seem like a big deal, but considering that you’re probably using a power strip because you need to plug several things into it, it’s rather unfortunate that the Quatro’s power supply occupies three outlets.
The HDHomerun Quatro itself is roughly the same size as the Connect, although a square box as opposed to the Connect’s curved chassis.
The LED indicators for power and tuner usage have been removed. While the tuner usage LEDs might not have been useful to everyone, I often found it handy to know when a box was in use so I wouldn’t go mucking with the RF cabling or networking. Sure, I could always query the Entangle, which would tell me what it’s recording. But (at least at present) it doesn’t tell me which HDHomeruns its recording on. The power indicator was also a nice-to-have, especially when you’re setting things up. It’s far too easy to knock the barrel connector out. The only indicator on the Quatro is the Ethernet link LED on the rear of the unit, which would most likely be facing away from you.
One surprising difference is the lack of any ventilation. The Connect has a number of holes on its top to provide ventilation. The Quatro is completely sealed, and instead uses a large metal base plate to dissipate heat.
The plate is recessed (where the ID label is affixed), and makes contact with a couple chips via thermal pads.
Disassembling the Quatro, you can see an area shielded by a large can. I didn’t remove the can but one an safely assume that the RF splitter circuitry and tuner/demodulators are under there.
While the Connect uses a Panasonic demodulator (and separate silicon tuner?), the Quatro uses the new MaxLinear MxL692 single-chip tuner/demodulator. The Hisilicon Hi3716MB330 is the primary SoC running the HDHomerun firmware.
As noted above, the Quatro is a completely sealed unit with a plastic cover and metal base plate that acts as a heat sink. Since I’m familiar with some products that have had thermal issues, it’s something I’m wary of.
The good news is that despite the lack of ventilation, the Quatro’s temperatures stay within a quite reasonable range. At idle, the temperature of the base plate was measured with an IR thermometer at around 80 F. The ambient temperature was around 69 F.
To measure the temperature when active, the Quatro was placed on a towel and all four tuners streamed the unfiltered transport stream. Placing the Quatro on a towel simulates a condition where it’s on a surface that isn’t great at conducting heat, which could happen in real life. The base plate reached a temperature of about 103 F. The plastic cover was measured at the same temperature. This isn’t even warm enough for it serve as a coffee mug warmer, although you’re advised to keep your chocolate away from it.
As a worst-case test, the Quatro was wrapped in a towel. Obviously this is not recommended, but in my history of developing consumer electronics devices I’ve been amazed at what users subject them to. The wrapped Quatro got a bit warmer to 123 F. This is still far from posing any danger (except to your chocolate bars.)
Four tuners are great, but how well do they actually perform? At first glance, the Quatro’s performance appears similar to the Connect’s. Hooking the Quatro up to my primary antenna (aimed at Sutro Tower in San Francisco) and spot-checking channels, I get the same channels with the visual quality as with the Connect.
To look at things in more detail, we’ll examine performance in a couple ways: performance with weak signals, and resilience to impaired signals. The analysis is performed by examining the demodulated transport stream. As with all HDHomerun models, the Quatro will provide statistics such as signal strength and quality. These metrics are invaluable in antenna aiming, or in determining if your signal is impaired by a bad cable or other component. However, between models (especially those with different tuners and demodulators), comparing the values is sketchy at best. On the other hand, there can be no arguing about a transport packet that has errors, or that has been dropped altogether.
A modified version of hdhomerun_config was used to get a high-level view of the transport stream. Those of you familiar with the hdhomerun_config “save” command know that it outputs a status once per second indicating whether transport, sequence, or network errors were detected. The modified version used here indicates the number of transport, sequence, or network errors that occur. You can decode the output according to the following table:
|o||The capture buffer in the PC overflowed|
|n||A network packet was dropped|
|A-Z||Transport packets with errors were received. 'A' indicates 1-9 packets, 'B' 10-19, etc.|
|1-9||Sequence errors were detected. The number represents the number of sequence errors.|
|_||No packets were received|
|.||No errors were detected|
The table shows what character will be output in priority order. For example, if both transport and sequence errors occur within a second, only the transport error count will be output.
One of the nice things about the HDHomeruns is that despite all the new hardware, from a software perspective it looks the same as older HDHomeruns, so the same application is run against each.
The following HDHomeruns were used in this evaluation:
Weak Signal Test
For the weak signal test, a feed from an antenna pointed at Sutro Tower was passed through a variable RF attenuator. The attenuated signal is then split and sent to a Connect and a Quatro. While this obviously simulates a weak signal, one must keep in mind that it’s a bit artificial. The attenuator attenuates everything, including noise that would be picked up by the antenna and possibly interfere with demodulation of the signal. (The signal-to-noise ratio remains the same, since both are attenuated by the same amount. In real life weak signals tend to have poor signal-to-noise ratios.)
Once everything was hooked up, the signal was attenuated until either the Connect or Quatro started to show errors. Both RF12 (KNTV) and RF45 (KBCW) were tested.
The following shows the Quatro and Connect output for RF12.
From this comparison, one can see that, at least in this case, the Quatro has a harder time demodulating the signal. At times when the Connect reports less than 250 transport errors in a second, the Quatro consistently reports more than 250. There are also periods where the Quatro outputs no packets at all, suggesting that the tuner and/or demodulator lost lock. To be fair, this is a very poor signal. It’s not something you’d watch on either the Connect or Quatro. And with a slight bump on the attenuator, both the Quatro and Connect demodulated the signal without error.
I should also point out that from my location, the signal-to-noise ratio of RF12 isn’t quite as good as RF45. (This is also a property of the antenna, a Channel Master CM4228HD. It’s a UHF antenna which does surprisingly well for hi-VHF channels).
The story on RF45 is slightly different:
Here we see that the Connect (HDHR4) is for the most part reporting a few error’d packet periodically while the Quatro is reporting them with much greater frequency. In order to rule out any differences introduced by the splitter and cable, the feeds to the Connect and Quatro were swapped three times. These are the green highlighted areas where no signal was reported. It should be noted that unlike the RF12 test, the Quatro did not lose signal lock on RF45. In this case the Connect’s output would be somewhat watchable. Viewing it in VLC you’d see glitches about once every couple seconds. VLC failed to display video from the Quatro’s transport stream and audio would come and go.
Again, one must bear in mind that a slight bump to the attenuator to reduce attenuation brings both the Connect and Quatro into a state where the transport stream is demodulated mostly error-free. And a nudge in the opposite direction causes both the Quatro and Connect to yield transport streams with a great many errors. So in general, you should take away that the overall sensitivity of both HDHomeruns to weak signals is comparable, with a slight edge to the Connect.
Impaired Signal Resiliency
Transient impairments to broadcasts happen quite frequently – they can be caused by inductive surges generated by bath exhaust fans, inrush current in LED lighting, multipath from a passing car or plane, or (one of my issues), cats wandering the roof. While the weak signal test used an attenuator to artificially generate a weak signal, we can simply wait for transient impairments to occur.
To examine transient impairments, a Connect and Quatro were fed independent feeds from a distribution amplifier, which in turn is fed from an antenna oriented towards Sutro Tower.
At first glance, the Connect and Quatro appear to react similarly. Both indicate some number of error’d packets. In general, the Quatro would report fewer error’d packets received, suggesting better resiliency. However a curious artifact of the Quatro was that it would often indicate a sequence error in the second following the transport errors. The Connect would not. This seemed rather odd, so I dug into the transport streams a bit more. If only the received transport stream could be compared to a golden reference broadcast, we could see the exact nature of any errors.
While I don’t have a feed directly from the station, for some stations I can get an alternate broadcast via a translator. In particular, the KTVU-DT/RF44 broadcast from Sutro Tower in San Francisco is brought to the south SF Bay Area via the KTVU-LD/RF48 translator on Monument Peak. As they are about 100 degrees apart from my location, an impairment affecting one tends not to affect the other. In this way we can compare the impaired KTVU-LD/RF48 signal on the Connect/Quatro to an unimpaired signal from KTVU-DT/RF44. (It should be noted that not all translators are bit-for-bit identical to their primary broadcast. For example, the local ABC affiliate has a primary broadcast KGO-DT/RF7 from Sutro Tower and a translator KGO-LD/RF35 on Mt. Allison. These broadcasts are identical at the PES level. But when examined at the transport level there are differences in PCRs and NULL packet placement.)
As our goal is to observe the HDHomeruns’ reaction to impairments, the weaker KTVU-LD/RF48 signal is used. (The antenna used here is pointed just a bit off of Monument Peak, as it also is intended to pick up broadcasts from nearby Mt. Allison.) KTVU-DT/RF44 from the Sutro Tower antenna provides the golden reference signal.
The image below compares the error-free KTVU-DT/RF44 transport stream packets on the left, and the KTVU-LD/RF48 transport stream received by the Connect on the right.
Each line provides summary information for a transport packet (the sync byte, which should always be 0x47, the status of some flags in the transport stream header, the adaptation field control value, the PID, the continuity counter, and a crc32 of the packet). This information is sufficient to compare packets in one stream against another and determine which packets differ (indicating a reception error), and which are missing. A line with exclamation points (“!!!!!!!!!!!!!!!!!!!!”) means that the transport error indicator was set in the packet header. When the TEI is set, all we know is that bits are in error somewhere in the packet. Any of the fields in the transport packet could be in error, so no summary information is displayed.
In the case of the HDHR4, we can see that 36 packets were received with the transport error indicator set, however all packets are accounted for. Every program in the MPTS lost a half dozen to dozen packets on the video PID (0x31, 0x41, 0x51, 0x61). The primary HD broadcast also lost a single packet on its alternate audio (0x35). This level of impairment would most likely go unnoticed with an MPEG2 video decoder that has reasonable error concealment.
Now for the HDHR5:
In the case of the HDHR5, we can see that it starts off similarly to the HDHR4, with the transport error indicator set in 17 packets. We then have a block of 253 packets that are missing, after which error-free reception is restored. I don’t have a spectrum analyzer handy, so I can’t speak to the exact type of impairment that was experienced or what the tuner/demodulator “saw”. However it seems that the Quatro’s MxL692 has a more difficult time maintaining signal lock in the presence of an impairment. The missing packets suggest that ATSC segment lock was lost at some point, and close to a data field’s worth of packets went astray until lock could be restored. (The HDHR4, in contrast, did not appear to lose lock). It would be interesting to know how many packets had errors which were detected and corrected via Reed-Solomon codes. There is no field in the transport packet that could be used to flag this, however demodulators tend to make this information available. The HDHomeruns regrettably do not expose this information.
Due to the large number of missing packets, in particular audio packets, it’s less likely that error concealment can prevent noticeable audiovisual artifacts.
The large number of missing packets explains the apparently smaller number of transport errors on the Quatro. The packets are just AWOL so can’t be counted.
It also explains the mysterious sequence error that would be flagged in the second after transport errors were reported. The large number of lost packets resulted in continuity counter discrepancies across a large number of PIDs – all audiovisual PIDs, as well as the EIT on PID 0x1d00 and the ETTs on PIDs 0x1e00 and 0x1e0d. Audiovisual packets are broadcast quite frequently, so the sequence error caused by missing packets would be recovered in well under a second. However The EIT and ETT are transmitted infrequently, so a sequence error may not be detected until quite a bit later. In the cases examined here, the error is not detected until the following second. (Unlike loss of audiovisual packets, the loss of EIT, ETT, and other system information packets will not result in any observable issues. They contain metadata such as a program’s description and is retransmitted periodically.)
While the Quatro performs generally well with most signals, both the weak signal and transient impairment tests suggest that it has a more difficult time with impaired signals. Most users will not notice any difference, although some will see a bit more block noise on occasion from the Quatro than from the Connect. Users who are trying to pull in very marginal signals may have a rougher time with the Quatro.
If you’re using the Quatro with a DVR, then it’ll be powered on 24/7, so both active and idle power consumption are important. The Quatro excels in this area.
The power consumption measurements were taken using a WattsUp Pro meter using the power supply provided with the HDHomerun. It reflects the consumption the typical user would see “at the wall”, including losses in the power supply as well as the draw of the HDHomerun itself. According to the WattsUp specs, it can measure wattage accurately down to 0.5 watts with an accuracy of 1.5%.
The Quatro idles at approximately 1.2 w. Each tuner that’s in use adds roughly 0.5w. With all four tuners tuned and streaming the full ~19.39 Mbit/s transport stream, the WattsUp reported the Quatro pulling 3.1w. (There was no measurable difference in power consumption when comparing the Quatro with four tuners tuned vs four tuners tuned and streaming.)
In contrast, the HDHomerun Connect idled at 1.3w, and each active tuner added roughly 0.7w (~2.6w with both tuners active). Comparing two Connects vs one Quatro, the two Connects require more than double the power when idle and nearly twice as much when fully active.
The HDHomerun Quatro is a much-anticipated and welcome addition to the HDHomerun family. It’s low power consumption and overall good tuner and demodulator performance makes it a fine addition to any HTPC setup. The one fly in the ointment is that RF impairments are not handled as well as in the Connect. The Maxlinear tuner/demodulator used in the Quatro is a rather new solution, and hopefully issues such as these can be resolved in future firmware updates.
Update: January 23, 2018
Some further testing has been done since this review was first posted, and new firmware (20171208) is also available for the HDHR5. Here’s some updated information:
- With the 20170914 firmware, some channels would need to be tuned twice before the MXL692 would lock. In the SF Bay Area this would happen fairly reliably with KKPX-DT on RF 41. This issue appears to have been resolved with the 20171208 firmwmare.
- The behavior with transient impairments has unfortunately not changed with the 20171208 firmware. When compared to the HDHR4 Connect, the HDHR5 Quatro has a tendency to stop emitting packets for a time when a transient impairment occurs.Some further analysis suggests that the Quatro will resume sending packets at the ATSC data field sync following the impairment. ATSC data field syncs happen every 22 ms or so. So the good news is that it seems the Quatro will recover in short order. The bad news is of course that its still a lot of packets that are lost. The glitches are almost guaranteed to be noticeable.(On a practical note, whether you should be worried about this or not depends on the type and frequency of transient impairments you get. The Quatro may magnify the glitching that occurs when an impairment happens, but in general both the HDHR4 Connect and HDHR5 Quatro are affected. Doing what you can to avoid the impairments in the first place by having a good, well-placed antenna, keeping RF cable runs away from electric circuits, and the like will likely have a greater impact on your TV viewing experience.)
A word of caution if you opt to use beta HDHomerun firmware: you can’t go back to the last released version. Upgrading is a one way street. So unless you’re having severe issues, you may want to wait for new released versions.