[Discuss-gnuradio] small build problem with gnuradio (git) on ubuntu 9.10 (64bit)
I've just installed gnuradio (git) on ubuntu 9.10 64-bit and ran into this small problem where waterfallGlobalData.h would have the following error ./gnuradio/gr-qtgui/src/lib/waterfallGlobalData.h: ISO C++ forbids declaration of ‘uint64_t’ with no type I had to include the following to make it compile: waterfallGlobalData.h: #include gr, marcel maatkamp ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Interest in 2.0-2.5 GHz transceiver
I am looking to gauge interest in a 2.0 to 2.5 GHz transceiver daughterboard, based on the RFX-series, populated with some different parts. This would cover some satellite bands which are not covered by our other daughterboards. Please send me an email off-list if this would be of interest to you. If you could tell me how many you think you might want, that would be helpful in determining if we move forward on this. Thanks, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Custom block problem on OSX 10.6
Hi Kunal - I can't directly address the question of whether or not custom blocks work on OSX 10.6 x86_64, since I've never compiled by custom blocks under that OS (yet). I need to do some 10.6 x64 work anyway, so I'll try out my blocks later today & see what happens. Not sure if this makes any difference, but one of the errors seems to be: File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/ gnuradio_swig_py_runtime.py", line 1487, in connect return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(self, *args) NotImplementedError: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'. Possible C/C++ prototypes are: connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr) connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr,int,gr_basic_block_sptr,int) so ... maybe in your QA code you're creating a bad connection? If you go back to 10.5 32-bit, does your custom block work correctly? - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] small build problem with gnuradio (git) on ubuntu 9.10 (64bit)
On Sat, Feb 20, 2010 at 02:51, Marcel Maatkamp wrote: > I've just installed gnuradio (git) on ubuntu 9.10 64-bit and ran into this > small problem where waterfallGlobalData.h would have the following error > ./gnuradio/gr-qtgui/src/lib/waterfallGlobalData.h: > ISO C++ forbids declaration of ‘uint64_t’ with no type > I had to include the following to make it compile: > waterfallGlobalData.h: #include Can you confirm which version of gcc you are using? I have a number of machines in the above configuration, using stock gcc 4.4.1, and can't replicate this. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] packet interarrival time
I narrowed down the problem to this: - In a standard benchmark_rx.py example from "digital" immediately after a packet is received the callback is triggered. - In the ofdm case the the callback is triggered in groups separated by one second. So, if a sender sends a bunch of packets they will be buffered at the receiver (or perhaps at the sender?) and then the callback is issued sequentially for each of the packets in that group. Then, after a one second gap, another group of packets will be processed. I checked the times of when "msg = self.rcvd_pktq.delete_head()" from ofdm.py is called and confirmed the above. Sometimes it waits for a second, and then it gets fired in a number of bursts corresponding to the number of pkts received. Is there a way to force the receiver to wait for less then a second? Or is it the sender that buffers the packets? Although, it doesn't look like that from my measurements. Thanks, Veljko 2010/2/12 Veljko Pejovic : > Hi Eric, > > 2010/2/12 Eric Blossom : >> On Fri, Feb 12, 2010 at 12:52:00PM -0800, Veljko Pejovic wrote: >>> Hi, >>> >>> I'm using two USRP2 with XCVR2450s, gnuradio 3.2.2 and Ubuntu 9.10. >>> >>> I ran the benchmark_tx/rx example from gnuradio-examples/ofdm and >>> measured packet inter-arrival times at the receiver. I also modified >>> the sender to wait for some time (like 200ms) between individual >>> packets. I also set the msg queue size to one. In python code I'm >>> printing a bunch of time.time() values to keep the timeline of the >>> events. >>> >>> What I observe is the following: >>> - inter-departure times are constant, the packet size and the bit rate >>> would of course influence the time spent sending, but that would still >>> be a relatively small value. >>> - at the receiver, most packets are received with the inter-arrival >>> time comparable to the inter-departure time at the sender, however, >>> occasionally I would see a huge lag between two consecutive packets >>> (almost a second). >>> >>> I read the NSDI'09 paper >>> (http://portal.acm.org/citation.cfm?id=1558984) that talks about USRP1 >>> performance, however, what I observe is way higher delay and it's >>> USRP2. Thus, I'm sure that there's something I can do to fix this >>> delay. Any hints? >> >> Are packets getting dropped? > > I don't get any overruns/underruns reported, but, yes, there's some > packet loss. However, I'm only considering the interarrival time of > those packets with consecutive packet numbers. > >> Is the USRP2 on a dedicated ethernet port? > > yes, it is. > >> Is there a switch between the host and the USRP2? > > no > >> >> Eric >> > > cheers > > Veljko > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] small build problem with gnuradio (git) on ubuntu 9.10 (64bit)
The versions are: mar...@asrock-ubuntu-01:~$ gcc --version gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 mar...@asrock-ubuntu-01:~$ uname -a Linux asrock-ubuntu-01 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux The machine was freshly installed yesterday with ubuntu 9,10 with nothing more than a 'apt-get dist-upgrade' and the packages mentioned on the gnuradio.org/howtobuild page. gr, marcel 2010/2/20 Johnathan Corgan > On Sat, Feb 20, 2010 at 02:51, Marcel Maatkamp > wrote: > > > I've just installed gnuradio (git) on ubuntu 9.10 64-bit and ran into > this > > small problem where waterfallGlobalData.h would have the following error > > ./gnuradio/gr-qtgui/src/lib/waterfallGlobalData.h: > > ISO C++ forbids declaration of ‘uint64_t’ with no type > > I had to include the following to make it compile: > > waterfallGlobalData.h: #include > > Can you confirm which version of gcc you are using? I have a number > of machines in the above configuration, using stock gcc 4.4.1, and > can't replicate this. > > Johnathan > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
Hi Tom, I tried increasing the bandwidth of the filter and also tried changing the window type to KAISER, but it didn't improve on the offset error. I am getting a constant frequency offset value "-10". Currently, I am just compensating for the offset at the receiver or specifying a minimum BW to be used for that pair of USRP2s. Thanks a lot for your time. Srinivas On Thu, Feb 18, 2010 at 9:45 AM, Tom Rondeau wrote: > On Thu, Feb 18, 2010 at 12:49 AM, Srinivas wrote: > > Hi Tom, Matt > > > > replied inline: > > > > On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau > > wrote: > >> > >> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas > wrote: > >> > Matt, > >> > > >> > Thanks for verifying the data rate calculation! > >> > > >> > I tried the other solutions that you suggested, namely, > >> > > >> > - increasing the data rate by a factor of 2 or 4 > >> > It works. > >> > > >> > - modifying the OFDM code to widen the search range - How do I widen > the > >> > search range ? > >> > Should I be looking in the "ofdm_sync_" blocks in "blks2impl" folder ? > >> > If > >> > yes, which synchronizer is currently used with ofdm_examples ? > >> > >> You need to add an argument to gr.ofdm_frame_acquisition in > >> ofdm_receiver.py (in python/gnuradio/blks2impl). > >> > >> In the current Git master, this is located on line 109 of > >> ofdm_receiver.py. After the "ks[0]" argument, you can put in an > >> integer. This is the maximum number of bins the receiver will search > >> over for correlation. It defaults to 10. > >> > > I added this extra argument and tried changing the values from 10 to 100. > I > > also tried with "int(0.5*occupied_tones) " as the argument, but it > doesn't > > receive for lower data rates (< 1M). Only when I increase the data rate > > > 1.2M, I start receiving some pkts. > > > > As mentioned before, when I compensate for the frequency offset at the > > receiver it starts receiving packets successfully too. > > For small bandwidths, it's possible that the frequency offset has > pushed you outside of the channel filter. The filter is probably > specified too tight and is really supposed to cover only the occupied > tones, so if you're too far away from the center frequency, the > filter's already hitting it and no amount of frequency correction > after that will work. > > In ofdm_receiver.py, try making the bandwidth term (bw on line 66) > wider and see what that does for you. > > Also, you can print out d_coarse_freq calculated on line 130 in > gr_ofdm_frame_acquisition.cc. This is the number of bins you're off by > that you can use to get a feel for how far away in frequency you are. > > If opening up the filter works for you, please let us know. We might > want to either parameterize the bandwidth or just set it wider by > default. > > Tom > -- Srinivas WINLAB, Rutgers University New Jersey ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Custom block problem on OSX 10.6
Hi Michael, Thanks for looking into it. I don't have access to a 10.5 32-bit machine to test it out on at the moment (is there anything I can do with the configuration?) However, I had built and tested my code on a 10.5 32-bit machine, and it worked fine then. I have not changed the code itself since I moved to the new Snow Leopard machine, but I did have to play with the configuration to get it to compile. Basically I had to force a 64-bit build, and override pkg-config to get Makefile to use the macports gnuradio install. This is the configure command I ran in my custom block directory: ./configure --build=i686-apple-darwin10 --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 LDFLAGS=-L/opt/local/lib CFLAGS=-I/usr/include/python2.6 CXXFLAGS=-I/usr/include/python2.6 --with-pythondir=/opt/local/lib/python2.6/site-packages GNURADIO_CORE_INCLUDEDIR=/opt/local/include/gnuradio GNURADIO_CORE_LIBS=/opt/local/lib I had the same error for howto-write-a-block (with the same configure command) as I did my custom block, so I suspect a problem in the install or my configuration. Kunal On Sat, Feb 20, 2010 at 2:03 PM, Michael Dickens wrote: > Hi Kunal - I can't directly address the question of whether or not custom > blocks work on OSX 10.6 x86_64, since I've never compiled by custom blocks > under that OS (yet). I need to do some 10.6 x64 work anyway, so I'll try > out my blocks later today & see what happens. > > Not sure if this makes any difference, but one of the errors seems to be: > > > File >> "/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", >> line 1487, in connect >>return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(self, *args) >> NotImplementedError: Wrong number of arguments for overloaded function >> 'gr_top_block_sptr_connect'. >> Possible C/C++ prototypes are: >>connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr) >>connect(boost::shared_ptr< gr_top_block > >> *,gr_basic_block_sptr,int,gr_basic_block_sptr,int) >> > > so ... maybe in your QA code you're creating a bad connection? > > If you go back to 10.5 32-bit, does your custom block work correctly? > > - MLD > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Lost packet problem
I think the problem was the high bit rate. my bit rate was 100K when i decrease it to 10K the lost packets can be recovered safely. I think that there is overflowing in the USRP, which cause the missing of access code. therefore i miss the packets. I'll try what you have said in the first post. thanks for your help Tom Rondeau wrote: > > On Fri, Feb 19, 2010 at 12:50 AM, abbasi > wrote: >> >> Thanks a lot for your reply, >> sorry for my bad english... >> >> >> Tom Rondeau wrote: >>> >>> >>> Which modulation are you using? Are you using the >>> digita/benchmark_*.py files or is this OFDM. I'm not quite getting >>> what you mean when you're talking about the PN code (which makes it >>> sound like the OFDM code we have in the examples). >>> >>> >> >> I'm using dbpsk, through a file based on tunnel.py. >> As far as i know, the receiver is using gr_correlate_access_code_bb to >> slide >> the given access code (usually an M-sequence) across the demodulated >> bits, >> and produces two bits of output for each input bit. This is done for >> synchronization. > > The access code correlator is just there to determine when the packet > start happens by looking for the preamble access code. I'm not sure if > this is what you mean by synchronization. I just always think of > synchronization in the symbol domian; that is, it does the frequency, > phase, and timing synchronization to be able to slice the symbols into > bits. > >> Tom Rondeau wrote: >>> >>> Sorry, I'm really not understanding what you're doing. Are you >>> checking the CRC and sending an ACK if the CRC doesn't check out? If >>> so, that requires that you get enough good bits of the packet through >>> to first detect that it's a packet and then be able to parse it. If >>> you miss the header and length fields, you won't be able to see the >>> CRC. >>> >> >> i check the CRC, if it returns correct i send ACK, if it is not correct i >> send LOST-ACK, > > Yeah, ok. But like I said, I really don't think this is a very good > way to determine when a packet is missed since this will only work > when at least most of the packet has been received. If a packet is > corrupted in the header or access code such that it is completely > overlooked by the demodulator, you'll never know it with just an > ACK/NACK scheme. > >> Tom Rondeau wrote: >>> >>> This is usually solved, like in TCP, with a sequence number. You can >>> tell if you missed a packet because the sequence numbers from two >>> consecutive packets received will not match up. This way, the receiver >>> can completely drop a packet and still know it after then next packet >>> arrives. >>> >> >> I understand what are you saying. but the point is there any scheme >> (already >> implemented in GNURADIO) which solve this problem. or i have to do it >> manually? >> >> regards, > > There has been some work done on MAC layer implementation in GNU > Radio, but there is nothing in the main repo that will do what you > want. > > Tom > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/Lost-packet-problem-tp27637608p27672856.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
