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, four days 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!