SDR Top 10 Has Fallen: Meet something new....

 

At the HOPE 16 conference back in August 2025, my presentation focused on the most popular projects based on key search terms such as "SDR", "Software Defined Radio", "Amateur Radio" and "Ham Radio".   

My theory was to look at how many stars were voted on by the GitHub community per project and compare against how long the project has been around in order to create a velocity score, simply by dividing stars by number of days old the project is.  While Git is just one narrow dimensional lens to observe through, it is still a good one since its a great way to capture crowd sourced ranking data.

The idea was that the faster a project could generate the most stars would mean that it captured more interest or maintained that over time and thus, would be very important to pay attention to these projects. So while not perfect, this is the best way to capture interest level from a community of people who generally all have overlapping interests.

Here are the slides, charts and data to back up the presentation if you missed it. I analyzed the top 10 most popular for each search term for a total of 40 projects overall. Below is an example of one of my "velocity" charts enabled by the star history site which can be used for exactly what I needed.

I really wanted to wait a full year before seeing if there were major changes to the top projects, so here is a short update to start May 2026 off since too many exciting things are happening. I will compare again just before HOPE 26 at the New Yorker Hotel now less than 90 days away.

Changes:  SDR

First up, lets look at the "SDR" top 10 from last year and how they compare to now. I bolded out four worth talking about below.

Last year, GQRX which is one of the longest maintained "SDR" projects was the 9th most starred project followed by SDRangel as 10th most popular. Less than a year later, GQRX has dropped to 13th most popular and SDRangel is now 11th most popular. 

In March, SDRangel released version 7.24.0 which now includes Meshtastic functionality,  which is clear evolution from the earlier Chirp Chat function designed to support LoRa based messaging.  This is nice because if you have a HackRF, ADLAM Pluto, Lime SDR or most other transmit capable SDR, you can use it as a mesh device with limited capabilities along with its many (many) other useful features.

Not much of anything has changed in the last year however with GQRX since its intent was always to be a simple and easy to use radio application for those getting started with SDR.

Shadowbroker

What is really amazing are the two new entries to the top ten most starred SDR projects less than a year later from my original analysis.  

Shadowbroker is defined as "Open-source intelligence for the global theater. Track everything from the corporate/private jets of the wealthy, and spy satellites, to seismic events in one unified interface. The knowledge is available to all but rarely aggregated in the open, until now." This project is now the 6th most popular as voted on by the community all time. 

Much of what Shadowbroker offers is functionality built into SDRangel actually, but Shadowbroker is meant to be an OSINT tool where SDRangel is more of a SIGINT tool, with built in OSINT functionality. 

It is amazing how fast Shadowbroker has obtained 5,500 stars since its first release which was only in March 2026.  From Shadowbroker's repository, here is a video showing its capability. 

A blend of true coding plus some level of "AI" vibe coding was used to come up with this and is an amazing achievement that not many are talking about Shadowbroker across the wider interwebs.  Maybe that will change soon. I sure hope so. 

It is really worth explaining why Shadowbroker is unique.  While SDRangel allows the user to show many types of location based signals like aircraft, balloons, boats, spacecraft, amateur radio people and more on a map all at the same time from directly connected SDR's, or those over a network,  SDRangel also allows some of what is received to also feed into other systems.

Shadowbroker is not just about radio signals. Its about complex situational awareness, so this is a really cool project for looking at many types of information. If you ever dreamed about becoming the "guy in the chair" this project helps you get pretty close to that, just like in the movies!.

Ground Station

Having a look at the now 9th most popular repository simply called ground-station, this project began life in October 2025 and has already gained 4,200 stars.  This is also very impressive as it touts being  a full-featured, open-source software solution for satellite tracking and radio communication. 

Designed for amateur radio operators, satellite enthusiasts, and researchers, it provides a comprehensive and easy-to-use platform for monitoring spacecraft, controlling radio equipment, and receiving live radio signals from satellites. This project was built with the help of Claude Code and Codex.

It is clear what this project is and how it was made.  Again, much of this functionality is built in to SDRangel, but can be overwhelming to some users and the new ground station project seems really nicely done.  A full understanding of its functionality can be found on the project page, which is now coming close to its hundredth release yet is still on up to version 0.4.4.  

Typically, when a project hits the v1 milestone, its considered much more mature, so there is certainly a lot more expected to happen with ground station.

Software Defined Radio

Comparing the top 10 from last year until now,  the same are all present with a few changing places in total stars, but otherwise nothing else is unique.  Clearly if you want to experiment with SDR,  its worth searching both ways, but the long form of "software defined radio" is not where things are happening compared to "SDR".

Ham Radio

There is one change in the top ten thanks to a project called HamDashboard which now would rank as 9th most popular and surprisingly helped knock down the LoRaHam project down to the eleventh spot. While the LoRaHam project is managed by the pretty famous Travis Goodspeed, here is a clear example that when a project sees no updates, it often becomes less popular. 

But, the work of Travis on areas like hacking the TYT MD-380 which helped make DMR very popular and his other projects found on his Git repository demonstrate that its worth keeping an eye on anything he is doing.  

HamDashboard by VA3HDL started three years ago, but has seen more work in the last few months. The focus is to provide a simple, browser-based ham radio dashboard that displays images, maps, web pages, and feeds in a configurable grid. It is lightweight, easy to host, and suitable for use on a local computer, Raspberry Pi, or a static host such as GitHub Pages or Cloudflare Pages. 

