Posts Tagged SDR
I recently got a pair of the Nuand BladeRF SDR transceivers, and I’ve got about a days worth of experience with them. Of course, first thing’s first, I had to print the BladeRF Coaster by Piranha32. This is especially so because there are a few large tantalum-looking capacitors on the bottom. Before I had this printed, I used some small machine screws with bolts and made a quick set of standoffs. The package came with a nice blue USB3 cable and a pair of SMA jumpers; I assume these would go to their transverter, which I don’t have, but they’re nice to have anyway. There aren’t any instructions in the box, but for a product like this the assumption is that the user knows what they’re getting and how to use it. This is a reasonable assumption, and I had no problem finding all the relevant documentation.
I’m an ardent mac user, and this sometimes poses a problem while using specialized hardware and applications. It wasn’t until the last few months that the recent versions of GNURadio worked through MacPorts. Luckily it does now, as does all the BladeRF software. Going from nothing to a working software environment took minutes. One thing that you have to make sure and do it download the most recent FPGA code, as you’ll have to re-load it every time you boot the BladeRF.
All software defined radios have an Achilles’ heel. If the DC offset of the I and Q baseband signals isn’t minimized a constant “tone” at zero Hz will be up-converted to whatever frequency the final spectrum is. Also, if the relative magnitude and phase of I and Q aren’t matched (and precisely 90 degrees) there will be a image of the desired signal mirrored across the up-converter frequency. The BladeRF wiki has a short article that shows how to measure the correction factors to use to minimize these effects. This article documents my attempt of deriving the correction factors for one of the two boards.
To start, I tuned the board to 450MHz. Then, I decided that a 100KHz sine would be appropriate as a baseband tone. What happens is that, in software, the 100KHz tone is generated, then it is up-converted to 450.1MHz. The spectrum below is the result of that test without any corrections applied. The spur resulting from the DC error is about 25dB down from the desired carrier, and the image is closer to 35dB down. It’s not really that great.
Playing around with the values according to the instructions, I was able to improve these results quite a bit. The DC error is now 58dB down from the carrier (ignore the marker table) and the image is almost 63dB down. This is pretty respectable. Now, there is another troubling question. What’s up with the spikes in the phase noise?
I asked on the #bladerf room on freenode, and they agree that it’s not normal. The spikes are exactly 7.8 KHz apart, so I would start looking for things that happen at that frequency. I wish I had measured how distant the largest one was from the carrier and zero. That could have been good to know.
Oh, wait, I did :). The main tone is 63KHz away from the main carrier and 37KHz away from zero. There was some speculation that it could be artifacts from the quantization of the software-generated sine wave or that the tuning algorithm could be at fault. For fun, I ran the same test without generating any sine wave at all, so all you’re seeing is a large zero tone from a constant DC offset. I do think that the quantization explanation makes sense because that would manifest as phase noise, and the spikes are centered about the modulated tone, rather than the zero-spur.
The same artifacts should still appear there if there was any kind of a problem with the power supplies of the board, for example. It seems very clean, and I’m happy with the phase noise performance of the board. You’re probably seeing the phase noise of the rigol in this plot rather than the BladeRF.
In all, so far, I’m very happy this these. I’m very excited about their potential.
The National Oceanic and Atmospheric Administration (NOAA) manages a few satellites in low earth orbit. There are three actively transmitting APT signals at the moment, NOAA15, 17, and 18. Each of these satellites passes overhead a few times a day. I’ve been interested in learning how to receive their signals for a while now, and I’ve finally succeeded!
A bit ago, I bought a “SoftRock” SDR (Software Defined Radio, read the excellent 3-part article by Bob Larkin at the ARRL site.) receiver kit from Tony Parks. (A note about his site, he puts a few kits up for sale a few times a month, so he’s almost always sold out.) I think SDR is really, really interesting. I don’t want to get too bogged down in the details of it, because it’s not the point of this post, but I’m going to briefly discuss it. Basically, the idea is that you want to have some minimum amount of electronics to deal with the antenna; letting your computer handle the rest. This can take a variety of forms, but the simplest is the QSD, or Quadrature Sampling Detector.
It sounds complex, but it’s quite like using a strobe light to look at a spinning wheel. The bright light of the strobe “samples” the world at a given interval. If it strobe rate matches the speed of the wheel, the wheel appears still. Stretching the analogy a bit further, imagine that information is written on the wheel. Using the strobe you can read it, even if it’s spinning. While that is an awful analogy, but the idea is that we can sample the radio signal at (nearly) the same frequency as the carrier of our desired signal. When we do this, the signal we want magically appears at the output. If we’re using AM (or its derivatives such as LSB or USB) we can even listen to it directly. It only gets a bit more complex when we consider the quadrature part. Quadrature just means “90 degrees out of phase.” Using another copy of the radio signal, and a sampling clock in quadrature, we can cancel out some noise and interfering signals. Sorry for the tangent, if you read this far (without falling asleep), I recommend you read the linked articles at the top of this paragraph. The math isn’t too hard, and it’s sooo powerful!
This isn’t an image of my SoftRock, it’s a slightly different version, but I don’t have an image handy. It’s a really easy kit to build, and it’s fairly inexpensive. More than that, it’s really easy to use. Once it’s all setup, you just attach it to your computer, power it, and install the antenna!
Once you’ve attached the receiver hardware to your computer, you need some software to use it. This is an image I took of a very well written SDR program on the Mac called DSP Radio. On the left side of the spectrum window, there is the live radio spectrum coming from the satellite. The green box around it represents the bandwidth of my software radio receiver. In a traditional radio, this bandwidth would be set by a filter circuit. Most communication radios only have about 15 kHz of bandwidth. This makes them unable to properly receive satellite weather images. Traditionally, you would have to build or buy a specially-built satellite receiver. With SDR, I can move a slider to scale the bandwidth way, way up! In this case, I’m using about 37 kHz of bandwidth! Notice that there’s all this empty space on the right, this is radio spectrum that I’m receiving, but there’s nothing there. Maybe you can notice the shadow of the satellite data on the right; this is an “image.” These images are the bane of all radio designers. The true test of a receiver (other than sensitivity) is how well these images are suppressed. In this case, they’re suppressed rather well, notice how bright the lines are on the left compared to the right.
The DSP Radio program takes the signals from the Softrock through the audio input of the computer. When you have something tuned in through its interface the demodulated signal appears at the audio output. I’ve been recording these signals as well as passing them to another program called WXtoIMG. This program is not great, I’ll be honest. It’s barely maintained, and you can tell it’s an ugly cross-platform mess. To even get it to work is tricky. But, what it does, it does well. The image at the head of this post was generated using it. When I made that image, I literally had to connect the audio out of one computer to the audio in of another. I’m not sure how I’m going to get around that issue. It can accept data in the form of wav files, provided that they’re linear PCM sampled at 11,025 Hz with at least 16 bit samples. The problem is that the nice political boundaries, lat/lon lines and ground image comes from the program. It does this by computing the location of the satellite and where on the earth its photographing. It has to decode the audio in real time for this to work, which means that I can’t use an audio file. For you to play around with, if you wish, I’ve included a sample wav file. It starts before the satellite pass and ends after, so if begins and ends with static.
NOAA15-baseband.wav (large file warning: 28 MB)
The included audio can be used to create the image below. I used WXtoImg to generate it, though the open source WXAPT could be used under Linux. This image was taken when the satellite was traveling south-north, so I had to flip it vertically and horizontally. On the right side of the image is the A channel, which is visible light, and the left side is the B channel, infrared. Normally, these channels are reversed left-to-right. The stripes and color bars help the decoder line up the image and adjust brightness, contrast, and gamma. (Right-click here to download full-size image: 2080 x 1260 pixels)
My next step is to write some shell scripts on a Linux box to automate this whole process. My goal is to have a page that has the latest satellite image and an archive available at all time. But first, I have to write a post about the antenna I built to receive these signals. Stay tuned!
This post has a specific audience in mind, so unless you have, or are interested in a Softrock Ensemble VHF receiver, you’ll be bored. You’ve been warned 🙂 There are a few radio bands that are interesting near the ham 2 meter band. NOAA weather satellites send images using APT at and around 137 Mhz and there are weather broadcasts at 162.5. There was a question on the mailing list for the Softrock about whether it could be tuned to receive signals in all of these bands without re-tuning. This post is simply documenting my experimentation with the front end. I’m sampling the signal using an oscilloscope probe with the 10x setting and inserting the signal from the tracking generator connected to the antenna port. It’s not really possible to measure the precise insertion loss absolutely, so I’ll measure it relative to the baseline of front end tuned for 2 meters.
To begin the testing, I tuned as best I can to the 2M band. The filter shape isn’t as flat as I would like, but it’s the best I could do.
It was a little easier to tune the front end for NOAA APT transmissions. I got a better filter shape, and about 5 dB better average insertion loss.
Tuning for weather radio wasn’t that bad either. The average insertion loss is about equal to what I got for 2 meters.
Finally, if you’re interesting in receiving signals from throughout the band, it’s possible strike a compromise. You’re just about always going to get a peaked response, so I placed the lower peak at 137 Mhz and the upper at 165. The 2 meter ham band is somewhere in the middle. The peaks at 137 and 165 are 5-10 dB below the baseline. The 2 meter band is a little worse at about 20 dB below the baseline. So, it’s possible to get a somewhat broadband response at the fronted at the expense of some signal strength. It may be possible to mitigate some of this if you use a low noise preamplifier.