Project Entangle – our platform for exploring ways of obtaining and consuming media – was developed on PCs and up until now Entangle platforms have largely been laptops or NUCs. They make great development environments and have a plethora of tools often missing from embedded platforms. But even “thin and light” laptops are big and power-hungry compared to most set-top boxes, and, we’ve always kept an eye out for ways we might piece together a more compact version. And we finally took our first step in that direction with a Raspberry Pi 4 and HDHomerun Flex 4k packaged in a DeskPi Pro chassis.

(Ok, we admit it – the vast majority of the software running on Entangle EX has been mature for quite a while. So this post is really about Having Fun With Your 3D Printer, or maybe Tetris and The Art of  Set-Top Box Assembly. But we really are thrilled at having a more compact platform!)

 

DeskPi Pro Case

The DeskPi Pro is a solid, aluminum case that happens to be just the right size to accommodate a Raspberry Pi 4 and a HDHomerun – if you jettison the hard drive / SSD  board (that’s where the HDHomerun will end up). There’s also just enough space to slip a USB SSD adapter under the DeskPi Pro expansion board. We used a thermal pad that helps to both secure the SSD to the case as well as dissipate heat. (More on storage options later.)

Raspberry Pi 4

We’d gotten the Entangle stack running on the Raspberry Pi 4 a couple years ago. Compared to the PC-bound Entangles, the primary piece of development was to enable hardware acceleration for the encode part of transcoding MPEG-2 to H.264 video. (Pure software transcoding is used on PCs. More on why transcoding is used when streaming to iDevices below.) Software transcoding aside, Entangle was from the outset intended to run in an embedded environment so the Pi’s CPU and 4GB of memory is more than up to the task.

Tuners

HDHomeruns have always been a staple for Project Entangle, but we wanted to be able to handle both ATSC 1.0 and ATSC 3.0 broadcasts. For a few years our go-to ATSC 3.0 tuner has been the Airwavz Redzone Receiver. While the Redzone Receivers perform admirably, they’re single-tuner devices and for this build we wanted multiple tuners (and something a bit cheaper). The SiliconDust HDHomerun Flex 4k is an appealing option The Flex 4k has a total of four tuners, two of which are ATSC 1.0 and 3.0-capable, and the remaining two 1.0-only. Many markets have only one ATSC 3.0 emission (a “lighthouse”), and very few have more than two, so in just about all markets a Flex 4k can simultaneously receive all ATSC 3.0 channels, with two or three tuners to spare for ATSC 1.0.

We’d gotten the HDHomerun Connect 4k (the Kickstarter predecessor to the Flex 4k) sort-of-kind-of working a year ago. There were some stability issues in using the HTTP protocol to get ATSC 3.0 streams from the HDHomeruns. (For ATSC 1.0 the newer models support the same UDP/RTP streams that were used since the first generation of HDHomerun.) After some firmware updates and spending some time beefing up our device support and error recovery, the Connect 4k (and Flex 4k) started to have a robustness level on par with the Airwavz RedZone Receivers. We don’t like missing out on shows because the tuner decided to go on strike!

One thing about the HDHomeruns is that they’re Ethernet-connected devices. We wanted the EX to be as self-contained as possible, so we added a USB-Ethernet adapter. The HDHomerun lives on a private network with the Pi, leaving the Pi’s on-board Ethernet available for connecting to the outside world.

There’s just enough space at the front of the DeskPi  to cram the USB-Ethernet adapter into (we used a TP-Link UE300 and pried the PCB out of its plastic housing to make it a bit more compact). You could then run the USB cable to one of the back USB 2.0 ports, or as we did use the DeskPro Pi’s front USB 2.0 connector. If you do the latter you’ll probably want a custom bezel to hide the USB connector (which also means the power switch will be inaccessible – not a huge loss as it doesn’t initiate a clean shutdown anyway).

The Flex requires 12v power, which isn’t readily available via the Pi. You can either use a separate 12v power supply, or a 5v to 12v boost converter. If you use a boost converter make sure you can supply ~12v @ 1A. We tried some lower amperage converters and while they may seem to work initially, once you start firing up all the tuners you’ll start to see erratic behavior. The Connect 4k that was originally available via SiliconDust’s Kickstarter uses 5v power and could be powered via the Pi’s expansion connector directly.

The Flex 4k has decent ATSC 1.0 and 3.0 performance, but we’d love it if it came as a module using USB for data and power.

Storage

