Watching ATSC TV with an SDRplay SDR and GNU Radio
ATSC is the digital HD TV standard used within the United States and Canada. It is 6 MHz wide so the RTL-SDR with its maximum bandwidth of about 2.8 MHz cannot decode this signal. However, higher end SDR’s such as the SDRplay, Airspy and HackRF have larger bandwidths that can easy cover 6 MHz.
One SDRplay owner was able to figure out a way to decode ATSC by using a decoder written in GNU Radio. With the process the author used we note that other wide band SDR’s such as the Airspy and HackRF should also be capable of achieving the same results.
The process the author used was to first record a RAW IQ WAV file in HDSDR in Windows, making sure that any DC spike correction is applied. The WAV file is then opened in a premade GNU Radio flow graph in Linux and processed into an MPEG file. The process is not real time. The authors article shows a step by step tutorial on how its done.
In an update post to his results the author also notes that to successfully do a recording at the maximum SDRplay bandwidth of 8 MHz a RAM disk or perhaps SSD is required so that samples are not dropped.
Just go out and buy a Hauppauge HVR-955Q USB Stick. Pair that with TSReaderPro, you will have N ATSC and QAM Analyzer that can record the incoming streams.
Hauppauge : WinTV-HVR-955Q Product Description
For some, the fun is in doing it the “hard way” and learning something in the process 😉
Now it would be nice to see a simular method for QAM. I know a lot of it is encrypted in the US cable operators but ClearQAM still exists, and some simple “privacy mode” SCTE-58 lightweight encrypted QAM exists for DTA’s that may be able to be decoded in software, provided the processor is up to the task.
Why isn’t there a RTL-SDR dongle that can decode ATSC in “normal” mode?
I want a dongle that can be used to watch HD TV in North America (in realtime),
or be used with RTL-SDR tools in debug mode.
Kudos to the guy who figures out how to run 2 RTL-SDR’s at 3 MHz each, combine the signal, decode, and produce a live video stream. If our processors can’t handle it today, just wait a year.
You take the covers off both RTL-SDR, remove the crystal from one and connect (short) wires from the other crystal to that board, so that both share a common clock. That way when the crystal drifts up and down in frequency it will drift by the same amount for both boards simultaneously. The clock will still drift a lot and have poor jitter, that could be reduced by removing both crystals and using a much higher specification external crystal (€€€/$$$/£££).
You now have two phase coherent receivers. And using cross-correlation you can synchronize both while tuned to overlapping parts of the spectrum. You will need enough RAM to buffer all the samples from both, because they both can never start sampling at the exact same time. Then you need to knit the two spectrum’s into one. And finally you have to process it as you normally.
See https://www.rtl-sdr.com/rtl-sdr-based-coherent-multichannel-receiver/ for some info.
P.S.Two would not be enough, the most that an RTL-SDR can do under ideal circumstances is about 2.56MSPS (probably 2.4MSPS in a less than ideal setup) without dropping samples. And if any RTL-SDR is dropping samples then they are no longer phase coherent.
Without a common clock, and all samples, the problem is analogous to trying to drive a car with two un-synchronized, independent engines one for the left side of the car and one for the right side of the car. And both engines have different random performance characteristics. And you can only see the speedometer for both engines, not what is going on outside the car.
sorry correction needed “buffer all the samples from both” should be “buffer all the overlapping samples from both”
Trying to replicate the ATSC capture step using a USRP B210 and GNU Radio, and not having much luck. I think I’m hitting the issue the author talks about with DC issues…but I cannot figure out how to deal with them (I’m getting a 0 byte TS file which he says is the ATSC decoder seeing DC and breaking). Any suggestions on how to mitigate DC in the USRP? Thanks.
Have you got any other DC-like solid bars in the passband? Are your sampling rate and format correct? Also, your signal might be too weak.
there’s a gnu radio block for dc removal
does anyone know the technical reasons why the RTL dongles cant go above 2.8MHz in SDR mode when they can decode 7MHz DVB-T in “normal” mode?
When the RTL2832U chip is in debug/SDR mode the bandwidth is limited to about ~3 MHz.
The closest analogy that I can think of would be reading data through a serial port over USB vs reading data over USB.