Hi Marcus,
My old application targets at getting 50 data packages for a single
carrier frequency and then terminate the graph (I just don't know how to
get the 30 seconds alarm to work, so forget about it).
The new application targets at the following feature:
Frequency hopping in sequence in a given set of center frequencies. On
each frequency, I want to get 50 packages.
The method I use is:
*******************************************
for x in xrange(0,nom):
cur_freq=tb.min_freq+x*stepsize
tb.set_freq(cur_freq)
*******************************************
where nom is the number of measurements. By invoking set_freq, I could
change the center frequency at both the TX and RX sides with no problem at
all.
If I use the method of 'WORK_DONE' after a block sees 50 decoded
packages, then the for loop would stuck since it is already terminated by
'WORK_DONE', and cannot proceed further into the next center frequency.
Say, cur_freq stuck at 5.0GHz since 'WORK_DONE' is invoked somewhere, and
there is no way to restart the graph.
Speaking of the frequency hopping, the output is connected to a meta
file sink. After frequency hopping, there is only one single file,
containing data from all frequencies. To tell these data apart, I passed
the rx_freq tag from the usrp source at receiver side. Is it a good way in
practice?
Thanks!
2015-07-12 12:00 GMT-04:00 <[email protected]>:
> Send Discuss-gnuradio mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
> 1. Re: Precise interrupts in GNURADIO? (Chen Chen)
> 2. Re: Precise interrupts in GNURADIO? (Marcus M?ller)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 11 Jul 2015 17:53:26 -0400
> From: Chen Chen <[email protected]>
> To: [email protected]
> Subject: Re: [Discuss-gnuradio] Precise interrupts in GNURADIO?
> Message-ID:
> <
> caldu+9zp8uogctqdwwrxwp3bkw_nlbkwzskhznp1tzgag2h...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello all,
> I am wondering, after the WORK_DONE is invoked, is it possible to
> restart the flowgraph? Thanks!
>
> 2015-02-09 17:11 GMT-05:00 Chen Chen <[email protected]>:
>
> > Dear all,
> > In my application, I want to implement the following feature:
> > 1. If I decode 50 packages, then stop the flowgraph immediately
> > 2. otherwise, if after 30 seconds, I cannot receive more than 50
> > packages, then stop the flowgraph. So I could prevent the flowgraph from
> > locking forever.
> >
> > For the first part, I add a state machine inside the decoder. When
> > there are 50 packages decoded correctly, I would output a high level '1'
> on
> > the output. Otherwise I output low level 0. I connect this output port,
> > with a probe. In python, I wrote
> > -------------------------------------------------------------
> > def _probe_peak_package_number():
> > while True:
> > val = round(self.probe_package_number.level())
> > if (val == 1):
> > print "package number reach threshold %d!"
> > %self.threshold
> > self.stop()
> > break
> > _probe_package_number_thread =
> > threading.Thread(target=_probe_peak_package_number)
> > _probe_package_number_thread.daemon = True
> > _probe_package_number_thread.start()
> > -------------------------------------------------------------
> > which starts a thread, listening to the probe. Whenever it observes a
> high
> > level '1', it would STOP the flowgraph immediately.
> >
> > For the second part, I am using the Timer in the package threading.
> > -------------------------------------------------------------
> > #def _shut_down_flow_graph():
> > #print "Passing %d seconds, going to kill the process!"
> > %self.timing
> > #self.stop()
> >
> > #_timer_thread=Timer(self.timing,_shut_down_flow_graph)
> > #_timer_thread.start()
> > -------------------------------------------------------------
> >
> > But, what I observe is that:
> > 1. If I set the threshold to 10 packages, I have to wait until about 100
> > packages being decoded correctly. Sometimes I have to wait for about 500
> > packages. The threading is not very stable, even there is an high-level
> > output at the probe, it does not 'see' it immediately.
> >
> > 2. The alarm would prevent my flowgraph from exiting. Namely, when there
> > are more than 50 packages, the flowgraph would not be stopped, until 30
> > seconds passed. But I have a self.stop() in the snippet.
> >
> > if (val == 1):
> > print "package number reach threshold %d!"
> > %self.threshold
> > self.stop()
> > break
> >
> > Why it does not terminate the python program immediately?
> >
> > Or, is there any suggestions on implementing precise interrupt in
> GNURADIO?
> >
> > Thanks.
> > --
> > CHEN CHEN
> >
> >
>
>
> --
> CHEN CHEN
> Electrical and Computer Engineering
> University of Maryland, College Park
> E-mail:[email protected] or [email protected]
> Address: KEB 2238, Kim Bldg
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150711/295c421f/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sun, 12 Jul 2015 15:55:21 +0200
> From: Marcus M?ller <[email protected]>
> To: [email protected]
> Subject: Re: [Discuss-gnuradio] Precise interrupts in GNURADIO?
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Hi Chen Chen,
>
> After the first block's work returns WORK_DONE, the rest of the buffers
> is processed, and the flow graph is stopped.
> In principle, you can restart that flow graph, but generally, that's not
> a good idea -- stopping the flow graph usually brings blocks into a
> state where continuing to work is impossible. For example, the file sink
> closes the file.
>
> So the general answer is: No, that's not possible. I thought your
> application dictated that you're completely finished after 50 packets
> (or 30s)?
>
> Best regards,
> Marcus
>
> On 11.07.2015 23:53, Chen Chen wrote:
> > Hello all,
> > I am wondering, after the WORK_DONE is invoked, is it
> > possible to restart the flowgraph? Thanks!
> >
> > 2015-02-09 17:11 GMT-05:00 Chen Chen <[email protected]
> > <mailto:[email protected]>>:
> >
> > Dear all,
> > In my application, I want to implement the following feature:
> > 1. If I decode 50 packages, then stop the flowgraph immediately
> > 2. otherwise, if after 30 seconds, I cannot receive more
> > than 50 packages, then stop the flowgraph. So I could prevent the
> > flowgraph from locking forever.
> > For the first part, I add a state machine inside the
> > decoder. When there are 50 packages decoded correctly, I would
> > output a high level '1' on the output. Otherwise I output low
> > level 0. I connect this output port, with a probe. In python, I wrote
> > -------------------------------------------------------------
> > def _probe_peak_package_number():
> > while True:
> > val = round(self.probe_package_number.level())
> > if (val == 1):
> > print "package number reach threshold %d!"
> > %self.threshold
> > self.stop()
> > break
> > _probe_package_number_thread =
> > threading.Thread(target=_probe_peak_package_number)
> > _probe_package_number_thread.daemon = True
> > _probe_package_number_thread.start()
> > -------------------------------------------------------------
> > which starts a thread, listening to the probe. Whenever it
> > observes a high level '1', it would STOP the flowgraph immediately.
> >
> > For the second part, I am using the Timer in the package threading.
> > -------------------------------------------------------------
> > #def _shut_down_flow_graph():
> > #print "Passing %d seconds, going to kill the
> > process!" %self.timing
> > #self.stop()
> >
> > #_timer_thread=Timer(self.timing,_shut_down_flow_graph)
> > #_timer_thread.start()
> > -------------------------------------------------------------
> >
> > But, what I observe is that:
> > 1. If I set the threshold to 10 packages, I have to wait until
> > about 100 packages being decoded correctly. Sometimes I have to
> > wait for about 500 packages. The threading is not very stable,
> > even there is an high-level output at the probe, it does not 'see'
> > it immediately.
> >
> > 2. The alarm would prevent my flowgraph from exiting. Namely, when
> > there are more than 50 packages, the flowgraph would not be
> > stopped, until 30 seconds passed. But I have a self.stop() in the
> > snippet.
> >
> > if (val == 1):
> > print "package number reach threshold %d!"
> > %self.threshold
> > self.stop()
> > break
> >
> > Why it does not terminate the python program immediately?
> >
> > Or, is there any suggestions on implementing precise interrupt in
> > GNURADIO?
> >
> > Thanks.
> > --
> > CHEN CHEN
> >
> >
> >
> >
> > --
> > CHEN CHEN
> > Electrical and Computer Engineering
> > University of Maryland, College Park
> > E-mail:[email protected] <mailto:e-mail%[email protected]> or
> > [email protected] <mailto:[email protected]>
> > Address: KEB 2238, Kim Bldg
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > [email protected]
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150712/a2b21e6f/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> End of Discuss-gnuradio Digest, Vol 152, Issue 12
> *************************************************
>
--
CHEN CHEN
Electrical and Computer Engineering
University of Maryland, College Park
E-mail:[email protected] or [email protected]
Address: KEB 2238, Kim Bldg
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
