Meshcore Legal Battle

Whilst Meshcore is hardly the place for intelligent exchanges of messages, being rather like CB radio of old in content, it is a treasure-trove of scandal in recent months.

The reason? A team split, where one of the members of team Meshcore filed his own trademark application, allegedly without notifying the team itself. 

The split, down to Andy Kirby, has caused a lot of ill-feeling and, on Meshcore itself, anger and not a little abuse. Kirby issued a YouTube video defence of his actions, but though there are many words, it achieves nothing by way of explanation.

The Meshcore team have opted to challenge the trademark filing, which will of course be expensive - for them as well as Kirby, should he defend the challenge. 

From time to time, a link is sent as a message on Meshcore, inviting people to visit and donate to the legal costs. This takes you to a blog post, explaining why they don't simply change the name to something else and have decided to follow the legal route - and how much that will likely cost. 

As you can see, they had initial cost of $15,000, with further costs then identified of $18,000; a total of $33,000. 

It seems that, within just 12 days, Meshcore supporters had already donated $41,283 at the time of writing this post (15th July). 

Fundraiser total as of 15:55UTC, July 5, 2026.

 

Whilst there is no suggestion or claim of wrongdoing, with over $8000 in excess of what was being sought already, I think a fair question would be: how is that excess to be managed and spent? It's not at all clear that this is explained in the blog or elsewhere. The blog post text only seems to contemplate a situation where there is not enough money raised, or they decide the challenge isn't viable (one might hope this had been assessed prior to the fundraiser, but there are, admittedly, plenty of unknowns as one progresses down a legal route). $41,283, at the time of writing, seems a very large amount of money for 'bug bounties', should the claim not proceed.

Perhaps the team have received donations way in excess of what they expected to achieve. And they do mention supporting the overall project from funds raised, not only 'bug bounties'. But it all seems a bit nebulous to me, and some greater clarity - as well as an update to the blog, which still claims only $1800 has been raised - would seem necessary, especially as trust is at the heart of all this shenanigans.

 

Random Connections of the Meshcore World

I've never claimed to be an electronics person and, though I always try to pick things up as I go along, I'm still, and always will be, a learner.

That, however, doesn't mean I can't ask questions that get to the heart of the matter. And this is what I've been up to this week. And it seems a lot of people don't have the answers, seemingly because they've been connecting things up without much thought as to maximum voltages and potential longer-term damage to their Mesh boards.

First, let's remember that there are two main types of Meshcore (or Meshtastic, if you prefer that) board: Heltek, now at v4, and the more expensive but often preferred RAK boards. With both Heltek and RAK boards now being optimised for low current draw, one can conclude there is little to choose between them. The only board I've had software, rather than hardware issues, is in fact the RAK board (a database locked error, requiring a re-flashing).

The solar charging of these two boards are not the same. The Heltek v4 has integrated MPPT charging, whereas the RAK boards do not.

Many folk use the external MPPT charging board shown below. It costs around £10 and, in my case, is rated for 12V solar panels, with 5V output. 

MPPT charge regulator. Fine for RAK boards, no good for Heltek.

My real-world test of this board shows it is entirely successful with the RAK boards. You connect any solar panel, of any rating between 6 and 24V, to the 'SOLAR IN' socket. The output goes to the input of the RAK board. Your battery connects to the remaining board socket. Battery charging begins when the MPPT regulator sees about 3.7V. It will only ever provide around 4.2V in full sunshine, which is exactly what we need. The RAK board has a 'never exceed' input limit of 5.5V. 

My test so far this spring shows that the battery is charged up to around 80-81% and only discharges by around 1% overnight. In winter, the charge and discharge will of course suffer more, but we'll cross that bridge once winter arrives; we have summer to enjoy first!

When it comes to the Heltek V4, MPPT is already on-board and you can't therefore connect an external regulator in series, because the battery will see little or even no charging. The trouble with the Heltek is that you need to provide the correct input voltage (not more than around 6V), without going through an MPPT regulator first. That's usually achieved with a simple (and very small) buck converter. As far as my tests show, this seems to be successful, though I haven't tested it for more than a few days. 

One alternative for Heltek is to use the much more complex Waveshare regulator. This is a bit more expensive, physically larger and uses around 16mA continuously, simply by virtue of being connected up. Whether that is too much current draw depends on where you are and how active your board might be.

Waveshare solar power manager module. Nice item, though the screw connectors are never my favourite, and it consumes 16mA at all times when connected, which may or may not be an issue, depending on your location and board activity levels.

 

Another option is to buy a 6V-rated panel which has a buck converter and USB connector glued to the back. This works very well for me on a field-deployed Heltek V3 (not V4, though it should be fine for that, too). The only issue is that these boards tend to be of the flexible type, which can be a problem in field deployments, where a solid surround is usually needed. Also, the USB connection needs either to be modified to a permanent, wired solution, or else protected with sealant of some form, so that the whole thing doesn't rust to bits in the outside environment (which will happen quickly otherwise).

Be aware that directly connecting a supposedly 6V panel, especially of the 'CCTV', smaller types that are widely sold, can result in failure of your boards, regardless of type, because they will often exceed 7V output. Those types of panel, whilst fine in very sunny locations with little cloudy weather, are absolutely useless otherwise. Even on a bright day with cirrus obscuring the sun a little, the output falls to very low levels.

  

 

  

LoRa Coax Losses.

Recently, I installed a test solar repeater at a remote location. This was entirely to assess the reliability of such a system and whether anything might need improving in time.

