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.
TARPN NinoTNC is waiting no more…
Category: Computing
Yet another project…
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!
Zigbee randomness
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!
Shack networking
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!
A GPS based Raspberry Pi Stratum 1 NTP server
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 systems to use the new NTP server. On the Pi systems this is typically done via /etc/systemd/timesyncd.conf and then restarting systemd-timesyncd; the Mac was done via System settings –> General –> Date & Time, and the various network switches and wi-fi APs each had their own way but each was obvious. Of course one thing to remember is these are all static systems that never leave the house. Setting a local IP into a mobile system would not be that great an idea.
The final thing that tripped me up was that in chronyc options such as clients would give an error. Running chronyc under sudo fixed those.
And there it is in a tall metal Pi case also from Pi Hut and rather unceremoniously chopped with some cutters to enable the SMA connector to fit. This case has plenty of vertical space for the Pi, the PoE HAT and the GPS HAT.
Sources: https://austinsnerdythings.com/2021/04/19/microsecond-accurate-ntp-with-a-raspberry-pi-and-pps-gps/ https://www.jacobdeane.com/iot/2020/building-a-gps-based-time-server/
Pi PoE
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.
FT818
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.
Zigbee
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!
FT817 first fiddle…
I now have a second Signalink USB complete with the Yaesu cable to go with the FT817. This is actually the third one to arrive here, the second was mis-advertised as having the radio cable – it didn’t so it is going back because the price is £20 more than a competitor, a little less than the cost of the radio cable. Serves me right for trying to save a couple of quid!
Anyway, FT817 and Signalink all cabled together and no antenna. Hmmm. Ok let’s try into a dummy load, should be good enough for across the shack with FT8 running on the Linux box. Nothing received.
Ah, it’s a Windows box and 1.5 seconds adrift. Sync the time. No change.
Ok. Set WSJT-X to 2m and use the front antenna which I have. Nope, nothing sent.
It is always a good idea to read the manual before fiddling! Let’s change the display to power. Ah. No power… Hmmm.
Ok, transmit from the Linux box and I can see that on WSJT-X via the FT817. So it receives fine.
Did I mention the manual?
Set radio to DIG. Works fine now! Funny, that.
Microsoft time
You know the thing… installing stuff on Windows where it counts down, and sometimes up again, then gets to 100% and seems to wait for ages. Our washing machine seems to run on Microsoft time too.
Well, so too it seems does our old MacBook. This is a 2015 or so 13″ MacBook Pro and is no longer used so sits on a shelf. I had it set up as me for testing but wanted to clean it all out so it can be sold. That’s where things went a tad wrong.
For some reason it took ages to even log in – very unusual as these generally boot in seconds. Then, after the reset it would not boot at all. Long story cut…
I set it going doing a restore over the Internet. It began saying it would take 2 hours. Ok. This changed to 12 hours and seemed to come down ok, 11, then 10 each taking about an hour. Then it got down to 9 hours and dropped to 12 minutes! After an hour at 12 minutes left it went to 21 minutes and showed the Apple logo. After another hour it apparently had less than a minute to go. After 2 hours of that I gave up and rebooted it. It went straight back to 29 minutes, then 1 and sat there again. Hmmm.
So I downloaded MacOS onto a USB stick and booted the Mac that way. This fired up and said 4 hours (from an attached USB??) but dropped to a few minutes. I left it running but those few minutes became an hour before it finally finished.
It is not a happy Mac…