Capturing Weather Satellites Easily

I've been wanting to capture weather satellite signals for quite a while. This was one of my considerations when I chose the SDRPlay, since the high-quality digital mode is 4 MHz wide. Tonight I was able to capture the low-quality analog signal.

For this and most of my other experiments, I used TV rabbit ears. They're from Target and cost about $20. This is my go-to antenna, offering great performance on VHF and up. With it, I've been able to receive broadcast FM, 1900 MHz GSM, and everything in between. Just don't expect it to do HF very well.

I'm particularly interested in the digital HRPT signals, but since I'm not fully set up for that yet, I had to settle for the analog one. That's OK, because I didn't even see anything on the HRPT frequencies when NOAA-19 passed by this afternoon.

Unlike what I first expected, it's not hard to capture weather satellites, even though some online tutorials might look hard. My favorite radio projects are those that accept an audio signal through Stereo Mix and decode it live. I don't like having to record, transcode, feed IQ into complex software, etc. I will if necessary, like I did with GNURadio and ATSC, but I really prefer live audio-based decoders.

I did manage to capture a weak signal of NOAA-19's analog broadcast. It was too weak, so I didn't get a good decode. Later, NOAA-18 made a pass and I managed to tune it in. The funny thing was, Stellarium reported it as transmitting on 137.1 MHz. I didn't see anything when I tuned there, so I checked Wikipedia and it said that NOAA-18 is actually on 137.9125 MHz, having moved to that frequency in 2009. It's a good thing I didn't just wait for a signal, because I would've missed a great pass.

I tried to look up what LRPT looks like on sigidwiki.com, but there was nothing. Turns out the signal is actually called APT. LRPT is a Russian digital (but low-res) format. I've included pictures of APT below.

Very strong:

Really bad when it passed over my house:

I also would've appreciated a sound sample so I could positively identify it, so I've included one. It's recorded in NFM.

Directions:

I managed to find a program called WXtoImg that can decode by sound instead of pre-recorded files. It's free but you can pay for more features if you want.

Next you need a program to tell you where and when the satellites will pass. I use Stellarium. Since I have an older video card, I have to use the 0.12.x series. Enable the satellites plugin and make sure it updates the orbital elements (it should do so automatically.)

Now zoom out and scroll in such a way that the ground wraps around so that the sky is a circle in the middle. This lets you see the whole sky at once. Go into Stellarium's Date and Time dialog, click in the minute, and push the Up arrow key. Stop when a weather satellite shows up (Hint: NOAA-17 is dead.) Try to find a good, high pass. I ignore any passes that just skim the horizon. You might want to look up which other NOAA satellites are dead. NOAA-15, -18, and -19 are functional at the time of this writing. Make a note of the time and direction the satellites rises. Try to find a window that faces that direction or go outdoors when it's time.

When the time comes, turn on HDSDR, set the mode to FM, bandwidth to about 30 KHz, tune to the proper frequency, and notice how it is a few kilohertz off. This is due to Doppler shift. Zoom in and tune to the actual center frequency. Since this is FM, being off-center will hamper the signal. Be sure that Stereo Mix is your default recording source and that the volume is about right.

You can also record 48 KHz IF and demodulate it later if you prefer. It's quite easy in HDSDR, just right-click the Record button and check the IF checkbox. This would let you go back and try different settings without missing the pass.

Be sure to turn on AFC in HDSDR. This tells HDSDR to automatically stay centered on the signal as the frequency shifts.

Open WXtoImg. Click File->Record. Under Record and auto process, click Create image(s). Then click Manual Test. It should now start scanning upwards. You should see test patterns on the side and be able to recognize clouds. If you're indoors, the signal will go away abruptly as the satellite passes directly over your house and sets, even if the antenna is in a window. It might work better if the antenna is outside with a clear view of the sky.

Here is the final, but unprocessed, picture:
(click to enlarge)

Notice how the lines in the waterfall above are slanted? As the satellite rises and sets, the Doppler shift constantly changes the signal's perceived frequency. This is why you need to enable AFC.

My opinion of Digital TV

I think digital TV is a great concept, but is not implemented correctly.

(Update 1/13/2016) I found out from the GNURadio mailing list that the ATSC group is working on a new version of ATSC (version 3) that uses OFDM. The new standard was exhibited at the Consumer Electronics Show in Las Vegas last week and will probably solve the unreliability issue.

In 2009, most TV stations in the United States were forced to turn off analog transmitters. In September 2015, the last few stations were told to turn off their analog channels. Cable and satellite are still allowed to use analog, but it's cheaper for them to use digital because they can pack more channels into the same bandwidth.

