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. Apologies. I have an automated system which starts the flowgraph at specific times, runs it for a few minutes (15-20mins) and shuts it down. So when there is no data at the output I believe that the flowgraph is launched but it either stalls or crashes (for whatever reason). The source of data is actually USRP so there is hardware involved in the system. I also know whether it is launched or it failed to launch and I monitor the CPU utilisation during this time. I havent received any alerts on the CPU but I agree I wouldnt discard the possibility that the computing power could be the issue. As a result it becomes a bit hard to know where it crashes (which by the way I am still not 100% certain that it actually does) so thats why I thought I should start with some vitals first. I am also thinking of doing the core dump somehow to check for any segfaults etc but not sure yet how useful that will be (unless I build the gnuradio in debug mode). Thank you all again. Best Regards Milos On 1 April 2018 at 13:27, Müller, Marcus (CEL) <muel...@kit.edu> wrote: > 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 > -- *Dr. Milos Milosavljevic* Communications DSP/FPGA Engineer *Spire Global UK Limited* Unit 5A, Sky Park 5, 45 Finnieston Street, Glasgow, G3 8JU United Kingdom *+44 (0)1413 439 <+44%207881%20295658>146* *+44 (0)7954 161 6 <+44%207881%20295658>79*
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
