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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
