Computing ⁽³⁷⁾

It's surprising just how many things one gathers that need Ethernet. Having just made an NTP server out of a Raspberry Pi that took the last port in my 8+2 port PoE switch I needed more ports. The switch is a Netgear GS110TP, 8 Ethernet ports and up to two SFP modules for interlinking. So I have added a second GS110TP linked to the original one via a short fibre lead and two SFP transceivers. The house now has 4 Ethernet switches, all Netgear, making 48 Ethernet ports in total but not all in use, plus 3 wifi access points, Netgear again and all PoE powered. Actually I could have settled for a non-PoE switch as the additional one but this one came cheap, and new in box. All the switches and access points do SNMP too, centrally monitored using MRTG. Why? Because they can!

I decided to make my own Stratum 1 NTP server for the home. No, I don’t need the accuracy, but localising stuff like that is always interesting. So, I recently purchased an Uputronics GPS HAT from Pi Hut which is marked Raspberry Pi GPS+RTC Rev 6.4. It arrived next day along with some other bits. I also got another PoE HAT and already had a Pi 4. Raspbian installed on an SD card – this time I remembered to first set it up to work via ssh – and the Pi booted ok with the GPS board flashing it’s ‘time pulse’ LED once per second. I followed instructions on the web, in particular from the two websites shown at the bottom of this post. Initial setting up of the Pi involves the use of raspi-config to stop the serial port login shell but leaving the port enabled, and disabling serial getty and bluetooth. At this point, doing cat /dev/ttyAMA0 should return data from the GPS receiver but all I got was garbled characters. More on that later. The next step was to enable PPS support which involves modifications to /boot/config.txt and a module adding to /etc/modules, plus downloading pps-tools. Running sudo ppstest /dev/pps0 looked ok but again, more on that later. Next was to install gpsd and modifying /etc/default/gpsd plus setting it up to run at boot time. After a reboot running sudo service gpsd status returned valid information. The gpsd-clients package was installed which includes gpsmon. Running gpsmon showed that all was not well. It generated a few lines but nothing that meant any sense. I then returned to sudo ppstest /dev/pps0 and noticed this time that all it was giving was timeouts. I may well have missed this in my haste earlier as it reports ok, but then gives timeouts. An, unfortunately not recorded web page suggested adding arm_64bit=0 to /boot/config.txt and after rebooting sudo ppstest /dev/pps0 now produced a valid line, once per second. Ok. Retracing my steps I ran gpsmon again to take a closer look and noticed that in the few lines it managed to display was the entry ‘”bps”:9600’. That was the lightbulb moment. The GPS board defaults to 115200. Stopping gpsd and running minicom -b 115200 -o -D /dev/ttyAMA0 produced valid GPS data. Modifying /etc/default/gpsd to set the baud rate to 115200 (GPSD_OPTIONS=“-n -s 115200”) fixed the issue. But, gpsmon still does not produce all the output that I had expected, in particular it does not populate the time and date fields. Running cgps does show valid information and suggests that all is well and there is something I am missing regarding gpsmon. At the end of the day it all appears to be working fine. The next package installed was chrony. This all went to plan and running chronyc and its sources and sourcestats options showed valid data after the system had settled down for a couple of minutes after boot. The final leg of this journey was to set up various…

Still sorting the shack out today, hopefully two more days and it’s done. Today’s task was to fit PoE HATs to the two Raspberry Pi systems that run things like Pi-Star, the ADSB grabber and HamClock. These were both Pi 3B’s which do not have the pins for PoE - the 3B+ or the 4 does. So, first off, strip the cards out of the box. Not too bad. The first Pi 4 and its HAT was easy but the Pi Star one has the RF board. Installing the PoE HAT does not leave any of the Pi 4’s pins protruding. Fortunately I had a small stock of extenders, in fact, just enough. Not the neatest of constructions but it works. One thing caught me out though. The Pi Star Pi gets a static IP address via DHCP. When it booted up it would not let me connect or get to the web interface. A scan of the network found it and only then did I remember that, of course changing the card means a new MAC address! Anyway, both cards now have their MAC addresses in pi-hole (even though the IP is static doing it that way makes pi-hole record their activity against the names) and the Pi Star one has been reconfigured with a static IP rather than DHCP.

I now have an FT818 as well as the FT817 so I have been rearranging stuff yet again. The FT817 was destined to be used portable but will now be a shack fixture - it has 2m and 70cm which is lacking since I sold the two transverters. The FT818 will be paired with the LDG Z817 autotunes and I will put together some wire and stuff to go portable. Both rigs came with the internal battery packs and together there is now a car charger, two mains chargers (one converted to power pole connectors) and a couple of leads that are of no use now with the power pole adapters being fitted to both rigs. There are lots of ideas floating about on using better battery packs or external batteries which I will have a think about. Given my 'portable' use initially is more likely to be in holiday accommodation there will be mains available. So, having decided the FT817 is to become a fitment I have connected its Signalink to the Linux box along with the one already attached to the FT450D. Wsjt-x has this though out nicely through the ability to have multiple configurations. I'd never want to run two copies of wsjt-x for the two rigs at the same time so this works well. The documentation explains it but basically it's a matter of selecting Configuration and cloning the current one, choosing names for each (I just used the rig names), and then selecting the second Signalink and rig details in the cloned configuration. All seems to work fine, the only thing that initially caught me out is that when one selects a configuration wsjt-x closes and reopens - I thought it had crashed. I only run the radio at 2.5W but I do have a 2m linear to play with at some stage. It always surprises me how far 2.5W and the loft mounted big wheel will get on 2m. This means my current configuration - digital wise anyway - is the FT817 and FT450D are connected to the Linux box via their Signalinks and CAT cables but the FT450D Signalink and CAT control can also be switched across to the Windows PC where I have Vara and VarAC installed. And a mess of wire... Update: clearly I have overcomplicated things. Last night when changing configs wsjt-x could not sort itself out. Rebooting the PC sorted that. But this morning the FT817 was sat flashing its screen and although the FT450D was fine and I could make FT8 contacts all was not well. Unplugging everything from the FT817 and power cycling it cured the flash but then the FT450D had dropped off CAT control as well. For now I've set everything back as before, with the FT817 on the Mac.

I have always dabbled in home automation, pretty much since before it even became a thing. Most of the control was, and mostly still is via X10 devices and controllers which use mains signalling. This is rather old fashioned now and, being mains signalling is susceptible to interference. At one stage the outdoor light, which are controlled via an X10 appliance module in the workshop were very intermittent, until I discovered the wall-wart on one of the internal cameras was injecting awful noise that caused a scanner AM to buzz wildly when held near any mains outlet in the house! Anyway, that isn’t radio related, but this is… enter Zigbee. I have not read very far into this yet but it uses 2.4GHz among other frequencies for its signalling and there are lots of modules available. I plan to change our two dimmers to Zigbee and it will be pretty much plug and play. Apart from removing the mains signalling path the modules communicate both ways, so the controller can see their status as well as control them. Some of the newer X10 modules do this but very few of them and none of the ones I have. The current setup here is a Raspberry Pi running Homebridge which appears in the Apple Home app and can respond to commands via Siri. The X10 lighting controllers are handled via shell scripts which are called by a Homebridge plugin. But with no status return, if the lights are switched on by a switch or, in the case of the garden and outdoor lights via a script which calculates dusk and dawn the Home app has no clue as to their state. With Zigbee it will. There is a little way to go yet but everything appears to work. The Homebridge software has a plugin that communicates with software on the server which in turn works via a Zigbee 2.4GHz USB dongle. Basically, with very little work new devices feed their names all the way back to the Home app. All I need now is some more!