discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vijay Ramasami
Subject: Re: [Discuss-gnuradio] Questions on US digital cable ...
Date: Sun, 13 Apr 2008 19:23:22 -0700

Jan,

Sorry. I have been out of touch with GNURadio for a while. I am very
happy to hear that you have some data available to test. I would
really appreciate it if you can find time to upload your data
(whatever size you are comfortable with - I have a fast connection and
hence 270MB should download fairly quickly). I am ready to jump back
in.

Thanks again,
Vijay.

On Fri, Sep 21, 2007 at 1:28 AM, Jan Schiefer <address@hidden> wrote:
>
> 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
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]