My test solar repeater, with its short RG174 coax (now changed).

 

As a test, I simply used a 1m length of RG174 coax as part of a pre-made connector to hook up the McGill Microwave Systems 4.5dBi colinear vertical to the Heltek V4 board.

On showing a picture for interest on Facebook, the inevitable 'oh, you shouldn't do that!' comments began to roll in. 

First, I 'shouldn't put an antenna in somebody else's field at random, without permission'.

Er, I've been given a personal easement to use this field and structures 35 years ago.

Then, I shouldn't use 'that very thin wire for a long run; it will defeat the gain of the antenna'.

Er, the cable is 1m long. 

The pole the antenna is fixed to is simply to hold it clear of a roof and little else. Great height isn't feasible and neither is a larger antenna at this very exposed, remote location. The antenna-coax combination was an entirely reasonable system, given what I had available and that it was a short run and that a 1/4 wave antenna using the same RG174 cable assembly had already been shown in earlier tests to give perfectly adequate performance from the same location.

Another factor, significant for me, was that thin coax needs only a narrow hole to be cut through brick walls - in my case, by hand drilling. Wider cable needs a larger hole - very difficult to drill by hand, especially above head height, and otherwise excessive and unsightly for some on a house wall. 

All the same, the question as to whether RG174, which is widely used, almost as standard for LoRa applications, is really so lossy as to require replacement in most cases.

Undoubtedly, RG174 has extremely high losses at or around 868MHz; Farnell's datasheet gives 105dB per 100 metres, or 1.05dB per metre. So any runs much greater than my own 1m length would, indeed, present losses that most people would deem unacceptable, except perhaps where a directional antenna was in use. Even then, a run of more than 2m would really need better coax.

LMR400 coax.

 

The usual alternative is LMR400. In ham circles, we've been pre-conditioned to expect high prices for long runs at HF or VHF, made worse by US-centric discussions online, which usually have very much longer runs to antennas than those in the UK.

In fact, a pre-assembled LMR400 coax of (standard) 3m length for LoRa comes in at just  £19, delivered (mainland UK). This is the kind of length many would choose for an antenna situated on a house wall to be fed from indoors, for example.

RG174, thin coax.

 

The benefit of LMR400 is the low loss: at 868MHz, it's around 12.8dB per 100 metres, or 0.128dB per metre. With a 3m length, the loss is 0.38dB, or already 0.66dB less than just 1m of RG174.

So, is the use of LMR400 and its relatively high price, worth using?  For runs of 2m or less, for most people, no. Beyond that kind of run, LMR400, or even the cheaper and slightly higher loss (~0.193dB/m) X-400, rapidly leaves RG174 in the dust, keeping losses within tolerable limits until one reaches around 15-20m runs or so. Above this length, a better antenna and/or even more expensive, lower loss coax will come into consideration.

 

 

SDRConnect: The Linux Installation

There's a lot of chatter at the moment about how Windows 11 is forcing everyone towards a 'forever rent' model i.e. paying every month for cloud-based computing that you previously ran locally. It's being called 'the end of personal computing' by some.

Whether through use of Raspberry Pi SBCs or more concerted efforts in replacing a computer's OS, most amateur radio operators will have something answering to the Linux label in their shacks.

And so it has long been with me. But I'm no Linux expert - at all. I do enjoy the more interactive aspects of delving into the terminal and actually entering real commands from time to time. But it can also be a bit difficult and frustrating to get to grips with.

I'd tried to install SDRConnect on Linux Mint a few months ago, but I hadn't really gone to much effort to overcome the hurdles I met. Last night, I wiped my 12 year-old HP laptop clear of Windows and Zorin OS, installing only Ubuntu. What follows, though, also applies to Linux, which I tested this morning.

Most of what you need to know is actually on the SDRPlay website, but isn't really that obvious a place to hit during a stressed visit, trying to figure-out how to get the damned software running! It's on a PowerPoint-type page:

The commands are: cd Desktop (or cd Downloads, depending on where you have the downloaded SDRConnect .run file) Note that the directory names are case-sensitive.

Type ls to list the files in the relevant directory. Somewhere, you will see the SDRConnect file with a '.run' at the end. You can highlight and copy this filename to the clipboard to paste it when it comes to the commands.

Now type chmod 755 SDRConnect.[whatever the rest of the filename].run You can paste the filename from the clipboard.

Now type ./SDRConnect[rest of filename].run  Note there is no space between the ./ and the filename.

The user agreement and installation now goes ahead. But if you are missing some files, it will tell you to run the installation of SDRConnect again after downloading and installing the missing ones; it's usually very simple and just one file.  Just go back to the ./SDRConnect[etc] instruction, above, when the missing files are sorted.

You should now find SDRConnect installed and an icon and/or listing for the software.

Easy! Works for Ubuntu, Raspberry Pi OS and Linux Mint so far.

 

 

 

 

 

868MHz DX

It was a very bright, sunny day today, though icy cold when the sun went behind a cloud, up on the few high spots on Anglesey - Mynydd Parys. This is 139m above sea level, with a clear line of sight across the Irish Sea to Cumbria, the Isle of Man and the Mourne Mountains in Northern Ireland. It's a great place for radio, and where I lived for 13 years.

Beaming northern Cumbria...

I had a bit of a stroll up there and took my 8-element AliExpress Yagi along with a GPS-enabled Meshcore transceiver. A convenient concrete block to stop people driving over the historic copper mine tailings heaps provided a useful level surface on which to rest the antenna. 