Our initial thought was to use the micro SD card for recording storage. The HDHomerun Connect/Flex 4k support two ATSC 1.0/3.0 and two ATSC 1.0-only tuners, so we could be tuned to four emissions simultaneously. The Entangle platform allows recording any (or all) programs from a tuned emission, so the actual number of simultaneous recordings could be quite high. For example six HD channels from a 3.0 lighthouse, plus two HD channels and two SD channels from each of the other three 1.0 emissions. Or 18 simultaneous channels recording isn’t out of the question.

The Entangle platform is designed to optimize drive access (it was originally designed for use with hard drives and their high seek times), and attempts to use large I/Os. The cumulative bitrate tends to be more important than the total number of shows being recorded. ATSC 3.0 can be configured in a number of ways but 256 QAM with a 10/15 code rate is common. With typical FEC configurations this yields somewhere on the order of 28 Mbit/s of usable bits coming out of the demodulator, For ATSC 1.0 we’ve got around 19.4 Mbit/s/emission. So with two ATSC 3.0 and two ATSC 1.0, our worst-case bitrate should be around 94 Mbit/s.

We were a little skeptical that a micro SD card could sustain that, but our initial tests with a Teamgroup A2 Pro Plus 1 TB Micro SDXC card were very promising. We would frequently record shows from three ATSC 3.0 and five ATSC 1.0 HD channels simultaneously. All was good for a few weeks. Then we noted that the card would go out to lunch from time to time. Both read and write performance would plummet to a few KB/s. We’re still trying to figure out what’s going on, but apparently other people have experienced this behavior with some SDXC cards as well. As the A2 Pro is a V30 card, it should have a minimum sustained write performance of 30 MB/s. Perhaps it has to do with the random write workload (there’s a cost to accessing flash pages and only so many can be “open” at a time). Or some vagary of ext4 and xfs filesystems (we tried both with various block sizes, journaling and other options).

But eventually we went back to using a USB-SSD adapter and a 2TB Teamgroup MP33 SSD.

Boot and volatile storage

With the SD  slot not being used for recording storage, we decided to use it as the primary system drive. One of the problems we’ve run into with the Pi (and PCs) is that if you remove USB or SD storage at an inopportune time then you can end up with a corrupted filesystem.  So we wanted the system drive to be read-only. With Ubuntu (what we’re running on the Pi), this can be accomplished with overlayroot. So far this is working well.

So what about volatile storage – things like the Entangle database, logs, and the like? For that were using a Samsung Fit Plus. It’s small. And its surprisingly speedy at small 4k random writes. CrystalMark benchmarked it at 16.2 MB/s for random 4k writes (Q1T1). In comparison a PNY Fit, which we originally used, came in at 0.38 MB/s.

Wi-Fi Configuration via Bluetooth

As we started to think about using the box outside of the lab, some aspects of the OOB (out-of-box) experience nagged at us. Sure, the EX is an engineering prototype so things can be rough around the edges, and once the the box’s network is up it can be configured via the web UI. The web UI is a bit clunky but serviceable. However having to ssh into the box via wired Ethernet on a static IP to configure Wi-Fi cut a little too deep.

As a headless device we had limited options, and Bluetooth seemed like a possibility to bootstrap the setup process. As we were starting to look into writing a BLE service for the Pi, we discovered someone had already blazed the trail. With a few tweaks their solution at https://github.com/nksan/Rpi-SetWiFi-viaBluetooth was exactly what we were looking for. And it even came with an iPhone app! (Sadly the sources for the app aren’t provided – we’d really like to merge it into the Entangle iOS app..)

Streaming

For the most part the EX behaves like its PC-based siblings. It can stream live and recorded TV to iPhones, iPads, Apple TVs,  and Fire TVs. You can fast-forward or rewind, and watch shows in-home or out-of-home. Starting initial playback or after trick play can take a fraction longer – even with hardware transcoding the Pi isn’t really a match for ffmpeg running on an 11th-gen Core i3. But we’re quite happy with it.

The one fly in the ointment is that while you can watch your ATSC 3.0 shows fine via Fire TV, they can’t stream to Apple devices. The reason is that to stream to these devices the show is transcoded from its as-broadcast format to H.264/AAC HLS…since Apple requires HLS with adaptive bitrate (at least if you want to go cellular), and you really do need adaptive bitrate to stream out-of-home. Plus the older iDevices we use don’t support H.265. For ATSC 1.0, everything’s great. We can easily decode the MPEG-2 video in hardware – or software (it’s not exactly computationally expensive) –  and use the Pi’s H.264 encoder. But when it comes to ATSC 3.0’s H.265…well for that we definitely need a hardware decoder, and its regrettably only available via the stateless V4L2 request API (which isn’t supported via stock ffmpeg 6.0.) There are patches to ffmpeg available which we hope will be merged into the next release…or we might use one of the other frameworks to access the H.265 decoder.

