discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: Reliable "virtual RF channel" between two grc applications (UDP Sour


From: Lukas Haase
Subject: Re: Reliable "virtual RF channel" between two grc applications (UDP Source/Sink?)
Date: Mon, 4 May 2020 23:43:53 +0200

Hi,

A quick followup on the ZMQ PULL/PUSH:

> Derek Kozel wrote:
> > For an example of that check out the Simulation tutorial.
> > https://wiki.gnuradio.org/index.php/Simulation_example:_AM_transmitter_and_receiver
> 
> On 22/04/2020 19:08, Marcus Müller wrote:
> > Use zeromq; that should do just fine, and if the default TCP transport 
> > feels like too much overhead,
> > you can try the ipc:// transport, iirc.
> 
> Thank you, sounds promising. ZMQ PULL Source + ZMQ PUSH Sink with IPC works 
> well at first glance.
> 
> First to make sure (since there is this hint generated): A Throttle block 
> after the ZMQ PULL Source
> is still a good idea right?
> 
> PS: Can the UDP Source/Sink be regarded as deprecated wrt ZMQ or is there a 
> different reason they exist?

I would still be interested in these two. But additionally, is there anything I 
need to take care regarding timing synchronization? Can it be that these 
sources/link result in data loss on start/end, causing random time offsets?



I have "Flowgraph 1" which I start in the background and looks like:

                        ,------------.
  ZMQ Pull Source 1 --> |            | --> ZMQ Push Sink 1
                        | Processing |
  ZMQ Pull Source 2 --> |            | --> ZMQ Push Sink 2
                        `------------'

The "Processing" block models basically a channel (simply speaking) and mixes 
both.

The model of my Transceiver is "Flowgraph 2" and looks similar to:

  Signal Source 1 --> ZMQ Push Sink 1
  Signal Source 2 --> ZMQ Push Sink 2
     ZMQ Push Source 1 --> Receiver
     ZMQ Push Source 2 --> Receiver

>From this is is clear:
1.) If "Flowgraph 2" is started but not "Flowgraph 1", everything is stuck 
because nothing is received from the ZMQ Push Sources in "Flowgraph 2".
2.) "Flowgraph 1" can always be started in the background. Whenever data comes 
in via the ZMQ Pull Sources, it goes through the processing block and spits out 
data on the ZMQ Push Sinks

While this is working I realized weird behavior which I ended up tracing down 
to the fact that the samples "Flowgraph 1" receives via the two ZMQ Pull 
Sources are out of sync *if* "Flowgraph 2" is restarted. On a coldstart 
everything works as predicted. With out of sync I mean that the effective 
sample times are offset (probably either of the streams looses samples).

I could fix this by using vectors instead of streams and having just one ZMQ 
Push/Pull per flowgraph.

However, I would still be interested what is the issue because down the line I 
might have multiple flowgraphs interacting together via ZMQ.
Then I need to ensure that every ZMQ Source spits out exactly the same amount 
of samples and every ZMQ Sink takes exactly the same amount of samples.


Even with now, with just one ZMQ Source/Sink per flowgraph, I get unpredictable 
time offsets when I restart "Flowgraph 2" (while keeping "Flowgraph 1" running 
in the background).


Any insights are much appreciated.

best,
Luke







reply via email to

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