Measuring The Velocity Factor of Coax Using an SDR

Recently I had the need to measure the velocity factor of some coax. The velocity factor of a transmission line is ratio of the actual propagation of radio signals through the cable vs the speed of light in a vacuum.

Here’s the coax in question:

It’s RG-6U, for which I have seen published velocity factors ranging from 0.65 to 0.85, depending on the manufacturer and type of dielectric. This coax was laying in my junk box, and I have no idea who makes it, or what the claimed specifications are. The performance of a lot of lower cost coax often widely varies from published specs, as well.

One technique to measure the velocity factor of a transmission line is to use a piece of it as an open stub, which is a section of transmission line connected to another line via a Tee connector. The added transmission line is open at the other end, hence the term “open” stub. The open stub will act as a notch filter for frequencies with a wavelength close to four times the length, in other words the stub is 1/4 wavelength.

For this measurement, I used an SDR (Software Defined Radio) as the measurement device. In this case an SDR-14. To generate RF I used a noise bridge.

The output of the noise bridge is a good source of wide-band RF.

Here is the Tee. On the left is the RF signal, on the bottom is the connection to the SDR, on the right is the open stub.

With the noise bridge connected, but no stub, here is what the SDR spectrum looks like, click to enlarge:

As you can see it is relatively flat. Next, we’ll connect the 1/4 stub (again, click to enlarge):

You can see the dip in the signal level, caused by the stub.

In this case, the stub was 13 ft (4 meters) of cable. Iif the velocity factor was 1.00 the wavelength would be 16 meters, the frequency 18.75 MHz. The frequency of the center of the notch is 15.7 MHz, so the measured velocity factor is 15.7 / 18.75 = 0.84.

Next I used a 9 ft 3 inch (2.85 meter) cable. The wavelength for a velocity factor of 1.00 would be 11.38 meters, the frequency 26.35 MHz. The frequency of the center of the notch was 21.8 MHz, so the measured velocity factor is 0.83.

Using both cables, the total length is 6.85 meters, the wavelength for a velocity factor of 1.00 would be 27.4 meters, the frequency 10.95 MHz. The frequency of the center of the notch was 9.1 MHz, so the measured velocity factor is 0.83.

For this piece of coax, the velocity factor seems to be 0.83, which is a reasonable value.

Boom Box Radio Early Morning Propagation Analysis

Boom Box Radio had an early morning transmission on March 10, 2013, from 1044 until 1212 UTC. They were trying to reach a listener in Guatemala. The time of this transmission, starting just before to after sunrise, lets us examine the effects of sunrise on reception on the 43 meter band.

This first waterfall shows when Boom Box Radio signed on at 1044 UTC. You can see a very faint trace appear on the waterfall about a quarter of the way up from the bottom, at 6925 kHz. Remember that with a waterfall, time flows or falls down, like with a real waterfall, so the latest information is at the top:

This next waterfall shows what happened at 1107 UTC, when the signal went from just a faint trace of a carrier on the waterfall, and no audio, to a very good S7 to S9:

Note again that the oldest information as at the bottom of the waterfall. At that time, there is just barely a carrier. Then you start to see some modulation, and then finally, in a matter of seconds, the signal shoots up to armchair quality.

Below is a graph showing the signal strength of Boom Box Radio, in dBm, from 1044 UTC sign on, until 1212 UTC sign off. You can click on it to see a larger version:

An S9 signal corresponds to -73 dBm. Every S unit is 6 dBm, so S8 is -79 dBm, S7 is -85 dBm, etc.

I have annotated several important times: The 1044 UTC sign on, 1107 UTC when the signal went up, 1125 UTC which was local sunrise, and 1212 UTC when it went off the air.

You can see that there is a very slow increase in signal level after the sign on, but the signal remains extremely weak. Then suddenly at 1107 UTC, the signal shot up to S9. Then for the rest of the transmission it mostly stayed in a range between S7 and S9.

The sudden increase in signal was caused by the Sun increasing the ionization level of the F layer of the ionosphere. This increase needs to have occurred at the point in the ionosphere where the radio waves are being reflected, most likely roughly midway between the transmitter and receiver locations. Note that in my case, this occurred before my local sunrise. This could be due two at least two factors I can think of. First, the transmitter site could be to my east. Second, the ionosphere is several hundred miles up, so it experiences sunrise before a point directly below it (on the Earth’s surface) does.

I believe this graph shows the importance of selecting the correct time for transmissions, depending on your target area. Just before sunrise is when the ionosphere is the weakest, and is only able to reflect radio waves on 43 meters at low angles. Too early in the morning, and the band is not open for local (NVIS – Near Vertical Incidence Skywave) reception. The band is, however, open for reception to more distant locations, that is, more than many hundreds of miles away (well over 500, perhaps close to 1,000 miles). If you’re trying to get out to DX locations, this is a good time to do it. Sunrise varies throughout the year, so as we move into summer, and it occurs earlier, the band will likewise open up earlier for NVIS. Likewise in the middle of winter in December, it is somewhat later.

For reference, the operator of Boom Box Radio stated that this was a Heathkit DX-60 transmitter putting out 40 watts into a 40 meter band dipole that was about 15 feet high.

I thank Boom Box Radio for conducting this early morning test.

Update: The operator contacted me again to mention that his local sunrise was at exactly 1107 UTC.

Decoding ADS-B Aircraft Transponders: An SDR for $17 – The R820T USB RTL-SDR DVB-T Dongle – Part 3

Please be sure to read Part 1 and Part 2, if you’re new to this series of articles.

All aircraft contain a piece of avionics technology called a transponder. This contains a receiver, and a transmitter. When the signal from ground radar is received, the transponder transmits a short burst on 1090 MHz, encoded with information.

There are several possible replies from an aircraft transponder:

  • Mode A replies with a target ID code
  • Mode B replies with the barometric altitude of the plane
  • Mode S, also called the Extended Squitter, is the one we’re interested in.

Mode S, also called ADS-B allows a variety of types of data to be sent from the transponder, including:

  • ICAO aircraft code (the tail number of the plane can be obtained from this)
  • Flight Number
  • Altitude
  • Location (Longitude and Latitude)
  • Heading

There’s an online document called ADS-B for Dummies that goes through the various messages, and their format.

Since the RTL dongles can receive 1090 MHz at a wide bandwidth, it turns out to be possible to use them as low cost transponder decoders. Very low cost. You can pick them up for around $15 on eBay. Dedicated ADS-B receiver packages are more. Much more. As in hundreds of dollars.

There are quite a few packages out for the RTL dongles that decode ADS-B transmissions. For Windows, there’s ADSB#:

For linux and Mac OS X, there’s Dump1090

I compiled Dump1090 for Mac OS X, here is what the output looks like:

The columns across the screen:

  • Hex – the ICAO code for the plane
  • Flight – flight number
  • Altitude – altitude in feet
  • Speed – speed in mph
  • Lat – latitude of position
  • Lon – longitude of position
  • Track – heading in degrees
  • Messages – the number of messages from this plane that have been received
  • Seen – how long ago (in seconds) since the last message from the plane, that is, how long since it has been last seen (or heard from)

I’ve since ported the Dump1090 code over to Cocoa on Mac OS X, resulting in Cocoa1090:

Cocoa1090 uses the ICAO hex code to derive the tail number (and aircraft model) from a database in a text file, which are also displayed.

A beta version of Cocoa1090 can be downloaded here: http://www.blackcatsystems.com/software/cocoa1090.html

Spying on your neighbor’s grill thermometer – Monitoring the 433.92 MHz ISM Band with an RTL Dongle

Remote weather stations, some car key fobs (although many in the US use 315 MHz), wireless grill thermometers, and many other devices use the 433.92 MHz ISM (Industrial, Scientific and Medical) band. Chances are good that if it is a wireless sensor, it uses this band.

Here is a waterfall showing transmissions observed here, using one of the inexpensive USB RTL DVB-TV Dongles:

The entire waterfall occupies 139 seconds.

You can observe several periodic transmissions. I have a remote weather station and a remote thermometer, so that accounts for two of them.

If you have an RTL tuner dongle, take a look and see what 433 MHz transmissions are occurring near you.

An SDR for $17 – The R820T USB RTL-SDR DVB-T Dongle – Part 2

Earlier, I wrote about the RTL2832U based USB TV tuner dongles that can be turned in an inexpensive Software Defined Radio (SDR). Please take a moment to read that for an overview of these insanely great (for the price) modules, if they’re new to you. I’ve since mounted the dongle in a small metal enclosure:

There were two reasons for this, first to reduce noise pickup, the second was to easily add an F style antenna connector.

Next, I wanted to try getting the rtl-sdr series of command line programs to run. I had tried a set of pre built binaries, but they didn’t work, so I decided to build it myself.

First I got the code from http://cgit.osmocom.org/cgit/rtl-sdr/

I followed the instructions from http://sdr.osmocom.org/trac/wiki/rtl-sdr
cd rtl-sdr/
autoreconf -i
./configure
make
sudo make install
sudo ldconfig

The first problem was after ./configure, namely:
configure: error: Package requirements (libusb-1.0 >= 1.0) were not met:

Turns out I had an ancient version of libusb.
sudo port install libusb
solved that.

With the programs built, the next step was running rtl_test:
$ rtl_test -t
Found 1 device(s):
0: ezcap USB 2.0 DVB-T/DAB/FM dongle

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
No E4000 tuner found, aborting.

So far so good.

Next I tried running rtl_fm, which lets you demodulate a FM signal. AM is supposedly also supported. I say supposedly because I could not get rtl_fm to work properly. It would run, and write demodulated sound data to a file, but playing it back always produced gibberish. Also, the files were way too large for the specified sample rate and length of time the program was running. The documentation for rtl_fm is sketchy, even by open sores standards. For example, the list of options includes:
[-s sample_rate (default: 24k)]

which naturally makes you suspect -s sets the sample rate. It does no such thing, it actually sets the IF bandwidth. Again, supposedly.

After several hours of trying to get rtl_fm to work properly, I threw in the towel, and moved on to rtl_tcp, which acts as a little TCP server, sending I/Q data to a connected client. I had much better luck here. Running the program produced the following:
$ ./rtl_tcp
Found 1 device(s).
Found Rafael Micro R820T tuner
Using ezcap USB 2.0 DVB-T/DAB/FM dongle
Tuned to 100000000 Hz.
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).

I then connected to it via telnet in another console window:
$ telnet 127.0.0 1234

And the rtl_tcp server program responded with:
client accepted!
and proceeded to send I/Q data to my telnet session, which spewed it to the window. Mission accomplished.

Next I wrote a small program to open a connection to the rtl_tcp server, and grab all the received data, count the number of bytes per second, and display it once per second, as a quick and dirty test to see if everything was working OK. I got around 4M bytes per second, which is correctly for a 2 MHz sample rate (the data is 8 bit I/Q, so there are two bytes per sample).

Having accomplished this, the next step was to make some use of the data. I thought trying to decode and display ADS-B aircraft transponder messages on 1090 MHz would be fun. That is my next post.

An SDR for $17 – The R820T USB RTL-SDR DVB-T Dongle

You may have heard of the latest SDR craze to hit the radio hobby – the RTL based USB dongle TV tuners. These were originally made to receive and decode the European standard digital television broadcasts. An enterprising hobbyist discovered that they can be tuned throughout the VHF and UHF range, and that you can get at the raw sampled data from the onboard A/D converter (only 8 bit, however). This allows them to be used as a very inexpensive Software Defined Radio (SDR) for VHF and UHF. How inexpensive? Mine was $17 shipped, although you can find them for even less, if you’re willing to get them direct from China and wait a few weeks for delivery.

Here is what I got:

There’s the dongle itself, as well as the small (about 4″) antenna.

It’s interested to note that the enclosure actually says SDR on it, the word has apparently gotten out about the SDR applications for this dongle, and someone is private branding them.

Here’s what the inside looks like:

The USB connector is on the left, the MCX style RF connector is on the upper right.

There are control programs available for Windows, Mac OS X, and Linux. For software, first I decided to try rtl-sdr I copied the libraries to the specified locations, restarted, and was greeted with:

>:rtlsdr_osx cps$ rtl_test -t
Found 1 device(s):
0: ezcap USB 2.0 DVB-T/DAB/FM dongle

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Failed to open rtlsdr device #0.

It’s possible this is an older version of the rtl-sdr package, that expects the E4000 tuner chip. (Although a less cryptic error message would sure be helpful)

Then I tried Cocoa Radio. It crashes on launch. So far open sores is zero for two.

So next I tried the Mac OS X port of gqrx. Much better! It came right up, and within a minute I was receiving FM broadcast stations. I have noticed that if I make a change to the sample rate, I need to quit and re-start the app before putting it into run mode, or it crashes.

