Re: [Discuss-gnuradio] Decimation Rate with a fraction part

[Alexander Chemeris]

Hi Nick,

You could use USRP1 plus our ClockTamer to get exact sampling rate right
from the USRP without fractional resampling. You could find more information
on the GnuRadio wiki and at ClockTamer google-code site

--
Regards,
Alexander Chemeris

On 3 Mar 2011 23:06, "Nick Othieno"  wrote:

Hi all,

I would like to get an output of 16.3676 Ms/s. Is it then possible to set a
decimation values of 6.109631223? I am wondering whether decimation values
have to be whole numbers, or whether decimation values with fraction parts
are allowed.

The reason for this is that I am trying to mimic the behaviour of the SiGe
GPS sampler which has a sampling rate of 16.3676 Ms/s. Anyone who has used
the USRP(2) to collect signals for processing with a software GPS receiver
written to run specifically with the SiGe sampler is welcome to comment or
throw in ideas :-)

Nick


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP output power

[Marcus D. Leech]

On 03/07/2011 11:43 PM, Songsong Gee wrote:
> Hello,
> I want to know USRP output power
> If I set an amplitude of a sinusoidal signal to 32767, which is the
> maximum value that USRP can transmit.
> Then, at the antenna, what voltage value the sinusoidal signal swing?
> 5V to -5V?
>   
Most of the daughtercards have a maximum output power of about +20dBm
into a 50-ohm load.
  I think that works out to about 2VP-P.

The BASIC_TX puts out a maximum of about 0dBm.

-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP output power

[Songsong Gee]

Hello,
I want to know USRP output power
If I set an amplitude of a sinusoidal signal to 32767, which is the maximum
value that USRP can transmit.
Then, at the antenna, what voltage value the sinusoidal signal swing? 5V to
-5V?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: Developers' Call, March 7, 2011

[Tom Rondeau]

I have put the IRC log from today's developers call to the GNU Radio Wiki:

http://gnuradio.org/redmine/wiki/gnuradio/Call20110307


Thanks to everyone who joined the call and participated today! We will have
our "regularly scheduled" call again in a few weeks.

I put that in quotes because the regularly scheduled might change based on
feedback from last time. I am finding these calls to be incredibly useful,
and we, obviously, would like to optimize the time so that as many people
can participate as possible.

Tom



On Fri, Mar 4, 2011 at 6:32 PM, Tom Rondeau  wrote:

> Our next developers' call will be held on Monday, March 7, 2011 at 1700
> UTC.
>
> Details:
> Time: 1700 UTC, 12 PM EST, 9 AM PST, etc.
> SIP call: sip:gnura...@digitalbazaar.com
> IRC channel: #gnuradio on Freenode
>
> Agenda:
> - Details of the GNU Radio 'next' transition
> - What bugs are left to work out?
> - keep_1_in_n
> - Volk build issues
>
> - gr-digital revolution
> - introduction to the "grand-restructure"
> - some inside-baseball on the migration
>
> - gr-conference
> - kicking around a few more details and ideas
>
>
> If you would like to discuss anything else, let me know and I will update
> the schedule before Monday.
>
> Thanks!
> Tom
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: A beginner question

[rono]

Thanks,

Do they explain on the use of filters, mixer of the sine waves too?





On 04/03/11 21:06, Martin Braun wrote:

On Fri, Mar 04, 2011 at 03:52:45AM -0700, Michael Ossmann wrote:

On Fri, Mar 04, 2011 at 02:35:53PM +0800, rono wrote:


Could anyone suggest some books as very layman? Thanks.


Practical Signal Processing by Mark Owen is an outstanding book for
those new to the field.  He introduces the use of complex numbers in the
first few pages instead of trying to avoid the concept as long as
possible like many such books do.


"Understanding Digital Signal Processing" by Richard G. Lyons also has a
good introductory chapter on complex baseband processing.

MB




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] usrp c++: changing external clock frequency

[Burak TUYSUZ]

Hi All,

While using the c++ interface for usrp with basicRX
if I need to supply a different clock frequency do I have to change
something as in python?
Thanks in advance.
-Burak
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Piping to the USRP - mkfifo issue

[Marcus D. Leech]

On Mon, Mar 7, 2011 at 2:45 AM, Tom Hendrick > wrote:


Thanks Tom,

