Re: [Discuss-gnuradio] gnuradio companion

[Douglas Geiger]

 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 <address@hidden> 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
address@hidden