The personal website of Scott W Harden

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 Hz wide, although an extra 100 Hz above and below the band is typically included in grabber spectrograms to aid experimentation in these regions. WSPR bands are often just above the QRSS window, so WSPR transmissions frequently appear on QRSS grabs.

Band Lower Edge (Hz) Upper Edge (Hz) Dial Frequency (Hz)
160M 1,843,000 1,843,100 1,836,600
80M 3,500,800 3,500,900 3,568,600
40M 7,000,800 7,000,900 7,038,600
30M 10,140,000 10,140,100 10,138,700
20M 14,000,800 14,000,900 14,095,600
17M 18,068,800 18,068,900 18,104,600
15M 21,000,800 21,000,900 21,094,600
12M 24,860,800 24,860,900 24,924,600
10M 28,332,800 28,332,900 28,124,600

⚠️ WARNING: These frequencies sometimes change based upon community discussion. The latest frequencies can be found at https://groups.io/g/qrssknights/wiki/3964

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.

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

⚠️ Warning: This article is obsolete.
Articles typically receive this designation when the technology they describe is no longer relevant, code provided is later deemed to be of poor quality, or the topics discussed are better presented in future articles. Articles like this are retained for the sake of preservation, but their content should be critically assessed.

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.

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!

⚠️ Warning: This article is obsolete.
Articles typically receive this designation when the technology they describe is no longer relevant, code provided is later deemed to be of poor quality, or the topics discussed are better presented in future articles. Articles like this are retained for the sake of preservation, but their content should be critically assessed.

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.

⚠️ Warning: This article is obsolete.
Articles typically receive this designation when the technology they describe is no longer relevant, code provided is later deemed to be of poor quality, or the topics discussed are better presented in future articles. Articles like this are retained for the sake of preservation, but their content should be critically assessed.

Ridiculously Simple AVR AM Radio Transmitter

I was brainstorming some RF circuits today and I had the desire to create a rapid transmitter/receiver pair that anyone would have around their house. I decided that AM or FM radio would be good since everyone can receive that, and pondered how best to generate the necessary radio signal and modulate it appropriately. After a few LC oscillator designs, I thought about the RC oscillators built into most micro-controllers. I grabbed an ATMEL AVR I had on hand (an ATTiny44A) and checked the datasheet. It had an 8MHz RC oscillator, which could be divided-down to 1MHz, and output on a CKOUT pin - all configurable with a few hardware fuses! Note that commercial AM radio stations are between 0.52 and 1.61 MHz, so a 1MHz signal would be smack-dab in the middle of our radio dial! I had to build a prototype to see how well it would work. Once concern was that the RC oscillator wouldn't be stable enough to produce reliable audio - boy was I wrong!

__The circuitry is textbook simple.__ Appropriately configured, the AVR generates 5V square waves from its CKOUT pin. Although a pretty shape, they're not powerful enough on their own to be heard across a room, so I needed an amplifier stage. A class C amplifier provided by a 2n7000 is commonly done in the low power amateur radio (QRP) community, so I went with it. A 2n7000 N-channel MOSFET with a 220-ohm resistor on the drain and the CKOUT directly into the gate did a fine job (I've used this design for 10MHz QRSS transmitters before), and I was able to modulate its amplitude by feeding the voltage from a MCU pin (turned on/off rapidly) through a decoupling capacitor into the drain of the MOSFET. I couldn't have asked for a simpler result!

This code sends a message in Morse code. It seems too easy! Applications are endless, as this is one heck of an easy way to send audio from a micro-controller to a radio, and possibly to a computer. Morse code is easy, and since we have the ability to dynamically generate different audio frequencies and tones, data exchange is easy too! Nothing's stopping you from adding the code to turn this into a RTTY (or Hellschreiber?) transmitter.

Again, this transmitter can be heard on a standard AM radio tuned to about 1000 kHz. This is the setup I used with great success:

Here's the code on the chip! Nothing complicated:


// designed for and tested with ATTiny44A
#include <avr/io.h>
#define F_CPU 1000000UL
#include <avr/delay.h>
#include <avr/interrupt.h>

void beep(){
    for(char i=50;i;i--){
        DDRA|=_BV(PA7);_delay_ms(1);
        DDRA&=~_BV(PA7);_delay_ms(1);
    }
}

void rest(){_delay_ms(100);}

void dot(){beep();rest();}
void dash(){beep();beep();beep();rest();}
void space(){rest();rest();}
void space2(){space();space();}

int main(){
    DDRA|=_BV(PA7);
    for(;;){
        dot();dot();dot();space();             // S
        dash();dot();dash();dot();space();     // C
        dash();dash();dash();space();          // O
        dash();space();                        // T
        dash();space();                        // T
        space2();
        dot();dash();dot();space();            // R
        dash();dash();dash();space();          // O
        dash();dot();dash();dot();space();     // C
        dash();dot();dash();space();           // K
        dot();dot();dot();space();             // S
        _delay_ms(1000); // silence
    }
    return 0;
}

THIS IS ILLEGAL to do if you exceed a certain amount of power because you're stepping on legitimate commercial broadcasters and will have to deal with the FCC. Additionally, you are transmitting on more frequencies than the primary frequency because the signal is heavy in odd harmonics. This means a 1 MHz transmitter, producing square waves, will generate tones on 1, 3, 5, 7 MHz, etc. Don't do this with much power! Heck, you probably shouldn't do it at all ;-)

page 1, page 2, page 3, page 4, page 5, page 6, page 7, page 8, page 9, page 10
All Blog Posts