The government claimed it needed a lot of the old analog channels for mobile broadband (LTE) and public safety communications. It seems to me that TV broadcasters could have just been told, "We're kicking you off the high channels because a cell company offered us a lot of money," and let them keep transmitting analog in their new channels. Analog probably wouldn't have bothered the higher-frequency services. It isn't a "waste of bandwidth" as some say, because in terms of RF bandwidth, digital channels use the same amount (although they do multiplex multiple channels onto it.) Also, it makes no sense to ban analog on low bands like 50 MHz. Cell companies obviously have no use for those bands, so why waste spectrum by outlawing analog transmission in them? I'm pretty sure the ionosphere would never let ATSC work in a band like that.

I seem to remember reading, possibly on the FCC website, about how digital stations have increased coverage because they're more efficient. I even saw a map comparing coverage areas before and after the transition. Anyone who's watched over-the-air digital TV knows that's a lie. Far away, you could get a snowy picture. Even if you couldn't get the picture, the sound on analog was pretty reliable. Now it's all or nothing. If you don't get perfect reception, you get none at all.

But, assuming it was necessary to change to digital, how could things have been done better?

Whoever designed ATSC should have known that VSB (vestigial sideband) was a bad idea. VSB is a form of AM, and we all know AM isn't very reliable in bad conditions. Old analog channels used VSB for the picture and ordinary FM (the same format as broadcast FM) for the sound. I'd love to see digital TV get implemented in ultra-wide FM, maybe 10-20 MHz wide. I'm sure that would make the signal nearly unstoppable, but it would also take up too much spectrum.

We've had since the 1940's to figure out that VSB is prone to issues. Why would we choose it for our digital standard? In Europe they use OFDM for their DVB-T standard. Some say OFDM is better. It's what other services like Wi-Fi use. Wikipedia says it's more reliable in the presence of multipath and bad weather than digital VSB. Multipath is what keeps TV from working in a moving vehicle. And what about passing vehicles? If they reflect the signal just right, the signal will go out. If you look online, you can find a story about a US company that wanted the FCC to give TV broadcasters the choice of OFDM vs digital VSB. The FCC said no, so we're stuck with VSB.

I know analog was great because I remember one rainy day in the mountains with a portable TV. The FM sound came through, but the AM picture was obliterated by the rain.

I'd like to see analog come back as a broadcaster's choice, but that's not likely. It turns out I'm not the only one who wants analog back. Here's what someone commented at http://moronstalkingrubbish.com/dontTurnOffAnalogueTVAust.htm

A small majority of us, here, in the US are currently petitioning our congress to bring back analog since signal interference is caused by trains, snowmobiles, & autos. It's almost 2013 and the dtv has not become better for the millions of lower class who once had reception on functioning equipment.

There are many others online who feel the same way. There are some petitions you can sign online asking the government to allow analog TV again. The higher frequencies are gone to cell companies, but analog in the low bands would still be great. I'd sign them if I thought it would do any good, but if you're interested here are some links:

Petition2Congress: Bring Analog TV Back!!!!!!!
GoPetition: Bring back Analog for the people who can't afford to switch to Digital TV
thepetitionsite: bring back analog TV

ATSC now possible on magnetic drives

I have found a way to reduce the data rate of ATSC IQ recording from 32 MiB/sec to 14 MiB/sec.

Last night I was taking some recordings of Fox, recording clips of World's Funniest. I was annoyed at only being able to take 1 minute at a time and then having to wait almost two minutes transferring it from RAM to my external hard drive. Taking 1 minute clips spaced 2 minutes apart causes you to miss so much and because of this I looked into reducing the required data bandwidth.

To make a long story short, I found a way to take 8-bit IQ recordings and thus reduce data bandwidth to the point where you can actually take IQ recordings to an ordinary hard drive. Why is this important? Because with hard drives being so cheap versus SSD's, you can buy an 8 TB model like mine and (at least in theory) take recordings of virtually unlimited length.

This new way of recording will take the required data from the 32 MiB/sec in my original work down to 14 MiB/sec, while still yielding good decodes! This should be well within what a magnetic drive can handle, plus it takes less data so your hard drive space goes further.

A few notes/tips:

• Use 7 MHz bandwidth on the SDRPlay. Although I said to use 8 before, 7 has been proven to provide flawless recordings while taking up less data.
• If you can find one, I would suggest you use an older version of SDRSharp. All my recent perfect decodes were recorded in SDRSharp. As I said before, it has superior DC cancellation.
• SDRSharp also has an 8-bit recording option

