[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] HDTV
From: |
Ilia Mirkin |
Subject: |
Re: [Discuss-gnuradio] HDTV |
Date: |
Fri, 27 May 2005 13:48:54 -0400 |
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...)