Made some useful progress on packet radio today. I managed to access a node in Scotland and one near the south coast on 40m, 300 baud. This was using QtSoundModem on the Linux box connected to the FT450D via a Signalink, fed into the random length wire in the loft. Access was via EasyTerm running on the Windows PC at first, but then I managed to compile QtTermTCP so ran that on the Linux box instead. A bit of fun but it proves the possibility of using 40m to interconnect where there is currently no VHF or UHF paths here.
Fingers crossed once I get some wire and metal in the air things will only improve.
So… that time of year again! Where did the last 63 go… Currently all my antennas are in the loft and this is something I have wanted to address for far too long. So 2024 is going to see some actual metal outdoors.
First on the list is the collinear for GB7RVB. The plan there is to use a TK bracket and put it up on a mast so it is just above the roofline. The issue I will have here is our house is silhouetted against the backdrop of far away hills and I just know there will be complaints. But as we do not have an external TV antenna there are many oversized examples around where people have clearly been done over by unscrupulous installers. We can see Emley Moor mast to the south plus at least two repeaters and our 6 element or so TV antenna in the loft provides perfectly good signal strengths so why the large ‘digital’ antennas? Anyway, they cannot really whinge at me for a collinear given all that metalwork along the rooflines. That’s my defence anyway! Depending on complaints, or hopefully the lack thereof it will probably get a coup, of feet higher as time goes on…
Next the QO100 dish needs to move to the house wall. The current location is about 5 foot off the ground and unsuitable for the new radiation rules. Siting it on the house wall avoids this and means I can up the power to DATV levels.
And for HF… my initial plan is for a random wire the length of the garden, from the house wall to the trees at the top. I have the wire and rope and assorted clamps etc.
I hope I don’t need to revisit this page in 2025 and still have work to do!
I’ve been doing the ’12 days of QRZ’ again this year and managed to get the award yesterday – I started two day late as I forgot about the award. So far I had endorsements for 80m, 40m, 30m and 20m, and today I added 17m and 10m.
A couple of log entries were the same stations over two or three days, I’m not actually stalking you!
It’s fun and frustrating at the same time, logging, sending to QRZ and LoTW and hoping for a match. A few 60m QSOs from yesterday were from stations that had previously logged to LoTW and now are not… but never mind. Just one more day for 60m and 15m to get 12 days in each and the associated endorsements. The award updates automatically once you get sufficient days and go to the awards page again,
Now then, 12m. I did not realise last year, nor this year that it is included, as are all bands. You need to go to the bottom of the awards check page and click on ‘all bands’. So this year I added 3 days (so far) of 12m, 9 to go. I’ve never heard anything on 160m, the wire is so short for that band it is no surprise. I always miss the openings on 6m, and 2m yields very little, so I will probably leave those alone.
Update 24/12/23 – just competed the necessary QSOs for 12m, so I have 80, 60, 40, 30, 20, 17, 15, 12 and 10m. That’s it for this year!
Well. Further to my previous post where all hope seemed to have gone out of the window I finally made progress today, but not the way I set out to.
First off, I pulled a Raspberry Pi 4 from another project and sat the CaribouLite HAT on it.
Next was a fresh installation of DragonOS. But this time it did open the ssh port – I’ve no idea why it did not before and note I am being unscientific here as I changed the Pi, but I am not going backwards.
Then, time for install.sh…
All seemed to go well but the software failed to compile completely. Searching on the errors I added #include <memory> to two source files, cariboulite/software/libcariboulite/src/CaribouLiteCpp.cpp and cariboulite/software/libcariboulite/src/CaribouLite.hpp. Stripping out all the ‘apt’s and ‘depmod’ from install.sh and running it again and the software compilation completed! I had already added and commented out the necessary lines in /boot/firmware/config.txt so a reboot was all that was needed to kick it into life. The driver was loaded – lsmod|smi showed this and also /proc/device-tree/hat now exists, both precursors to success according to the notes and YouTube videos.
Running sudo SoapySDRUtils –find showed the card, and, finally (!), running SoapySDRServer –bind and CubicSDR on the Mac mini finds the server on the Pi and I can tune to the local radio station.
Success, but that was a struggle. Mind you, I learned stuff at least!
I came across this via a post someone made somewhere – actually it might have been an email on a group. Anyway, with a tx/rx range top to 6GHz I thought, why not? It arrived quite quickly from Crowd Supply via Mouser with Crowd Supply charging the VAT but no other taxes on arrival.
I duly mounted it on a spare Raspberry Pi 3B with a fresh Bookworm 64 bit OS and followed the installation instructions at https://github.com/cariboulabs/cariboulite but I always got various errors and never got to a working system. The errors were mainly surrounding the SMI driver and the kernel headers. There seemed no way round this one, and thus no working system.
Following on from another complaint I downloaded and installed DragonOS, a 64 bit variant with lots of SDR utilities built in. Once installed, although the developer stated that ssh is available from first boot and does not need the usual empty ssh file it is not – the system does not open port 22 but does open the vnc port so I then had to find out which of my desktop systems has a vnc viewer as I never use it. When I found one and connected all it gave me was a blank screen. But guess what? Adding an empty ssh file onto the SD card worked, despite the advice!
Following the guidance from one user regarding getting the cariboulite to even install I did a complete upgrade / dist-upgrade cycle and then began the installation process. This time there were no errors about SMI or the kernel headers but there were fatal errors in the general build and no working system at the end.
After countless iterations, reading comments from other users, watching YouTube videos etc. I had to admit defeat and give up.
So there we are. On one hand it serves me right for not finding and reading all the issues before ordering this thing, but on the other given it costs money I rightly expect more, i.e. something that actually works rather than something that will sit in a box until maybe, one day the developer sorts the mess out. As it is I would compare it to the excellent SDRConnect and RSP SDR products which just work – this is the exact opposite!
In a nutshell, don’t bother with this card. But then, you never know, maybe the developer will sort the software and I will re-visit this post in a more positive light.
Update: there is a fork of the software detailed at https://github.com/cariboulabs/cariboulite/discussions/82 but following those instructions in a fresh Bookworm throws up the same kernel header errors and results in no SMI driver. So no go there. I tried the same in a fresh DragonOS – I must have been mistaken about the ned for the ssh file because I added this but DragonOS never opens the ssh port for me. So, no go there either!
All in all this has been a lesson in how to waste many hours for no gain. YMMV. There are a few other web pages with differing views and builds which I may try but as a product this is really, really poorly supported by the developer.
My second NinoTNC is built. The parts came today from Mouser in a huge box. I need to adjust the case a little to make it fit nicely but now I have this one I can go mobile and see how access to GB7RVB is. So far, no-one has connected (and yes, the antenna is still in the loft!)
I did find a TNC program for the Mac called KISSet which works fine once I remembered to put my callsign in! I wondered why it was sending data and GB7RVB’s TNC was receiving – no callsign. Twit. It worked fine after that.
Here is the setup for GB7RVB, not much to see really. The radio is a Tait TM8110 which has been configured according to information on the OARC wiki. The NinoTNC is next to it, both currently sitting on top of my Portsdown. Above, and annoyingly not square because I need to move some cables, is the Pi 4 which is PoE powered from a Netgear switch.
I now have a NoV for GB7RVB, a packet mailbox on 144.950MHz. It is currently set for AFSK AX25 at 1200 baud, though may move to more modern IL2P 4800 baud after trials.
It is located here in IO93eu and I would be interested in reports if anyone manages to connect to it. The only service currently enabled is local chat. Early days… it’s a bit of a backwater here with no packet and hardly any APRS activity. Maybe this will start it as there are moves elsewhere to build up a national packet network. If one or two other nodes pop up between here and the emerging networks we could make links.
If you do not have a hardware TNC it is possible to use software, for example I have successfully used QtSoundModem to drive a Signalink and my FT817, and QtTermTCP to connect via AGW to the modem, with the FT817 set to 144.950 and packet mode.
GB7RVB is currently based on the LinBPQ package and runs on a Raspberry Pi 3B, with a NinoTNC (see my earlier post about having built that). It is currently driving an FTM100 set for 5W but will be using a Tait TM8110 once the data lead arrives in a few days.
At this stage I must state that I overlooked the fact I have an FTM100 and it has a suitable interface! Ok, no way I am going to fiddle soldering a 10-pin mini-DIN plug even if I had one, so I ordered a CT167 cable from www.JGTech.com which arrived within two days. I already had a stock of D9 plugs. With the NinoTNC connected to the Windows PC the APRSIS32 software could send and receive APRS to/from my FT2D (no APRS activity round here other than a receive-only igate).
But packet was a tad more problematic. I wanted to use the Windows PC + Signalink + FT817 setup which means using QtSoundModem on the PC, but I also needed a program to talk to the TNC. QtTermTCP will via KISS but neither the Mac or Linux version had KISS anywhere to be seen, only AGW. And any mix of QtSoundModem and QtTermTCP on the Windows PC generally resulted in nothing talking to anything, which is probably my fault but it definitely got in the way.
So… I set up an old Pi 3B with the LinBPQ software, connected the NinoTNC / FMT100 to that and set up a test configuration. I then ran up QtSoundModem on the Windows PC talking to the FT817, and QtTermTCP on the Mac talking to the Windows QtSoundModem via AGW. And… nothing! The node sent broadcasts which were picked up by QtSoundModem etc. but connects to it all failed.
I noticed that if I sent APRS from the FT2D the OK LED on the TNC would light, but if I sent anything via QtSoundModem only the DCD flashed, no OK. Data issues then. It was then that I realised that in my earlier fiddling about with QtSoundModem I had all the various options in weird modes. Turning off FX25 and IL2P in the modem setting cured it (and no, I have no idea why I had them switched on!), and I could then connect. Success.
So, packet radio across the shack, using two radios, three computers and a NinoTNC.
Next steps… in theory anyway… I have a Tait TM8110 on order via eBay and a cable on order, I already have the programming lead and software. If all goes to plan I may even be able to build a packet node and get a NoV for it. As there is nothing at all round here then this may be a start if I can get others interested. I am to far away from other nodes in the progressive national packet network, but, early days…
See, I built it! And it works. The 3D printed case needs a bit of tidying but is perfectly functional. All I need now is a radio to use it with plus probably re-use one of my spare Pi 3B cards to drive it.