With projects like HamClock undergoing changes, it seems HamDashboard is becoming more popular and here is the proof to show that.  While very different than what Shadowbroker does, it seems that a need to visualize many data sources is an area that many radio hobbyists are very interested in. 

Amateur Radio

The top ten most "starred" projects found by using the "amateur radio" key term are also almost the same as a year ago.  A few projects changed total rankings, but there is a new number nine present via the APRS D project, which has been around since 2021, but only recently become more popular. 

Many changes within MKISS and AX.25 are starting to rattle thanks to the recent news about certain things being dropped from the Linux kernel but that is out of scope for this update, but still was worth a quick mention.

APRS which has been covered here at length continues to be a misunderstood or narrowly conceptualized area within communications, so its amazing that this project is one of the more popular voted on projects to keep an eye on.  

Pretty much anything related to APRS is worth keeping an eye on actually, so this is a nice place to end this article without diving super deep on this topic.

Summary

It is important to embrace the advances in technology and a great way to do that is to spend some time searching for things on Git.  The value I hope my presentation offers from last year and into this update is to demonstrate theory to fact in order to prove a point on how to track trends and uncover hidden patterns around topical areas worth paying attention to.  

A benefit for those interested in coding is you may find something you can help improve or for those not considered "coders", might find inspiration to leverage artificial intelligence (AI) by way of vibe coding to help create solutions targeted at clear problems, just like Ground Station has done and most likely a few other projects too.

Also worth noting that when it comes to "amateur/ham" radio, there is still not enough excitement in these areas to attract more innovation.  While unfair to compare to "SDR",  this is an area which many in the amateur community should be looking at for what should be next.

 

Receiving WWVB with HackRF Pro...

Dear HVDN readers the few of you who are left, it has been seventy four days since my last sin, er my last post.  As we enter into the colder months and possibly less distractions, have you been able to receive WWVB yest on your new HackRF PRO?

Of course you have not!  Early official units of this long anticipated SDR are not expected until December 2025 at the very earliest, but here is a great article dated October 31st which hits on many of my favorite topics.  Still, there is much to consume and apply to other projects or ideas you may have.

Click below for new window to open with this great article. Really, its really great! Expect more frequent content too.

Of just follow this URL if you want to feel more safe than randomly clicking an image and hovering over the URL to see if it is safe.

https://greatscottgadgets.com/2025/10-31-receiving-wwvb-with-hackrf-pro/

Presentation Replay: It had a long title.....

 

Here is the jump to my replay of the "Top Ten: Democratic Open-Source Software Defined Radio and Amateur Radio Applications That Matter Today" presentation on Saturday. 

https://youtu.be/bEatax_cbKA?t=7520

Other related stuff here https://hvdn.org/hope16.html

Been a while: What is new?

HOPE 16 is just a few days away and I am really excited to be there all day Saturday August 16th

Event details at https://hope.net/index.html

Details on my presentation "in advance" along with some other stuff can be found at https://hvdn.org/hope16

During HOPE 16, I may be making mention of a new and exciting job I am starting later this month.

If attending HOPE 16, please register at https://hope-16.totawatch.de/rules/

Also check out  https://www.nycresistor.com/ 

I will be on 446.075 MHz using DMR mode with TS1, CC1 and TG99 with 446.000 analog FM as backup.

Looking forward to being a bit more active again with projects, content and all sorts of other fun stuff again really soon.

-Steve K2GOG

You need to know what is going on within 902 and 928 MHz!

Will keep this brief as a photo is a 1,000 words and a 3 part video combining for 59 Minutes and 13 Seconds is worth I do not know what, but.....

You need to know what is going on within 902 and 928 MHz! 

On September 30th 2024, I was invited to present on what is known as the 33cm spectrum to the Warren County Amateur Radio Club. This plan was hatched by the club president, Adam Koeble KD2YFY and I over the summer while attending the Sussex County Hamfest. I just needed a topic, but knew it would involve MeshTastic and something else interesting.

Thanks to the NextNav news brought to the attention of the amateur radio world by the ARRL, I think I had my plan. With not only the amateur radio community irritated, the commercial world is not happy with what they are attempting to do. Even the Electronic Frontier Foundation has something to see about this possible land grab.

In my video, I explain who are the major users and what they are doing between 902 to 928 MHz.  Amateur radio is not as important here as some may think, as a secondary user for 39 years. But, those who are using unlicensed devices plus those using licensed frequencies with higher power here are pretty irritated should this NextNav plan get approved by the FCC.

My personal opinion is that there is enough spectrum to keep everyone happy, but amateur radio should lose secondary status and be given a few portions as primary users only.  I would offer the following scenario.

• 927.000 to 927.500 MHz (Repeater Output Block)
• 902.000 to 904.000 MHz (Weak Signal Users & Repeater Input Block)
• 910.000 to 912.000 MHz (Amateur Data Experimenters Block)

This reduces from secondary status from 26 MHz of total spectrum down to only to less than 5 MHz of spectrum.  The blocks above were chosen to protect repeater users as well as weak signal activities. It then dedicates a block to be used specific for any other use, such as modified use only for ISM repurposed devices for amateur radio only. These are my summarized comments submitted to the FCC before the deadline period.

A plan like this is more than fair, offers clarity for commercial users and easy to coexist with existing licensed users in almost every area plus provides a great incentive for unlicensed users to consider a path towards amateur radio or just stay as ISM users.

Let the rest of the ecosystem fight over the remaining 21 MHz left. Has the ARRL proposed anything?  I would love to find out! 

Have watch. I broke the video down into three parts and you can play them via a playlist or one by one:

Part 1 - Mostly just focuses on some history of the spectrum and how many devices are sharing the same spectrum across all users, licensed or unlicensed.

Part 2 - Gets into more details of the commercial users and breaks down spectrum used by different types of users, regardless of what they are doing as licensed or unlicensed users plus if they are commercial minded or not.

Part 3 - Focuses 100% on the very basics of MeshTastic, which uses unlicensed devices anywhere across the entire spectrum and by those that are not licensed and thus restricted to what they can do legally compared to the benefits of an amateur radio license holder, but will face other issues too! 

Controversial SDR: Plus 3-D Printing Stuff

It has been a while since an article has posted here, so this should be a good one involving a controversial SDR plus some 3D printing tips related to designing a simple enclosure for it.

Quick Summary:  Saving you a 20 minute video

Why is everything about price? For usually under $30, this SDR can be purchased on a few websites like Aliexpress and I am NOT encouraging you to buy this. Why?  It has infringed on the intellectual property of SDRplay in some regards. The driver used to get this and other similar MSI2500 chip based devices to work not made by SDRplay is needed. 

Only until recent versions of the driver, cloned versions of the RSP1 could use the driver to work with software easily like SDRangel, but that stopped after SDRplay API version 3.7.  I am glad that SDRplay built in some functions to only allow genuine SDRplay products to work with some of its software.  

However, since reference designs have been made public on the SDRplay earlier devices, anyone can freely assemble different semiconductors to replicate a decent SDR.  The device shown in the video uses separate band pass filters which is actually nice so the user can have spectrum specific antennae in use without the extra noise or complexity of electronic switching or the need for software to control that. This is why the SDR is so inexpensive.

Now that enough time has passed since I purchased these "clone" SDR devices and there are some improvements to protect SDRplay in place, now is a great time to get back to this.

https://www.aliexpress.us/item/3256805375754709.html

Any SDR based around the MSI2500 and MSI001 are unique compared to the R820T, 828D  and RTL2832U in that these support 10 MHz of bandwidth for around the same cost for those offering 3.2 MHz.  Another example is this one in a smaller form factor around the same size as the RTL-SDR devices, but with the extra filtering loses the wider frequency coverage above 1 GHz.

https://www.aliexpress.us/item/3256804660151348.html

There is an older video from 2021 where I showed how to get the SDRplay driver working with SDRangel below, but the new video instead focuses on an enclosure I designed for these 5 port SDR devices since I forgot to order them. The benefit however is a small case and simple design.

Here is the 2021 video talking about getting the SDRplay API to allow an SDRplay. Please note that this will not work any longer due to changes made by SDRplay, but there is an alternative version available called libmirisdr you can search for on your own or until I make a video about that.

Would you like the STL or OBJ or 3MF or STEP files for my case design? Please leave some nice and friendly comments in the video called Controversial SDR: Plus 3-D Printing Stuff  and will see what happens next. :)

30 Days: Weather Balloons from NY Capital Region

 

After thirty full days of monitoring the National Weather Service balloons launched from the capital region of New York State, here are some observations. 

Hopefully this inspires you to become interested in this unique weather monitoring opportunity anywhere in the United States or other parts of the world using inexpensive and easy to set up equipment.

Twice daily and from more than 90 launch sites in the United States, the National Weather Service releases weather balloons to help monitor upper air observations for the first 15 miles of atmosphere. The closest launch site to me comes from the Albany area of New York and currently the exact location is on the grounds of University of  Albany instead of at an official NWS facility.

Even with all the advancements in space or ground based radar or other sensors, a radio sonde balloon still is one of the best ways to monitor a variety of useful measurements.

Setting up a receiver which listens for these weather balloons is relatively easy and inexpensive. Not much additional knowledge is needed and generally the project of setting up a ground receiver will teach a number of other useful things related to some basic RF and computer related skills to anyone interested in STEM related interests.

30 Days:  What Did I Learn?

Different times of the year of course will have different general weather characteristics. Here in New York, December and January are known to be a bit tricky thanks to cold and wet weather which usually includes some gusty conditions too!

From my home in Poughkeepsie shown as the radio tower on the map, I am easily able to receive the Albany area launched balloons once they generally reach around 17,000 feet AGL. 

Signals first are heard by my antenna at an average of 58 miles south of the launch point and the average furthest signals away are closer to 100 miles usually towards the north east.

Looking at the above map, green target symbols are for where the balloon signal was first received and the red target symbol is where the last signal heard by my receiver system.  A explosion icon is where the balloon reached maximum altitude before it burst and started to descend.

Given the distances involved from my home location, a quick retrieval is not very likely by me but the goal is eventually to capture one and send it back to the National Weather Service.

In general, the wind mostly blows west to east. On more than a few occasions, it got so windy, some balloons traveled so quickly and accurate telemetry was not received for too long. 

On average, locations are sent once every 10-15 seconds and more than 3000 positions are captured per flight. Here is an example of January 22nd to 29th 2024 recordings and general statistics.

