[Discuss-gnuradio] OFDM Receiver
Hi, I am referring the built in example of gnuradio companion ( rx_ofdm.grc). In which I replace random source with usrp source. on Transmetter side I am sending some bits and in receiver flow graph (rx_ofdm ) I am facing problem where I have to attach file sink to get these bits. I attached *File sink block* after *bits repack* block but I did not get any data in file. I also have attached *File sink after stream CRC32 block but* I did not get data in file. Kindly inform if possible where I have to attach file sink in flow graph to get receiving bits. Here is an Attached flow graph modified form of (rx_ofdm) Thanks in anticipation. finaloftm_rx.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver
Hi Muhammad, sadly, it's not very clear what you're asking about. * Which flow graph are you referring to? * What is your precise problem, and what have you tried to solve it so far? How can we help you with that? Best regards, Marcus On 02/22/2017 02:05 PM, MUHAMMAD AHMAD wrote: > How can I receive bits using file sink in ofdm receiver. > where I have to connect file sink in flow graph of ofdm receiver? > either bits repack block output can give bits? > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM receiver
How can I receive bits using file sink in ofdm receiver. where I have to connect file sink in flow graph of ofdm receiver? either bits repack block output can give bits? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver error, FATAL: Missing a required length tag on port 0 at item #0
Hi, thank you for your response. In fact, I still have the same error: FATAL: Missing a required length tag on port 0 at item #0 thread[thread-per-block[21]: gr_block crc 32_bb (9)]: Missing length tag. and UOO I put the usrp sink and usrp source 's sample rate to 1M. What is the suitable sampling rate to put ? Thanks in advance 2014-06-30 16:36 GMT+02:00 Philip Balister phi...@balister.org: On 06/30/2014 09:20 AM, Wafa Elhajhmida wrote: Hi, I implemented OFDM receiver on USRP E110 using the OFDM receiver in examples in gnuradio's files 3.7 and I added to it a chain to create OFDM transmitter: random source, OFDM transmitter, channel model, throttle, USRP sink But when I executed the flow graph. It generated UOO and I got an error : Slow the data rate until this message stops. Then worry about the next message. Philip FATAL: Missing a required length tag on port 0 at item #0 thread[thread-per-block[21]: gr_block crc 32_bb (9)]: Missing length tag. and tag debug didn't show anything. Have you an idea how to fix this error ? Thanks in advance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM receiver error, FATAL: Missing a required length tag on port 0 at item #0
Hi, I implemented OFDM receiver on USRP E110 using the OFDM receiver in examples in gnuradio's files 3.7 and I added to it a chain to create OFDM transmitter: random source, OFDM transmitter, channel model, throttle, USRP sink But when I executed the flow graph. It generated UOO and I got an error : FATAL: Missing a required length tag on port 0 at item #0 thread[thread-per-block[21]: gr_block crc 32_bb (9)]: Missing length tag. and tag debug didn't show anything. Have you an idea how to fix this error ? Thanks in advance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver error, FATAL: Missing a required length tag on port 0 at item #0
On 06/30/2014 03:20 PM, Wafa Elhajhmida wrote: FATAL: Missing a required length tag on port 0 at item #0 thread[thread-per-block[21]: gr_block crc 32_bb (9)]: Missing length tag. Add a stream to tagged stream converter. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
On Mon, Jan 17, 2011 at 7:58 PM, Guanbo gbzh...@gmail.com wrote: Hi, I feel like the output of coarse frequency offset is very inaccurate. Or probably it is not directly related. For best test, I tried higher resolution of subcarrier bandwidth by selecting the large FFT length, high Interp/decim rate, as follows: @TX: $ sudo python benchmark_ofdm_tx_new.py --mac-addr=ADD -m qpsk -f 2.462G -i 512 --tx-gain=30 --fft-length=2048 --occupied-tones=200 @RX: $ sudo python benchmark_ofdm_rx_new.py --mac-addr=ADD -m qpsk -f 2.462G -d 512 --rx-gain=30 --fft-length=2048 --occupied-tones=200 From ofdm_frame_acquisition.cc, I can output d_coarse_freq. Therefore, I can calculate the coarse frequency offset by: (ADC rate / Decim rate / FFT_len) * d_coarse_freq But the results I have obtained does not match the real frequency offset. From the command above, I obtained the d_coarse_freq = 2 -- 190 Hz By moving the RX center frequency to 2.46202G (20KHz offset), the output d_coarse_freq is -64 -- -6103Hz I tried to look into the problem by changing the filter BW line 66-68 of ofdm_receiver.py, as well as shift length at line 109. But they does not work out. Would anyone can help to explain the problem here? Really appreciate :) Thanks, Guanbo I know this doesn't directly answer your question, but I know that Matt and I performed the exact same tests when we developed the OFDM code to make sure that the coarse frequency offset followed the input frequency offset that we used. So if one subcarrier in your case is ~95 Hz, we could easily track the coarse frequency offset output and match up our results. One problem that you seem to have is that a 20 kHz is completely outside your channel. If I've done my math correctly, 20 kHz is almost 210 subcarriers and you are only using 200, so you are out of the receiver's channel by about 110 bins. Tom Tom Rondeau wrote: On 2/20/2010 7:43 PM, Srinivas wrote: 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 Changing the window type isn't going to help much with this problem. What I was suggesting was that the filter is too small, not the wrong type. Also, the only way to change the offset value is to actually move the frequency. I was just suggesting that you see what that value is to see how many bins you are off by (i.e., calculate the bandwidth of a subcarrier and multiply that by 10; that's you're coarse offset). You can use that to see how much bigger to make the channel filter's bandwidth. Tom On Thu, Feb 18, 2010 at 9:45 AM, Tom Rondeau trondeau1...@gmail.com mailto:trondeau1...@gmail.com wrote: On Thu, Feb 18, 2010 at 12:49 AM, Srinivas psriniva...@gmail.com mailto:psriniva...@gmail.com wrote: Hi Tom, Matt replied inline: On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau trondeau1...@gmail.com mailto:trondeau1...@gmail.com wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com mailto:psriniva...@gmail.com 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
Re: [Discuss-gnuradio] OFDM receiver on USRP2
Hi, I feel like the output of coarse frequency offset is very inaccurate. Or probably it is not directly related. For best test, I tried higher resolution of subcarrier bandwidth by selecting the large FFT length, high Interp/decim rate, as follows: @TX: $ sudo python benchmark_ofdm_tx_new.py --mac-addr=ADD -m qpsk -f 2.462G -i 512 --tx-gain=30 --fft-length=2048 --occupied-tones=200 @RX: $ sudo python benchmark_ofdm_rx_new.py --mac-addr=ADD -m qpsk -f 2.462G -d 512 --rx-gain=30 --fft-length=2048 --occupied-tones=200 From ofdm_frame_acquisition.cc, I can output d_coarse_freq. Therefore, I can calculate the coarse frequency offset by: (ADC rate / Decim rate / FFT_len) * d_coarse_freq But the results I have obtained does not match the real frequency offset. From the command above, I obtained the d_coarse_freq = 2 -- 190 Hz By moving the RX center frequency to 2.46202G (20KHz offset), the output d_coarse_freq is -64 -- -6103Hz I tried to look into the problem by changing the filter BW line 66-68 of ofdm_receiver.py, as well as shift length at line 109. But they does not work out. Would anyone can help to explain the problem here? Really appreciate :) Thanks, Guanbo Tom Rondeau wrote: On 2/20/2010 7:43 PM, Srinivas wrote: 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 Changing the window type isn't going to help much with this problem. What I was suggesting was that the filter is too small, not the wrong type. Also, the only way to change the offset value is to actually move the frequency. I was just suggesting that you see what that value is to see how many bins you are off by (i.e., calculate the bandwidth of a subcarrier and multiply that by 10; that's you're coarse offset). You can use that to see how much bigger to make the channel filter's bandwidth. Tom On Thu, Feb 18, 2010 at 9:45 AM, Tom Rondeau trondeau1...@gmail.com mailto:trondeau1...@gmail.com wrote: On Thu, Feb 18, 2010 at 12:49 AM, Srinivas psriniva...@gmail.com mailto:psriniva...@gmail.com wrote: Hi Tom, Matt replied inline: On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau trondeau1...@gmail.com mailto:trondeau1...@gmail.com wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com mailto:psriniva...@gmail.com 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
Re: [Discuss-gnuradio] OFDM receiver on USRP2
On Wed, Jan 12, 2011 at 7:36 PM, Guanbo gbzh...@gmail.com wrote: Hi, Tom I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/. What is the difference between frequency synchronization and carrier frequency offset. Why we have to do the timing and frequency synchronization before it? Thanks, Guanbo There is the difference between the fine frequency tuning (centering the signal inside of a subcarrier) and coarse frequency tunning (making sure that subcarrier 0 is at the correct location). The ofdm_sync_xx blocks perform the timing and fine frequency calculations (the self.nco in ofdm_receiver.py is generated from the fine frequency offset from the sync block). This is required before being able to perform the FFT demo, or else you'll get inter-carrier interference. We can then go into the frequency domain (after the FFT) and work on the subcarrier bins to handle the coarse frequency offset, since it is easier to do in this domain. Tom Tom Rondeau wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com 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. - locking the usrps to a common reference My usrp2s are located wide apart so I guess this solution is not practical. Besides, this confirms that the problem is somewhere in the USRP2 board, right ? (as I tried swapping the daughter cards firmware with the working pair) Thanks, Srinivas Nope, this is typical of radio hardware. They are always off frequency. If two oscillators are off frequency and then multiplied up to another frequency, the difference will also be magnified. So a 2.4 GHz board will have a larger frequency offset than if you ran it just through the BasicTx/Rx boards (even though the ratios should be the same). 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/OFDM-receiver-on-USRP2-tp27557644p30658514.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
Thanks Tom. I tried to see how much the carrier frequency offset would be. As you suggested above, I output the coarse freq offset bins, which was similar as Srinivas's result. It is constant -2. Does it means the carrier offset can be computed as: ADC rate /( Decim_rate * FFT_len) * 2 ? If so, in my case, it is around 4KHz. From my knowledge, it seems too good to be true. From your reference, I put on the channel filter code: -- bw = (float(occupied_tones) / float(fft_length)) / 2.0 tb = bw*0.08 chan_coeffs = gr.firdes.low_pass (1.0, # gain 1.0, # sampling rate bw+tb, # midpoint of trans. band tb, # width of trans. band gr.firdes.WIN_HAMMING) # filter type self.chan_filt = gr.fft_filter_ccc(1, chan_coeffs) win = [1 for i in range(fft_length)] -- Also, my hardware is USRP2+ XCVR2450. $ sudo python benchmark_ofdm_tx_new.py --mac-addr= -f 2.462G -m qpsk -i 100 --tx-gain=30 -M 8 -s 1000 FFT_len = 512 (default) occupie_tones=200 Tom Rondeau wrote: On Wed, Jan 12, 2011 at 7:36 PM, Guanbo gbzh...@gmail.com wrote: Hi, Tom I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/. What is the difference between frequency synchronization and carrier frequency offset. Why we have to do the timing and frequency synchronization before it? Thanks, Guanbo There is the difference between the fine frequency tuning (centering the signal inside of a subcarrier) and coarse frequency tunning (making sure that subcarrier 0 is at the correct location). The ofdm_sync_xx blocks perform the timing and fine frequency calculations (the self.nco in ofdm_receiver.py is generated from the fine frequency offset from the sync block). This is required before being able to perform the FFT demo, or else you'll get inter-carrier interference. We can then go into the frequency domain (after the FFT) and work on the subcarrier bins to handle the coarse frequency offset, since it is easier to do in this domain. Tom Tom Rondeau wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com 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. - locking the usrps to a common reference My usrp2s are located wide apart so I guess this solution is not practical. Besides, this confirms that the problem is somewhere in the USRP2 board, right ? (as I tried swapping the daughter cards firmware with the working pair) Thanks, Srinivas Nope, this is typical of radio hardware. They are always off frequency. If two oscillators are off frequency and then multiplied up to another frequency, the difference will also be magnified. So a 2.4 GHz board will have a larger frequency offset than if you ran it just through the BasicTx/Rx boards (even though the ratios should be the same). 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/OFDM-receiver-on-USRP2-tp27557644p30658514.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 ___ 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/OFDM-receiver-on-USRP2-tp27557644p30669471.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
Re: [Discuss-gnuradio] OFDM receiver on USRP2
Hi, Tom I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/. What is the difference between frequency synchronization and carrier frequency offset. Why we have to do the timing and frequency synchronization before it? Thanks, Guanbo Tom Rondeau wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com 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. - locking the usrps to a common reference My usrp2s are located wide apart so I guess this solution is not practical. Besides, this confirms that the problem is somewhere in the USRP2 board, right ? (as I tried swapping the daughter cards firmware with the working pair) Thanks, Srinivas Nope, this is typical of radio hardware. They are always off frequency. If two oscillators are off frequency and then multiplied up to another frequency, the difference will also be magnified. So a 2.4 GHz board will have a larger frequency offset than if you ran it just through the BasicTx/Rx boards (even though the ratios should be the same). 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/OFDM-receiver-on-USRP2-tp27557644p30658514.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
Re: [Discuss-gnuradio] OFDM receiver on USRP2
Hi, Tom I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/. What is the difference between frequency synchronization and carrier frequency offset. Why we have to do the timing and frequency synchronization before it? Also, Thanks, Guanbo Tom Rondeau wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com 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. - locking the usrps to a common reference My usrp2s are located wide apart so I guess this solution is not practical. Besides, this confirms that the problem is somewhere in the USRP2 board, right ? (as I tried swapping the daughter cards firmware with the working pair) Thanks, Srinivas Nope, this is typical of radio hardware. They are always off frequency. If two oscillators are off frequency and then multiplied up to another frequency, the difference will also be magnified. So a 2.4 GHz board will have a larger frequency offset than if you ran it just through the BasicTx/Rx boards (even though the ratios should be the same). 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/OFDM-receiver-on-USRP2-tp27557644p30658519.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
Re: [Discuss-gnuradio] OFDM receiver on USRP2
Sorry for bringing up an old thread. I was having the same problem of not receiving packets using benchmark_ofdm_* and changing the receiver frequency to tune to the transmitter frequency indeed solved the problem. However, if I have to manually do it every time, I don't see how I can get ofdm tunnel to work. In tunnel, each USRP is both transmitter and receiver. The frequency offset of one USRP (A) transmitting to the other (B) will be different than B transmitting to A. Since the frequency offset can't be set at run time, I don't see how to manually tune after running tunnel on both USRPs. Can anyone show me how to make tunnel work? Thank you very much, Tuan On 2/20/2010 7:43 PM, Srinivas wrote: 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 Changing the window type isn't going to help much with this problem. What I was suggesting was that the filter is too small, not the wrong type. Also, the only way to change the offset value is to actually move the frequency. I was just suggesting that you see what that value is to see how many bins you are off by (i.e., calculate the bandwidth of a subcarrier and multiply that by 10; that's you're coarse offset). You can use that to see how much bigger to make the channel filter's bandwidth. Tom On Thu, Feb 18, 2010 at 9:45 AM, Tom Rondeau addr...@hidden wrote: On Thu, Feb 18, 2010 at 12:49 AM, Srinivas addr...@hidden wrote: Hi Tom, Matt replied inline: On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau addr...@hidden wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas addr...@hidden 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] OFDM receiver on USRP2
On 2/20/2010 7:43 PM, Srinivas wrote: 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 Changing the window type isn't going to help much with this problem. What I was suggesting was that the filter is too small, not the wrong type. Also, the only way to change the offset value is to actually move the frequency. I was just suggesting that you see what that value is to see how many bins you are off by (i.e., calculate the bandwidth of a subcarrier and multiply that by 10; that's you're coarse offset). You can use that to see how much bigger to make the channel filter's bandwidth. Tom On Thu, Feb 18, 2010 at 9:45 AM, Tom Rondeau trondeau1...@gmail.com mailto:trondeau1...@gmail.com wrote: On Thu, Feb 18, 2010 at 12:49 AM, Srinivas psriniva...@gmail.com mailto:psriniva...@gmail.com wrote: Hi Tom, Matt replied inline: On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau trondeau1...@gmail.com mailto:trondeau1...@gmail.com wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com mailto:psriniva...@gmail.com 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] 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 trondeau1...@gmail.com wrote: On Thu, Feb 18, 2010 at 12:49 AM, Srinivas psriniva...@gmail.com wrote: Hi Tom, Matt replied inline: On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com 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] OFDM receiver on USRP2
On Thu, Feb 18, 2010 at 12:49 AM, Srinivas psriniva...@gmail.com wrote: Hi Tom, Matt replied inline: On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com 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. - locking the usrps to a common reference My usrp2s are located wide apart so I guess this solution is not practical. Besides, this confirms that the problem is somewhere in the USRP2 board, right ? (as I tried swapping the daughter cards firmware with the working pair) Thanks, Srinivas Nope, this is typical of radio hardware. They are always off frequency. If two oscillators are off frequency and then multiplied up to another frequency, the difference will also be magnified. So a 2.4 GHz board will have a larger frequency offset than if you ran it just through the BasicTx/Rx boards (even though the ratios should be the same). Tom ___ 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, Matt replied inline: On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau trondeau1...@gmail.comwrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com 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. - locking the usrps to a common reference My usrp2s are located wide apart so I guess this solution is not practical. Besides, this confirms that the problem is somewhere in the USRP2 board, right ? (as I tried swapping the daughter cards firmware with the working pair) Thanks, Srinivas Nope, this is typical of radio hardware. They are always off frequency. If two oscillators are off frequency and then multiplied up to another frequency, the difference will also be magnified. So a 2.4 GHz board will have a larger frequency offset than if you ran it just through the BasicTx/Rx boards (even though the ratios should be the same). Tom Thanks! I understand this now. -- 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] OFDM receiver on USRP2
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 ? *- locking the usrps to a common reference *My usrp2s are located wide apart so I guess this solution is not practical. Besides, this confirms that the problem is somewhere in the USRP2 board, right ? (as I tried swapping the daughter cards firmware with the working pair) Thanks, Srinivas On Sun, Feb 14, 2010 at 3:25 AM, Matt Ettus m...@ettus.com wrote: That formula will give you the number of occupied tones per second. You need to multiply by the number of bits per tone to get bps. If you are using BPSK, multiply by 1. If using QPSK, you'll need to multiply by 3, 8PSK by 3, etc. I meant to say: BPSK - multiply by 1 QPSK - mult by 2 (not 3 like I said above) 8PSK - mult by 3 sorry for the confusion. Matt -- 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] OFDM receiver on USRP2
On 02/16/2010 02: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 ? *- locking the usrps to a common reference *My usrp2s are located wide apart so I guess this solution is not practical. Besides, this confirms that the problem is somewhere in the USRP2 board, right ? (as I tried swapping the daughter cards firmware with the working pair) No, this confirms that there is no problem. Frequency offset is a natural part of radio systems. The software needs to handle it properly. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
On 02/12/2010 03:53 PM, Srinivas wrote: Matt, There was a frequency offset of ~30 KHz at the Rx w.r.t Tx so I compensated for it and it worked!. The settings I am using is as follows: ./benchmark_ofdm_tx.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk --fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128 ./benchmark_ofdm_rx.py -f 2.45G -m bpsk --fft-length=512 --occupied-tones=80 -d 64 --rx-gain=20 --cp-length=128 I calculate the data-rate for OFDM as follows Data rate R = (ADC sampling rate x Occupied Tones) / (Nfft x Decimation) For the above setting it is 244 KHz. Am I right with the data rate calculation ? That formula will give you the number of occupied tones per second. You need to multiply by the number of bits per tone to get bps. If you are using BPSK, multiply by 1. If using QPSK, you'll need to multiply by 3, 8PSK by 3, etc. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
That formula will give you the number of occupied tones per second. You need to multiply by the number of bits per tone to get bps. If you are using BPSK, multiply by 1. If using QPSK, you'll need to multiply by 3, 8PSK by 3, etc. I meant to say: BPSK - multiply by 1 QPSK - mult by 2 (not 3 like I said above) 8PSK - mult by 3 sorry for the confusion. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
Matt, There was a frequency offset of ~30 KHz at the Rx w.r.t Tx so I compensated for it and it worked!. The settings I am using is as follows: ./benchmark_ofdm_tx.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk --fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128 ./benchmark_ofdm_rx.py -f 2.45G -m bpsk --fft-length=512 --occupied-tones=80 -d 64 --rx-gain=20 --cp-length=128 I calculate the data-rate for OFDM as follows Data rate R = (ADC sampling rate x Occupied Tones) / (Nfft x Decimation) For the above setting it is 244 KHz. Am I right with the data rate calculation ? Thanks very much for your time, On Thu, Feb 11, 2010 at 10:26 PM, Matt Ettus m...@ettus.com wrote: On 02/11/2010 04:45 PM, Srinivas wrote: Hi All, I have 2 pairs of USRP2s with GNURadio-3.2 installed on their hosts. On one pair I am able to successfully run OFDM (benchmark_ofdm_tx rx) with almost 95+% packet success rate. However on the other pair I am not receiving even 1 packet! I am using the same host machines and scripts. I also tried swapping the daughtercards (XCVR2450) and the firmwares with the working pair, but the problem remains. Does any one have a clue of where the problem might be ? PS: The received signal spectrum (usrp2_fft.py) on one of the non-working USRP2s is attached herewith. Besides this I plotted the spectrum of the received data from usrp2_rx_cfile.py at the receiver using MATLAB. The spectrum is of the same shape and strength as usrp2_fft.py displays. Srinivas, It looks like you are using a very narrow signal. The frequency offset of the USRP2s giving you trouble may be enough that you are outside of the search range of the OFDM receiver (which is a percentage of the bandwidth of the signal). You could try any or all of the following: - increasing the data rate by a factor of 2 or 4 - modifying the OFDM code to widen the search range - locking the usrps to a common reference - measure the frequency offset of the transmitter, and run the receiver with the actual frequency. For example, if the receiver sees the signal 30 kHz high using usrp2_fft.py, call the ofdm receiver with -f 2.450030G on the command line Matt -- 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] OFDM receiver on USRP2
On 02/11/2010 04:45 PM, Srinivas wrote: Hi All, I have 2 pairs of USRP2s with GNURadio-3.2 installed on their hosts. On one pair I am able to successfully run OFDM (benchmark_ofdm_tx rx) with almost 95+% packet success rate. However on the other pair I am not receiving even 1 packet! I am using the same host machines and scripts. I also tried swapping the daughtercards (XCVR2450) and the firmwares with the working pair, but the problem remains. Does any one have a clue of where the problem might be ? PS: The received signal spectrum (usrp2_fft.py) on one of the non-working USRP2s is attached herewith. Besides this I plotted the spectrum of the received data from usrp2_rx_cfile.py at the receiver using MATLAB. The spectrum is of the same shape and strength as usrp2_fft.py displays. Srinivas, It looks like you are using a very narrow signal. The frequency offset of the USRP2s giving you trouble may be enough that you are outside of the search range of the OFDM receiver (which is a percentage of the bandwidth of the signal). You could try any or all of the following: - increasing the data rate by a factor of 2 or 4 - modifying the OFDM code to widen the search range - locking the usrps to a common reference - measure the frequency offset of the transmitter, and run the receiver with the actual frequency. For example, if the receiver sees the signal 30 kHz high using usrp2_fft.py, call the ofdm receiver with -f 2.450030G on the command line Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
