Alternet

R820t tuner on a rtl-sdr compatible dongle, from eBay seller CosyCave

Relating to the rtl-sdr work that has been done, the E4000 tuner was the standard barer for a long time.  However, Elonics has discontinued this part, and it’s becoming difficult to find.  The popularity, and scarcity, of this part has encouraged sellers to offer products claiming to be built with the E4000 and are not.  Luckily, someone discovered the code for using the R820t tuner in the Linux V4Lin drivers.  They ported this code into the rtl-sdr source maintained by osmocom.

I just finished porting their code into Cocoa Radio.  Now, it’s possible to use my software with both the E4000 and the R820t.  On startup, Cocoa Radio will automatically detect which tuner you’re using and perform the appropriate actions.

It did take a little while to finish this work, and there are several more tuners out there.  If you are desperate for support of a specific tuner, you can donate a device for the cause and I’ll try to support it.  By the way, Softshell uses the same code for tuning as Cocoa Radio, if you recompile softshell, it should include this new code.

All the relevant code and binaries are, as usual, available at github.  Make absolutely sure that you also update the softshell repository!

Share on Facebook

Cocoa radio interface explained (click for full size)

Well, I’m back from vacation and I want to tell everyone about a new version of Cocoa Radio (my application for demodulating radio signals using the rtlsdr dongles on mac os x, written in Objective C).  This version seems to be running really well.  I’ve set the sample rate to 1024000 samples per second for the moment (though this value can be changed in the code), and at this rate everything seems really stable.  Please give it a try and create issues at the github issues page if you find any problems.  I should say that I’m a little tired of working on it, so unless there are major issues I’ll be working on other projects for a while.  I encourage others to take a look at the code if they’re interested in SDR.  It’s not as scary as it looks!

Also, the sliders are a little buggy (especially the bandwidth ones).  Move the a little bit once the app starts up and they’ll work correctly.

Finally, I don’t have any support for AM (amplitude modulation) yet.  It’s an easy modulation type, and I may add it soon.

Share on Facebook

I’ve been working on a stand-alone software defined radio (SDR) application for Mac OS on-and-off for a few months, and I think it’s good enough now to encourage people to test it and provide feedback.  Though it’s possible, of course, to do everything my app does in GNU Radio, it’s much more convenient to have a dedicated app.  Especially because this app uses a lot less CPU than GNU Radio.

This video shows the basic operation of the user interface:

And this one shows an ‘inside peek’ at what happens to the signal inside of the application. In normal usage, the waterfall display won’t do this, but it’s an interesting effect:

There are still many, many bugs, but it should be enough to play around with. I’ve been able to listen to broadcast FM radio for some time using the app. There is no squelch control, that’s on the list of things to add. Also, it’s possible to get audio buffer underruns. It’s likely caused by slight differences in the clock rate of the rtl-sdr dongle and the audio device that you’re using.

If you notice any bugs, or have specific issues that you would like addressed, please create an issue on the github page.  Also, if you are able to contribute, please let me know.  I’m obviously in need of some GUI assistance!

One word of advice, don’t try to change the modulation type using the drop-down menu, it doesn’t work!

Again, code is available at github, as is an application binary.

Share on Facebook

It has been a little while since I released the very early code for softshell (not that the code has advanced much), and I’ve received a few requests for a bit more information about how it’s intended to be used.

I admit that I hacked it together very quickly so that I could make some basic use of the rtlsdr dongles on my mac.  To be very clear, Softshell does no actual SDR itself.  You can really look at it more like a driver for the rtlsdr.  Softshell opens a connection to the rtl device, allows you to tune its internal oscillator, and puts the data on the network.

To start, install the rtl device in your USB port, then open Softshell.

Freshly opened

If you see a similar window, it means that Softshell has found your device (the ezcap in this case).  It is, perhaps, a good time to mention that I’ve only ported the tuner code for the Elonics E4000 tuner.  Click the “Open” button to have the program open the connection to the device.  If it detects that you have the E4000 the “Tuner type” field will be filled in with “Elonics E4000.”

Once this is done, changes to the sample rate and center frequency will take effect with the “Update” button is clicked.  The Center frequency is provided in Hz.

Now, that’s all fine and good, but you’re just tuning the device.  To actually get the data out of it, you need to setup the network settings.  Choose a port number for Softshell to listen to, I use “12345,” and click the “Running” checkbox.

Finally, in GnuRadio, you need to use a “TCP Source” block setup as a client with the same port number you used before.

Setting up GnuRadio to work with Softshell (click for full size)

Once that’s done you should be up & running.  Note that, natively, the rtl device actually outputs unsigned bytes and that Softshell converts these to floats centered around zero.  Some GnuRadio examples include the blocks that perform this conversion.  If you come across this, just remove those blocks.

Good luck!  Please feel free to comment with any questions or issues!

Share on Facebook

Here’s a compiled executable, including the rtl-sdr library, for those that don’t want to get the source on github and compile it.

Also, if anyone wants to design a logo, it would be much appreciated!

Softshell-alpha