Headed or Headless?

Aside from streaming to other devices, Entangle does have a native linux UI built on top of SDL2 and CEF (for general rendering) and libVLC (for media playback). And we’re fairly certain it would come up fine on the EX.

However as a practical matter Entangles go where an antenna input and power is available – which could be an attic or wiring closet – not necessarily where a TV is. And really that’s how we envision boxes like Entangle EX being used these days. A “gateway” box tucked away in a corner and  streaming to mobile devices and TVs. With app ecosystems on smart TVs no additional stick or box would be needed. Just download the app and start watching!

Power Consumption

We’re big fans of minimizing power consumption, especially for things that are on 24/7. So one of our hopes with EX was to have a very low power box, but we’re not quite there yet.  A peak power of around 13 watts is ok, but idle power of 7.4w is surprisingly high – even with a Frankensteinish collection of components. We’ll need to take a look on where all that power is going.

EX is quite a bit better than a recent build using an Intel N100 processor in a NUC-like form factor. The N100 box itself drew about 10 watts at idle – and that doesn’t include any tuners! And for the sake of comparison, the Entangle powering SFBayATSC uses a Core i3-13100 and three 5400 RPM 16 TB hard drives. With two of the 13100’s cores disabled it idles at around 16 watts and draws about 50 watts under normal load. That doesn’t include the 8 HDHR4 tuners its paired with.

Power Consumption was measured at the wall using a WattsUp Pro with a wired Ethernet connection and no HDMI output. The HDHomerun Flex’s power supply was used (no 5v-12v boost converter). An Apple iPad 10 USB-C power brick supplied the Pi.

What’s in a name?

The EX is what we used to call a “blue wire prototype” back in the days when we were developing set-tops. Basically, take off-the-shelf components (or a previous-generation set-top box) and mod/wire them together to create the genesis of a new generation set-top box. For example the first HD DVR prototype for a certain major DVR manufacturer was created by wiring an ATSC tuner (among other things) into an existing DVR platform. (Red wires were used as often as blue, and we seem to recall other colors as well. Now that I think about it I don’t know why we always referred to the process as “blue wiring…”) A lot of hardware and software tinkering would go on, and when we thought we’d got things about right the design would be committed to a PCB prototype The blue-wire prototypes were designated PX and the PCB prototypes PY. We look forward to the day when we have an EY!

Some fans out there of a certain TV series franchise might also appreciate that our first EX build has been designated the EX-Alpha!

Locast launched in 2018 as a way for TV viewers to receive OTA TV without an antenna. For those of you familiar with the TiVo Stream (not to be confused with the more recent and most unfortunately christened TiVo Stream 4k), the Locast service essentially does what the Stream does.: it makes the OTA broadcast friendly to network (including internet) streaming. Basically, the Locast service receives the OTA station (using an antenna) and converts it into a broadband stream. Viewers can then use apps on their televisions, set-top boxes, streaming sticks, or other devices to view live programming.

I Want My TV!

As one might imagine, here at Koherence we have a better than usual OTA setup. There are multiple antennas, that provide optimal orientation towards the broadcast towers as well as providing redundancy. The multiple antenna inputs are also used to provide diversity. The combination of these usually results in error-free broadcast reception.  The entire Entangle setups are also on UPSs that can withstand an hour or so of power outages.

But even with those measures, there are times when we receive an imperfect or no signal.  An increasingly common problem is power outages. One wouldn’t think that would be an issue in the heart of Silicon Valley, but go figure. Twice this year there have been outages that ran down the UPSs.

Also problematic at certain times of the year is a weather condition known as atmospheric ducting. Basically, broadcasts farther away interfere with (and  in some cases overwhelm) the local broadcast. This is particularly true where the local broadcast is low-power, in which case the local broadcast is overwhelmed and the remote broadcast is received in its place. But it can also happen with higher power broadcasts where a transient impairment (such as those caused by planes or trees swaying in the wind) pushes reception over the threshold of the tuner’s sensitivity and error correction, resulting in errors in the broadcast stream. Naturally these events happen at the worst possible time, such as when Emeril Lagasse says, “And now let me tell you the secret to the perfect chocolate mouse – all you have to do is”…<LOSS OF SIGNAL>.

