The personal website of Scott W Harden

Seven Years of QRSS Plus

This article was written for Andy (G0FTD) for publication in the December 2020 edition of 74!, The Knights QRSS Newsletter. Join the QRSS Knights mailing list for the latest QRSS news.

The QRSS hobby owes much of its success to the extraordinary efforts of amateur radio operators who run and maintain QRSS grabber stations. QRSS grabbers are built by pairing a radio receiver with a computer running software to continuously convert the received signals into spectrogram images which are uploaded to the internet every few minutes. QRSS Plus is a website that displays these spectrograms from active QRSS grabbers around the world. This article discusses the history of QRSS Plus, the technical details that make it possible, and highlights its most active contributors in 2020.

Early Days of QRSS Grabber Websites

In the early 2010s when I started to become active in the QRSS community, one of my favorite grabber websites was I2NDT's QRSS Knights Grabber Compendium. I remember checking that website from my laptop during class several times throughout the day to see if my signal was making it out of Gainesville, Florida. I also recall many nights at the bench tweaking my transmitter and looking at all the grabs from around the world trying to spot my signal.

A common problem with QRSS grabber websites was the persistance of outdated grabber images. Whenever a grabber uploaded a new spectrogram image it replaced the previous one, but when a grabber stopped uploading new images the old one would remain. Most uploaded spectrograms have a date written in small text in the corner, but at a glance (and especially in thumbnails) it was difficult to identify which grabber images were current and which were outdated.

History of QRSS Plus

I created QRSS Plus in July 2013 to solve the problem of outdated spectrograms appearing on grabber websites. QRSS Plus works by downloading grabber images every 10 minutes and recording their MD5 hash (a way to convert an image into a unique set of letters such that when the image changes the letters change). Grabbers were marked "active" if the MD5 hash from their newest image was different than the one from the previous image. This original system was entirely operated as a PHP script which ran on the back-end of a web server triggered by a cron job to download new images and update a database every 10 minutes. The primary weakness of this method was that downloading all those images took a lot of time (they were downloaded sequentially on the server). PHP is famously single-threaded, and my web host limited how long PHP scripts could run, limiting the maximum number of supported grabbers.

The back-end of QRSS Plus was redesigned in 2016 when I changed hosting companies. The new company allowed me to execute python scripts on the server, so I was no longer limited by the constraints of PHP. I redesigned QRSS Plus to download, hash, and store images every 10 minutes. This allowed QRSS Plus to display a running history of the last several grabs for each grabber, as well as support automated image stacking (averaging the last several images together to improve visualization of weak, repetitive signals). This solution is still limited by CPU time (the number of CPU seconds per day is capped by my hosting company), but continuously operating QRSS Plus does not occupy a large portion of that time.

QRSS Plus Activity in 2020

I started logging grabber updates in September 2018, allowing me to reflect on the last few years of grabber activity. It takes a lot of effort to set-up and maintain a quality QRSS grabber, and the enthusiasm and dedication of the QRSS community is impressive and inspiring!

In 2020 our community saw 155 active grabber stations! On average there were more than 60 active stations running on any given day, and the number of active stations is visibly increasing with time.

In 2020 QRSS Plus analyzed a mean of 6,041 spectrograms per day. In total, QRSS Plus analyzed over 2.2 million spectrograms this year!

This bar graph depicts the top 50 most active grabber stations ranked according to their total unique spectrogram upload count. Using this metric grabbers that update once every 10 minutes will appear to have twice as many unique grabber images as those which upload a unique image every 20 minutes.

Many QRSS grabber operators maintain multiple stations, and I think those operators deserve special attention! This year's winner for the most active contributor goes to David Hassall (WA5DJJ) who alone is responsible for 15.26% of the total number of uploaded spectrograms in 2020 🏆

The top 25 contributors with the greatest number of unique uploads in 2020 were (in order): WA5DJJ, WD4ELG, W6REK, G3VYZ, KL7L, G4IOG, W4HBK, G3YXM, HB9FXX, PA2OHH, EA8BVP, G0MQW, SA6BSS, WD4AH, 7L1RLL, VA3ROM, VE7IGH, DL4DTL, K5MO, LA5GOA, VE3GTC, AJ4VD, K4RCG, GM4SFW, and OK1FCX.

Maintaining QRSS Plus

I want to recognize Andy (G0FTD) for doing an extraordinary job maintaining the QRSS Plus website over the last several years! Although I (AJ4VD) created and maintain the QRSS Plus back-end, once it is set-up it largely operates itself. The QRSS grabber list, on the other hand, requires frequent curation. Andy has done a fantastic job monitoring the QRSS Knights mailing list and updating the grabber list in response to updates posted there so it always contains the newest grabbers and uses the latest URLs. On behalf of everyone who enjoys using QRSS Plus, thank you for your work Andy!

The Future of QRSS Plus

Today QRSS Plus is functional, but I think its front-end could be greatly improved. It is written using vanilla JavaScript, but I think moving to a front-end framework like React makes a lot of sense. Currently PHP generates HTML containing grabber data when the page is requested, but a public JSON API would make a lot of sense and make QRSS Plus it easier to develop and test. From a UX standpoint, the front-end could benefit from a simpler design that displays well on mobile and desktop browsers. I think the usability of historical grabs could be greatly improved as well. From a back-end perspective, I'd much prefer to run the application using a service like Azure or AWS rather than lean on a traditional personal website hosting plan to manage the downloads and image processing. Automatic creation of 8-hour (stitched and compressed) grabber frames seems feasible as well. It is unlikely I will work toward these improvements soon, but if you are a front-end web developer interested in working on a public open-source project, send me an email and I'd be happy to discuss how we can improve QRSS Plus together!

QRSS is a growing hobby, and if the rise in grabbers over the last few years is an indication of what the next few years will look like, I'm excited to see where the hobby continues to go! I encourage you to consider running a grabber (and to encourage others to do the same), and to continue to thank all the grabber operators and maintainers out there who make this hobby possible.

Notes and Resources

  • Data includes Jan 1 2020 through Dec 11 2020
  • Stations with <1000 unique uploads were excluded from most analyses
  • Summary data (a table of unique images per day per station) is available: qrss-plus-2020.xlsx
  • Bar graphs, scatter plots, and line charts were created with ScottPlot
  • QRSS Plus is open source on GitHub
  • A modern introduction to QRSS: The New Age of QRSS
  • FSKview is a new QRSS and WSPR Spectrogram Viewer for Windows
Markdown source code last modified on January 18th, 2021
---
title: Seven Years of QRSS Plus
date: 2020-12-14 21:16:00
tags: qrss, amateur radio
---

# Seven Years of QRSS Plus

