RTL-SDR

[Clark1961]

All the stratux stuff motivated me to check out software defined radios (SDR) again. I'd looked at them a couple years ago but decided to pass. This time I had an RTL-SDR delivered for $30. It included a couple antennas.

Pretty easy to set up SDR# on a windows laptop and checked out known FM stations. Some local broadcasters have some fair sized side-lobes.

Dropped down to shortwave and picked up a couple local FM stations. The audio was distorted and the signals were fairly weak so I don't know if it was a harmonic or a deliberate broadcast. The frequncies were near 1/4 of their FM broadcasts. Maybe Nate knows what's going on there.

After that I looked at transponder data. There are a couple utilities for decode the data and a couple more that will plot it if there's position data. Some of the utilities work better than others. Most of the software is free although the developers do beg.

I briefly scanned AM frequencies and didn't pick anything up. The antenna isn't the best for the kilohertz range but I thought it should have picked something up. Need to do some more fiddling.

Didn't look much at aviation band. I did pick up some traffic on Denver approach frequencies but it was all garbled/weak. Antenna prolly had a lot to do with that.

Lots more to look at with trunked radios and various Ham stuff to scan for. Some folks are listening to satellites which sounds a little boring. Other folks are doing radio astronomy with SDR. I'm still looking at various software and learning the lingo/acronyms. The world has it's own language, that's for sure. Another thing that is for sure is that an SDR would be pretty darn helpful in looking at a transmitter such as an aircraft radio to see what was going on with the signal if someone was having trouble with particular frequencies. You could also ramp check a transponder pretty easy as long as there was a radar "ping" available on the ground. ADS-B validation also gets pretty cheap.

 

[denverpilot]

Where on "shortwave"?

 

[Clark1961]

Where on "shortwave"?

Up around 28

 

[wsuffa]

Get one of the new T2 dongles, it'll have much better image rejection. Much. And spend the few extra $$$ to get the one with 0.5 PPM stability - the standard dongles are 25 PPM, and do drift until they warm up. It's not too significant at FM broadcast - it's very significant if you're using it at 800 MHz trunked bands and/or ADS-B.

 

[Clark1961]

Get one of the new T2 dongles, it'll have much better image rejection. Much. And spend the few extra $$$ to get the one with 0.5 PPM stability - the standard dongles are 25 PPM, and do drift until they warm up. It's not too significant at FM broadcast - it's very significant if you're using it at 800 MHz trunked bands and/or ADS-B.

Yup, got the T2 but didn't spend the extra so there's some drift. This is just a cheap hobby thing.

 

[RotorDude]

Isn't there a simple way to compensate for the temperature drift by software?

 

[dans2992]

The Flightaware guys say that adsb is not all that sensitive to drift...


Sent from my iPhone using Tapatalk

 

[Clark1961]

The Flightaware guys say that adsb is not all that sensitive to drift...

So far the drift is much less than the bandwidth.

 

[Old Geek]

Isn't there a simple way to compensate for the temperature drift by software?

I'm pretty sure that's the way the low-drift dongles do it. Not enough space or power for a crystal oven.

 

[denverpilot]

Isn't there a simple way to compensate for the temperature drift by software?

Not really on these cheap ones. The computer doesn't know what frequency the clock source inside the dongle is producing for the receiver mixing stage.

It assumes when it asked for X frequency, that's where the receiver went. There's no feedback loop to calibrate the SDR to.

 

[Clark1961]

Yup, got the T2 but didn't spend the extra so there's some drift. This is just a cheap hobby thing.

One other thing, the spec is 2 ppm initial drift and then 1 ppm temperature drift so not to bad at all for $30.

 

[RotorDude]

Isn't there a simple way to compensate for the temperature drift by software?

Not really on these cheap ones. The computer doesn't know what frequency the clock source inside the dongle is producing for the receiver mixing stage.

It assumes when it asked for X frequency, that's where the receiver went. There's no feedback loop to calibrate the SDR to.

I don't understand. If the application driving the dongle can, for example, measure peak signal power at a certain working frequency, why can't it periodically run a calibration series of tests (with incremental central frequencies) and find the current drift correction factor? IOW, even if the dongle doesn't have that built into its firmware, why can't the app do it?
I would think that a simple drift correction at the app level would be cheaper than getting a super-duper high stability ultra low drift hardware.

 

[wsuffa]

The Flightaware guys say that adsb is not all that sensitive to drift...


Sent from my iPhone using Tapatalk

So far the drift is much less than the bandwidth.

Well, sorta.

Setting an offset in ADSB# will improve reception, particularly for weaker signals. BTDT.

If you use this with an P25 trunking decoder (non-aviation) the drift is significant as the signals are much narrower band. To the point that the offset can be outside the bandwidth of the receiver.

Flightaware has a bunch of receivers that feed it, so max range is not as important. Single receiver and I'll take max coverage every time.

I don't understand. If the application driving the dongle can, for example, measure peak signal power at a certain working frequency, why can't it periodically run a calibration series of tests (with incremental central frequencies) and find the current drift correction factor? IOW, even if the dongle doesn't have that built into its firmware, why can't the app do it?
I would think that a simple drift correction at the app level would be cheaper than getting a super-duper high stability ultra low drift hardware.

You can do drift correction to some extent in SDR#. Most other packages give you little control.

I just ordered a 0.5 PPM unit for $25.95 vs $21.95 for the regular unit. There's a group selling 1.0 PPM for $24.95. It's not much more, and certainly not worth my time for that little money. YMMV.

Noo Elec also sells a metal case for the dongle - pricy, but keeps RF interference down.

Lots of options.

 

[RotorDude]

Well, sorta.

Setting an offset in ADSB# will improve reception, particularly for weaker signals. BTDT.

If you use this with an P25 trunking decoder (non-aviation) the drift is significant as the signals are much narrower band. To the point that the offset can be outside the bandwidth of the receiver.

Flightaware has a bunch of receivers that feed it, so max range is not as important. Single receiver and I'll take max coverage every time.



You can do drift correction to some extent in SDR#. Most other packages give you little control.

I just ordered a 0.5 PPM unit for $25.95 vs $21.95 for the regular unit. There's a group selling 1.0 PPM for $24.95. It's not much more, and certainly not worth my time for that little money. YMMV.

Noo Elec also sells a metal case for the dongle - pricy, but keeps RF interference down.

Lots of options.

Yes, definitely for a few bucks extra I'd go for the best stability and reliability. I'd consider software drift correction only if the price hike to do it in hardware were significant.

 

[Clark1961]

Worked with HDSDR (software) early this morning. It has some interesting features such as frequency lists, auto-tuning, bandwidth control, and others which SDR# didn't appear to have (but there may be plug-ins).

It seems to do a poor job with actually turning radio signal into sound. Of course there's lots of variables there and my chief suspect is operator error. HDSDR showed lower signal levels than SDR# across the board. Tried using max gain and using the auto-gain on both the radio and the tuner, still had lower signal levels. Hardware set-up was unchanged. Could be a display scaling thing but the problems with sound make me think there's a software problem. Probably something I'm missing. Lots to learn.

 

[denverpilot]

I don't understand. If the application driving the dongle can, for example, measure peak signal power at a certain working frequency, why can't it periodically run a calibration series of tests (with incremental central frequencies) and find the current drift correction factor? IOW, even if the dongle doesn't have that built into its firmware, why can't the app do it?

I would think that a simple drift correction at the app level would be cheaper than getting a super-duper high stability ultra low drift hardware.

Well true. One could write a whole lot of code to do that and the first spurious signal to interlope into the band pass of what you're trying to lock to, would confuse it and the software would chase it.

Not such a big deal if you're listening to broadcast stuff that continuously transmits and isn't in shared spectrum or if there isn't much noise or other transmitters near your SDR receiver.

As someone mentioned there's usually some sort of fixed offset available and that usually is enough to handle the 80/20 rule. There's a point of diminishing returns for automatic tuning code.

The trunking systems are typically multi-frequency so the software is hopping the receiver(s) around anyway. (Some implementations bounce the receiver on and off of the control channel, some dedicate a receiver to the control channel and hop a second receiver.)

You're only limited by the code that can be written and the execution speed, I guess, if you're really dead set on wanting to write auto-tune code.

In the early days of this experimentation I remember lots of folks whining that their PC wouldn't keep up and they had to get a faster one. Not such a big problem anymore.

 

[RotorDude]

Well true. One could write a whole lot of code to do that and the first spurious signal to interlope into the band pass of what you're trying to lock to, would confuse it and the software would chase it.

Not such a big deal if you're listening to broadcast stuff that continuously transmits and isn't in shared spectrum or if there isn't much noise or other transmitters near your SDR receiver.

As someone mentioned there's usually some sort of fixed offset available and that usually is enough to handle the 80/20 rule. There's a point of diminishing returns for automatic tuning code.

The trunking systems are typically multi-frequency so the software is hopping the receiver(s) around anyway. (Some implementations bounce the receiver on and off of the control channel, some dedicate a receiver to the control channel and hop a second receiver.)

You're only limited by the code that can be written and the execution speed, I guess, if you're really dead set on wanting to write auto-tune code.

In the early days of this experimentation I remember lots of folks whining that their PC wouldn't keep up and they had to get a faster one. Not such a big problem anymore.

I think this kind of software need not be complex nor get confused on "the first spurious signal". Since you know temperature drift is a very slow effect, you can filter/ignore any spurious changes and look for the long time constants only.

 

[denverpilot]

I think this kind of software need not be complex nor get confused on "the first spurious signal". Since you know temperature drift is a very slow effect, you can filter/ignore any spurious changes and look for the long time constants only.

For continuous transmitted signals, yes.

For hopping around to different non-continuous transmitters (the drift problem mentioned for the trunking receiver application), no.

Once the thing warms up and stabilizes at a temperature, it's not going to drift all that much, which is that 80/20 rule thing. Nobody wants to spend a (relatively) large coding effort to fix the 20 side of the ratio.

Sure. It can be done. Anything can be done given enough free labor.

Batter up! Fire up the text editors and start coding. That's why they call it open-source, after all. (Note: Many of the projects that have nifty features aren't open. Which is also pretty normal. Simple economics, if it's a pay to play application. Insert rms and esr rants, here...)