On Wed, Mar 02, 2011 at 09:00:36PM +0900, Minsuk Kang wrote:
That is, we are trying save all the samples of a packet (all complex
values) and demodulate at once in a function at a receiver.
We do something somewhat like this in gr-bluetooth. See
bluetooth_multi_block.cc and its subclasses in the git repo here:
We originally tried to string together separate blocks (squelch, ddc,
demodulator, clock recovery, binary slicer), but the resulting symbol
stream lost too much information about the relative timing between
packets. For our application we needed precise packet interval
information (like counting the number of samples between packets), but,
even without the squelch block, the demodulator produced a stream of
symbols that varied too much with respect to the sample timing.
Instead we use the history mechanism to ensure that we are always
working with a chunk of samples long enough to encompass an entire
packet, and we have reimplemented (mostly by copy and paste) all the
things mentioned above (that would traditionally be done in separate
blocks) in a single block. Then we use the demodulated symbol stream to
detect packets, and we construct a packet data structure from the
complete set of symbols all at once. At that point we could also store
the raw samples of the entire packet, but we haven’t had a need to do
Frankly, I think it is ugly, but it does what I think you want to do.
For years I have had in mind a rewrite using something like the new
stream tags mechanism to do all this in separate blocks that pass time
stamps along with the data streams.