Hi, everyone, Is there any way in GRC to stop sending a signal? For example, I attach a snapshot of a simple GRC flowgraph with a 250 Hz cosine signal source outputting floats into an audio sink, and also into a file sink called "test.dat". Everything works fine and I see the output, and I can graph the file with a simple python script. But the problem is that after some time I have to stop the transmission by manually forcing the flow graph to abruptly end. Is there any way in GRC to automatically stop the signal after some time, say a finite pulse? I don't want to send a continuous signal, but I want it to stop, say, after ten periods. Now some of you (e.g., Josh) have pointed me to a way of using Python or C++ to maybe tag the last sample with an EOB metadata, and I will try this when I need to do something in Python or C++, but I don't understand how it would change anything in this particular flow graph. I mean, just coloring the last sample with an EOB tag won't stop the datafile from being populated by a continuous data stream. I guess I don't understand why it should be so hard just using GRC to stop sending a signal after some time., or maybe it's easy, and I just don't get it. I know there is a burst tagger object in GRC that someone once mentioned in this group, but it was used to feed into the USRP, and I assume that the USRP knew somehow to stop reception? I guess I am confused, and need some kind of help in understanding this. :-(. Thanks for any insights....
on 2013-01-31 01:09
on 2013-01-31 01:27
> transmission by manually forcing the flow graph to abruptly end. > datafile from being populated by a continuous data stream. > > > _______________________________________________ > Discuss-gnuradio mailing list > Discussfirstname.lastname@example.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio You can use the "head" block to allow your flow-graph to run for a certain amount of time and stop. One of the problems with GRC is that it isn't, really, an imperative, procedurally-oriented programming environment. It's a flow-based environment, and you have to kind of stand on your head to do "procedural" things with it. Probes, for example, can be used to call arbitrary python code at regular intervals. This can sometimes help you "fake up" a procedural environment using state machines and the return values from your python code.