Understanding Spread Spectrum (Direct Sequence)

I've recently been working on some spread-spectrum DSP software for an experiment I'm conducting. I'm very familiar with frequency-hopping spread spectrum (FHSS). In fact, I own a pair of the discontinued TriSquare walkie-talkies. However, it took me a while to wrap my mind around direct-sequence spread spectrum, and now that I understand it I'm providing a simplified explanation for the benefit of others like me.

Background

Spread spectrum involves spreading a signal's bandwidth to enable many users to share a frequency band. It has the added benefit of providing decent privacy as it's very difficult to de-spread a signal unless you know the unique code used to spread it.

Before I got an SDRplay, I tuned my RTL-SDR to 900 MHz and spoke into a TriSquare walkie-talkie. On the waterfall I could see very short bursts of relatively wide FM. When a burst happened to land on my passband I could hear my voice momentarily. This came as a surprise since I had thought these walkie-talkies used encrypted digital voice. Even when not using my TriSquare I have seen similar bursts in the same band, and they are quite strong. These walkie-talkies are extremely rare so I knew it had to be another device. My research makes me think these are electric and gas meters.

I am particularly interested in creating a DSSS transmitter, but I didn't understand how to spread a signal evenly over a band, as opposed to hopping. This YouTube video was extremely helpful.

What doesn't work:

I misunderstood the video the first time around. Here's what I thought it meant:

Let's say I want to spread the string "SaaS" with a 20-byte spreading code of

"356A192B7913B04C54574D18C28D46E6395428AB".
(By the way, that's the SHA-1 hash of "1")

I thought spreading worked by literally spreading the whole message (or at least a chunk) over the spreading code. Here's what I imagined:

You repeat each letter of the string 5 times, and since the string is 4 bytes this becomes 20 bytes:

SSSSSaaaaaaaaaaSSSSS
In hex that is 5353535353616161616161616161615353535353

Then you XOR it with your 20-byte spreading code:
              5353535353616161616161616161615353535353
XOR     356A192B7913B04C54574D18C28D46E6395428AB
------------------------------------------------------------------------------
             6066651262585323565850522351551066676664

All seemed well and good until I wanted to despread it. I was completely at a loss as to how that would be done and, looking over the video again, saw that it would be a mess, if it was possible at all.
(On a side note, I know I could just XOR it again like a one-time pad and thereby recover the data, but if I had combined it with other signals then it likely would have been unrecoverable.)

What does work:

I found that in fact each bit of the message must be spread with the entire spreading code. So let's say I have a spreading code of 10010101. Just XOR each message bit by the entire spreading code. If I want to transmit a 1, then it would look like this:

            10010101 (entire spreading code)
XOR    11111111 (just one message bit)
----------------------
             01101010 (spreaded bits, chip rate 8x)

Now here's where it gets interesting. The signal must be transmitted as a waveform, so these bits are converted to voltages. The standard convention is 0 = +1 volt while 1 = -1 volt. However, when I was writing my modulator and demodulator I found it easier to think of it as 1 = +1 and 0 = -1. Using my convention, the message wave voltages would be:

-1 +1 +1 -1 +1 -1 +1 -1

Repeat the process with all the transmitters that must share the band. Then add their values together to get a composite waveform.

How do you recover just one stream? Assuming you tune in at the beginning of a bit's spreading cycle (which you can assume since you're working with samples in a file), simply multiply the +1/-1 values of the desired spreading code by the corresponding values of the composite waveform. This will yield a lot of crazy, fluctuating values. Average them. Unlike the YouTube tutorial, the average you get will not be clean-cut or precisely 1 or 0. You will have to depend on the sign to determine the actual bit. The software provided below takes this into account.

If you want to try this concept, I have written a program that generates *.CSV files of the waveforms of whatever text you like. It uses the 0=-1/1=+1 convention and uses just the sign of the average to determine the bits. Just save several different CSV files with different spreading codes and copy-paste them into their own Excel columns in one document. Then apply Excel's Average Add function to the final column. Copy-paste that column into its own file called "compositewaveform.csv" or whatever you like. The demodulator will read this file, accept the spreading code in a variable, despread the message, and show it on screen.

Here are download links for my program:
Written in Liberty BASIC v4.50