Some math...

Last night I was limited to 1 minute 12 seconds on a 2-GiB RAM drive. I was using 7 MHz bandwidth at 16 bits per sample. I used a stopwatch app on my phone to time how long it takes Windows to move this onto my external drive, since Windows' reported transfer rate is inaccurate. It took me 102 seconds to transfer. The files were about 1.92 GiB each.

1.92 GiB divided by 102 = about 19 MiB / sec average transfer rate. At 16-bit sampling, this would only allow you to record 4.75 MHz of spectrum, which is obviously not enough for TV. When I calculated this, I saw that if I could switch to 8-bit recordings, my hard drives would be sufficiently fast.

Recall in my last post that I said it would take 16 MiB/sec to do an 8 MHz @ 8 bit recording, which is below the 19 MiB/sec I just calculated. But now that I'm using 7 MHz, it would only take 14 MiB/sec, well below the limit.

But 8-bit recordings didn't work last time. Then it dawned on me: if GNURadio can't natively decode 8-bit ATSC recordings, why not trick it by taking an 8-bit recording and upsampling to 16 bits?

After some more tests I noticed SDRSharp is limited to 2 GiB, which is about 2 minutes. This is a hard limit of the official WAV format, and SDRSharp doesn't support RAW or WAV64. If anyone finds a fix for this please comment below.

How I did it:

Today I took an 8-bit recording in SDRSharp. It was a WAV file, not RAW, so I was able to open it in Audacity and merely save it as a 16-bit WAV. I knew Audacity likes to dither, but that doesn't seem to happen on upsampling. I verified the 16-bit WAV I had just generated by opening it in SDRSharp and, sure enough, it looked like a great signal, so I knew Audacity hadn't messed it up.

Below: live waterfall of WACH Fox.

Below: 8-to-16 bit converted WAV recording

As you can see, there's very little difference.

I fed the 16-bit converted WAV through GNURadio as usual, and waited expectantly. For all I knew, I could get the dreaded "!!! atsc_fs_checker" errors, or simply an empty TS file. Neither happened (see below) but I still had no proof it would play.

To my surprise it actually played! (although it did skip in 2 spots)
(pictured below)

I think the skips were caused by minor sample dropping, so it should work perfectly with a very fast and defragmented hard drive. Of course, PrimoCache would still be a great idea to smooth out any hard drive latency, such as what occurs during recalibration, but only as long as the IQ data rate doesn't exceed your drive's average write speed.

I did more tests on Sunday, but with a RAM drive this time to avoid latency. 8-bit recording is indeed very reliable, not to mention space-efficient, as I was able to fit 2 minutes 33 seconds into my 2-GiB limit. I had been concerned about the reduced dynamic range afforded by 8-bit sampling, but my fears seem to be unfounded.

It would be amazing to leave this recording, latency smoothed out, to my 8 TB drive, to catch shows I'd miss. Below are two ideas for software fixes that would allow us to set up a full software-based DVR.

1. HDSDR supports unlimited file length but has a minimum bit depth of 16. It should be updated to support 8-bit recording,
2. SDR#, on the other hand, supports 8-bit recording but [its native recorder] is limited to 2 GiB. It should be updated to use a format other than WAV. See new recorder for SDRsharp breaks 2GiB limit. With a certain 3rd-party plugin, we can now take 8-bit recordings of unlimited length in Wave RF64 format using SDRsharp.

Thanksgiving ATSC Tests

Yesterday I did some more ATSC experiments.

(above) Finally... the elusive WZRB ION channel 47 comes in. On the right edge is WACH Fox 57.