I'm a beginner still with linux/GNURadio so I couldn't really find
any information that makes sense as to how gr-atsc handles the
fifo piping.

I had seen an example online of someone that had done a
transmission using the USRP and piping.  They had piped the output
of gstreamer using mkfifo like I had tried but I can't get any
output on the USRP when I read from the file created by mkfifo.

http://wiki.oz9aec.net/index.php/Simple_DVB_with_Gstreamer_and_GNU_Radio

-Tom


Hi tom,

Maybe the program you use for writing the video to the file uses some 
operations that only work on regular files? You may compare it to 
gnuradio/core/src/lib/io/gr_file_sink.cc which works well with named 
pipes. Also note that applications that use named pipes are frozen 
until both ends of the pipe are open. So if both applications are 
running then the "pipe connection" should be OK and the problem could 
be data type mismatch or something like that.


Alex

So, you have to make sure that your "producer" isn't buffering really 
large amounts of data.  Also, stupid question, are you producer and
  consumer processes both executing at the same time, and if so, how 
are you arranging that?






--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Trying to figure out time of packet arrival in USRP

[Sapna Dasarath]

Hello,

I am running usrp_transmit_path.py for transmission on one USRP
and usrp_receive_path.py for reception of signals on another USRP.
I want to determine the exact arrival time of a packet on the USRP.

I get the message stream which is received from packetutils.
The code in PacketUtils.py gets a packet from the USRP.
This is populated from copy_from_usrp_buffer  in usrp_source_base.cc.
I am assuming there is some polling mechanism to invoke usrp_basic_rx::read
for this.
I want to track the point where this buffer is populated. The time stamp of
the packet when it is detected by USRP without any modifications by higher
layers.
Can this be done without any changes in Firmware? Any pointers on how to
proceed will be appreciated.

Thanks.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error while building wxPython, GCC4

[Moeller]

On 07.03.2011 15:15, Don Ward wrote:
> Remove any gcc/g++ versions other than the one you choose to use (only
> 3.4.4-999 is currently known to work with GNU Radio).  Be prepared to
> rebuild any dependencies that you might have built with another compiler.

The GCC 4.3.4 (GCC4 cygwin packages) also works for me, at least with
the current git/main branch of Gnuradio.
GCC 3 is installed in parallel, but I don't use it any more.
They don't conflict, because the gcc, g++ etc. aliases all point to GCC4.
GCC can handle multiple installations with its separated library directories.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] volk build issues on Cygwin, partial success

[Johnathan Corgan]

On Mon, Mar 7, 2011 at 05:34, Moeller  wrote:

> Unfortunately, grc always tells me it's a "v3.3.1git-974-g942e2685" version,
> although I removed all traces of previous versions.
> Are the GRC version strings updated in the git versions?

Unfortunately, this is an artifact of how 'git describe' works, which
is what we use to calculate the version string on non-release
versions.  It finds the shortest path back to the last tag in the
tree.  When we merge from master -> next, the shortest path backwards
becomes the last tag in the master branch, which is '3.3.1git'.

I see if I can work out a way to fix this when we create the new
'next' branch after the 3.4.0 release.

Johnathan

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error while building wxPython

[Vijay Pillai]

Hi Don,

Thank you for your suggestion. I set the version for libgcc1, gcc4-core, 
gcc4-g++ to the same (4.3.4-3) and then it seemed to work (not exactly sure why 
this should make it work, but I read a thread online that said all the 
different gcc variants should have the same version)

Best regards,
-Vijay

--- On Mon, 3/7/11, Don Ward  wrote:

From: Don Ward 
Subject: Re: [Discuss-gnuradio] Error while building wxPython
To: Discuss-gnuradio@gnu.org
Date: Monday, March 7, 2011, 9:15 AM

Vijay Pillai wrote:

> I am following the instructions at (Step 9) available at
> http://gnuradio.org/redmine/wiki/gnuradio/WxPythonCygwin
> 
> In the previous step, I am able to generate the test window so I assume
>  everything is working to that point. After running the following command
> python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin 
> BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0
> I get an error. I have tried various things such as use different versions of
> gcc without much success.

I highly recommend picking one version of gcc and using that version only.
If you switch versions, you should probably start over, recompiling everything.

> I also changed the ownership of directories as was noted in the tips section
> for installing on windows. The error that I get is attached at the end and
> seems to be related to gcc.
> 
> What could be going wrong here?
> 
> Error as follows -
> 
> Vijay@DG70JBG1 /usr/src/wxPython-src-2.8.11.0/wxPython
> $ python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin 
> BUILD_GLCANVAS
> =0 BUILD_GIZMOS=0 UNICODE=0
> WARNING: WXWIN not set in environment. Assuming '..'
> Found wx-config: /usr/local/bin/wx-config
>    Using flags:  --toolkit=msw --unicode=no --version=2.8
> Preparing CORE...
> Preparing STC...
> running build_ext
> building '_core_' extension
> gcc -mcygwin -mdll -O -Wall -DSWIG_TYPE_TABLE=_wxPython_table 
> -DSWIG_PYTHON_OUTP
> UT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES  
> -DWXU
> SINGDLL -D__WXMSW__ -Iinclude -Isrc 
> -I/usr/local/lib/wx/include/msw-ansi-release
> -2.8 -I/usr/local/include/wx-2.8 -I/usr/include/python2.6 -c src/helpers.cpp 
> -o
> build/temp.cygwin-1.7.8-i686-2.6/src/helpers.o -O3
> gcc: error trying to exec 'cc1plus': execvp: No such file or directory
> error: command 'gcc' failed with exit status 1

This seems to say that part of your gcc installation is missing.  Use the
command "cygcheck -c" to see what gcc is installed and to verify that
the files required are present.  Remove and reinstall any damaged packages.
Remove any gcc/g++ versions other than the one you choose to use (only
3.4.4-999 is currently known to work with GNU Radio).  Be prepared to
rebuild any dependencies that you might have built with another compiler.

-- Don W.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] libstdc++ error on Cygwin

[Vijay Pillai]

Hi Don,

Here is the what was displayed earlier, exactly when the error occured. When I 
ran "make check" a couple of times afterward (one after the other), eventually 
it passed without any errors

Best regards,
-Vijay

--

==
ERROR: test_002_ (__main__.qa_classify)
--
Traceback (most recent call last):
  File "./qa_classify.py", line 94, in test_002_
    self.tb.run()
  File "/home/Vijay/gnuradio-3.3.0/gnuradio-core/src/python/gnuradio/gr/top_bloc
k.py", line 104, in run
    self.wait()
  File "/home/Vijay/gnuradio-3.3.0/gnuradio-core/src/python/gnuradio/gr/top_bloc
k.py", line 107, in wait
    _top_block_waiter(self._tb).wait()
  File "/home/Vijay/gnuradio-3.3.0/gnuradio-core/src/python/gnuradio/gr/top_bloc
k.py", line 59, in __init__
    self.event = _threading.Event()
  File "/usr/lib/python2.6/threading.py", line 360, in Event
    return _Event(*args, **kwargs)
  File "/usr/lib/python2.6/threading.py", line 368, in __init__
    self.__cond = Condition(Lock())
error: can't allocate lock



--- On Sun, 3/6/11, Don Ward  wrote:

From: Don Ward 
Subject: Re: [Discuss-gnuradio] libstdc++ error on Cygwin
To: discuss-gnuradio@gnu.org
Date: Sunday, March 6, 2011, 8:34 PM

Vijay Pillai wrote:

> Something that I want to note was that after running "make check"
> I did get an error message but the program did not halt when it
> showed the error. This error did not prevent the tone so maybe it
> does not matter. For reference, I am attaching the error message
> at the end of this mail.
[...]
> Here is the error message at the end of running "make check"
> FAIL: run_tests
> ==
> 1 of 1 test failed
> ==

Earlier in the output there should have been more information.
The most likely problem would include the messages

...sem_init: No error

and

error: can't allocate lock

This is a problem in Cygwin and does not indicate a problem in
your GNU Radio installation.  It does not always occur, and "make
check" may succeed if you run it enough times.

-- Don W.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] message_source repeatly transmit msg 10times

[Yan Nie]

I also tried the struct.pack('!H',pktno & 0x) + data to pack the data as 
pkt_send does. This approach gives the error on gr_chunks_to_symbols_bf 
((unsigned int)in[i]*d_D+d_D)<=d_symbol_table.size() failed, where the symbol 
table size in my case is 2. I dug into the pkt.py and packet_utils.py, which 
gives the idea in order to connect the packed message source with block 
gr.chunks_to_symbols_bf, packed message should be unpacked. If this 
understanding is correct, the message don't have to be packed before insert to 
the flow graph. I found when the message is packed in packet_utils.make_packet, 
it appends a '\x55' in the pack. Does this '\x55' sign tell USRP this is the 
end of this msgq and this msgq only be sent once by calling 
msgq.insert_tail(msg) once?

Any of your help values a lot for me, since this problem is the last problem I 
need to get solved for my project. It really gets stuck here.

Really appreciate any suggestion on solving this problem!

Yan

On 03/07/11, Yan Nie   wrote:
> 
> 
> 
> I also tried msgq.flush() to delete all of the data in the queue as soon the 
> data is inserted to the message queue. This approach allows the data repeatly 
> transmitted in various times, ranging from once to 10 times.  Could anyone 
> give me some suggestion to allow me keep on going.
> 
> 
> I also tried struct.pack('!H', pktno & 0x) + data to pack the data 
> 
> 
> 
> 
> 
> 
> On 03/06/11, Yan Nie   wrote:
> > 
> > Dear all,
> > 
> > I'm using message_source generate data source then modulated and 
> > transmitting through USRP1 board with LFTX plugged-in. After building the 
> > flow graph, I used the msgq_insert to insert 1950 bytes data into the flow 
> > graph to be transmitted, then insert another group of data which is 97500 
> > bytes into the the flow graph. The result turns out these two group of data 
> > are repeatly sent 10 times. What could be the problem here?
> > 
> > This problem really troubles me for a while and it seems to be the biggest 
> > problem that I really need to solve for my project, and I dug into the 
> > source code related to message_source and gr_message, but couldn't get any 
> > clue why this happens here. Really need your help!
> > 
> > Really appreciate any of you help!
> > 
> > Thanks,
> > Yan
> > 
> > the code related:
> > #message_source in tb block
> > indata = gr.message_source(gr.sizeof_char, 1950)
> > msgq = indata.msgq()
> > constellation = [-1,1]
> > mapper = chunks_to_symbols_bf(constellation)
> > #setup USRP and signal amplitude setting..
> > usink  = ...
> > connect(indata,mapper,usink)
> > 
> > #flowgraph running in main
> > try:
> >    tb.start()
> >    while 1:  
> >   i = 0
> >   tb.set_amp(5000)
> >   msg_13bit = gr.messge_from_string(payload_13bit) #payload_13bit 
> > is 1950 bytes
> >   tb.msgq.insert_tail(msg_13bit)
> >   tb.set_amp(0)
> >   while (i<50)
> >   msg_stop = gr.message_from_string(payload_stop) #payload_stop 
> > is 1950 bytes
> >   tb.msgq.inset_tail(msg_stop)
> >   i +=1
> >     tb.wait()
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> 
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How many tunable parameters in GNU radios?

[Rachel Li]

Hi All:

I have a very general question, does anyone know how many tunable parameters
(approximately) are there in GNU radio (e.g. USRP1)?

Suppose two radios need to get/set each other's parameters, in the
conventional approach, they need a fixed protocol, the number of tunable
parameters will effect the design of the protocol. I am using a different
approach in which the radios use a common language to "talk" to each other,
therefore, they can use this language to exchange singling messages and
doesn't need a fixed protocol.

If anyone knows the answer of my question, it would be very helpful for the
evaluation of my approach!

Thanks very much!

Rachel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio c++ code structure question

[mehmet kabasakal]

Hi Martin,

As you guess, i use gr_sync_block.
But i don't use vector input items, i mean the input of the block is
streaming points.
Do i still have noutput_items * 2048 buffer size?

Mehmet.