The blue lines on the map are the flight paths and there is much greater granularity to be observed when plotting the path on Google Earth. Its worth noting that sometimes the GPS on the balloon sometimes sends a false report for a short time to help explain the straight horizontal or vertical lines on the map.

Within the AutoRX application which is what runs on a Raspberry Pi based receiver along with an SDR dongle, its easy to also output in real time to Google Earth to visualize in 3D, such as to see where packets were not received by looking at the lighter colored part of the map when zoomed in. Sometimes wind gusts make the balloon much faster than the reporting transmissions occur.

Here is a converted MKV to GIF video file zooming around from azimuth and elevation angles to show more details in the North East from receiving site, path and location details during the February 1st evening launch from Albany area.

It is interesting to see how the wind blows is sort of the summary of this article.  Data like this is just one of the many inputs used in more complex weather forecasting.  When the time is right and weather nice, it will be fun to retrieve a balloon once its on the ground. 

Details about that can be found on www.sondehub.org and there are also portable receivers easily created from the ESP32 LoRa boards like the Heltec V3 which also runs other projects like Morserino, HASviolet, LoRa APRS and MeshTastic.

Hey guess what? I "sonde" you up in a tree!

 

Each year in the United States, there are over 70,000 balloon based "sondes" launched by the National Weather Service.  From locations from around the country, multiple times a day these are launched and they each transmit back weather data back down to ground stations.

It is easy to receive the 400-405 MHz signals from these balloons and this is what we will cover here

It is easy to use an inexpensive RTL-SDR device and a modest antenna to receive the balloon signals line of sight. Before you even get started with building your own ground station, you can check out networks of these stations such as the ARDC backed www.sondehub.org 

Looking at your area you will see launch and receiver sites, plus those interested in tracking them once they land.  Some hunters put some nice stories up once they find them.   

If the weather interests you and you are looking for some other signals to find if you also are interesting in radio direction finding, you may have just found yourself a new side hobby. Here are some of the Grafana based analytics from Sondehub.

Getting Started:   You have the pieces. Now what?

To build a ground station for radiosonde tracking, you will need:

• A Raspberry Pi (3B or later is best)
• An RTL-SDR (Suggest the RTL-SDR V3 or V4)
• A UHF antenna (1/4 wavelength is small. Look it up)
• Auto-RX software
• A place to put your system which will need to be on 24/7

There is a great Wiki for setting everything up from a software perspective, so no need to summarize. It is a big project with great documentation. https://github.com/projecthorus/radiosonde_auto_rx/wiki 

Figuring you are starting with a fresh SD card, once you install Raspberry OS, the rest of the steps should have you up and running in less than an hour or faster.

Give some thought to your antenna though first. If you are an amateur radio person, you do not want to transmit where it may interfere with your new ground station. Some inexpensive filters help here, plus improves the overall results anyway. A nice double benefit.

Here are reception results from the author location for last 24 hours of launches from the Albany NY launch location.  Once balloon has landed and the other is still floating around. 

Not sure what else to share, but beyond using Auto-RX,  you can also use SDRangel to receive radio sonde data too, which is nice if you plan to go portable or mobile.  There was reason to include radiosonde capability in the SIGpi project too, so feel free to look into that also.

Until next time....

Steve K2GOG

Modern Ham Radio: 6 Reasons why LoRa Matters

 

Before COVID was a thing, the HVDN team worked on a project called HASviolet. The underlying wireless technology for this was LoRa. The timing was great for us to get into this spread spectrum technology as the costs for consumer hobbyists were coming down and the possibilities were endless or so we thought back in 2018 and into 2019.  

There are many, many videos by all the famous ham radio people on YouTube covering this also, so chances are you have heard of LoRa by now right?

This article is going to focus on six clear reasons why if you are involved in ham radio and our modern digital future, you need to get up to speed about LoRa now. And.... we are only hyperlinking once, so get ready to do some massive Google action for things mentioned below! 

Lessons learned from a presentation made at a few ham clubs a few years ago, we were early adopters in HVDN and now the rest of the world can catch up to us now that there is more to do and easier to buy.  

This article does not apply to people who think that HF and CW is the pinnacle of ham radio, so do NOT start making comparisons because LoRa has different goals, mostly deployed on the 70cm and 33cm bands.  Here we go...

Reason #1:  Its another mode with infinite settings - In LoRa language, there are some settings you can adjust that give you optimized communication.  As in "traditional" ham radio, in voice modes like AM, FM and SSB, you can change your bandwidth and audio to your liking. 

With Morse code, you can change how fast or slow you send with the aid of your radio features plus how to filter out adjacent signals.  With digital voice modes like DMR, you really do not adjust anything, just the destination details like color code, time slot and talk group. 

Other modes like D-Star, Fusion, NXDN, P25, there are other things you change relative to destination, but with these you can also send different non-voice payloads like location, texts and limited telemetry.  LoRa also does not compete directly with the likes of FT8, PSK31, RTTY, etc since it can do so much more. Closest competitor in terms of utility might be VARA, but its still not the same.

It is hard to RTFM if no manual exists. Welcome to LoRa and many other modern things which only include out of date limited print material. Its no longer 1979. Lets move on here.

With LoRa, you adjust the frequency and bandwidth plus specific settings for spread factor (SF) and coding rate.  The right blend of settings can provide short and fast transmissions for short range communication or longer and slower communications for greater range plus higher overall throughput or data speeds.  