(I'm using the older copy of SDRSharp I mentioned in my previous post)

Since hard drive recording is spotty, I copied SDRSharp to a RAM drive, since it only records to its own program directory. SDRSharp kept setting the SDRPlay's PPM correction to a crazy value and changing it kept locking up the computer.

SoftPerfect RAM Disk also kept locking up when I tried to unmount disks. I would turn it off in Task Manager and restart it from the Start menu. That caused it to forget the RAM it had previously taken and I would have to reboot. I eventually switched to IMDisk and kept working.

Adding to my troubles, when I tried to decode it, I accidentally used the old flowgraph from my previous post, the one that expects 8-bit samples. Of course, my TS file stayed empty, and it took me a while to realize the issue. (Pictured below)

Even after fixing this, I wasn't able to decode WZRB, even though the TV had no trouble. However, I did manage to get a long successful recording of WRLK PBS.

Pictured below is WAGT NBC. As I write this, I can't get it to come in on my TV.

I've seen this kind of fading in other stations, most notable PBS. This picture was taken with my SDRPlay hooked to a rooftop Yagi. For some reason, a few cases of this fading can be cured by using indoor rabbit ears and rotating them until it goes away. Strangely, I've actually had far better results on PBS with indoor rabbit ears than an outdoor Yagi. I don't yet know why certain portions of the station would fade before reaching me, considering that it leaves the transmitter as a uniform distribution of power over the whole 6 MHz. I know that ATSC doesn't work for moving receivers, but I'm not moving, so why would only certain sections fade as opposed to others?

In summary, trying to decode ATSC is more of a hit-and-miss process since it's hard to know if a station will be readable. In several situations, software-based solutions perform better than embedded hardware, as is the case with DRM radio reception. But from what I've seen, if a TV can't receive a station, GNURadio certainly won't. Sometimes even if a TV is perfectly OK with a certain station GNURadio still can't decode it. I wonder if they'll update GNURadio's blocks for better results? In theory you should be able to decode just as well (if not better) in software as you can with a hardware decoder, since you have more control over processing.

ATSC Update 2

I'd like to share three more aspects of ATSC recording you might not be aware of.

First.

In previous posts I stressed the need for high-speed recording media when recording ATSC IQ samples. A few days ago I proved myself wrong.

I was using an older copy of SDRSharp, one that still works with the SDRPlay. SDRSharp has superior DC cancellation functionality, which it labels "IQ Correction."

I used the Baseband recording option at 16-bit sampling and managed to record 44 seconds to a fast magnetic hard drive before dropping samples. The IQ file yielded a perfect decode. You can download the final TS here: 183mhz_decoded.ts.7z. (70 MiB)

You'll probably still need a RAM drive for longer recordings, but this opens up a lot of possibilities. Someone just needs to write a program that will "buffer" writes to a hard drive to smooth out latency. Ideally this would work by registering a virtual drive and creating a RAM buffer, and having two separate threads, one to accept the write requests and store them in RAM, and another to write them when the drive is ready. That way, SDR programs never see the delay in the hard drives.

(Update) I've found a paid program that should do this. It's called PrimoCache and the concept is called deferred write. It costs $29.95 USD and comes with lifetime free upgrades.

Second,

You've probably noticed that most digital channels offer an EPG (Electronic Program Guide.)

I learned that if you open a valid decoded TS file in MediaInfo you can retrieve the EPG, among other things, such as channel resolution and bitrate.

Click here to read a TXT file of MediaInfo's output for the TS file I offer above. The EPG's for each channel are at the bottom.

(Update 11/24/2015) Interestingly, there is a Start and End UTC near the top. MediaInfo can apparently look at the timestamps embedded in TV channels to find the start and end time of the recording. Note that the recording's Start and End span 38 seconds, 6 seconds less than the 44 seconds of IQ data I took. This implies that the syncing (and de-syncing) periods take off 3 seconds at both the beginning and end.

Third,

During the experiment under "First," I also tried taking 8-bit IQ samples, which cut bandwidth and storage requirements in half from 32 to 16 MiB/sec. I was not able to decode this IQ file, but maybe someone else will figure out a way.

Of course, one big advantage of the SDRPlay over the RTL dongle is the 12-bit sampling. and the loss of dynamic range incurred by downsampling to 8 bits might hamper decoding no matter what you do.



As always, feel free to comment below.

Software to filter through EiBi schedule

One of the important aspects of shortwave listening is identifying the shortwave station you're listening to. The EiBi schedule is an exhaustive list of stations along with their respective frequencies and transmit times. It is my most-used shortwave listening resource.

When I still used analog radios, I would have to wait until the top of the hour and listen for the name or callsign, hoping there was no interference, then go search in Excel to find the frequency. Now that I have SDR, I can accurately pinpoint the frequency. Needless to say, this makes it much easier to find out what the station is. However, usually multiple stations use the same frequency at the same time, and not all stations transmit 24/7. The EiBi schedule gives times in UTC, but it's time-consuming to convert all those UTC time ranges, plus you might make a mistake if you do it in your head (you know, forgetting to "wrap" when you cross 24 or 0.)

Because of all this, I wrote a small Windows program to go through the EiBi CSV-format schedule and populate a list of what's currently on based on your PC's time. You just give it an EiBi *.CSV file and your offset from UTC and it does the rest. I even added an option to show only DRM stations.

I live on the East Coast so I originally hard-coded a timezone of -5, but I updated it recently for international use. Just enter your timezone to replace -5. The program should remember your CSV file and timezone between sessions.

Download an EiBi schedule (get the CSV file)

Download eibiscanner.zip

Unzip the ZIP to a folder and run eibiscanner.exe.
Note: You must unzip everything or it will not run


Feel free to comment on this software.

Intercepting pager messages

Today I heard data bursts on 155.170 MHz and thought they were P25 or MotoTRBO. When they didn't produce any output in DSD+, I went on sigidwiki, chose VHF, and went through NFM signals until I heard one that sounded similar. It turned out to be a pager signal. I downloaded a program called PDW. It can be downloaded here.

I was then able to decode what turned out to be hospital messages. This form of interception is legal, according to what I read on this RTLSDR Blog post. In the post, they wrote, "In most countries it is perfectly legal to receive these messages, as they are plain text unencrypted, but it is illegal to act on the information received. Please respect your local laws."

I can't legally go into detail, but I will say I was able to read some interesting stuff. By law, you must not act on what you hear or divulge it to someone who wasn't present.

929.612 MHz has far more activity than VHF, at least in my area.

I recommend TV rabbit ears in a window with the adjustable parts vertically oriented. This forms a sort of vertical dipole. I've tried pager interception with a rooftop Yagi connected through a TV RF amp and it doesn't seem as good. It could be the RF amp corrupting any signal over 800 MHz, attenuation in the old cable wiring, or maybe TV Yagis just weren't meant for this frequency. Of course, the 150 MHz paging comes in significantly better with the Yagi, but that's understandable because it's near a VHF TV band, something the Yagi is good at, and the RF amp is designed for this frequency.

Extra tip: although HDSDR beats SDR# hands-down when it comes to CPU usage, SDR# seems to have a better FM demodulator, which means higher decoded message accuracy.

Here's where things get mysterious...

While monitoring 155.170 MHz, I heard a voice signal more than once. It seems people sometimes talk between pager bursts. I've embedded a recording of one such instance.

(Update 11/09/2015) I think this is an example of a voice page. Here is a good link to some info on this. Apparently pagers can receive voice messages.

Improved propagation

The shortwave bands are opening up again after months of discouraging reception. Since the spring of this year, the sun's radiation blocked, rather than helped, the radio waves.
It was frustrating for me because I only found out about it when I couldn't make any contacts on 20 meters. I had never been able to transmit SSTV on 14.230 MHz without getting a response! I realized that I could barely hear anything but static on that frequency, and I checked the propagation report. A very good one can be found here. Sure enough, all the bands were labeled, "Poor." I had never seen this happen before.

Several weeks later, I bought an SDRPlay. Then I set up a hanging dipole from a top-floor window. After more mediocre reception, I began to doubt the quality of my antenna and even my radio. I gave up monitoring the bands until things got better.

Things got better just under a week ago. Now the bands are open and this morning at 8 AM I got up, strung up an antenna, and turned on my radio. Australia comes in very well in the mornings. It's no surprise, considering that when the sun is rising on the east coast, the Pacific is dark. What was surprising was that the 15 meter (21 MHz) band was full. I heard what sounded like an Indian voice saying something about Germany.

I made an SSTV contact on 20 meters today. He got my callsign, but I couldn't read his. This weekend was the CQWW DX SSB contest, so the bands were full. Every 3 khz I could hear someone talking! Thankfully, 14.230 MHz was clear enough for me to get my picture out.

I first received a picture of a street sign that said, "Delaware." This was sent (probably to me) twice. Another picture looked like it contained my callsign and said, "Darn Contesters." Then I got a picture of Yoda labeled, "May the force be with you." By now I could just make out my callsign at the top. These pictures had horizontal bands of snow whenever contesters talked over the transmission.

I also heard what sounded like DRM on 14.233 MHz. The ham radio version of DRM is used for sending pictures.

Tip to make Windows 10 more usable

This is a quick tip I learned yesterday. I upgraded to Windows 10 from XP recently because I needed to be able to run Visual Studio 2015. Thankfully, I managed to do it before October 1st.

I noticed that the mouse doesn't respond to clicks right after I've typed. I would be typing in a Word document, click to place the cursor inside another paragraph, and then start typing again, only to find that the cursor had remained in the first paragraph!!! This naturally drove me crazy. I noticed the same problem when typing into Calculator (which, in Windows 10, is a Universal App.) Calculator wouldn't respond to clicks immediately after entering numbers.

I normally use LibreOffice and Office Online (both free) because Microsoft Office is expensive. I thought, "Ok, maybe LibreOffice isn't well written." But Calculator behaved the same way. Likewise, I thought, "Well, it is a Universal App, so it has to be written in some sort of universal language and run on an emulator in order to be ported between x86 (PC and tablet) and ARM (phone). Maybe the emulator is slow." One thing was sure: this certainly wasn't a problem on Windows XP!

But yesterday I found out that the problem stems from a new feature in Mouse settings (in the weird new settings window that replaces Control Panel.)

Here is a picture (you may want to click to enlarge it):

As you can see, I have already set it to "No delay (always on)." It had been set to "Medium delay."

Now that this is resolved, all programs, including Calculator and LibreOffice, are quite snappy. I now am a fan of the new Universal App system, but I still don't recommend upgrading to Windows 10 until more of the bugs and privacy issues are fixed.

Tracking aircraft with ACARS

This morning I was using my SDRPlay and heard some AM data packets near 130 MHz. I knew this was the aircraft band and so they must be ACARS packets.

Transmissions in the aircraft band are in AM, as opposed to most other VHF services which use FM. Because they use VHF, you need line of sight to hear airplanes, but that doesn't mean they have to be passing overhead; on the contrary, planes usually fly so high that people in other states have line of sight.

You can download an ACARS decoder here.

I knew there were programs that could decode ACARS packets, but didn't expect it to work very well. Thankfully, I was wrong.

I upgraded to Windows 10 and thought I'd mention that I was skeptical when I saw how old this program looks. A lot of old decoding programs were for Windows 95/98 and expect different sound API's than what Windows Vista and up are willing to provide. Fortunately, acarsd runs just fine on Windows 10.

Here is what an ACARS packet looks like:
(click to zoom)

Download acarsd (the program above) and extract the ZIP. There will be a file called installer.exe. It's not a normal installer as it just extracts some files to a folder you choose. When it is done, open that folder and choose acarsd.exe.

You need a way to pipe the audio into the program. It will expect the sound to come from the default recording device. I prefer to use the Stereo Mix in my sound card. Be sure it is set as the default recording device.

If you sound card doesn't have Stereo Mix, make sure you have the latest official drivers from your manufacturer (not built-in Windows drivers) or use VBcable (which is free.)

After listening to some packets, the program will look like this:
(click to zoom)

You can type the aircraft registration number in a search engine to find current flight plan. Sometimes there will even be GPS coordinates and "CREW ACKNOWLEDGEMENT" messages.

The picture below shows that you really can receive packets even if the plane doesn't pass over your state. (I'm in South Carolina)