2011/3/7, Martin Braun :
> Hi Mehmet,
>
> you've omitted some crucial parts of your code.
> I'm guessing you've made your block a gr_sync_block.
>
> It's easiest if your input items are vectors. In that case, your input
> buffer (input_items) will contain noutput_items * 2048 float values.
> Then, just process your data on whole blocks.
>
> The operation you describe seems pretty simple. You can probably set it
> up with a couple of existing blocks without having to write any code at
> all, although your method is surely more efficient (in terms of CPU
> load, not development time).
>
> MB
>
> On Mon, Mar 07, 2011 at 03:56:04PM +0200, mehmet kabasakal wrote:
>> Hi everyone,
>>
>> I am trying to develop a frame based structure for gnuradio block on c++.
>> The frame size will be 2048 point and i will calculate the normalized
>> amplitude for every frame i.e.
>>
>> ma = sum(every 2048 points)/2048;
>> normalized amplitude = all 2048 points / ma;
>>
>> i wrote a code that gives me the desired result under "work" function;
>>
>>
>>
>> int
>> gr_gama_maks_ff::work (int noutput_items,
>>  gr_vector_const_void_star &input_items,
>>  gr_vector_void_star &output_items)
>> {
>>   const float *in = (const float *) input_items[0];
>>   float *out = (float *) output_items[0];
>>   float ma = 0.0;
>>   float acn[noutput_items], an[noutput_items];
>>   int C = 2048;
>>   int a = 0;
>>   int count = 0;
>>
>>   for (int i = 0; i < noutput_items; i++){
>> ma = 0.0;
>> for (int m = a*C; m < a*C+C ; m++) {
>>  ma += in[m]/C;  
>> }
>>
>> an[i] = in[i]/ma;
>> acn[i] = an[i]-1;
>> out[i] = acn[i]*d_k;
>>
>>if ((i+1) % C == 0) {
>> a = a + 1;
>>}
>>   }
>>
>>
>>
>> As you see i didn't keep a 2048 point array, i just find the sum of
>> 2048 points and then use it for the output (an[i]= in[i]/ma). But i
>> couldn't figure out how this happens. I mean the while index "i = 1"
>> in the first for loop, i can reach the i+2047th sample in the second
>> for loop.
>>
>> Is there a buffer for every block in gnuradio. If yes what is the size
>> of the buffer?
>>
>> I hope i would explain it clear.
>>
>> Mehmet.
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> --
> 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
>
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio c++ code structure question

[Martin Braun]

Hi Mehmet,

you've omitted some crucial parts of your code.
I'm guessing you've made your block a gr_sync_block.

It's easiest if your input items are vectors. In that case, your input
buffer (input_items) will contain noutput_items * 2048 float values.
Then, just process your data on whole blocks.

The operation you describe seems pretty simple. You can probably set it
up with a couple of existing blocks without having to write any code at
all, although your method is surely more efficient (in terms of CPU
load, not development time).

MB

On Mon, Mar 07, 2011 at 03:56:04PM +0200, mehmet kabasakal wrote:
> Hi everyone,
> 
> I am trying to develop a frame based structure for gnuradio block on c++.
> The frame size will be 2048 point and i will calculate the normalized
> amplitude for every frame i.e.
> 
> ma = sum(every 2048 points)/2048;
> normalized amplitude = all 2048 points / ma;
> 
> i wrote a code that gives me the desired result under "work" function;
> 
> 
> 
> int
> gr_gama_maks_ff::work (int noutput_items,
>   gr_vector_const_void_star &input_items,
>   gr_vector_void_star &output_items)
> {
>   const float *in = (const float *) input_items[0];
>   float *out = (float *) output_items[0];
>   float ma = 0.0;
>   float acn[noutput_items], an[noutput_items];
>   int C = 2048;
>   int a = 0;
>   int count = 0;
> 
>   for (int i = 0; i < noutput_items; i++){
> ma = 0.0;
> for (int m = a*C; m < a*C+C ; m++) {
>   ma += in[m]/C;  
> }
> 
> an[i] = in[i]/ma;
> acn[i] = an[i]-1;
> out[i] = acn[i]*d_k;
> 
>if ((i+1) % C == 0) {
> a = a + 1;
>}
>   }
> 
> 
> 
> As you see i didn't keep a 2048 point array, i just find the sum of
> 2048 points and then use it for the output (an[i]= in[i]/ma). But i
> couldn't figure out how this happens. I mean the while index "i = 1"
> in the first for loop, i can reach the i+2047th sample in the second
> for loop.
> 
> Is there a buffer for every block in gnuradio. If yes what is the size
> of the buffer?
> 
> I hope i would explain it clear.
> 
> Mehmet.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
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



pgpTw7u95Luyi.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: uhd_usrp_sink often blocks in non-continuous data sending

[Feng Andrew Ge]

Josh,

The code works well now, thanks a lot for your help in the past week.

The delay was caused by a system setting in my computer and not related 
to UHD code.


Andrew


On 03/04/2011 12:19 AM, Josh Blum wrote:




As such, do you know an approach to solve this blocking problem?  I have
tried to set the timeout as a small value, e.g. 1ms, but it seems not
able to completely solve the problem.  I have never seen such behavior
using the raw Ethernet code.  What's the difference?


Andrew,

The uhd_usrp_sink::work() should always block until the entire buffer
has been transmitted. There is no choice in the matter. However many
samples gnuradio buffered before calling work(), we must send all of
those samples.

Now, there is a question of where is the delay, what is taking too long,
what is buffering too much, etc. I am attaching a diff with prints for
the time before and after the send() call in the work function. This
will tell us how often work is called, how many samples are transmitted,
and how long this operation takes. Please try the attached diff and post
the output.

Thanks,
-Josh



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error while building wxPython

[Don Ward]

Vijay Pillai wrote:


I am following the instructions at (Step 9) available at
http://gnuradio.org/redmine/wiki/gnuradio/WxPythonCygwin

In the previous step, I am able to generate the test window so I assume
 everything is working to that point. After running the following command
python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin 
BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0
I get an error. I have tried various things such as use different versions 
of

gcc without much success.


I highly recommend picking one version of gcc and using that version only.
If you switch versions, you should probably start over, recompiling 
everything.


I also changed the ownership of directories as was noted in the tips 
section

for installing on windows. The error that I get is attached at the end and
seems to be related to gcc.

What could be going wrong here?

Error as follows -

Vijay@DG70JBG1 /usr/src/wxPython-src-2.8.11.0/wxPython
$ python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin 
BUILD_GLCANVAS

=0 BUILD_GIZMOS=0 UNICODE=0
WARNING: WXWIN not set in environment. Assuming '..'
Found wx-config: /usr/local/bin/wx-config
   Using flags:  --toolkit=msw --unicode=no --version=2.8
Preparing CORE...
Preparing STC...
running build_ext
building '_core_' extension
gcc -mcygwin -mdll -O -Wall -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTP
UT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES 
 -DWXU

SINGDLL -D__WXMSW__ -Iinclude -Isrc -I/usr/local/lib/wx/include/msw-ansi-release
-2.8 -I/usr/local/include/wx-2.8 -I/usr/include/python2.6 -c 
src/helpers.cpp -o

build/temp.cygwin-1.7.8-i686-2.6/src/helpers.o -O3
gcc: error trying to exec 'cc1plus': execvp: No such file or directory
error: command 'gcc' failed with exit status 1


This seems to say that part of your gcc installation is missing.  Use the
command "cygcheck -c" to see what gcc is installed and to verify that
the files required are present.  Remove and reinstall any damaged packages.
Remove any gcc/g++ versions other than the one you choose to use (only
3.4.4-999 is currently known to work with GNU Radio).  Be prepared to
rebuild any dependencies that you might have built with another compiler.

-- Don W.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gnuradio c++ code structure question

[mehmet kabasakal]

Hi everyone,

I am trying to develop a frame based structure for gnuradio block on c++.
The frame size will be 2048 point and i will calculate the normalized
amplitude for every frame i.e.

ma = sum(every 2048 points)/2048;
normalized amplitude = all 2048 points / ma;

i wrote a code that gives me the desired result under "work" function;



int
gr_gama_maks_ff::work (int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
  const float *in = (const float *) input_items[0];
  float *out = (float *) output_items[0];
  float ma = 0.0;
  float acn[noutput_items], an[noutput_items];
  int C = 2048;
  int a = 0;
  int count = 0;

  for (int i = 0; i < noutput_items; i++){
ma = 0.0;
for (int m = a*C; m < a*C+C ; m++) {
ma += in[m]/C;  
}

an[i] = in[i]/ma;
acn[i] = an[i]-1;
out[i] = acn[i]*d_k;

   if ((i+1) % C == 0) {
a = a + 1;
   }
  }



As you see i didn't keep a 2048 point array, i just find the sum of
2048 points and then use it for the output (an[i]= in[i]/ma). But i
couldn't figure out how this happens. I mean the while index "i = 1"
in the first for loop, i can reach the i+2047th sample in the second
for loop.

Is there a buffer for every block in gnuradio. If yes what is the size
of the buffer?

I hope i would explain it clear.

Mehmet.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] volk build issues on Cygwin, partial success

[Moeller]

On 05.03.2011 01:52, Don Ward wrote:
> Due mainly to circumstances beyond my control, it is now possible to build 
> the volk library on Cygwin :-).  Previously, there was no support for C99 
> complex data types in the Cygwin library, but this was fixed by the release 
> of Cygwin 1.7.8-1 this past Tuesday.

Thanks. I updated Cygwin and now the current git/main Gnuradio builds out of 
the box.
(after installing all dependencies with Cygwin, cygport or manually)

The functionality was Ok, examples are working, with synthetic signals
as well as with live audio in/out. GRC is working with the wx widgets.
Waterfall, FFT sinks, constellation plots ... all working.

The git/next branch compiles (incl. volk), but make check fails and
make install fails (after installing most of it), too.

Unfortunately, grc always tells me it's a "v3.3.1git-974-g942e2685" version,
although I removed all traces of previous versions.
Are the GRC version strings updated in the git versions?
According to the "Process Monitor", the "3-4git" DLLs are loaded
(after the partial git/next install, before it was 3-3-2git)

> The remaining issues can be addressed by patches or workarounds:
>  (1) configure fails while testing for -lboost_unit_test_framework because 
> of the presence of  "-Wl,--enable-runtime-pseudo-reloc" in LDFLAGS.  I'm not 
> sure why it is a problem, but I don't think these flags are needed at all in 
> this situation.

I installed boost 1.43 and got no errors this time.
Last time I tried, it stopped at some boost unit test code.

>  (2) C++ libraries are not found because 
> volk/config/gcc_version_workaround.m4 specifies -nostdinc++ without knowing 
> where to find the libraries on Cygwin.  My suggestion is to exempt Cygwin 
> from the action of gcc_version_workaround.m4.
> Changes to fix both of these (for Cygwin, anyway) are in the attached patch 
> file.

I had no problems with this (GCC 4).

>  (3) volk_16i_x4_quad_max_star_16i_a16.h triggers an internal compiler error 
> in the Cygwin gcc 3.4.4-999.  One workaround is to remove "-O2" from the 
> Makefile.  (An obvious suggestion is to use a newer compiler, but the last 
> time I tried it Cygwin gcc 4.x couldn't handle the exceptions generated 
> while looking for a working circular buffer strategy.  I will check again 
> from time to time to see if the latest compiler works.)

The first GCC 4 release came out in 2005. I used GCC 4 very early
for my projects. It's important for OpenMP parallelization.
Unfortunately Cygwin still uses GCC 3 as standard compiler.
But they offer GCC 4 as package in their setup.exe.
In the early years, there were many incompatibilities with GCC 4,
because it's more strict with the standard, and also had bugs.
But now it's very mature. I think, you should just forget about GCC 3.

> The bottom line is that we can now build volk (and the GNU Radio 'next' 
> branch) on Cygwin.

It's great to have a functional Gnuradio on the Windows platform.
UHD did not build, but I don't have UHD compatible devices, anyway.
I'm still looking for alternative (cheap) hardware, that can be made
gnuradio compatible and integrated in the UHD driver.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Piping to the USRP - mkfifo issue

[Alexandru Csete]

On Mon, Mar 7, 2011 at 2:45 AM, Tom Hendrick  wrote:

> Thanks Tom,
>
> I'm a beginner still with linux/GNURadio so I couldn't really find any
> information that makes sense as to how gr-atsc handles the fifo piping.
>
> I had seen an example online of someone that had done a transmission using
> the USRP and piping.  They had piped the output of gstreamer using mkfifo
> like I had tried but I can't get any output on the USRP when I read from the
> file created by mkfifo.
>
> http://wiki.oz9aec.net/index.php/Simple_DVB_with_Gstreamer_and_GNU_Radio
>
> -Tom
>

Hi tom,

Maybe the program you use for writing the video to the file uses some
operations that only work on regular files? You may compare it to
gnuradio/core/src/lib/io/gr_file_sink.cc which works well with named pipes.
Also note that applications that use named pipes are frozen until both ends
of the pipe are open. So if both applications are running then the "pipe
connection" should be OK and the problem could be data type mismatch or
something like that.

Alex
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio