Computing ⁽³⁷⁾

I finally got round to putting my Allstarlink node together after looking at it sitting almost completed for a week. Poor thing. Anyway, it's now functioning but I want to add the LEDs. Software-wise it turned out a bit of a faff. I had already signed up and got a node number and set a password etc. My first attempt was via the Raspberry Pi image downloaded from the Allstar wiki. That seemed to go in just fine with a fairly easy setup and well scripted information on the wiki. All seemed ok except for when I wanted to install Allmon... the instructions for which began with the need to install git. That failed and so I did the usual update / upgrade cycle - which I really ought to have done right away as the image is quite old. After that, nothing worked. The USB interface was not working and so there was no radio functions. Power cycling did nothing. So I installed the hamvoip image. One nice thing about the Pi and similar thing is you change SD cards and this changes the o/s and everything. Hamvoip went in fine with a fairly automatic installation and after a couple of loops where I'd missed something it now works fine. It comes with Allmon and Supermon installed. (the Allstar image does not have a web server and so the Allmon installation would have failed anyway even if I had not already given up). Not picking on the Allstar image - had I taken more time I would have set up a Raspbian system and manually installed the Allmon software onto this, as detailed in their wiki. But, having got hamvoip working I will stick with that for now. So... now to go off and figure out exactly why I built this thing anyway!! Edit: Ok, I spoke too soon. Having connected to a test server the audio that comes back, allegedly the same as what I sent, is awful with a tone and buzzing in the background which the audio only just makes it over. Something is wrong... audio from the box is fine with the generated voice announcements perfectly clear, as well as a few calls heard when connected to hubnet receive-only. The HT is fine as I can hear good quality audio via a scanner. Hmmm... Edit 2: I've experimented with every parameter and made no difference. I have increased the mic gain on the HT as it seemed low even with a high setting in the simpleusb setup. But the noise remains. It seems that whenever I transmit anywhere near the node it happens, and simply moving to the other side of the shack cures it to a great extent. Currently the radio is connected to a dummy load but swapping for a small antenna makes no difference. Moving the dummy load well away from the node with an extension coax makes no difference to the noise if transmitting near the node. So the transmission is…

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!

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.

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.

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…