Spreader (proper_adjustable_spreader.bas)

Despreader (dsss_demod.bas)

Note that if you don't feel like combining several waveforms in Excel, you can still tell the demodulator to open just one waveform file and it will still despread it, provided you have given it the right spreading code.

You can experiment with spreading codes to see which ones coexist well. I have experimented with using the first 16 bits of SHA-512 hashes of consecutive numbers. My favorite hashing tool is a hex editor called HxD Hex Editor. It also has a great disk editor. However, I don't think it can copy-paste excessively large chunks. For that, use HHD Hex Editor Neo.

I have found that some of the data is corrupted when too many signals are together in the composite waveform. Also, some spreading codes do not coexist well at all, losing all the data in their streams. But higher chip rates, while reducing throughput, also reduce errors.

New recorder for SDRsharp breaks 2GiB limit

In my post ATSC now possible on magnetic drives I said that SDRsharp was the perfect solution for TV recording but lamented its 2 GiB limitation.

In my opinion, HDSDR and SDRsharp are the two best SDR applications. HDSDR has minuscule computing requirements (low CPU usage) and more reliable recording while SDRsharp draws a slightly better waterfall and (at least for older versions) is more fun to use overall.

I especially like that HDSDR is written (AFAIK) in rock-solid, no-frills Win32 C++ instead of SDRsharp which was done in C# .NET. Pure C++ produces smaller and lighter programs that don't crash or bog down the CPU quite as easily.

Since the recording function is so reliable and well-written in HDSDR, not to mention the support it has for files of unlimited size, I have written 2 emails to the author of HDSDR asking him to add 8-bit recording. However, he has not gotten back to me. On the HDSDR website it says the latest version is from 2013, implying that he has halted development. That fine by me, though. Apart from the lack of 8-bit recording, HDSDR is perfect and I hate when software developers mess with perfection.

Last week I emailed Youssef Touil, the author of SDRsharp, requesting that he update SDRsharp to support larger files. After I explained that it wasn't specifically for the SDRplay he kindly sent me links to plugins that will unlock >2GiB recording. Here they are:

Baseband Recorder (http://rtl-sdr.ru/uploads/download/basebandrecorder.zip)
WavPlayer (http://rtl-sdr.ru/uploads/download/wavplayer.zip)

Today I had a chance to test the Baseband Recorder. To use it yourself, open the zip file after downloading and go into the basebandrecorder folder:

I only needed the Baseband Recorder because my goal is to convert the files in Audacity, not play them back. Just select the 4 files you see and do Ctrl+C. Then go into your SDRsharp folder and paste.

Then you will need to open MagicLine.txt and do Ctrl+A and Ctrl+C. Close MagicLine.txt and open Plugins.xml in your SDRsharp folder. Paste the line in where indicated:

You may have more or fewer plugins than I do, but you get the general idea. Also, as you can see, it needn't be tabbed over.

Save Plugins.xml and open SDRsharp. You should see the new recorder at the bottom of the sidebar.

Click the arrow to expand it.

And there you have it: a flexible new recorder that even supports choosing an output directory. To show just how flexible it is, here is the Configure dialog:

What... did that just say WAV RF64?!? Yes it did!

With this plugin we are very close to being able to do some awesome stuff with ATSC decoding. Now the last step is to figure out how to capture the necessary 7 MHz bandwidth as opposed to SDRsharp's baseband which is limited to 250 KHz. I was really hoping I could capture the whole bandwidth with this plugin.

(Update 03/01/2016)

I made a mistake above. I had confused Baseband with passband. Baseband in SDR# is the same as RF in HDSDR, which means that this plugin will record your full RF bandwidth. I had my SDRplay set to about 200 kHz during the first test, and so the WAV file's properties said 200 kHz sampling, reinforcing my false assumption that this plugin only records passband.

I am very pleased to see that progress bar underneath "Dropped buffers: 0". In case you didn't know, the progress bar represents the recording buffer. In a previous post I suggested that a buffer be used to smooth out the latency inherent in magnetic hard drives. It seems that the author of this plugin has taken that into account. I don't think the buffer is very big, but it's certainly better than nothing (ever notice how the native SDR# recorder seems so prone to dropping samples? I suspect the native recorder has no buffer.)

Today I made some TV recordings on 8-bit with this plugin, converting them to 16 bits in Audacity and decoding them. Sure enough, the plugin works as I had hoped. I was able to take recordings of unlimited length and I chose to stop them at 8 GB because I didn't want Audacity to take too long to convert them. Both final decodes were rife with errors, although WACH had some perfect spots. I only used the two blowtorches in my area, WJBF and WACH. These two have always been the most reliable, so it is obviously something wrong with the new method. I think it has something to do with 8-bit and the reduced dynamic range because no buffers were dropped.

In conclusion, if you can get around the reliability problem then it is now possible to take TV recordings of virtually unlimited length using magnetic hard drives.

Special thanks to Youssef Touil for showing me the final piece of the puzzle that made this possible.

Why I still prefer Windows XP

A few days ago I restored my laptop to Windows XP from a hard drive image I made before upgrading to Windows 10. As you know, I only upgraded so I could use Visual Studio and Office 2013. I prefer XP and here's a major reason why:

Above you can see I've set my SDRplay to the full 8 MHz of bandwidth. It's tuned to a Volmet upper-sideband weather report and there is no stutter. HDSDR reports only about 50% CPU usage. (Notice how overall usage is not ~100%, like Windows 10 would be?)

Fortunately, I also imaged the drive before going back to XP, so I have a Windows 10 drive image. After a nice break from Windows 10, I have to restore it so I can finish an app I'm working on in Visual Studio.

I restored my Windows 10 backup. Here in Windows 10 I've got HDSDR tuned to some RTTY on lower-sideband and it stutters incessantly. CPU usage is almost 100%. (If you click to zoom in, you can even see a strip of waterfall smear at the top where HDSDR froze.)

But maybe Windows 10 isn't really to blame. Maybe my laptop is just too old to hardware-accelerate all the visual styles, so it has to be done by the CPU. I would like to blame it on the background processes, but HDSDR itself is at nearly 100% CPU, and the overall CPU reading is only marginally higher. A newer computer should be able to run HDSDR with 8 MHz bandwidth without breaking a sweat, but there's no denying XP was a much leaner OS.

Toshiba Encore first impressions

For Christmas I received a Toshiba Encore WT8-A32 8-inch Windows tablet. It has 2 GB RAM and 32GB storage. It was refurbished but like-new and cost only $91.19. It was an amazing deal because it's hard to find a working Windows tablet with that much RAM and storage under $100.

Tablet's best qualities

• Dual-band Wi-Fi (both 2.4 and 5GHz; 802.11abgn)
• 2 GB RAM (most cheap ones have 1 GB)
• 32 GB solid-state storage (16 GB on most cheap ones)
• 8 inches - pretty big
• Quad-Core Intel Z3740 CPU - fast and uncommon in cheap tablets
• This CPU family is said to be able to hardware-decode H.263, H.264, and even VP8, among others
• The GPU (built into the CPU) is new enough that it runs the latest Stellarium without problems

The Wi-Fi seems good. My Lenovo T60p was able to connect and do pings on a G network from much further away than the tablet, but it was a business-grade laptop and had bigger antennas, so that's to be expected. But the tablet's Wi-Fi is by no means bad. Aside from supporting 802.11n, which the Lenovo doesn't, it's been able to connect to the Wi-Fi at Sams Club while I was sitting in a car in the parking lot.

When I first turned it on, I was shocked at the display's contrast ratio. It uses IPS technology, so it's no OLED, but it looks a lot better than most other screens I work with.

Battery life is nice as long as the screen is dim. Just try to avoid Flash video on websites whenever possible. I use the latest Opera, which supports HTML5, and YouTube always selects HTML5 for me. I've read that it's more power-efficient that Flash, and I've observed it to be true. My battery went to almost nothing after watching a little bit of AFV on the official ABC website, which uses Flash, but I've been able to watch YouTube with HTML5 for hours without a recharge.

I also installed the K-Lite Codec Pack which comes with Media Player Classic. I experimented to see which hardware decoder would have the least CPU load. I downloaded the official music video of Little Talks by Of Monsters and Men from YouTube in 720p H.264 format using 4k Video Downloader, which is a lot nicer for this task than Any Video Converter. After trying both Intel Quicksync and DXVA2 Native, I saw that DXVA2 Native used significantly less CPU than Quicksync. I even asked about this on a forum related to K-Lite and the admin confirmed it.

You'll need a good dedicated USB device charger (included). Some mobile devices, including this tablet, will not charge off computers and certain wall chargers. I have, however, been able to charge it in the car.

I also learned that the Lithium-Ion batteries used in mobile devices should not be fully charged and discharged except once a month or even less. I'd always heard that batteries had a memory and so should be fully cycled, but everyone says this type does not have a memory and lasts longer if kept between 40% and 80%. Maybe that's how my Lenovo T60p's battery got ruined...

Battery pitfall

Recently the battery charge indicator had gotten stuck at 100%. It thinks it's 100%, runs down to nothing, and suddenly shuts off. Even if I stop charging at 82% or 74%, it's stays at that value. I did some searches online and this is a very common problem for mobile devices. It has to do with the battery not calibrating. I couldn't find a Windows tablet app to calibrate the battery, so I did some more reading and at least one person on a forum suggested letting it charge to 100%, running it until it turns off, and then charging it again. This is supposed to make it automatically re-calibrate the battery. But over the last 3 days the battery had been exhibiting this condition with no indication of stopping. I was concerned that I may have gotten a dud tablet.

How I saved my battery

Today I realized the tablet had only gotten stuck at 100% when I went to Sams Club 3 days ago. I normally kept my screen at its dimmest, but that day I set it one or two ticks brighter. It subsequently got stuck at 100% when I charged it. The next day it just turned off. After charging and dying several times over three days, today (1/13/2016) it went down to 67% when I had left it at 74%. It hadn't gone down at all in 3 days so this was a relief, but I had to be sure it wasn't just a fluke. Since AFV is notorious for draining the battery, I played a couple minutes of it, and sure enough, the battery went down at least 2 percentage points. The lesson? Expect a few days of automatic recalibration if you change your screen brightness.


The tablet has front and rear cameras and an ambient light sensor. Most of the time the Camera app just shows blackness because sometimes the cameras can't be connected to. Skype's camera preview showed green once when this happened but for some reason Skype can now connect without issues.

The tablet has a GPS sensor, a Broadcom BCM4752 chip. It supports 4 different satellite constellations and supposedly works indoors by triangulating Wi-Fi, although I haven't seen any way of doing that. The tablet rarely gets fixes when stationary and when it does they are very inaccurate. For me, at least, you have to be going about 3 mph (a brisk walk) or faster to get any fixes at all. If you are moving then it will consistently get fixes once per second and they are usually surprisingly accurate. I've even tested it in the car while traveling over 65 mph and it still got dependable position fixes once per second. The GPS sensor only provides info over the Windows Location Platform. It will not natively output NMEA 0183 streams. However, there are people on forums who are able to use conversion software to emulate a regular serial GPS.

The tablet runs Windows 8.1, which takes up most of the hard drive. I've read that upgrading to Windows 10 would free up a lot of space, but I don't think I'll upgrade for quite a while. My Lenovo T60p runs Windows 10 and seems to get slower every day. To some extent, so does a more recent laptop I upgraded. It also runs out of memory on my T60p way before it should, but that started recently. I looked it up online and I think it's a bad Windows Update (gotta love mandatory updates.)

Why I won't be upgrading my tablet to Windows 10 (yet):

1. Constantly phones home to Microsoft
2. Runs mysterious processes in the background for no reason, using hard drive, memory, and CPU time
3. The Start menu and taskbar notification icons are a bit unresponsive and sometimes the Start menu doesn't let you enter search keywords
4. Low on Memory errors and program crashes when there's still 500MB RAM left
5. All Windows Updates mandatory and automatic
6. Battery life rumored to be worse versus Windows 8 (no surprise: see #1 and #5)

On older Windows versions, such as XP, menus popped up immediately. The fact that the new Start menu and especially notification icons sometimes take a while to respond implies to me that that part of Windows' interface may be running on top of some emulator. Still, it's free, so we should expect some issues. I really like how XP was tolerant of low memory and you could be reasonably certain your computer was truly idle when you weren't using it.

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.