Thank you all every much on the ideas. I appreciate it. I have initially
thought about using UDP in the similar manner you suggested and I guess I
will start with that one first and probably try other methods if that
doesnt work.
By the way, I was not clear about "continuous" mode of operation.
Ap
That sounds very feasible!
But, again, if all that happens is actually a hardware source
overflowing, and dropping a single let's say 200 sample packets, this
might be hard to detect externally if "Keep 1 in N" has an N > 200 or
so to reliably detect a single missed packet, and that might mean you
Thanks for the Throttle insights :)
If there's a hardware source in the flowgraph, maybe he can leverage the
source's clock, and use source -> Keep 1 in N -> sink?
Or write a custom UDP sink that connects directly to the source, and
implements some kind of "Send 1 for every N items" internally?
O
Be a bit careful there, Throttle doesn't work like that!
Throttle will sleep for as long as it takes to pass the number of input
items it sees.
For example, if you connected
Constant Source(1) -> Throttle (1 S/s) -> UDP Sink
Then, on start of the flow graph, "constant source" will produce e.g.
Might work for you:
Any kind of source, throttled to 1/HEARTBIT_INTERVAL, to a UDP sink.
Example:
Constant Source(1) -> Throttle (1 S/s) -> UDP Sink
will write the number 1 to the designated UDP sink, once every second.
On Sun, Apr 1, 2018 at 12:22 AM Milos Milosavljevic <
milos.milosavlje...@spi
Hi All,
I was wondering if someone can give me some hints on the below please.
I have a flowgraph running continuously demodulating some off air signals
and spitting out meta data about the parameters, calculated SNRs, BER, freq
offset estimations, etc. That meta and output data is parsed regular