> This article was written for [Andy (G0FTD)](https://sites.google.com/view/andy-g0ftd/) for publication in the December 2020 edition of [74!, The Knights QRSS Newsletter](https://swharden.com/qrss/74/). Join the [QRSS Knights mailing list](https://groups.io/g/qrssknights) for the latest QRSS news.

The QRSS hobby owes much of its success to the extraordinary efforts of amateur radio operators who run and maintain QRSS grabber stations. QRSS grabbers are built by pairing a radio receiver with a computer running software to continuously convert the received signals into spectrogram images which are uploaded to the internet every few minutes. [**QRSS Plus**](https://swharden.com/qrss/plus/) is a website that displays these spectrograms from active QRSS grabbers around the world. This article discusses the history of QRSS Plus, the technical details that make it possible, and highlights its most active contributors in 2020.

### Early Days of QRSS Grabber Websites

In the early 2010s when I started to become active in the QRSS community, one of my favorite grabber websites was [I2NDT's QRSS Knights Grabber Compendium](https://digilander.libero.it/i2ndt/grabber/grabber-compendium.htm). I remember checking that website from my laptop during class several times throughout the day to see if my signal was making it out of Gainesville, Florida. I also recall many nights at the bench tweaking my transmitter and looking at all the grabs from around the world trying to spot my signal. 

A common problem with QRSS grabber websites was the persistance of outdated grabber images. Whenever a grabber uploaded a new spectrogram image it replaced the previous one, but when a grabber stopped uploading new images the old one would remain. Most uploaded spectrograms have a date written in small text in the corner, but at a glance (and especially in thumbnails) it was difficult to identify which grabber images were current and which were outdated. 

### History of QRSS Plus

I created [QRSS Plus](https://swharden.com/qrss/plus/) in July 2013 to solve the problem of outdated spectrograms appearing on grabber websites. QRSS Plus works by downloading grabber images every 10 minutes and recording their [MD5 hash](https://en.wikipedia.org/wiki/MD5) (a way to convert an image into a unique set of letters such that when the image changes the letters change). Grabbers were marked "active" if the MD5 hash from their newest image was different than the one from the previous image. This original system was entirely operated as a PHP script which ran on the back-end of a web server triggered by a cron job to download new images and update a database every 10 minutes. The primary weakness of this method was that downloading all those images took a lot of time (they were downloaded sequentially on the server). PHP is famously single-threaded, and my web host limited how long PHP scripts could run, limiting the maximum number of supported grabbers.

The back-end of QRSS Plus was redesigned in 2016 when I changed hosting companies. The new company allowed me to execute python scripts on the server, so I was no longer limited by the constraints of PHP. I redesigned QRSS Plus to download, hash, and store images every 10 minutes. This allowed QRSS Plus to display a running history of the last several grabs for each grabber, as well as support automated image stacking (averaging the last several images together to improve visualization of weak, repetitive signals). This solution is still limited by CPU time (the number of CPU seconds per day is capped by my hosting company), but continuously operating QRSS Plus does not occupy a large portion of that time.

### QRSS Plus Activity in 2020

I started logging grabber updates in September 2018, allowing me to reflect on the last few years of grabber activity. It takes a lot of effort to set-up and maintain a quality QRSS grabber, and the enthusiasm and dedication of the QRSS community is impressive and inspiring! 

<div class="text-center">

![](grabbers-per-day.png)

</div>

In 2020 our community saw ***155 active grabber stations***! On average there were more than 60 active stations running on any given day, and the number of active stations is visibly increasing with time.

<div class="text-center">

![](grabs-per-day.png)

</div>

In 2020 QRSS Plus analyzed a mean of 6,041 spectrograms per day. In total, QRSS Plus analyzed over ***2.2 million spectrograms*** this year!

<div class="text-center">

![](grabbers-leader.png)

</div>

This bar graph depicts the top 50 most active grabber stations ranked according to their total unique spectrogram upload count. Using this metric grabbers that update once every 10 minutes will appear to have twice as many unique grabber images as those which upload a unique image every 20 minutes.

<div class="text-center">

![](qrss-2020-pie.png)

</div>

Many QRSS grabber operators maintain multiple stations, and I think those operators deserve special attention! This year's winner for the most active contributor goes to David Hassall (WA5DJJ) who alone is responsible for 15.26% of the total number of uploaded spectrograms in 2020 🏆

The top 25 contributors with the greatest number of unique uploads in 2020 were (in order): WA5DJJ, WD4ELG, W6REK, G3VYZ, KL7L, G4IOG, W4HBK, G3YXM, HB9FXX, PA2OHH, EA8BVP, G0MQW, SA6BSS, WD4AH, 7L1RLL, VA3ROM, VE7IGH, DL4DTL, K5MO, LA5GOA, VE3GTC, AJ4VD, K4RCG, GM4SFW, and OK1FCX. 

### Maintaining QRSS Plus

I want to recognize Andy (G0FTD) for doing an extraordinary job maintaining the QRSS Plus website over the last several years! Although I (AJ4VD) created and maintain the QRSS Plus back-end, once it is set-up it largely operates itself. The QRSS grabber list, on the other hand, requires frequent curation. Andy has done a fantastic job monitoring the [QRSS Knights mailing list](https://groups.io/g/qrssknights) and updating the grabber list in response to updates posted there so it always contains the newest grabbers and uses the latest URLs. On behalf of everyone who enjoys using QRSS Plus, thank you for your work Andy!

### The Future of QRSS Plus

Today QRSS Plus is functional, but I think its front-end could be greatly improved. It is written using vanilla JavaScript, but I think moving to a front-end framework like React makes a lot of sense. Currently PHP generates HTML containing grabber data when the page is requested, but a public JSON API would make a lot of sense and make QRSS Plus it easier to develop and test. From a UX standpoint, the front-end could benefit from a simpler design that displays well on mobile and desktop browsers. I think the usability of historical grabs could be greatly improved as well. From a back-end perspective, I'd much prefer to run the application using a service like Azure or AWS rather than lean on a traditional personal website hosting plan to manage the downloads and image processing. Automatic creation of 8-hour (stitched and compressed) grabber frames seems feasible as well. It is unlikely I will work toward these improvements soon, but if you are a front-end web developer interested in working on a public open-source project, send me an email and I'd be happy to discuss how we can improve QRSS Plus together!

QRSS is a growing hobby, and if the rise in grabbers over the last few years is an indication of what the next few years will look like, I'm excited to see where the hobby continues to go! I encourage you to consider running a grabber (and to encourage others to do the same), and to continue to thank all the grabber operators and maintainers out there who make this hobby possible.

### Notes and Resources
* Data includes Jan 1 2020 through Dec 11 2020
* Stations with <1000 unique uploads were excluded from most analyses
* Summary data (a table of unique images per day per station) is available: [qrss-plus-2020.xlsx](qrss-plus-2020.xlsx)
* Bar graphs, scatter plots, and line charts were created with [ScottPlot](https://swharden.com/scottplot)
* QRSS Plus is [open source on GitHub](https://github.com/swharden/qrssplus)
* A modern introduction to QRSS: [The New Age of QRSS](https://swharden.com/blog/2020-10-03-new-age-of-qrss)
* [FSKview](https://swharden.com/software/FSKview) is a new QRSS and WSPR Spectrogram Viewer for Windows

The New Age of QRSS

QRSS is an experimental radio mode that uses frequency-shift-keyed (FSK) continuous wave (CW) Morse code to transmit messages that can be decoded visually by inspecting the radio frequency spectrogram. The name "QRSS" is a derivation of the Q code "QRS", a phrase Morse code operators send to indicate the transmitter needs to slow down. The extra "S" means slow way, way down, and at the typical speed of 6 second dots and 18 second dashes most QRSS operators have just enough time to send their call sign once every ten minutes (as required by federal law). These slow Morse code messages can be decoded by visual inspection of spectrograms created by computer software processing the received audio. A QRSS grabber is a radio/computer setup configured to upload the latest radio spectrogram to the internet every 10 minutes. QRSS Plus is an automatically-updating list of active QRSS grabbers around the world, allowing the QRSS community to see QRSS transmitters being detected all over the world.

TLDR: Get Started with QRSS

  • Tune your radio to 10.140 MHz (10.1387 MHz USB)
  • Install spectrogram software like FSKview
  • Inspect the spectrogram to decode callsigns visually
  • Join the QRSS Knights mailing list to learn what's new
  • Go to QRSS Plus to see QRSS signals around the world
  • Design and build a circuit (or buy a kit) to transmit QRSS

What is QRSS?

QRSS allows miniscule amounts of power to send messages enormous distances. For example, 200 mW QRSS transmitters are routinely spotted on QRSS grabbers thousands of miles away. The key to this resilience lies in the fact that spectrograms can be designed which average several seconds of audio into each pixel. By averaging audio in this way, the level of the noise (which is random and averages toward zero) falls below the level of the signal, allowing visualization of signals on the spectrogram which are too deep in the noise to be heard by ear.

If you have a radio and a computer, you can view QRSS! Connect your radio to your computer's microphone, then run a spectrogram like FSKview to visualize that audio as a spectrogram. The most QRSS activity is on 30m within 100 Hz of 10.140 MHz, so set your radio to upper sideband (USB) mode and tune to 10.1387 MHz so QRSS audio will be captured as 1.4 kHz audio tones.

FSKview is radio frequency spectrogram software for viewing QRSS and WSPR simultaneously. I wrote FSKview to be simple and easy to use, but it's worth noting that Spectrum Lab, Argo, LOPORA, and QRSSpig are also popular spectrogram software projects used for QRSS, with the last two supporting Linux and suitable for use on the Raspberry Pi.

QRSS Transmitter Design

QRSS transmitters can be extraordinarily simple because they just transmit a single tone which shifts between two frequencies. The simplicity of QRSS transmitters makes them easy to assemble as a kits, or inexpensively designed and built by those first learning about RF circuit design. The simplest designs use a crystal oscillator (typically a Colpitts configuration) followed by a buffer stage and a final amplifier (often Class C configuration using a 2N7000 N-channel MOSFET or 2N2222 NPN transistor). Manual frequency adjustments are achieved using a variable capacitor, supplemented in this case with twisted wire to act as a simple but effective variable capacitor for fine frequency tuning within the 100 Hz QRSS band. Frequency shift keying to transmit call signs is typically achieved using a microcontroller to adjust voltage on a reverse-biased diode (acting as a varactor) to modulate capacitance and shift resonant frequency of the oscillator. Following a low-pass filter (typically a 3-pole Chebyshev design) the signal is then sent to an antenna.

QRP Labs is a great source for QRSS kits. The kit pictured above and below is one of their earliest kits (the 30/40/80/160m QRSS Kit), but they have created many impressive new products in the last several years. Some of their more advanced QRSS kits leverage things like direct digital synthesis (DDS), GPS time synchronization, and the ability to transmit additional digital modes like Hellschreiber and WSPR.

Radio Frequency Spectral Phenomena

Atmospheric phenomena and other special conditions can often be spotted in QRSS spectrograms. One of the most common special cases are radio frequency reflections off of airplanes resulting in the radio waves arriving at the receiver simultaneously via two different paths (a form of multipath propagation). Due to the Doppler shift from the airplane approaching the receiver the signal from the reflected path appears higher frequency than the direct path, and as the airplane flies over and begins heading away the signal from the reflected path decreases in frequency relative to the signal of the direct path. The image below is one of my favorites, captured by Andy (G0FTD) in the 10m QRSS band. QRSS de W4HBK is a website that has many blog posts about rare and special grabs, demonstrating effects of meteors and coronal mass ejections on QRSS signals.

QRSS Transmitters are Not Beacons

Radio beacons send continuous, automated, unattended, one-way transmissions without specific reception targets. In contrast, QRSS transmitters are only intended to be transmitting when the control operator is available to control them, and the recipients are known QRSS grabbers around the world. To highlight the distinction from radio beacons, QRSS transmitters are termed Manned Experimental Propagation Transmitters (MEPTs). Users in the United States will recall that the FCC (in Part 97.203) confines operation of radio beacons to specific regions of the radio spectrum and disallows operation of beacons below 28 MHz. Note that amateur radio beacons typically operate up to 100 W which is a power level multiple orders of magnitude greater than QRSS transmitters. MEPTs, in contrast, can transmit in any portion of the radio frequency spectrum where CW operation is permitted.

The New Age of QRSS

QRSS was first mentioned in epsisode 28 of The Soldersmoke Podcast on July 30, 2006. It was discussed in several episodes over the next few years, and a 2009 post about QRSS on Hack-A-Day brought it to my attention. In the early days of QRSS the only way to transmit QRSS was to design and build your own transmitter. David Hassall (WA5DJJ), Bill Houghton (W4HBK), Hans Summers (G0UPL), and others would post their designs on their personal websites along with notes about where their transmitters had been spotted. In the following years the act of creating QRSS grabbers became streamlined, and websites like I2NDT's QRSS Grabber Compendium and QRSS Plus made it easier to see QRSS signals around the world. Hans Summers (G0UPL) began selling QRSS transmitter kits at amateur radio conventions, then later through the QRP Labs website. As more people started selling and buying kits (and documenting their experiences) it became easier and easier to get started with QRSS. Before QRSS kits were easy to obtain the only way to participate in the hobby was to design and build a transmitter from scratch, representing a high barrier to entry for those potentially interested in this fascinating hobby. Now with the availability of high quality QRSS transmitter kits and the ubiquity of internet tools and software to facilitate QRSS reception, it's easier than ever to get involved in this exciting field! For these reasons I believe we have entered into a New Age of QRSS.

QRSS Frequency Bands

This table shows the QRSS frequency range for every major amateur radio band. Primary QRSS band windows are 100-200 Hz wide and located just below the WSPR bands (so WSPR transmissions frequently appear on QRSS grabs). Experimentation is encouraged on the lower portion of the band and the upper portion is typically used for mature and stable transmitters.

Band QRSS Frequency (±100 Hz) Dial Frequency (Hz)
600m 476,100 474,200
160m 1,837,900 1,836,600
80m 3,569,900 ⭐ popular 3,568,600
60m 5,288,550 5,287,200
40m 7,039,900 ⭐ popular 7,038,600
30m 10,140,000 🌟 most popular 10,138,700
20m 14,096,900 ⭐ popular 14,095,600
17m 18,105,900 18,104,600
15m 21,095,900 21,094,600
12m 24,925,900 24,924,600
10m 28,125,700 (±200 Hz) 28,124,600
6m 50,294,300 50,293,000

⚠️ WARNING: It may not be legal for you to transmit on these frequencies. Check license requirements and regulations for your region before transmitting QRSS.

⚠️ WARNING: These frequencies sometimes change based upon community discussion. Frequency tables can be found on the Knights QRSS Wiki. Outdated or alternate frequencies include 160m (1,843,200 Hz), 80m (3,593,900 Hz), 12m (24,890,800 Hz), 10m (28,000,800 Hz and 28,322,000 ±500 Hz), and 6m (50,000,900 Hz). Experimentation on 10m is encouraged in the 100Hz above the band.

When tuning your radio your dial frequency may be lower than the QRSS frequency. If you are using upper-sideband (USB) mode, you have to tune your radio dial 1.4 kHz below the QRSS band to hear QRSS signals as a 1.4 kHz tone. Recommended dial frequencies in the table above are suitable for receiving QRSS and WSPR.

QRSS Knights

The QRSS Knights is a group of QRSS enthusiasts who coordinate events and discuss experiments over email. The group is kind and welcoming to newcomers, and those interested in learning more about QRSS are encouraged to join the mailing list.

Resources

  • This page can be found at http://swharden.com/qrss

  • QRSS Plus is an automatically-updating active QRSS grabber list

  • What is QRSS by M0AYF is a classic summary of QRSS, with many links to detailed schematics and design consideration notes. Notably the sections for receiving QRSS and transmitting QRSS are great places to learn more.

  • QRSS and You by KA7OEI is another classic summary of QRSS.

  • Weak Signal Propagation Reporter (WSPR) is a low power radio protocol that typically operates adjacent to the QRSS bands and provides automated decoding of callsign, power, and location information. Read more at http://wsprnet.org

  • The QRSS Adventure by Dave Hassall (WA5DJJ) has circuit designs and commentary spanning far back into the early days of QRSS. His 1,164,000,000 Miles per Watt Test is extraordinary!

  • QRSS de W4HBK website by Bill Houghton (W4HBK) contains many useful blog posts about advanced QRSS topics. The website also has many examples of special grabs depicting rare events and atmospheric phenomena.

  • Hans Summers' website (the founder of QRP Labs) has many excellent resources related to RF design and early work in the QRSS space.

  • Simple QRP Equipment by Onno (PA2OHH) is a collection of fantastic resources related to QRSS transmission, reception, and software design.

  • Electronics & HAM Radio Blog by Eldon Brown (WA0UWH) has many fantastic articles about QRSS. Eldon's SMT band-edge transmitter inspired me to make a SMT QRSS transmitter many years later.

  • Dave Richards, AA7EE has a fantastic website documenting many amateur radio topics including QRSS. This website has the prettiest pictures of circuit boards you'll ever see.

  • Andy, G0FTD has an excellent website with many pages about radio transmitters and QRSS including a gallery of interesting QRSS grabs

  • My QRSS Hardware GitHub page collects notes and resources related to QRSS transmitter and receiver design.

Markdown source code last modified on January 18th, 2021
---
title: The New Age of QRSS
date: 2020-10-03 22:08:00
tags: qrss, amateur radio
---

# The New Age of QRSS

**QRSS is an experimental radio mode that uses frequency-shift-keyed (FSK) continuous wave (CW) Morse code to transmit messages that can be decoded visually by inspecting the radio frequency spectrogram.** The name "QRSS" is a derivation of the [Q code](https://en.wikipedia.org/wiki/Q_code) "QRS", a phrase Morse code operators send to indicate the transmitter needs to slow down. The extra "S" means slow way, _way_ down, and at the typical speed of 6 second dots and 18 second dashes most QRSS operators have just enough time to send their call sign once every ten minutes (as required by federal law). These slow Morse code messages can be decoded by visual inspection of spectrograms created by computer software processing the received audio. A QRSS grabber is a radio/computer setup configured to upload the latest radio spectrogram to the internet every 10 minutes. [QRSS Plus](https://swharden.com/qrss/plus/) is an automatically-updating list of active QRSS grabbers around the world, allowing the QRSS community to see QRSS transmitters being detected all over the world. 

> **TLDR: Get Started with QRSS**
> * Tune your radio to 10.140 MHz (10.1387 MHz USB)
> * Install spectrogram software like [FSKview](https://swharden.com/software/FSKview)
> * Inspect the spectrogram to decode callsigns visually
> * Join the [QRSS Knights](https://groups.io/g/qrssknights) mailing list to learn what's new
> * Go to [QRSS Plus](https://swharden.com/qrss/plus/) to see QRSS signals around the world
> * Design and build a circuit (or [buy a kit](https://www.qrp-labs.com/)) to transmit QRSS

## What is QRSS?

**QRSS allows miniscule amounts of power to send messages enormous distances.** For example, 200 mW QRSS transmitters are routinely spotted on QRSS grabbers thousands of miles away. The key to this resilience lies in the fact that spectrograms can be designed which average several seconds of audio into each pixel. By averaging audio in this way, the level of the noise (which is random and averages toward zero) falls below the level of the signal, allowing visualization of signals on the spectrogram which are too deep in the noise to be heard by ear.

<div class="text-center img-border">

![](lopora-signals2.jpg)

</div>

**If you have a radio and a computer, you can view QRSS!** Connect your radio to your computer's microphone, then run a spectrogram like [FSKview](https://swharden.com/software/FSKview/) to visualize that audio as a spectrogram. The most QRSS activity is on 30m within 100 Hz of 10.140 MHz, so set your radio to upper sideband (USB) mode and tune to 10.1387 MHz so QRSS audio will be captured as 1.4 kHz audio tones. 

**[FSKview](https://swharden.com/software/FSKview/) is radio frequency spectrogram software for viewing QRSS and WSPR simultaneously.** I wrote [FSKview](https://swharden.com/software/FSKview/) to be simple and easy to use, but it's worth noting that [Spectrum Lab](https://www.qsl.net/dl4yhf/spectra1.html),  [Argo](https://digilander.libero.it/i2phd/argo/), [LOPORA](https://www.qsl.net/pa2ohh/11lop.htm), and [QRSSpig](https://gitlab.com/hb9fxx/qrsspig) are also popular spectrogram software projects used for QRSS, with the last two supporting Linux and suitable for use on the Raspberry Pi.

<div class="text-center">

![](fskview.png)

</div>

## QRSS Transmitter Design

**QRSS transmitters can be extraordinarily simple because they just transmit a single tone which shifts between two frequencies.** The simplicity of QRSS transmitters makes them easy to assemble as a kits, or inexpensively designed and built by those first learning about RF circuit design. The simplest designs use a crystal oscillator (typically a [Colpitts](https://en.wikipedia.org/wiki/Colpitts_oscillator) configuration) followed by a buffer stage and a final amplifier (often [Class C](https://en.wikipedia.org/wiki/Power_amplifier_classes#Class_C) configuration using a 2N7000 N-channel MOSFET or 2N2222 NPN transistor). Manual frequency adjustments are achieved using a variable capacitor, supplemented in this case with twisted wire to act as a simple but effective variable capacitor for fine frequency tuning within the 100 Hz QRSS band. Frequency shift keying to transmit call signs is typically achieved using a microcontroller to adjust voltage on a reverse-biased diode (acting as a [varactor](https://en.wikipedia.org/wiki/Varicap)) to modulate capacitance and shift resonant frequency of the oscillator. Following a low-pass filter (typically a 3-pole [Chebyshev](https://en.wikipedia.org/wiki/Chebyshev_filter) design) the signal is then sent to an antenna.

<div class="text-center img-medium">

![](qrp-labs-kit-schematic.jpg)

</div>

**[QRP Labs](https://www.qrp-labs.com/) is a great source for QRSS kits.** The kit pictured above and below is one of their earliest kits (the 30/40/80/160m QRSS Kit), but they have created many impressive new products in the last several years. Some of their more advanced QRSS kits leverage things like direct digital synthesis (DDS), GPS time synchronization, and the ability to transmit additional digital modes like Hellschreiber and WSPR.

<div class="text-center img-border img-medium">

![](qrp-labs-kit-photo.jpg)

</div>

## Radio Frequency Spectral Phenomena

**Atmospheric phenomena and other special conditions can often be spotted in QRSS spectrograms**. One of the most common special cases are radio frequency reflections off of airplanes resulting in the radio waves arriving at the receiver simultaneously via two different paths (a form of [multipath propagation](https://en.wikipedia.org/wiki/Multipath_propagation)). Due to the Doppler shift from the airplane approaching the receiver the signal from the reflected path appears higher frequency than the direct path, and as the airplane flies over and begins heading away the signal from the reflected path decreases in frequency relative to the signal of the direct path. The image below is one of my favorites, captured by [Andy (G0FTD)](https://sites.google.com/view/andy-g0ftd/the-qrss-gallery) in the 10m QRSS band. [QRSS de W4HBK](http://pensacolasnapper.blogspot.com/) is a website that has many blog posts about rare and special grabs, demonstrating effects of meteors and coronal mass ejections on QRSS signals.

<div class="text-center img-medium">

![](rf-reflection-airplane.png)

</div>

<div class="text-center img-medium img-border">

![](rf-reflection-airplane.jpg)

</div>

## QRSS Transmitters are Not Beacons

Radio beacons send continuous, automated, unattended, one-way transmissions without specific reception targets. In contrast, QRSS transmitters are only intended to be transmitting when the control operator is available to control them, and the recipients are known QRSS grabbers around the world. To highlight the distinction from radio beacons, QRSS transmitters are termed ***Manned Experimental Propagation Transmitters (MEPTs)***. Users in the United States will recall that the FCC (in Part 97.203) confines operation of radio beacons to specific regions of the radio spectrum and disallows operation of beacons below 28 MHz. Note that amateur radio beacons typically operate up to 100 W which is a power level multiple orders of magnitude greater than QRSS transmitters. MEPTs, in contrast, can transmit in any portion of the radio frequency spectrum where CW operation is permitted.

## The New Age of QRSS
**QRSS was first mentioned in epsisode 28 of [The Soldersmoke Podcast](http://www.soldersmoke.com/) on July 30, 2006.** It was discussed in several episodes over the next few years, and a 2009 [post about QRSS](https://hackaday.com/2009/02/22/qrss-radio-amateurs-slow-speed-narrowband/) on Hack-A-Day brought it to my attention. In the early days of QRSS the only way to transmit QRSS was to design and build your own transmitter. [David Hassall (WA5DJJ)](http://www.zianet.com/dhassall/QRSS_A.html), [Bill Houghton (W4HBK)](http://pensacolasnapper.blogspot.com/), [Hans Summers (G0UPL)](http://www.hanssummers.com/), and others would post their designs on their personal websites along with notes about where their transmitters had been spotted. In the following years the act of creating QRSS grabbers became streamlined, and websites like I2NDT's [QRSS Grabber Compendium](https://digilander.libero.it/i2ndt/grabber/grabber-compendium.htm) and [QRSS Plus](https://swharden.com/qrss/plus/) made it easier to see QRSS signals around the world. [Hans Summers](http://www.hanssummers.com/) (G0UPL) began selling QRSS transmitter kits at amateur radio conventions, then later through the [QRP Labs website](https://www.qrp-labs.com/). As more people started selling and buying kits (and documenting their experiences) it became easier and easier to get started with QRSS. Before QRSS kits were easy to obtain the only way to participate in the hobby was to design and build a transmitter from scratch, representing a high barrier to entry for those potentially interested in this fascinating hobby. Now with the availability of high quality QRSS transmitter kits and the ubiquity of internet tools and software to facilitate QRSS reception, it's easier than ever to get involved in this exciting field! For these reasons I believe we have entered into a _New Age of QRSS_.

## QRSS Frequency Bands

**This table shows the QRSS frequency range for every major amateur radio band.** Primary QRSS band windows are 100-200 Hz wide and located just below the [WSPR](http://wsprnet.org/) bands (so WSPR transmissions frequently appear on QRSS grabs). Experimentation is encouraged on the lower portion of the band and the upper portion is typically used for mature and stable transmitters.

<div class="text-center">

Band | QRSS Frequency (±100 Hz)     | Dial Frequency (Hz)
-----|------------------------------|-----------------------
600m | 476,100						| 474,200
160m | 1,837,900					| 1,836,600
80m  | 3,569,900 ⭐ _popular_		| 3,568,600
60m  | 5,288,550					| 5,287,200
40m  | 7,039,900 ⭐ _popular_		| 7,038,600
30m  | 10,140,000 🌟 _most popular_	| 10,138,700
20m  | 14,096,900 ⭐ _popular_		| 14,095,600
17m  | 18,105,900					| 18,104,600
15m  | 21,095,900					| 21,094,600
12m  | 24,925,900					| 24,924,600
10m  | 28,125,700 (±200 Hz)			| 28,124,600
6m   | 50,294,300					| 50,293,000

</div>

> **⚠️ WARNING:** It may not be legal for you to transmit on these frequencies. Check license requirements and regulations for your region before transmitting QRSS.

> **⚠️ WARNING:** These frequencies sometimes change based upon community discussion. Frequency tables can be found on the [Knights QRSS Wiki](https://groups.io/g/qrssknights/wiki/3964). Outdated or alternate frequencies include 160m (1,843,200 Hz), 80m (3,593,900 Hz), 12m (24,890,800 Hz), 10m (28,000,800 Hz and 28,322,000 ±500 Hz), and 6m (50,000,900 Hz). Experimentation on 10m is encouraged in the 100Hz above the band.

**When tuning your radio your dial frequency may be lower than the QRSS frequency.** If you are using upper-sideband (USB) mode, you have to tune your radio dial 1.4 kHz _below_ the QRSS band to hear QRSS signals as a 1.4 kHz tone. Recommended dial frequencies in the table above are suitable for receiving QRSS and WSPR.

## QRSS Knights

**The [QRSS Knights](https://groups.io/g/qrssknights) is a group of QRSS enthusiasts** who coordinate events and discuss experiments over email. The group is kind and welcoming to newcomers, and those interested in learning more about QRSS are encouraged to join the mailing list.

## Resources

* This page can be found at http://swharden.com/qrss

* [QRSS Plus](https://swharden.com/qrss/plus/) is an automatically-updating active QRSS grabber list

* [What is QRSS](https://www.qsl.net/m0ayf/What-is-QRSS.html) by M0AYF is a classic summary of QRSS, with many links to detailed schematics and design consideration notes. Notably the sections for [receiving QRSS](https://www.qsl.net/m0ayf/Receiving-QRSS.html) and [transmitting QRSS](https://www.qsl.net/m0ayf/Transmitting-QRSS.html) are great places to learn more.

* [QRSS and You](http://www.ka7oei.com/qrss1.html) by KA7OEI is another classic summary of QRSS.

* Weak Signal Propagation Reporter (WSPR) is a low power radio protocol that typically operates adjacent to the QRSS bands and provides automated decoding of callsign, power, and location information. Read more at http://wsprnet.org

* [The QRSS Adventure](http://www.zianet.com/dhassall/QRSS_A.html) by Dave Hassall (WA5DJJ) has circuit designs and commentary spanning far back into the early days of QRSS. His [ 1,164,000,000 Miles per Watt Test](http://www.zianet.com/dhassall/BILLIONMPW.html) is extraordinary!

* [QRSS de W4HBK](http://pensacolasnapper.blogspot.com/) website by Bill Houghton (W4HBK) contains many useful blog posts about advanced QRSS topics. The website also has many examples of special grabs depicting rare events and atmospheric phenomena.

* [Hans Summers' website](http://www.hanssummers.com/) (the founder of [QRP Labs](https://www.qrp-labs.com/)) has many excellent resources related to RF design and early work in the QRSS space.

* [Simple QRP Equipment](https://www.qsl.net/pa2ohh/) by Onno  (PA2OHH) is a collection of fantastic resources related to QRSS transmission, reception, and software design.

* [Electronics & HAM Radio Blog](http://wa0uwh.blogspot.com/) by Eldon Brown (WA0UWH) has many fantastic articles about QRSS. Eldon's SMT band-edge transmitter inspired me to make a SMT QRSS transmitter many years later.

* [Dave Richards, AA7EE](https://aa7ee.wordpress.com/) has a fantastic website documenting many amateur radio topics including QRSS. This website has the prettiest pictures of circuit boards you'll ever see.

* [Andy, G0FTD](https://sites.google.com/view/andy-g0ftd/home) has an excellent website with many pages about radio transmitters and QRSS including a [gallery of interesting QRSS grabs](https://sites.google.com/view/andy-g0ftd/the-qrss-gallery)

* My [QRSS Hardware](https://github.com/swharden/QRSS-hardware) GitHub page collects notes and resources related to QRSS transmitter and receiver design.

<div class="text-center img-border">

![](smt-qrss.jpg)

</div>

VHF Frequency Counter with PC Interface

Projects I build often involve frequency synthesis, and one of the most useful tools to have around is a good frequency counter. I love the idea of being able to access / log / analyze frequency readings on my computer. Commercial frequency counters can be large, expensive, and their calibration is a chicken-and-egg problem (you need a calibrated frequency counter to calibrate a frequency reference you use to calibrate a frequency counter!). For about the cost of a latte I made a surprisingly good frequency frequency counter (which directly counts >100 MHz without dividing-down the input signal) by blending a SN74LV8154 dual 16-bit counter (which can double as a 32-bit counter, $1.04 on mouser) and an ATMega328 microcontroller ($3.37 on Mouser).

Although these two chips are all you need to count something, the accuracy of your counts depend on your gate. If you can generate a signal of 1 pulse per second (1PPS), you can count anything, but your accuracy depends on the accuracy of your 1PPS signal. To eliminate the need for calibration (and to provide the 1PPS signal with the accuracy of an atomic clock) I'm utilizing the 1PPS signal originating from a GPS unit which I already had distributed throughout my shack (using a 74HC240 IC as a line driver). If you don't have a GPS unit, consider getting one! I'm using a NEO-6M module ($17.66 on Amazon) to generate the 1PPS gate, and if you include its cost we're up to $22.07. Also, all of the code for this project (schematics, C that runs on the microcontroller, and a Python to interact with the serial port) is shared on GitHub! You may be wondering, "why do GPS units have incredibly accurate 1PPS signals?" It's a good question, but a subject for another day. For now, trust me when I say they're fantastically accurate (but slightly less precise due to jitter) if you're interested in learning more read up on GPS timing.

This is the general idea behind how this frequency counter works. It's so simple! It's entirely digital, and needs very few passive components. sn74lv8154 is configured in 32-bit mode (by chaining together its two 16-bit counters, see the datasheet for details) and acts as the front-end directly taking in the measured frequency. This chip is "rare" in the sense I find very few internet projects using it, and they're not available on ebay. However they're cheap and plentiful on mouser, so I highly encourage others to look into using it! The datasheet isn’t very clear about its maximum frequency, but in my own tests I was able to measure in excess of 100 MHz from a breadboarded circuit! This utilized two cascaded ICS501 PLL frequency multiplier ICs to multiply a signal I had available (the 11.0592 MHz crystal the MCU was running from) by ten, yielding 110 MHz, which it was able to measure (screenshot is down on the page).

The 1PPS gate signal is generated from an inexpensive GPS module available on Amazon. I've hinted at the construction of this device before and made a post about how to send output signals like the 1PPS signal generated here throughout your shack via coax using a line driver, so I won't re-hash all of those details here. I will say that this module has only VCC, GND, and TX/RX pins, so to get access to the 1PPS signal you have to desolder the SMT LED and solder a wire to its pad. It requires a bit of finesse. If you look closely, you can see it in this picture (purple wire).

I first built this device on a breadboard, and despite the rats nest of wires it worked great! Look closely and you can see the ICS501 frequency multiplier ICs I wrote about before. In this case it's measuring the 10x multiplied crystal frequency clocking the MCU (11 MHz -> 110 MHz) and reporting these readings every 1 second to the computer via a serial interface.

Frequency measurements of the VHF signal are reported once per second. Measurements are transmitted through a USB serial adapter, and captured by a Python script. Note that I'm calling this signal VHF because it's >30 MHz. I am unsure if this device will work up to 300 MHz (the border between VHF and UHF), but I look forward to testing that out! Each line contains two numbers: the actual count of the counter (which is configured to simply count continuously and overflow at 2^32=4,294,967,296), and the gated count (calculated by the microcontroller) which is the actual frequency in Hz.

This screenshot shows that my ~11.05 MHz crystal is actually running at 11,061,669.4 Hz. See how I capture the 0.4 Hz unit at the end? That level of precision is the advantage of using this VHF-capable counter in conjunction with a 10x frequency multiplier!

Once I confirmed everything was working, I built this device in a nice enclosure. I definitely splurge every few months and buy extruded split body aluminum enclosures in bulk (ebay), but they're great to have on hand because they make projects look so nice. I added some rubber feet (cabinet bumpers from Walmart), drilled holes for all the connectors with a continuous step drill bit, made a square hole for the serial port using a nibbler, and the rest is pretty self-evident. Labels are made with a DYMO LetraTag (Target) and clear labels (Target, Amazon) using a style inspired by PA2OHH. I tend to build one-off projects like this dead-bug / Manhattan style.

I super-glued a female header to the aluminum frame to make in-circuit serial programming (ICSP) easy. I can't believe I never thought to do this before! Programming (and reprogramming) was so convenient. I'm going to start doing this with every enclosed project I build from now on. FYI I'm using a USBTiny ISP ($10.99, Amazon) to do the programming (no longer the BusPirate, it's too slow) like I describe here for 64-bit Windows 7 (although I'm now using Windows 10 and it works the same).

The front of the device has LEDs indicating power, serial transmission, and gating. Without a 1PPS gate, the device is set to send a count (of 0) every 5 seconds. In this case, the TX light will illuminate. If a gate is detected, the TX and GATE LEDs will illuminate simultaneously. In reality I just drilled 3 holes when I really needed two, so I had to make-up a function for the third LED (d'oh!)

The back of the device has serial output, frequency input, gate input, and power. Inside is a LM7805 voltage regulator, and careful attention was paid to decoupling and keeping ripple out of the power supply (mostly so our gate input wouldn't be affected). I'm starting to get in the habit of labeling all serial output ports with the level (TTL vs CMOS, which makes a HUGE difference as MAX232 level converter may be needed, or a USB serial adapter which is capable of reading TTL voltages), as well as the baud rate (119200), byte size (8), parity (N), and stop bit (1). _I just realized there's a typo! The label should read 8N1. I don't feel like fixing it, so I'll use a marker to turn the 2 into an 8. _I guess I'm only human after all.

I should have tried connecting all these things before I drilled the holes. I got so lucky that everything fit, with about 2mm to spare between those BNC jacks. Phew!

This is an easy test frequency source. I have a dozen canned oscillators of various frequencies. This is actually actually a voltage controlled oscillator (VCO) with adjustment pin (not connected), and it won't be exactly 50 MHz without adjustment. It's close enough to test with though! As this is >30 MHz, we can call the signal VHF.

You can see on the screen it's having no trouble reading the ~50 MHz frequency. You'll notice I'm using RealTerm (with a good write-up on sparkfun) which is my go-to terminal program instead of HyperTerminal (which really needs to go away forever). In reviewing this photo, I'm appreciating how much unpopulated room I have on the main board. I'm half tempted to build-in a frequency multiplier circuit, and place it under control of the microcontroller such that if an input frequency from 1-20MHz is received, it will engage the 10x multiplier. That's a mod for another day though! Actually, since those chips are SMT, if I really wanted to do this I would make this whole thing a really small SMT PCB and greatly simplify construction. That sounds like a project for another day though...None

Before closing it up I added some extra ripple protection on the primary counter chip. There's a 560 uH series inductor with the power supply, followed by a 100 nF capacitor parallel with ground. I also added ferrite beads to the MCU power line and gate input line. I appreciate how the beads are unsecured and that this is a potential weakness in the construction of this device (they're heavy, so consider what would happen if you shook this enclosure). However, anything that would yank-away cables in the event of shaking the device would probably also break half the other stuff in this thing, so I think it's on par with the less-than-rugged construction used for all the other components in this device. It will live a peaceful life on my shelf. I am not concerned.

This is the final device counting frequency and continuously outputting the result to my computer. In the background you can see the 12V power supply (yellow) indicating it is drawing only 20 mA, and also the GPS unit is in a separate enclosure on the bottom right. Click here to peek inside the GPS 1PPS enclosure.

I'm already loving this new frequency counter! It's small, light, and nicely enclosed (meaning it's safe from me screwing with it too much!). I think this will prove to be a valuable piece of test equipment in my shack for years to come. I hope this build log encourages other people to consider building their own equipment. I learned a lot from this build, saved a lot of money not buying something commercial, had a great time making this device, and I have a beautiful piece of custom test equipment that does exactly what I want.

Source Code

Microcontroller code (AVR-GCC), schematics, and a Python script to interface with the serial port are all available on this project's GitHub page

Afterthought: Using without GPS

One of the great advantages of this project is that it uses GPS for an extremely accurate 1 PPS signal, but what options exist to adapt this project to not rely on GPS? The GPS unit is expensive (though still <$20) and GPS lock is not always feasible (underground, in a Faraday cage, etc). Barring fancy things like dividing-down rubidium frequency standards or oven controlled oscillators, consider having your microcontroller handle the gating using either interrupts and timers precisely configured to count seconds. Since this project uses a serial port with a 11.0592 MHz crystal, your 1PPS stability will depend on the stability of your oscillator (which is pretty good!). Perhaps more elegantly you could use a 32.768 kHz crystal oscillator to create a 1 PPS signal. This frequency can be divided by 2 over and over to yield 1 Hz perfectly. This is what most modern wristwatches do. Many AVRs have a separate oscillator which can accomodate a 32 kHz crystal and throw interrupts every 1 second without messing with the system clock. Alternatively, the 74GC4060 (a 14 stage ripple counter) can divide 32k into 1 Hz and even can be arranged as an oscillator (check the datasheet). It would be possible to have both options enabled (local clock and GPS) and only engage the local clock if the GPS signal is absent. If anyone likes the idea of this simple VHF frequency counter with PC interface but doesn't want to bother with the GPS, there are plenty of options to have something almost as accurate. That really would cut the cost of the final device down too, keeping it under the $5 mark.

Update: Integrating Counter Serial Output with GPS Serial Output

The NEO-M8 GPS module is capable of outputting serial data at 9600 baud and continuously dumps NEMA formatted GPS data. While this isn't really useful for location information (whose frequency counter requires knowing latitude and longitude?) it's great for tracking things like signal strength, fix quality, and number of satellites. After using this system to automatically log frequency of my frequency reference, I realized that sometimes I'd get 1-2 hours of really odd data (off by kHz, not just a few Hz). Power cycling the GPS receiver fixes the problem, so my guess it that it's a satellite issue. If I combine the GPS RX and counter in 1 box, I could detect this automatically and have the microcontroller power cycle the GPS receiver (or at the least illuminate a red error LED). I don't feel like running 2 USB serial adapters continuously. I don't feel like programming my AVR to listen to the output from the GPS device (although that's probably the correct way to do things). Instead I had a simpler idea that worked really well, allowing me to simultaneously log serial data from my GPS unit and microcontroller (frequency counter) using 1 USB serial adapter.

The first thing I did was open up the frequency counter and reconnect my microcontroller programmer. This is exactly what I promised myself I wouldn't do, and why I have a nice enclosure in the first place! Scott, stop fidgeting with things! The last time I screwed this enclosure together I considered adding super glue to the screw threads to make sure I didn't open it again. I'll keep my modifications brief! For now, this is a test of a concept. When it's done, I'll revert the circuitry to how it was and close it up again. I'll take what I learn and build it into future projects.

I peeked at the serial signals of both the frequency counter (yellow) and the GPS unit output (blue). To my delight, there was enough dead space that I thought I could stick both in the same signal. After a code modification, I was able to tighten it up a lot, so the frequency counter never conflicts with the GPS unit by sending data at the same time.

I had to slow the baud rate to 9600, but I programmed it to send fewer characters. This leaves an easy ~50ms padding between my frequency counter signal and the GPS signal. Time to mix the two! This takes a little thought, as I can't just connect the two wires together. Serial protocol means the lines are usually high, and only pulled down when data is being sent. I had to implement an active circuit.

Using a few components, I built an AND gate to combine signals from the two serial lines. For some reason it took some thought before I realized an AND gate was what I needed here, but it makes sense. The output is high (meaning no serial signal) only when both inputs are high (no serial signals on the input). When either signal drops low, the output drops low. This is perfect. My first thought was that I'd need a NOR gate, but an inverted AND gate is a NOR gate.

Here's my quick and dirty implementation. A reminder again is that this will be removed after this test. For now, it's good enough.

After connecting the GPS serial output and frequency counter serial output to the AND gate (which outputs to the computer), I instantly got the result I wanted!

RealTerm shows that both inputs are being received. It's a mess though. If you want to know what everything is, read up on NEMA formatted GPS data.

I whipped-up a python program to parse, display, and log key information. This display updates every 1 second. The bottom line is what is appended to the log file on ever read. It's clunky, but again this is just for testing and debugging. I am eager to let this run for as long as I can (days?) so I can track how changes in satellite signal / number / fix quality influence measured frequency.

Markdown source code last modified on January 18th, 2021
---
title: VHF Frequency Counter with PC Interface
date: 2016-09-05 17:34:44
tags: amateur radio, circuit, python, old
---

# VHF Frequency Counter with PC Interface

**Projects I build often involve frequency synthesis, and one of the most useful tools to have around is a good frequency counter.** I love the idea of being able to access / log / analyze frequency readings on my computer. Commercial frequency counters can be large, expensive, and their calibration is a chicken-and-egg problem (you need a calibrated frequency counter to calibrate a frequency reference you use to calibrate a frequency counter!). **For about the cost of a latte I made a surprisingly good frequency frequency counter (which directly counts >100 MHz without dividing-down the input signal)** by blending a SN74LV8154 dual 16-bit counter (which can double as a 32-bit counter, [$1.04 on mouser](http://www.mouser.com/Search/Refine.aspx?Keyword=sn74lv8154&Ns=Pricing%7c0&FS=True)) and an ATMega328 microcontroller ([$3.37 on Mouser](http://www.mouser.com/Semiconductors/Integrated-Circuits-ICs/Embedded-Processors-Controllers/Microcontrollers-MCU/8-bit-Microcontrollers-MCU/_/N-a86lo?P=1z0y33r&Keyword=atmega328p&Ns=Pricing%7c0&FS=True)). 

**Although these two chips are all you need to count something, the accuracy of your counts depend on your gate.** If you can generate a signal of 1 pulse per second (1PPS), you can count anything, but your accuracy depends on the accuracy of your 1PPS signal. To eliminate the need for calibration (and to provide the 1PPS signal with the accuracy of an atomic clock) I'm utilizing the 1PPS signal originating from a GPS unit which I already had distributed throughout my shack ([using a 74HC240 IC as a line driver](https://www.swharden.com/wp/2016-08-20-breadboard-line-driver-module/)). If you don't have a GPS unit, consider getting one! I'm using a NEO-6M module ([$17.66 on Amazon](https://www.amazon.com/Andoer-AeroQuad-Multirotor-Quadcopter-Aircraft/dp/B00RCP9MLY)) to generate the 1PPS gate, and if you include its cost we're up to $22.07. Also,** all of the code for this project (schematics, C that runs on the microcontroller, and a Python to interact with the serial port) is [shared on GitHub](https://github.com/swharden/AVR-projects/tree/master/ATMega328%202016-09-04%20SN74LV8154)!** You may be wondering, "why do GPS units have incredibly accurate 1PPS signals?" It's a good question, but a subject for another day. For now, trust me when I say they're fantastically accurate (but slightly less precise due to jitter) if you're interested in learning more read up on [GPS timing](https://www.u-blox.com/sites/default/files/products/documents/Timing_AppNote_%28GPS.G6-X-11007%29.pdf).

<div class="text-center">

[![](pc-frequency-counter-schem_thumb.jpg)](pc-frequency-counter-schem.png)

</div>

**This is the general idea behind how this frequency counter works.** It's so simple! It's entirely digital, and needs very few passive components. sn74lv8154 is configured in 32-bit mode (by chaining together its two 16-bit counters, [see the datasheet for details](http://www.ti.com/lit/ds/symlink/sn74lv8154.pdf)) and acts as the front-end directly taking in the measured frequency. This chip is "rare" in the sense I find very few internet projects using it, and they're not available on ebay. However they're cheap and plentiful on mouser, so I highly encourage others to look into using it! The datasheet isn’t very clear about its maximum frequency, but in my own tests I was able to measure in excess of 100 MHz from a breadboarded circuit! This utilized [two cascaded ICS501 PLL frequency multiplier ICs to multiply a signal](https://www.swharden.com/wp/2016-08-31-ics501-simple-frequency-multiplier/) I had available (the 11.0592 MHz crystal the MCU was running from) by ten, yielding 110 MHz, which it was able to measure (screenshot is down on the page).

<div class="text-center">

[![](neo-60-gps-1pps_thumb.jpg)](neo-60-gps-1pps.jpg)

</div>

**The 1PPS gate signal is generated from an inexpensive GPS module [available on Amazon](https://www.amazon.com/Andoer-AeroQuad-Multirotor-Quadcopter-Aircraft/dp/B00RCP9MLY).** I've hinted at the construction of this device before and [made a post](https://www.swharden.com/wp/2016-08-20-breadboard-line-driver-module/) about how to send output signals like the 1PPS signal generated here throughout your shack via coax using a line driver, so I won't re-hash all of those details here. I will say that this module has only VCC, GND, and TX/RX pins, so to get access to the 1PPS signal you have to desolder the SMT LED and solder a wire to its pad. It requires a bit of finesse. If you look closely, [you can see it in this picture](https://www.swharden.com/wp/2016-08-20-breadboard-line-driver-module/#jp-carousel-5918) (purple wire).

<div class="text-center img-border">

[![](IMG_8207_thumb.jpg)](IMG_8207.jpg)

</div>

**I first built this device on a breadboard, and despite the rats nest of wires it worked great!** Look closely and you can see the ICS501 frequency multiplier ICs [I wrote about before](https://www.swharden.com/wp/2016-08-31-ics501-simple-frequency-multiplier/). In this case it's measuring the 10x multiplied crystal frequency clocking the MCU (11 MHz -> 110 MHz) and reporting these readings every 1 second to the computer via a serial interface.

<div class="text-center img-border">

[![](ss_thumb.jpg)](ss.png)

</div>

**Frequency measurements of the VHF signal are reported once per second. Measurements are transmitted through a USB serial adapter, and captured by a Python script.** Note that I'm calling this signal [VHF](https://en.wikipedia.org/wiki/Very_high_frequency) because it's >30 MHz. I am unsure if this device will work up to 300 MHz (the border between VHF and UHF), but I look forward to testing that out! Each line contains two numbers: the actual count of the counter (which is configured to simply count continuously and overflow at 2^32=4,294,967,296), and the gated count (calculated by the microcontroller) which is the actual frequency in Hz.

>  This screenshot shows that my ~11.05 MHz crystal is actually running at 11,061,669.4 Hz. See how I capture the 0.4 Hz unit at the end? That level of precision is the advantage of using this VHF-capable counter in conjunction with a 10x frequency multiplier!

**Once I confirmed everything was working, I built this device in a nice enclosure.** I definitely splurge every few months and buy extruded split body aluminum enclosures in bulk ([ebay](http://www.ebay.com/sch/i.html?_nkw=extruded+split+body+aluminum+enclosure)), but they're great to have on hand because they make projects look so nice. I added some rubber feet (cabinet bumpers from Walmart), drilled holes for all the connectors with a continuous step drill bit, made a square hole for the serial port using a [nibbler](https://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dtools&field-keywords=Nickel+Plated+Nibbling+Tool), and the rest is pretty self-evident. Labels are made with a DYMO LetraTag (Target) and clear labels (Target, Amazon) using a style [inspired by PA2OHH](http://www.qsl.net/pa2ohh/tlabels.htm). I tend to build one-off projects like this dead-bug / Manhattan style.

<div class="text-center img-border">

[![](IMG_8277_thumb.jpg)](IMG_8277.jpg)
[![](IMG_8282_thumb.jpg)](IMG_8282.jpg)

</div>

**I super-glued a female header to the aluminum frame to make in-circuit serial programming (ICSP) easy.** I can't believe I never thought to do this before! Programming (and reprogramming) was so convenient. I'm going to start doing this with every enclosed project I build from now on. FYI I'm using a USBTiny ISP ([$10.99, Amazon](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=usbtiny+isp)) to do the programming (no longer the BusPirate, it's too slow) [like I describe here for 64-bit Windows 7](https://www.swharden.com/wp/2013-05-07-avr-programming-in-64-bit-windows-7/) (although I'm now using Windows 10 and it works the same).

<div class="text-center img-border">

[![](IMG_8330_thumb.jpg)](IMG_8330.jpg)

</div>

**The front of the device** has LEDs indicating power, serial transmission, and gating. Without a 1PPS gate, the device is set to send a count (of 0) every 5 seconds. In this case, the TX light will illuminate. If a gate is detected, the TX and GATE LEDs will illuminate simultaneously. In reality I just drilled 3 holes when I really needed two, so I had to make-up a function for the third LED (d'oh!)

<div class="text-center img-border">

[![](IMG_8286_thumb.jpg)](IMG_8286.jpg)

</div>

**The back of the device** has serial output, frequency input, gate input, and power. Inside is a LM7805 voltage regulator, and careful attention was paid to decoupling and keeping ripple out of the power supply (mostly so our gate input wouldn't be affected). I'm starting to get in the habit of labeling all serial output ports with the level (TTL vs CMOS, which makes a HUGE difference as MAX232 level converter may be needed, or a USB serial adapter which is capable of reading TTL voltages), as well as the baud rate (119200), byte size (8), parity (N), and stop bit (1). _I just realized there's a typo! The label should read 8N1. I don't feel like fixing it, so I'll use a marker to turn the 2 into an 8. _I guess I'm only human after all.

<div class="text-center img-border">

[![](IMG_8297_thumb.jpg)](IMG_8297.jpg)

</div>

**I should have tried connecting all these things before I drilled the holes.** I got _so_ lucky that everything fit, with about 2mm to spare between those BNC jacks. Phew!

<div class="text-center img-border">

[![](IMG_8316_thumb.jpg)](IMG_8316.jpg)

</div>

**This is an easy test frequency source.** I have a dozen [canned oscillators](https://en.wikipedia.org/wiki/Crystal_oscillator) of various frequencies. This is actually actually a voltage controlled oscillator ([VCO](https://en.wikipedia.org/wiki/Voltage-controlled_oscillator)) with adjustment pin (not connected), and it won't be exactly 50 MHz without adjustment. It's close enough to test with though! As this is >30 MHz, we can call the signal [VHF](https://en.wikipedia.org/wiki/Very_high_frequency).

<div class="text-center img-border">

[![](IMG_8318_thumb.jpg)](IMG_8318.jpg)

</div>

**You can see on the screen it's having no trouble reading the ~50 MHz frequency.** You'll notice I'm using [RealTerm](http://realterm.sourceforge.net/) (with a [good write-up on sparkfun](https://learn.sparkfun.com/tutorials/terminal-basics/real-term-windows)) which is my go-to terminal program instead of HyperTerminal (which really needs to go away forever). In reviewing this photo, I'm appreciating how much unpopulated room I have on the main board. I'm half tempted to build-in a frequency multiplier circuit, and place it under control of the microcontroller such that if an input frequency from 1-20MHz is received, it will engage the 10x multiplier. That's a mod for another day though! Actually, since those chips are SMT, if I really wanted to do this I would make this whole thing a really small SMT PCB and greatly simplify construction. That sounds like a project for another day though...[None](https://www.swharden.com/wp/wp-content/uploads/2016/09/IMG_8316.jpg)

<div class="text-center img-border">

[![](IMG_8335_thumb.jpg)](IMG_8335.jpg)

</div>

**Before closing it up I added some extra ripple protection on the primary counter chip.** There's a 560 uH series inductor with the power supply, followed by a 100 nF capacitor parallel with ground. I also added [ferrite beads](https://en.wikipedia.org/wiki/Ferrite_bead) to the MCU power line and gate input line. I appreciate how the beads are unsecured and that this is a potential weakness in the construction of this device (they're heavy, so consider what would happen if you shook this enclosure). However, anything that would yank-away cables in the event of shaking the device would probably also break half the other stuff in this thing, so I think it's on par with the less-than-rugged construction used for all the other components in this device. It will live a peaceful life on my shelf. I am not concerned.

<div class="text-center img-border">

[![](IMG_8335_thumb.jpg)](IMG_8335.jpg)

</div>

**This is the final device counting frequency and continuously outputting the result to my computer.** In the background you can see the 12V power supply (yellow) indicating it is drawing only 20 mA, and also the GPS unit is in a separate enclosure on the bottom right. [Click here to peek inside](https://www.swharden.com/wp/2016-08-20-breadboard-line-driver-module/#jp-carousel-5918) the GPS 1PPS enclosure.

<div class="text-center img-border">

[![](IMG_8344_thumb.jpg)](IMG_8344.jpg)

</div>

**I'm already loving this new frequency counter!** It's small, light, and nicely enclosed (meaning it's safe from me screwing with it too much!). I think this will prove to be a valuable piece of test equipment in my shack for years to come. I hope this build log encourages other people to consider building their own equipment. I learned a lot from this build, saved a lot of money not buying something commercial, had a great time making this device, and I have a beautiful piece of custom test equipment that does _exactly_ what I want.

## Source Code

Microcontroller code (AVR-GCC), schematics, and a Python script to interface with the serial port are all available on [this project's GitHub page](https://github.com/swharden/AVR-projects/blob/master/ATMega328%202016-09-04%20SN74LV8154/main.c)

## Afterthought: Using without GPS

One of the great advantages of this project is that it uses GPS for an extremely accurate 1 PPS signal, but what options exist to adapt this project to not rely on GPS? The GPS unit is expensive (though still <$20) and GPS lock is not always feasible (underground, in a Faraday cage, etc). Barring fancy things like dividing-down rubidium frequency standards or oven controlled oscillators, consider having your microcontroller handle the gating using either [interrupts and timers precisely configured to count seconds](https://www.swharden.com/wp/2011-06-19-using-timers-and-counters-to-clock-seconds/). Since this project uses a serial port with a 11.0592 MHz crystal, your 1PPS stability will depend on the stability of your oscillator (which is pretty good!). Perhaps more elegantly you could use a 32.768 kHz crystal oscillator to create a 1 PPS signal. This frequency can be divided by 2 over and over to yield 1 Hz perfectly. This is what most modern wristwatches do. Many AVRs have a separate oscillator which can accomodate a 32 kHz crystal and throw interrupts every 1 second without messing with the system clock. Alternatively, the [74GC4060](http://www.nxp.com/documents/data_sheet/74HC_HCT4060_Q100.pdf) (a 14 stage ripple counter) can divide 32k into 1 Hz and even can be arranged as an oscillator (check the datasheet). It would be possible to have both options enabled (local clock and GPS) and only engage the local clock if the GPS signal is absent. If anyone likes the idea of this simple VHF frequency counter with PC interface but doesn't want to bother with the GPS, there are plenty of options to have something _almost_ as accurate. That really would cut the cost of the final device down too, keeping it under the $5 mark.

## Update: Integrating Counter Serial Output with GPS Serial Output

The NEO-M8 GPS module is [capable of outputting serial data](https://www.u-blox.com/sites/default/files/NEO-M8_DataSheet_(UBX-13003366).pdf) at 9600 baud and continuously dumps [NEMA formatted](http://www.gpsinformation.org/dale/nmea.htm) GPS data. While this isn't really useful for location information (whose frequency counter requires knowing latitude and longitude?) it's great for tracking things like signal strength, fix quality, and number of satellites. After using this system to automatically log frequency of my frequency reference, I realized that sometimes I'd get 1-2 hours of really odd data (off by kHz, not just a few Hz). Power cycling the GPS receiver fixes the problem, so my guess it that it's a satellite issue. If I combine the GPS RX and counter in 1 box, I could detect this automatically and have the microcontroller power cycle the GPS receiver (or at the least illuminate a red error LED). I don't feel like running 2 USB serial adapters continuously. I don't feel like programming my AVR to listen to the output from the GPS device (although that's probably the _correct_ way to do things).  Instead I had a simpler idea that worked really well, allowing me to simultaneously log serial data from my GPS unit and microcontroller (frequency counter) using 1 USB serial adapter.

<div class="text-center img-border">

[![](IMG_8401_thumb.jpg)](IMG_8401.jpg)

</div>

**The first thing I did was open up the frequency counter and reconnect my microcontroller programmer.** This is exactly what I promised myself I wouldn't do, and why I have a nice enclosure in the first place! Scott, stop fidgeting with things! The last time I screwed this enclosure together I considered adding super glue to the screw threads to make sure I didn't open it again. I'll keep my modifications brief! For now, this is a test of a concept. When it's done, I'll revert the circuitry to how it was and close it up again. I'll take what I learn and build it into future projects.

<div class="text-center img-border">

[![](IMG_8402_thumb.jpg)](IMG_8402.jpg)

</div>

**I peeked at the serial signals of both the frequency counter (yellow) and the GPS unit output (blue).** To my delight, there was enough dead space that I thought I could stick both in the same signal. After a code modification, I was able to tighten it up a lot, so the frequency counter never conflicts with the GPS unit by sending data at the same time.

<div class="text-center img-border">

[![](IMG_8403_thumb.jpg)](IMG_8403.jpg)

</div>

**I had to slow the baud rate to 9600, but I programmed it to send fewer characters.** This leaves an easy ~50ms padding between my frequency counter signal and the GPS signal. Time to mix the two! This takes a little thought, as I can't just connect the two wires together. Serial protocol means the lines are usually high, and only pulled down when data is being sent. I had to implement an active circuit.

<div class="text-center img-border img-small">

[![](FullSizeRender-2_thumb.jpg)](FullSizeRender-2.jpg)

</div>

**Using a few components, I built an AND gate to combine signals from the two serial lines.** For some reason it took some thought before I realized an AND gate was what I needed here, but it makes sense. The output is high (meaning no serial signal) only when both inputs are high (no serial signals on the input). When either signal drops low, the output drops low. This is perfect. My first thought was that I'd need a NOR gate, but an inverted AND gate _is_ a NOR gate.

<div class="text-center img-border">

[![](IMG_8404_thumb.jpg)](IMG_8404.jpg)

</div>

**Here's my quick and dirty implementation.** A reminder again is that this will be removed after this test. For now, it's good enough.

<div class="text-center img-border">

[![](IMG_8405_thumb.jpg)](IMG_8405.jpg)

</div>

**After connecting** the GPS serial output and frequency counter serial output to the AND gate (which outputs to the computer), I instantly got the result I wanted!

<div class="text-center img-border">

![](serial-combine.jpg)

</div>

**RealTerm shows that both inputs are being received.** It's a mess though. If you want to know what everything is, read up on [NEMA formatted](http://www.gpsinformation.org/dale/nmea.htm) GPS data.

<div class="text-center img-border">

[![](combined-python_thumb.jpg)](combined-python.png)

</div>

**I whipped-up a python program to parse, display, and log key information.** This display updates every 1 second. The bottom line is what is appended to the log file on ever read. It's clunky, but again this is just for testing and debugging. I am eager to let this run for as long as I can (days?) so I can track how changes in satellite signal / number / fix quality influence measured frequency.

High School Students' High Altitude Balloon #2

Last year a group of high school students, in collaboration with a seminar course on Space Systems sponsored by the University of Florida's Student Science Training Program (SSTP), gained some real-world experience planning, building, and launching a research payload to the edge of space – all in a couple weeks! Last year's high altitude balloon launch was covered on my website, and the radio transmitter I built for it was featured on this Hack-A-Day post. Unlike last year's payload, whose only homebrew device was the radio transmitter, this year's payload had equipment we assembled ourselves, and instead of launching from NASA we launched from the UF football stadium! There were a couple problems along the way, and the payload hasn't been recovered (yet), but it was a fun project and we all learned a lot along the way!

Update: project video

Below is a panoramic photo right before the launch - see our balloon on the right? So cool!

Our goal was to take photos from the edge of space, and log temperature, pressure, humidity, and GPS coordinates along the way. On-board were a radio transmitter, an Arduino with a GPS shield, and an Android phone to take pictures every few seconds.

Android details: Most of the Android development was handled by UF student Richard along with high school students Benji, Tyler, Michael, and Kevin. Their GitHub project is here:https://github.com/rich90usa/AndroidSensorLogger. Also note that the automatic photo capture utilized Photo Log Lite. We also used GPSLogger to handle logging GPS to SD. "Both of these programs were chosen for their ability to run in the background - and do so reliably by using the 'correct' Android supported methods of doing so." -- Richard

Our code used the phone's text-to-speech engine to speak out an encoded version of every 90th new GPS coordinate. The data was encoded by connecting every number (0-9) to a word the NATO phonetic alphabet. The code also used text-to-speech to have the phone speak out the phone's altitude data. --Benji

The device consisted of 4 main components: a payload (the styrofoam box in which all of the electrical equipment was housed), a radar reflector (hanging off the bottom of the payload, to help make this object visible to aircraft), a parachute (at the top, made of bio-degradable plastic), and the balloon itself which measured about 6 feet wide when inflated at ground level (supposedly it reaches approximately 30 feet wide at high altitudes before it bursts). Once the balloon bursts, the parachute fills with air and the device floats back to earth.

Kunal demonstrates the effectiveness of our parachute with a scientific "run test"!

The radio communication system we used this year were a little more commercial than last year. Due to my limited time availability (I had an oral surgery rotation all week the week before launch), I chose to get something pre-packaged. My intent was to use FRS (those little 500mW family radio service radios) to send GPS data back to earth, but I later (after launch) did a little more research and realized that it probably wasn't the most legal way to do it. However, it was extremely cost effective (amateur radio transmitters and RF transmitter modules are quite pricey). For about the cost of a pizza, we were able to interface a FRS radio to the android phone, and the phone ran a program which polled its GPS, turned coordinates into NATO letter abbreviations, and spoke them through the speaker line. The FRS radio with VOX (voice operated transmit) sensed audio and transmitted accordingly. Although it worked very well, I later learned that this may not have been legal in the US because, although FRS doesn't require a user license and is legal to use anywhere as long as you use its stock antenna, I violated the rule that it cannot be operated above a certain height (20m I think?). Note that this should not be replicated, and probably shouldn't have been done in the first place. I know I'll take a lot of heat over this, but it's in the past now and will be done differently in the future.

Here are some photos right before the launch. It was a sunny day at the UF football stadium! The Android phone is taped the the outside of the box and takes pictures every few seconds, storing them on a micro SD card. Inside the box is an Arduino with GPS shield, and the FRS radio transmitter.

After launch the balloon ascended at a rate of about 500ft/min. It spat out GPS data often, and altitude (not encoded with NATO abbreviations) was the easiest to hear as I walked from the UF football stadium to the UF Gator Amateur Radio Club to use their equipment (namely an AZEL-rotor-controlled 70cm yagi antenna attached to an I-Com 706) to listen in as the balloon ascended... but not before a group photo!

Here we are in the station... let's get to work!

The results were a bit disappointing, as we believe the Android phone froze/crashed about 10,000 feet in the air! Since that was the device which generated the audio fed into the transmitter, when that phone died, the transmitter stopped transmitting, and we didn't hear anything else from the transmitter ever again! We included contact information in the payload and it's possible it will be found one day and we will be contacted about it. If this is the case, we'll view the SD cards and see the full GPS log and pictures from the edge of space! Until then, we can only cross our fingers and hope for the best. Either way we had a blast, and learned a lot along the way. Next time we can be better prepared for a solid recovery!

Here's audio of the device's last words when it was about 10,000 feet in the air: lastwords.mp3

Overall we had an awesome time! I'd like to thank everyone who helped with this project, especially UF students Richard, Kunal, Dante, and all of the SSTP high school students!

Markdown source code last modified on January 18th, 2021
---
title: High School Students' High Altitude Balloon #2
date: 2011-08-14 18:36:12
tags: amateur radio
---

# High School Students' High Altitude Balloon #2

__Last year a group of high school students,__ in collaboration with a seminar course on Space Systems sponsored by the University of Florida's [Student Science Training Program (SSTP)](http://www.cpet.ufl.edu/sstp/default.html), gained some real-world experience planning, building, and launching a research payload to the edge of space – all in a couple weeks!  Last year's high altitude balloon launch was [covered on my website](http://www.swharden.com/blog/2010-07-14-high-altitude-balloon-transmitter/), and the radio transmitter I built for it was featured on [this Hack-A-Day post](http://hackaday.com/2010/07/27/200-mile-rf-transmitter-and-high-altitude-balloon/). Unlike last year's payload, whose only homebrew device was the radio transmitter, this year's payload had equipment we assembled ourselves, and instead of launching from NASA we launched from the UF football stadium! There were a couple problems along the way, and the payload hasn't been recovered (yet), but it was a fun project and we all learned a lot along the way!

**Update:** [project video](http://vimeo.com/27447092)

<div class="text-center img-border">

[![](group_thumb.jpg)](group.jpg)

</div>

Below is a panoramic photo right before the launch - see our balloon on the right? So cool!

<div class="text-center img-border">

[![](pan_thumb.jpg)](pan.jpg)

</div>

__Our goal was to take photos from the edge of space, and log temperature, pressure, humidity, and GPS coordinates along the way.__ On-board were a radio transmitter, an Arduino with a GPS shield, and an Android phone to take pictures every few seconds.

__Android details:__ Most of the Android development was handled by UF student Richard along with high school students Benji, Tyler, Michael, and Kevin. Their GitHub project is here:<https://github.com/rich90usa/AndroidSensorLogger>. Also note that the automatic photo capture utilized [Photo Log Lite](http://www.appbrain.com/app/photo-log-lite/com.keepknocking.PhotoLogLite). We also used [GPSLogger](http://mendhak.github.com/gpslogger/") to handle logging GPS to SD. _"Both of these programs were chosen for their ability to run in the background - and do so reliably by using the 'correct' Android supported methods of doing so." -- Richard_

>  Our code used the phone's text-to-speech engine to speak out an encoded version of every 90th new GPS coordinate. The data was encoded by connecting every number (0-9) to a word the [NATO phonetic alphabet](http://en.wikipedia.org/wiki/NATO_phonetic_alphabet). The code also used text-to-speech to have the phone speak out the phone's altitude data. --Benji

<div class="text-center img-border">

[![](DSC_6013_thumb.jpg)](DSC_6013.jpg)
[![](IMG_2095_thumb.jpg)](IMG_2095.jpg)

</div>

__The device consisted of 4 main components:__ a payload (the styrofoam box in which all of the electrical equipment was housed), a radar reflector (hanging off the bottom of the payload, to help make this object visible to aircraft), a parachute (at the top, made of bio-degradable plastic), and the balloon itself which measured about 6 feet wide when inflated at ground level (supposedly it reaches approximately 30 feet wide at high altitudes before it bursts).  Once the balloon bursts, the parachute fills with air and the device floats back to earth.

<div class="text-center img-border">

[![](DSC_6009_thumb.jpg)](DSC_6009.jpg)

</div>

__Kunal demonstrates the__ effectiveness of our parachute with a scientific "run test"!

<div class="text-center img-border">

[![](DSC_6015_thumb.jpg)](DSC_6015.jpg)

</div>

__The radio communication system we used this year__ were a little more commercial than last year. Due to my limited time availability (I had an oral surgery rotation all week the week before launch), I chose to get something pre-packaged. My intent was to use FRS (those little 500mW family radio service radios) to send GPS data back to earth, but I later (after launch) did a little more research and realized that it probably wasn't the most legal way to do it. However, it was extremely cost effective (amateur radio transmitters and RF transmitter modules are quite pricey). For about the cost of a pizza, we were able to interface a FRS radio to the android phone, and the phone ran a program which polled its GPS, turned coordinates into NATO letter abbreviations, and spoke them through the speaker line. The FRS radio with VOX (voice operated transmit) sensed audio and transmitted accordingly. Although it worked very well, I later learned that this may not have been legal in the US because, although FRS doesn't require a user license and is legal to use anywhere as long as you use its stock antenna, I violated the rule that it cannot be operated above a certain height (20m I think?). Note that this should not be replicated, and probably shouldn't have been done in the first place. I know I'll take a lot of heat over this, but it's in the past now and will be done differently in the future.

<div class="text-center img-border">

[![](DSC_6016_thumb.jpg)](DSC_6016.jpg)
[![](DSC_6042_thumb.jpg)](DSC_6042.jpg)
[![](DSC_6049_thumb.jpg)](DSC_6049.jpg)
[![](DSC_6071_thumb.jpg)](DSC_6071.jpg)

</div>

__Here are some photos right before the launch.__ It was a sunny day at the UF football stadium! The Android phone is taped the the outside of the box and takes pictures every few seconds, storing them on a micro SD card. Inside the box is an Arduino with GPS shield, and the FRS radio transmitter.

<div class="text-center img-border img-small">

[![](DSC_6079_thumb.jpg)](DSC_6079.jpg)
[![](DSC_6119_thumb.jpg)](DSC_6119.jpg)
[![](DSC_6132_thumb.jpg)](DSC_6132.jpg)
[![](pan_thumb.jpg)](pan.jpg)
[![](panZoomed_thumb.jpg)](panZoomed.jpg)
[![](DSC_6145_thumb.jpg)](DSC_6145.jpg)

</div>

![](https://www.youtube.com/embed/BozzCpdTJUk)

__After launch the balloon ascended at a rate of about 500ft/min.__ It spat out GPS data often, and altitude (not encoded with NATO abbreviations) was the easiest to hear as I walked from the UF football stadium to the UF [Gator Amateur Radio Club](http://gatorradio.org) to use their equipment (namely an AZEL-rotor-controlled 70cm yagi antenna attached to an I-Com 706) to listen in as the balloon ascended... but not before a group photo!

<div class="text-center img-border">

[![](DSC_6151_thumb.jpg)](DSC_6151.jpg)

</div>

__Here we are in the station... let's get to work!__

![](https://www.youtube.com/embed/98SHxyvsGB4)

<div class="text-center img-border">

[![](IMG_2118_thumb.jpg)](IMG_2118.jpg)

</div>

__The results were a bit disappointing,__ as we believe the Android phone froze/crashed about 10,000 feet in the air! Since that was the device which generated the audio fed into the transmitter, when that phone died, the transmitter stopped transmitting, and we didn't hear anything else from the transmitter ever again!  We included contact information in the payload and it's possible it will be found one day and we will be contacted about it. If this is the case, we'll view the SD cards and see the full GPS log and pictures from the edge of space! Until then, we can only cross our fingers and hope for the best. Either way we had a blast, and learned a lot along the way. Next time we can be better prepared for a solid recovery!

__Here's audio of the device's last words__ when it was about 10,000 feet in the air: [lastwords.mp3](lastwords.mp3)

__Overall we had an awesome time!__ I'd like to thank everyone who helped with this project, especially UF students Richard, Kunal, Dante, and all of the SSTP high school students!

High Altitude Balloon Transmitter Prototype

It's been my goal for quite some time to design a simple, easy-to-replicate transmitter for high altitude balloon telemetry transmission. I'm quite satisfied by what I came up with because it's very simple, cheap, easy to code for, and easy to change frequency. I'd say the most common alternative is a handheld amateur radio transmitter which starts around $60, requires an amateur radio license, and typically output 5W of FM on 144MHz (2m) or 440MHz (70cm). Fancier handheld radios are capable of transmitting APRS packets, and use established base station repeaters to listen to these frequencies, decode the packets, and update an internet database about current location information. Although it's quite fancy, elegant, and technical (and expensive), I desire a much simpler, cheaper, disposable option! If my balloon lands in the Atlantic ocean, I don't want to be out $100+ of radio equipment! This alternative is about $7.

Here's my solution. I don't normally build things on perf-board (I prefer sloppy Manhattan construction), but since this might go near the edge of space and be jerked around in turbulent winds, I figured it would be a nice and strong way to assemble it. Anyhow, it uses a can crystal oscillator as the frequency source. These things are pretty cool, because they're very frequency stable, even with changing temperatures.

The can oscillator (28.704MHz, selected to be in a rarely-used region of the 10m amatuer radio allocation which I'm licensed to use, call sign AJ4VD) outputs 5V square waves which I use to drive two successive class C amplifiers. The signal can be shunted to ground between the two stages by a third "control" transistor, which allows micro-controller control over the final amplifier. Although it may have seemed logical to simply supply/cut power from the oscillator to key the transmitter, I decided against it because that can oscillator takes 20ms to stabilize, and I didn't think that was fast enough for some encoding methods I wish to employ!

Although during my tests I power the device from my bench-top power supply (just a few LM3805 and LM3812 regulators in a fancy case), it's designed to be run off 3xAAA batteries (for logic) and a 9V battery (for the transmitter). I could have probably used a regulator to drop the 9V to 5V for the MCU and eliminated some extra weight, but I wonder how low the 9V will dip when I draw a heavy RF load? The 3xAAAs seemed like a sure bet, but quite at the expense of weight. I should consider the regulator option further... [ponders]

There's the device in action while it was in a breadboard. I've since wired it up in a perf board (pictured) and left it to transmit into a small string of wire inside my apartment as an antenna as I went to the UF Gator Amateur Radio Club (a few miles away) and tried to tune into it. It produced a stunningly beautiful signal! I can't wait for its first test on a high altitude balloon! Here it's transmitting CW Morse code the words "scott rocks", separated by appropriate call sign identification every 10 minutes, AJ4VD, my amateur radio license... of course!

Above is what the audio sounded like with a narrow CW filter (awesome, right?), and a 3KHz wide USB configuration. I think this should be more than enough to carry us through a mission, and aid in direction finding of a landed payload!

Notes about filtering: The output of this transmitter is quite harmonic-rich. The oscillator produces square waves for goodness' sake! The class C amplifier smooths a bit of that out, but you still need some low-pass filtering, not shown on the schematic. I think for my purposes a 3-pole Chebyshev filter will suffice, but just keep this in mind in case you replicate my design. You certainly don't want to be transmitting out of band! Below is the output of the transmitter viewed on my scope. It's suspiciously smooth, which leads me to wonder about the accuracy of my scope! I really should get a spectrum analyzer.

Markdown source code last modified on January 18th, 2021
---
title: High Altitude Balloon Transmitter Prototype
date: 2011-08-14 18:42:59
tags: amateur radio, circuit, old
---

# High Altitude Balloon Transmitter Prototype

__It's been my goal for quite some time__ to design a simple, easy-to-replicate transmitter for high altitude balloon telemetry transmission. I'm quite satisfied by what I came up with because it's very simple, cheap, easy to code for, and easy to change frequency.  I'd say the most common alternative is a handheld amateur radio transmitter which starts around $60, requires an amateur radio license, and typically output 5W of FM on 144MHz (2m) or 440MHz (70cm). Fancier handheld radios are capable of transmitting [APRS](http://en.wikipedia.org/wiki/Automatic_Packet_Reporting_System) packets, and use established base station repeaters to listen to these frequencies, decode the packets, and update an internet database about current location information. Although it's quite fancy, elegant, and technical (and expensive), I desire a much simpler, cheaper, disposable option! If my balloon lands in the Atlantic ocean, I don't want to be out $100+ of radio equipment! This alternative is about $7.

<div class="text-center img-border">

[![](DSCN1718_thumb.jpg)](DSCN1718.jpg)

</div>

__Here's my solution.__ I don't normally build things on perf-board (I prefer sloppy Manhattan construction), but since this might go near the edge of space and be jerked around in turbulent winds, I figured it would be a nice and strong way to assemble it.  Anyhow, it uses a can crystal oscillator as the frequency source. These things are pretty cool, because they're very frequency stable, even with changing temperatures.

<div class="text-center img-border">

[![](DSCN1701_thumb.jpg)](DSCN1701.jpg)

</div>

__The can oscillator (28.704MHz, selected to be in a rarely-used region of the 10m amatuer radio allocation which I'm licensed to use, call sign AJ4VD) outputs 5V square waves which I use to drive two successive class C amplifiers.__ The signal can be shunted to ground between the two stages by a third "control" transistor, which allows micro-controller control over the final amplifier. Although it may have seemed logical to simply supply/cut power from the oscillator to key the transmitter, I decided against it because that can oscillator takes 20ms to stabilize, and I didn't think that was fast enough for some encoding methods I wish to employ!

<div class="text-center img-border">

[![](DSCN1717_thumb.jpg)](DSCN1717.jpg)

</div>

__Although during my tests I power the device from my bench-top power supply__ (just a few LM3805 and LM3812 regulators in a fancy case), it's designed to be run off 3xAAA batteries (for logic) and a 9V battery (for the transmitter). I could have probably used a regulator to drop the 9V to 5V for the MCU and eliminated some extra weight, but I wonder how low the 9V will dip when I draw a heavy RF load? The 3xAAAs seemed like a sure bet, but quite at the expense of weight. I should consider the regulator option further... [ponders]

![](https://www.youtube.com/embed/rRatJBAMgdg)

__There's the device in action while it was in a breadboard.__ I've since wired it up in a perf board (pictured) and left it to transmit into a small string of wire inside my apartment as an antenna as I went to the UF Gator Amateur Radio Club (a few miles away) and tried to tune into it. It produced a stunningly beautiful signal! I can't wait for its first test on a high altitude balloon!  Here it's transmitting CW Morse code the words "scott rocks", separated by appropriate call sign identification every 10 minutes, AJ4VD, my amateur radio license... of course!

* [cw.mp3](http://www.SWHarden.com/blog/images/cw.mp3)

* [usb.mp3](http://www.SWHarden.com/blog/images/usb.mp3)

__Above is what the audio sounded like__ with a narrow CW filter (awesome, right?), and a 3KHz wide USB configuration. I think this should be more than enough to carry us through a mission, and aid in direction finding of a landed payload!

__Notes about filtering:__ The output of this transmitter is quite harmonic-rich. The oscillator produces square waves for goodness' sake! The class C amplifier smooths a bit of that out, but you still need some low-pass filtering, not shown on the schematic. I think for my purposes a 3-pole [Chebyshev filter](http://en.wikipedia.org/wiki/Chebyshev_filter) will suffice, but just keep this in mind in case you replicate my design. You certainly don't want to be transmitting out of band! Below is the output of the transmitter viewed on my scope. It's suspiciously smooth, which leads me to wonder about the accuracy of my scope! I really should get a spectrum analyzer.

<div class="text-center img-border">

[![](DSCN1707_thumb.jpg)](DSCN1707.jpg)

</div>
Pages