Gr-atsc module transmit questions

GNU Radio
#1

Hi,

I am relatively new to gnuradio block-level development and am working
with
the gr-atsc module. I am specifically interested in the transmit portion
and
have a few [likely elementary] questions:

  1. From what I can see the transmit functionality is only implemented up
    to
    the atsc_field_sync_mux(), I don’t see the symbol mapping or VSB
    modulation
    though I have read a few other posts that suggest it is there. The
    gnuradio
    0.9 has GrAtscWeaverModHead and GrAtscWeaverModTail header files but
    maybe
    these did not get modified into gr 3.x.

  2. The atsc_field_sync_mux block is derived from gr_sync_block however
    it
    outputs more data fields than it consumes (by a factor of 313/312). Even
    though this seems to work, for my own benefit I re-did this as a
    gr_block
    but I am not sure if that is necessary; could someone shed some light on
    why
    gr_sync_block works (or appears to but doesn’t)?

Thanks for your time, JJ

#2

On Sat, Sep 24, 2011 at 10:40 AM, Jay J. [email protected] wrote:

these did not get modified into gr 3.x.

Well, the atsc receive functionality hasn’t worked properly for some
time.
It’s been on my todo list for ages, but I haven’t gotten there, yet, so
if
you are working on it and can fix it up, that would be great!

So having said that, no, I don’t think all of the pieces to make an atsc
transmitter are there, either. So I don’t think you are wasting your
time or
far off track.

  1. The atsc_field_sync_mux block is derived from gr_sync_block however it
    outputs more data fields than it consumes (by a factor of 313/312). Even
    though this seems to work, for my own benefit I re-did this as a gr_block
    but I am not sure if that is necessary; could someone shed some light on why
    gr_sync_block works (or appears to but doesn’t)?

Thanks for your time, JJ

Yes, if the block is outputting 313 and consuming 312 items, then it’s
not a
sync block, so it sounds like you are doing the right thing. Being off
by
that small amount will have an effect, but my guess is that it was
minimal.
Maybe a blip or overwriting a value or two here and there. So it was
probably that the problem wasn’t noticeable but present.

Let us know how you’re getting along with it.

Tom

#3

I have converted atsc_field_sync_mux to type gr_block and added
atsc_symbol_mapper and atsc_weaver_mod_head. The rest can be done using
existing GR blocks; I don’t frequency translate the signal away from
complex
baseband (see 3 below):

[atsc stuff] => [float_to_complex] => [fir_filter_ccf] =>
[pfb_arb_resampler_ccf] => [file sink]

I have a couple more questions:

  1. Is there a reason the weaver_mod_tail module was introduced as
    opposed to
    the output being complex baseband (-3 MHz to 3 MHz)? I could combine
    some of
    the other blocks with frequency translation to mimmic what was
    GrAtscWeaverModTail but im not sure that is the idea here.

  2. What is the purpose of the atsci_x functions as opposed to atsc_x?

Thanks, I’ll get this cleaned up and documented and submit it.

Jacob

#4

On Mon, Sep 26, 2011 at 12:34 PM, Jay J. [email protected] wrote:

  1. Is there a reason the weaver_mod_tail module was introduced as opposed
    to the output being complex baseband (-3 MHz to 3 MHz)? I could combine some
    of the other blocks with frequency translation to mimmic what was
    GrAtscWeaverModTail but im not sure that is the idea here.

That was before my time. Anyone around who worked on this have an
answer?

  1. What is the purpose of the atsci_x functions as opposed to atsc_x?

There’s concept of separation of an implementation file (atsci_) verses
a
GNU Radio block (atsc_). The implementation block is the raw algorithm
that
gets wrapped up into a real GNU Radio block in atsc. We’ve used the same
structure on occasion in gnuradio-core, where we’ll have gri and gr
files.
The gri files tend to be written in a way that other blocks could call
them
as a function/object, too.

Thanks, I’ll get this cleaned up and documented and submit it.

Jacob

Great, thanks!

Tom