Cumbria, seen early morning from Mynydd Parys, with background lighting revealing the landscape clearly.

 

Aiming it by eye at northern Cumbria, I was quite surprised to make a direct, 'zero hop' connection with a repeater on Lank Rigg at 137.6km distance. Given this is UHF and the power output only around 0.15W - admittedly boosted by the Yagi's ~10dBi gain to an effective 1.5W, that's pretty good going!  As you can see from the screengrab of the app, below, the direct 'ping' signal there was -13dB and -6.25dB back to me (the rest of the information on-screen is redundant for the ping test). I don't know what the antenna arrangements are in Cumbria.

 

Irish Sea area, showing me (north coast Anglesey, purple dot) and the MCC Lank Rigg repeater that heard me.

 

Cornwall, Some Years On.

Back in 2015 - still not that long ago to my mind - the RSGB waded into what became a political farce, about which I was reminded this morning on reading The Guardian, and its piece on widening celebration of Cornish identity in the region. 

The issue all those years ago? The regional secondary locator (RSL) that OFCOM had decided to grant, on a permanent basis, to Cornwall (Kernow in Cornish, hence the 'K').

Source of hostility by the RSGB in 2015...

This came about as a result, in 2014, of the Cornish being granted National Minority Status, recognised by the UK Government, under the European Framework Convention for the Protection of National Minorities. This brought them into line with the Scots, Welsh and Irish, who had enjoyed such recognition from a much earlier point.

Of course, the bigwigs at the RSGB had other ideas. They issued public announcements of support, whilst rabidly opposing it from the very outset, as soon as they thought they were behind closed doors in meetings with OFCOM.

OFCOM itself added, inevitably, to the mess. It formally involved Cornish MPs by telling them all about the new, permanent 'K for Cornwall' callsign, only to withdraw the whole thing, making it a mere temporary issue, ultimately negotiated to last a year.

The reason for the change of heart at OFCOM?  It was never explicitly said, but minutes obtained under FoIA at the time revealed pressure from the RSGB, to which OFCOM seemed unreasonably willing to bow. 

The RSGB raised the entirely specious spectre with OFCOM that, if Cornwall got its own, permanent RSL, then the country - Lord help us all - could be faced with "wide repercussions" - angry mobs from all over the UK, shaking their pointy antenna sticks at the government and threatening regime change and perhaps the collapse of global civilisation itself. The RSGB, desperately, added that operators across the world would be "confused" by the K RSL. Radio operators are not known for being confused by callsigns and geography.

The Guardian article today contains a beautiful line that anyone who is from one of the National Minorities will strongly identify with and understand: "I'm Cornish. I'm definitely not English". To the English ear, this sounds like a declaration of war; that having a minority identity means you are saying you hate the English. Which is, of course (usually), utter bilge.

Why did the RSGB react in this way, advancing ridiculous and clearly disingenuous arguments to overturn what OFCOM - a government agency - had already decided?  Seasoned critics opined, perhaps not unreasonably, that it was concern from within the ranks of the obsessive contesters, including from the within the ranks of the (non-Cornish) Board, that led them to believe they would be at some disadvantage in their pointless point-gathering of a weekend. Think about it: a hobby society, unaccountable to anyone, somehow forcing UK official policy to be changed, making a fool of OFCOM and its decision.

To the wider world, it was a non-story. To the Cornish and those in the UK who are not English, it was another typical English dirty trick, reminding us all of how petty, oppressive and loathsome they can be. Rather than celebrate Celtic cultures - here way, way before England and English ever existed - the English-centric RSGB and its black-suit-(but no black Board members)-and-tie ways decided to have a tantrum and break everything. They were clearly very satisfied with it all.

The Guardian today, celebrating growing Cornish pride, simply reminds us how disgracefully out-of-step with UK cultural history the RSGB was and, no doubt, still is. A word commonly used to describe such prejudiced responses to issues like the RSGB exhibited towards Cornwall is: 'gammon'.

If you're really bored, you can trawl through my blog to find the several posts I wrote at the time. If you're only mildly interested, you can just read my letter to the then Managing Director, or this summary from a bit earlier. Whilst it's a while ago now, it does tell you a lot about our so-called representative body, the Board of which today still contains some of those around at the time.

 

Meschore Continues

It's been a busy few weeks, including getting to grips with Meshcore and its various elements.

Luckily, there's a repeater within line-of-sight - just - of me and this helps develop the interest. Slowly, more repeaters are appearing across Anglesey and, come summer, this may well pick up significantly.

Attention in the past couple of weeks has turned to antennas. At home, a window-placed test 8.5dBi collinear from Paradar has proved to work perfectly well, although it doesn't really offer any advantage in what can be heard in practice over what the stock stubby antenna was delivering. Not really planning to stay at this property much longer, I've resisted putting this antenna outside and stuck it in the loft instead. It does OK there.

With one unit tied up in the loft, I decided to buy a Heltec V3 with GPS and a 3-D printed case, so that I could shove it in a rucksack and take up the mountains - or just a hill overlooking the Irish Sea on Anglesey. The weather being so wet, though, I haven't managed to get out to do this!

Instead, I've been testing the handheld unit out on my daily walk around the local reservoir, which is surrounded by a relatively narrow strip of conifer trees, which of course have pretty dense branches and needles - very effective in blocking microwaves!

 

The only place I could get a signal from the handheld's stubby antenna to my home was from an old railway embankment across a lake that has a relatively clear line-of-sight path (orange and turquoise positions, both at ~2km). From any position on the dam (pink and white positions), which has a path through 250m of conifers and also lies behind a low hill on which they grow, I couldn't get a signal back home with the stubby. 

