# Save all the samples of a packet (all complex values) and demodulate at once. (Is it possible?) **URL:** \ **Category:** GNU Radio\ **Created:** [March 2, 2011, 1:02pm UTC](https://www.ruby-forum.com/t/save-all-the-samples-of-a-packet-all-complex-values-and-demodulate-at-once-is-it-possible/203955 "2011-03-02T13:02:13Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\ **Post date:** [March 2, 2011, 1:02pm UTC](https://www.ruby-forum.com/t/save-all-the-samples-of-a-packet-all-complex-values-and-demodulate-at-once-is-it-possible/203955/1 "2011-03-02T13:02:13Z")
Dear all, We’re using benchmark\_tx(rx) apps to implement a simple cellular-like network. In the benchmark\_rx example, the demodulator demodulates some amount of symbols at a time and the correlator and the framer, which followed the demodulator, read the demodulated bits and packetize them into a frame. But, for some reasons, we want to change the way the receiver decodes a packet. 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. However, we haven’t implemented or seen this kind of receiver structure in gnuradio. If you have seen or any experience with similar examples, please let us know. Any comment on it would be very appreciated. Thanks in advance. PS. we’re using USRP1 / gnuradio 3.3.0 / Ubuntu 10.04 ---
**Author:** ![Minsuk\_Kang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/dfb087/32.png) [@Minsuk\_Kang](https://www.ruby-forum.com/u/Minsuk_Kang)\ **Post date:** [March 2, 2011, 3:03pm UTC](https://www.ruby-forum.com/t/save-all-the-samples-of-a-packet-all-complex-values-and-demodulate-at-once-is-it-possible/203955/2 "2011-03-02T15:03:55Z")
On Wed, Mar 2, 2011 at 6:00 AM, Minsuk Kang [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > However, we haven’t implemented or seen this kind of receiver structure in > gnuradio. > If you have seen orany experience withsimilar examples, please let us > know. > Any comment on it would be veryappreciated. > Thanks in advance. > PS. we’re using USRP1 / gnuradio 3.3.0 / Ubuntu 10.04 The main issue with this is “what is a packet”. In the benchmark scripts there is a defined start and end of the packet, namely, correlation sequence at the beginning, and the n\_bytes field. To save the demodulated samples into packets would not do you any good, as you have no idea where packets begin and end. You could just save fixed size blocks using the packetizer, but then your real packets would be split between your saved blocks at random. If what you are trying to do is really the best way to go about it, you would still need to demodulate at least /some/ of the bits (probably just the header) so you would know when to a packet starts, then packetize the raw stream starting at that point. Jason ---
**Author:** ![Minsuk\_Kang](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/dfb087/32.png) [@Minsuk\_Kang](https://www.ruby-forum.com/u/Minsuk_Kang)\ **Post date:** [March 2, 2011, 6:16pm UTC](https://www.ruby-forum.com/t/save-all-the-samples-of-a-packet-all-complex-values-and-demodulate-at-once-is-it-possible/203955/3 "2011-03-02T18:16:05Z")
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](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