Space Dorothy appears on Weather Radar

On August 6th, 2015, PiBalloonIII was launched from the Trinity Valley Community College in Terrell, TX. Launch took place at approximately 11:15AM. The balloon drifted south, towards Athens, and then cut west for a burst near Ennis. Burst happened at ~2:33PM, and the payloads were on the ground shortly thereafter.

Space Dorothy was two draw-string bags filled with ~150 ping pong balls. A 5″ foil tail was attached to each ping pong ball to help with reflectivity. The bags were mounted above the parachute, so they would be turned up-side-down when the balloon burst.

This map shows the launch from Terrell, the burst point, landing site (final K5UTD-11 position), and the debris field based on local area reports. Several residents called after seeing my phone number written on the side of ping pong balls.


This album shows the differential reflectivity between horizontal and vertical polarization on weather radar. At the 1.5° tilt, the altitude was approximately 8kft. At the 2.5°, 3.6° and 4.5° tilts, the approximate altitudes of the beam were 12kft, 17kft, and 21kft respectively.

As you can see, there is a cluster of debris that intersects the expected flight path of the ping pong balls shortly after burst. Because the ping pong balls have little mass and a foil tail, they took much longer to descend than the primary payloads.

Despite original looks at the radar being inconclusive, a further analysis of the Level 2 data proved to be quite useful. The filtering on the WSR-88D most likely filtered out most of the ping pong balls on the Base Reflectivity and Base Velocity products, but the Differential Reflectivity appears to have far less filtering, allowing these reflections to be seen. Apparently 152 ping pong balls can actually appear on weather radar.

These images were rendered with GR2Analyst. The data was pulled from KFWS on 8/6/2015 between 1900 and 2030 UTC.

PiBalloonIII Flies For a Third Time!

On Thursday, August 6, we will be launching a student payload, PiBalloonIII, and Space Dorothy. This launch is part of a STEM outreach camp.

Space Dorothy

space dorothy

We plan on dumping 152 ping-pong balls from the edge of space. Each ball will be labeled with “REWARD!” and my phone number. In addition, the ping-pong balls will have a small hole, and a foil tail. There’s a decent chance that the ping-pong balls will reflect weather radar. Space Dorothy is being assembled by the students.

Radio Payloads

There will be two radio payloads on this launch, PiBalloonIII and the student box.

  • Primary Tracking/Telemetry (Student Box): K5UTD-11, 144.34MHz, Arduino-powered telemetry
  • Backup Tracking: KE5GDB-11, 144.39MHz
  • SSTV: 144.5MHz, Martin 2
  • Crossband Repeater: 147.5MHz downlink, 446.050MHz pl110.9 uplink

Launch Details

We will try and launch from the Trinity Valley Community College in Terrell at about 10:15AM. Wide area communications will be on the Flamethrower (146.7- pl110.9/441.925+ pl110.9). The simplex chase frequency is 446.1.

PiBalloon III/PHAB-11 – Another Success!

PiBalloon III (on the PHAB-11 string) had a successful flight on Saturday, July 11. Launch was at 9:30AM from Bonham High School, and landing was at 12:23 in Sherman. The balloon narrowly missed a populated area, and some high-tension power lines. The average descent rate was 3500ft/min. Conversely, the ascent rate was 675ft/min.

The Launch

The balloon launching went off without a problem. We laid the balloon out, and connected it to the hydrogen tank, but waited for PiBalloonIII to be fully operational before filling began. Once the crossband repeater, SSTV, and APRS were all verified, we inflated the balloon. When the balloon was filled, we rigged the payloads, and walked it over to the field. The PARK Balloon group uses a method called a tethered launch, where a rope is fed through the ring on the balloon. This allows a final check on all of the payloads to be run before the balloon is let go. When we’re ready for launch, one end of the rope is let go, and it slowly feeds through the ring allowing a jolt-free release.

Payload Performance

All systems functioned as intended, with the exception of one experimental tracker (W5ADC-7). Based on the data received over the APRS network, the GPS was not in “high altitude mode,” and capped out around 40,000ft. The other two trackers (KE5GDB-11 and W5ADC-11) functioned exactly as intended.

The crossband repeater sustained a lot of traffic! There were about a dozen check-ins, and a constant chatter about the balloon.

The slow-scan TV package sent amazing photos from the edge of space.

Pi Camera Photos


Watching the Balloon Come Down

One of the coolest parts about this flight was that we nearly intercepted it on the descent. Landon (N5AET) and I were able to see the balloon come down. I was able to take the video recorded from the balloon and locate my vehicle (or maybe the one just in front of us).

(BEWARE: Clenching may occur as power lines become visible!)

Flight path in final few minutes:


A still from the video above:








How it looked from the chase vehicle (taken about 10 seconds later):


Final Thoughts

This was a fantastic launch with great results. The pictures were amazing; both the real-time SSTV and the ones pulled from the SD card later on. We had a little fun with the SSTV when the balloon was in “descent mode,” and will probably continue the tradition. It was a pleasure to launch with the PARK Balloon group, and I’m very thankful for the opportunity.

PiBalloonIII – Another Flight!

On July 11th, PiBalloonIII will be flying with the PARKBalloon group. This is the second of four possible flights for this hardware configuration.

This payload features SSTV, a crossband repeater, and an APRS tracker.

  • APRS: KE5GDB-11 on 144.39MHz (change to .34 is possible)
  • Slow Scan TV: 144.5MHz – Martin 2
  • Crossband Repeater: 446.050MHz Uplink (110.9PL); 147.5MHz Downlink

Launch is at 9:00AM out of Bonham. I’ll post an update when the details are finalized.

More details on the payload can be found here.

PiBalloonIII – A Success!

Well, mostly.

The launch took place earlier than scheduled; at 0932L the balloon was released in some moderate winds from Forney High School. Everything ran ahead of schedule, we arrived at the high school early, the students from DeSoto and Lancaster arrived early, and subsequently the balloon was launched early.

All pre-flight checks went OK. Everything was beaconing properly, APRS data looked good, and the crossband repeater was repeating. There were five payloads that seemed to be functional: Primary Tracking, Telemetry, Secondary Tracking, Slow-Scan Television (SSTV), and the Crossband Repeater.

Once the rigging was complete, the students huddled in a corner and began inflating the balloon. It took nearly all 21 students with their hands in the air to prevent the balloon from making contact with the building when gusts of wind would take control of the balloon. Upon inflation, we zip-tied the payload string to the balloon, and walked it out to the practice football field. After a quick run-down of launch procedure (essentially “release slowly!”) we let the balloon up by feeding the payload string hand-over-hand. At times, the wind was so strong, the string was barely 30° above the ground.

It’s in the air!

Shortly after launch, we realized that the Pi-based tracker was not updating its position. It was sending the same packet over and over. Although not good, it does indicate that the problem was upstream of the TNC, most likely a communication issue with the GPS. Unfortunately, my code is not self-recovering from a GPS connect/disconnect issue. It can easily handle a position unlock, but if the gpsd daemon stalls, it will not recover. I imagine that there was a loose connection that caused this particular problem. Fortunately, the primary tracker functioned exactly as intended.

The telemetry looked good. At the launch site, the balloon measured a pressure of 981mb, an external temperature of just over 30°C and a relative humidity of 47.6%. Tony (W5ADC) was able to calculate the ascent rate – just over 1200ft/min, or 6m/s. With the balloon in the air, the chase began.

Tony (W5ADC), John (KC0L), and myself took off just after the balloon launched. The students loaded up, and went to a local park to play around while the flight took place. Tony, John and I stopped in Seagoville to run flight predictions, talk on the crossband repeater, and plan out our chase. After about 45 minutes of waiting, we determined it would be wise to head towards Ferris.

I made numerous contacts through the crossband repeater. In this mode, it will repeat things heard on 446.050MHz out on 147.5MHz. I talked to AF5MI in Carrolton, K5LUO near OKC, W5TXG near Palestine, and KD5OUG in Richardson. Next time I’d like to work “Balloon DX” through the repeater.

Bursting Point

We made it to Ferris rather quickly, and kept heading south on 45. Believe it or not, bladder instinct led us to our next waiting point, a Shell/Sonic combo just outside the city of Palmer. John, Tony and I spent about twenty minutes at this location while the students were rounded up and caught up with us. The balloon peaked at 85,000 feet, and made a quick descent following the same winds that took it up.

Space Launch 1 Flight Path

The bus driver was kind enough to follow the chase vehicles as we weaved our way through Palmer out to some country roads. John had a slight lead, and informed us that the balloon would be very easy to access, and was nicely strewn out in a field. His assessment was correct; the balloon was 30 yards from CR813 and was waiting for us in a slightly muddy field.

The students hopped off the bus, and helped gather up the payload bits. The landing, although mostly soft, was enough to knock some batteries out of their holder on the primary tracker. The chase was completed after a trip to CiCi’s in Lancaster.

Data Analysis

My favorite part of the launches is the data. I love seeing where the balloon can be heard, and watching the telemetry stream in through the flight. This flight had the telemetry basics covered, but not overdone: internal temperature, external temperature, pressure, and humidity. Altitude was handled by the GPS.

The basics:

  • Launch: 9:32AM
  • Burst: 10:54AM
  • Landing: 11:20AM
  • Flight Time: 1:48
  • Max Altitude: 84,486ft
  • Lowest Temperature: -47.9°C
  • Lowest Pressure: 25mb

Even though my primary tracker had failed to accomplish its primary function, it was still useful for ranging the balloon. A handful of IGates were able to directly receive packets from the balloon: N5DTX-5, K5UTD, KB5ASY-4, AF5I-1, WD5DDH-1, WB5QLD, N5HYH-5, AE5PL-10, KE5UUO, W5LHG, N8QVR-10, KC5AFM-1, W5AMZ-1, KD5UMO-1, N5YSQ, KA5WMY-10, W5NGU-4, W5ROX, KA5WMY-5. Remember, to IGate a packet, you must have a good signal from the balloon. This means >-110dBm (or so). The image below represents the areas in which the balloon was definitely heard via RF, and you probably could have talked through the crossband repeater or received SSTV images.

The temperature data is ever so slightly skewed by the color of the temperature sensor: black. As seen in the chart below, the temperature rapidly dropped on the descent and ultimately reached a minimum value of nearly 20°C less on the descent than it did on the ascent. I believe this is caused by the air rapidly moving over the sensor, giving the sun and the internal electronics less of a chance to skew the data.



Another aspect of the data to analyze is the pressure/altitude correlation. The GPS read a max altitude of 85,000 feet, and the lowest measured pressure was 25mb. Using formulas provided by NOAA, I plugged in our meager 25mb to produce a theoretical maximum altitude of 73,499 feet. It’s a good thing our altitude data came from a GPS, as the NOAA formula and our sensor produced over a 15% error between the two numbers.

The humidity data was rather boring, other than inconsistent amounts of moisture at various altitudes. I’m sure the people that paid close attention in Skywarn school would like me to make a Skew-T chart out of this data, but you’ll have to do it yourself.

The data can be downloaded here.

A Successful Launch

All things considered, this launch was very successful. First and foremost, the students enjoyed themselves and learned a lot in the process. On the balloon, there were no catastrophic failures, as the only issue was a GPS failure on the secondary tracker. The Byonics TinyTrak4 once again proved that it is a solid piece of equipment, and that I’m not yet qualified to make flight-ready trackers myself. The GoPros did a great job, and took plenty of photos of the areas surrounding the metroplex. We couldn’t have asked for a better recovery location, and a better chase team to help find it.

Thanks to everybody that made this launch and recovery possible! It was a very enjoyable experience, and I look forward to the next one.

PiBalloon III – Launch on July 1st


