Thursday, February 1, 2024

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 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.

Wednesday, December 27, 2023

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 

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. 

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!

Wednesday, December 20, 2023

Behind the scenes in building a SIGINT Linux distro


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.


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


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 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.


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.


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]
                 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

                 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 


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]
                 build     compile and install TARGET from current release
                 package   compile and create Debian package only
                 A SIGpi package

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


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.


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.


Joe, NE2Z