Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 152, Issue 12

[Chen Chen]

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 <address@hidden>:

Send Discuss-gnuradio mailing list submissions to
        address@hidden

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
        address@hidden

You can reach the person managing the list at
        address@hidden

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 <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Precise interrupts in GNURADIO?
Message-ID:
        <address@hidden>
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 <address@hidden>:

> 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:address@hidden or address@hidden
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 <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Precise interrupts in GNURADIO?
Message-ID: <address@hidden>
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 <address@hidden
> <mailto:address@hidden>>:
>
>     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:address@hidden <mailto:address@hidden> or
> address@hidden <mailto:address@hidden>
> Address: KEB 2238, Kim Bldg
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> 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
address@hidden
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:address@hidden or address@hidden

Address: KEB 2238, Kim Bldg