Previously on this site we examined the possibility of using a Caldigit TS3 Thunderbolt 3 dock to provide power to a downstream Thunderbolt 3 device (expensive way of doing it, but this dock is useful for a lot of other things). I said I’d check some of the other peripherals to see what works and what doesn’t, when you use this dock with a TB2 MacBook, via an adaptor.
So, read on to find out what works, and what doesn’t.
(BTW - short Thunderbolt 3 cables like this one are passive and also work for USB 3. Longer TB3 cables (>1m) are active and only support USB 2. This is why the Thunderbolt 3 cable seen here is successfully being used with the USB 3.2 SSD enclosure at full speed. Thunderbolt 2 cables, however, are all active - hence the price.)
So where we left off last time, I had a 10Gbit Thunderbolt 3 adaptor, and a mid-2014 Macbook Pro that I couldn’t plug it into.
I found out that you can in fact use the Thunderbolt 3 to 2 adaptor in a “backwards” configuration. I purchased the 2m TB2 cable - quite expensive at $65 for the cable. This is because although Thunderbolt 3 allows for short passive cables, all TB2 cables are active. Surprisingly, purchasing brand new from Apple was actually the cheapest option over anything on Amazon or eBay.
I bought the TB3 to 2 adaptor off Amazon for $9. That’s suspiciously cheap, and the one I got was labelled for sale in Brazil. Given Amazon’s approach to stock fungibility, it probably wasn’t even the one that the seller put into the system.
There’s just one catch - it doesn’t provide bus power from the TB2 side to the TB3 side. I looked for a third party adaptor that did, but Startech was the only 3rd party vendor to ever make one and that one doesn’t even support reverse mode.
Just to make sure I was right about this limitation, I tried it anyway. As expected, it didn’t work.
The other way round - a TB3 Mac using a bus powered TB2 Gigabit adaptor works fine.
So what we need is something to inject bus power - preferably something quite cheap. I looked for a suitable cable, but finding nothing (I’m really surprised I can’t find something), I heard others had success with docking stations.
Searching eBay finds that the StarTech TB3DKDPMAW was available for as low as $60 (without power brick). It only takes a 12v DC barrel jack, so this seems pretty cheap and easy.
Why so cheap and unwanted? It only does 15w USB PD back to the host, meaning that unlike other popular docks on the market, you can’t charge your laptop with it.
This isn’t a problem here, because we can’t charge through Thunderbolt 2 anyway, so you’d expect that at this point, I’d have bought this obscure bit of largely unwanted hardware that might do exactly what I want. But I didn’t.
By the time I get it shipped to me, and dig up a suitable power brick, it’s approaching half the cost of a CalDigit TS3+, a very popular Thunderbolt 3 laptop dock, that has tons of ports and the capability to charge the connected laptop at near 90 watts.
When I inevitably buy a new MacBook Pro, I can use the dock with that, rather than relegating the old dock to the bottom of a “random cables” drawer - making this a much better investment.
So I borrowed a CalDigit TS3+ dock from someone who already had one, while I wait for this one to arrive.
The old fileserver was filled with a mixture of 3TB and 4TB disks, which were starting to become increasingly unreliable. The ZFS pool couldn’t expand until all the 3TB disks were replaced with 4TB, the SAS card they were connected to was obtained suspiciously cheaply as it was an uncommon chipset variant that’s not supported very well in Linux, the onboard SATA had persistently many read errors on one of the ports, I never quite liked the HTPC case it was in, and fixing any of these problems would inevitably require replacing most of entire server.
So a new fileserver was built in a 2RU rackmount case. 8x 12TB drives fill the front panel which has drive bays rather than the drives being internally mounted. 64GB of ECC RAM is fitted to the motherboard, with all the drives attached to 8 onboard SATA ports. It’s running an AMD CPU, because the current generation allows ECC on all CPUs without onboard graphics if the motherboard supports it (unlike Intel where only the high end Xeon line supports it). Two NVMe SSDs are installed on the motherboard - a 256GB one for the OS to boot from, and a 1TB one for L2ARC. A NVidia GT710 provides graphics, should the console ever need to be used - and maybe I can use it for hardware H.264 decoding/encoding to transcode some media later on - although I’m not totally sure it’ll be faster than doing so on the CPU.
It’s much more interesting with the top off…
I did, however, need a low profile 10Gbit network card. You may recall a long time ago, I picked up a bunch of Mellanox ConnectX-2 cards for about $35 each. Now, nearly four years on, the later ConnectX-3 cards are now selling for about $50, so I bought two with full height brackets, and a third with a low profile bracket (for a few dollars more). All three subsequently turned up with both kinds of bracket included.
Top left: Intel dual-port gigabit. Top centre: Mellanox ConnectX-2. Bottom row: Mellanox ConnectX-3, times 3.
Filming footage in 4k resolution isn’t difficult - the GoPro has been able to film 4k30 since the GoPro 3, and 4k60 since the GoPro 6. Most recent mobile phones can film in 4k as well.
But editing this footage is a different matter. The H.264 / H.265 codecs that are used for such footage gain their efficiency by making heavy use of references to previous (and sometimes even future) frames in their encoding. This is fine for playback, providing you have a powerful enough machine, but if you want to edit said footage, you’re going to want to be able to freely step back and forward through the frames.
The solution is to make use of proxy media. This refers to generating a lower resolution copy of every clip, and using it instead of the original clip during the edit process. But for the full quality final export, the video is generated using the original clips.
When you import footage into Final Cut Pro, there’s a checkbox here to generate proxy media. By default, proxy media is generated using the Apple ProRes 422 LT codec. This DCT-based codec uses only intra-frame compression to allow immediate seeking to any frame, and is very light on CPU load for playback.
But suppose that, say, your main editing machine - a quad core i7 MacBook Pro with 16GB of RAM discrete graphics - was dead, and you were using the “backup” machine - a much slower dual core i5 with 8GB of RAM and no GPU. The proxy media sure is going to take a while longer if there’s 200GB of footage to sort through.
On the other hand, let’s say that you have a much more powerful Linux machine that could be doing all the hard work instead. FFmpeg has an encoder for ProRes. How do we generate the proxy media on the server, then have Final Cut Pro recognise and use it?
It’s a fairly simple process, but it’s not entirely straight forward, and I haven’t seen anyone else describe how to do it - hence I wanted to document it here for the benefit of others. Read on to find out how.
There was just one major issue with it - the modem operates in serial mode, due to RouterOS v6 having no MBIM support (RouterOS v7 does but it’s still unreleased).
For a while now I was considering using another device to do the routing - like a Raspberry Pi, oDroid or Beaglebone. But I wanted one that booted quickly, isn’t SD card based (I have replaced so many cards at inconvenient times) and I wanted something that is less picky about power input.
On Twitter. I saw that @decryption bought a Mikrotik RBM11G to run ROOTer - an OpenWRT based firmware that is designed specifically to route a LTE modem.
The RBM11G looks nice - wide DC input, gigabit ethernet, miniPCIe slot. Running something that has a newer kernel than RouterOS v6 would give me MBIM support and might also stop the random dropouts that require power cycling the modem to make it seen again. I have a suspicion it’s either related to the unsupported PPP serial or maybe the RB2011’s USB hardware. Either way this fixes it.
I’ve previously covered building a multi-band linked dipole Inverted V antenna on here. This antenna has been a great performer - when and where you can set up the pole, get the angle on the V correct and keep other stuff out of its near field. Failing to do this will result in a VSWR that’s a little less than great.
And with the Codan 9323 running in addition to the Icom 7100 on some radio-based outings, a second HF antenna was needed.
I decided to build an end-fed random wire. It’s a compromise on performance but it’s much more versatile and easy to deploy.
On the left: Garmin eTrex H (aka eTrex High Sensitivity), the 2007 update of the iconic yellow eTrex. (BTW - The screen is much more readable head on).
On the right: Garmin eTrex 10, released in 2011 (but purchased by me in 2018).
Why is the device on the left displaying a date in 1999? Because GPS just had a little Y2K style problem of its own. The 10 bit week number just rolled over to zero for the second time since the GPS system was switched on. Aside from the date being completely wrong, the device still finds a GPS position but it takes significantly longer to acquire satellites.
This has happened before in 1999 but back then GPS was much less of a consumer product (the first eTrex was still a year away) and most devices were programmed to cope with it. This time around though, there’s a lot of older, lower cost GPS devices still in use that may well have outlasted their manufacturers.
Fortunately the newer GPS signals have a 13 bit week number meaning this won’t be a problem again until 2137. For older devices still reading the 10 bit date/time, it’ll happen again on the 20th of November 2038 - 10 months after dealing with the other 2038 problem.
I bought the eTrex 10 to replace it because I don’t think there’s a firmware update coming for such an old device.
So I guess my eTrex H outlasted the 10 bit counter - now I guess we see if the eTrex 10 lasts until 2038…