Forum: GNU Radio gr-atsc

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Dc48f9c00e3e6de9640898a531c26d89?d=identicon&s=25 Charles Swiger (Guest)
on 2007-04-27 16:17
(Received via mailing list)
The 2.x version of atsc_field_sync_demux has been proven to work.

The equalizer still looks like an issue with symbol/tag alignment -
A working 0.9 system demux syncs on a (FIELD-2) at 3277436, while a
failing 2.x system syncs at 3277487 - a difference of exactly
d_offset = ntaps - npretaps - 1 (51).


How to do the 0.9 alignment scheme:

  inputs[1].index = output.index + offset;      // align equalizer tags

in gr 2.x I have NO idea.



--Chuck
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-04-27 17:43
(Received via mailing list)
On Fri, Apr 27, 2007 at 10:15:35AM -0400, Chuck Swiger wrote:
>   inputs[1].index = output.index + offset;      // align equalizer tags
>
> in gr 2.x I have NO idea.
>
>
> --Chuck

Chuck,

I'll take a look at this as soon as I finish with the USRP power
management problem.

Thanks,
Eric
Dc48f9c00e3e6de9640898a531c26d89?d=identicon&s=25 Charles Swiger (Guest)
on 2007-04-27 19:07
(Received via mailing list)
On Fri, 2007-04-27 at 08:48 -0700, Eric Blossom wrote:
> On Fri, Apr 27, 2007 at 10:15:35AM -0400, Chuck Swiger wrote:
> > The 2.x version of atsc_field_sync_demux has been proven to work.
> >

> I'll take a look at this as soon as I finish with the USRP power
> management problem.
>

Actually I just got the 2.x equalizer to work (w00t!). Then verified the
2.x field sync checker as working ok.

That leaves just ONE module, and then we'll be all up to date: the Bit
Timing loop.

Heheh.

--Chuck
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-04-27 19:12
(Received via mailing list)
On Fri, Apr 27, 2007 at 01:06:19PM -0400, Chuck Swiger wrote:
> 2.x field sync checker as working ok.
>
> That leaves just ONE module, and then we'll be all up to date: the Bit
> Timing loop.
>
> Heheh.
>
> --Chuck

Excellent!

Eric
Dc48f9c00e3e6de9640898a531c26d89?d=identicon&s=25 Charles Swiger (Guest)
on 2007-04-27 20:33
(Received via mailing list)
On Fri, 2007-04-27 at 13:06 -0400, Charles Swiger wrote:
> 2.x field sync checker as working ok.
>
> That leaves just ONE module, and then we'll be all up to date: the Bit
> Timing loop.
>

Well, it turns out the bit_timing_loop already works so at this point
the 2.x gr-atsc is fully functional from antenna to mpeg output (with
warts, like a segfault in btl-fsd.py at the end of a decoding run).

I'll put better instructions on how to use it in the
gr-atsc/src/python/README shortly. The biggest advantage is that now we
can easily run differnt combinations of modules to spread the work over
multiple processors, tied together with named pipes.  The most obvious
improvement is probably using an fpll that takes complex input data.
Right now we have to interpolate by 3 (interp.py), shift to 5.75Mhz and
convert to float (xlate.py), then feed the fpll which does another
shift.

--Chuck
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-04-27 21:28
(Received via mailing list)
On Fri, Apr 27, 2007 at 02:33:01PM -0400, Chuck Swiger wrote:
> On Fri, 2007-04-27 at 13:06 -0400, Charles Swiger wrote:
> >
> > That leaves just ONE module, and then we'll be all up to date: the Bit
> > Timing loop.
> >
>
> Well, it turns out the bit_timing_loop already works so at this point
> the 2.x gr-atsc is fully functional from antenna to mpeg output (with
> warts, like a segfault in btl-fsd.py at the end of a decoding run).

This is great news!

> I'll put better instructions on how to use it in the
> gr-atsc/src/python/README shortly. The biggest advantage is that now we
> can easily run differnt combinations of modules to spread the work over
> multiple processors, tied together with named pipes.  The most obvious
> improvement is probably using an fpll that takes complex input data.
> Right now we have to interpolate by 3 (interp.py), shift to 5.75Mhz and
> convert to float (xlate.py), then feed the fpll which does another
> shift.
>
> --Chuck

Eric
This topic is locked and can not be replied to.