Re: [Discuss-gnuradio] HDTV

[Ilia Mirkin]

On Fri, 2005-05-27 at 04:06 -0700, Eric Blossom wrote:
> There's nothing special about the 20MS/sec.  That's just what the
> Measurement Computing PCI DAS 4020/12 A/D board put out.  It's what we
> had to work with, so we used it.  16MS/sec real baseband should fine
> with a couple of tweaks.

I actually looked at tweaking the code, and was unsuccessful (but then
again I didn't have a clean enough signal, and I was also unfamiliar
with gnuradio-0.9 architecture). There are a few more things to change
than just the sampling rate it expects. I was merely suggesting the
easiest thing to do (i.e. use gnuradio-0.9 directly), to see if you have
a strong enough signal, and then tweak all you want.

Additionally, I don't think the USRP can provide 16MS/s real baseband.
It can do 16MS/s complex, but that was more than USB could do in my
case, hence the shenanigans below... 32MB/s was just a little over what
I was able to get in the speed tests.

> > What I did was take the USRP, record the ATSC signal to a file centered
> > at 0MHz using DDC (make sure to downconvert in the right direction)
> > (compex floats), which allows you to use 8MS/s and the USB bus seems to
> > be able to keep up with that, mostly. Then you can write a script to
> > convert that to a file of shorts with the signal centered at 5.75MHz
> > (e.g. by multiplying it by a complex sine wave).
> 
> There's no reason to put it back at 5.75MHz.  Just change the
> constand that defines the location that the FPLL is looking for the
> pilot tone. 
> 
> Since the USRP is currently lacking the half-band filter, the signal
> wouldn't have been flat enough (given our equalizer) and will have
> aliasing that could cause a problem.  The fix is to make the half-band
> filter work in the USRP.  Voluteers and patches welcome.  The guts of
> the code are done and in CVS.  The state machine to control it still
> needs to be written.

Could you explain this, potentially? Or give references for us
non-signals types? What signal wouldn't have been flat enough, and why?

> > Now you have a file that the gnuradio-0.9 code is willing to deal with,
> > and if your signal is clean enough then you should get an mpeg file.
> > This is where I hit a dead end, and thus wasn't really willing to try to
> > convert the old code to new code since I had no way of knowing if it
> > would work or not.
> 
> There are at least three independent existence proofs that the old
> code works.  Me, John Gilmore and the folks at UIUC.  A bit of
> searching through the archives and/or google will turn up links.
> 

Right -- but if I were to port the code to current cvs, I would have no
way of telling if my ported code worked (without having other people
test it, and I guess I wasn't interested enough...)