Share on Facebook

Softshell works!

Basic functionality of Softshell works!  In the image above, you can see the app (Cocoa-rtl-sdr is the old name) on the right.  I didn’t even have the text boxes wired in yet for the sample rate and center frequency, because I was so excited that it was working.  The samples from the receiver are transported into GNU radio over TCP where a simple FFT is being performed.  Notice that all the extra blocks needed for the original rtl-sdr aren’t needed, because I’m doing all of the uchar  to float conversion inside of Softshell.

The code that’s available on GitHub was hacked together with some network code that I can’t release right now, but I’m going to move it over to code that I can use soon.

Update:

Here’s a pre-compiled application for those that don’t feel like compiling it:

Softshell-alpha

Share on Facebook

I’ve made significant progress porting over the rtl-sdr code.  I added printfs to every function that interfaces with the USB port so that I can compare what happens.  Everything seems normal, up until the gainControl function.  Once there, the returns from my application are usually about one digit off of the rtl-sdr code.  If anyone has any ideas, I’d love to hear them!

Link to the comparison spreadsheet.

Share on Facebook

For the uninitiated, a few months ago one of the developers in the V4L (video for linux)/DVB (digital video broadcasting) team,  Antti Palosaari, discovered that this cheap video tuner dongle could be used as a software defined radio.  Since then, it has developed a HUGE following!  The team over at osmocom helped to package the driver into a separate executable.  The application seems to work well, and even compiles on the mac.  The problem is, though, that you have to install the libusb library for it to work.  It’s not hard to do, but you have to install mac ports, then install libusb.  What a pain.

Most of the active discussion about rtlsdr appears to be happening at the RTLSDR subreddit.

RTL SDR compatible dongle

The idea behind Softshell is to port the osmocom rtl-sdr code into a native Cocoa application that doesn’t need libusb.  I’ve published the code to github, but it’s still very early in the development process.

This post is just meant as a heads-up for anyone with Objective-C experience and an interest.

Share on Facebook

That looks neat, but it's very, very bad...

If there’s one thing that I was blissfully ignorant of before trying to build a spectrum analyzer, that is now an annoyance and borderline obsession, it’s phase noise.  Phase noise is exactly the same as any other kind of noise, but unlike noise on a DC signal, phase noise is mode like tiny variations in the frequency of the signal.

To get a little more specific, think about phase as a quantity that describes how far along the sine wave we are at any given instant.  It can be described in degrees, radians, or even if you’re a little radical, tau radians.  The idea is the same.  Phase increases until it “rolls over” at the end of the cycle.  It looks a bit like a sawtooth wave, assuming that we’re discussing a constant frequency, unmodulated wave.  Hopefully you believe me that phase noise looks just like noise superimposed on the sawtooth-shaped phase ramp.

Phase related to sine

I think the graphs above helps to illustrates the relationship between phase (above) and a sine wave (below).  I’ve re-scaled the phase so that it goes from zero to one over the range of one whole number.

In the frequency domain, phase noise is a little easier to understand, and see.  The graph at the head of this article is an extreme example of phase noise.  Really, there are two kinds of phase noise here, and one of them we can do something about.

PLL example (From a Linear Technology data sheet)

I tried really hard to find some nice graphics to use to describe, simply, the basic operation of a PLL-based oscillator.  The best I could come up with is the above diagram.  This was lifted from the Linear Technology LMX2326 PLL IC.  This is the same (or damn near) as the PLL chip that’s used in the analyzer.  The bottom left corner is the oscillator.  All it does it generate a single frequency set by the voltage coming into pin 6.  On the PLL chip, pin 2 is the output from the “charge pump,” which is how the PLL sets the tuning voltage.

PLO1 Schematic (by Scotty)

Unfortunately, the PLL in the spectrum analyzer isn’t this simple (if you can call an normal PLL simple!).  In the center, near the top, notice the Op-Amp.  The high-side supply to this amplifier is +20 volts (at least).  The reason for this is as simple as that’s what the VCO (voltage controlled oscillator) needs.  It isn’t possible for the PLL to produce voltages like this, so we need this extra supply.

VCO power supply noise

Now, the question is: “What happens when there’s noise on the +20 voltage supply?”  The waveform on the oscilloscope above shows about 20mV of noise on the 20 volt supply.  The frequency of this noise is about 20kHz. It’s no coincidence that the spacing between the peaks in the comb-like plot is about 20kHz.  What’s happening is that the noise on the 20 volt supply is literally modulating the output.  Incidentally, that’s exactly what you do if you want to frequency modulate something.

Now that we know what the cause is, what can we do about it?  If we eliminate that noise, we can fix the problem.  I had made a second 20 volt supply, and used cheap capacitors.  Apparently, when using high voltages (relatively speaking) the amount of capacitance decreases in cheap, small, ceramic capacitors.  I went back to the first supply I made, and added even more capacitance.

Better +20 volt supply

The lower trace is the new +20 volt supply, and it’s peak-to-peak noise voltage is about 3mV.  But the proof of the pudding is in the eating, so how does it affect the phase noise?

