Echolink

So… having an Allstar node I wanted to configure it for Echolink. It seemed this was just a matter of editing the pre-prepared configuration file echolink.xxx and renaming it to echolink.conf. Edits in place, this I did. Oh yes, and I set our broadband router up to forward the relevant ports to the hub. On restarting asterisk it gave numerous errors of the form ‘Error in parsing header on servers.echolink.org’. Hmmm.

Ok, scratching around the web I found that Echolink has a firewall test service at https://secure.echolink.org/pingTest.jsp. It failed. Ugh.

Then it dawned on me (meaning I read the documentation a little better!). I had set a callsign with ‘-L’ at the end which appeared to be the way to go. But this needed separate validation! Once that was done it all sprang into life.

Simple, and also obvious when I realised. Old age?

http://km6uso.net/index.php/2021/02/27/adding-echolink-to-your-allstar-hub/ is an excellent guide – there are others of course but this one pointed out clearly the need to register the -L or -R callsign.

Portsdown / Langstone progress

Slowly coming together. Yesterday I decided to attack the front panel with a drill and mount the rotary encoder, switches and the little Arduino board which I programmed earlier. This is for tuning the Langstone. For some reason my drill press insists on making triangular holes – if I wanted a triangular hole I’d never manage of course. So I’ve resorted to making a smaller hole and using a round file. Anyway, everything went into place, although the Arduino board has no mounting holes so I’ve tie-wrapped a piece of plastic under it as an insulator and used a decent (hopefully!) sticky pad to secure the board inside the front panel.

So far, so good. Here it is receiving the Allstar microHub…

I need to sort the microphone out. The USB audio dongles seem to be constructed for stereo input so I wired the same to the front panel. Plugging the headset in gives no audio, presumably its all shorting out. I can make it work by ‘adjusting’ the plug (pulling it out until it works!) so I need to re-wire or make a little adapter.

There are a couple of fans in the case and so far it seems to be keeping nice and cool. Next steps include making the GPIO breakout board and possibly the band switching stuff.

Edit: of course I have a mono to stereo adapter plug, I just never looked in the junk box! Mic input now working fine…

Allstar micro-node

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 clearly getting in somewhere that it should not. I have verified the HT is ok by monitoring on a scanner, so no issue there.

Edit 3: Adding a ferrite around the cables between the radio and the CM108 has helped a little in that I can get closer to the node and not get this noise played back in parrot mode. Unfortunately I have put all my small clip-on ferrites in A Safe Place, ever to be seen again, so I can’t add more right now.

I have carried out a tactical withdrawal i.e. the node is sitting under the desk in disgrace. No amount of ferrite’ing, re-routing wires or even running the node from a lab supply makes any difference to this noise. The only thing I can be reasonably sure of is it is some interaction between RF from the HT and the audio chain, so the CM108 I guess. Holding the HT next to the node while monitoring it on a scanner shows no audio issues but playback in parrot mode and it is there every time. Moving away from the node cures it to a great extent but no amount of shielding works. I could (should!) investigate further but I have other projects to take care of plus a bunch of DIY stuff.

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.

Categories

Tags

Recent Posts

Archives

Links