The creativity of 3D printing

raspberry pi camera mount

One of the things I love about 3D printing is the creativity of it. I didn’t want to print any supports, so by putting a flat spot on one side I could print it with no cleanup needed.

Black and Decker Portable AC

I recently picked up a Black and Decker Portable AC https://www.amazon.com/Black-Decker-Portable-Conditioner-Display/dp/B01DLPUWG2 and wanted to port over a Blynk project I had created. I couldn’t find anything online about what the infrared protocol is for the remote. So here you go:

Protocol  : TCL112ACCode      : 0x23CB26010024030D00000000C009 (112 Bits)Mesg Desc.: Power: On, Mode: 3 (Cool), Temp: 18C, Fan: 0 (Auto), Econo: Off, HealProtocol  : TCL112AC
Code      : 0x23CB26010024030D00000000C009 (112 Bits)
Mesg Desc.: Power: On, Mode: 3 (Cool), Temp: 18C, Fan: 0 (Auto), Econo: Off, Health: Off, Light: On, Turbo: Off, Swing(H): Off, Swing(V): Off
uint16_t rawData[227] = {3134, 1586,  496, 1174,  504, 1166,  502, 334,  494, 366,  474, 362,  476, 1166,  502, 332,  496, 340,  498, 1170,  498, 1172,  496, 366,  474, 1194,  474, 336,  502, 358,  470, 1174,  506, 1164,  504, 332,  496, 1174,  494, 1176,  504, 358,  472, 336,  502, 1166,  502, 334,  494, 340,  500, 1168,  500, 336,  504, 358,  472, 336,  502, 358,  470, 364,  476, 332,  496, 364,  474, 360,  468, 366,  472, 362,  478, 358,  472, 334,  504, 356,  472, 362,  476, 358,  470, 364,  474, 360,  470, 1172,  496, 366,  474, 334,  494, 1174,  504, 330,  498, 336,  502, 1166,  502, 1168,  500, 334,  496, 340,  498, 362,  476, 332,  498, 336,  502, 332,  496, 1172,  496, 338,  502, 1168,  500, 1170,  498, 336,  504, 358,  470, 364,  474, 360,  470, 364,  474, 362,  468, 340,  498, 360,  468, 366,  472, 362,  476, 332,  496, 364,  476, 332,  496, 366,  476, 332,  496, 338,  500, 360,  468, 366,  472, 336,  504, 356,  472, 364,  476, 358,  470, 364,  476, 358,  470, 364,  474, 360,  468, 366,  474, 360,  468, 340,  500, 362,  468, 366,  472, 362,  476, 358,  470, 364,  474, 332,  498, 364,  476, 332,  496, 366,  474, 360,  468, 366,  472, 362,  476, 330,  498, 1198,  472, 1172,  496, 1174,  496, 338,  500, 362,  478, 1164,  504, 330,  498, 364,  476, 360,  468, 366,  474};  // TCL112AC
uint8_t state[14] = {0x23, 0xCB, 0x26, 0x01, 0x00, 0x24, 0x03, 0x0D, 0x00, 0x00, 0x00, 0x00, 0xC0, 0x09};
th: Off, Light: On, Turbo: Off, Swing(H): Off, Swing(V): Offuint16_t rawData[227] = {3134, 1586,  496, 1174,  504, 1166,  502, 334,  494, 366,  474, 362,  476, 1166,  502, 332,  496, 340,  498, 1170,  498, 1172,  496, 366,  474, 1194,  474, 336,  502, 358,  470, 1174,  506, 1164,  504, 332,  496, 1174,  494, 1176,  504, 358,  472, 336,  502, 1166,  502, 334,  494, 340,  500, 1168,  500, 336,  504, 358,  472, 336,  502, 358,  470, 364,  476, 332,  496, 364,  474, 360,  468, 366,  472, 362,  478, 358,  472, 334,  504, 356,  472, 362,  476, 358,  470, 364,  474, 360,  470, 1172,  496, 366,  474, 334,  494, 1174,  504, 330,  498, 336,  502, 1166,  502, 1168,  500, 334,  496, 340,  498, 362,  476, 332,  498, 336,  502, 332,  496, 1172,  496, 338,  502, 1168,  500, 1170,  498, 336,  504, 358,  470, 364,  474, 360,  470, 364,  474, 362,  468, 340,  498, 360,  468, 366,  472, 362,  476, 332,  496, 364,  476, 332,  496, 366,  476, 332,  496, 338,  500, 360,  468, 366,  472, 336,  504, 356,  472, 364,  476, 358,  470, 364,  476, 358,  470, 364,  474, 360,  468, 366,  474, 360,  468, 340,  500, 362,  468, 366,  472, 362,  476, 358,  470, 364,  474, 332,  498, 364,  476, 332,  496, 366,  474, 360,  468, 366,  472, 362,  476, 330,  498, 1198,  472, 1172,  496, 1174,  496, 338,  500, 362,  478, 1164,  504, 330,  498, 364,  476, 360,  468, 366,  474};  // TCL112ACuint8_t state[14] = {0x23, 0xCB, 0x26, 0x01, 0x00, 0x24, 0x03, 0x0D, 0x00, 0x00, 0x00, 0x00, 0xC0, 0x09};
Protocol  : TCL112ACCode      : 0x23CB26010020030D00000000C106 (112 Bits)Mesg Desc.: Power: Off, Mode: 3 (Cool), Temp: 18C, Fan: 0 (Auto), Econo: Off, Health: Off, Light: On, Turbo: Off, Swing(H): Off, Swing(V): Offuint16_t rawData[227] = {3138, 1582,  502, 1170,  498, 1170,  498, 364,  476, 360,  468, 366,  472, 1196,  472, 364,  476, 360,  468, 1200,  478, 1166,  502, 332,  496, 1200,  468, 368,  472, 362,  476, 1192,  476, 1166,  502, 362,  478, 1192,  476, 1168,  500, 362,  478, 356,  472, 1196,  472, 364,  474, 360,  468, 1200,  478, 330,  498, 364,  476, 360,  468, 364,  474, 360,  468, 366,  472, 362,  476, 358,  470, 364,  474, 360,  468, 364,  474, 360,  468, 366,  472, 362,  476, 358,  470, 364,  474, 360,  468, 364,  474, 360,  468, 366,  472, 1194,  474, 362,  476, 358,  470, 1198,  470, 1174,  504, 358,  470, 364,  474, 360,  468, 366,  474, 362,  478, 358,  470, 1196,  472, 366,  474, 1194,  474, 1170,  498, 364,  476, 360,  468, 366,  474, 360,  468, 368,  472, 362,  476, 358,  470, 366,  474, 362,  466, 366,  474, 362,  468, 366,  472, 362,  476, 360,  470, 364,  474, 360,  468, 366,  474, 362,  478, 356,  472, 364,  476, 358,  470, 366,  474, 362,  478, 356,  472, 366,  474, 358,  470, 364,  474, 360,  468, 366,  472, 362,  478, 356,  472, 362,  476, 358,  470, 364,  474, 360,  468, 366,  474, 1196,  474, 336,  504, 358,  472, 364,  474, 360,  468, 366,  472, 1194,  474, 1170,  498, 364,  476, 1194,  474, 1170,  498, 362,  476, 360,  470, 366,  474, 362,  476, 358,  472};  // TCL112ACuint8_t state[14] = {0x23, 0xCB, 0x26, 0x01, 0x00, 0x20, 0x03, 0x0D, 0x00, 0x00, 0x00, 0x00, 0xC1, 0x06};

TDR with the NanoVNA

The performance of my satellite downlink station is nowhere near as good as I would like. I been doing some various troubleshooting measures to try and figure out what is going on. In my previous post, you can see some of my explorations about antenna tuning. In this post I took my first pass at exploring the feedline situation. It’s been up for at least five years and wanted to make sure nothing untoward had happened to it.

To help measure it, I ran a TDR test on the feedline. This is not a perfect measurement as I left the antenna attached, which messes up some things. But it gives you the opportunity to measure where impedance changes occur in the feedline. Here’s what the resulting plot looks like:

At first I was terribly confused thinking my feedline was terribly broken. It’s important to note that the current NanoVNA-Saver software doesn’t present TDR the way most people expect. It stacks the impedances of the various segments, so you shouldn’t read that big flat segment in the middle as being at 90 ohms.

Breaking it down by segment I get the following: short stub that adapts SMA to UHF connector; 10 feet of LMR 400 equivalent; a big impedance jump as the signal travels through a 3 inch barrel connector through a door; 30 feet of LMR 400 outside; another barrel connector; 10 more feet of LMR 400; then the antenna.

What did I learn in the end? It looks like my various lengths of cable are fine. Most importantly I learned that UHF connectors have a surge impedance of around 35 ohms instead of the 50 ohms we are looking for. That causes reflections and increases the return loss of your feedline. Wikipedia article on the impedance of UHF connectors: https://en.wikipedia.org/wiki/UHF_connector

