Is there any way in GRC to send a finite pulse?

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…

transmission by manually forcing the flow graph to abruptly end.
datafile from being populated by a continuous data stream.


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
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.