Computing ⁽³⁷⁾

Here is the setup for GB7RVB, not much to see really. The radio is a Tait TM8110 which has been configured according to information on the OARC wiki. The NinoTNC is next to it, both currently sitting on top of my Portsdown. Above, and annoyingly not square because I need to move some cables, is the Pi 4 which is PoE powered from a Netgear switch.

I actually achieved something. Makes a change! At this stage I must state that I overlooked the fact I have an FTM100 and it has a suitable interface! Ok, no way I am going to fiddle soldering a 10-pin mini-DIN plug even if I had one, so I ordered a CT167 cable from www.JGTech.com which arrived within two days. I already had a stock of D9 plugs. With the NinoTNC connected to the Windows PC the APRSIS32 software could send and receive APRS to/from my FT2D (no APRS activity round here other than a receive-only igate). But packet was a tad more problematic. I wanted to use the Windows PC + Signalink + FT817 setup which means using QtSoundModem on the PC, but I also needed a program to talk to the TNC. QtTermTCP will via KISS but neither the Mac or Linux version had KISS anywhere to be seen, only AGW. And any mix of QtSoundModem and QtTermTCP on the Windows PC generally resulted in nothing talking to anything, which is probably my fault but it definitely got in the way. So... I set up an old Pi 3B with the LinBPQ software, connected the NinoTNC / FMT100 to…

See, I built it! And it works. The 3D printed case needs a bit of tidying but is perfectly functional. All I need now is a radio to use it with plus probably re-use one of my spare Pi 3B cards to drive it.

Note to self... stop collecting bits for projects and start building instead! Just in, this PCB and chip for the TARPN NinoTNC. Described as a multi-speed, multi-protocol USB-KISS packet radio interface this comes as a very nicely made PCB and PIC plus a bill of parts complete with Mouser part numbers and a spreadsheet that loads into Mouser to make a complete order. This will be a fun build. The TARPN website also has full ordering and step by step construction details. Neat!

Recently the outside lights here decided to switch off at random intervals for no apparent reason. There are 5 different controllers, two being Zigbee bulbs and the others Zigbee switches. All use 2.4GHz. All had been running reliably for maybe a year. On/off cycles are controlled by scripts on the server as well as manually via an app. In each case whichever set of lights had gone out did report as being off and would turn back on via the app. Some days there was no issue, on others at least one would go off at some point. The Zigbee bulbs never failed, just the switches. There was no evidence of any commands being sent to turn the lights off, but there was the occasional error being reported. Rebooting the server made no difference. A power cycle of the server seems to have cured the issue so I am considering it likely to be the Zigbee transceiver itself. This is now nagging at me to figure out what happened and presumably it will reoccur some time in the future. Too many other things to sort out though!