[Discuss-gnuradio] Bitrate doubt
hi folks, I am using BENCHMARK_TX.PY, BENCHMARK_RX.PY to test the transmission and reception of signals. I have doubts regarding the outpu that is appearing on the screen. >>> gr_fir_fff: using SSE socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted eth0: socket: No such file or directory Requested RX Bitrate: 100k Actual Bitrate: 125k Warning: Failed to enable realtime scheduling. 1) What is the SOCKET part in the output 2) What is the difference between Actual Bitrate and Requested Bitrate 3)How to enable real time scheduling 4)I am always loosing the last 5-10 packets during the reception. What is the reason behind this loss. ( I tried varying packet size , bitrate also. But no use) Thanks, Amarnath -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Throughput with Turbo Encoder
The throughput depends on how optimal and fast the program you write is. I'm not familar with Turbo decoder theory. In 2007, we used turbo decoder from IT++ libary (http://sourceforge.net/apps/wordpress/itpp/). It is faster than that we wrote. It supports a 64 kbps (One CPU) and 384 kbps (maybe 3 CPUs, I don't remember.) TD-SCDMA PHY layer in realtime. Another method is to use SIMD optimization. Lin 2010/1/16 万千 > Dear all, > I am new to GNU Radio. I am building a transceiver with turbo encoder > and FQPSK modulator. At the receiver, FQPSK demodulator softly demodulates > the received signals with BCJR algorithm (FQPSK can be viewed as a two-bit > input TCM with 16 states). I simulated the system using C++ code. The length > of a frame into the turbo encoder is 1024. The generator polynomial is (013, > 015). 8 iterations are taken. The three metrics of alpha, beta and gamma are > calculated by using LUT to speed up the simulation. But I found that it > still is a little bit slow. The turbo decoding operation of a frame takes > about 0.064s (the simulation runs on a computer with 2 CPU of 3.0GHz and 2G > memory). So I think if the turbo decoding is done by software, the > throughput will be rather slow. > I checked the mailing list in 2006-05, in which it is said that > throughput is very slow with extension to turbo decoding. But I am still > wondering with some easy improvements, the throughput can be increased > significantly. Further, if iterative phase synchronization is done by > software, the receiving time of a frame will be intolerable. So I wonder > whether the software define radio is suited for the transceiver that I > mentioned above and GNU Radio is really real-time. > > thanks > Neil > > > > ___ > 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] Throughput with Turbo Encoder
Dear all, I am new to GNU Radio. I am building a transceiver with turbo encoder and FQPSK modulator. At the receiver, FQPSK demodulator softly demodulates the received signals with BCJR algorithm (FQPSK can be viewed as a two-bit input TCM with 16 states). I simulated the system using C++ code. The length of a frame into the turbo encoder is 1024. The generator polynomial is (013, 015). 8 iterations are taken. The three metrics of alpha, beta and gamma are calculated by using LUT to speed up the simulation. But I found that it still is a little bit slow. The turbo decoding operation of a frame takes about 0.064s (the simulation runs on a computer with 2 CPU of 3.0GHz and 2G memory). So I think if the turbo decoding is done by software, the throughput will be rather slow. I checked the mailing list in 2006-05, in which it is said that throughput is very slow with extension to turbo decoding. But I am still wondering with some easy improvements, the throughput can be increased significantly. Further, if iterative phase synchronization is done by software, the receiving time of a frame will be intolerable. So I wonder whether the software define radio is suited for the transceiver that I mentioned above and GNU Radio is really real-time. thanks Neil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
Tom-
> Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
>
> We greatly appreciate the information and need to think about stuff on
> our end. I've been deliberately vague about our application (not that
> I could really explain it even if I felt authorized discuss it). The
> thing to remember is that we believe (maybe we are fooling ourselves)
> that we see easily reproducible problems when RX is ON but not when RX
> is OFF.
>
> One more question was just sent to me to pass on, while I was
> composing this email:
>
> crazy idea: is there any way to "clock" the host, i.e. keep track of a
> time stamp in the host and gate/trigger the host outputs at a constant
> sample rate that is consistent with the sample rate of the USRP2?
>
> just thought I would throw that out there...
"Clock the host" at multi-MHz rate? One way would be to connect the A/D
converter directly to the PC and omit
external radio hardware. Then you would not need FPGA de-modulation, GbE, etc.
That would be a multi-year hardware
and software effort, but sounds like something you and your mystery questioner
might be willing to take on ;-)
-Jeff
> On Fri, Jan 15, 2010 at 6:24 PM, Matt Ettus wrote:
>> On 01/15/2010 03:08 PM, Tom Gross wrote:
>>>
>>> yes of course we have two separate gig-e cards. if the usrp2 is
>>> sending us "pause" commands then it seems evident the usrp2 is having
>>> trouble keeping up, not the computer.
>>
>> First off, the USRP2 will only send pause frames when you are transmitting,
>> not receiving. Pause frames are not generated due to the USRP2 being unable
>> to keep up. Pause frames are not generated due to the computer not being
>> able to keep up. Pause frames are generated as a normal part of the
>> transmission process. This is fundamental, and you need to understand
>> exactly why.
>>
>>
>>
>> When you are transmitting, the USRP2 can only consume samples at a fixed
>> rate, determined by the clock rate (100 MHz) and the interpolation rate (4
>> or higher). No matter what that rate is, your computer should be able to
>> generate samples faster than that. Since your computer does not have a 100
>> MHz clock to pace the generation of those samples, it will generate them too
>> fast. When they are sent the USRP2, which can only consume them at a
>> certain rate, they will pile up in the buffers of the USRP2. Once the
>> buffers get full enough, the USRP2 will send pause frames back to the
>> computer to tell it to wait until the samples it has can work their way
>> through the pipeline.
>>
>> Again, this is completely normal and not because your computer is too slow,
>> and not because the USRP2 is too slow. It is a normal consequence of the
>> practicalities of generating samples asynchronously to their consumption.
>>
>> So in normal transmit operation, you will see large numbers of pause frames
>> going from the USRP2 to the computer. Do not be alarmed.
>>
>>
>> When receiving, the USRP only generates data as fast as samples are created
>> by the ADC clock, divided by the decimation rate. If the decimation rate is
>> 4 then the sample rate is 25 MS/s at 32 bits per sample, or 800 mbits. This
>> fits just fine into gigabit ethernet, and so it all just goes out almost
>> immediately over the ethernet, and nothing ever backs up and stalls. If
>> your computer couldn't keep up, then it MIGHT WANT TO send pause frames, but
>> we have disabled that. Instead, if your computer can't keep up it will drop
>> frames and you'll see "S" in your terminal window. Get a faster computer or
>> do less processing if you see this.
>>
>> If you were to try a decimation of 3 or lower, then you would be generating
>> more than 1 gigabit per second, and the ethernet wouldn't keep up, and the
>> buffers in the USRP2 would overflow and cause an overrun ("O") error. You
>> shouldn't be doing this because it won't work.
>>
>> I hope this has cleared it up. To summarize -- each USRP2 needs its own
>> Gigabit ethernet card to talk to EVEN if it is using only a tiny fraction of
>> the total bandwidth. And those cards need to be configured to honor flow
>> control.
>>
>> Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
On 01/15/2010 03:53 PM, Tom Gross wrote: Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ). We greatly appreciate the information and need to think about stuff on our end. I've been deliberately vague about our application (not that I could really explain it even if I felt authorized discuss it). The thing to remember is that we believe (maybe we are fooling ourselves) that we see easily reproducible problems when RX is ON but not when RX is OFF. It is very hard to help when we don't have information about what you are trying to do. The important piece of information is that you are transmitting and receiving at the same time when you see this problem. This indicates that there may be flow control tuning issues. Is the RX stream ok and the TX has a problem? Or is it that the TX is ok and the RX has a problem? Or is it both? Do you have a TTL serial port hooked up to J305? Do you see characters there? Do you see "S" characters on the receive application window? Are you trying to use 2 separate programs (1 tx, 1 rx) to talk the the USRP2, or are they in the same app? One more question was just sent to me to pass on, while I was composing this email: crazy idea: is there any way to "clock" the host, i.e. keep track of a time stamp in the host and gate/trigger the host outputs at a constant sample rate that is consistent with the sample rate of the USRP2? No, for 2 reasons: - Even if the host had a clock, clocks drift relative to each other - The USRP2 might need to hold off on sending for some reason. This is a system that requires feedback and there is no way around it. On the USRP1 the feedback is done by the flow control built into the USB protocol. On the USRP2 the feedback is done by the flow control built into ethernet. You could imagine doing a different feedback mechanism using your own protocol, but it would still involve the device telling the computer when to go and when to stop. Actually there is one way around it -- have infinitely large buffers in the USRP2, but that would add to the cost :) Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] need help on loading my own FPGA bitstream
Dear all, I'm trying to load my own FPGA bitstream. The .rbf file, however, cannot be loaded due to the errors as below. I've already copied the .rbf file under the directories /usr/local/share/usrp/rev2 and rev4 as well. Could you please guide me what the problem or the solution to solve the problem? Thank you so much in advance for the help. Can't find fpga bitstream: ionosonde_tx_test0106.rbf Traceback (most recent call last): File "./usrp_ionosonde.py", line 115, in main() File "./usrp_ionosonde.py", line 91, in main debug=options.debug) File "/home/john/gnuradio/ionosonde/src/python/ionosonde.py", line 179, in __init__ verbose=self._verbose) File "/home/john/gnuradio/ionosonde/src/python/ionosonde.py", line 56, in __init__ self._u = usrp.sink_s(fpga_filename="ionosonde_tx_test0106.rbf") File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py", line 2736, in sink_s return _usrp_swig.sink_s(*args, **kwargs) RuntimeError: can't open usrp Regards, Yan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Commit emails from git repository
In the spirit of more open communication, I've changed the gnuradio.org configuration to send commit emails from individual developer repositories to the main commit-gnuradio mailing list. The upside to this is that it is easier to see what people are working on before it gets promoted to the main gnuradio.git repository. The downside is that if you're subscribed to commit-gnuradio, you may get multiple emails--one when the developer pushes their branch to their personal repo, and one again when it is merged into the main repo. Developers--this also means that your in-progress work is immediately notified on the list when you commit, which means you may wish to do your squashes/rebases locally before pushing. As a reminder, the URL for the collection of git repositories for gnuradio.org is: http://gnuradio.org/cgit Johnathan Corgan Corgan Enterprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-pager build issue
On Fri, Jan 15, 2010 at 17:44, Veljko Pejovic wrote: > I got the same error: > > make[4]: *** No rule to make target `/../lib/libgnuradio-pager.la', > needed by `_pager_swig.la'. Stop. > Did anyone find out what is the source of this error is? I just did a from-scratch rebuild of the current git revision on Ubuntu 9.10, no issues. I suspect this may have to do with a build tree left over from a prior compile. Did you just upgrade from 9.04 to 9.10 perhaps? In any case, the complete nuke-it-all-to-pristine-state command in git is: $ git clean -d -x -f Then you can bootstrap, configure, make, etc. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-pager build issue
Hi, I got the same error: make[4]: *** No rule to make target `/../lib/libgnuradio-pager.la', needed by `_pager_swig.la'. Stop. make[4]: Leaving directory `/home/moment/Documents/gnuradio-veljkop/trunk/gnuradio/gr-pager/swig' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/moment/Documents/gnuradio-veljkop/trunk/gnuradio/gr-pager/swig' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/moment/Documents/gnuradio-veljkop/trunk/gnuradio/gr-pager' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/moment/Documents/gnuradio-veljkop/trunk/gnuradio' make: *** [all] Error 2 on Ubuntu 9.10 when trying to build the most recent gnuradio source code. The latest release (3.2.2) builds fine. Did anyone find out what is the source of this error is? Cheers, Veljko 2009/12/21 Ben Hilburn : > Yup - I tried all of the 'dumb mistake' things I could think of. Like > I said, I couldn't reproduce the error on another system. I'll dig > through things once I find time and see if I can't get to the source > of the issue. > > I just wanted to mention it in case it comes up again in the near > future from another user. > > Cheers, > Ben > > On Mon, Dec 21, 2009 at 10:19 PM, Tom Rondeau wrote: >> Ben Hilburn wrote: >>> >>> Hey all - >>> >>> When building the most recent pull of the GNURadio tree on Ubuntu, >>> gr-pager fails to build with the following error: >>> >>> -- >>> make[5]: *** No rule to make target `/../lib/libgnuradio-pager.la', >>> needed by `_pager_swig.la'. Stop. >>> make[5]: Leaving directory >>> >>> `/users/bhilburn/code/gnuradio.git/gnuradio-3.3git-575-g75429993/_build/gr-pager/swig' >>> make[4]: *** [all] Error 2 >>> make[4]: Leaving directory >>> >>> `/users/bhilburn/code/gnuradio.git/gnuradio-3.3git-575-g75429993/_build/gr-pager/swig' >>> make[3]: *** [all-recursive] Error 1 >>> make[3]: Leaving directory >>> >>> `/users/bhilburn/code/gnuradio.git/gnuradio-3.3git-575-g75429993/_build/gr-pager' >>> make[2]: *** [all-recursive] Error 1 >>> >>> -- >>> >>> The Ubuntu system has swig 1.3 installed, and I get the same results >>> when using 'make distcheck'. However, I tested the build on another >>> machine running Archlinux, and could not reproduce the problem. >>> >>> I'm not sure if it is a system configuration issue or a compatibility >>> issue, but I wanted to give the list a heads-up in case it pops up >>> again later. I don't have time now, but I'll dig through it and >>> locate the problem when I find some free time. >>> >>> Cheers, >>> Ben >>> >> >> This seems like a configure-time error. Did you try a make distclean then a >> bootstrap && configure to rebuild all of the Makefiles? >> >> Tom >> >> > > > ___ > 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] Understanding flow control
Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
We greatly appreciate the information and need to think about stuff on
our end. I've been deliberately vague about our application (not that
I could really explain it even if I felt authorized discuss it). The
thing to remember is that we believe (maybe we are fooling ourselves)
that we see easily reproducible problems when RX is ON but not when RX
is OFF.
One more question was just sent to me to pass on, while I was
composing this email:
crazy idea: is there any way to "clock" the host, i.e. keep track of a
time stamp in the host and gate/trigger the host outputs at a constant
sample rate that is consistent with the sample rate of the USRP2?
just thought I would throw that out there...
have a good weekend!
-Tom
On Fri, Jan 15, 2010 at 6:24 PM, Matt Ettus wrote:
> On 01/15/2010 03:08 PM, Tom Gross wrote:
>>
>> yes of course we have two separate gig-e cards. if the usrp2 is
>> sending us "pause" commands then it seems evident the usrp2 is having
>> trouble keeping up, not the computer.
>
> First off, the USRP2 will only send pause frames when you are transmitting,
> not receiving. Pause frames are not generated due to the USRP2 being unable
> to keep up. Pause frames are not generated due to the computer not being
> able to keep up. Pause frames are generated as a normal part of the
> transmission process. This is fundamental, and you need to understand
> exactly why.
>
>
>
> When you are transmitting, the USRP2 can only consume samples at a fixed
> rate, determined by the clock rate (100 MHz) and the interpolation rate (4
> or higher). No matter what that rate is, your computer should be able to
> generate samples faster than that. Since your computer does not have a 100
> MHz clock to pace the generation of those samples, it will generate them too
> fast. When they are sent the USRP2, which can only consume them at a
> certain rate, they will pile up in the buffers of the USRP2. Once the
> buffers get full enough, the USRP2 will send pause frames back to the
> computer to tell it to wait until the samples it has can work their way
> through the pipeline.
>
> Again, this is completely normal and not because your computer is too slow,
> and not because the USRP2 is too slow. It is a normal consequence of the
> practicalities of generating samples asynchronously to their consumption.
>
> So in normal transmit operation, you will see large numbers of pause frames
> going from the USRP2 to the computer. Do not be alarmed.
>
>
> When receiving, the USRP only generates data as fast as samples are created
> by the ADC clock, divided by the decimation rate. If the decimation rate is
> 4 then the sample rate is 25 MS/s at 32 bits per sample, or 800 mbits. This
> fits just fine into gigabit ethernet, and so it all just goes out almost
> immediately over the ethernet, and nothing ever backs up and stalls. If
> your computer couldn't keep up, then it MIGHT WANT TO send pause frames, but
> we have disabled that. Instead, if your computer can't keep up it will drop
> frames and you'll see "S" in your terminal window. Get a faster computer or
> do less processing if you see this.
>
> If you were to try a decimation of 3 or lower, then you would be generating
> more than 1 gigabit per second, and the ethernet wouldn't keep up, and the
> buffers in the USRP2 would overflow and cause an overrun ("O") error. You
> shouldn't be doing this because it won't work.
>
> I hope this has cleared it up. To summarize -- each USRP2 needs its own
> Gigabit ethernet card to talk to EVEN if it is using only a tiny fraction of
> the total bandwidth. And those cards need to be configured to honor flow
> control.
>
> Matt
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
On 01/15/2010 03:08 PM, Tom Gross wrote:
yes of course we have two separate gig-e cards. if the usrp2 is
sending us "pause" commands then it seems evident the usrp2 is having
trouble keeping up, not the computer.
First off, the USRP2 will only send pause frames when you are
transmitting, not receiving. Pause frames are not generated due to the
USRP2 being unable to keep up. Pause frames are not generated due to
the computer not being able to keep up. Pause frames are generated as a
normal part of the transmission process. This is fundamental, and you
need to understand exactly why.
When you are transmitting, the USRP2 can only consume samples at a fixed
rate, determined by the clock rate (100 MHz) and the interpolation rate
(4 or higher). No matter what that rate is, your computer should be
able to generate samples faster than that. Since your computer does not
have a 100 MHz clock to pace the generation of those samples, it will
generate them too fast. When they are sent the USRP2, which can only
consume them at a certain rate, they will pile up in the buffers of the
USRP2. Once the buffers get full enough, the USRP2 will send pause
frames back to the computer to tell it to wait until the samples it has
can work their way through the pipeline.
Again, this is completely normal and not because your computer is too
slow, and not because the USRP2 is too slow. It is a normal consequence
of the practicalities of generating samples asynchronously to their
consumption.
So in normal transmit operation, you will see large numbers of pause
frames going from the USRP2 to the computer. Do not be alarmed.
When receiving, the USRP only generates data as fast as samples are
created by the ADC clock, divided by the decimation rate. If the
decimation rate is 4 then the sample rate is 25 MS/s at 32 bits per
sample, or 800 mbits. This fits just fine into gigabit ethernet, and so
it all just goes out almost immediately over the ethernet, and nothing
ever backs up and stalls. If your computer couldn't keep up, then it
MIGHT WANT TO send pause frames, but we have disabled that. Instead, if
your computer can't keep up it will drop frames and you'll see "S" in
your terminal window. Get a faster computer or do less processing if
you see this.
If you were to try a decimation of 3 or lower, then you would be
generating more than 1 gigabit per second, and the ethernet wouldn't
keep up, and the buffers in the USRP2 would overflow and cause an
overrun ("O") error. You shouldn't be doing this because it won't work.
I hope this has cleared it up. To summarize -- each USRP2 needs its own
Gigabit ethernet card to talk to EVEN if it is using only a tiny
fraction of the total bandwidth. And those cards need to be configured
to honor flow control.
Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
On 01/15/2010 03:14 PM, Tom Gross wrote: Matt, What is the maximum data rate that the USRP2 transmitter can accept from the host without firing pause signals back to the host? See my other message. The USRP2 will ALWAYS put out pause frames. In fact, when the data rate is low it will actually put out MORE pause frames. This is normal and is not something you should want to avoid. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
On Fri, Jan 15, 2010 at 15:08, Tom Gross wrote: > yes of course we have two separate gig-e cards. if the usrp2 is > sending us "pause" commands then it seems evident the usrp2 is having > trouble keeping up, not the computer. The host software, when creating a data stream to be sent to the USRP2 for TX, will create the data as fast as the processor allows, and TX on the GbE at full wire rate. The USRP2, however, is "consuming" data at a fixed rate proportional to the configured TX RF baseband sample rate. Even at the fastest sample rate, 25 Msps (interpolation rate 4), this is only 800 Mbps + framing overhead. So the USRP2 doesn't have problems "keeping up", it's just that the host can create the digital sample stream faster than real time, so the USRP2 pauses it periodically to keep the average data rate down to what is needed. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
Matt, What is the maximum data rate that the USRP2 transmitter can accept from the host without firing pause signals back to the host? -Tom On Fri, Jan 15, 2010 at 6:04 PM, Matt Ettus wrote: > >> Incidentally my System Engineer/Project Lead points out that if the >> USRP2 is actually telling the host to stop sending (which certainly >> appears to be the case) then we are only able to get overall >> throughput with two USRP2s over two gig-e connections comparable to >> what we were getting with a single USRP over a single USB 2.0 line. >> Something of a disappointment to us. > > That is not correct. If you have 2 USRP2s both connected by gig-e, then you > need 2 separate gig-e cards. You should be able to get the full throughput > to each one, but your computer may have a hard time keeping up. > > Matt > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
yes of course we have two separate gig-e cards. if the usrp2 is sending us "pause" commands then it seems evident the usrp2 is having trouble keeping up, not the computer. On Fri, Jan 15, 2010 at 6:04 PM, Matt Ettus wrote: > >> Incidentally my System Engineer/Project Lead points out that if the >> USRP2 is actually telling the host to stop sending (which certainly >> appears to be the case) then we are only able to get overall >> throughput with two USRP2s over two gig-e connections comparable to >> what we were getting with a single USRP over a single USB 2.0 line. >> Something of a disappointment to us. > > That is not correct. If you have 2 USRP2s both connected by gig-e, then you > need 2 separate gig-e cards. You should be able to get the full throughput > to each one, but your computer may have a hard time keeping up. > > Matt > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
Incidentally my System Engineer/Project Lead points out that if the USRP2 is actually telling the host to stop sending (which certainly appears to be the case) then we are only able to get overall throughput with two USRP2s over two gig-e connections comparable to what we were getting with a single USRP over a single USB 2.0 line. Something of a disappointment to us. That is not correct. If you have 2 USRP2s both connected by gig-e, then you need 2 separate gig-e cards. You should be able to get the full throughput to each one, but your computer may have a hard time keeping up. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
On Fri, Jan 15, 2010 at 2:07 PM, Eric Blossom wrote: > > Actually, PAUSE handling is all handled in the FPGA. When the FIFO is > getting full, a PAUSE frame is sent on the wire telling the host to > stop sending for a while. > Incidentally my System Engineer/Project Lead points out that if the USRP2 is actually telling the host to stop sending (which certainly appears to be the case) then we are only able to get overall throughput with two USRP2s over two gig-e connections comparable to what we were getting with a single USRP over a single USB 2.0 line. Something of a disappointment to us. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: WBX
Matt-san, Congratulations to the WBX announcement. As you know well, I am using USRP-1 for 150MHz/400MHz satellite beacon experiment, and the WBX just meets our frequency range. I would like to test it as soon as possible. But at the same time, I would like to say that RFX400 is very useful for our purpose. Larger concern from me is on the USRP-1. Our application (dual-band coherent receiver for TEC measurement, named GRBR) really needs USRP-1. Our experiment is getting more popularity these days. We now use 10+ receivers in Japan and in southeast Asian contries. But the globe is huge! I hope that many stations are built by number of researchres in the world. Soon I want to renew our GRBR web page, and announce our current status. Thanks for your help. Regards, Mamoru Yamamoto Research Institute for Sustainable Humanosphere (RISH) Kyoto University yamam...@rish.kyoto-u.ac.jp >At long last, the WBX is now available. It covers 50 MHz to 2.2 GHz. >The introductory price is $400 which includes an LNA/filter board and an >MCX to SMA-bulkhead cable. > >After the initial batch is gone, the price will be changing to $450 to >reflect the increased costs and capabilities associated with the >improved specs since our redesign for coverage to 2.2 GHz. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
Thanks Eric, that's exactly what I thought. I think in our application it's probably better to drop data, or at least that's why things are more stable for us when RX is OFF. Or maybe we should just slow down a bit. Something to think about. On Fri, Jan 15, 2010 at 2:07 PM, Eric Blossom wrote: > On Fri, Jan 15, 2010 at 01:54:24PM -0500, Tom Gross wrote: >> >> I guess I could study the firmware source (if it's in the C code where >> this happens) to figure out what happens if RX is OFF. My assumption >> is that somewhere in the USRP2 code there is some recognition that it >> can't keep up with transmit data, thus causing it to send pause >> signals back to the ethernet controller (is that correct?). Maybe >> it's not in the firmware but built into some ethernet port controller >> chip. > > Actually, PAUSE handling is all handled in the FPGA. When the FIFO is > getting full, a PAUSE frame is sent on the wire telling the host to > stop sending for a while. > >> Or maybe my understanding of what RX ON/OFF does is completely wrong. >> :-) So, I guess I'm asking: as I understand it, the USRP2 sends pause >> packets (or something) to the ethernet controller when it can't keep >> up with data being sent to it. RX ON means that the controller will >> acknowledge these pause commands and stop sending data. Or have I got >> that completely backwards? > > In ethtool lingo, "Rx ON" means that the host will listen to the PAUSE > frames. This is what we want. Otherwise the host will continue > blasting away, and they'll get dropped somewhere along the way. "Tx > OFF" means that the host does not send PAUSE frames. This is what we > want. The USRP2 never listens to PAUSE frames, since it doesn't have > enough buffer to avoid an overrun. > > We're using "Asymmetric flow control". See also: > > http://grouper.ieee.org/groups/802/3/z/public/presentations/nov1996/asym.pdf > > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: WBX
On 01/15/2010 12:39 PM, Matt Ettus wrote: Yes, that one is actually designed by the same person as the one we sell. We could carry it as well if there were enough demand. Matt Something I wonder about FR4-based patch antennae is the loss factor. At the higher frequencies (above 500Mhz or so) FR4 becomes quite lossy, and I wonder about antenna structures fabricated using it. Anyone have any good data on this? Now, admittedly, I'm a weak-signals guy, and the loss for ordinary communications applications is negligible, I imagine. With the 15dB or better link margins in comms applications, the additional loss of a dB or two probably doesn't make that much difference. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] M-block integration status
On Fri, Jan 15, 2010 at 06:46:47PM +, Ben Gear wrote: > Hi Eric, > > Great to have an update on how the new features are progressing. > m-blocks and the replacement features have been mentioned a few times > on this mailing list in relation to building TDMA MACs. Having VRT > metadata available in gr blocks is going to give access to timestamps > for Rx samples; will we be able to specify tight timings for Tx using > the VRT headers in the same manner? In the git VRT code I've noticed > that the VRT header that is passed with the Tx data to the USRP > contains timing info. Is this used by the USRP at the moment, or is > it purely for the Rx side of things? The VRT frames transmitted to the USRP2 contain either no timestamp info, or they contain both the integer and fractional seconds timestamps. If they do not contain a timestamp, the frame is transmitted "now" in a FIFO manner. If a frame contains a timestamp and the "start of burst" flag is set, the frame is transmitted at that time. If a frame contains a timestamp, and the "start of burst" flag is not set, and we haven't "underrun" in the middle of the burst, the frame is enqueued into the FIFO. If a frame is late, it's dropped. The timestamps in the packets must be monotonically increasing. No in-FPGA rearrangement is done. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
On Fri, Jan 15, 2010 at 01:54:24PM -0500, Tom Gross wrote: > > I guess I could study the firmware source (if it's in the C code where > this happens) to figure out what happens if RX is OFF. My assumption > is that somewhere in the USRP2 code there is some recognition that it > can't keep up with transmit data, thus causing it to send pause > signals back to the ethernet controller (is that correct?). Maybe > it's not in the firmware but built into some ethernet port controller > chip. Actually, PAUSE handling is all handled in the FPGA. When the FIFO is getting full, a PAUSE frame is sent on the wire telling the host to stop sending for a while. > Or maybe my understanding of what RX ON/OFF does is completely wrong. > :-) So, I guess I'm asking: as I understand it, the USRP2 sends pause > packets (or something) to the ethernet controller when it can't keep > up with data being sent to it. RX ON means that the controller will > acknowledge these pause commands and stop sending data. Or have I got > that completely backwards? In ethtool lingo, "Rx ON" means that the host will listen to the PAUSE frames. This is what we want. Otherwise the host will continue blasting away, and they'll get dropped somewhere along the way. "Tx OFF" means that the host does not send PAUSE frames. This is what we want. The USRP2 never listens to PAUSE frames, since it doesn't have enough buffer to avoid an overrun. We're using "Asymmetric flow control". See also: http://grouper.ieee.org/groups/802/3/z/public/presentations/nov1996/asym.pdf Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] M-block integration status
On 01/15/2010 10:46 AM, Ben Gear wrote: Hi Eric, Great to have an update on how the new features are progressing. m-blocks and the replacement features have been mentioned a few times on this mailing list in relation to building TDMA MACs. Having VRT metadata available in gr blocks is going to give access to timestamps for Rx samples; will we be able to specify tight timings for Tx using the VRT headers in the same manner? In the git VRT code I've noticed that the VRT header that is passed with the Tx data to the USRP contains timing info. Is this used by the USRP at the moment, or is it purely for the Rx side of things? The vrt timing data is also used on the tx side. If you set the vrt time field bits and specify a time stamp in ticks and seconds you are essentially doing a "send_at" for usrp2 tx. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
We've tried it with and without a switch - definitely better without the switch. Thinking about our setup the behavior actually makes sense to me, although I'm waiting to discuss it with my signal processing guru. two usrp2s, connected with a mimo cable. the slave is just getting its clock from the master. the master is sampling, and sending data back to the host, which is also getting data from the slave, which is also sampling. usrp2 master is on eth0 (receive and transmit). usrp2 slave is on eth1. basically my flow graph in grc is pretty simple: two usrp2 sources feeding my custom block, which is doing some magic stuff and outputs a single channel to a single usrp2 sink (the master usrp2). I suspect that when RX is ON for eth0, the pause packets are causing the data going out on eth0 to back up, and the delay is worse (in terms of the algorithm running on the host) than the consequences of some data just being dropped on the floor, and never being transmitted. I guess I could study the firmware source (if it's in the C code where this happens) to figure out what happens if RX is OFF. My assumption is that somewhere in the USRP2 code there is some recognition that it can't keep up with transmit data, thus causing it to send pause signals back to the ethernet controller (is that correct?). Maybe it's not in the firmware but built into some ethernet port controller chip. Or maybe my understanding of what RX ON/OFF does is completely wrong. :-) So, I guess I'm asking: as I understand it, the USRP2 sends pause packets (or something) to the ethernet controller when it can't keep up with data being sent to it. RX ON means that the controller will acknowledge these pause commands and stop sending data. Or have I got that completely backwards? On Fri, Jan 15, 2010 at 1:12 PM, Eric Blossom wrote: > On Thu, Jan 14, 2010 at 10:11:38PM -0500, Tom Gross wrote: >> Following up on my previous email, thinking about this some more: >> >> I'm guessing that we are sending the USRP2 more data than it can >> handle, it is sending pause packets back, which when RX is ON, the >> ethernet card recognizes and slows down its output (not knowing >> anything about gig-e control flow but this sounds like x-on x-off), >> which causes our system to become unstable, BUT when we turn of RX on >> the ethernet device, it ignores the pause packets coming back from the >> USPR2, and keeps bombarding the USRP2 with transmitter data. >> >> so what happens if we ignore the pause packets? does the USRP2 drop >> packets on the floor and just output stuff as fast as it can? > > Tom, are there any switches between the host and the USRP2? > If so, try removing them. PAUSE frames and switches don't interact > well. > > I'm not sure I'm following the physical interconnection of the pieces. > Is this the set up? > > Does the host have two gig E ports? > Is there a dedicated cable between eth and USRP2 <1>? > Is there a dedicated cable between eth and USRP2 <2>? > The two USRP2's are connected with a MIMO cable? > > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] M-block integration status
Hi Eric, Great to have an update on how the new features are progressing. m-blocks and the replacement features have been mentioned a few times on this mailing list in relation to building TDMA MACs. Having VRT metadata available in gr blocks is going to give access to timestamps for Rx samples; will we be able to specify tight timings for Tx using the VRT headers in the same manner? In the git VRT code I've noticed that the VRT header that is passed with the Tx data to the USRP contains timing info. Is this used by the USRP at the moment, or is it purely for the Rx side of things? Many thanks, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
On Thu, Jan 14, 2010 at 10:11:38PM -0500, Tom Gross wrote: > Following up on my previous email, thinking about this some more: > > I'm guessing that we are sending the USRP2 more data than it can > handle, it is sending pause packets back, which when RX is ON, the > ethernet card recognizes and slows down its output (not knowing > anything about gig-e control flow but this sounds like x-on x-off), > which causes our system to become unstable, BUT when we turn of RX on > the ethernet device, it ignores the pause packets coming back from the > USPR2, and keeps bombarding the USRP2 with transmitter data. > > so what happens if we ignore the pause packets? does the USRP2 drop > packets on the floor and just output stuff as fast as it can? Tom, are there any switches between the host and the USRP2? If so, try removing them. PAUSE frames and switches don't interact well. I'm not sure I'm following the physical interconnection of the pieces. Is this the set up? Does the host have two gig E ports? Is there a dedicated cable between eth and USRP2 <1>? Is there a dedicated cable between eth and USRP2 <2>? The two USRP2's are connected with a MIMO cable? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: WBX
On 01/15/2010 07:32 AM, John Ewan wrote: Another antenna to look at. http://www.ramseyelectronics.com/cgi-bin/commerce.exe?preadd=action&key=LPY41 Yes, that one is actually designed by the same person as the one we sell. We could carry it as well if there were enough demand. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio and beagle board
Hi, I'm testing gnuradio with the beagle board. I'm using: - gnuradio 3.2.1 (with neon patch). - libusb-1.0-0 First, I've tried benchmark_dotprod_fff: # ./benchmark_dotprod_fff generic: taps: 256 input: 4e+07 cpu: 1119.820 taps/sec: 9.144e+06 cortex_a8: taps: 256 input: 4e+07 cpu: 43.391 taps/sec: 2.36e+08 (and I believe it is ok) Then, I've tried usrp_benchmark_usb, with very low performance: ./arm-angstrom-linux-gnueabi-usrp_benchmark_usb.py Testing 2MB/sec... [ 718.592163] usb 1-2: USB disconnect, address 2 [ 719.116760] usb 1-2: new high speed USB device using ehci-omap and address 3 [ 719.283386] usb 1-2: configuration #1 chosen from 1 choice gr_vmcircbuf_createfilemapping: createfilemapping is not available gr_vmcircbuf_sysv_shm: shmat (2): Invalid argument usb_throughput = 2M ntotal= 100 nright= 994162 runlength = 994162 delta = 5838 OK Testing 4MB/sec... usb_throughput = 4M ntotal= 200 nright= 1982575 runlength = 1982575 delta = 17425 OK Testing 8MB/sec... uUuUuUuUuOuOuOuOuOuOuOuOuOuOuOuOuOuOuOusb_throughput = 8M ntotal= 400 nright= 3720433 runlength = 22608 delta = 3977392 FAILED Testing 16MB/sec... uUuOuUuOuUuOuUuOuUuUuOuUuOuUuOuUuUuOuUuOuUuOuUuUuOuUuOuUuUuOuUuOuUuOuUM ntotal= 800 nright= 1934045 runlength = 0 delta = 800 FAILED Testing 32MB/sec... uUuOuUuOuUuOuUuUuOuUuOuUuOuUuUuOuUuOuUuOuUuUuOuUuOuUuOuUuUuOuUuOuUuOuUM ntotal= 1600 nright= 167550 runlength = 0 delta = 1600 FAILED Max USB/USRP throughput = 4MB/sec Do you have any suggestion? thanks andrea ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: WBX
It amazes me how much people will pay for a piece of FR-4 and an SMA connector. -Mark On Fri, Jan 15, 2010 at 10:32 AM, John Ewan wrote: > Another antenna to look at. > > > http://www.ramseyelectronics.com/cgi-bin/commerce.exe?preadd=action&key=LPY41 > > > > > > From: > discuss-gnuradio-bounces+jewan=its.bldrdoc@gnu.org[discuss-gnuradio-bounces+jewan= > its.bldrdoc@gnu.org] On Behalf Of Marcus D. Leech [mle...@ripnet.com] > Sent: Friday, January 15, 2010 12:10 AM > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Re: WBX > > On 01/15/2010 12:26 AM, Matt Ettus wrote: > > > > The Vert400 antenna will work well over several separate bands: > > > > 118-160MHz, 250-290MHz, > > 360-390MHz, 420-470MHz, 820-960MHz, 1260-1300MHz > > > > It will radiate but will not be optimal in areas outside of that. For > > this wide a bandwidth you could also look into a discone antenna. > > Radio shack and some other companies carry them. > > > > Matt > Here's a good discussion of the discone antenna: > > http://www.northcountryradio.com/Articles/discone.htm > > > > > ___ > 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Re: WBX
Another antenna to look at. http://www.ramseyelectronics.com/cgi-bin/commerce.exe?preadd=action&key=LPY41 From: discuss-gnuradio-bounces+jewan=its.bldrdoc@gnu.org [discuss-gnuradio-bounces+jewan=its.bldrdoc@gnu.org] On Behalf Of Marcus D. Leech [mle...@ripnet.com] Sent: Friday, January 15, 2010 12:10 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Re: WBX On 01/15/2010 12:26 AM, Matt Ettus wrote: > > The Vert400 antenna will work well over several separate bands: > > 118-160MHz, 250-290MHz, > 360-390MHz, 420-470MHz, 820-960MHz, 1260-1300MHz > > It will radiate but will not be optimal in areas outside of that. For > this wide a bandwidth you could also look into a discone antenna. > Radio shack and some other companies carry them. > > Matt Here's a good discussion of the discone antenna: http://www.northcountryradio.com/Articles/discone.htm ___ 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] "usleep" problem while executing "make" forgnuradio-3.1.3 on MSYS-MINGW
Shabbir Ahmed wrote: I have been trying to get GNURADIO installed on windows, failed with CYGWIN and then tried with MSYS/MINGW everything went fine until the last, while executing "make" for gnuradio. --- $ make make all-recursive make[1]: Entering directory `/usr/src/gnuradio-3.1.3' Making all in config make[2]: Entering directory `/usr/src/gnuradio-3.1.3/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/src/gnuradio-3.1.3/config' Making all in omnithread make[2]: Entering directory `/usr/src/gnuradio-3.1.3/omnithread' /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -DOMNITHREAD_NT=1 -DPthreadDraftVersion=10 -I/usr/src/gnuradio-3.1.3/omnithread -I/usr/local/include -g -O2 -Wall -Woverloaded-virtual -MT omni_time.lo -MD -MP -MF .deps/omni_time.Tpo -c -o omni_time.lo omni_time.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -DOMNITHREAD_NT=1 -DPthreadDraftVersion=10 -I/usr/src/gnuradio-3.1.3/omnithread -I/usr/local/include -g -O2 -Wall -Woverloaded-virtual -MT omni_time.lo -MD -MP -MF .deps/omni_time.Tpo -c omni_time.cc -DDLL_EXPORT -DPIC -o .libs/omni_time.o In file included from omni_time.cc:23: ../config.h: In function `int nanosleep(const timespec*, timespec*)': ../config.h:467: error: `usleep' was not declared in this scope ../config.h:467: warning: unused variable 'usleep' make[2]: *** [omni_time.lo] Error 1 make[2]: Leaving directory `/usr/src/gnuradio-3.1.3/omnithread' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/gnuradio-3.1.3' make: *** [all] Error 2 - It is a problem that was reported earlier ( http://old.nabble.com/Make-fail...config.h:467:-error:-'usleep'-was-not-declared-in-this-scope-td21246741.html) but no solution is posted in the link. I looked into the steps mentioned by Don. But couldnt get any leads. This problem (and others) are fixed in the latest development version (the git repository). I recommend that you install git under Cygwin and use that to download the latest code (per http://gnuradio.org/redmine/wiki/gnuradio/Download). You could also start with the 3.2.2 tarball (is there a reason you are using 3.1.3?) and add patches, but many of the quick patches (when done "right") are more than simple hand edits and require that you run ./bootstrap before they will take effect. For example, you can fix the usleep problem above by adding "#include " before the call to usleep in config.h, but that fix will go away the next time you run ./configure; patching config.h.in will fix that, but the right way is to patch config/gr_pwin32.m4 and rerun ./bootstrap and ./configure. In any case, you will need the following: * Before ./configure: export CXX="g++ -mthreads" export LDFLAGS="-L/usr/local/lib -lws2_32" If you want to try patching problems in 3.2.2: * If using Python 2.5, after running ./configure edit Makefile to add "-shrext .pyd" to PYTHON_LDFLAGS * In config.h and config.h.in, add "#include " before the call to usleep * In gnuradio-core/src/lib/missing, edit Makefile to remove references to posix_memalign * In gnuradio-core/src/lib/io, remove references to gr_histo_sink in Makefile.* and io.i * use "--disable-gr-msdd6000" on ./configure * If building usrp code, add "#include " near top of usrp/host/lib/db_wbxng.cc" I hope this helps. Eventually, this will all be documented in the wiki, but until then feel free to ask when you run into problems. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] OFDM modulation/demodulation over USRP2
Hi, I've tried the OFDM example on the USRP2 with minor changes and I didn't encounter any problems. Be sure that you have the same FFT-length, number of occupied tones, interpolation/decimation on both the receiver and transmitter. Have you tried to increase the distance between the transmitter and the receiver? Depending on your surrounding environment you may have to tweak the length of the CP. I have the same configuration as you, but I have the RFX2400 instead of the XCVR2450. Regards, Patrik Eliardsson > -Original Message- > From: > discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu.org > [mailto:discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu. > org] On Behalf Of Veljko Pejovic > Sent: Wednesday, January 13, 2010 10:22 PM > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] OFDM modulation/demodulation over USRP2 > > Hi, > > I'm using Ubuntu 9.10, gnuradio version 3.2.2 and two USRP2 > boards with XCVR2450 daughter boards. The boards are about a > meter apart from each other. > > I'm trying to get OFDM working over USRP2 boards and for that > I'm using GRC. I created a simple local loop (without USRPs): > signal_source->modulation->channel_model->demodulation->scope_ > sink. In this case OFDM modulation/demodulation works fine. > However, when I split the loop into a sender > signal_source->modulation->usrp2_sink and a receiver: > usrp2_src->demodulation->scope_sink the decoding does not > work, i.e. I don't get any output on the scope_sink. > Although, FFT of the usrp2_src output looks exactly like what > OFDM should look like. > I'm pretty sure that the error is connected to OFDM as I got > this transmitter/receiver pair working with GMSK, for example. > > I also tried the examples in > gnuradio-3.2.2/gnuradio-examples/python/ofdm which I had to > tweak a bit in order to get them using USRP2, but I got the > same results: > there is an OFDM-like signal in the air, but it's not getting decoded. > > Did anyone got OFDM demodulation working on USRP2? If so, any > hints are highly appreciated. > > Thanks, > > > Veljko > > > ___ > 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] "usleep" problem while executing "make" for gnuradio-3.1.3 on MSYS-MINGW
Hi ALL: I have been trying to get GNURADIO installed on windows, failed with CYGWIN and then tried with MSYS/MINGW everything went fine until the last, while executing "make" for gnuradio. --- $ make make all-recursive make[1]: Entering directory `/usr/src/gnuradio-3.1.3' Making all in config make[2]: Entering directory `/usr/src/gnuradio-3.1.3/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/src/gnuradio-3.1.3/config' Making all in omnithread make[2]: Entering directory `/usr/src/gnuradio-3.1.3/omnithread' /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -DOMNITHREAD_NT=1 -DPthreadDraftVersion=10 -I/usr/src/gnuradio-3.1.3/omnithread -I/usr/local/include -g -O2 -Wall -Woverloaded-virtual -MT omni_time.lo -MD -MP -MF .deps/omni_time.Tpo -c -o omni_time.lo omni_time.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -DOMNITHREAD_NT=1 -DPthreadDraftVersion=10 -I/usr/src/gnuradio-3.1.3/omnithread -I/usr/local/include -g -O2 -Wall -Woverloaded-virtual -MT omni_time.lo -MD -MP -MF .deps/omni_time.Tpo -c omni_time.cc -DDLL_EXPORT -DPIC -o .libs/omni_time.o In file included from omni_time.cc:23: ../config.h: In function `int nanosleep(const timespec*, timespec*)': ../config.h:467: error: `usleep' was not declared in this scope ../config.h:467: warning: unused variable 'usleep' make[2]: *** [omni_time.lo] Error 1 make[2]: Leaving directory `/usr/src/gnuradio-3.1.3/omnithread' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/gnuradio-3.1.3' make: *** [all] Error 2 - It is a problem that was reported earlier ( http://old.nabble.com/Make-fail...config.h:467:-error:-'usleep'-was-not-declared-in-this-scope-td21246741.html) but no solution is posted in the link. I looked into the steps mentioned by Don. But couldnt get any leads. Please help! regards. -- Shabbir Ahmed PhD. Student Centre for Telecommunications and Microelectronics Victoria University Email: shabbir.ah...@live.vu.edu.au ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
