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) <muel...@kit.edu> > 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 > > > v...@spire.com> 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 > > > > Discuss-gnuradio@gnu.org > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > _______________________________________________ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
