The Project Entangle EX

 

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!