I think the only part which will be a potential stumbling block is the PLCP block - which does the de-framing of the demodulated signal, and puts it in a message queue. As I understand it you can have message queues in GRC, but since there's no 'display' it may seem non-obvious about what to do with it. The rest of the blocks are pretty well-behaved as far as going in GRC - I believe I got it working once without much difficulty. So if you're just concerned with the 'lower level's - i.e. the physical layer, as the original poster apparently is - you can put the FIR filter, slicer (which together do the de-spreading), and demodulation blocks in GRC, no problem. Bear in mind, since the PLCP is where the de-scrambling happens in the current code, you either have to instantiate a de-scrambler block (I believe the one defined in the BBN code works, but isn't even used as a stand-alone block), or just remember the bits coming out of the demod are still scrambled. Doug
On Wed, Sep 30, 2009 at 11:56 AM, Josh Blum <[email protected]> wrote: > The bbn can be but a mere block within the mighty GRC! ~Muhaha > > Meaning... > There is no bbn stuff in currently in grc. You can always add blocks: > http://gnuradio.org/trac/wiki/GNURadioCompanion#AddingCustomBlocks > > How easy this is depends on how well the bbn code adheres to the block > model... If it uses function callbacks to pass messages (like the > blks2.packet mod) then we are probably out of luck. > > Perhaps when we start using PMTs and someone adds PMT-based message passing > into the bbn code, then it will be a more possible. But I am not familiar > with the bbn code, so maybe it is possible now? > > -josh > -- Doug Geiger [email protected] _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