There are many options in between which give you higher or lower data rates too.  This is important depending on what you are communicating and how often. LoRa does not support voice communications though, but can actually have up to eight distinct simultaneous channels for different needs and that is actually pretty cool.

There are preset options for frequency and the right settings to chose from are built in to many projects already.  The top non-academic level projects to look into are Meshtastic, HASviolet and LoRa APRS.

 All three are ready for use and support many different applications not found elsewhere in amateur radio today using advanced waveforms, low signal to noise ratios and options around spread spectrum technology at very low cost. Beware that interoperability is still being worked on given frequency and setting variances.

Reason #2: It is a cheap way into ham radio for people who do not speak - Sure, you can go and buy a cheap Baofeng or Quansheng radio for VHF/UHF voice communications or any other inexpensive radio that may do digital voice modes like DMR with or without some extra messaging capability.   You can also buy and build some type of 40m CW lower end kit for around the same price. 

Sure you can use a wire and connect the radio to your computer device and do limited data over audio channels. 

Price is not the goal here, but for under $50.00 you can buy a pair of either 433-510 MHz or 900-928 MHz LoRa radios plus maybe a case for both.   

While all the projects mentioned support either frequency range, there are benefits to both options.  

If you plan to coordinate with others, try to all buy the right spectrum radios.  It is worth noting that the M17 mode boards available for under $50 today can do both voice and data, but require a 9600bd capable radio and is still the same type of 12.5 kHz signal used by other digital voice modes. So we are still not talking about price.  For under $50 you can buy two LoRa radios on 70cm, install the right code for which over project catches your eye and that is all you need along with an antenna for greater range.

Reason #3:  It offers great community value  -  If you and your local friends can actually plan together, you can communicate in interesting ways with LoRa. 

Depending on the project you like best, its possible to bounce your signals from one another using mesh features or over a wider distance via a well placed digipeater. 

While most LoRa options are low transmit power, the range is pretty impressive and this allows both ham radio and unlicensed people to talk to each other with LoRa. As a ham, you can use higher power and create nodes that serve the whole community.  Be careful however when selecting frequencies so that you do not share unlicensed users over a digipeater created via LoRa in amateur radio.

Here is your chance to actually do something for the community because no one who is not a ham could care less about your morning "fiddle faddle good guy net". 

Your neighbors can check in with one another if the internet or cellular network goes down. 

This is your chance to do something without a 130ft wire antenna and the cult like aura of Morse code or even the local analog voice repeater where some "morning drive" discussions take on some form of papal like positioning.  

Once you get your community engaged with LoRa, then you can try and suck them in to the parts of the hobby you like better later on.  Again,  LoRa could be a great gateway into ham radio if thought about correctly.

Reason #4:  Gets you out of the house - We know you want to sit in your shack or pack your car full of gear to go to a park and bring way too much equipment to play "Parks On The Air".  With a LoRa device, you can look for other signals and be surprised who may be using LoRa, especially via Meshtastic if everyone is using the same frequency and settings.  

Clip a node to your dog collar or hide one on your wife's bag to track them, if you have a LoRa device with GPS. Give one to your kid or grandchild to stay in touch with you in an area with bad cellphone coverage.  It is easy to pair a LoRa device to your smartphone to create a modern text communicator.

There are many things you can do with LoRa and it also makes a great discussion point the next time you are doing POTA and no one cares about 20m contact park leader points.   If you are into SOTA, this may really get fun during summit to summit contacts especially since these are very small and light weight.  

You may even wish to visit your local library to have them print a 3D case for you if you do not own a 3D printer. So, anything with LoRa may get you doing something different somewhere different and possibly with different people for different reasons.

Reason #5: People who have 3D Printers will love it - If you have a 3D printer, now you can print cases for your local community which are customized how you like them for a LoRa based project. This also gives you reasons to find unique places or uses for a LoRa device to help justify why you bought your printer in the first place.

If you got into digital modes like DMR, D-Star, etc via a MMDVM based hotspot, think of LoRa as the next thing you need a 3D printed case for.

 

Reason #6:  Update the software to do really cool things - Best for last. If you use the Meshtastic software and want to try something else, just flash the new program to the ESP32 LoRa device you have or whatever other option you acquired.  

It is super easy to change things around and then even make you rethink your device case since you may now want to connect sensors to your LoRa device.  Have you ever wanted a mailbox alert to know when your small Amazon packages get shover in your postal box?  You can do that!  

There are so many options to explore and software is usually free, thanks to a community of opensource people. 

Heck, maybe if even gets you dabbling in some code without feeling overwhelmed since the projects mentioned here are well documented on Git.

Ok, now that I have your attention 

You are probably thinking, what to buy and where to buy it. Ham radio people often jump at the chance to spend a little money. And, by little I mean little.  That last under $50 HT you bought because you saw a video on YouTube or a local friend got one is a great example.  

How about those under $50 ham clock screens for your shack?  YES!  LoRa is now another thing competing for your under $50 spending.

Before you go and buy something, please do a little more research.  This is not for someone who struggles to find the power switch on a computer, how to use CHIRP software, or does not yet know that Raspberry Pi is not a snack.

The good news is there are people who did the hard work for you already to help guide what you buy, but beware, not all LoRa products are the same. Here are the tips for making your first LoRa related purchase.

Tip #1 -  Spectrum choice. It is likely better to purchase 70cm (420-450 MHz) capable equipment compared to the 33cm (900-928 MHz) type.  Be sure what you are buying is the correct frequency range. Some options on Amazon may be unclear so be 100% sure of this first before buying.

Tip #2 - LoRa is not always a finished product. While there are some really cool things on Etsy, Amazon and others sites you can find simply by searching for "LoRa".  Likely a case is the most important thing to put an unfished LoRa board in. Here is an example if you want to get started which includes a basic case, but not self contained in any other way.

Tip #3 - Power!  The Heltec v2 board linked in the above tip can run on a battery, but this means you need to buy a battery and a case to put your radio in. This means you will do some more research. A great example can be found on Etsy via a reputable seller who often gets sold out quickly since he prints on demand per order, but are top quality. If you have your own 3D printer, you can print the cases yourself though since the plans are in public.  Really consider power to your device early on to help you with future use cases.

Tip #4 - How do you use it?   The Heltec or TTGO options out there based around an ESP32 provide the ability to connect the LoRa board to a computer or smartphone over USB, WiFi or Bluetooth. If you plan to build some sort of "LoRa Base Station" for use at home connected to an amplifier and larger antenna, using USB is fine since it can power a board and provide communications at the same time without needing a battery.

Tip #5 - Oh, this is sort of like APRS for tracking things?  Yes, LoRa can be used for that. Not every LoRa board has GPS built in. Many boards can connect an external GPS to it if you wish to add that later. Many applications can still send location data without a GPS since you can either manually put coordinates in or use the GPS from your smartphone.  I would advise start with the two pack of LoRa mentioned above first and then perhaps buy a device like a TTGO T-Beam which is almost all self contained, including battery.

Tip #6 - Tell your friends!!  For this to work, we need more people using LoRa. There are groups focused on frequency standard like 433.775 as being a common one so far, but with different spread and coding rate.   If a few digipeaters can be put up somewhere using this inexpensive equipment, communications range is increased. Parts or Europe have been ahead of one North American country for a few years now, not surprisingly as example. 

Finishing Up

There are no links above in article which is different compared to many HVDN articles. We are trying to encourage you to go and search on your own. That is why!

Behind the scenes in building a SIGINT Linux distro

Introduction

Back in October 2021 I was interested in building a SIGINT platform. I logged my journey and published an article on HVDN at that time. Little did I know that journey would have led me to build and maintain a SIGINT build tool for Linux called SIGpi for the past two years with 28 releases during that time.

Inspiration

As the saying goes, "Necessity and is Mother of invention." It started with Steve K2GOG wanting to run the latest release of SDRangel on the Raspberry Pi. SDRangel is an awesome Open Source SDR and signal analyzer tool written by Edoaurd Griffiths F4EXB. If your a long time fan of the HVDN notebook, you already know Steve is a huge fan of SDRangel.

Often your Linux distribution of choice may not have the latest version of your favorite software whether available as a distro package, Snap, or Flatpak. In fact it could be many versions behind. Some authors will have package releases on their GitHub sites ready to download and install. If not and if its open source, you will be able to download the source could from their GitHub repo source and compile yourself. While authors may provide compiling instructions, you will find yourself down the rabbit hole addressing all the dependencies the software has first - libraries, drivers, specific versions, etc. The advantage in using packages that came with distros is the package manager will take care of auto-installing dependencies and their correct versions.

Fortunately SDRangel is well-documented providing detailed compile instructions. Once I mastered that I canned the instructions into a Bash script. and shared that with Steve. After getting rid of some bugs with my script we achieved success

Crawl

Compiling code and writing shell scripts was something I had done in the past but not to the degree of calling myself a developer. But working with SDRangel inspired me to expand on that Bash script and create a script that would install a series of drivers, libraries, and applications to create a SIGINT platform for my needs and anyone who had similar one - SIGpi 1.0 was born.

SIGpi 1.0 was really just one big bash script named SIGpi_installer.sh. SIGpi 1.0 installed drivers for RTL-SDR, HackRF, and PlutoSDR SDR devices and the Soapy SDR platform which provides a vendor-neutral API for SDR applications. With my compiling and scripting skills leveling up, I could confidently choose whatever latest SDR application I wanted for SIGpi and compile and package myself as long as it was open source and the source code available. But the cost of using the latest software versions is it could take up to four hours for SIGpi to install on a Raspberry Pi.  For Amateur Radio related applications I stayed with the releases available from the distro since little changes with them.

Walk

Less than thirty days later I released SIGpi 2.0. Besides support for LimeSDR and additional applications, it introduced a text-based menu system allowing you to pick and choose what applications and SDR drivers you want installed. The menu uses Whiptail - a dialog box tool for shell scripts which is included in most if not all Linux distros. It is used by raspi-config.

Adding applications requires ensuring their dependencies are installed as well. Since many applications have same dependencies, I broke SIGpi install into stages where the dependencies for all applications would be installed before installation of the applications themselves. The stages were:

• Run OS update
• Setup directories and desktop menu skeleton
  
• Install devices
• Install dependencies
• Install Libraries
• Install Applications
• Install Desktop Menu
• Reboot system
  

The staging model continues to this day but evolved from functions within a single install script to nested scripts called by the install script starting with SIGpi 3.0.

