Re: [Discuss-gnuradio] Flowgraph heartbeat pulse

[CEL]

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
need to transport many samples! 

Best regards,
Marcus

On Sun, 2018-04-01 at 11:31 +0000, Gilad Beeri (ApolloShield) wrote:
> 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?
> 
> On Sun, Apr 1, 2018 at 2:16 PM Müller, Marcus (CEL) <address@hidden>
> wrote:
> > 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.
> > 4096 items, and then Throttle's work will be called with these 4096
> > items. Throttle then calculates #input_items/sample_rate = 4096s
> > and
> > sleep, for more than an hour, then signal it's finished copying
> > thes
> > 4096 items to the output. This is everything but a usable watchdog!
> > 
> > Frankly, I know (very, very well) that GNU Radio isn't bug-free.
> > But if your flow graph occasionally breaks, then you need to fix
> > that,
> > and not only try to figure out when that happens. This is
> > especially
> > hard in GNU Radio, since all blocks run in different threads, and a
> > disjunkt watchdog subgraph might just as well continue running
> > after
> > your main graph has ceased to function.
> > 
> > I interpret your "sometimes values are missing" as "but then it
> > continues working normally afterwards". I'm certain that means your
> > flow graph is *not* crashing, because then it wouldn't continue
> > working
> > normally after. What might happen is that some step or external
> > factor
> > needs to much resources of your computer, and then the real time
> > processing of your input data (wherever that comes from!) can't be
> > sustained, leading to your external data source (SDR device?)
> > having to
> >  drop samples. But then you'll need to debug your computation and
> > computational system to make it sufficienly reliable at not
> > consuming
> > more time to do whatever you do to the signal than it takes to
> > produce
> > the signal!
> > 
> > Vitals are still a good idea, but sadly, I don't have a standard
> > way of
> > doing them.
> > 
> > Best regards,
> > Marcus
> > 
> > On Sun, 2018-04-01 at 04:20 +0000, Gilad Beeri (ApolloShield)
> > wrote:
> > > 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
> > > address@hidden> wrote:
> > > > 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 regularly and saved to a database.
> > > >
> > > > However, sometimes it is either meta missing or data or both. I
> > am
> > > > convinced that the flowgraph either stalls or crashes. I need
> > to
> > > > capture it where exactly but first I want to develop a tool to
> > > > monitor the flowgraph to now when it crashed or hanged.
> > > >
> > > > So I want to add a hearbeat somewhere which I can monitor and
> > know
> > > > exactly that it is not running anymore. Does anybody have any
> > ideas
> > > > of what would be the best way to do it? Can I use something
> > from
> > > > the library for this?
> > > >
> > > > Any suggestions will be appreciated.
> > > >
> > > > Many thanks,
> > > > Milos
> > > >
> > > > _______________________________________________
> > > > Discuss-gnuradio mailing list
> > > > address@hidden
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature