PC progress

For a while now I’ve been pondering whether to get a Windows PC. For starters, SDR Console needs it as do other SDR packages. But other than watching them come and go on eBay I never took the plunge. However, as I’ve taken all the electronics out of the workshop due to it always being damp I had a spare Lenovo ThinkCentre PC, one of the very small things. I already use one as the home server but this other one was destined to run a DCC setup for a model railway that is still just a pile of bits.

It ran Ubuntu but when I got it it came with Windows 10. All I had done was swap hard disks, keeping the Windows one just in case I ever needed it. Well…

…it is now in the shack and SDR Console has been installed and all is well. We had a screen lying around which is full HD, a much better display option than the old laptop I had been using. And with it being a fresh Windows 10 it’s not (yet!) cluttered up.

One strange thing though. I set up SDR Console just as I had on the laptop along with the recommended offsets etc. But on the laptop I had to adjust the offsets to set it correct, e.g. for the lower beacon to actually appear where it should. But now, with the published offsets it is in the right place with no further adjustment. Another oddity is that when I boot this PC and run SDR Console up having shut it down with the SDR receiving the lower beacon, it comes right back. On the laptop it was always somewhat off and would drift. Not sure how that happens given it’s all in the digital domain. I must have set something up odd on the laptop, but no idea what. Anyway, it works.

The Lenovo only has the one set of audio jacks, those on the front. And only 4 USBs, two at the back in use for the mouse and keyboard. In order to get audio into the mixer I will need to use a USB sound card, not an issue except that will need to plug in the front and I like to keep cables out of the way. Maybe it’s time for another wireless keyboard and mouse, after all the current keyboard does rather dwarf the tiny PC!

Pibox progress

After a long delay (other work, life getting in the way, general laziness etc) I ran some more tests on the Pibox. With the fans disconnected (actually, one disconnected itself!) and the case assembled I’ve been running the box to see how bad the temperatures get. With two of the three Pi cards operating, and all 3 powered up, pi-star, which is on top due to the DVMEGA hat settles at 60 degrees C, and the utility Pi which has a Discone attached settles at 50. So not actually bad. I think what I will do is go back to Plan C or whatever it was and run the fans via a transistor hanging off the GPIO port of one of the cards so the fan comes on if it is getting a bit steamy. For now, at least it means I can run pi-star 24/7 again, especially as I had to upgrade it by hand as it has missed a lot of the overnight updates.

And it saves me having to run mains power into the loft.

PiBox progress…

The PiBox is almost completed. It’s taken far too long due to all sorts of silly things like having to get fans because a dry run indicated the poor little boards were getting a bit hot, having to get bolts for the fans because I had none long enough, and having to get a connector for the 1-wire (actually 3 wires!) lead from the central heating sensors.

So, there is is. Two fans on the left, 5V PSU bottom right, gigabit Ethernet switch above that, then the Pi’s: top is the PiStar with the DVMega board which has coax to the rear panel and then a dummy load, middle is the ASD-B and central heating monitor Pi, and the bottom is a general purpose one with various bits on such as rtl_tcp. The lower two boards have USB-A sockets on the rear of the case for the two SDR sticks, one for the ADS-B antenna and one to attach to a Discone for general use.

But there is an issue. I had originally intended this to sit in the shack but those fans are just too annoying. Not loud, but constant. I suspect the box will end up in the loft. Or maybe a re-think. I may fiddle with running the fans from one (or two) of the Pi’s and set up some temperature control to turn them on and off. It may even be that I am rather too ‘sensitive’ to the temperature range as others seem happy running their boards a lot hotter than I do mine.

Raspberry Pi and SDRs

I had an idea that my RSP2 SDR could sit in the loft driven by a Pi in the shack. The Pi in question had DireWolf and a DVB-T stick watching APRS traffic. Ideal, I though. Hmmm.

I really thought this would be easy and a web search suggested that it should all work, my plan being to use the Pi to serve the SDR remotely from one of the laptops. 

My first attempt was to install a fresh Raspberry Pi OS and install SoapySDR and SoapySDRPlay. However, various bits of SoapySDR failed to compile due to some things not being found, even though I followed the instructions to the letter. A web search found only two identical but unanswered questions, so no help there.

More searches. SDRPlay have a useful looking image for the Pi where it will run in a number of modes, including soapy remote. This seemed just what I wanted. It all went in and the Pi throws open port 1234 which web searches indicated as the right thing for it to do.

However, SDRPlay refuses to play whatever I try. I have again followed what instructions I can find regarding remote operation, some of which point to the SoapySDR package so I downloaded those onto the Windows laptop. Again, no go. Trying a different mode results in – nothing.

There was also a claim that SDR Console will see a remote SDRPlay but it won’t for me and given my setup works really well for the Pluto / QO100 transceiver I have no intention fiddling with that further.

CubicSDR made promises as it at least mentioned Soapy Remote but will not find the Pi. Stuffing bits in by hand results in nothing.

Trying different modes in the SDRPlay Pi image yielded nothing further.

There seems no way to progress, so I have, for now at least given up and gone back to using the good old DVB-T dongle which at least has a simple plugin that works for data bits like APRS via DireWolf. At least it works.

Now, I’ve been fiddling about with software all my career and I would / should be able to figure this out. But thinking as a beginner all it would lead to is frustration. If this kind of facility is viable then more thought needs to go into documentation, simple step-by-step guides with problem solutions, and simple one-click installations rather than sending the user chasing around the globe finding bits that end up not working. Yes, I know the software is all provided as-is and someone has spent a lot of effort in building each bit for free. And yes, if I make the time to figure it out I will produce such a guide,  but don’t hold your breath as many other projects are calling for attention.

