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 |
|---|---|
|
|
Packaging
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.
Hardware
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.
Temperature
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.)
Performance
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:
| Character | Description |
|---|---|
| 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:
| Quatro | Connect | |
|---|---|---|
| Model | HDHR5-4US | HDHR4-2US |
| Firmware | 20170914 | 20161117 |
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.)
Performance Summary
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.
Power Consumption
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%.
| Tuners Active | Quatro | Connect |
|---|---|---|
| idle | 1.2w | 1.3w |
| 1 | 1.8w | 2.0w |
| 2 | 2.2w | 2.6w |
| 3 | 2.7w | N/A |
| 4 | 3.1w | N/A |
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.
In Summary….
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.
I had a quatro unit at my house for about a week and I found that there were alot of peaks and valleys in the signal quality, even though the strength is very high (I have 8 towers in a single direction less than 7 miles from my home). I used 2 different antennas, hoping that one was causing the problem, but unfortunately the issue remained with the quatro unit. The result of the spikes was significant glitching and pixelation in the digital video signal as well as pauses in audio. Certain channels were worse than others, and specific times of day made it better or worse, but it never totally stopped.
It was bad enough that I returned the unit and I’m looking for another option.
The part that annoys me is the 2 antennas work VERY well on a standard HD TV directly but adding the Quatro seemed to cause a degraded output. Any ideas on how to resolve, or should I try the 2 tuner connect and see if that works better? Thanks for any help you can offer?
Hi there, while it does appear that the fourth-generation Connect is slightly better in its handling of weak signals and transient noise than the fifth-generation Quatro, it’s not clear that it would be better in your case. One question – when you say “…adding the Quatro seemed to cause a degraded output” do you mean that when you added the Quatro, both the TV and Quatro exhibited the same degradation? If that’s the case then I’d take a look at the cabling to the Quatro, especially any splitters that may have been introduced. Maybe try swapping the Quatro for another TV. And make sure that any open ports on the splitter are terminated.
Since you didn’t mention if you were connecting to the Quatro via wired Ethernet or Wi-Fi, I’d first suggest that you see how things work with a wired Ethernet connection between a PC and the router. The glitching and loss of audio could be a result of data loss, which can be particularly problematic with Wi-Fi. Even if your Wi-Fi is great 90% of the time, in order to stream from the HDHomerun it needs to maintain a certain bitrate 100% of the time. It could be interference from other devices such as microwaves, or from another Wi-Fi access point that causes channel hopping. As different channels have different bitrates, your experience may be better with some than others.
If using wired Ethernet provides a better experience, then the HDHomerun Extend may be worth a try. The Extend has a transcoder that will allow you to adapt the bitrate to what can be sustained over your Wi-Fi. It won’t help if your access point channel hops (since your Wi-Fi effectively goes away for a very brief period), or if the microwave is causing long-term drops in Wi-Fi throughput.
Be sure to upgrade the firmware to the latest official release (currently 20171208) as this fixes a demodulator issue that was causing reception issues in some areas.
Thanks Nick. I’ve been looking at the 20171208 firmware for the past week or so. I’ll update this post should I find anything has changed. I had hoped to get a better feel for things before heading off to CES, but there are some anomalies with KTVU RF 48 interfering with the test.
Great job! Nobody has done such an in depth review let alone a technical one, let one opened one up! You have definitely provided a huge service for us shoppers. The average HDhomerun review never mentions anything beyond the bare basics. The “tech” blogs are worthless when it comes to this kind of thing. So again thank you very much from both a sheer curiosity point of view and consumer point of view.
First off, many thanks for providing this sort of analysis and technical breakdown. It seems to be increasingly hard to find people who actually know and share stuff these days.
As a quasi-technoliterate I’m interested in whether the issues with weak signals/impairment are worse on the Quattro than you might expect if you split a signal and shared that between two Connects?
Thank you. I appreciate all the positive feedback I’ve gotten. I use a number of HDHR4s, which are excellent devices, so was eagerly awaiting the Quatro. So the tests I’ve run against it aren’t just for the sake of reviewing it. It’s part of my own qualification to determine whether I can put the Quatro into service (which I have on a limited basis – I’m still waiting on the transient impairment handling to be improved).
Regarding your question about splitting signals – the sensitivity of the Quatro to weak signals seems to be about the same as the Connect. In the weak signal test we’re talking really, really weak signals. This is not a case where the HDHR4 Connect would macroblock occasionally while the HDHR5 Quatro would show total garbage. That was in fact what I was looking for, and I am happy to say that it’s not the case.
Now if you do split a signal, I would expect that most of the channels will behave the same. There will be some borderline channels that will show increased blocking as compared to an unsplit feed. Basically with a weaker signal there may be some transient RF impairments that are not handled as well. A minor (mostly unnoticeable) glitch may magnify into a noticeable one. I use a distribution amplifier to avoid situations like that. For example, take a look at the Channel Master CM3412. I’ve been using a number of the four and eight port versions.
A last word of caution – there are some pretty poor splitters out there that can lead to greater than expected signal loss per output and that do not provide isolation between the ports (i.e. noise from one device may be relayed to others). That’s another advantage of using something like the Channel Master distribution amps (the PCT ones are basically the same thing).
Many thanks! Will give the quattro a go as soon as it becomes available in the UK!
In the UK you’ll need a DVB-T/COFDM version of the HDHR5, so what I’ve written about the ATSC version won’t necessarily apply. The types of issues that occur with DVB-T COFDM are rather different than ATSC 8-VSB. And the demodulator for a UK version of HDHR5, which is really what will determine how well it performs, is almost guaranteed to be different. To the best of my knowledge the MxL692 is ATSC/8VSB-only. Still, the HDHomerun series are excellent products and definitely worth a look.
Thx for the update. I was aware that I’d have to wait for the DVB-T version but hadn’t realis/zed that the US used a different modulation method to GB too. The UK version is being released this quarter so I’m now just waiting to order.
Did you compile the “modified” hdhomerun_config yourself?
If so, can you include the patches?
If not, can you include a link to or a sha256 of the file you used?
Thank you.
I haven’t really set up this site for file sharing, however if you’d like to send me an email I’d be happy to send you the file. SiliconDust was kind enough to distribute their source under LGPL 2.1.
Alternately (since the changes are rather trivial), take a look at the function cmd_save in hdhomerun_config.c. That’s the function that sits in a loop getting data from the hdhromerun, and periodically prints ‘o’, ‘t’, ‘n’, ‘s’ or ‘.’. Just change those fprintfs to something meaningful for what you’re monitoring.
First, thank you for this review.
I am currently using USB dual tuners in a Windows/Mediaportal VM (thanks to VT-d NEC chipset USB3 board passthrough), but I experience USB tuner deaths more and more frequently as they get old. I now have only 1 dual tuner working out of 4 initially set up (8 years ago), connected on 2 USB PCIe boards.
The last one that died obviously overheated; its case has an abnormal shape, as melted.
This is quite worrying.
I was contemplating buying the silicondust quatro (EU version, for DVB-T) but could not find data on silicondust website (I was especially concerned with power draw).
You convinced me to give it a go, power dissipation seems very good and should make it last long (fingers crossed) because it’s an expensive device (170€).
This will let me try tvheadend instead of Mediaportal, in order to get rid of Windows.
Furthermore, as it is widely supported, it will let me try various software, even in the same time, and will be way easier to use from a virtual machine.
Thank you very much agian for sharing (and doing the manufacturer’s job, by the way 🙁 )