ATSC update

Hi again. While making ATSC recordings, I ran into a problem that I think you should be aware of. Even with 100% perfect reception, your final decodes may be corrupt.

The moral of this post: Use RAM drives to record your IQ samples! SSD's might also be a good idea.

How I found out:
As I described in the first post, it takes a lot of bandwidth to record the IQ samples necessary to capture a TV station. Surprisingly, it takes 32 MiB/sec for 8 MHz of bandwidth, even though you're doing 16-bit samples. It seems that it should be 8 Megasamples/sec * 2 bytes/sample = 16 Megabytes/second.

If you use a magnetic hard drive to record IQ samples and some of your TV recordings are corrupt and won't play, chances are good it's the hard drive not keeping up.

On a side note: you may have also noticed that 8 MHz looks cleaner in the waterfall than 7 MHz, although 7 MHz can work. 6 MHz is just too narrow, because of the IF filters that round off the edges.

Using RAM drives, I had been limited to ~1500-1800 MB available RAM on one computer, which was only enough for about a minute. The only way to get more space was to use a hard drive. But hard drive recordings never played very well. I began to wonder if the recordings somehow got bad after a certain amount of time.

I tested this by taking several very large IQ recordings (of different stations.) Some were recorded to an 8 TB external drive I purchased recently, others to a very fast internal magnetic SATA drive, and one more on a 5 or 6 GB RAM drive (on different computer.)