So where does that leave me?

This showed I didn’t have any problems in my feed lines other than the ones I caused myself by using UHF connectors and patching together shorter lengths of cable. My next steps to evaluate the system performance will be to measure the SWR and return loss of just the feedline without the antenna connected. This means I’ll replace the antenna with a 50 ohm calibration standard to measure return loss; then replace it with a dead short to measure insertion loss. More detail here: https://www.tek.com/blog/improving-vna-measurement-accuracy-quality-cables-and-adapters

I’ve been having a strong desire to replace every UHF connector with a Type N connector. These measurements are an attempt for me to quantify what, if any, practical improvement I would see from that change. I fear that my real problem is that I live in a city and there is just far too much noise around me.

I cut it twice and it’s still too short!

For my satellite ground station I built an antenna from the plans by WA5VJB http://www.wa5vjb.com/references/Cheap%20Antennas-LEOs.pdf

I originally built a 7 element 70cm antenna. But then added on a two element 2m one. While I had tuned the 70cm antenna, it was tuned a little too low after the second cut to shorten the driven element. But it passed, just barely.

While attaching the new antenna to the old, I got frustrated smacking the darn thing into everything and hacked off the end, converting it to a 5 element in short order. With years of experience under my belt I have learned that anger is not a great engineering design philosophy.

I didn’t check the tuning before mounting it up here.

Lets take a look at what the NanoVNA Says. This is the return loss chart for 2 m frequency.

While the tuning is a little low for what I want, it’s close enough to work. For example most satellites are around 145 MHz.

Unfortunately this is awful. I need tuning closer to 435 MHz, this bad boy is coming in at 415 MHz. Looks like it’s time to take out the plumbers torch and solder some more wire back onto the antenna :).

abandoning Pi-Hole for cloudflared

I’ve been using Pi-Hole for a while and it just caused too many problems. Many shopping carts across the web would just fail. I need to run google ad campaigns and you can’t get to the admin UI. Therefore I decided to move dns resolving back to my ER-X and instead use cloudflared to resolve DNS queries so CenturyLink has a harder time selling my browsing history.

I found a great post on how to do this at: https://reichley.tech/dns-over-https-edgerouter-x/ but it doesn’t cover the v2 series of EdgeOS based on Debian 9. These are my quick notes on changes to their directions.

When you install a new update of EdgeOS, it overwrites all the default partitions such as /usr. Therefore I decided to store my files in /config/user-data which is an area that persists between system updates.
On edgeos:
mkdir /config/user-data/cloudflared
On machine used to upload:
scp cloudflared user@erx:/config/user-data/cloudflared

I also decided to store a copy of config.yml in this directory before copying it over to /etc/cloudflared/config.yml. That way after an upgrade I have less work to do.

EdgeOS v2 uses systemd instead of init.d for startup.

sudo cp /config/user-data/cloudflared/config.yml /etc/cloudflared/yml
sudo /config/user-data/cloudflared/cloudflared service install
sudo vi /etc/systemd/system/multi-user.target.wants/cloudflared.service  

Modify line to include pid info (not sure if we need this with systemd)

ExecStart=/config/user-data/cloudflared/cloudflared --config /etc/cloudflared/config.yml --origincert /etc/cloudflared/cert.pem --pidfile /var/run/$name.pid --no-autoupdate 
sudo systemctl enable cloudflared.service
sudo systemctl start cloudflared.service
systemctl status cloudflared.service  

Also /usr/sbin wasn’t in my path, so I had to call tcpdump directly.
/usr/sbin/tcpdump -nXi eth0 port 443 and dst host 1.1.1.1

After an upgrade I should only need to do re-run a few of the steps above.

Satellite Fun

I’ve been slowly working towards building a satellite uplink and downlink station for years. I have finally reached a point where I finished building the station and have Receive some signals.

The performance is rather abysmal, I still have a fair amount of work to do.