discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Messages into two blocks: Message order & timing guaranteed?


From: Johannes Demel
Subject: Re: Messages into two blocks: Message order & timing guaranteed?
Date: Wed, 26 Aug 2020 13:21:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Hi Lukas,

I'd suggest you use timed transmissions with your USRP. I assume you want to build a TDD system. In that case, it would be advisable to avoid transmitting `0`s. One more reason to use timed transmissions.

I assume your align block is some kind of synchronization. I suggest to sync your RX stream first and then use your messages to align your stream.

Your 2 Msg2Tag blocks will probably deviate sometimes since they run in separate threads.

Cheers
Johannes

On 25.08.20 18:35, Lukas Haase wrote:
Hi,

I have a block that generates messages (may be very fast, in the ms range or 
below).

At some point I need to convert these into precise, repeatable timing, so I have a 
"Msg2Tag" block. It takes messages at the input and outputs a sample stream of zeros with 
the messages as tags. However, since I need repeatable and precice timing, that block has a 
parameter "period" and it would insert a tag only every period-th sample.

+---------+  Msg    +---------+
| Message +-------->+ Msg2Tag |-----> Stream with 0s, tag every period-th sample
+---------+         +---------+

Now I want to copy this "Message to Tag" block and feed it with the same 
message source.


+---------+  Msg    +---------+
| Message +---+---->+ Msg2Tag |-----> Stream with tags #1
+---------+   |     +---------+
               |
               |     +---------+
               `---->+ Msg2Tag |-----> Stream with tags #2
                     +---------+

*** Will both output sequences (and tags) be guaranteed to be identical?


*** Why am I doing this? I have a system with a query and response (think of an RFID reader 
for example) based on USRP. The query/response time is short (>1ms). I need to perfectly 
time-align the USRP response with the USRP query. Right now I only have one "Message to 
Tag" block which I use as global timing control: I feed this signal not only into the 
USRP Sink but also in a block that properly aligns the response from USRP Source:


+---------+  Msg    +---------+      +-----------+
| Message +-------->+ Msg2Tag |-+--->+ USRP Sink |
+---------+         +---------+ |    +-----------+
                                 |
                                 |    +---------+
                                `--->+         |
                                      | Align   |-----> Further
                                  ,-->+         |       processing
                                /    +---------+
                                 |
              +-------------+    |
              + USRP Source |----'
              +-------------+

(Note that I am omitting blocks and details for the sake of clarity).

However, a configuration in which the USRP is "in the loop" seems to be 
extremely unreliable [*].
Since I can perfectly reproduce the signal that goes into the USRP Sink, I 
could just clone the block; I would not need to use the same output stream of 
the Msg2Tag block.
However, for reproducible results, the clone must be guaranteed to be an 
identical copy.


I am afraid that with two Msg2Tag blocks, the result will not be guaranteed the 
same. Which options do I have for my setup? I do want to use messages initially 
because it makes high-level protocol stuff much easier.

Thanks,
Lukas


PS: I heard about gr-eventstream but want to avoid it if possible.

[*] While this setup seems to be working for some parameters (such as inserting huge 
delay blocks and changing min output buffer of Msg2Tag block, this generally seems to be 
unreliable and at some point the USRP reports a late packets. I think this is because now 
the "Align" block dictates the sample flow. It might let Msg2Tag buffer lots of 
samples at the output while reading in samples from USRP Source. During this time, the 
USRP clock proceeds. Once the samples in the buffer are sent to the USRP, they are late 
and the system breaks.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]