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

[Lukas Haase]

Hi Johannes,

Thanks.
It's not exactly a TDD system but I assume in terms of timing similar, yes.
In a TDD system I am most concerned that transmitted data is perfectly timed. 
In my case, I need both, transmitted data and received data to be perfectly 
time aligned with each other.
Think of my system more like RADAR: I send a pulse which is reflected and 
receive the response. There is a static delay (USRP, cables, ...) that I want 
to calibrate and a dynamic phase shift that I want to obtain.

I think I use timed transmissions already? :

I use set_start_time in both USRP Source & Sink so in general the data I 
receive from USRP is perfectly aligned with the data that I transmit (up to a 
constant delay). While this constant delay is constant over operation, it is 
not constant over multiple power cycles and hence I have a block for 
calibration. Currently it's super manual and just a QT Time Sink block where I 
view the transmitted and received signal on the same screen. From there I can 
easily read off the delay and insert a "Skip Samples" block on the received 
data and have both perfectly aligned.

Again, this works well but is not reliable because I put the transmitted and 
received data into the same block (QT Time Sink), causing the USRP be inside a 
gnuradio loop. Since I know what I am transmitting, I could just clone the 
block that generates the transmitted signal but the output of both blocks must 
be identical.

I also need to clarify: The system is just so much more complicated and I tried 
hard to break it to the essentials. The output of the Msg2Tag block are only 
zeros because I am only interested in the tags! Before I send it into the USRP 
there is another block that inserts data into the stream based on these tags 
(which are precicely sample time controlled as opposed to messages).

Can you elaborate what you mean by timed transmission?

Thanks,
Lukas




> Date: Wed, 26 Aug 2020 13:21:17 +0200
> From: Johannes Demel <demel@ant.uni-bremen.de>
> To: discuss-gnuradio@gnu.org
> Subject: Re: Messages into two blocks: Message order & timing
>       guaranteed?
> Message-ID: <232d2415-75f3-338c-8fb4-cf58f3ef5b37@ant.uni-bremen.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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.
> >
> >
> >
> >