Radio, railways, stuff...

So the Ethernet interface on the shack PC decided not to work at all today. It's managed by the network-manager stuff so no ideas why it had decided to go funny. Actually, it has been off colour for a few weeks now as at boot it does not see the Internet i.e. it fails to find a route but does see locally. Anyway, I've never liked network-manger, I would far rather get control of it all myself. I realise it's there for a reason but I favour a more handraulic approach. After battling it into submission and removing it from the startup scripts editing /etc/networks/interfaces has cured its tantrum. For now anyway! But I am wondering what is up with the PC now as USB failures yesterday and then a collapse of networking today... everything important is backed up so no worries there. However, I am not of the camp that these things fail slowly as I have had PCs running for years and years before. I may well use this as an excuse to get a midi-tower system I can dual boot (Windows and Linux) and get a couple of PCI cards into.

This morning the rig would not go into transmit via wsjt-x. It worked fine last night up to when everything was shut down and there were no changes to anything, hardware or software. Rebooting the PC made no difference. CAT control was working both ways and it was receiving FT8 fine. I noticed that transmitting would sometimes change the rig settings e.g. from data to non-data. I tried the flrig / fldigi combination but transmitting via this messed the FT450D’s settings up in that it was rapidly triggering tx and the rig decided to engage its internal tuner. Plugging the two USB connectors into the front USB sockets on the PC made it work but the transmit levels are mad - ALC is triggering and the rig does not generate any decent power with this turned down. ALC is on a knife-edge where it goes from very little power / no ALC via the SignaLink TX control to 50% ALC and proper power output with nothing in between. Fiddling with the audio settings on the PC and in wsjt-x makes little difference. But changing the Mode to Data/Pkt in Settings -> Radio does improve the ALC business. This was set to None and I cannot remember if this is a change or not. The audio settings via pavucontrol are set to 100% for the USB audio. This was 120% before as otherwise the rig would keep falling out of Tx on 40m. Wsjt-x’s tune function is holding up on 40m at 100% so there is a change there for no apparent reason. All the PC USB ports are USB2.0 so there is no difference there. Trying a few CQs on 17m shows that FT8 is being received across Europe so it is all working. The same is true to 40m. Weird. The only physical differences between it not working at all this morning and now are the two USB cables are plugged into the front sockets and the USB leads are away from the antenna coax. But the latter, i.e. the cable routing has always been along the same path as the coax and it has worked every day without issue.

Been having fun with the Pluto today. It has been working fine, though not used very often with SDR Console on my acquire Windows 10 laptop but today I needed an SSB source to find a fault on the TR-9130 which had gone deaf on SSB. The Pluto made an ideal source and helped me to find out I’d got the gain and RIT controls mixed up and so had turned the gain right down! D’oh. So, after putting the TR back on the shelf it gave me the opportunity to finally fiddle with the Pluto. First off, when transmitting on SDR Console the transmission breaks at a regular short interval. Googling (well, actually these days DuckDuckGo’ing - does that work?) found some info which I tried but to no avail. Someone mentioned that it worked fine in SDR Angel so I downloaded this and after watching YouTube I managed to get a decent output. Not sure what I’ve done wrong with SDR Console but that will wait for now. But I really wanted to use the Pluto on the Linux box. Some time ago I had a go at installing the Gnu Radio software along with the modules that make the Pluto work. Ages back I tried but I could never get it to compile but since then I have upgraded Ubuntu to 18.04. This time it all seemed to go in but the software cannot see the Pluto. There is something obvious that I am missing here. Anyway, I installed SDR Angel on the Linux box via snapd and it loads fine but it cannot see the Pluto. Probably no surprise because Gnu Radio can’t either and I had forgotten of course! As an intermediate step here I have ordered a USB to Ethernet adapter as someone posted information about this and he can access his Pluto that way. That doesn’t mean I will carry on trying to crack why the Pluto is invisible to Gnu Radio and SDR Angel but it will help once I finally get the dish set up for QO100 as the Pluto will be out in the workshop as close to the dish as possible while still under cover, and I will want to drive it over the wires. More on that later as I still need a decent galvanised pole and some concrete and we’re still locked down here. For completeness on the Pluto issues, iio_info -s finds the Pluto fine, and avahi-resolve —name pluto.local tells me it is on 192.168.2.1 as expected. But neither iio_info -n pluto.local or iio_info -n 192.168.2.1 will work, both stating ‘Unable to create IIO context: Connection timed out’. Update: Typical. Reading what I have written got me thinking that this is simply a routing issue. When plugged in the Pluto appears as a USB Ethernet device and fails because it is not on the same subnet. Closing that and running ifconfig by hand I updated the Ethernet device Pluto 'becomes' by giving it the IP address…