Re: [Discuss-gnuradio] forecast and general work function
As mentioned, the stream-to-message-passing gr-eventstream approach is right for you. Best regards, Marcus On 10/29/2015 01:47 PM, s.subrata...@gmail.com wrote: > Thank you Marcus. I am trying to simulate a network with 2 transmitters and > one receiver. The TX's transmit streams at random times and the RX receives > the sum of the signals from both the TX's. The adder block however doesn't > give any output when one of its input stream is empty (i.e. when both the > inputs are not available at the same time) . That's why I'm trying to create > an intermediate block for each TX that takes in an input and outputs zeros if > the input is empty. This way the adder block would always have something to > add. Thanks. > > Subrata > >> On Oct 28, 2015, at 17:36, Marcus Müller wrote: >> >> Hi Subrata, >> >> while what you plan to do is possible if you build a block with a >> general_work method and a forecast. In fact, here the forecast >> implementation will probably be pretty crucial, but also be pretty >> simple -- just always require the same amount of samples from input0 as >> you're asked to produce output, and don't require anything from input1. >> >> However, I'm pretty certain GNU Radio won't schedule your block as you >> want to (in fact, I just wrote a minimal test case to verify[1]). >> >> My general recommendation would be to write a minimal block that takes a >> stream and converts it to messages, and passes those to >> gr-eventstream[2]. gr-eventstream has blocks to do exactly that: produce >> a zero-signal when there's no (message) input, produce the content of >> the message input otherwise; you could just take that output and add it >> to your input1, and be done :) >> >> Best regards, >> Marcus >> >> >> [1] https://github.com/marcusmueller/gr-demo_assymetric_input clone, and >> run ./qa_prioritizer.py in the python/ folder >> [2] http://oshearesearch.com/tag/gr-eventstream/ >>> On 28.10.2015 21:26, s.subrata...@gmail.com wrote: >>> I am trying to create a block that has two input and one output. Its like a >>> priority multiplexer; if input0 is empty then output = input1 else output = >>> input0 ( input0 always has samples) its a stream based block. >>> How do I declare the work function, because the number of samples needed >>> from each input to produce noutput_items depends on whether input0 is >>> empty. >>> Any help in the general work function is also greatly appreciated. >>> >>> Thanks >>> ___ >>> 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and general work function
Thank you Marcus. I am trying to simulate a network with 2 transmitters and one receiver. The TX's transmit streams at random times and the RX receives the sum of the signals from both the TX's. The adder block however doesn't give any output when one of its input stream is empty (i.e. when both the inputs are not available at the same time) . That's why I'm trying to create an intermediate block for each TX that takes in an input and outputs zeros if the input is empty. This way the adder block would always have something to add. Thanks. Subrata > On Oct 28, 2015, at 17:36, Marcus Müller wrote: > > Hi Subrata, > > while what you plan to do is possible if you build a block with a > general_work method and a forecast. In fact, here the forecast > implementation will probably be pretty crucial, but also be pretty > simple -- just always require the same amount of samples from input0 as > you're asked to produce output, and don't require anything from input1. > > However, I'm pretty certain GNU Radio won't schedule your block as you > want to (in fact, I just wrote a minimal test case to verify[1]). > > My general recommendation would be to write a minimal block that takes a > stream and converts it to messages, and passes those to > gr-eventstream[2]. gr-eventstream has blocks to do exactly that: produce > a zero-signal when there's no (message) input, produce the content of > the message input otherwise; you could just take that output and add it > to your input1, and be done :) > > Best regards, > Marcus > > > [1] https://github.com/marcusmueller/gr-demo_assymetric_input clone, and > run ./qa_prioritizer.py in the python/ folder > [2] http://oshearesearch.com/tag/gr-eventstream/ >> On 28.10.2015 21:26, s.subrata...@gmail.com wrote: >> I am trying to create a block that has two input and one output. Its like a >> priority multiplexer; if input0 is empty then output = input1 else output = >> input0 ( input0 always has samples) its a stream based block. >> How do I declare the work function, because the number of samples needed >> from each input to produce noutput_items depends on whether input0 is empty. >> Any help in the general work function is also greatly appreciated. >> >> Thanks >> ___ >> 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and general work function
Hi Subrata, while what you plan to do is possible if you build a block with a general_work method and a forecast. In fact, here the forecast implementation will probably be pretty crucial, but also be pretty simple -- just always require the same amount of samples from input0 as you're asked to produce output, and don't require anything from input1. However, I'm pretty certain GNU Radio won't schedule your block as you want to (in fact, I just wrote a minimal test case to verify[1]). My general recommendation would be to write a minimal block that takes a stream and converts it to messages, and passes those to gr-eventstream[2]. gr-eventstream has blocks to do exactly that: produce a zero-signal when there's no (message) input, produce the content of the message input otherwise; you could just take that output and add it to your input1, and be done :) Best regards, Marcus [1] https://github.com/marcusmueller/gr-demo_assymetric_input clone, and run ./qa_prioritizer.py in the python/ folder [2] http://oshearesearch.com/tag/gr-eventstream/ On 28.10.2015 21:26, s.subrata...@gmail.com wrote: > I am trying to create a block that has two input and one output. Its like a > priority multiplexer; if input0 is empty then output = input1 else output = > input0 ( input0 always has samples) its a stream based block. > How do I declare the work function, because the number of samples needed from > each input to produce noutput_items depends on whether input0 is empty. > Any help in the general work function is also greatly appreciated. > > Thanks > ___ > 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
[Discuss-gnuradio] forecast and general work function
I am trying to create a block that has two input and one output. Its like a priority multiplexer; if input0 is empty then output = input1 else output = input0 ( input0 always has samples) its a stream based block. How do I declare the work function, because the number of samples needed from each input to produce noutput_items depends on whether input0 is empty. Any help in the general work function is also greatly appreciated. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast in infinite loop
On 30.09.2015 16:16, Jared Dulmage wrote: > Ubuntu 14.04, GR 3.7.8 > > I apologize if this question is a duplicate, I never received a confirmation of my original request in the mailing list digest. I appreciate any insights or advice to diagnose the issue presented below. Hey Jared, I replied to your original email; can you please go back to that thread. In general, if you're participating in discussions, I recommend not subscribing to the digest. Cheers, M > > From a high level, I am trying to create a block that acts like a gate, i.e. in the locked state, the block passes all inputs to the output; in the unlocked state the block consumes its input and provides no output. The state depends on a count of consecutive events (misses) where the block's state changes to locked (unlocked) when a threshold is met. Events are marked by stream tags on the input at a regular interval. So there is no a priori known relationship between input and output. I've seen this thread which I believe is related: > > https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00039.html > > > but I can't seem to determine a solution from that discussion. My block is called frame_sync_c and is a python block. > > My test flowgraph looks like > > vector_source_c -> throttle -> frame_sync_c -> null_sink > > The vector source has tags placed periodically with a gap in the tag sequence. The block behaves completely as expected for a number of lock/unlock cycles and then devolves into an infinite loop of forecast calls without calling general_work. Below is a sample log that shows the forecast calls, noutput_items and nitems_read(0) in each general_work call and consume calls. > > Consume calls are prefixed by the current block state, Locked or Unlocked. "Consume & produce X" means the block called self.consume(0,X) and also returned X. "Consume X" means self.consume(0,X) was called and 0 was returned (i.e. no output was produced). The block generally consumes up to a state transition and then relies on another call to general_work to continue processing with the new state. Interestingly, the block seems to devolve after around 3000 samples regardless of the vector_source_c data size, tag period, or other parameters related to the input stream. > > gr::debug :INFO: frame_sync_c0 - Forecast 4096 > gr::debug :INFO: frame_sync_c0 - Forecast 2048 > gr::debug :INFO: frame_sync_c0 - Forecast 1024 > gr::debug :INFO: frame_sync_c0 - Forecast 512 > gr::debug :INFO: frame_sync_c0 - Forecast 256 > gr::debug :INFO: frame_sync_c0 - Forecast 128 > gr::debug :INFO: frame_sync_c0 - Forecast 64 > gr::debug :INFO: frame_sync_c0 - Forecast 32 > gr::debug :INFO: frame_sync_c0 - Forecast 16 > gr::debug :INFO: frame_sync_c0 - Forecast 8 > gr::debug :INFO: frame_sync_c0 - Forecast 4 > gr::debug :INFO: frame_sync_c0 - Forecast 2 > gr::debug :INFO: frame_sync_c0 - Forecast 1 > gr::debug :INFO: frame_sync_c0 - Forecast 4096 > gr::debug :DEBUG: frame_sync_c0 - noutput_items = 4096, nitems_read(0) = 0, > key_tags @ 10, 110, 210, 310, 410, 510, 610, 710 > gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 410 > gr::debug :INFO: frame_sync_c0 - Forecast 4096 > gr::debug :INFO: frame_sync_c0 - Forecast 2048 > gr::debug :DEBUG: frame_sync_c0 - noutput_items = 2048, nitems_read(0) = 410, > key_tags @ 410, 510, 610, 710 > gr::debug :DEBUG: frame_sync_c0 - Locked: Consume & produce 600 > gr::debug :INFO: frame_sync_c0 - Forecast 4096 > gr::debug :INFO: frame_sync_c0 - Forecast 2048 > gr::debug :DEBUG: frame_sync_c0 - noutput_items = 2048, nitems_read(0) = > 1010, key_tags @ > gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 2048 > gr::debug :INFO: frame_sync_c0 - Forecast 4096 > gr::debug :INFO: frame_sync_c0 - Forecast 2048 > gr::debug :INFO: frame_sync_c0 - Forecast 1024 > gr::debug :DEBUG: frame_sync_c0 - noutput_items = 1024, nitems_read(0) = > 3058, key_tags @ > gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 1024 > gr::debug :INFO: frame_sync_c0 - Forecast 4096 > gr::debug :INFO: frame_sync_c0 - Forecast 2048 > gr::debug :INFO: frame_sync_c0 - Forecast 1024 > gr::debug :INFO: frame_sync_c0 - Forecast 512 > gr::debug :INFO: frame_sync_c0 - Forecast 256 > gr::debug :INFO: frame_sync_c0 - Forecast 128 > gr::debug :INFO: frame_sync_c0 - Forecast 64 > gr::debug :INFO: frame_sync_c0 - Forecast 32 > gr::debug :INFO: frame_sync_c0 - Forecast 16 > gr::debug :INFO: frame_sync_c0 - Forecast 8 > gr::debug :DEBUG: frame_sync_c0 - noutput_items = 8, nitems_read(0) = 4082, > key_tags @ > gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 8 > gr::debug :INFO: frame_sync_c0 - Forecast 4096 > gr::debug :INFO: frame_sync_c0 - Forecast 2048 > gr::debug :INFO: frame_sync_c0 - Forecast 1024 > gr::debug :INFO: frame_sync_c0 - Forecast 512 > gr::debug :INFO: frame_sync_c0 - Forecast 256 > gr::debug :INFO: frame_sync_c0 - Forecast 128 > gr::debug :INFO: frame_sync_c0 - Forecast 64 > gr::debug :INFO: frame_sync_c0 - Forecast 32 > gr::debug :INFO: fram
[Discuss-gnuradio] forecast in infinite loop
Ubuntu 14.04, GR 3.7.8 I apologize if this question is a duplicate, I never received a confirmation of my original request in the mailing list digest. I appreciate any insights or advice to diagnose the issue presented below. >From a high level, I am trying to create a block that acts like a gate, i.e. >in the locked state, the block passes all inputs to the output; in the >unlocked state the block consumes its input and provides no output. The state >depends on a count of consecutive events (misses) where the block's state >changes to locked (unlocked) when a threshold is met. Events are marked by >stream tags on the input at a regular interval. So there is no a priori known >relationship between input and output. I've seen this thread which I believe >is related: https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00039.html but I can't seem to determine a solution from that discussion. My block is called frame_sync_c and is a python block. My test flowgraph looks like vector_source_c -> throttle -> frame_sync_c -> null_sink The vector source has tags placed periodically with a gap in the tag sequence. The block behaves completely as expected for a number of lock/unlock cycles and then devolves into an infinite loop of forecast calls without calling general_work. Below is a sample log that shows the forecast calls, noutput_items and nitems_read(0) in each general_work call and consume calls. Consume calls are prefixed by the current block state, Locked or Unlocked. "Consume & produce X" means the block called self.consume(0,X) and also returned X. "Consume X" means self.consume(0,X) was called and 0 was returned (i.e. no output was produced). The block generally consumes up to a state transition and then relies on another call to general_work to continue processing with the new state. Interestingly, the block seems to devolve after around 3000 samples regardless of the vector_source_c data size, tag period, or other parameters related to the input stream. gr::debug :INFO: frame_sync_c0 - Forecast 4096 gr::debug :INFO: frame_sync_c0 - Forecast 2048 gr::debug :INFO: frame_sync_c0 - Forecast 1024 gr::debug :INFO: frame_sync_c0 - Forecast 512 gr::debug :INFO: frame_sync_c0 - Forecast 256 gr::debug :INFO: frame_sync_c0 - Forecast 128 gr::debug :INFO: frame_sync_c0 - Forecast 64 gr::debug :INFO: frame_sync_c0 - Forecast 32 gr::debug :INFO: frame_sync_c0 - Forecast 16 gr::debug :INFO: frame_sync_c0 - Forecast 8 gr::debug :INFO: frame_sync_c0 - Forecast 4 gr::debug :INFO: frame_sync_c0 - Forecast 2 gr::debug :INFO: frame_sync_c0 - Forecast 1 gr::debug :INFO: frame_sync_c0 - Forecast 4096 gr::debug :DEBUG: frame_sync_c0 - noutput_items = 4096, nitems_read(0) = 0, key_tags @ 10, 110, 210, 310, 410, 510, 610, 710 gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 410 gr::debug :INFO: frame_sync_c0 - Forecast 4096 gr::debug :INFO: frame_sync_c0 - Forecast 2048 gr::debug :DEBUG: frame_sync_c0 - noutput_items = 2048, nitems_read(0) = 410, key_tags @ 410, 510, 610, 710 gr::debug :DEBUG: frame_sync_c0 - Locked: Consume & produce 600 gr::debug :INFO: frame_sync_c0 - Forecast 4096 gr::debug :INFO: frame_sync_c0 - Forecast 2048 gr::debug :DEBUG: frame_sync_c0 - noutput_items = 2048, nitems_read(0) = 1010, key_tags @ gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 2048 gr::debug :INFO: frame_sync_c0 - Forecast 4096 gr::debug :INFO: frame_sync_c0 - Forecast 2048 gr::debug :INFO: frame_sync_c0 - Forecast 1024 gr::debug :DEBUG: frame_sync_c0 - noutput_items = 1024, nitems_read(0) = 3058, key_tags @ gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 1024 gr::debug :INFO: frame_sync_c0 - Forecast 4096 gr::debug :INFO: frame_sync_c0 - Forecast 2048 gr::debug :INFO: frame_sync_c0 - Forecast 1024 gr::debug :INFO: frame_sync_c0 - Forecast 512 gr::debug :INFO: frame_sync_c0 - Forecast 256 gr::debug :INFO: frame_sync_c0 - Forecast 128 gr::debug :INFO: frame_sync_c0 - Forecast 64 gr::debug :INFO: frame_sync_c0 - Forecast 32 gr::debug :INFO: frame_sync_c0 - Forecast 16 gr::debug :INFO: frame_sync_c0 - Forecast 8 gr::debug :DEBUG: frame_sync_c0 - noutput_items = 8, nitems_read(0) = 4082, key_tags @ gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 8 gr::debug :INFO: frame_sync_c0 - Forecast 4096 gr::debug :INFO: frame_sync_c0 - Forecast 2048 gr::debug :INFO: frame_sync_c0 - Forecast 1024 gr::debug :INFO: frame_sync_c0 - Forecast 512 gr::debug :INFO: frame_sync_c0 - Forecast 256 gr::debug :INFO: frame_sync_c0 - Forecast 128 gr::debug :INFO: frame_sync_c0 - Forecast 64 gr::debug :INFO: frame_sync_c0 - Forecast 32 gr::debug :INFO: frame_sync_c0 - Forecast 16 gr::debug :INFO: frame_sync_c0 - Forecast 8 gr::debug :INFO: frame_sync_c0 - Forecast 4 gr::debug :DEBUG: frame_sync_c0 - noutput_items = 4, nitems_read(0) = 4090, key_tags @ gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 4 gr::debug :INFO: frame_sync_c0 - Forecast 4096 gr::debug :INFO: frame_sync_c0 - Foreca
Re: [Discuss-gnuradio] forecast
Hi Miklos, yes, a forecast might be different for different situations. Greetings, Marcus On 02/16/2014 07:12 PM, Miklos Maroti wrote: Hi Guys, If a block keeps some internal state, can the forecast method return different values for the same number of noutput_items depending on its internal state? Will the forecast method be called before the flow graph is started? Miklos ___ 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
[Discuss-gnuradio] forecast
Hi Guys, If a block keeps some internal state, can the forecast method return different values for the same number of noutput_items depending on its internal state? Will the forecast method be called before the flow graph is started? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
i got a new problem.. when i am working with signals, i converted them to vectors using stream to vectors, then the vectors are given as input to my block (since my block has an input as vectors of fixed length) , then processing is done on the vector, output is also a vector .. but the problem is that there is delay in processing the each vector.. and i declared my i/o signature as follows: i/p signature sizeof(float)*vec_len o/p signature sizeof(float)*vec_len when is plot the output, it is not exactly delay because some unwanted plot is occurring and again my ouput is being plotted... i can post my code if u need it... thanks ... -- View this message in context: http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327p44601.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
thanks , and i have created the block ,which is working fine (but it is slow for signals of larger size) -- View this message in context: http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327p44381.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
On Wed, Oct 23, 2013 at 1:33 PM, Bharat Mukkala wrote: > its true that setting the history to length of coefficients work, but when we > go for more than 1 level of decomposition, the output from previous level > will be used , so how can is use the output again ? Seems to me like you'll need to keep that state inside the object. > i have another doubt , if we set the size of each element in the input > signature to be 4*sizeof(float) and size of each output element to be > 4*sizeof(float) in a gr::sync_block, then in the work function , how each > element will be handled, (is it like 4 input items of size float), also > please tell me how to use them. > thank you Look at some of the other blocks where a vector length is specified. gr-blocks/lib/float_to_short_impl.cc might be a good one to look at. The vlen used here means that each item is of size vlen times the size of a float (on the input stream). If vlen=4, each item is composed of 4 floats. So if 'float *in = (float*)input_items[0]', then it has a length of ninput_items[0]*4. You can index the array from 0 to (ninput_items[0]*4 - 1). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
its true that setting the history to length of coefficients work, but when we go for more than 1 level of decomposition, the output from previous level will be used , so how can is use the output again ? i have another doubt , if we set the size of each element in the input signature to be 4*sizeof(float) and size of each output element to be 4*sizeof(float) in a gr::sync_block, then in the work function , how each element will be handled, (is it like 4 input items of size float), also please tell me how to use them. thank you -- View this message in context: http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327p44342.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
On Wed, Oct 23, 2013 at 7:47 AM, Martin Braun (CEL) wrote: > On Wed, Oct 23, 2013 at 03:23:36AM -0700, Bharat Mukkala wrote: >> the i/o ratio is 1 since the number of input items is same the number of >> output items, but while processing we use the whole signal but not a single >> element while calculating the output elements, i have doubt in figuring out >> how to tell that to gnuradio,my idea is that, can i set_output_multiple to >> ninput_items_required and then do processing. >> thank you > > You can only set_output_multiple before work starts, usually in the > constructor. So you set_output_multiple such that you can process the > entire signal at once, and make your block a gr::sync_block. > > MB Bharat, Have you looked at the wavelet_ff block in gr-wavelet? It might do what you want already or is at least close. Also, since a wavelet is very much like a decimating fir filter, I'm not sure output_multiple is the right thing to do. I think setting the history for the length of the wavelet coefficients should be adequate. Check out my overview of the scheduler for some details on what history does: http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
On Wed, Oct 23, 2013 at 03:23:36AM -0700, Bharat Mukkala wrote: > the i/o ratio is 1 since the number of input items is same the number of > output items, but while processing we use the whole signal but not a single > element while calculating the output elements, i have doubt in figuring out > how to tell that to gnuradio,my idea is that, can i set_output_multiple to > ninput_items_required and then do processing. > thank you You can only set_output_multiple before work starts, usually in the constructor. So you set_output_multiple such that you can process the entire signal at once, and make your block a gr::sync_block. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpfEcty018h_.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
the i/o ratio is 1 since the number of input items is same the number of output items, but while processing we use the whole signal but not a single element while calculating the output elements, i have doubt in figuring out how to tell that to gnuradio,my idea is that, can i set_output_multiple to ninput_items_required and then do processing. thank you -- View this message in context: http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327p44330.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
On Tue, Oct 22, 2013 at 11:10:54PM -0700, Bharat Mukkala wrote: > I am creating a new gnu radio block for decomposing the signal using haar > wavelet decompostion and includes the option of number of levels of > decompostion. > In order to write the code, how should i set the set_history or forecast > function because in order to produce output the input signal should be > processed as a whole rather than in chunks. This seems to be a case of set_output_multiple() rather than forecast() (the i/o ratio is still a constant, right?). MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpvYo1vEOCGy.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] forecast and set history function for haar decomposition
I am creating a new gnu radio block for decomposing the signal using haar wavelet decompostion and includes the option of number of levels of decompostion. In order to write the code, how should i set the set_history or forecast function because in order to produce output the input signal should be processed as a whole rather than in chunks. -- View this message in context: http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast method for HDLC transmit block
On Thu, Oct 23, 2008 at 05:52:18PM -0400, Ed Criscuolo wrote: > Eric Blossom wrote: >> On Thu, Oct 23, 2008 at 04:56:04PM -0400, Ed Criscuolo wrote: > > >>> At this point, I think I'll embed all the packet reading AND >>> hdlc processing into a single source block with no flow >>> inputs. This way the block can check for packets on the TUN >>> device, read them, bitstuff and hdlc frame them, and put them >>> into an internal ring buffer. Then it would return as many bits >>> as requested, or flags if the ring buffer was empty. >> >> OK. The only problem that I can see with this is that the scheduler >> will run this block whenever there is space available in the >> downstream buffer. If your data rate is low (100's of b/s) we could >> be adding a serious amount of latency to the system. If this is a >> deep space probe, no problem :-) otherwise we may need to cookup some >> way to limit the amount of buffer used between the blocks. The >> default is ~32KB. If the data rate is relatively high, the 32KB of >> buffering may not be an issue. >> > > It's not deep space, just LEO (Low Earth Orbit), so speed-of-light > latency is only on the order of 5 - 30 mS. > > This flow will be feeding the uplink, which runs at 9600 bits/sec. > Not that low, but not very high either. OK > My initial plan, was to have the block output an unpacked stream > of bits, one per byte. Now, if I'm understanding you correctly, > the scheduler will request as much as 32KB of output from this > hdlc source block at one time. At one bit/byte, and 9600 bits/sec, > that amounts to just over 3 seconds worth of data. If my ring > buffer just happens to be empty, this means I'm going to insert > 3 seconds worth of flags into the stream at once, even if I have > a packet come along in the next millisecond. This would cause > me to fall behind, never to catch up. The overall effect would > be to reduce my effective data rate to something less than 9600. > Seems like I should be checking for newly arrived packets after > sending each flag, not just once per invocation of the work method. > But this sounds like a lot of extra processing overhead. Is it > possible for a block to return less than the number of outputs > requested? (I think the answer is yes for a block, no for a sync > block). You can return less. In any event, the scheduler will call you again if there's still room in the output buffer. > Would that be a better way to limit the amount of data output at once? I think the right answer is to come up with a way to limit the total buffer space you see. My suggestion is to not worry about it right now, get the rest of it working, then we can fix this problem. It shouldn't be a big deal. (I just spent a couple of minutes looking at it. It won't be hard to limit the buffer space seen. We just need to come up with a reasonable API for it.) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast method for HDLC transmit block
Eric Blossom wrote: On Thu, Oct 23, 2008 at 04:56:04PM -0400, Ed Criscuolo wrote: > At this point, I think I'll embed all the packet reading AND hdlc processing into a single source block with no flow inputs. This way the block can check for packets on the TUN device, read them, bitstuff and hdlc frame them, and put them into an internal ring buffer. Then it would return as many bits as requested, or flags if the ring buffer was empty. OK. The only problem that I can see with this is that the scheduler will run this block whenever there is space available in the downstream buffer. If your data rate is low (100's of b/s) we could be adding a serious amount of latency to the system. If this is a deep space probe, no problem :-) otherwise we may need to cookup some way to limit the amount of buffer used between the blocks. The default is ~32KB. If the data rate is relatively high, the 32KB of buffering may not be an issue. It's not deep space, just LEO (Low Earth Orbit), so speed-of-light latency is only on the order of 5 - 30 mS. This flow will be feeding the uplink, which runs at 9600 bits/sec. Not that low, but not very high either. My initial plan, was to have the block output an unpacked stream of bits, one per byte. Now, if I'm understanding you correctly, the scheduler will request as much as 32KB of output from this hdlc source block at one time. At one bit/byte, and 9600 bits/sec, that amounts to just over 3 seconds worth of data. If my ring buffer just happens to be empty, this means I'm going to insert 3 seconds worth of flags into the stream at once, even if I have a packet come along in the next millisecond. This would cause me to fall behind, never to catch up. The overall effect would be to reduce my effective data rate to something less than 9600. Seems like I should be checking for newly arrived packets after sending each flag, not just once per invocation of the work method. But this sounds like a lot of extra processing overhead. Is it possible for a block to return less than the number of outputs requested? (I think the answer is yes for a block, no for a sync block). Would that be a better way to limit the amount of data output at once? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast method for HDLC transmit block
On Thu, Oct 23, 2008 at 04:56:04PM -0400, Ed Criscuolo wrote: > Eric Blossom wrote: >> >> Ed, >> >> The problem is that you need to know when the output is about to >> underrun, and only then insert flags. >> >> Is there any external reference clock or other way to tell when the >> external stream needs data? In general, GR has no tie to an external >> timebase, except indirectly through sinks or sources that consume data >> at a fixed rate (e.g., USRP, audio card, etc). If there is some way >> to tell when the external world is ready for more data, we can solve >> this problem. > > The data stream needs to be at a fixed rate. I was planning to add > a throttle block to insure this. You definitely don't want to use a throttle block for this purpose. It's only reason for existence is so that file driven GUI test code doesn't suck down all the CPU available. >> Is the USRP the final sink for the modulated bits? >> > > Yes, after it's upsampled and modulated, the USRP is the final sink. Good. > I realize that this should pace things, but I figured the throttle > block would be a good idea in that it would allow me to test > without a USRP hooked up, just a spectrum display. I strongly suggest not using the throttle block. Definitely don't use it if the USRP is in the graph. There should be only a single clock in the system. > At this point, I think I'll embed all the packet reading AND > hdlc processing into a single source block with no flow > inputs. This way the block can check for packets on the TUN > device, read them, bitstuff and hdlc frame them, and put them > into an internal ring buffer. Then it would return as many bits > as requested, or flags if the ring buffer was empty. OK. The only problem that I can see with this is that the scheduler will run this block whenever there is space available in the downstream buffer. If your data rate is low (100's of b/s) we could be adding a serious amount of latency to the system. If this is a deep space probe, no problem :-) otherwise we may need to cookup some way to limit the amount of buffer used between the blocks. The default is ~32KB. If the data rate is relatively high, the 32KB of buffering may not be an issue. > I'm assuming that the scheduler would keep asking for enough bits > from this source block to keep the flow going at the throttled rate. > (assuming I have enough CPU power to keep up). Yes. > Does this approach sound like it will work? Yes. Let us know how it works out! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast method for HDLC transmit block
Eric Blossom wrote: Ed, The problem is that you need to know when the output is about to underrun, and only then insert flags. Is there any external reference clock or other way to tell when the external stream needs data? In general, GR has no tie to an external timebase, except indirectly through sinks or sources that consume data at a fixed rate (e.g., USRP, audio card, etc). If there is some way to tell when the external world is ready for more data, we can solve this problem. The data stream needs to be at a fixed rate. I was planning to add a throttle block to insure this. Is the USRP the final sink for the modulated bits? Yes, after it's upsampled and modulated, the USRP is the final sink. I realize that this should pace things, but I figured the throttle block would be a good idea in that it would allow me to test without a USRP hooked up, just a spectrum display. At this point, I think I'll embed all the packet reading AND hdlc processing into a single source block with no flow inputs. This way the block can check for packets on the TUN device, read them, bitstuff and hdlc frame them, and put them into an internal ring buffer. Then it would return as many bits as requested, or flags if the ring buffer was empty. I'm assuming that the scheduler would keep asking for enough bits from this source block to keep the flow going at the throttled rate. (assuming I have enough CPU power to keep up). Does this approach sound like it will work? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast method for HDLC transmit block
On Tue, Oct 21, 2008 at 11:01:51AM -0400, Ed Criscuolo wrote: > I'm building a set of blocks to implement the HDLC link-layer > functions for a spacecraft communication system. > These blocks deal with IP packets from/to the stack on one side, > and a bitstream to/from the modulator/demodulator on the other side. > > The receive block is already done and working. It takes a bitstream > from the demodulator, finds the frame, un-bitstuffs it, extracts the > IP packet payload and shoves it into the network stack. But I've run > into a snag doing the transmit part. > > HDLC is a synchronous serial protocol. It has to keep clocking bits > out at a fixed rate no matter what. When there are no packets to > transmit, it outputs "flag" bytes (0x7E) continuously until there is > more packet data to transmit. > > The problem is that this makes the output independent of the input. > I'm struggling with how to implement a forecast method to deal > with this. The "how-to-write-a-block" tutorial states that complex > forecast methods are possible, but gives no examples. I've gone > through the code of many forecast implementations, but all of them > seem to be simple decimators (N:1) or interpolators (1:N). > > I need something more complicated. When there is a packet of "N" > bytes ready on the input, the number of output bits produced will > be : > > ( Bytes x 8 x Bitstuffing_factor ) + header_size + crc_size > > but when there's NO packet data ready on the input, the number > of output bits produced will simply be 8 (one flag byte). > > Is this sort of forecast method possible? Where can I find > some code examples of complicated forecast functions, or a > more detailed description of the use of the forecast method? > > Or am I overthinking this, and the simple answer is to set > ninput_items_required to Zero, since I always have something > to output? Ed, The problem is that you need to know when the output is about to underrun, and only then insert flags. Is there any external reference clock or other way to tell when the external stream needs data? In general, GR has no tie to an external timebase, except indirectly through sinks or sources that consume data at a fixed rate (e.g., USRP, audio card, etc). If there is some way to tell when the external world is ready for more data, we can solve this problem. Is the USRP the final sink for the modulated bits? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] forecast method for HDLC transmit block
I'm building a set of blocks to implement the HDLC link-layer functions for a spacecraft communication system. These blocks deal with IP packets from/to the stack on one side, and a bitstream to/from the modulator/demodulator on the other side. The receive block is already done and working. It takes a bitstream from the demodulator, finds the frame, un-bitstuffs it, extracts the IP packet payload and shoves it into the network stack. But I've run into a snag doing the transmit part. HDLC is a synchronous serial protocol. It has to keep clocking bits out at a fixed rate no matter what. When there are no packets to transmit, it outputs "flag" bytes (0x7E) continuously until there is more packet data to transmit. The problem is that this makes the output independent of the input. I'm struggling with how to implement a forecast method to deal with this. The "how-to-write-a-block" tutorial states that complex forecast methods are possible, but gives no examples. I've gone through the code of many forecast implementations, but all of them seem to be simple decimators (N:1) or interpolators (1:N). I need something more complicated. When there is a packet of "N" bytes ready on the input, the number of output bits produced will be : ( Bytes x 8 x Bitstuffing_factor ) + header_size + crc_size but when there's NO packet data ready on the input, the number of output bits produced will simply be 8 (one flag byte). Is this sort of forecast method possible? Where can I find some code examples of complicated forecast functions, or a more detailed description of the use of the forecast method? Or am I overthinking this, and the simple answer is to set ninput_items_required to Zero, since I always have something to output? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
