On Mon, Sep 26, 2011 at 12:34 PM, Jay Jones <[email protected]> wrote:
> 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: > > 3) 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? > 4) 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 > On Mon, Sep 26, 2011 at 8:56 AM, Tom Rondeau <[email protected]>wrote: > >> On Sat, Sep 24, 2011 at 10:40 AM, Jay Jones <[email protected]> wrote: >> >>> 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. >>> >> >> 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. >> >> >>> 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 >>> >> >> 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 >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
