Taming excess data usage by Chromecast

Chromecast uses a lot of data, even while idle.  This tip can help reduce that usage.

This has been a known issue for some years, going back to at least 2014.  The problem is the Ambient Mode in Chromecast, which displays artwork and images when nothing is being streamed to the Chromecast.  And to be sure, the images it displays are attractive and fun to look at.  But because they're so high-resolution, the data consumed by Ambient Mode is noticeable. 

The problem is exacerbated by the increase in data usage from newer smart home devices like doorbell cameras and security cameras, which tend to upload large amounts of data to the cloud for AI features like facial recognition.  Combined with the high data usage of Chromecast Ambient Mode, this puts you at risk of exceeding the data caps from your ISP - and getting an unexpectedly large bill.

In the past, tips such as plugging the Chromecast's USB power cord into the display's USB ports (so that it's unpowered when the display is off) are helpful, but that still means the Chromecast is using data any time you're using the display for any reason.  During a long weekend of DVD watching the Chromecast will still consume data as it downloads high-res photos.  A couple of years ago, someone had the idea to post two small 16 x 9 pixel images of a solid color in Google Photos, and then set the Chromecast to display only that image folder, but for some reason that's no longer working.  Another tip is to set the Chromecast to cycle images only every 10 minutes, which helps but not very much. 

Chromecast now has an Experimental Mode for Ambient, which now includes a Low-Bandwidth setting.  But if you're operating on a very limited data plan, even this may be too much.  So what to do?

My tip is to block Chromecast from getting data at all.  Use your Wi-Fi router's client management feature to block the Chromecast when you're not using it.  I use the Google Wi-Fi mesh system, which allows me to create an On/Off blocking switch for any Wi-Fi client device.  Most modern Wi-Fi routers have a client management feature.  When I want to use my Chromecast, I unblock it.  When it's blocked, it can't access the network - so it can't download anything, and you run less risk of exceeding your data cap. 

Mobilinkd interface with TM-942A / Shack

A while back I bought the excellent Mobilinkd TNC - a device that interfaces amateur radio with smartphones and PCs via Bluetooth.  There are a ton of useful applications for this, not the least of which is being able to place my radio where I want it, and not be cable-tethered to it.  I've used the Mobilinkd TNC with a Kenwood TH-F6A as a mobile device, and that worked very well - I can leave my radio and the TNC in my backpack and type messages on my smartphone.  If I'm doing something mobile/portable like parade/race support, I put the radio/TNC and a battery pack up where it can get good reception and use my smartphone or PC as the interface - as long as I'm in Bluetooth range, I'm good. 

I've long been a fan of the old Kenwood TM-742A and TM-942A tri-band mobile radios.  I own several of them, and have become fairly well-versed in the art and science of repairing them.  I've always been curious about a somewhat unique feature of the radio, which is the Receive Data (RD) line on the microphone 8P8C connector - it's a direct feed of the receiver audio intended for packet radio that bypasses the final audio shaping/amplification stage, with a 100 mV pk-pk signal across a 10k load. 

I run a TM-942A (which is just a TM-742A with the 1.2 GHz band module in third slot) in my shack, which is interfaced to an MFJ-1263 microphone switch.  I thought it would be interesting to wire the Mobilinkd into the MFJ-1263 switch, so I could use the TM-942A for audio or APRS/packet at the flick of a switch.  The RD line makes this really simple to wire up.  Critical for APRS/packet applications, the RD line is tapped off before the squelch and CTCSS circuits - so I can monitor the audio for debug, or mute it as needed, without having to worry if the squelch and CTCSS settings are screwing with the RD line.  (Of course, this requires me to run DCD on the TNC software, otherwise it will never transmit while it sees the channel as "busy".)  Volume control also has no effect. 

I started off by ensuring that the MFJ-1263 was jumpered properly to bring the TM-942A connector out to the switch's front panel 8P8C jack without re-ordering the pins.  I put this onto the switch's A-side, and left my voice microphone on the B-side.  I had previously built a 3.5mm (1/8th inch) TRRS cable with breadboard pins soldered to the ends for my test kit.  I also have an 8P8C breakout board in my test kit.  Both pieces were jumpered together on a small breadboard.  Once I had the wiring confirmed, I made the cable permanent.  It might sound like overkill to proceed this way, but the TM-942A's microphone jack also has an 8 VDC (@ 100 mA) voltage source, and I wanted to make sure I wasn't injecting a voltage into my TNC. 

I'm really happy with this set up - I can use the Mobilinkd TNC at home, or take it mobile by simply unplugging the TRRS connector and USB power cable.  My Mobilinkd stays charged via USB when it's in the home configuration.  My only gripe is that the Receive Data line from the TM-742A is a fixed level which is slightly lower than the Mobilinkd's software wants to see, but it doesn't appear to be affecting decode on APRS.