The sensitivity is not bad, I was able to pick up stations about 50 or 60 miles away using the included tiny 4″ antenna, laying on my desk.

Below is a screenshot of gqrx running on the FM band, you can see three FM broadcast stations, at 97.9, 98.5 and 99.1 MHz, the latter is tuned in for demodulation.:

I was also able to pick up 2m packet radio transmissions on 144.39 MHz, and one of the NOAA weather radio stations, on 162.525 MHz.

There are many varieties of these TV tuner dongles out there, mostly the difference is the RF tuner chip used. Previously the E4000 tuner was the preferred one for SDR applications, as it had the widest tuning range, although with a gap in the middle. It apparently is no longer made and is difficult to find tuners that use it. Currently the R820T tuner chip seems to be the preferred one for SDR use, the tuning range is slightly less, but there is no gap. Some eBay vendors identify the chip used, many do not, but there are lists online of the various USB dongles by brand name and model number, with the tuner chip specified, such as here.

My next project was mounting the dongle in a small metal enclosure, with a different RF connector, so I can easily connect one of my existing outdoor antennas to it. Read all about it here.

mySdrPlayback – Mac OS X App to Play Back SDR I/Q Recording Files

I use an RFSpace netSDR to record the 43 meter (6800-7000 kHz) pirate radio band, overnight and often in the daytime as well. I then go back and check the recordings, to see what stations have been on the air. This lets me catch lots of broadcasts even when I am away from the shack.

Going through the recordings with traditional SDR software can be extremely tedious. You literally have to play the recordings at a real time rate, hoping to stumble across a transmission. Even being able to skip ahead and back is not much better.

So I ended up writing my own app to make the process of analyzing SDR recordings for interesting transmissions much easier and faster. I’ve just recently made this app available for others to download and use. It’s called mySdrPlayback (although it could probably use a more catchy name).

This is what the program window looks like (click on it for an enlarged image):

When the app loads, it reads in a list of all the recording files from the directory you have told it they are stored in. Clicking on a file loads it. A waterfall of the entire file is created, that is what you see in the large area on the right side of the window. The x axis is frequency, the y axis is time. Any transmissions are immediately obvious, such as a pirate on 6925 in AM mode, as well as WWCR, also in AM mode, on 6875 kHz. SSB and the various digital modes also have distinctive visual appearances. In no time, you can tell what type of transmission it is just by looking at it.

Files created by SpectraVue, the SDR app that RF Space supplies with their radios, SdrDx, the third party app also for RF Space radios, as well as files created by Perseus can be read. Other file types could probably also be added, if their exact format is known.

Selecting a portion of the recording file to play back could not be easier. Just drag select with the mouse by drawing a rectangle around it. Select the mode, and click Play. The frequency and time limits are displayed in the Secs Start/End and Demod fields when you drag select, you can also edit them in the boxes by hand if needed, to fine tune things.

The buttons to the left and right of Play let you skip playback behind or ahead by 10, 30, or 60 second increments, or even by 5 minutes. This makes it easy to jump around, looking for an ID. An S meter updates during playback, showing the signal strength in dBm.

The Demod To File button will demodulated the entire selected transmission to a WAVE file. You can then feed that into a decoding program, such as MultiMode if you want to decode an SSTV or other digital mode. You can also convert it to an mp3 file using your own utility, if you want to post it for others to download.

mySdrPlayback is only available for Mac OS X. There is no windows or linux version, and there never will be one. It’s written in objective-c and uses the extremely powerful and feature rich cocoa API. That makes development extremely easy, but is only available for the Mac. It can be downloaded from the program page: http://www.blackcatsystems.com/software/sdr_iq_recording_playback_program.html

Lies, Damned Lies, and Receiver Images

I have my SDR-14 receiver online, for some listeners to use. The other day, there was a logging of Trenton military aviation weather on 6950 kHz. I had not seen other reports of Trenton aviation weather on this frequency. And, since 6950 is a very popular frequency for pirate radio in the USA, this could cause some concern, as QRMing military stations is generally bad karma for pirates.

Here is a recording of Trenton Aviation as received on the SDR-14.

As it turns out, I had been running a recording of 6800-7000 kHz via another SDR, my netSDR. So I went back, and checked that recording at the same time the SDR-14 had picked up Trenton on 6950. Nothing. Nothing at all. And the netSDR is connected to a much better antenna than the SDR-14. Hmm. This is strange.

Last night, I was alerted that Trenton was again being heard on the SDR-14 on 6950 kHz. So I went and tuned in on the netSDR, and again heard nothing. I then decided to look for a schedule of frequencies used by Trenton, and found that they should be on 6754 kHz. I tuned in, and sure enough, there they were. Coming in very well, about S9+30 dB or so. Hmm… I did a quick calculation, and the difference between 6950 kHz and 6754 kHz is 196 kHz. 196 kHz, that sounds familiar. Why yes, that’s the I/Q sample rate of the SDR-14!

Now it all makes sense – the received signal on 6950 kHz is an image, a false signal generated by the receiver. It turns out that even SDRs are not immune to images. (Shhh… don’t anyone tell Al Fansome)

Images have been the bane of DXers for decades. They often manifest themselves as a particularly strong signal that is picked up on other frequencies. With an analog receiver, these frequencies are often offset from the actual frequency by the IF frequency of the receiver. With VHF/UHF radios and scanners, this is often 10.7 MHz, or close to that. In the case of the SDR-14, the image was located at an offset equal to the I/Q data rate. It was probably being heard on 6558 kHz (6754 kHz – 196 kHz) as well.

If you’re hearing an unexpected signal, one suggestion is to try another radio, ideally one with a different IF frequency. If you don’t hear the signal on the second radio, then it is most likely an image. Or your other radio is broken. But it’s probably an image. Ask another DXer if they can hear it, as well.

There’s a ham in Erie, PA that has been harassing the local club that runs a 2 meter repeater with claims of interference to the VHF marine band. The FCC has investigated, and found no interference. Multiple hams have contacted the Coast Guard and they have not had any interference issues. The only person who reports interference is the previously mentioned ham, who lives a few hundred yards from the building housing the repeater. I’ll close by noting that the VHF marine band is about 10.7 MHz above the 2 meter band frequency used by the repeater – 146.610 MHz.

New version of SdrDx available, now for Windows also

There’s a new version of SdrDx, the free app for RF Space SDRs (SDR-IQ, SDR-14, netSDR, etc): http://fyngyrz.com/?p=915

This version includes a lot of new features, including recording I/Q data directly to disk, so you can then play it back. Think of it as a VCR. You can, for example, record the entire 43 meter band (6800-7000 kHz or so, depending on your SDR model) and then go back later and run the I/Q recording back through SdrDx again. It’s awesome! Previously I’ve had to run SpectraVue under vmware to do this, now I can do it natively on the Mac.

I use a program I’ve written myself, that reads in the I/Q data file, and plots a waterfall for the entire file. I can then selectively demodulate what signals I want. I can record all of 43 meters overnight, then check in the morning to see who was on, and listen in. I don’t miss anything, nor do I have to choose if there’s two, or even three pirates on at the same time. I can listen to all of them. At some point I may release this for others to use (Mac OS X only) but it’s still pretty crude right now.

There’s lots of other new features and improvements to SdrDx, so if you have an RF Space SDR, go download a copy to try out.

GPS Disciplined 10 MHz Reference

Some time ago, I wrote about the Rubidium reference that I connected to SDR. The reference supplies a very stable and precise 10 MHz reference clock to the SDR, so that the sample rate does not drift. Drift in the sample rate causes drift in the received frequency, much like drift in the various oscillators in a conventional radio causes drift.

Just today, I replaced the Rubidium reference with a GPS disciplined reference.

Here’s what I got:

The reference itself is the box in the center. To the right is the power supply, to the left is the antenna.

A GPS disciplined reference or oscillator uses timing signals from the GPS satellites to control,or “discipline” the oscillator built into the reference using a tracking loop. The 10 MHz output is continuously adjusted to keep it at the correct frequency, usually by making very small adjustments and using long time constants (averaging periods), typically around 100 seconds or more.

The 10 MHz output from the reference connects to an input on the netSDR. Internally, that 10 MHz signal is used to produce an 80 MHz clock that is used to drive the A/D sampling.

Here is what the inside of the reference looks like:

Here’s a plot of WWV on 10 MHz:

I believe the frequency shifts you see are due to doppler effects in the ionosphere.

Now I can figure out exactly what frequency Captain Morgan is on.