While we appreciate that receiving the OTA broadcast provides the best possible picture quality – Locast’s transcoding inevitably yields some amount of resolution and/or quality loss – one cannot argue with being able to watch broadcast shows without intermittent macroblock – or just being able to watch it in the case of an extended power outage!

What’s The Big Deal?

As is so often the case, the issue swirling around Locast is related to money. But wait, you say, OTA TV is free isn’t it? Well yes and no. If you think about it, all those people working at your TV station probably aren’t working for free. They need equipment to do their jobs, not to mention all the equipment needed to broadcast a signal. If your station has a newsroom then that crew needs to be funded too. So where does all that money come from? In the Good Old Days advertising provided a chunk of revenue.  This is one reason why commercial skip features are so controversial. They quite literally starve the hand that feeds them. Long form advertising (informercials) are another way to raise money, as are having shows sponsored. All of these are still applicable today.

But over the years other forms of revenue have popped up. Retransmission fees are now a non-trivial source. Retransmission fees are fees that a broadcaster charges cable, satellite, and other providers to retransmit their signal. If you subscribe to cable you’ve probably seen this fee passed on to you on your bill. To give you an idea of how important retransmission fees have become, in 2010 they were for the most part non-existent. By 2018 they were close to $10 billion range and was overtaking advertising revenue.

As you might guess, this is where Locast is problematic. It doesn’t pay retransmission fees to the broadcasters whose signal it is retransmitting. Locast says it is operating under the Copyright Act of 1976, which lets a nonprofit entity retransmit a broacaster’s signal in order to extend the signal into regions where it is not received well (but of course still within the region where the signal is intended to be received.) This allowance was intended to allow repeaters to be set up. Consider for example a valley where the signal from a tower is obstructed. A strategically placed repeater could allow viewers in the valley to receive the broadcast. Rather than extending the range of the broadcast, Locast overlaps with the original broadcast area. Through geofencing Locast does attempt to limit who can access channels based on where they are located. So if you’re in San Francisco you can’t watch Locast’s Phoenix channels (…unless of course you use a VPN making it look like you’re in Phoenix…)

There are other aspects to the Locast controversy and we’ll touch on just one more here: content rights. Basically whoever produces a show has the right to monetize it. Broadcasters either have to create that content themselves (think news broadcasts, or series produced by a parent or affiliated company), or pay a license to whoever owns the content. In retransmitting a broadcaster’s signal, Locast is effectively taking content which a broadcaster paid for (either by paying for its production or via licensing fees) and providing that content free to viewers. The Copyright Act of 1976 does allow a nonprofit translator to rebroadcast signals without a copyright license from the broadcaster.  It should be noted however that if a broadcaster licenses content, it may or may not have the right to stream that content over the internet- if the broadcaster doesn’t provide a live stream of its own it has no reason to negotiate that right.

So Is Locast A Good Thing?

There’s no question that the concept behind Locast – making OTA signals available via broadband – is a good thing. Given the choice, who wouldn’t want to load an app onto their smart TV or phone instead of trying to install an antenna and locating that one perfect spot and orientation that lets you get most of your local broadcasts?

But at the same time its hard to deny the harm Locast does to broadcasters. Whether we like it or not, “free TV” has only been free in the sense that we don’t send money to our local TV stations. We do allow them to make money by watching ads or sponsored content, and retransmission feels are in fact subsidizing OTA viewers.

There are certainly things Locast could do to mitigate things. For one, it could pay retransmission fees. While Locast is free, it does ask for a $5/month donation.  As of 2020 Locast was receiving enough in donations that it was sustainable, which suggests that it could soon be in a position to give some of that money to broadcasters – effectively paying a retransmission fee.

Locast could also collaborate with local broadcasters by providing the infrastructure for providing a live stream of the broadcaster’s signal. This might be particularly attractive to stations which do not already provide a live stream.  No doubt there might be some additional work to make the Locast live stream look like it was owned by the station, and things important to broadcasters like audience measurement would need to be considered. For those cases where a station already provides a live stream it is questionable whether Locast should be operating in the first place. But even if Locast were to stop, or not, provide a live stream services that overlap with a broadcasters, its service and application would still have tremendous value as aggregation service – one which allows users a single place to go to for local live streamed broadcasts, whether those streams are provided by Locast (on behalf of a station), or by the station itself.