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: http://sourceforge.net/projects/gr-bluetooth/develop 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 so. 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. mossmann _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
