After our trip to Europe and Japan I really want to do FT8 or other digimodes – my preferred mode because of naff hearing etc – rather than just take handhelds. But the weight of the FT818 + tuner + PSU + a laptop is prohibitive. True, the PSU and tuner would go in the checked bag but I feel that the FT818 would really need to come as carry-on. And anyway I do not own a laptop, plus the fact that we tend to travel light so there is very little room for my stuff anyway.

So it got me thinking. At home I use one PC for Linux, one for Windows 10, the Mac mini, and a Pi. Four systems, four screens, and great flexibility as all the audio is interconnected by a mixer. But the Windows PC is now playing up and is too old for Windows 11, not that I want that but I guess it is inevitable as running Windows without security patches is just about the worst thing I can imagine. Well, ok, my imagination runs a lot deeper than that, but you know what I mean.

The QRP Labs QMX+ looks most interesting, small and portable, and with the QRP Labs heritage ought to be a really useful bit of kit. So it got me thinking, is it time I invested in a small Windows laptop, junk the current Windows box and use the laptop connected to the screen for here plus simply unplug it and go portable? I mean, it’s not like I’ve not done that before and it is a pretty standard model. It’s just that, all my life I’ve used old hardware, secondhand or chucked out, cobbled together to make it do what I want. I’ve never had a new system other than the Mac Mini and its MacBook predecessor, the latter not eve being mine anyway. It is, therefore rather uncharted territory, purchasing a new or new-ish laptop which will not see a great deal of use as I really prefer the Mac. Or do I find an older MacBook and cobble that together? I have an older 11″ model with a dead battery – I changed the battery before but the replacement didn’t last. That was going to be sold but I no longer trust eBay as suitable for someone that sells very little.

So, the choice, should I go this route seems to be a new(-ish) Windows laptop that will take Windows 11, or a cobbled together old MacBook which I already have but could potentially sell to offset the cost of the Windows one.

Either way I will investigate the QMX+ first because the weight of my other HF transceivers is the killer.

We just had a short trip to Europe and then Japan and so I took a couple of handheld radios along. For Europe the CEPT licence was fine but for Japan I arranged a short term one via JARL who were very helpful.

So, licences and HTs in hand, or, rather, in carry-on bag, off we went. I had broken the radios down into battery, radio and antenna and put each in a plastic bag to keep everything clean. Big mistake! My bag was searched at the UK airport and in Schiphol. The bags were causing confusion, especially as, at Schiphol they asked how the battery related to whatever the Mouser code was on the old plastic bag I had used. Very quick though, it only added a couple of minutes each time and they were happy.

So I left the radios intact for the onward trip from Schiphol and into Japan. No issues at all at either end or on the return.

So… note to self, leave the radios intact.

I wanted to get a programmer for the ID51. So, off to RT Systems as I have some of their programmers already. Got the Mac version of the package for the ID51 but it does not allow programming via SD card. That caught me out because their package for the FT2D does and I wrongly assumed this would too.

Of course, it needs a cable! Off to eBay… an allegedly suitable cable arrived today but the RT Systems program will not find it. Typical, it needs one of their enfangled cables that are incompatible with the rest of the world. No way that will arrive in time for our trip.

So… Chirp then. Downloaded the Mac version but it, too will not see the eBay cable. I know the Mac sees it so why won’t the software? RT Systems has no option to select a USB port, Chirp does but offers no help as to what it is.

Try Linux? Hmmm…  I’m really not into fiddling with flatpack or any other enfangled package managers – apt is enough, no apt, no use.

Windows then! Got Chirp, and it can find the cable, and Chirp will see it and will download from the ID51. All good then? Nope!

This exercise was to enable me to program up all the foreign repeaters ready for the trip and also to figure out why our local repeater was in the list incorrectly. So let’s take a step backwards now…

I had tried to update the list of repeaters by downloading from Icom. This method works fine by loading the relevant file onto an SD card and telling the radio to load it. RT Systems take note – why does your FT2D software allow this but the ID51 software does not? This should be standard!

But the resultant list was missing the local repeater. I tried to add it but then the radio tells me there are no repeaters at all. I tried downloading the file from repeaterbook which at least knows about the local repeater. No joy. I tried editing the files already on the radio but each time it somehow messed up. After many attempts and permutations I had to give up which is why I though getting an actual programmer would help.