Launch on Wednesday, July 1st, before noon. Location TBD. Chasing encouraged.

  • APRS Primary: K5UTD-11 on 144.34MHz
  • APRS Backup: KE5GDB-11 on 144.39MHz
  • Slow Scan TV: 144.5MHz – Robot 36
  • Crossband Repeater: 446.050MHz Uplink (110.9PL); 147.5MHz Downlink

Launch Details:

This launch is part of an Intro to Space camp being hosted at UT Dallas. High school students interested in STEM will be coordinating launch aspects, and assembling the primary payload. We will be launching on Wednesday, July 1st, some time before noon. The students will chose the launch site a day or two before the launch. Upper level atmospheric conditions will dictate the launch site.

Payload Details:

The primary tracking payload will be built by the students. It will consist of a TinyTrak4, GPS, Arduino, and a handful of weather sensors. It will operate under the K5UTD-11 SSID, and beacon a position once every 15 seconds, and a telemetry packet once every 15 seconds.

The secondary tracking will be handled by a RaspberryPi and a TNC-Pi. The “signal” chain will be a USB GPS to gpsd, which is then read by a python script, and sent to the aprx daemon. The aprx daemon transmits a position every 10 seconds.

The SSTV transmitter will be driven by the RaspberryPi running the secondary tracking. The Pi will take a picture with a Pi Camera, process the .png into a .wav file, and play the audio to a radio via the soundcard. This can be run simultaneously with the APRS, as the APRS radio is controlled by the TNC-Pi, not the soundcard on the Pi.

The crossband repeater will be a Yaesu FT-530.

Power Management:

The payloads will be divided into three separate power groups: primary tracking, secondary tracking, and non-essentials. Primary tracking will consist of the TinyTrak4, GPS, Arduino, sensors, and a Baofeng UV-5R. Secondary tracking will be the RaspberryPi and another Baofeng UV-5R. The non-essentials will include the crossband repeater and the SSTV transmitter (you guessed it; another UV-5R!).

Each group will be powered by three or four Li-SO2 D cells. This will give us 10.8v or 14.4v to play with, at 9.2Ah.

Communications Plan

We will use the following frequencies depending on balloon location.

County Repeater Frequency
Collin/Rockwall UT Dallas 145.43- pl110.9
Dallas/Ellis/Kaufman Flamethrower 146.7- pl110.9
Denton/Wise Rosston 145.49- pl85.4
Tarrant K5FTW 146.94- pl110.9
Elsewhere Simplex 146.54

Using APRS to Determine Repeater Coverage

Here at the University of Texas at Dallas, we operate a repeater on 145.430MHz (K5UTD-R). For 5 years, it sat on the top of a 50′ tower, on a 50′ roof, giving us about 100′ feet above ground level. The end goal is to relocate this repeater to a higher tower on campus. This would make use of an antenna that is ~250′ AGL (if not a little more), as opposed to 100′ AGL. Moving this repeater took a lot of time and coordination, so in the mean time, I determined I would experiment with the APRS network to get a general idea of how coverage will change.

Is this an exact science? Not at all. The predicted coverage relies on many different variables; some are in my control, but most are not. The general principle is that you can make use of stations beaconing their positions, and compare the position packets you hear on one antenna with packets heard on the other. This will loosely correlate with the changes in repeater coverage when the transition is complete. This takes advantage of the APRS network, and the fact that many radio operators run GPS-based tracking systems in their cars. Data from these systems can be received on 144.39MHz.

The basic premise of this experiment is not to see where the repeater can be heard, but rather what the repeater can hear. As mentioned above, this experiment takes advantage of radio operators persistently beaconing their position using systems similar to what they will use for voice communications.

To get an estimate of what the repeater can hear in the “pre-move” and “post-move” configurations, I collected two datasets at two separate times. The first dataset was using an antenna on the roof of the Engineering and Computer Science building. The antenna had similar height and gain to the old repeater antenna. Due to hardware constraints, I could not simultaneously run two IGates to collect data on both antennas. This is one source of error.

