Kevin Reid's blog

Latest Posts

 

new
Name
Kevin Reid
Website
My Website

View

August 23rd, 2012

Software-defined radio

Share
new

A couple weekends ago, I was musing that among my electronic devices there was no radio — as in AM/FM, not WiFi and Bluetooth and NFC and etc. Of course, radio is not exactly the most generally useful of information or entertainment sources, but it still has some things to be said for it, such as being independent of Internet connections.

Another thing that came to mind was my idle curiosity about software-defined radio. So, having read that Wikipedia article, it led me to an article with a neat list of radio hardware, including frequency range, sampling rate (≈ bandwidth) and price. Sort by price, and — $20, eh? Maybe I’ll play around with this.

What that price was for was RTL-SDR — not a specific product, but any of several USB digital TV receivers built around the Realtek RTL2832U chip, which happens to have a mode where it sends raw downshifted samples to the host computer — intended to be used to provide FM radio receiving without requiring additional hardware for the task. But there's plenty of room to do other things with it.

I specifically bought the “ezTV”/“ezcap” device, from this Amazon listing by seller NooElec (who also sells on eBay, I hear) (note: not actually $20). One of the complications in this story is that different (later?) models of the same device have slightly different hardware which cannot tune as wide a frequency range. (Side note: when buying from Amazon, what you actually get depends on the “seller” you choose, not just the product listing, and as far as I know, any seller can claim to sell any product. If you see a product with mixed “this is a fake!” and “no it's not!” reviews, you're probably seeing different sellers for the same product listing.)

Of course, the point of SDR is to turn hardware problems into software problems — so I then had a software problem. Specifically, my favorite source for unixy software is MacPorts, but they have an obsolete version of GNU Radio. GNU Radio is a library for building software radios, and it is what is used by the first-thing-to-try recommendation on the Osmocom RTL-SDR page (linked above), multimode.py. The MacPorts version of GNU Radio, 3.3.0, is too old for the RTL-SDR component, which requires 3.5.3 or later. So I ended up building it from source, which took a bit of tinkering. (I'm working on contributing an updated port for MacPorts, however.)

I've had plenty of fun just using it “scanner” style, seeing what I can pick up. A coworker and friend who is into aviation posed a problem — receive and decode VOR navigation signals — which has led to several evenings of fiddling with GNU Radio Companion, and reading up on digital signal processing while I wait for compiles and test results at work. (It sort-of works!)

This is also notable as the one time in my life where a ferrite bead on a cable actually did something — putting one on the computer end of the USB extension cord noticeably reduced the noise level. (And, of course, there remains a large, metallic hardware problem: antennas!)

(I could say more, such as the detailed fiddling to build GNU Radio, and various useful links, but it's taken me long enough to get around to writing this much. Let me know if you'd like me to expand on any particular technical details.)

October 7th, 2007

One of the requirements for the timer project is that the alarm sound be not too unpleasant.

So: What can I do with the current prototype hardware, a piezo element taken from a watch connected directly to a (digital) output pin on the PIC?

Trivially, fixed-volume square waves, by either toggling the output pin in software or setting up the PIC's PWM feature to drive it automatically. (Note that the PWM produces a minimum frequency of 1/16384 of the main oscillator.)

(I've moved the piezo output on the prototype to the RC2/CCP1 pin. This change is not yet reflected in the published circuit and program.)

However, I want software volume control, so I tried something more elaborate. I set the PWM to a very high frequency, and produce the audio-frequency signal by varying the PWM's duty cycle parameter. The characteristics of the piezo crystal filter out the high frequency, producing an effectively analog output.

After much twiddling getting this to work (CCPR1L is not the least-significant bits of the duty cycle), I found that square waves work well, sine waves are very quiet, and changing the amplitude has the expected effect. So while it won't sound great, I can at least program it to increase the volume gradually.

I haven't yet integrated this into the main timer program, so I don't know whether I'll be able to produce decent tones despite (or making use of) the timer program's counting interrupt.

Powered by LiveJournal.com