Run

To end users, the evolution of SIGpi from 3.0 to 4.1 varied in the applications supported. But much of the development was focused on the underlying architecture of the SIGpi build to facilitate ease of updates. First step was to simplify the development process in producing releases. The second step was to extend that so end users can perform application updates themselves through a simply command line process.

For SIGpi 5.0 I created a package management system akin to APT as used by Debian and Ubuntu. SIGpi management differs in that it is source neutral. Source could be a distro package, local package, Snap, FlatPak, or download/compile/install from source code.This started with maturing application specific nested scripts used by the SIGpi_installer into "SIGpi Package Scripts." The package scripts would be used by SIGpi_installer and a new command-line script called SIGpi - a front end to the package scripts.

Usage: sigpi [ACTION] [TARGET]
          ACTION  
                 install   install TARGET from current release
                 remove    remove installed TARGET
                 purge     remove installed TARGET and purge configs
                 update    check to see if new TARGET available
                 upgrade   upgrade TARGET to latest release

          TARGET
                 A SIGpi package

The update command checks the SIGpi repo if there is a new release. If the response is "update is available" then you can run the upgrade command and the target will be updated to the new release.

SIGpi update sdrangel

Update is available 

SIGpi upgrade sdrangel 

Fly

Compiling applications like SDRangel and GNUradio on the Raspberry Pi contributes to more than half of the install time for SIGpi. Time is the price you pay to run the latest versions. To improve the install time I realized I needed to uplevel my skills again with the ability to create Debian packages. After some research I discovered the checkinstall tool as a simple way for creating Debian packages from compiled source. For SIGpi 6.0 I created a number of Debian packages starting with GNUradio and SDRangel that could be download and installed as part of the SIGpi installation process. I had now significantly reducing the install time to just over an hour.

I updated SIGpi package management with hidden developer options to build Debian packages of supported applications.

Usage: sigpi [ACTION] [TARGET]

          ACTION  
                 build     compile and install TARGET from current release
                 package   compile and create Debian package only

          TARGET
                 A SIGpi package

SIGpi 6.0 also saw the deprecation of 32bit for 64 bit.

Idling

SIGpi started with support only on Raspbian OS (32bit) for the Raspberry Pi 4. When 32bit support was deprecated, SIGpi not only migrated to Raspberry Pi OS (64bit) but expanded to include Ubuntu on x86-64/AMD64 architecture. The change was not only in response to the RPi hardware "famine" that was out there, but RPI pricing was reaching the point for serious consideration of low-end Mini PCs. While we test for those platforms, know SIGpi should be able to run on most Debian-based AMD64 and ARM64 systems.

Throughout the journey I kept considering whether SIGpi should continue as the build kit it is or be a full distro where you download and install a full OS image like DragonOS or DigiPi. What I kept coming back to is releasing a distro image may be easier for me to support and develop but it would be at the expense of limiting end-user experimentation integrating SIGpi into their own creations.

Another consideration has been whether to start using Docker and create docker images for complex SDR applications like SDRangel. Again what may be easier for the developer would be at the expense of experimentation by end-users. Docker adds overhead that the end-user would need to be familiar with.

Land

Many open source projects come and go for a variety of reasons. The best reason for closing a project is when similar projects merge and leverage the best of each. But often a project owner loses interest or support and refers people to other open source projects.

It makes me happy to see all the stars and forks the SIGpi project has received to date. It keeps me thinking on what more I can do with the project that delivers the most value in ease of experimentation for SDR while minimizing efforts for end-users in building a platform that supports it. This is the goal as I begin development for SIGpi 7.0

Areas of improvement considered include:

• A better TUI menu system for installation and SIGpi package management.
• Documentation on the SIGpi package management system for end-users to add applications requiring compilation for using latest versions
• Continuous development/release rather than point release model
  
• Hardware Certification metrics for SIGpi
  

I hope this article serves as an inspiration for your own projects and helps with decision points in your own journey.

73,

Joe, NE2Z

 

Journey into Software Defined Radio Experimentation

A few years ago, I published an article asking (Is a Poor Man's 705 possible?

​At that time, Ashhar VU2ESE announced work on the sBitx - an Open Source Software Defined Radio (SDR) using a Raspberry Pi 4 (RPi4.) The sBitx would be the successor to his previous project, the uBitx, a software-controlled radio using an Arduino. A PDF was published providing in-depth technical detail of the sBitx and a GitHub repo shared of code developed to date. The uBitx and sBitx are great examples reflecting the evolution of transceiver kit building.

 

Software-Controlled Radios

Software-controlled radios use software only to control the radio. Early examples of this include the use of Programmable Interface Controllers (PIC) with the PIC16F84 being quite popular. The PICs were pre-programmed and undocumented making them "black boxes." Replacing PICs with end-user programmable microcontrollers (MCUs) like the Arduino and open source code made software experimentation more accessible to the kit builder.

The uBitx architecture reflects a well-documented entry level software-controlled radio. Software-controlled because for it to be considered a SDR, signal processing needs to occur in the digital/compute domain. The RF section of the uBitx is mostly analog using a double conversion superhet design. The piece that is not is the si5351 i2c programmable oscillator commonly available as a breakout board module.

Diagram 1 - uBitx Architecture Model

The si5351 and the rest of the RF section is controlled by an Arduino MCU. The Arduino also drives the display and connects to a rotary encoder for user input.

Building the kit is a combination of plugging cables and soldering connectors. You can run with the firmware included or download the Arduino source code, modify, compile, and upload your own firmware. The firmware is created using the Arduino language compiled with the Arduino Integrated Development Environment a cross-platform application installed on a PC or laptop. The Arduino has a USB port for uploading the compiled code from your PC or laptop. The Arduino language itself is based on C/C++. 

Subsequent uBitx versions updated the display from LCD to a touchscreen by Nextion. Nextion displays are considered Human Machine Interfaces (HMI) with their own programmable microcontroller embedded dedicated to the task. The Nextion display is programmed using the Nextion Editor. The editor is used for GUI design and uploading the code to the display.

As a software-controlled transceiver, it is important to understand the code that is controlling and the implications of any changes you make to that code since you could damage it. If you are new to the Arduino, it is best you become familiar with it, building simple projects first and getting familiar with the IDE and the libraries it uses. The same can be said with the Nextion.

 

SDR using the Raspberry Pi

For many the Raspberry Pi is considered a more relatable technology to work with its single-board computer (SBC) that runs full operating systems supporting simpler popular languages like Python. The promise of introducing a Raspberry into a SDR design is more options for experimentation.

Diagram 2 - sBitx Architecture Model

​Diagram 2 is a high-level architecture model of the sBitx. The sBitx still uses a mostly analog RF section, but the MCU is replaced with a single board computer (SBC) the RPi4.

In this design, audio is routed through to an audio codec board using a WM8731. In turn, the audio is routed to the RPi4 via the SPI interface using the i2s protocol. There is also a switch from the proprietary Nextion display to commonly available touchscreens connected via DSI interface of the RPi4. The Sbitx includes a Raspberry Pi OS image with all the applications required to operate it included. The applications are compiled C.

Running operating systems adds processing overhead and latency which limits how much signal processing you can offload to the RPi4. This is why an audio codec board is used and all the code that runs the RF and Display sections is compiled C.

The allure of using a Raspberry Pi is the familiarity many have with it as part of their radio stations for logging, digital modes, and SDR RX projects and installing those applications on the RPi4 used by the sBitx. But lower-level experimentation with signals and control remains in the domain of C level programming to address latency concerns.

Up to now we have been covering HF transceivers which require more discrete analog components for RF sections. What about VHF/UHF?

 

Building VHF/UHF SDR transceivers

Say what you want about the Baofeng UV-5R and its derivatives, but its design has contributed to experimentation starting with its core component, the RDA1846 single chip transceiver coupled to a microcontroller. While the microcontroller code is proprietary some people have either hacked similar radios to upload their own firmware (such as OpenGd77) or breadboarded began using shielded RF modules like the SA818 "walkie Talkie" module This module includes an embedded microcontroller programmed through a serial connection using AT commands reminiscent of the analogue modem days. The best representation of this in kit build is the Hackerbox #0096 Two meter kit with its high-level architecture modeled below.

Diagram 3 - VHF/UHF Architecture Model

The design includes a SA818 module connected to a ESP32-S3 microcontroller with display and pushbutton connections to it controlling channels, PTT, etc. The kit refers you to GitHub repos for source code and compiles it using the Arduino IDE.  As with the evolution of uBitx to sBitx you could replace the MCU with an SBC and Audio board to expand from RF and interface control to include applications for SDR and digital modes with display and controls updated to a TFT. With an RF module, your experimentation on the build proper is all software.

 

”Full Stack” SDR

The “software” in open source SDR has been targeting the lowest common denominator in languages for developers for experimentation. This includes C, Bash, and Python. When it comes to interfaces, developers have a closer relationship to web development than coding in C for displays. You can see this in practice if you have used one of the many WebSDRs on the Internet.

Diagram 4 - "Full Stack" SDR Architecture Model

In the diagram above the application and interface sections reflect the web technologies required for a web browser to be the interface. I wrote an application and interface a few years ago (radioDASH) that will give you an idea what this looks like at the code level plus another project implemented with a LoRa transceiver on a microcontroller (HASviolet-ESP32.)

 

Why no HF RF modules?

In the simplest of explanations, longer wavelengths at HF frequencies require larger discrete components for filtering transmission spurs on unintended frequencies. Hence many of the QRP SDR kits out there have full RF boards with the local oscillators (that include the Si5351) on those boards controlled by a microcontroller. True SDRs like the FlexRadio use direct conversion for RF and proprietary FPGA chips for signal processing hence their expense.

 

Where is this all heading?

The lowest common denominator in the evolution from PICs to SDR is firmware developed in C given the low latency needs for signal processing. With the evolution from PICs to MCUs, entrants like the Arduino have made programming more accessible with its IDE and community support in code shared. But going from MCUs to SBCs only adds the ability of running peripheral applications like digital modes, logging, and radio control on the same platform. Compiled C is still necessary for any latency sensitive control.

Only when you have RF modules with embedded controllers and well documented APIs are software skill requirements relaxed. As mentioned previously, the SA818 module is configured using AT style commands via a serial port. This should sound familiar to those using dial-up or early cell modems.

When it comes to SDR experimentation consider your goals and the skillsets required before selecting the architecture model you want to pursue. This is why software-controlled radios remain the best entry level into the SDR space.

73,

Joe NE2Z