The IGate operated on the rooftop tower from Jan 26 to Feb 18. This gave me about 3 weeks worth of data to work with. The IGate operated with the larger tower from Feb 26 to March 8. This was only about a week and a half worth of data.

In this particular setup, the IGate consisted of a Raspberry Pi with the TNC Pi addon board. The radio was an Icom IC-229H, and would beacon two packets every 10 minutes (status/position). The APRX daemon was used to internally log and gate the packets to the internet. The log files are what I used to produce the map seen below.

Parsing the log file is no easy task. As you would have expected, there is a library written in Perl to parse APRS packets, so I wrote the script in Perl. I wrote several filters to only give me packets that I locally received. The filters discarded packets that have been digipeated, came in over the APRSIS servers, were not position packets at all, or had a distance greater than 150 miles. I also wrote in a filter that discarded packets with a speed greater than 100mph, as planes will skew the data.

The Perl script was written to spit out a KML file. It would take several minutes to run, as the log file is >113MB, but would result in a 6MB KML file ready for Google Earth.


The image above is what the script produced. These are the packets that were heard directly from the transmitting station. The blue dots represent the packets heard on the new, higher antenna, while the red dots represent the packets heard on the older, lower antenna.

Obviously the higher antenna heard packets much further out than the lower antenna, with one exception. There is a 60° slice of the old coverage area to the south that is not covered by the higher antenna. This is because the antenna is side-mounted on the north side of the new tower. Aside from that, the higher antenna appears to cover much more of the metroplex than the lower antenna.

Anyway, it was a major project to move the repeater, and a lot of fun to write the script and produce the map while we had downtime. This type of map is easy to produce, and can be done by modifying my script to suit your needs.

PiBalloonII is finished!

After a few months of gathering pieces, writing code, and actually building the payload, PiBalloonII is ready.

The subsystems of PiBalloonII consist of:

  • Raspberry Pi B+
  • uBlox NEO-6M GPS (UART/TTL level)
  • TI TMP513 Power Monitoring System (I2C)
  • DS18B20 Temp Sensor (1-Wire)
  • DHT11 Humidity Sensor (Proprietary)
  • BMP180 Pressure Sensor (I2C)
  • Dorji DRA818V 2M Transceiver (UART/TTL level)
  • 8xAA Ultimate Lithium batteries (in two 4xAA configuration)

Each of the sensors listed above is interfaced to the Pi with their respective protocol. Due to the nature of the sensors, some can update very quickly, while others can take up to two seconds. The barometer can update at 53Hz, while the humidity sensor can update once every two seconds. Because of this, it’s easiest for each sensor to maintain its own log file.

The GPS feeds a program called GPSD. This program makes it very easy to cross-interface multiple types GPS units, while also providing libraries to Python. As learned on the first PiBalloon, it’s best to set the GPS in high-altitude mode. I didn’t know such a mode was needed, and at 12,000 meters, the GPS started sending garbled data. The GPS purchased has a battery, so it’s easy enough to set the configuration on the computer and it will maintain the settings.

The TI TMP513 is the coolest sensor on the payload. It will measure voltage and current, while also providing up to three external temperature sensors. Here is a snippet of the TMP513 log file:

1417641807.10, 12.368, 318, 30.44, 27.00, 20.44, 318, 676
1417641808.31, 12.172, 680, 30.44, 27.38, 178.25, 318, 680
1417641809.27, 11.972, 683, 30.50, 28.19, 255.94, 318, 683
1417641809.93, 11.984, 689, 30.50, 28.25, 255.94, 318, 689
1417641810.58, 11.964, 606, 30.50, 27.62, 248.38, 318, 606
1417641811.68, 12.180, 304, 30.50, 29.25, 255.94, 304, 606
1417641812.74, 12.352, 311, 30.44, 27.00, 18.94, 311, 606
1417641813.42, 12.352, 323, 30.44, 27.00, 19.31, 323, 606
1417641814.08, 12.352, 312, 30.44, 26.94, 19.31, 312, 606
1417641814.76, 12.356, 312, 30.44, 26.94, 19.19, 312, 606