Much improved phase noise

It squashes it like a bug!  The above plot is almost textbook for phase noise.  The large peak in the center is representing the width of the final filter (I’ll get to that in a later post) and the skirt is caused by traditional phase noise.  If I zoom in to the center of that plot it’s easier to see:

close in phase noise

Here, I’ve highlighted another common cause of phase noise: PLL loop bandwidth.  This is the bandwidth of the filter that smooths out the pulses that come out of the PLL chip.

That’s all I have for now…  I’ve tried to make this topic, which is very technical and dry, interesting and accessible to those that haven’t spent the last 5 years trying to build a spectrum analyzer.  I hope you’ve enjoyed it.

If you want a much more in-depth and technical analysis, see Scotty’s website.

Share on Facebook

Beautiful new frame for my SA

I haven’t posted for a while.  I’m sorry.  I was being selfish.  I’ve made fantastic progress on my spectrum analyzer build, and it’s so much fun that I haven’t had the will to pull myself away and post about it.

Also, completely unrelated to the build, I’ve experimented with a service called “Cloudflare” as a way to make my site more resilient.  It doesn’t, it’s MUCH worse.  I’m not happy with it at all.  I’ve shut it down, so hopefully once the DNS changes propagate it’ll be more stable.

Anyway, back to topic.  The last post about the analyzer was about the ChipKit digital logic controller.  That was going very well, so well, in fact, that I was able to finally diagnose an intermittent connection problem between modules.  Intermittent problems are always the worst, especially when you don’t trust other components in the system.  The reason this is relevant to the discussion at hand is that the problem only manifests when one of the connectors has pressure one one side.  I needed a reliable way the hold all the modules in fixed positions.

Since beginning this project, I’ve been inspired by the way that two people built their analyzers. Hans’ is probably my favorite.  I took the image below from his photo album in the Yahoo Spectrum Analyzer group.

Hans' analyzer "bottom view"

I love how clean and organized it looks.  Much different than most of the others out there.  His frame has holes that go all the way through the frame, and he has a back cover that screws on.  His coax cabling is made of right-angle soldered-on connectors with what looks like RG-405 hard pipe.

Another inspirational build is Sants.  This image is also scraped from the Yahoo group.

Sant's build

This build is most probably the closest to mine.  The pockets, or wells, for the component side of the boards don’t go all the way through the substrate.  Notice, in both designs, that there is a small lip around the perimeter of each well.  This is there to hold the boards and to electrically connect to the ground vias on the perimeter.  This design also uses right-angle connectors and hard pipe.

With these designs in mind, I sought out the things I would need.  First, of course, was the aluminum itself.  I had looked into McMaster-Carr (hopefully this link works), and a 1/2″ thick 12″ square costs about $40.  Then, my brother suggested looking on eBay.  I was able to find an equivalent sheet for about $30 after shipping.

Frame block layout

Once I had a cool hunk of 6061 alloy in my hands, I started designing the layout of the frame.  I started with OmniGraffle (it’s like Visio) because I could lay it out to scale, and the connections move in a natural way.

Once the layout was complete, I transcribed the design, complete with all the details into AutoCAD.  By this time, about a month passed, and I was able to find someone willing to machine it for me as a favor.  I also got a quote from another friend, which was about $250.  This is a reasonable cost for something like this, in case you’re looking to duplicate my results.

Close up of one of the wells

It took several weeks to get the parts back from the machinist, but the results are totally worth it!  The larger hole was cut with a 1/8″ end mill, and the inner pocket was cut with a 1/4″ mill.  With the majority of the modules, the inner radius is fine.  There were a few exceptions, however.

Small relief for DDS capacitors

This photo shows some of the rework I had to do to accommodate a few capacitors right at the edge of the DDS module.  It’s very difficult to take a picture of a small notch in a shiny material, but hopefully you can see the cut into the side of this pocket.  I made that mostly by making small, successive cuts using an exact-o knife.  The PLO reliefs were a bit more aggressive (there is a power header right in the corner), so I had to use a Dremel cutter bit in my drill press.

Relief for the PLO module

Once important lesson learned in this process is that 1.2″ or 2.4″ set into a PCB specification is more of a suggestion rather than something that you can count on all that much.  I had to sand almost every module to get it to fit.  Once that was done, however, everything fit like a glove.

Making custom coax jumpers

The final piece in the puzzle is the coax.  The perfect jumpers that both the other designs featured were definitely something that I wanted.  It’s possible to get these right-angle SMA connectors from China for about a dollar a piece, much less than the ~$5 that you’ll spend at Digi-Key.

Connector end, ready for solder.

To make them, all you really need to do is measure the coax sections, strip the ends, and solder…

Soldered center conductor

Soldering around the shield of the coax is the hardest part, and it’s not even that bad.

Final product!!

That’s all there is to it!  I’m really happy with how well things turned out.  Certainly something to be proud of.  Over the next few days, I’m going to try to keep posting about the other advancements.  I have a bit of a backlog, so I should be able to keep them coming…

Share on Facebook