# Gr-atsc module transmit questions **URL:** \ **Category:** GNU Radio\ **Created:** [September 24, 2011, 4:41pm UTC](https://www.ruby-forum.com/t/gr-atsc-module-transmit-questions/212179 "2011-09-24T16:41:15Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\ **Post date:** [September 24, 2011, 4:41pm UTC](https://www.ruby-forum.com/t/gr-atsc-module-transmit-questions/212179/1 "2011-09-24T16:41:15Z")
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 ---
**Author:** ![shambolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e36b37/32.png) [@shambolic](https://www.ruby-forum.com/u/shambolic)\ **Post date:** [September 26, 2011, 2:57pm UTC](https://www.ruby-forum.com/t/gr-atsc-module-transmit-questions/212179/2 "2011-09-26T14:57:37Z")
On Sat, Sep 24, 2011 at 10:40 AM, Jay J. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![shambolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e36b37/32.png) [@shambolic](https://www.ruby-forum.com/u/shambolic)\ **Post date:** [September 26, 2011, 6:35pm UTC](https://www.ruby-forum.com/t/gr-atsc-module-transmit-questions/212179/3 "2011-09-26T18:35:31Z")
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 ---
**Author:** ![shambolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e36b37/32.png) [@shambolic](https://www.ruby-forum.com/u/shambolic)\ **Post date:** [September 27, 2011, 4:34pm UTC](https://www.ruby-forum.com/t/gr-atsc-module-transmit-questions/212179/4 "2011-09-27T16:34:44Z")
On Mon, Sep 26, 2011 at 12:34 PM, Jay J. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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