The first column is UNIX epoch time. All log files will share this property. The second column battery voltage, followed by current (in mA). The fourth column is the onboard temperature sensor on the TMP513, then a remote internal temperature sensor and a remote external temperature sensor. The last two columns are idle current and transmit current.

As you can see, a temperature of 255.94C is very unlikely, so I’m going to write it off as RFI problems on the remote sensor. Fortunately, we have a digital sensor for the external temperature readings, with almost no chance of RFI.

The DS18B20, DHT11, and BMP180 measure temperature, humidity, and pressure respectively. I much prefer the DS18B20 to the TMP513 for temperature readings at the moment, as I don’t yet fully understand how to calibrate the 513 and minimize RF interference.

The final item on the payload list is the Dorji DRA818V. This is our 2 meter transceiver. Originally I planned to fly two of these, but after much thought and some technical difficulties, I determined that we could move a similar amount of data, with little compromise, using only one radio. The compromise made pertains to the quality of the SSTV images. Because SSTV can’t use the transmitter continuously, I opted for a 36 second Robot 36 image instead of a 5 minute Scottie DX image. The visual difference is definitely noticeable, but it’s not worth the trouble of maintaining a second transmitter.

To save time, the scripts will compile APRS packets while the SSTV image is transmitting. Theoretically, I could reduce the cycle down to about 45 seconds, but I’m going to opt to keep it at 60 seconds to give the transmitter some time to unkey and cool (ever so slightly).

Using the Energizer Ultimate Lithium Batteries, I’m able to get a predicted 4 hours of use from 8 batteries. The Pi uses about 300mA, transmitter 750mA and we lose 100mA in the voltage regulators, so we can assume 1.25A of draw at any given time. After cross referencing the datasheets, I can predict we will see at least 4 hours, if not more from a given set of batteries.

All of the code can be found on GitHub.


Radio Amateurs attempt Low Power FM

Back in October of 2013, members of the K5UTD Amateur Radio Club met up at Raising Canes after the monthly meeting. We discussed RadioUTD, and how the internet wasn’t providing enough exposure. Apparently the FCC allows you to setup very low power AM stations in which the AC mains act as your antenna. For UT Dallas, and a station like RadioUTD, this was unsatisfactory. We discussed another option, Low Power FM.

Back in the early 2000’s, the FCC created the Low Power classification of Part 73 FM broadcast stations. LPFM stations are community-driven entities that transmit at no greater than 100 watts ERP at 100 feet above ground level. The goal of LPFM is to bring more community-based programming to served areas, as opposed to commercial broadcast interests.

The dinner at Canes finished up, and we all went home. Sometime later in the night, I got a text from another K5UTD club member, Landon. It said something along the lines of, “LPFM application process open. Act soon!”

[K5UTD is the Amateur Radio Club. Our focus is on communications, RF engineering, and public service. RadioUTD is the internet-only radio station located in the Student Union. These two organizations are independent, but are collaborating for a common goal of establishing an LPFM station. RadioUTD wants to be on the air, and K5UTD enjoys a challenge.]

Applying for a License

It’s not like driving over to the DMV, waiting in line, getting an awful picture taken, and regretting said photo for the next 10 years. The application was 26 pages long. The window to file the application was from October 15, 2013 to November 14, 2013 (at 5:00PM). Per the college student standard, ours was submitted at 4:45PM on the 14th of November.

In the application, there were a lot of technical details, details about the organization applying for the license, and an odd favoring of Native American applicants. Everything is based on a point system. Established Community Presence is worth one point. This is defined as being established for two years. Local Program Origination will earn you another point. For at least 8 hours of every day, the programming must be locally produced. Having a main studio that is staffed for at least 20 hours a week will earn a point. A bonus point is awarded for having local programming and a main studio! The final point that we were eligible for certifies that we don’t have an interest in any other broadcast station. This totals to 5 points. Without being affiliated with tribes, tribal lands, or tribal organizations, we cannot claim a sixth point. Unfortunately, we’re not affiliated with anything tribal.