Line-of-sight (terrain) map for the dam. LoS is only in the clear areas, free of dark lines (the upper end of the lake isn't correct, because it fails to properly take into account the effect of the trees).

 

I felt I could do better than this, despite the very low power involved (22dBm, or 160mW). 

So I built a simple 1/4 wave vertical with four sloping radials, based on a N-type panel mount socket with a SMA connector on the other side. I simply soldered the radiator into the centre of the N-type and attached the radials to the panel mount holes. With a bit of trimming, I got a nice matching curve with about 1.25:1 SWR. It's probably best to grind the thread mounting down to the level of the centre pin socket, or slightly below it, to avoid the lowest few mm of the radiator being somewhat inside a grounded surround of metal. I fixed the whole thing to a timber stick using a 15mm PVC pipe clip, into which the N-type screw thread mount fits snugly.

The Heltec v3 attached to its stick-mounted vertical.

 

So, looking more of a nerd than ever, off I went for a walk with the handheld, but now connected to the new vertical antenna. I was only going to send one test 'advert' signal from the most challenging position - the nearest point on the dam, at 1.8km exactly and through all those trees and a low hill. Would it get through?

Satisfyingly, it very much did! It's no surprise to anyone who has used stock stubby antennas that they are very poor and something to be discarded as soon as possible. And so it is at 868MHz. 

Success! Signal heard back home from the dam.

 

Of course, a PVC tube collinear is more convenient and robust to carry around that a spidery vertical for mountain hiking, for example. But it's also not an impossible antenna to carry in your hand or sticking up from the backback.

Very satisfying experiment, costing no more than the price of a N-type-to-SMA panel mount connector.

Incidentally, at the moment, you can save yourself well over £20 if you buy the same ~6dBi collinear from McGill Microwave Systems rather than the popular Paradar outlet. 

 

 

 

Meshcore: overcoming the issues

Yes, I'm still alive!

I recently started experimenting with Meshtastic - this lasted less than a day - and straight thereafter onto the much better Meshcore 868MHz network.

Though I live in what is to many a 'remote' area, with not that many active radio people about, I was surprised to find two repeaters on Anglesey and a couple of client nodes over on the mainland. 

Having kicked-off using just the standard stub antenna, I decided to spend the £68 for a Paradar 8.5dBi antenna (1m-long collinear). This is nicely made, though I'm not entirely persuaded by the sealant on the end caps, which remains unset on receipt. A quick spin with the self-amalgamating tape is therefore advisable. The mild steel bracket supplied is also poor; it will rust to bits in no time, especially in a salty sea air environment like mine. You can currently save yourself about £10 on Paradar's direct-to-consumer site if you buy via E-bay; you get the self-same antenna and DHL delivery (from Germany).

The Heltec V3 was easy to flash and configure as a client, and the Meshcore app connected to it, straight away. It's important to remember that flashing requires you to use Microsoft Edge browser.

I didn't have quite the same easy experience with the V4, which I ordered via E-bay from China (which, as always, arrived in just a few days - quicker than most UK sellers can manage!)

The problem I had was largely one of ignorance. Firstly, the V4 I have needs its 'User' button (the top one) pressed on powering-up in order to put it into flashing mode. Once I understood that, flashing via the Meshcore online site was simple enough. 

Where I had a day of scratching my head was: why couldn't I connect to the flashed V4 immediately after this process, which used the exact-same serial (USB-C) connection, in order to configure it?

Turns out that it's a matter of rather clunky sequencing: you put the unit into flashing mode with the 'User' button, do the flashing, disconnect the V4, then reconnect it in the normal sense, such that it powers-up, goes through its 'Please wait' thing and then displays the repeater settings for a while. When the screen went blank, I clicked on 'Configure via USB' on the flasher site (I left the flashing page open and didn't touch it until the Heltec's screen was clear). I then got the configuration screen and I was able to sort everything out.

I used the following settings (you can find out what everyone in your particular area is using from the Meshcore nodes map). You can also just choose 'UK/Narrow' from the app and it will auto-fill the settings for you:

Frequency: 869.618MHz
Bandwidth: 62.5kHz
Coding rate: 8
Spreading factor: 8

This immediately worked and was immediately seen by my client in the other room. I've yet to figure out GPS integration on the V4 board, but that's just a matter of developing enough patience some other day!

Incidentally, using the Paradar antenna at the window, on 30/01/2026, I received a repeater in Greystones, south of Dublin, at 115km! No tropo, no line-of-sight. This was either an aircraft reflection or someone who had come across to Wales on the ferry, setting off a ping or two on Anglesey, having not changed their repeater settings. I will have to try and communicate with the owner to find out!

I later discovered why my repeater wasn't sending periodic flood notifications; I hadn't logged-in to it via the phone app, using the password I'd set. This is very confusing, because if you log in with no password, it lets you do so, but has very few options (because you'd be a guest logger-inner in this case).

When I did log in with the password, I saw I was now logged-in as an admin and all the settings were now available. I still have no idea how to enable the GPS so that's still a wrestle for another day!

NOTE: If you switch off your Meshcore repeater and it has no battery attached, your settings will remain in place on powering-up again, but the repeater's clock won't. So you will need to re-sync the clock from the phone app. 

 

 

 

 

 

 

 

Radioberry: PA3GSB Explains.

