[Discuss-gnuradio] something about forecast()
Hi all:
I want to know something about the forecast().
I have already known that forcast() can tell scheduler how many input
items are required for each output item.
1.But now i have read two example:
The first one:
void your_block::forecast(int
noutput_items,gr_vector_int ninput_items_required){
ninput_items_required[0]=100 *
noutput_items;
ninput_items_required[1]=100 *
noutput_items; }
I have already understand it.
But the second one:
void forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
unsigned ninputs = ninput_items_required.size ();
for (unsigned i = 0; i ninputs; i++)
ninput_items_required[i] = 1;}
I can't understand since we can't know how many input items
we required,why use ninput_items_required.size ().Can someone help me?
2.I want to know if we use the general_work().Is it means that we
must use the forcast()?Thanks.
Best regards
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT Gui FFT resizing Segfault
Hey, I know another GSoC Student has problems with the a GT GUI sink as well. It would randomly SEGFAULT in a volk multiply kernel. I think it is the volk_32_fc_32f_multiply_32fc kernel used in waterfall_sink_X_impl::fft(). This kernel takes the FFT size as an input argument, so it could be related to your problem. I just had a quick glance at it so I am not sure though. I'll ask him to post his exact problem when he arrives at the lab. Maybe he can shed a bit more light on this problem -Jan On 04.06.2014 01:43, Alfredo Muniz wrote: On Tue, Jun 3, 2014 at 4:35 PM, Marcus Müller mar...@hostalia.de mailto:mar...@hostalia.de wrote: I hope someone more familiar with the qtgui infrastructure might chime in. Hey Marcus, Did you try debugging the SEGFAULT using gdb? This is a good reference to try: http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html ___ 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] something about forecast()
Hi Xianda,
Easiest answer first:
2. You need to write a forecast if, and only if, you're using
general_work. I generally try to avoid doing that.
Then:
1.
ninput_items_required is, as you can see in the function signature, a
reference to a vector.
The size of the vector is the number of input ports.
Compare to
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a5bc118d94944d2ff71e378f807fb8d28
Greetings,
Marcus
On 04.06.2014 08:22, xianda wrote:
Hi all:
I want to know something about the forecast().
I have already known that forcast() can tell scheduler how many
input items are required for each output item.
1.But now i have read two example:
The first one:
void your_block::forecast(int
noutput_items,gr_vector_int ninput_items_required){
ninput_items_required[0]=100 *
noutput_items;
ninput_items_required[1]=100 *
noutput_items; }
I have already understand it.
But the second one:
void forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
unsigned ninputs = ninput_items_required.size
();
for (unsigned i = 0; i ninputs; i++)
ninput_items_required[i] = 1;}
I can't understand since we can't know how many input
items we required,why use ninput_items_required.size ().Can someone help me?
2.I want to know if we use the general_work().Is it means that
we must use the forcast()?Thanks.
Best regards
___
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] something about forecast()
On Wed, Jun 4, 2014 at 2:22 PM, xianda wangxianda920...@163.com wrote:
Hi all:
I want to know something about the forecast().
I have already known that forcast() can tell scheduler how many
input items are required for each output item.
1.But now i have read two example:
The first one:
void your_block::forecast(int
noutput_items,gr_vector_int ninput_items_required){
ninput_items_required[0]=100 *
noutput_items;
ninput_items_required[1]=100 *
noutput_items; }
In your first example above, you have exactly two input ports.
That's why you need to specify ninput_items_required[0] and
ninput_items_required[1], there are in total 2 ports.
In fact in this example the value of ninput_items_required.size() is 2.
In alternative, you could also replace above two lines with:
for (unsigned i=0; i 2; i++)
ninput_items_required[i] = 100 * noutput_items;
Or, to be more generic, you could also use this:
for (unsigned i=0; i ninput_items_required.size(); i++)
ninput_items_required[i] = 100 * noutput_items;
2.I want to know if we use the general_work().Is it means that
we must use the forcast()?Thanks.
Best regards
If you use general block, you need to specify forecast().
General block has general_work() function but not general() function.
If you use sync block, decim, interpolation block etc, you have work()
but not general_work(), and you don't need to write forecast().
This is very straight-forward.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT Gui FFT resizing Segfault
Hi! Alfredo: Jep, did that. GDB was how I figured out things went wrong in FreqDisplayForm::setFFTSize() in the first place :). Jörg: Interesting; but the error is quite reproducibly at the same place; I'll try to set a breakpoint at the kernel call and see if that happens again. But that will require some gdb magic (so that GDB only interrupts program flow when the fft size changes), and that's definitively something that would be worthwhile to learn, however I'm postponing this for now for reasons of time available. Greetings, Marcus On 04.06.2014 08:48, Jan Krämer wrote: Hey, I know another GSoC Student has problems with the a GT GUI sink as well. It would randomly SEGFAULT in a volk multiply kernel. I think it is the volk_32_fc_32f_multiply_32fc kernel used in waterfall_sink_X_impl::fft(). This kernel takes the FFT size as an input argument, so it could be related to your problem. I just had a quick glance at it so I am not sure though. I'll ask him to post his exact problem when he arrives at the lab. Maybe he can shed a bit more light on this problem -Jan On 04.06.2014 01:43, Alfredo Muniz wrote: On Tue, Jun 3, 2014 at 4:35 PM, Marcus Müller mar...@hostalia.de mailto:mar...@hostalia.de wrote: I hope someone more familiar with the qtgui infrastructure might chime in. Hey Marcus, Did you try debugging the SEGFAULT using gdb? This is a good reference to try: http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html ___ 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] QT Gui FFT resizing Segfault
I think it's going wrong in getActionFromSize, which easy as it looks[1], I don't get the hang of. Why do we need a specific QAction based on the FFT length we're setting? And why does an FFT size of 4 lead to negative indices in a QList? Anyway, the actual bug was on my side, as I was constantly setting an FFT size of 4. Which seemingly doesn't work. @LD: try callbackset_fft_size(max(int($fftsize),32))/callback instead. I was then able to change the displayed FFT on the fly using QT Gui sliders [2]. Greetings, Marcus [1] gr-qtgui/include/gnuradio/qtgui/form_menus.h [2] https://gist.github.com/marcusmueller/edfef568a92821261f9f , the adjustable_qtgui_fft.grc file should load nicely in a 3.7.4 GNU Radio, I think it should work with 3.7.x On 04.06.2014 09:21, Marcus Müller wrote: Hi! Alfredo: Jep, did that. GDB was how I figured out things went wrong in FreqDisplayForm::setFFTSize() in the first place :). Jörg: Interesting; but the error is quite reproducibly at the same place; I'll try to set a breakpoint at the kernel call and see if that happens again. But that will require some gdb magic (so that GDB only interrupts program flow when the fft size changes), and that's definitively something that would be worthwhile to learn, however I'm postponing this for now for reasons of time available. Greetings, Marcus On 04.06.2014 08:48, Jan Krämer wrote: Hey, I know another GSoC Student has problems with the a GT GUI sink as well. It would randomly SEGFAULT in a volk multiply kernel. I think it is the volk_32_fc_32f_multiply_32fc kernel used in waterfall_sink_X_impl::fft(). This kernel takes the FFT size as an input argument, so it could be related to your problem. I just had a quick glance at it so I am not sure though. I'll ask him to post his exact problem when he arrives at the lab. Maybe he can shed a bit more light on this problem -Jan On 04.06.2014 01:43, Alfredo Muniz wrote: On Tue, Jun 3, 2014 at 4:35 PM, Marcus Müller mar...@hostalia.de mailto:mar...@hostalia.de wrote: I hope someone more familiar with the qtgui infrastructure might chime in. Hey Marcus, Did you try debugging the SEGFAULT using gdb? This is a good reference to try: http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html ___ 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
[Discuss-gnuradio] using uhd_fft with USRP N210
Hi, I'm trying to run uhd_fft with usrp N210, my machine run ubuntu desktop 12.04.4 LTS. When I try to run uhd_fft which is located in /usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps directory, i've got the following message: root@openlab:/usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps# ./uhd_fft Traceback (most recent call last): File ./uhd_fft, line 23, in module from gnuradio import gr, gru ImportError: No module named gnuradio This is the message i've got when installing gnuradio with command: cmake -DENABLE_VOLK=FALSE ../ ## -- # Gnuradio enabled components -- ## -- * python-support -- * testing-support -- -- ## -- # Gnuradio disabled components -- ## -- * volk -- * doxygen -- * sphinx -- * gnuradio-runtime -- * gr-ctrlport -- * gr-blocks -- * gnuradio-companion -- * gr-fec -- * gr-fft -- * gr-filter -- * gr-analog -- * gr-digital -- * gr-atsc -- * gr-audio -- * gr-comedi -- * gr-channels -- * gr-noaa -- * gr-pager -- * gr-qtgui -- * gr-trellis -- * gr-uhd -- * gr-utils -- * gr-video-sdl -- * gr-vocoder -- * gr-fcd -- * gr-wavelet -- * gr-wxgui -- -- Using install prefix: /usr/local -- Building for version: 3.7.2.1 / 3.7.2.1 -- Configuring done -- Generating done -- Build files have been written to: /usr/local/src/gnuradio-3.7.2.1/build Can anyone help to solve this issue Thanks, sammy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] something about forecast()
Hi Xianda,
the io_signature specifies a minimum and a maximum number of inputs, so
this might be 1,2 or 3.
Greetings,
Marcus
On 04.06.2014 10:24, xianda wrote:
Hi:
Thank you so much.
Now i want to ask:if we set
gr::block(c_vcvc,
gr::io_signature::make(1, 3, sizeof(gr_complex)*length1),
gr::io_signature::make(1, 1, sizeof(gr_complex)*length1))
then: ninput_items_required.size ()=1 or 3?
Thanks,
Best regards
At 2014-06-04 03:10:40, Marcus Müller marcus.muel...@ettus.com wrote:
Hi Xianda,
Easiest answer first:
2. You need to write a forecast if, and only if, you're using general_work. I
generally try to avoid doing that.
Then:
1.
ninput_items_required is, as you can see in the function signature, a
reference to a vector.
The size of the vector is the number of input ports.
Compare to
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a5bc118d94944d2ff71e378f807fb8d28
Greetings,
Marcus
On 04.06.2014 08:22, xianda wrote:
Hi all:
I want to know something about the forecast().
I have already known that forcast() can tell scheduler how many
input items are required for each output item.
1.But now i have read two example:
The first one:
void your_block::forecast(int
noutput_items,gr_vector_int ninput_items_required){
ninput_items_required[0]=100 *
noutput_items;
ninput_items_required[1]=100 *
noutput_items; }
I have already understand it.
But the second one:
void forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
unsigned ninputs = ninput_items_required.size
();
for (unsigned i = 0; i ninputs; i++)
ninput_items_required[i] = 1;}
I can't understand since we can't know how many input
items we required,why use ninput_items_required.size ().Can someone help me?
2.I want to know if we use the general_work().Is it means that
we must use the forcast()?Thanks.
Best regards
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orghttps://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] using uhd_fft with USRP N210
Hi Sammy, when building, basically *everything* was not built, so you don't really have GNU Radio installed. This is usually due to missing a crucial dependency of GNU Radio. How did you install? I recommend using pyBOMBs, if you didn't, because that should take care of installing dependencies: http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart Greetings, Marcus On 04.06.2014 10:41, sammy zada wrote: Hi, I'm trying to run uhd_fft with usrp N210, my machine run ubuntu desktop 12.04.4 LTS. When I try to run uhd_fft which is located in /usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps directory, i've got the following message: root@openlab:/usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps# ./uhd_fft Traceback (most recent call last): File ./uhd_fft, line 23, in module from gnuradio import gr, gru ImportError: No module named gnuradio This is the message i've got when installing gnuradio with command: cmake -DENABLE_VOLK=FALSE ../ ## -- # Gnuradio enabled components -- ## -- * python-support -- * testing-support ___ 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] using uhd_fft with USRP N210
Ah, missed that. You should not disable VOLK - almost all of GNU Radio uses that by now. On 04.06.2014 10:41, sammy zada wrote: Hi, I'm trying to run uhd_fft with usrp N210, my machine run ubuntu desktop 12.04.4 LTS. When I try to run uhd_fft which is located in /usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps directory, i've got the following message: root@openlab:/usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps# ./uhd_fft Traceback (most recent call last): File ./uhd_fft, line 23, in module from gnuradio import gr, gru ImportError: No module named gnuradio This is the message i've got when installing gnuradio with command: cmake -DENABLE_VOLK=FALSE ../ ## -- # Gnuradio enabled components -- ## -- * python-support -- * testing-support ___ 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] Fwd: Re: something about forecast()
Original Message
Subject:Re: [Discuss-gnuradio] something about forecast()
Date: Wed, 4 Jun 2014 16:52:11 +0800 (CST)
From: xianda wangxianda920...@163.com
To: Marcus Müller marcus.muel...@ettus.com
Hi:
Thank you.
1.Oh,I understand it.If i say,this is according to how many input
ports we connct to the block.If we connect 2 input ports(connect in python
program),then use the ninput_items_required.size (),it will tell us 2.Right?
2.Another question i want to ask.Thank you.I have check my program as you
saidHowever, you should not do get_tx_stream for every sample chunk you
transmit, but only once for every USRP, before starting to send..But i run my
code,it also display so many L L L.Is the sample to send too short?Thank
you.Any advices will be appreciated.
Best regards,
At 2014-06-04 04:34:11, Marcus Müller marcus.muel...@ettus.com wrote:
Hi Xianda,
the io_signature specifies a minimum and a maximum number of inputs, so
this might be 1,2 or 3.
Greetings,
Marcus
On 04.06.2014 10:24, xianda wrote:
Hi:
Thank you so much.
Now i want to ask:if we set
gr::block(c_vcvc,
gr::io_signature::make(1, 3, sizeof(gr_complex)*length1),
gr::io_signature::make(1, 1, sizeof(gr_complex)*length1))
then: ninput_items_required.size ()=1 or 3?
Thanks,
Best regards
At 2014-06-04 03:10:40, Marcus Müller marcus.muel...@ettus.com wrote:
Hi Xianda,
Easiest answer first:
2. You need to write a forecast if, and only if, you're using general_work.
I generally try to avoid doing that.
Then:
1.
ninput_items_required is, as you can see in the function signature, a
reference to a vector.
The size of the vector is the number of input ports.
Compare to
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a5bc118d94944d2ff71e378f807fb8d28
Greetings,
Marcus
On 04.06.2014 08:22, xianda wrote:
Hi all:
I want to know something about the forecast().
I have already known that forcast() can tell scheduler how many
input items are required for each output item.
1.But now i have read two example:
The first one:
void your_block::forecast(int
noutput_items,gr_vector_int ninput_items_required){
ninput_items_required[0]=100 *
noutput_items;
ninput_items_required[1]=100 *
noutput_items; }
I have already understand it.
But the second one:
void forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
unsigned ninputs = ninput_items_required.size
();
for (unsigned i = 0; i ninputs; i++)
ninput_items_required[i] = 1;}
I can't understand since we can't know how many input
items we required,why use ninput_items_required.size ().Can someone help me?
2.I want to know if we use the general_work().Is it means that
we must use the forcast()?Thanks.
Best regards
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orghttps://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] Fwd: Re: something about forecast()
Hi Xianda, 1.: Yes, that will be the case Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NEWSDR Event This Friday June 6 in Boston
* * Fourth-Annual * * * * New England Workshop on Software-Defined Radio* * NEWSDR 2014 * * * * Friday, 6 June 2014, 8:30 AM - 5:30 PM* * Boston University, Photonics Center, 9th Floor* *Boston, MA, USA* * * * http://www.sdr-boston.org/ * * INVITATION TO PARTICIPATE You are cordially invited to the 2014 New England Workshop on Software Defined Radio (NEWSDR 2014), which is the fourth installment of an annual series of workshops organized by the Boston SDR User Group (SDR-Boston). This year NEWSDR will be held on the 9th Floor of the Photonics Center of Boston University on Friday 6 June 2014. NEWSDR 2014 also features two technical oral presentation sessions, several technical poster presentation sessions, several hardware demonstrations and SDR test-beds, and an industry panel discussion, all focusing on the latest advances in software-defined radio and/or cognitive radio technology. Please forward this message to your colleagues that may be interested in NEWSDR'14. We hope to see you there! KEYNOTE SPEAKER: * Professor Jeffrey Reed, Virginia Tech INVITED SPEAKERS: * Dr. Tom Rondeau, Rondeau Research LLC * Dr. Zoran Zvonar, MediaTek Wireless Inc. SPONSORS: * The MathWorks Inc. * National Instruments / Ettus Research * Analog Devices Inc. * MediaTek Wireless Inc. * Range Networks Inc. * Boston University, Center for Information and Systems Engineering ORAL/POSTER PRESENTATIONS: * Oral and poster presentations are now being solicited * See link at the bottom of this email to submit your abstract online! REGISTRATION: * Free with advanced online pre-registration (lunch and parking included) * Space is limited, so register soon! * See link at the bottom of this email to register online. ADDITIONAL INFORMATION: The latest information of this event can be found at the following website: http://www.sdr-boston.org/ (under Workshops NEWSDR 2014). REGISTRATION LINK: https://docs.google.com/forms/d/14e4GfEDrOaJJ0OLFWwZU4B79aR_Oi2NWkrXETnm1ijY/viewform ORAL/POSTER ABSTRACT SUBMISSION LINK: https://docs.google.com/forms/d/1ScEEjxvik8qh0wnMKydudjnCSJI2UBkNhvKeGWnXuYU/viewform ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission
On Wed, Jun 4, 2014 at 4:59 PM, David Halls david.ha...@toshiba-trel.com wrote: Hi! This shouldn't be the case. But is there any easy way to allow different rates on the two streams, so I could produce more zeros on stream 1 than items on stream 0? Or vice versa? David Please stay on the list. To have different rates on different inputs, [1] http://lists.gnu.org/archive/html/discuss-gnuradio/2014-05/msg00166.html [2] http://gnuradio.4.n7.nabble.com/set-relative-rate-td46167.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission
On Wed, Jun 4, 2014 at 10:52 PM, David Halls david.ha...@toshiba-trel.com wrote: Not quite... i). the Source Tx USRP has a constant stream of data, and is constantly transmitting. If the codewords in the file are exhausted it repeats. ii). the Relay Tx USRP transmits data only when data has been received by the Relay Rx (I will use tx_time to control when the received burst is re-transmitted) iii). the Relay Rx USRP will receive data only when the Source Tx USRP transmits (section where Relay Tx's too will be ignored), What do you mean by section where Relay Tx's too will be ignored ? I have changed the block you suggested, to avoid inserting 0's mid burst. So does this give better results? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission
On Wed, Jun 4, 2014 at 10:52 PM, David Halls david.ha...@toshiba-trel.com wrote: Not quite... i). the Source Tx USRP has a constant stream of data, and is constantly transmitting. If the codewords in the file are exhausted it repeats. ii). the Relay Tx USRP transmits data only when data has been received by the Relay Rx (I will use tx_time to control when the received burst is re-transmitted) iii). the Relay Rx USRP will receive data only when the Source Tx USRP transmits (section where Relay Tx's too will be ignored), To clarify, is it true that both the Source TX USRP and Relay Tx USRP are controlled by the same UHD Sink in the flowgraph? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission
From: Activecat [active...@gmail.com] Sent: 04 June 2014 16:02 To: David Halls Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission On Wed, Jun 4, 2014 at 10:52 PM, David Halls david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote: Not quite... i). the Source Tx USRP has a constant stream of data, and is constantly transmitting. If the codewords in the file are exhausted it repeats. ii). the Relay Tx USRP transmits data only when data has been received by the Relay Rx (I will use tx_time to control when the received burst is re-transmitted) iii). the Relay Rx USRP will receive data only when the Source Tx USRP transmits (section where Relay Tx's too will be ignored), What do you mean by section where Relay Tx's too will be ignored ? I have changed the block you suggested, to avoid inserting 0's mid burst. So does this give better results? 1) this is to avoid loop interference, the Relay Rx will ignore the received signal during the time that the Relay Tx is transmitting. 2) Yes avoiding adding 0's gives me pretty much the performance I require, I need to work on some other parts of the implementation to be sure. (it is definitely not the neatest way yet!!) NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission
From: Activecat [active...@gmail.com] Sent: 04 June 2014 16:13 To: David Halls Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission On Wed, Jun 4, 2014 at 10:52 PM, David Halls david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote: Not quite... i). the Source Tx USRP has a constant stream of data, and is constantly transmitting. If the codewords in the file are exhausted it repeats. ii). the Relay Tx USRP transmits data only when data has been received by the Relay Rx (I will use tx_time to control when the received burst is re-transmitted) iii). the Relay Rx USRP will receive data only when the Source Tx USRP transmits (section where Relay Tx's too will be ignored), To clarify, is it true that both the Source TX USRP and Relay Tx USRP are controlled by the same UHD Sink in the flowgraph? Yes, they are both controlled by the same UHD sink. This ensures, in a simple fashion, that the Source Tx and Relay Tx transmissions have sample-level synchronicity - a must for my Quantize Map and Forward scheme. NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission
On Wed, Jun 4, 2014 at 8:53 PM, David Halls david.ha...@toshiba-trel.com wrote: Hi Activecat, I have disconnected the rest of the flow graph because it is extremely complex. In the system I have a Source, a Relay (1 rx USRP, 1 tx USRP), a Destination. S --- R_rx/R_tx -- D The two transmitters that you see on that flow graph snippet I sent you are the the Source Tx and the Relay Tx. Payload TD Tx 1 is derived from input codewords that are generated in MATLAB and stored in a file, then loaded into the flow graph. The payload is created in a similar fashion to Martin's original OFDM_tx. This is then transmitted from Source Tx. Until this point, no packets are received by Relay Rx but once the source transmits, these packets are then received by Relay Rx, and then there is a decode-and-forward chain of blocks, and this then creates Payload TD Tx 2. The full flow graph is attached, but may be missing many blocks for you... Could you send the source code of the missing blocks to me? I am trying hard to help you out. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission
On Wed, Jun 4, 2014 at 7:10 PM, David Halls david.ha...@toshiba-trel.com wrote: Activecat, In fact my horrible hack doesn't work properly. Once items start arriving at Payload TD Tx 2, they still don't arrive as 'consistently' (for want of a better word), as those from the Noise Source block, and thus zeros are inserted when they are not required! David David, Could you please explain in details, what is this Payload TD Tx 2? How does it generate data, is it getting data from a hardware or console, why it sometime idle but sometime transmitting? This is a virtual source. Where is it associated virtual sink? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tx_time tag accuraccy
I am using stream tags for the transmission control. I want to know what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A with tx_time=X, then the burst A will come out of the USRP transmit FIFO at X+delta, how large the value of delta could be? -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission
On Wed, Jun 4, 2014 at 10:25 PM, David Halls david.ha...@toshiba-trel.com wrote: Yes, there are 3. The Source Tx, the Relay Tx, and the Relay Rx. To clarify, i). the Source Tx USRP may or may not receive data at any time interval. ii). the Relay Tx USRP transmit data only when the Source Tx USRP receive data, and there is a delay due to signal processing iii). the Relay Rx USRP will receive data only when the Relay Tx USRP transmit it, is this correct? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission
Please do not top post. Refer http://gnuradio.org/redmine/projects/gnuradio/wiki/MailingLists#Guidelines-for-posting ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] tx_time tag accuraccy
It will depend some on the effective group delay of both the interpolation filters in the the FPGA and the analog group delay of the analog bits of whatever daughtercard you're using. The only way to be sure is to measure... on Jun 04, 2014, bob wole via USRP-users usrp-us...@lists.ettus.com wrote: I am using stream tags for the transmission control. I want to know what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A with tx_time=X, then the burst A will come out of the USRP transmit FIFO at X+delta, how large the value of delta could be? -- Bob ___USRP-users mailing listusrp-us...@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_time tag accuraccy
Marcus! Thanks for you comment. I think that USRP transmit FIFO is at the start of the DSP chain in FPGA i.e it is prior to both of the interpolation filters? right? I am not talking about when the burst will be over the air, I want to know when the first sample of the burst will leave the transmit FIFO if it has been tagged as tx_time=X. -- Bob On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech mle...@ripnet.com wrote: It will depend some on the effective group delay of both the interpolation filters in the the FPGA and the analog group delay of the analog bits of whatever daughtercard you're using. The only way to be sure is to measure... on Jun 04, 2014, *bob wole via USRP-users* usrp-us...@lists.ettus.com wrote: I am using stream tags for the transmission control. I want to know what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A with tx_time=X, then the burst A will come out of the USRP transmit FIFO at X+delta, how large the value of delta could be? -- Bob -- ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_time tag accuraccy
I don't know the detailed answer, but any such answer will depend very much on which USRP hardware you're talking about. One of the RD people who deals with the FPGA codebase may be able to give a precise answer, given stated hardware. on Jun 04, 2014, bob wole bnw...@gmail.com wrote: Marcus! Thanks for you comment. I think that USRP transmit FIFO is at the start of the DSP chain in FPGA i.e it is prior to both of the interpolation filters? right? I am not talking about when the burst will be over the air, I want to know when the first sample of the burst will leave the transmit FIFO if it has been tagged as tx_time=X. -- Bob On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech mle...@ripnet.com wrote: It will depend some on the effective group delay of both the interpolation filters in the the FPGA and the analog group delay of the analog bits of whatever daughtercard you're using. The only way to be sure is to measure... on Jun 04, 2014, bob wole via USRP-users usrp-us...@lists.ettus.com wrote: I am using stream tags for the transmission control. I want to know what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A with tx_time=X, then the burst A will come out of the USRP transmit FIFO at X+delta, how large the value of delta could be? -- Bob ___USRP-users mailing listusrp-us...@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Call for Volunteers - GNU Radio Website
Hello list! It's been a few weeks since I've been connected/active on the list. After talking things over Tom and others in the community it is apparent that the GNU Radio home site is becoming more critical. Here's some background: Sometime around GR Con 13, it became evident that the GNU Radio community would benefit if we added a customer facing website. While all technical content about installing and using GNU Radio would stay in its current form, this new site would be a place where we could highlight our communities success, post content about conferences/meetups, and just generally give new people a sense of what we're all about. I volunteered to help put this together. But I've been pretty busy for the last 6 months, and to be completely honest *I've just dropped the ball here*. So, I thought it would be best if I asked for help, and maybe found people who are much better at web design than I am! =) We're pretty open to using any platform at this point (Wordpress, straight html, bootstrap, w/e). *Please shoot me a message if you think you help, and I'll include you on a group discussion sometime next week.* I can be reached at my personal address for the time being: jmalsbury.perso...@gmail.com. -John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)
Hello, I am trying to get samples from a B200 at 50 Msps into GNU Radio. The UHD benchmark_rate tool receives at 50 Msps without any overflows detected. My GNU Radio flowgraph is simply a USRP source connected to a null sink, and I'm still getting overflows. I've tried expanding the min_output_buffer for the USRP source, but that doesn't seem to help. I really don't know what is causing the problem. Any suggestions about what I should try? Thank you, Orin Lincoln ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)
On 06/04/2014 05:16 PM, Orin Lincoln wrote: Hello, I am trying to get samples from a B200 at 50 Msps into GNU Radio. The UHD benchmark_rate tool receives at 50 Msps without any overflows detected. My GNU Radio flowgraph is simply a USRP source connected to a null sink, and I'm still getting overflows. I've tried expanding the min_output_buffer for the USRP source, but that doesn't seem to help. I really don't know what is causing the problem. Any suggestions about what I should try? Thank you, Orin Lincoln ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio What is causing the problem is that your computer/OS simply cannot keep up. Gnu Radio has noticeably more overhead than a hand-crafted program like benchmark_rate. Being able to maintain real-time streaming at these rates is *challenging*, and just because benchmark_rate doesn't fall over, is *zero* guarantee that some *other* program, trying to swallow data at a similar rate, will actually be able to. Desktop/Server operating systems (Windows, OSX, Linux, *BSD) aren't really optimized for dealing with high-bandwidth real-time flows. In any given system configuration, it's rather a crap-shoot as to whether your system will be able to keep up or not. What type of computer do you have? What OS? How much memory? Is it the fastest memory you can use on your motherboard? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)
On Wed, Jun 4, 2014 at 5:16 PM, Orin Lincoln orindlinc...@gatech.edu wrote: I am trying to get samples from a B200 at 50 Msps into GNU Radio. The UHD benchmark_rate tool receives at 50 Msps without any overflows detected. My GNU Radio flowgraph is simply a USRP source connected to a null sink, and I'm still getting overflows. I've tried expanding the min_output_buffer for the USRP source, but that doesn't seem to help. I really don't know what is causing the problem. Any suggestions about what I should try? In addition to what Marcus said, if your application allows, you can try 8-bit samples to relieve some pressure on the USB bus. -TT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)
On 6/4/2014 2:16 PM, Orin Lincoln wrote: Hello, I am trying to get samples from a B200 at 50 Msps into GNU Radio. The UHD benchmark_rate tool receives at 50 Msps without any overflows detected. My GNU Radio flowgraph is simply a USRP source connected to a null sink, and I'm still getting overflows. I've tried expanding the min_output_buffer for the USRP source, but that doesn't seem to help. I really don't know what is causing the problem. Any suggestions about what I should try? Thank you, Orin Lincoln On bladeRF, the number of USB3.0 buffers makes a big difference in the maximum sample rate without overruns. On the B200, you can try the same thing by increasing the number of buffers in the device_addr arguments. device_addr=recv_frame_size=65536,num_recv_frames=128, Ron ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] signal level
Hi, In GRC is it necessary that we give a signal to any sink having an amplitude greater than 1? Regards, Ali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] signal level
Hi Ali - some sinks care about the amplitude, and others do not. For example, the instruments built into gnuradio (Scope, Frequency display, etc.) can examine a signal of almost any amplitude within floating-point range because you can adjust the display scale factor. However other sinks, such as a physical transmitter (USRP, HPSDR, etc.) are constrained in the amplitude that they can accept. Normally this must be less than one, and hitting or exceeding 1.00 (even just on the peak) can cause problems. Also a physical transmitter might have only 12 or 16 bits fixed point dynamic range, so there may be a minimum signal amplitude as well. -- Tom, N5EG On Wed, Jun 4, 2014 at 7:33 PM, jason sam user0...@gmail.com wrote: Hi, In GRC is it necessary that we give a signal to any sink having an amplitude greater than 1? Regards, Ali ___ 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] signal level
Hi Tom, Can you tell what is the constraint for USRP B210? On Thu, Jun 5, 2014 at 8:13 AM, Tom McDermott tom.n...@gmail.com wrote: Hi Ali - some sinks care about the amplitude, and others do not. For example, the instruments built into gnuradio (Scope, Frequency display, etc.) can examine a signal of almost any amplitude within floating-point range because you can adjust the display scale factor. However other sinks, such as a physical transmitter (USRP, HPSDR, etc.) are constrained in the amplitude that they can accept. Normally this must be less than one, and hitting or exceeding 1.00 (even just on the peak) can cause problems. Also a physical transmitter might have only 12 or 16 bits fixed point dynamic range, so there may be a minimum signal amplitude as well. -- Tom, N5EG On Wed, Jun 4, 2014 at 7:33 PM, jason sam user0...@gmail.com wrote: Hi, In GRC is it necessary that we give a signal to any sink having an amplitude greater than 1? Regards, Ali ___ 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] Doxygen documentation
How can i configure GNU Radio Companion 3.7.3 with Doxygen so taht i can view the blocks' documentation from inside GRC?I have Doxygen installed but its not configured with GRC. Regards, Ali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNu radio examples not running
Hi All, When i try to run any of built in examples (in .py form) with GRC,i get the following error: Error: /usr/local/share/gnuradio/examples/audio/audio_fft.py:1:1:FATAL:PARSER:ERR_DOCUMENT_EMPTY: Start tag expected, '' not found An example of such file is as attached. #!/usr/bin/python #!/usr/bin/env python # # Copyright 2004,2005,2007 Free Software Foundation, Inc. # # This file is part of GNU Radio # # GNU Radio is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 3, or (at your option) # any later version. # # GNU Radio is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with GNU Radio; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 51 Franklin Street, # Boston, MA 02110-1301, USA. # from gnuradio import gr, gru, audio from gnuradio import eng_notation from gnuradio.eng_option import eng_option from gnuradio.wxgui import stdgui2, fftsink2, waterfallsink2, scopesink2, form, slider from optparse import OptionParser import wx import sys class app_top_block(stdgui2.std_top_block): def __init__(self, frame, panel, vbox, argv): stdgui2.std_top_block.__init__(self, frame, panel, vbox, argv) self.frame = frame self.panel = panel parser = OptionParser(option_class=eng_option) parser.add_option(-W, --waterfall, action=store_true, default=False, help=Enable waterfall display) parser.add_option(-S, --oscilloscope, action=store_true, default=False, help=Enable oscilloscope display) parser.add_option(-I, --audio-input, type=string, default=, help=pcm input device name. E.g., hw:0,0 or /dev/dsp) parser.add_option(-r, --sample-rate, type=eng_float, default=48000, help=set sample rate to RATE (48000)) (options, args) = parser.parse_args() sample_rate = int(options.sample_rate) if len(args) != 0: parser.print_help() sys.exit(1) self.show_debug_info = True # build the graph if options.waterfall: self.scope = \ waterfallsink2.waterfall_sink_f (panel, fft_size=1024, sample_rate=sample_rate) elif options.oscilloscope: self.scope = scopesink2.scope_sink_f(panel, sample_rate=sample_rate) else: self.scope = fftsink2.fft_sink_f (panel, fft_size=1024, sample_rate=sample_rate, fft_rate=30, ref_scale=1.0, ref_level=0, y_divs=12) self.src = audio.source (sample_rate, options.audio_input) self.connect(self.src, self.scope) self._build_gui(vbox) # set initial values def _set_status_msg(self, msg): self.frame.GetStatusBar().SetStatusText(msg, 0) def _build_gui(self, vbox): def _form_set_freq(kv): return self.set_freq(kv['freq']) vbox.Add(self.scope.win, 10, wx.EXPAND) #self._build_subpanel(vbox) def _build_subpanel(self, vbox_arg): # build a secondary information panel (sometimes hidden) # FIXME figure out how to have this be a subpanel that is always # created, but has its visibility controlled by foo.Show(True/False) def _form_set_decim(kv): return self.set_decim(kv['decim']) if not(self.show_debug_info): return panel = self.panel vbox = vbox_arg myform = self.myform #panel = wx.Panel(self.panel, -1) #vbox = wx.BoxSizer(wx.VERTICAL) hbox = wx.BoxSizer(wx.HORIZONTAL) hbox.Add((5,0), 0) myform['decim'] = form.int_field( parent=panel, sizer=hbox, label=Decim, callback=myform.check_input_and_call(_form_set_decim, self._set_status_msg)) hbox.Add((5,0), 1) myform['fs@usb'] = form.static_float_field( parent=panel, sizer=hbox, label=Fs@USB) hbox.Add((5,0), 1) myform['dbname'] = form.static_text_field( parent=panel, sizer=hbox) hbox.Add((5,0), 1) myform['baseband'] = form.static_float_field( parent=panel, sizer=hbox, label=Analog BB) hbox.Add((5,0), 1) myform['ddc'] = form.static_float_field( parent=panel, sizer=hbox, label=DDC) hbox.Add((5,0), 0) vbox.Add(hbox, 0, wx.EXPAND) def main (): app = stdgui2.stdapp(app_top_block, Audio FFT, nstatus=1) app.MainLoop() if __name__ == '__main__': main () ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org