We collaborated with RadioUTD to compose the application, and were ultimately confident with what we had submitted.

The Waiting Game

As with every government-based application process, progress isn’t exactly quick. There were many applications submitted, and I imagine the FCC wasn’t prepared to handle all of them. Several months after the applications were submitted, the FCC released “MX Groups.” In the event that there are multiple applicants competing for the same frequency in the same geographic area, a mutually-exclusive group is formed.

The first factor in resolving MX groups is the point system. Applicants with the most points will be chosen over those with less. We’re in a favorable situation, as we qualify for the maximum number of points attainable in the DFW area. Because DFW is in the top 10 radio markets, there are other applicants that also qualify for 5 points. In this case, we’re given an option to voluntarily enter a time-sharing agreement. For example, if Station A and Station B want to enter a time-sharing agreement, Station A can opt to take 5:00AM to 1:00PM. Station B can take 1:00PM to midnight. The final method of resolving an MX group is involuntary time-sharing. This is where the FCC will tell you when you can be on the air as to not conflict with the other stations. This is the method of last resort.

As of the writing of this post, our application is in an MX group with others from the DFW area. The FCC has not yet resolved the MX groups in Texas.

The Signal Chain of a Radio Station

Let’s take a minute to discuss how the audio moves through a radio station. There are several sources of audio – a computer, microphones, a telephone line, and maybe CD players, record players, or even tape decks. All of these sources are brought to a mixer. The primary function of a mixer (in a radio application) is to control the levels of each source. There’s typically a START/STOP button (think unmute/mute), a fader to control the level, and some routing options. The audio that’s intended to go over the air is played on the Program Bus. Contrary to the Program Bus, the Audition Bus is where you can play music to only be heard in the studio. This is useful for cuing music, screening callers, and level checking.

Processing is the next major step in the signal chain. Most commercial radio stations will heavily compress their audio. Compression is a way to level out the “loudness” of a track.This is an oversimplification of compression, but it effectively turns up the quiet parts and turns down the loud parts. Broadcasters will compress their signal so they can make every part of the song sound even. With everything even, it can be turned up to the maximum allowable level. The FCC defines this maximum as 100% modulation, where 100% = 75KHz FM deviation. Thus far, the signal (music, talking, etc) is generated, mixed, and compressed.

FM Stereo was introduced in the early 60’s. For stereo audio, you need two channels, Left and Right. In FM broadcast, the transmission itself is a single channel, or mono. To multiplex (simultaneously transmit) both the left and right channels, the audio is fed from the compressor to a stereo generator. The stereo generator uses math to split the signal into L + R and L – R. Your receiver will use the reverse process to separate that out into the left and right channels. The L + R technique is intended to be backwards compatible with mono receivers (if it were just L and R, the mono receivers would only get one channel instead of the sum of both). In our case, the stereo generator and compressor/limiter are an all-in-one solution (Orban Optimod 8100A).

The next step in the signal chain doesn’t change anything, but rather moves the signal from one location to another. It’s called the Studio to Transmitter Link, or STL. In the case of our station, the transmitter will be located in the Engineering and Computer Science building, and the studio is located across the street in the Student Union. In commercial radio, the distance between studio and transmitter is typically measured in miles, not yards. STLs were traditionally 950MHz RF links (strictly wireless), but modern radio stations make use of phone lines, traditional 950MHz STLs, and even the internet. Depending on how the station is built, the compression/limiting and stereo generation can happen at the transmitter site or at the studio. In our case, the STL is going to be an internet link, and the compression/limiting and stereo generation will happen at the transmitter site.

The final step is the transmitter. This is the unit that actually puts the station on the air. We give it audio and power, and it gives us RF. This will be amplified from about 15 watts to 80. This RF is then sent to an antenna. The antenna will induce a charge on other antennas in the receiving range, allowing you to receive the transmission with your car or home stereo.

