Re: [Discuss-gnuradio] Questions on US digital cable ...

[Jan Schiefer]

Vijay Ramasami wrote:
> On 8/17/07, Jan Schiefer <address@hidden> wrote:
>   
> > Vijay Ramasami wrote:
> >     
> > > Thanks for the information David. I will look up ITU-J.83B ...
> > >
> > > Do you happen to have any captured QAM cable data (or any website that
> > > lists the data) ? I wanted to see if I can put together a software
> > > demod for digital cable ...
> > >
> > > On 8/13/07, David I. Emery <address@hidden> wrote:
> > >
> > >       
> > > > On Mon, Aug 13, 2007 at 10:52:54AM -0400, Vijay Ramasami wrote:
> > > >
> > > >         
> > > > > Hi,
> > > > >
> > > > > I have a couple of questions:
> > > > >
> > > > > 1. Does the US digital cable system follow the DVB-C standard (or one
> > > > > of its annexes) ? Is there any information (website) on the typical
> > > > > symbol rates, bandwidths (I am guessing approx 6 MHz), used ?
> > > > >
> > > > >           
> > > >         There is a Cablelabs spec that defines what is used.   The ETSI
> > > > standards (ITU-T J.83B) also define the particular parameters as well.
> > > >
> > > >         I can look up detailed references if needed...
> > > >
> > > >         The are actually only two standard modulations in wide use 64QAM
> > > > with a particular set of parameters that yields a 30 Mb/s signal with a
> > > > 5.056941 Msym/symbol rate and a 256QAM signal which yields a 38.9 Mb/s
> > > > signal with a symbol rate of 5.360537 Msym/s
> > > >
> > > >         Both signals are 6 MHz wide as US CATV is universally 6 MHz
> > > > channel based.
> > > >
> > > >
> > > >         
> > > > > 2. Has anyone successfully captured (preferably unencrypted) digital
> > > > > QAM transmissions using the USRP ? If so, can you please send me a
> > > > > link to the data ? Given that the symbol rates are in the range of 5-6
> > > > > Ms/s, it must be possible to use 16 MHz sampling frequency to
> > > > > demodulate the signals.
> > > > >
> > > > >
> > > > >           
> > > >         I have used a number of purpose built demods, but not yet tried
> > > > a USRP solution.   Some of the cable transport streams have open
> > > > channels, but you will find most are encrypted except the local OTA HD
> > > > signals and a few freebie promos.
> > > >
> > > >         It is also possible to MODULATE QAM cable standard signals,
> > > > something that gets more useful every month as more QAM/ATSC tuners are
> > > > shipped for cable ready setups with CableCards rather than set top
> > > > boxes.   This of course allows direct input of MPEG transport streams
> > > > into the digital domain of LCD/plasma panels with no analog step...
> > > >
> > > >
> > > > --
> > > >   Dave Emery N1PRE/AE, address@hidden  DIE Consulting, Weston, Mass 02493
> > > > "An empty zombie mind with a forlorn barely readable weatherbeaten
> > > > 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
> > > > celebration of what could have been, but wasn't and is not to be now either."
> > > >
> > > >
> > > >
> > > >         
> > If you can't find any, let me know and I might be able to help. I have
> > access to 2 QAM-64 channels and 15 or so QAM256 channels, some HD, all
> > unencrypted. I probably have some encrypted ones too, but I don't know
> > how many, as they are encrypted...  If you can write a little capture
> > program, I can try to hook up the USRP to the cable jack and see whether
> > I can capture something. Problem is, I don't have a TVRX (yet), but this
> > that may be a good excuse to order one. :-). Provided the phase response
> > of the TVRX is sufficiently flat for this kind of signal. Anybody have a
> > guess?
> >
> > Cheers,
> > Jan
> >
> >     
>
> Hi Jan,
>
> I would highly appreciate it if you can capture a few QAM-64
> snapshots. I was able to successfully demodulate signals captured from
> a QAM modulator, but I don't have access to a real-world cable source.
> I guess the python script "usrp_rx_cfile.py" (in the examples
> directory) can be used to capture samples. We need at least 16 MHz
> sampling frequency for symbol timing recovery to work properly.
>
> Thanks,
> Vijay.
>   
Hi Vijay,

sorry this is taking so long, but I think I have what you need now. With 
a 16MHz sampling frequency you get only 8 bits of resolution, so I was a 
little skeptical as to whether this would be sufficient. I played around 
with a 10 second QAM64 snapshot (640MB, stored as 16-bit signed ints, 
which gzips down to around 270MB). I put a chunk of this data into the 
Agilent 89600 Vector Signal Analyzer software, and with equalization 
turned on, the constellation actually looks pretty reasonable. So what I 
captured must not be complete garbage :-).

Let me know if you still need this and I find a shady spot on the web to 
put it. Or if you'd rather have something shorter, or stored as floats, 
let me know.

Cheers,
  Jan