Recently, I wrote about M0AWS' concerns, (note: any posts or sites mentioned here may later be edited and may not reflect the original versions when I began this piece), highlighting data collection by PA3GSB from various Radioberry units as they become active.

Because this story has developed over the past few days, I've removed my original post to ensure the story is up-to-date and less messy than several posts on the same topic. I had tried to contact PA3GSB using his QRZ.com email address, but that simply bounced back; I could at the time find no other way to contact him.

Later, I was provided with a new email address. This, I'm told, appears when one uses the PA3GSB Radioberry software - which of course I didn't have (nor did my own Radioberry come with that operator's software).

So I was finally able to ask some questions, to which Johan, PA3GSB, quickly provided some detailed answers. I don't think, however, the answers amount to a reasonable justification for how the data was handled, and I'll try to explain why. 

Firstly, here's an extract from what M0AWS said on 10th December, 2024 about what he had discovered (the post has been linked to above, if you want the extract in full context):

Extract from M0AWS' post on the issue, accessed 22-24/10/2025, asserting the data collection was "spyware".

 

Firstly, Johan is clearly an enthusiastic developer. The data collection was obviously not malicious and neither I nor M0AWS have ever suggested it was. M0AWS did both assert it was "spyware" and that it (collectively, without any distinction), was a "breach of UK/European Data Protection Law [sic]".

It seemed to me, at first glance, that PA3GWS was someone who thought future projects of his would benefit from knowing details of the network of Radioberry units, but that the data had not been handled in a sensitive way, being published online. This included the MAC address and, if the user had entered those details, callsign and locator. Those are clearly inter-relatable identifiers that amount to a potential security risk to the user. 

This was what appeared in public (I've redacted callsigns and locators) up until I made contact with PA3GSB about these issues on 24/10/2025; I've redacted the few callsign and locator details:

 

 

PA3GSB, who takes issue with the claim this data collection was described by M0AWS as "spyware" and had not been previously contacted about it by anyone (M0AWS later claimed he had tried to contact him, something not mentioned in his December 2024 post), says that his software, on initial use, gives the user the option to enter or to decline to enter their callsign and locator. It's clear from his website that this is true and that few chose to enter their details. But some have. Entering those details might appear to some to be a normal part of ham operating and they might think it is necessary, for example, for their details to appear on some reporting map or other. I would do so, for example, to use it with WSPR.

Johan does not, however, deny that the MAC address reporting and publishing was a choice the user could NOT make. All the user could potentially see was a wiki page notice (if anyone saw it) that, if their Radioberry was connected to the internet, it would be "registered".

There is a link to the site where the data is published and so a reasonably curious person could see what would be published if they proceeded - but be unable to prevent/stop the MAC address being collected and published. Another issue was that, if the details had been published in the past, it remained published, no matter how long ago that was. If they didn't want this, some might conclude they were lumbered with a unit they'd paid maybe £150 or more for and now couldn't use 'out of the box' in a plug-and-play manner, which many do want (though other software without this data collection are readily available and now often supplied by Chinese sellers).

The notice that PA3GSB software use online will result in "registration", with a link to the page where MAC address and other details were published without restriction.

 

PA3GSB accepts in his response that collecting and publishing MAC addresses was "bad" and that he was to remove it. And, indeed, the MAC address was removed immediately, as this screengrab from this morning shows:

PA3GSB's site, accessed 08:05UTC, 24/10/2025. The MAC address column has now been removed. It's unclear whether Johan is still privately collecting the MAC details and, if so, how securely that data is being held. 

 

Johan could readily justify that collecting such data has a lawful basis; there is no prohibition on data collection under GDPR per se. But there was always a need to ask whether collection was necessary, justified and within the users' reasonable expectations. I don't think Johan can reasonably claim he did so in the way he ultimately went about it, and his immediate removal of the MAC details upon my contact supports this view. Initially cordial exchanges became increasingly chilly as Johan considered my post and emails further.

Johan could collect and use that data without difficulty in law by simply ensuring it was processed in a (private) way that didn't compromise users' personal data/IT security. Whether he was/is storing that data in a way that meets GDPR requirements in terms of overall security (pseudo- or full anonymisation. encryption, etc) isn't known. But he should ensure now that he is fully compliant with all elements of GDPR. Data security, in the age of 24/7 attacks by Russia, China and a plethora of criminal gangs, is no trivial matter that can be left to the choices of mere ham enthusiasts. That is why we have laws.

Where I would, to an extent, agree with Johan is that, if someone wants to question or criticise someone else in writing, the conventional way to go about it is to first ask the person subject to the reportage for his response. Perhaps M0ASW, like me, found Johan's email address on QRZ bounced and then didn't try some other route to establish contact, though according to Johan, his correct email address appears within his software (I don't have a copy, so can't check, but I take it at face value). I had to make contact with another operator in PA-land to get his address. M0AWS later claimed he did try to contact the developer, without success (he specifically says he didn't hear back, suggesting no further effort), but didn't mention this in his December 2024 post.

Overall, M0AWS, whilst perhaps not quite giving the full picture, did highlight an important aspect of this software and that some users, at least, would (and did) end-up entering their callsign and locator details and only later realising this would be matched-up in public against their MAC address. If it had, they couldn't quickly stop what had already appeared remaining online, indefinitely. 

[Update: since I wrote that last sentence, PA3GSB has changed the site, with a bold highlight that shows it only keeps the last week's data. He also asked me to "rewrite" my blog. Personally, I think people should own the mistakes they make, and I made none. Remember, until yesterday and my contact with PA3GSB, none of his site appears to have changed since M0AWS first highlighted it - on December 10, 2024 - as publishing MAC and other data. *After* the contact, the MAC address has gone and the period of data publication is reduced to a short period; why would that mean I have to "rewrite" anything, and why did Johan change so many things as a result of my contact? Why accept the MAC data gathering and publication was "bad", only later to take umbrage at all this being highlighted?]

The newly-changed PA3GSB site (accessed 16:10, 24/2025), now featuring no MAC address and a very limited publication period. Compare that with how it appeared yesterday (second image in this post).

 

What PA3GSB has not now done is to make his data gathering page private. He offers no reason during now several exchanges as to why any of this is appearing in public. The data has, at least at the moment, no apparent practical use to anyone other than him. That said, the data that does now appear (*after* my contact), is limited to what the users choose to enter. That was always their choice and it may not necessarily have been a "breach of UK/European data law", as M0AWS asserts, for those two elements to then be published. Whether it was a breach for the MAC address to be collected and published is moot.

I think PA3GSB is a good person, genuinely offering something positive to the ham community. But he has, unfortunately, put himself in an indefensible position by quite seriously overlooking his GDPR duties. That he takes no money for much or anything of what now happens with Radioberry and is essentially a private individual is no defence, because any data collection has to be done in a lawful manner. 

If anyone wants to delete some or all of the data collected by PA3GSB, then you have Article 17 rights to request he do so. In practice, there would be no reasonable basis for him to refuse, especially given the narrative of how the data came to be collected and published in the first place. With an increasingly irritated tone from PA3GSB and a terse demand I rewrite this post, I've highlighted to PA3GSB that he has been lucky not to have been reported to the Dutch data regulator. At that point, I asked him to cease emailing me, which he has.

Also don't forget there are other software options. The one supplied with my Radioberry, and one that works very well, is developed by John Melton, G0ORX, who confirms that neither his nor the version by DL1YCF gather or publish any such data.

I've just asked M0AWS for his response to Johan's explanation. Surprisingly, he appears to back-pedal on his claims to some degree, saying now that people install code without knowing what it does (this seemingly pushing the onus on avoiding "spyware" code onto the user) and that anyway, the source code is open and can be edited to remove any objectionable actions. M0AWS later wrote to say I have "misrepresented" his email and wasn't back-pedalling at all - a stance I entirely reject; a request for the precise words constituting the claimed 'misrepresenation' has [by now weeks later] gone without reply. Make of it what you will. But not everyone will know how to modify code, or want to. If they pay £150 for a SDR, there's a reasonable expectation from the user its software will comply with the rules, including GDPR.

And whilst M0AWS did of course write about his own modified code and offered it to the world at large, he didn't originally take the line that this was all a fuss about nothing much and could be overcome with some code-editing by any-old user. Quite the opposite: it was to him, at the time, "spyware", a "breach of UK/European Data Protection Law [sic]" and that "finding spyware in open source software is really poor and something most open source developers would never consider doing". If those words don't suggest the issue was a problem, rather than a wonderful, positive development, I don't know of any that could.

M0AWS also says, in private emails and deploying bold text to do so, that "it's important not to blow things out of proportion". Well, it was he who wrote a section about what he, and nobody else, called "spyware", wrongly suggesting that none of the data gathering can be opted out of; in fact, only the MAC address - only one of three possible data elements - was ever non-optional, "bad" though that itself was.

If anyone is in any doubt as to whether the word "spyware" is a good or a bad thing, here's respected and long-established antivirus company, Norton's definition, matching what anybody would reasonably conclude it means, noting that this was a word deployed by M0AWS and never by me:

"Spyware is malicious software that secretly monitors your activity and collects sensitive information, like passwords, location data, or browsing habits, without your consent."

The key fact is that it was not secret and two-thirds of the relevant data was always entirely up to the user to enter, or not. The fact the data was published in public was clear for all to see (and mentioned in the Wiki page), so anyone could have looked at it and decided whether to proceed with anything to do with the Radioberry. Yes, the MAC address publication was something that shouldn't have been done, but it wasn't "spyware" in the way ordinarily defined and understood. 

The take-home for M0AWS is that, if you write to criticise others, you shouldn't be surprised and take to objecting when someone else reads what you wrote and highlights what's objectively not right about it.

 

 

 

Radioberry (Update)

Last week, I wrote this post that reflected concerns first identified and written-up by M0AWS.

By now, my own Radioberry kit has arrived direct from China (my particular e-bay seller was t-mall2013, costing a not-insignificant £150) and, whilst some cold, windy and wet weather blows by, I assembled the few parts to make a functioning SDR.

 

First signals with my Radioberry (the antenna was not matched to the band, so the signals are weaker than they should be)

 

The assembly is very easy and anything like which way up the screen's ribbon cable goes is quickly cleared-up with an internet search. The ribbon cable is, of course, way too long and rather gets in the way of the antenna connection, especially if you use a SMA to SO239 adapter, as many inevitably will.

I was pleased to find that the SD card, should you use one, can - just - be installed and removed on the Pi board once everything has been mounted, though you'll need some fine forceps to manage it. A cheap, low-capacity SSD is probably a better long-term option, especially if you are going to mount the unit in a housing, as many do.

The whole thing was pretty painless and powering-up led to instant and successful operation of the SDR, the software already being installed alongside the Pi OS. The screen is small at just five inches, but presents a fair bit of information in a very clear way. You could easily install some other form of screen, of course. What's not so good is that the screen sizing used to implement the SDR interface is such that, if you then go and try to do something ordinary on the Pi, you'll find you can't see most of the screen and can't do much as a result. 

 

The blue tabs on the screen ribbon cable go this way around (screen at bottom).

 

Another seemingly good news story with this unit was that the SDR software supplied is that developed by G0ORX. I contacted him to find out if he knew of the data scraping by PA3GWS - which he didn't - and whether his software, if it was some modification of the former's efforts, might do the same. I'm glad to report that the response was that it does NOT send any data.

I also got a response from a Dutch operator whose name and locator appeared earlier this year on the PA3GWS site. He knew of the problem and was actively following the story. He had an email address for PA3GWS and so I'll try to see if he can fix this problem, which really shouldn't ever have been implemented, especially when there's no opt-out available.

UPDATE: I've now received a detailed response from PA3GWS and I'll write about this later this week. Also the Radioberry works really well. I'm controlling it via VNC and sound via bluetooth to a receiver on my hi-fi amplifier. Very impressed!

 

 

 

RSGB: Gender-Washing

A Mastodon bot account that gathers information about amateur radio published an interesting link to a RSGB page this morning.

I don't get much information about the RSGB these days, as I've long ceased being a member; this rather gives the lie to the constant claims made by the RSGB that they are 'out there', in the media, advocating for the hobby. Only two RSGB-related news results come up in a search online - one dating to 5 years ago, the other 12 years.

Anyhow, the link proved to be to a New Scientist-style, Q&A interview with an accomplished female engineer. This is good to see, because I've been pointing out for years how the RSGB has a truly monumental problem with gender balance in its representation of the hobby. Here's objective, numerical evidence for that claim. And here's more.

I later discovered, thanks to a social media message, that this was all in response to a call put out by the RSGB; the person who sent me the link commented on its wording:

"I actually thought their call for women to feature in the article was quite patronising so I decided NOT to answer. What I didn't like is a recurring theme. They assume that if you are a woman you won't be interested in the hobby just for fun. It must have been because it helps your career or something."

The RSGB's call.

 

In any case, as a result of all this, I had hoped that the RSGB board might now include the person featuring in the article (where neither the RSGB nor the hobby seems to have played any role in getting her into her career), or at least a shift towards a more gender-balanced composition. 

How did that exercise in a simple internet search (10am, 23/06/2025) go? Well, er... 

That's right, the 100% male (and white and, with one exception, pretty old) upper-echelon of the RSGB. The message isn't getting through to the right people...
 

ARRL: GB Boo-Boo

Leading on from sudden and never-before seen problems I recently had with ARRL's LoTW system, limited information has now come to hand that lets us see what is going on.

Now, just for clarity, I couldn't care two-hoots for DX awards and all that rubbish. It's sort-of nice to have a record of QSOs, especially of SSB QSOs, where the engagement may well have been memorable and enjoyable. For digital QSOs? Well, I mean, they are just conveyor-belt material, with only the very rarest being of any real human meaning (I count my spectacular 50W/3-ele 144MHz QSO with Cabo Verde in this latter category!)

So, what's happened?

My overarching callsign for LoTW is MW1CFN. 'W' signifies Wales, of course. I have a few certificates for other forms of my call, plus a couple for occasional, ongoing Marconi Carnarvon station commemorations. The following screengrab shows all this:

T-QSL, when I fired it up the other day to upload some GB1MUU QSOs, told me the certificate for that call expired in 54 days' time; did I want to submit a renewal request?  Why, yes, of course. When I began that process, I was confronted with this:

Here was the first sign of trouble: GB1MUU is listed in the greyed-out (unmodifiable) DXCC entity box as 'England'. Ticking 'Show All Entities' does not, in fact, pull up any alternative UK-based entities. It should show 'Wales', reflecting the entity I applied and obtained the certificate for in the first place. The ARRL have now confirmed that's what their records show, too:

Now, GBx callsigns are issued as temporary special event calls that may be used from anywhere within the UK (this has to be specified to a high location accuracy at the time of application). There no longer being a requirement or even a recommendation to include a regional secondary locator in any callsign, there has anyway never been a requirement to add one to a GBx call. 

You might say that 'GB' suggests those at OFCOM perceive of it as a central, all-UK type callsign and that the ARRL might be broadly right to decide it's an 'England' call. But that doesn't hold, because both GB and the UK have constituent countries, the only difference being that the concept of GB doesn't include Northern Ireland whilst the term 'UK' does. 

Which constituent country of the UK the GBx call is actually transmitted from is up to the operator to choose at the time of application, as appropriate; there is no automatic way for this to be determined. The call can be used only at one designated location and certainly can't be used in another constituent country of the UK to that it was applied for. In any event, OFCOM would not be so politically naive and contentious to try and force an operator like me, in Wales, to accept it's an 'England' callsign. This would be to reopen some very sore wounds indeed in the relationship between the coloniser and the colonised.

In my case I had, within the past three or so years, been able to select - and did select - Wales as my operating 'entity' within T-QSL/LoTw; this much is unarguably evident from the existing certificate. 

For completeness, persisting with the renewal process for GB1MUU resulted in:

So it can only be concluded that the ARRL has coded its system to decide that, whenever it sees a GBx callsign, it automatically deems it to be an England and England-only callsign. Other UK countries do not, according to the ARRL, now exist so far as GBx calls are concerned. 

Except, this is entirely at odds with the ARRL's DXCC list, which does include Wales as a DXCC entity. The ARRL, rather disgracefully, expect folk to cough-up $5.95 for the DXCC list rather than simply sticking it up online, so I have to rely on a third-party list by PA0ABM (dated 2022) to prove this - plus the fact my recently-renewed MW1CFN certificate is for 'Wales':

 

My guess is that someone at the ARRL - perhaps a new member of staff for example - at the ARRL has mistakenly interpreted GBx calls as applicable to England alone and changed the system accordingly. Whilst these things happen, they shouldn't be permitted to hold sway within the LoTW, once the errors are highlighted.

I was rather dreading having to look up the ARRL rules, their definition of DXCC entity and how that compares with the legal or conventional definition of a 'country'. But because Wales is firmly on the DXCC list, this descent into a black hole of definitions can be avoided and Wales (or any other relevant UK country) should not have been replaced with England when updating this and any other GBx callsign. 

This move by ARRL also, in an entirely unfair, retrospective manner, prevents me uploading GB1MUU QSOs because the 'Wales' I properly selected and was accepted by LoTW for the certificate in the past doesn't match the 'England' that they have now decided it should be.

I had two issues to raise with LoTW about my account, the second of which was this wrong assertion about GBx calls. This was either missed or entirely ignored in the response I received last night. I also sent a separate e-mail to the ARRL about this error. Days later, I received a response, asking for screenshots to help them resolve the matter. Having sent them a link to this post, a couple weeks later, I've heard nothing. 

In the same response, the ARRL also rather suggested I had simply entered the wrong DXCC, despite their records and mine showing this is definitively not the case; it's the ARRL that has done something to force an 'England only' determination. I don't think the ARRL guy had paid much attention to the problem.

In the first week of July, I received the rather unhelpful and perhaps evasive response that all was OK at the ARRL side. I was shown a screengrab to demonstrate this. Except, the callsign that had been selected was a different one - GB1QTM - a call I'd registered just a month earlier. It didn't address GB1MUU and how the certificate was being rejected as not England, despite having Wales in its ARRL-granted certificate! 

Update: things get worse!  Three emails later, now I'm patronised by an obtuse American telling me how GB callsigns work (thanks!) and that, er, I need to apply for an England certificate. Sorry? What? Pardon?  No, dumbass ARRL: I have a Welsh certificate GB callsign that the ARRL approved but now refuses to accept upon upload or certificate renewal. It's an ARRL problem, not a 'me' problem. 

 

ARRL email, July 09, 2025.

In any case, none of this matters to me personally, as I simply turned heel, abandoning the whole LoTW anachronism for the much nicer, simpler ClubLog. That, and the fact I don't exactly warm to Trumpland and its phenomenally obtuse ARRL deciding how the world outside America should work.

 

 

LoTW: Adiós!

I'm not your typical ham. That much I'll grant you.

I'm not motivated by radio contests and I have no interest in gathering 'DXCC' awards.

Of course, if they are on offer and awards of various kinds are granted by the way then, sure, I'll take them for all they're worth (i.e nothing beyond street-cred value).

Physical QSLing is something I used to enjoy on a fairly regular basis in the early days. Then it fell back to only returning what I was sent, or some especially 'exotic' DX. 

For the most part, the QSL cards were to interest my then young kids in the wider world. Operators, from a Swedish airline pilot to a Scottish man living on Cooke Island, were kind enough to send us cards and, quite often, little gifts. 

But postal rates increased quite a lot in the post-financial meltdown period. Money was anyway tight. Digital modes took hold such that you could have a list of 200 or more QSOs every day. QSLing them all - or even any - became increasingly burdensome and, ultimately, entirely impractical.

Logging QSOs was something I did in A4 page-to-a-day diaries. I loved doing that, especially when there was plenty of SSB going on. 

Eventually, I did start using e-QSL, QRZ.com's logbook feature and then LoTW. Over time, I opted only to use LoTW, it being the most recognisable logging scheme then on offer.

In fairness, LoTW has worked well for me over the years. It's rarely given any trouble, though the whole way it works through the T-QSL interface is now very outdated and irksome. In the past year, there was a big outage owing to a hack that the ARRL were reluctant to inform anyone about, at least until everyone had figured-out what had gone on for themselves.

This week, I went to upload about a month's worth of QSOs, which is pretty much the norm for me. T-QSL was having none of it. 

I apparently have no such overarching callsign as MW1CFN - funny, given it's worked for a decade or so thus far. No, the certificate hasn't expired, though on a second attempt at upload, it then advised me it expired in 2 days' time. Funny again, because I hadn't received any reminders as is usual with expiring calls.

GB1MUU's certificate is for DXCC 'Wales'. Yet, T-QSL has started deciding it's listed as 'England', even though a large number of QSOs over a couple of years have never generated this problem before. Even if it's a simple solution, I'm done with this LoTW rubbish.

 

Then it decided that my QSO's were being uploaded with the 'England' DXCC, even though the certificate within T-QSL itself shows 'Wales' - as it has done from the outset; why would any Welsh operator want to be associated with England, after all?

Whilst there is a LoTW help facility, the replies are often rudely terse and sound like a grumpy old man has been woken up to deal with something he'd rather not.

 

That's a lot better!

I decided this was the time to look elsewhere. I have previously registered with Club Log, but not used it much. I can't even remember why I registered! 

In any case, back to Club Log I came and the upload is as easy as pie. No two-key nuclear codes type verification, certificates and standalone uploaders and such like as with LoTW. Just upload the ADIF and it's all done. Plenty of data tools to keep the obsessives happy, too!