Here’s the TL;DR: Music/Speech > Mixer > Compression/Limiting > Stereo Generation > Transmitter > Antenna.

In the meantime…

Internally at K5UTD, we discussed our likelihood of getting the license. Based on this chance, and perceived financial risk, we set an arbitrary limit on broadcast equipment expenses. Is this enough to setup a full station? No. Is it enough to maintain interest with the involved parties? Yes, in fact having the dollar limit motivates us to work a little harder at finding good equipment at bargain prices. Remember, we’re Amateur Radio operators. Bargain hunting is our specialty.

Finding a transmitter was our first goal. We did some research, and two main contenders seemed to meet what we were looking for – the Harris MX-15 and the Continental 802A. Both are 80’s era, solid-state transmitters, going for far less than the all-digital solutions seen today. The signal chain in both of these units is completely analog. Oddly enough, we found an MX-15 on eBay, and were able to locally meetup with the seller. She appreciated what we were trying to do, and gave us a “student discount.”

Our next acquisition was mostly by chance. By sheer coincidence, I met the Chief of Engineering at an 8 station cluster. He also appreciated what we were doing, and offered to “fill up a pickup truck worth of gear.” A few months later, we returned with a truck, and were given Marti Remote Units, an Optimod 8100A, and some other kibbles and bits that will help in the long run. The 8100 was state-of-the-art back in the 80’s, and is commonly used as a backup today. It’s not overly aggressive, but will easily keep our station compliant and near 100% modulation all of the time. Remember, we’re not attempting to compete with KISS stations, or The EDGE, or whoever else. We’re not trying to squeeze as many dB as humanly possible out of 75KHz of deviation. Our goal sound will be lightly compressed, lightly equalized, and easy to listen to.

The most recent acquisition came from a local production company. They’ve migrated entirely to digital mixers, and with digital gear they don’t need outboard analog processing. They kindly donated some equalizers, compressors, and CD players. The CD players will be perfect for auto failover, as they can be controlled via RS-232 or TTL logic. The equalizers will be perfect for ever-so-slightly adjusting our curve to sound good in mobile applications.

We sincerely appreciate both the donors and what they’ve done to help us out with this process. We’ve spent a little over $600, and have almost built an entire transmitter site. None of this would have been possible without your help!

Final Thoughts

We’re still waiting for our construction permit, but the process thus far has definitely been educational and a lot of fun. It’s not every day that an opportunity to setup an FM radio station comes along, and I’m very glad that we’ve had support from everybody at K5UTD, RadioUTD, the various engineers I’ve harassed about FCC rules and regs, and from the equipment donors.

DORJI Modules – Radio on a Chip

The DORJI modules (DRA818V and DRA818U units) came in yesterday. These modules are full transceivers. They are programmed via UART, don’t require a power cycle between frequencies, have a sleep mode, and can provide 500mW or 1W.

Programming these units is not exactly easy. They use 3.3v TTL levels, so your typical USB to Serial adapter won’t work, as those use RS232 levels (-12v & +12v). TTL levels are typically 0v to 5v, or 0v to 3.3v. Fortunately I intend on using these with a Raspberry Pi, so I will already have a UART (serial interface) that provides 0 and 3.3v levels.

Minicom, screen, PuTTY, and various other terminal clients were giving me a very rough time with these units. The initial handshake command is “AT+DMOCONNECT” with the carriage return and line feed characters. With the terminal programs I listed above, each character was individually sent, and I was commonly seeing “+DMOERROR” as I was trying to type out AT+DMOCONNECT. Python was the tool that finally worked.

import serial
ser = serial.Serial(‘/dev/ttyAMA0’, 9600, timeout=2)

Assuming this all ran correctly, you should see an acknowledgement from the module.

Ultimately this is very exciting, as it’s giving me a full transmitter and receiver on a platform that can be dynamically programmed from a Raspberry Pi. The dynamic frequency changing will allow me to send Slow Scan TV, then send APRS packets, kerchunk repeaters, and then do the whole process again.