There is light at the end of the tunnel though (and it’s not just someone with a torch bringing more work!) – using the guide at https://www.2m0sql.com/2012/10/10/remote-sdr-using-raspberry-pi-rtl_tcp/ and SDR# on the Windows laptop at least the DVB-T dongle is working fine. Something to build on pending me sorting the SDRPlay out.

Of course, the nice thing about the Pi is it is so easy to copy a new image if you make a mess, and keep several SD cards with various ‘experiments’ on them.

(l)ubuntu…

I have an old netbook, a Samsung NF110 that is hopelessly underpowered now with only 1Gb RAM and a 1.66GHz Atom CPU. It used to run Windows 7 (can you imagine?!) and was ok for basic word processing when I got the thing and had a really good battery life. I installed Ubuntu on this a while ago and found it very slow. I recently put Ubuntu 18.04 on, simply because I use this on the desktop. Yesterday I wanted to see if it could provide another screen and run pskreporter and it sat there for 10 minutes allegedly loading Firefox. Hmmm. I remembered at that point that I had planned to put it on eBay anyway but wondered why on earth it was just so slow with Linux.

Enter Lubuntu. Lubuntu 12.10 has given the poor little thing a new lease on life. It is actually usable and no Gnome awkwardness. I’d still rather it had a little more RAM (like, I dunno, 8 times as much!) but it always was a handy little PC so it can remain in the shack now.

And on Lubuntu – well sort of – I installed LXDE on the shack PC as Gnome continues to annoy. So far, so good, and of course it’s easy to switch between desktop environments.

More PC blues

I finally decided to rebuild the shack PC given that just about everything was going daft. I suspect this is a result of various software installs while testing new stuff that were not fully deinstalled. Yeah I know I should test in a VM…

Anyway, a complete fresh install of Ubuntu 18.04 with it formatting the disk has got the PC back to normality. Almost. Networking works again with the inbuild (un)helpful config rather than me setting it up by hand each boot via a script. And I remembered to sort Gnome out so I can get the classic view rather than the daft dock setup.

But there are two oddities… first off, the rather annoying way the screen layout changes (un)helpfully (!) when you touch the to left corner with the mouse. This can be disabled but when done so the Applications menu – the leftmost top bar menu – is no longer accessible. No amount of permutations of the toggles via gnome-tweaks will sort that.

But more annoying I have lost almost all decode highlights in wsjt-x. The only ones that work are CQ, tx and my call, nothing else. I’ve tried every combination. It’s not wsjt-x (I installed a previous version just to check, same result) and I am rather stuck with that now. It will be something obvious but I just can’t see it… hmmm.

Even more PC woes

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.

Random PC woes

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.

Dead Pi

Well that’s a first for me. A dead Pi, or rather a dead SD card. I have a RPi 2 in the loft connected to a DVB-T dongle and ADSB antenna which sends data to FlightRadar 24. It’s been up there doing its thing for ages, but last night I received an email from FR24 that it had stopped sending data. As it turns out that was a very useful email because everything else was running fine.

It also logs temperatures from three 1Wire temperature sensors on the central heating pipes. As these are underneath the location of the Pi in the loft it was easier to run a wire down for the 1Wire sensors than cobble together another Pi and find a home for it away from the heat of the water cylinder and pipework. That logging and my network monitor indicated that all was apparently well and I had not noticed the FR24 status data indicated that the ADSB feed was down.

The Pi is fed via a PoE supply as I didn’t want a wall-wart and mains socket up there and it makes it easier to reboot. I logged into the Pi fine ad rebooted it from the command line to see if that cured the ADSB issue in case it had simply lost the USB-connected dongle. But it never came fully back and would not even open the ssh port. It did respond to ping. Power cycling made no difference and by this time it was midnight.

This morning I made a new SD card and got it all back working (actually better as the card is the latest o/s now and the FR24 feed also has the MLAT option built in). So, some interesting and annoying observations:

The Raspberry Pi website now has a download package for the Mac which makes creating a new SD card image a doddle. Simply download and run it, stuff a blank SD card in and choose the options and wait.

Don’t use the HDMI monitor, mouse and keyboard off your desktop PC when trying to get a Pi to work if you need to use said desktop PC at the same time! Yeah…

No matter how good your backups, if you cannot remember the name of an important file the backups are useless by themselves. D’oh.

But most importantly remember that you can mount a Pi SD card on a Linux box (and no doubt other systems) and access the files if the card still mostly works like mine did. Fortunately there were only two things on this Pi, the 1Wire code which is a five-line bash script and the FR24 package which basically installs itself from their download site. QED.

Ferrites

Those lumps you see on PC monitor cables and other PC and related cables… yes we know what they are and what they do but here’s proof.

I got a DisplayPort to HDMI cable for a new monitor. It works fine via VGA but why not? Anyway, aside from why on earth the PC has a DisplayPort and not an HDMI, the cable duly arrived. It’s a nice cable in that it has a braided cover, feels well made and the connectors fit well and do not drop out. But no ferrites.

All worked fine with both monitors – one DVI and one HDMI connected – came on fine. But when I key up the FT450D (set to 30W) the HDMI-connected screen goes blank. Completely blank. Black. It comes right back when I de-key. Ugh, no ferrites.

I fitted a decent clip-on to each end with a whole turn of lead in each – no problems since. See? They do work!

Categories

Tags

Recent Posts

Archives

Links