Enter Chirp (on Windows, yuk…). It downloaded from the radio fine but when I looked at the repeater list it seemed broken – all it had was a list of callsigns and no other information. Ugh! But then I remembered that the radio had whinged that there were no repeaters. So, I loaded a known good repeater list file already omitted the SD card, checked the radio would see repeaters when DR is pressed, and downloaded that from the radio into Chirp. The repeater list is just as broken.

Ok… so I exported everything from Chirp as CSV and opened in LibreOffice. But it does not export the repeater list so I am no further towards understanding how the data works. Time to hit the ‘net. Meanwhile, I checked the current repeater list to see if the ‘Near Repeater’ option was working… nope… 20 minutes in and the radio still has not got a GPS location, just like the FT2D!

Fiddling further with Chirp I found someone had kindly created a list of repeaters that does include our local one. I downloaded this and tried to load it into Chirp but it just says the file format is invalid. I copied it to the SD card and tried to import it into the ID51 – data error. Ok, this has gone far enough, this is not rocket science but it seems that it is made so.

Let’s try Icom’s own software, apparently called cs-51plus2. This is called cloning software and, of course is for Windows. After installing the software it read the ID51 ok. I found the repeater list under ‘Digital’ and, indeed, the local repeater is missing. The big question is, can I add it? Ok, I added the  local repeater to the end of the list of repeaters, adding the frequency and offset, plus coordinates. Coordinates are degrees, minutes and seconds but I had digital so had to convert – not a biggie. Wrote the data back to the radio and rebooted. And… the repeater is there! And it keys! Just had to wait for the radio to find the GPS – I reckon it does this by carrier pigeon – but finally the ‘Near Repeater’ function works and also finds the newly-added local repeater. Now to add the foreign ones…

So what is the takeaway from all of this? I wasted money on RT Systems software by assuming it would work the same as the FT2D software i.e. use the SD card. Never mind. I tried Chirp but that just confused the issue. And the manufacturer’s own software, generally looked down on, worked fine! (Apparently the software comes with the radio, I don’t remember it having a CD and there is no sign of it but I downloaded it from Icom just fine). I must remind myself if I ever get another radio to first try the manufacturer’s software as my needs are generally lightweight, otherwise try Chirp, and last get the RT Systems software after making sure (by which I mean email them as it is very muddled reading the literature) whether it needs their special cable – and, personally, if it does then I won’t buy the software. I mean, come on, I pay for the software and I am forced to buy a lead I’ll probably only use once or twice?

I now have a Raspberry Pi set up on one of the four monitors in the shack. The original layout was two screens at the top on Linux, then bottom left on Windows and bottom right – central to where I sit on the Mac as the main screen. But that layout had two major issues…

I use a program called Barrier to basically act as a KVM switch for the three systems with the Mac as server. That way the Mac mouse and keyboard controls any of the systems, although it can be awkward sometimes where Windows expects keys which Apple doesn’t have. But Barrier does not understand dual monitors and so moving the mouse up from the Mac got to the Linux box fine, but moving it down from the left hand screen would not get to Windows as the program does not see it being physically there. I could live with that, except for issue two…

The main issue was with the Linux screens being at the top and thus making me sit back or crank my neck upwards, not a good position.

So…

I got to realising that although I use both screens on the Linux box for radio stuff this tends to be with wsjt-x on the right screen and pskreporter on the left.

The solution, which somehow never occurred to me, was simple. Move all the wiring about so that the Mac is right and central, Linux is to the left at eye level so no neck ache, Windows is top right because I rarely use it anyway, and that left a dead screen top left. Enter a Pi 4B. So now I can arrange the four screens with pskreporter top right, Hamclock top left, wsjt-x bottom left and logging bottom right. QED.

Another new toy, a Quansheng UK-K5(8). Size-wise it’s taller and heavier than the Baofeng UV5R and has a nicer display. The reason I got this, apart from the price is there is firmware available to enable a spectrum display among other things.

I’ve loaded this version: https://github.com/egzumer/uv-k5-firmware-custom/wiki. Loading was simple enough. There have been mentions that one needs to insert the programming cable very firmly but I found that my aftermarket Baofeng USB cable went in quite easily with a click. Once I had remembered you need to turn the radio on in program mode the firmware went in via the Edge browser in just a few seconds.

Other than that I have yet to use it on air and it has not yet been near a spectrum analyser so no idea how good or bad it is RF wise. There’s plenty of information out there already anyway. For me, like the UV5R it’s a handy little radio that won’t hurt too much if lost or damaged, but it is the available firmware that seals the deal.

I may have the chance to visit Japan for a couple of weeks this year. I was hoping to take a couple of handhelds with me and to apply for a license. The information how to acquire a license as a non-resident foreigner seemed straightforward until I got to the requirement that any radios need a ‘technical standard certification number’ without which each one needs to be certified at a cost of around £30. It took some searching but I eventually found a document about this including the mark applied to equipment.

Neither my Yaesu FT2D or Icom ID-51 carries that mark. The Yaesu came with a printed booklet which discusses various conformances, the Icom has a PDF which says very little on that score. Presumably this is because of the market – I remember reading that some radios which can be wide banded cannot be if they are Japanese spec ones.

Both the handhelds are, of course radios which are made in Japan, and say so, but it seems I cannot bring them to Japan without incurring costs to have them certified. Both carry the CE mark. I am not (yet) convinced that I read everything correctly but that is what seems to be the case.

So, a radio-less holiday then! At least with an upcoming trip to Amsterdam I can just bring any radio and use it under the CEPT agreement. I am determined to use one outside the UK at least once!

After having ditched Meshtastic, for now at least, I had a fiddle with two of the LoRa modules with a view to repurposing them. And there they are. The first is a LoRa APRS r/o iGate, listening on 439.9125MHz, and the second is a receiver for radiosondes listening around 400MHz.

Nestled under a 70cm ground plane in the shack is, of course a good way to ensure nothing is ever received unless it is very close! However, it is destined for greater things… although at the end of the day it’s just me fiddling. The LoRa APRS map is at https://lora.ham-radio-op.net/

The radiosonde one stands a better chance of actually receiving something, especially as it is currently connected to the 70cm big wheel antenna in the loft. See https://sondehub.org/

The plan is to connect these two along with the module running TinyGS to a common antenna currently in the loft. They will be connected using a Crosscountry Wireless multicoupler which is due to arrive in a day or so.

Some time ago I wanted a logging program that would do things my way. Although there is absolutely nothing wrong with any of the various offerings they generally try to be everything for everyone and none of them really sat well with me. So I wrote my own in PHP (learning Python is high on my list of things to do, along with Mandarin, Morse, cooking…) which uses the QRZ.com logbook as the backend. Ok then, really I wrote a series of various scripts in PHP that make it all work. The advantage is it does just what I need and nothing more and can easily be modified to add functionality. The downside is I never was a coder (well, ok, I have a certification in COBOL from the 1970’s!) and it is not going anywhere other than my own server. So you can’t have it…

The way I tend to log stuff is via wsjt-x or other software that logs to a local file. I then have a script that takes the ADIF data and populates QRZ.com on a QSO-by-QSO basis. Somehow having to actually do something after each QSO feels like I am actually engaging in the process. But I am not a contester… it would simply not work for any stress situations (but then I could easily make it work if I so desired…)

With QRZ.com being the master a script then populates a local database which does all manner of stuff that I personally need. For example, it holds records of eQSL sent/received, real QSL sent/received, and various tabular data for Worked All Britain (WAB).

Scripts also modify the wsjt-x log file on all my systems such that each has a record of all QSOs. As QRZ.com is globally accessible (not tried from China mind… not that I plan to take any radio gear there anyway) and my main database is on a VPS so is also globally accessible the various scripts work from anywhere.

I do plan to move the database from the VPS to a system at home once we get FTTP broadband and use the VPS as a backup, synchronising between the two. But that will wait.

One plan which is more immediate is LoTW integration because as yet my LoTW logging is via QRZ.com which means an extra step. No biggie, I mean it’s its a few clicks and a password… but it would be nice to integrate it. The same goes for eQSL sends, but as yet I only send on receipt and I have scripts to deal with that anyway.

I’ve been rationalising hardware, in particular as the PoE HAT on the Pi running the GB7RVB packet mailbox was noticeably noisy and needs replacing. I had originally moved the packet mailbox off of my AMPRnet router Pi as I needed to install a VPN and the networking was becoming a bit too complex for my liking. In the end I had no use for the VPN, so GB7RVB has gone back, removing one Pi.

Linbpq went across just fine – there is an apt for it (https://wiki.oarc.uk/packet:linbpq-apt-installation) so installation is easy. Just install and copy the config across and the files under /opt/oarc/bpq (there are neater ways but this sledgehammer method works). With the node running I could access via the web interface as expected, but then the axudp route disappeared.

Then I realised that our broadband router had a NAT rule for the UDP port needed for axudp and that was still pushing it to the now switched off Pi. And I’m sure I’ve forgotten this same thing before! So now I have a note as a reminder, assuming I bother to check the note…

Now having removed one Pi with a noisy fan the NTP server Pi is also whining. Grumble.

It’s out! OFCOM today published the new licence terms stating that licences are changed from today, see https://www.ofcom.org.uk/__data/assets/pdf_file/0029/278345/amateur-radio-general-notice-decision.pdf

I did respond to the consultation. The two things that I was rather unsure of was the new rule that one cannily hold one personal licence – I still have my foundation and intermediate as well as the full – and the business about RSLs.

On the licences I have not used my foundation or intermediate calls since I got the full licence but I maintained domains named after all three and in some cases my login ID for various forums etc is still my foundation callsign. But no biggie, the domains can expire, I will make sure I do not use any old email addresses and it doesn’t actually matter if my login ID is the old callsign in any given forum provided my email address is correct. But to be tidy I’ll work my way through those. It looks like OFCOM will be revoking one’s ‘lesser’ licences during 2024/25.

RSLs always stuck out with me but as I live in England never affected me. I can see the point where people want to use the RSL, I mean if I lived in Scotland, say, I would definitely use MM. But the change is optional rather than RSLs being outlawed somehow. I have never operated outside England (I don’t seem to travel much!) and often wondered how, say I were driving up the A1 do I change callsign on approach to the Scottish border. But it was always academic because I never use radio while driving anyway.

I do like the bits about data stations and such but it will take some time to properly digest the new rules. I did find to my surprise that my 70cm pi-star setup could be heard from a few miles away given it was connected to a dummy load! One half of my setup – it’s a dual HAT – runs a pager for Dapnet and given a bit more power would be rather handy for the local area.

Also nice is the supervised use by unlicensed people whereas before those people needed to be on a recognised training course (I may have remembered that wrong…) – not that I have the need personally but it can only be helpful to the cause.

I actually spotted this little CB handheld via one of M0XFB’s Tiktok videos. CB is not particularly active round here but even so I felt a handheld bit would still make a good addition to my kit.

It will manage the full 4W output and has both the UK FM, and EU FM / AM ranges. https://www.thunderpole.co.uk/thunderpole-t-x-overview.html explains it better than me. It has the ubiquitous rubber duck type antenna but the antenna connector usefully is a BNC. No idea what the range will be with that antenna but it’s certainly a handy little thing.

I recently acquired a 10Ghz / 144MHz transverter which should get me a little closer to the band. I do still have a kit to build but having this means I can eventually test that as well. It needs a 10MHz reference input and I was recommended one from an eBay seller in China. The unit arrived today and having had it sat on a ‘scope and counter for several hours it does seem to produce a solid 10Mhz signal at a nice sine wave (it has TTL output too). Not bad for £12.

All this packet radio progressing around the place reminds me of a time long ago, pre-Internet where dial-up BBSs became the new thing in town. Back then I had a BBC Micro and a modem that ran at two speeds – I forget which now (will edit later!) and I persuaded my mum to get BT in to fit a socket rather than the hard-wired phone we had then. This let me plug the modem in. I used to use a BBS called ‘More Summer Wine’ plus one other but I forgot the name. Much of the activity back then is lost in the mist of time (or rather I just can’t remember) but sending and receiving mail was fun. BBS systems were all a part of the wider FidoNet. Mail would be routed between the various BBS systems, many of which only had the one telephone line and so would be inaccessible while that was happening. Indeed, they were mostly single user anyway, although if the sysop was there you could message them via the console of the BBS which was probably sitting in someone’s bedroom. I am reminded of the many times I would set the BBC and modem up on the hall floor because we only had the one telephone socket. In fact, it would be quite some time between then and when we finally got broadband Internet which for us was not until the later 1990s in our new home.

During that time and working in academia I had routine access to networks and mail and so interest in the BBS systems dwindled. There was a time before the winder Internet became available where we could gain network access to remote systems, all typically mini- or mainframe computers. One such system ran a MUD – Multi-user Dungeons and Dragons – another angle to remote access but this time for gaming rather than BBS. That provided an introduction to online chatrooms because the MUD we used to play on had that feature. One could not only progress through the game but also exchange messages online, the latter becoming the wanted feature vice the game itself.

And here we are. I was never involved in packet radio when it first came to be, but now it has reminded me a lot of those old days of the dial-up BBS.

And FidoNet? It is still there https://www.fidonet.org/

See: https://spectrum.ieee.org/social-medias-dialup-ancestor-the-bulletin-board-system

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.