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

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

Chipkit with 74595's connected to PLO2

Now that I know that trying to use the BusPirate with the 74595′s is basically a non-starter, I’ve moved on to using the ChipKit.  The ChipKit is a arduino-like board with a Microchip PIC32 micro controller.  The PIC32 is, as the name would imply, a 32 bit processor, running at 80 MHz.  That’s pretty impressive, if you ask me.  It has a boot loader and software package that makes it more or less compatible with arduino code.  I really like that I can just hack something together without all the setting up SFRs (Special Function Registers, or the bane of embedded device programmers existence).

Anyway, I’ve developed a simple “sketch” (program in arduino terminology) that accepts serial commands and executes SPI transfers using a set of pins through the 74595′s.  You can kinda see what’s happening in the logic analyzer trace above.  The top three traces are the SPI commands to the PLO module.  The middle two are the serial in and out of the chip kit.  The bottom three are the SPI commands to the 74595′s.  I had to zoom out far enough that you can’t see what the serial or bottom SPI contents are, but it’s basically “$,s,A,B,C,L,DDD…” where A, B, and C are the pins for SPI Chip Select, Clock and Data, L is the length of the transfer in bytes and DDD… is the contents of the transfer.  Currently, the limiting factor is the serial communication (by that I mean UART, not SPI), but I’m only using 9600 baud in this example.  The ChipKit uses an FT232R USB-Serial converter that is good into the megabaud.  In the future I’ll experiment with higher baud rates.

That’s basically, all.  I just wanted to post and say that it works.  By the way, the PLO module happily accepted its commands and tuned to 1024 MHz.  :)

Share on Facebook

As with most “publications,” if you can call a blog post a publication, you’re much more likely to read about what works than what doesn’t.  This is not that kind of post.

Experiment setup

Read more…

Share on Facebook

Collection of transceivers

This is just a post to point you over to my new Transceiver page.  I took the work that I did on the MRF49XA transceiver, and added an Atmel AVR USB micro controller.  I prototyped is using the AT90USBKey development kit, and designed a custom PCB that includes the transceiver and an AT90USB162.

"Component side" of the USB transceiver

I wanted to design the board such that all the “guts” were on the “back” side of the PCB.  The photo above shows the transceiver circuit (surrounded by a strip of track that you can use to solder a “fence” or “can” to manage RF interference), and the AT90USB162 micro controller.  This can be replaced by and 2 series USB micro controller, like the ATMega32U2 or the AT90USB82.  I recommend using the ATMeta32U2, though the first run of boards have the AT90USB162.  I’ve also included a dedicated 3.3v voltage regulator, because the built-in regulator inside the AVR doesn’t have a clearly marked current capacity, and I didn’t want to risk it.  I’ve also included every spare pin from the AVR that was practical.

The "top" side of the board

The other side of the board contains all the user facing parts.  This includes the status LEDs, the SMA connector, USB port, and the boot loader and reset buttons.  My grand idea here was that I could mount a piece of plastic to the component side to protect them, while having access to all the bits I need to use.  In hindsight, this means that it’s a “double-sided load” which is harder to manufacture.  I ended up having to learn a new technique to solder the USB port.  Notice that the can of the USB port covers the pads?  It’s very difficult to solder those on.  It helps to “tin” the pads first, then set the USB port on top of them.  Luckily, the USB port has little plastic pins that keep it aligned.  When you’re pressing down on it, just hit it edges of the pads with the soldering iron, and it should solder just fine.  When that’s finished, solder the mounting tabs on the sides.

Also, the buttons I bought aren’t “process compatible” which means that you can’t wash the board with them installed.  To deal with this, I reflow solder the entire board, then put them in my new ultrasonic jewelry cleaner with time isopropyl alcohol and brush them with a toothbrush, finally rinse off the alcohol and dry with compressed air.  Once the board is cleaned, then I solder on the buttons.

Lessons (mostly) learned?  Think about how you would assemble something when you’re designing it!!  Building the board this way adds 15-20 minutes of assemble time.  Bummer.

PDFs of the transceiver PCB artwork.  Sorry it’s so ugly, the “high quality” rendering in Gerbv doesn’t work in mac os anymore. transceiver-top transceiver-bottom

Component side artwork

User side artwork

Also, here is are the gerber and eagle design files: Design files.

Work on the software is ongoing.  Click on the transceiver’s main page (link at the top) for updates.  Enjoy!

Share on Facebook