Radio, railways, stuff...

I wanted to get a programmer for the ID51. So, off to RT Systems as I have some of their programmers already. Got the Mac version of the package for the ID51 but it does not allow programming via SD card. That caught me out because their package for the FT2D does and I wrongly assumed this would too. Of course, it needs a cable! Off to eBay… an allegedly suitable cable arrived today but the RT Systems program will not find it. Typical, it needs one of their enfangled cables that are incompatible with the rest of the world. No way that will arrive in time for our trip. So… Chirp then. Downloaded the Mac version but it, too will not see the eBay cable. I know the Mac sees it so why won’t the software? RT Systems has no option to select a USB port, Chirp does but offers no help as to what it is. Try Linux? Hmmm… I’m really not into fiddling with flatpack or any other enfangled package managers - apt is enough, no apt, no use. Windows then! Got Chirp, and it can find the cable, and Chirp will see it and will download from the ID51. All good then? Nope! This exercise was to enable me to program up all the foreign repeaters ready for the trip and also to figure out why our local repeater was in the list incorrectly. So let’s take a step backwards now… I had tried to update the list of repeaters by downloading from Icom. This method works fine by loading the relevant file onto an SD card and telling the radio to load it. RT Systems take note - why does your FT2D software allow this but the ID51 software does not? This should be standard! But the resultant list was missing the local repeater. I tried to add it but then the radio tells me there are no repeaters at all. I tried downloading the file from repeaterbook which at least knows about the local repeater. No joy. I tried editing the files already on the radio but each time it somehow messed up. After many attempts and permutations I had to give up which is why I though getting an actual programmer would help. Enter Chirp (on Windows, yuk…). It downloaded from the radio fine but when I looked at the repeater list it seemed broken - all it had was a list of callsigns and no other information. Ugh! But then I remembered that the radio had whinged that there were no repeaters. So, I loaded a known good repeater list file already omitted the SD card, checked the radio would see repeaters when DR is pressed, and downloaded that from the radio into Chirp. The repeater list is just as broken. Ok… so I exported everything from Chirp as CSV and opened in LibreOffice. But it does not export the repeater list so I am no further towards understanding how the data…

"Zilog has called time on the Z80 CPU." (https://www.theregister.com/2024/04/29/opinion_z80/) Wow. Actually I had no idea (through never having checked) that it was still being produced. And a fine chip it was too. I never built a system from wires up using the Z80 though. My first system, designed, built from chips and wire-wrap was an 8080 system, hand programmed to control al x-ray diffractometer. This was decades ago now but I still remember it, although I have no photos unfortunately. The system had a timer chip for a 1-second count and was interface to a Nuclear Engineering (I think it was!) counter that used nixies. But I did at least use Z80s, just they came as boards. The first was a Transom Triton computer and by then I was programming in Turbo pascal - back then this was really neat as one could have procedures full of assembler code which made interfacing easy. Later I used Gemini boards and that also gave the ability to have a graphics card. By then my interfacing to the diffractometer included a stepper motor and shaft encoder to control the arc motor. In the end there were two sets of Gemini Z80 boards, one for the x-ray diffractometer and one for an optical microdensitometer. Both gathered data and were interfaced to a mainframe computer for the processing using a suite of Algol 60 programs. Good old days... Personally my first system was a 6502 Newbear single board, followed by the ubiquitous Nascom 1 which was, of course, Z80 based. Farewell, Z80...

I now have a Raspberry Pi set up on one of the four monitors in the shack. The original layout was two screens at the top on Linux, then bottom left on Windows and bottom right - central to where I sit on the Mac as the main screen. But that layout had two major issues... I use a program called Barrier to basically act as a KVM switch for the three systems with the Mac as server. That way the Mac mouse and keyboard controls any of the systems, although it can be awkward sometimes where Windows expects keys which Apple doesn't have. But Barrier does not understand dual monitors and so moving the mouse up from the Mac got to the Linux box fine, but moving it down from the left hand screen would not get to Windows as the program does not see it being physically there. I could live with that, except for issue two... The main issue was with the Linux screens being at the top and thus making me sit back or crank my neck upwards, not a good position. So... I got to realising that although I use both screens on the Linux box for radio stuff this tends to be with wsjt-x on the right screen and pskreporter on the left. The solution, which somehow never occurred to me, was simple. Move all the wiring about so that the Mac is right and central, Linux is to the left at eye level so no neck ache, Windows is top right because I rarely use it anyway, and that left a dead screen top left. Enter a Pi 4B. So now I can arrange the four screens with pskreporter top right, Hamclock top left, wsjt-x bottom left and logging bottom right. QED.