Of the three, the only one I could actually watch was the one recorded to the RAM drive.

This is proof enough that filesize won't mess up the decoder; apparently the hard drives were causing samples to be dropped.

Multiple VFO (tuner) using the SDRPlay

There's a really cool program I recommend using with the SDRPlay called SDRConsole. It supports a feature called Multi-VFO.

I had heard of Multi-VFO but thought it was a hardware feature only present in the most expensive SDR's. But with SDRConsole, you can actually tune in multiple stations at once in software! This is useful for listening to walkie-talkies that transmit and receive on different frequencies, or even hearing multiple police walkie-talkies at once.

The only downside (for me) is that SDRConsole doesn't use the standard EXTIO interface, but rather the Mirics API. This means you don't get all the nifty SDRPlay options like RF Gain vs Use AGC, or most importantly, the DC cancellation options.

Musical Repeater Mystery

Two weeks ago I was monitoring the 2m band with my SDRPlay and heard music on 146.000 MHz. It was odd because music is illegal on ham radio.

Deciphered, the Morse code says, "DE KK4BQ FOX". KK4BQ is a repeater.

Here is a recording:

The music and Morse code must be this repeater's ID because they were repeated at regular intervals.

Mystery signal: 877.875 MHz (Solved)

While using my SDRPlay RSP, I noticed a weird signal centered on 877.5 MHz.
Here is a picture of HDSDR receiving the signal on 5 MHz bandwidth:

It is 2.55 MHz wide, and I haven't seen anything like this on www.sigidwiki.com. It could be some sort of cell phone tower signal

(Update 1/08/2016) I asked about this on the GNURadio mailing list and they say it's either IS-95 or CDMA 2000, both old cell phone signals. They also say it's actually 2 signals beside each other.

Watching ATSC HDTV on the SDRPlay RSP

One of the main reasons I got the SDRPlay RSP was its wide bandwidth. It can show up to 8 MHz of spectrum at once. I figured it should be able to watch TV. Turns out it can, but it's only designed to receive DVB-T.

Unfortunately, they only use that in Europe and a few other places. In North America we use ATSC.

In this article I will show how to use it to watch ATSC.

(Update 11/28/2015) See ATSC now possible on magnetic drives for updated info on sample rate and bit depth.

(Update 03/02/2016) You should use 7 MHz sampling instead of 8 MHz; it reduces bandwidth and space consumption and the narrower filter may help to block adjacent blowtorch stations. Also experiment with 8-bit recording, which cuts the file size and minimum write speed in half.

Background

ATSC is 6 MHz wide, so you have more than enough bandwidth on the SDRPlay. In theory you should be able to watch North American TV channels. Imagine my consternation when I searched online and found plenty of info on watching DVB-T, but practically nothing on ATSC!

There was one way, using a program called GNURadio, but the ATSC system wasn't well documented. In fact, information on it was almost non-existent. I proceeded to search but without much success.

I'm a Windows user, so I tried installing GNURadio on Windows, but it was a huge mess, taking hours to compile and then it wouldn't even start. I gave up and decided to use Linux.

I downloaded the GNURadio Live DVD from their website. It is an ISO file containing a bootable Linux Ubuntu installation with GNURadio pre-installed. All you have to do is pop it in and reboot, and you've got a full-featured GNURadio installation.

But that still didn't explain how to make ATSC decoding happen. GNURadio uses blocks, which are little squares containing functions. You can drag them onto your workspace and draw wires between them to make stuff happen. I just needed to know which blocks to use. I found some instructions in the GNURadio repository, but they said to use certain blocks, such as ATSC Field Sync Demux, that I couldn't find.

I subscribed to the mailing list and asked about that. Ron Economos was very helpful and responded that the block I wanted had been renamed. He also offered to help me if I wanted to make the ATSC decoder work.

I continued to communicate with him and he said I should use the pre-made flowgraph file, "file_atsc_rx.grc". This contains the entire ATSC decoder in one block. It was a great idea, since I would've had to import and configure each individual block if I hadn't used this file.

I initially recorded a RAW IQ file in HDSDR (on Windows) and tried to decode it in GNURadio. It produced an unusable TS file. Then I tried a few more times. Sometimes I would get empty output files.

Finally, Ron told me that if there was any DC in the middle, it would break the decoder. I applied DC cancellation and got a working video file on September 7.

How to do it:

I'll assume you've got your SDRPlay's driver installed already. If not, you can find instructions on the SDRPlay website.

1. The easiest way to use GNURadio is to download the latest Live DVD from http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD. It's over 1 GB, so start the download now so it can be done by the time you're ready for it.
2. Install HDSDR. You can find it at http://www.hdsdr.de.
3. Install the EXTIO plugin for the SDRPlay. It can be found at http://sdrplay.com/windows.htm. Make sure to install it in the HDSDR program folder.
4. Connect an antenna to your SDRPlay. A rooftop Yagi is best, but "rabbit ears" will also work.
5. Connect the USB connection to your computer. Turn on HDSDR.
   
6. If everything is working, you will see a bright blue button labeled EXTIO. Click it. You will get a dialog similar to this:
   
7. Under IF Bandwidth, choose 8 MHz. Make sure Sample Rate is set to 8.00
8. Enable Tuner AGC is probably turned on for you, but if not, turn it on.
9. Now click Advanced (at the bottom.) It should look like this:
   
10. You *must* change Periodic to One Shot. Then change Tracking Period to 58.6 uS. Click Apply and Exit.
    
11. Click Exit on the first dialog to return to HDSDR.
12. There are some buttons on the bottom left. Click the one labeled Options [F7]. Then click Input Channel Calibration for RX.
    
13. There's a button at the top-right labeled Off. Click it to change it to Auto.
    
    
14. Click OK.
15. Now you need to know the frequency of the TV station you want to record. To find a TV channel, go to http://www.antennapoint.com or http://antennaweb.org. I prefer antennapoint.com. Enter your zip code and it will give you a list of the TV channels in your area.
16. In the table of channels, you will see a column labeled RF Channel. I'll pick channel 12.
    
17. You need to find the desired station's RF channel and look it up at https://en.wikipedia.org/wiki/North_American_television_frequencies. In the table, find the channel and look under the Lower Edge column. That gives you the channel's lower edge frequency in megahertz. Add 3 to get the proper tuning frequency. The result will be used in the next step.
    
18. Then, in HDSDR, tune the LO frequency to the result you got in the last step.
    
19. In the buttons at the bottom of HDSDR, click Start [F2].
    
20. You should now have a waterfall that looks like this:
    
21. The stronger the signal, the greener, then redder, it'll get. Above is a great signal. If you have blue empty areas in the channel, repeat steps 16-18 to choose a stronger one. For example, this is what it should NOT look like:
    
22. Now right-click the Record button (the red circle) and you will get this dialog:
    
23. Under Recording Mode, make sure RF (full input signal) is checked, and uncheck (if checked) IF and AF.
24. Change Recording Format to RAW and Sample Type to PCM16.
25. (Optional) Beside RF (full input signal), change WAV file split size to 4095 MB (or higher).
26. Lastly, change Recording Directory to point to a fast disk, preferably a RAM drive. You will need about 32 MiB/sec sustained write (28 MiB/sec if using 7 MHz) to avoid dropping samples. I use SoftPerfect RAM Disk, which is free.
27. Click OK to close the dialog.
28. Take a recording by clicking the Record button. You may be limited by storage space to a minute or two if using a RAM drive.
29. When you're done recording (or your RAM drive runs out of space) click the Stop button twice.
    
30. If you used a RAM drive, now is the time to move the file off of it and onto your normal hard drive.
    
31. (Recommended) If you used a RAM drive, you should unmount it to free up the memory
32. Now, when your Live DVD image finishes downloading, burn it to a DVD. Alternatively, you can boot the ISO file in a virtual machine, but that goes beyond this tutorial.
33. Unlike Windows discs, this one doesn't ask you to "Press any key to start...", so it will boot up without intervention. It will take quite a while to start. When it does, there will be an icon labeled GRC on the desktop. Double-click it and wait for it to load.
34. Click the Open button at the top.
    
35. Click File System in the left sidebar.
    
36. Navigate to usr/local/src/pybombs/src/gnuradio/gr-dtv/examples and open file_atsc_rx.grc
    
37. There is a block labeled sample_rate. It will be set to "6.25M". Change it to 8000000. It should now say "8M"
    
38. Double-click the block at the bottom labeled File Source. In the dialog that comes, click the "..." button beside the File field. Find and select your IQ file. Then click OK.
    
    
39. Now double-click the File Sink block and save your output video file:
    
40. Now click the Play button to execute the script:
    
41. You'll get a terminal window. (The errors you see in the picture are nothing to worry about)
    
42. Now boot back into Windows and open your TS file in VLC Media Player. VLC Media Player will let you choose which sub-channel to view, whereas most other players won't.
    

Troubleshooting:

If your TS file is empty (0 bytes) then (most likely) you didn't cancel the DC bar in the middle of your spectrum recording. Experiment with your settings until it goes away. If you're sure you don't have a DC spike, then check to see that the sample rate in GNUradio matches your file's sample rate (you might have set GNUradio to 8 MHz and fed it a 7 MHz file, or vice versa).

If you get "!!! atsc_fs_checker: PN63 error count = xx" errors in your terminal window, then you experienced bad reception (or interference) during the recording. Take a new recording, adjust your antenna, or choose another station.