Re: [Discuss-gnuradio] Issues with benchmark_tx and benchmark_rx codes
Hi Tom, Thanks for the reply. I have a few more question on this regard and also some additional questions on benchmark_rx and tx. 1. There is a 'thres' parameter in the receive_path.py code, associated with the benchmark_rx.py code. The default value is 30. It says, thres = 30, # in dB, will have to adjust. What does it mean? 2. Does the 'packet Ok = true' in benchmark_rx inherently perform a CRC check? I implemented a CRC separately in the received payload, i.e., I was watching if there is a single bit error in the packet. I saw that whenever the benchmark_rx says 'packet Ok = true', it passes my CRC test and vice versa. It can't be coincidence, can it? 3. I am using the June 2011 version of gnuradio. My colleague just recently downloaded the latest version and he is trying to install the firmware in the SD cards. Now, with that June 2011 version, my benchmark tx and rx codes work predictably for gmsk modulation. By predictable, I mean that the codes work for --tx-ampl ranging from 0.05 to 0.9. At very low and high tx amplitude, it probably suffers from low signal strength and saturation. However, the dbpsk and dqpsk modulation work somewhat randomly, i.e., at one moment dbpsk may receive 100% packets at --tx-ampl 0.1. But, in the next moment, it may receive all packets as false at --tx-ampl 0.1. Therefore, I think that the problem is arising from the phase synchronization in the receiver. You talked in great details about control loop gain variables in http://gnuradio.squarespace.com/blog/2011/8/13/control-loop-gain-values.html. I just wonder which options in benchmark_rx are associated with these variables, i.e., the options that we can control? I can think of --costas-alpha, --gain-mu, alpha (in the receive_path.py code). Is there any other? 4. What is the difference between --costas-alpha (benchmark_rx option) and alpha (given with default value = 0.001 in the receive_path.py code)? Sorry for the long email. Your feedback will be very appreciated. Thanks, Nazmul On Sat, Nov 26, 2011 at 12:23 PM, Tom Rondeau wrote: > On Sat, Nov 26, 2011 at 12:13 PM, Nazmul Islam > wrote: > >> Tom, >> >> Thanks a lot for your reply. I appreciate it. I will upgrade to GNUradio >> 3.5. But I have a few more questions on the options. >> >> 1. Is there a roughly standard range of the option values that one should >> use? (the values of --tx-ampl, --tx-gain, --rx-gain, threshold, alpha, >> --costas-alpha, etc). For example, the values of alpha and thresh are given >> as 0.001 and 30 in the receive_path.py program. Shall I change these? If >> so, by how much? Are these values completely dependent on the local >> daughterboards? >> > > No since this is going to depend more on what USRP and daughterboard you > are using (or some other RF platform if it's not a USRP). We have not made > any measurements or analysis of this (and if you do, I hope you will share > it with the rest of us; since there are manufacturing tolerances on all of > these, any measurement should also come with a range (max/avg/min)). > > So right now, you're going to have to look at the output of your > transmitter to see if there is any distortion and play with the signal > levels to understand your system's behaviro. > > > >> 2. Is there any file or document that describe these options in more >> details? From my communication systems course, I can roughly understand >> these options. But some options, e.g. the effect of --tx-ampl versus the >> effect of --tx-gain are not clear to me. >> >> Any feedback will be really appreciated. >> >> Thanks, >> >> Nazmul >> > > No, there is nothing on this, yet. You're right that there should be > though... > > For now (so as to be cataloged on this mailing list at least), the > difference between --tx-ampl and --tx-gain is this. > > --tx-gain is a USRP/HW setting. It is the gain value (in dB) that is > applied by the analog stages of the USRP and daughterboard. > > --tx-ampl is a digital setting that sets the scale of the transmitted > signal. In the UHD world, all signals are between +/-1, so this scaling > factor should be < 1.0. > > Tom > > > >> On Sat, Nov 26, 2011 at 11:36 AM, Tom Rondeau wrote: >> >>> On Wed, Nov 23, 2011 at 1:49 PM, Nazmul Islam < >>> mnis...@winlab.rutgers.edu> wrote: >>> Hello All, I am trying to measure packet error rates for different modulation schemes using benchmark_tx and benchmark_rx codes. I run my codes on XCVR2450 USRP2 dughterboard and I am using the UHD_003_002_001 image (That image was downloaded on June, 2011 from the website, I believe). Now, I am getting strange results in terms of packet error rate. The benchmark_rx codes don't receive anything for d8psk modulation. It receives packets for dqpsk and qbpsk, but the work-ability depends on the inputs in a weird way. I am listing down some of the results that I have observed for different commands: Scenario 1: ./benchmark_tx.py -f 2.4G -r 1M
Re: [Discuss-gnuradio] Issues with benchmark_tx and benchmark_rx codes
On Sat, Nov 26, 2011 at 12:13 PM, Nazmul Islam wrote: > Tom, > > Thanks a lot for your reply. I appreciate it. I will upgrade to GNUradio > 3.5. But I have a few more questions on the options. > > 1. Is there a roughly standard range of the option values that one should > use? (the values of --tx-ampl, --tx-gain, --rx-gain, threshold, alpha, > --costas-alpha, etc). For example, the values of alpha and thresh are given > as 0.001 and 30 in the receive_path.py program. Shall I change these? If > so, by how much? Are these values completely dependent on the local > daughterboards? > No since this is going to depend more on what USRP and daughterboard you are using (or some other RF platform if it's not a USRP). We have not made any measurements or analysis of this (and if you do, I hope you will share it with the rest of us; since there are manufacturing tolerances on all of these, any measurement should also come with a range (max/avg/min)). So right now, you're going to have to look at the output of your transmitter to see if there is any distortion and play with the signal levels to understand your system's behaviro. > 2. Is there any file or document that describe these options in more > details? From my communication systems course, I can roughly understand > these options. But some options, e.g. the effect of --tx-ampl versus the > effect of --tx-gain are not clear to me. > > Any feedback will be really appreciated. > > Thanks, > > Nazmul > No, there is nothing on this, yet. You're right that there should be though... For now (so as to be cataloged on this mailing list at least), the difference between --tx-ampl and --tx-gain is this. --tx-gain is a USRP/HW setting. It is the gain value (in dB) that is applied by the analog stages of the USRP and daughterboard. --tx-ampl is a digital setting that sets the scale of the transmitted signal. In the UHD world, all signals are between +/-1, so this scaling factor should be < 1.0. Tom > On Sat, Nov 26, 2011 at 11:36 AM, Tom Rondeau wrote: > >> On Wed, Nov 23, 2011 at 1:49 PM, Nazmul Islam > > wrote: >> >>> Hello All, >>> >>> I am trying to measure packet error rates for different modulation >>> schemes using benchmark_tx and benchmark_rx codes. I run my codes on >>> XCVR2450 USRP2 dughterboard and I am using the UHD_003_002_001 image (That >>> image was downloaded on June, 2011 from the website, I believe). Now, I am >>> getting strange results in terms of packet error rate. The benchmark_rx >>> codes don't receive anything for d8psk modulation. It receives packets for >>> dqpsk and qbpsk, but the work-ability depends on the inputs in a weird >>> way. I am listing down some of the results that I have observed for >>> different commands: >>> >>> Scenario 1: >>> >>> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 20 -m >>> dbpsk >>> >>> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05 >>> --gain-mu 0.01 >>> >>> Results: All packets receiverd. >>> >>> >>> Scenario 2: >>> >>> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m >>> dbpsk >>> >>> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05 >>> --gain-mu 0.01 >>> >>> Results: All packets are received as false.( The only difference between >>> scenario 1 and scenario 2 is the in the increase of --tx-gain (from 20 to >>> 25).) >>> >>> >>> Scenario 3: >>> >>> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m >>> dqpsk >>> >>> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dqpsk --costas-alpha 0.05 >>> --gain-mu 0.01 >>> >>> Result: All packets are received as OK. (The difference between scenario >>> 2 and scenario 3 lies in the change of modulation (from dbpsk to dqpsk).) >>> >>> >>> Scenario 4: >>> >>> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m >>> d8psk >>> >>> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m d8psk --costas-alpha 0.05 >>> --gain-mu 0.01 >>> >>> Result: No packet gets received. The receiver sits idle waiting for the >>> packets. >>> >>> >>> I observed my transmitted signal in the spectrum analyzer and I did not >>> see any carrier offset, i.e., the received signal was centered at 2.4 GHz. >>> I think that the error is coming from either over-saturation of >>> transmission signal or the costas-loop at the receiver. At present, I am >>> simply walking in the dark and trying random input values to make the >>> schemes work. Is there any suitable range for these options? (--tx-ampl, >>> --tx-gain, --costas-alpha, --gain-mu, --rx-gain, etc.)? Please let me know >>> if any of you have found a suitable range for these options. Your >>> suggestions will be valuable. >>> >>> Thanks for reading the long email. >>> >>> Nazmul >>> >> >> >> Nazmul, >> You could try upgrading to version 3.5 of GNU Radio. There are a lot of >> changes in the digital modulation blocks that might help. There's still >> some work to be done with them, but the recovery loops used are more stable >> to the par
Re: [Discuss-gnuradio] Issues with benchmark_tx and benchmark_rx codes
Tom, Thanks a lot for your reply. I appreciate it. I will upgrade to GNUradio 3.5. But I have a few more questions on the options. 1. Is there a roughly standard range of the option values that one should use? (the values of --tx-ampl, --tx-gain, --rx-gain, threshold, alpha, --costas-alpha, etc). For example, the values of alpha and thresh are given as 0.001 and 30 in the receive_path.py program. Shall I change these? If so, by how much? Are these values completely dependent on the local daughterboards? 2. Is there any file or document that describe these options in more details? From my communication systems course, I can roughly understand these options. But some options, e.g. the effect of --tx-ampl versus the effect of --tx-gain are not clear to me. Any feedback will be really appreciated. Thanks, Nazmul On Sat, Nov 26, 2011 at 11:36 AM, Tom Rondeau wrote: > On Wed, Nov 23, 2011 at 1:49 PM, Nazmul Islam > wrote: > >> Hello All, >> >> I am trying to measure packet error rates for different modulation >> schemes using benchmark_tx and benchmark_rx codes. I run my codes on >> XCVR2450 USRP2 dughterboard and I am using the UHD_003_002_001 image (That >> image was downloaded on June, 2011 from the website, I believe). Now, I am >> getting strange results in terms of packet error rate. The benchmark_rx >> codes don't receive anything for d8psk modulation. It receives packets for >> dqpsk and qbpsk, but the work-ability depends on the inputs in a weird >> way. I am listing down some of the results that I have observed for >> different commands: >> >> Scenario 1: >> >> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 20 -m >> dbpsk >> >> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05 >> --gain-mu 0.01 >> >> Results: All packets receiverd. >> >> >> Scenario 2: >> >> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m >> dbpsk >> >> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05 >> --gain-mu 0.01 >> >> Results: All packets are received as false.( The only difference between >> scenario 1 and scenario 2 is the in the increase of --tx-gain (from 20 to >> 25).) >> >> >> Scenario 3: >> >> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m >> dqpsk >> >> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dqpsk --costas-alpha 0.05 >> --gain-mu 0.01 >> >> Result: All packets are received as OK. (The difference between scenario >> 2 and scenario 3 lies in the change of modulation (from dbpsk to dqpsk).) >> >> >> Scenario 4: >> >> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m >> d8psk >> >> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m d8psk --costas-alpha 0.05 >> --gain-mu 0.01 >> >> Result: No packet gets received. The receiver sits idle waiting for the >> packets. >> >> >> I observed my transmitted signal in the spectrum analyzer and I did not >> see any carrier offset, i.e., the received signal was centered at 2.4 GHz. >> I think that the error is coming from either over-saturation of >> transmission signal or the costas-loop at the receiver. At present, I am >> simply walking in the dark and trying random input values to make the >> schemes work. Is there any suitable range for these options? (--tx-ampl, >> --tx-gain, --costas-alpha, --gain-mu, --rx-gain, etc.)? Please let me know >> if any of you have found a suitable range for these options. Your >> suggestions will be valuable. >> >> Thanks for reading the long email. >> >> Nazmul >> > > > Nazmul, > You could try upgrading to version 3.5 of GNU Radio. There are a lot of > changes in the digital modulation blocks that might help. There's still > some work to be done with them, but the recovery loops used are more stable > to the parameter settings than previously. It should help. > > My guess from your post above is that, yes, you are having some issues > with overloading the transmitters. > > Tom > > >> >> > -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issues with benchmark_tx and benchmark_rx codes
On Wed, Nov 23, 2011 at 1:49 PM, Nazmul Islam wrote: > Hello All, > > I am trying to measure packet error rates for different modulation schemes > using benchmark_tx and benchmark_rx codes. I run my codes on XCVR2450 USRP2 > dughterboard and I am using the UHD_003_002_001 image (That image was > downloaded on June, 2011 from the website, I believe). Now, I am getting > strange results in terms of packet error rate. The benchmark_rx codes don't > receive anything for d8psk modulation. It receives packets for dqpsk and > qbpsk, but the work-ability depends on the inputs in a weird way. I am > listing down some of the results that I have observed for different > commands: > > Scenario 1: > > ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 20 -m dbpsk > > ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05 > --gain-mu 0.01 > > Results: All packets receiverd. > > > Scenario 2: > > ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m dbpsk > > ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05 > --gain-mu 0.01 > > Results: All packets are received as false.( The only difference between > scenario 1 and scenario 2 is the in the increase of --tx-gain (from 20 to > 25).) > > > Scenario 3: > > ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m dqpsk > > ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dqpsk --costas-alpha 0.05 > --gain-mu 0.01 > > Result: All packets are received as OK. (The difference between scenario 2 > and scenario 3 lies in the change of modulation (from dbpsk to dqpsk).) > > > Scenario 4: > > ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m d8psk > > ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m d8psk --costas-alpha 0.05 > --gain-mu 0.01 > > Result: No packet gets received. The receiver sits idle waiting for the > packets. > > > I observed my transmitted signal in the spectrum analyzer and I did not > see any carrier offset, i.e., the received signal was centered at 2.4 GHz. > I think that the error is coming from either over-saturation of > transmission signal or the costas-loop at the receiver. At present, I am > simply walking in the dark and trying random input values to make the > schemes work. Is there any suitable range for these options? (--tx-ampl, > --tx-gain, --costas-alpha, --gain-mu, --rx-gain, etc.)? Please let me know > if any of you have found a suitable range for these options. Your > suggestions will be valuable. > > Thanks for reading the long email. > > Nazmul > Nazmul, You could try upgrading to version 3.5 of GNU Radio. There are a lot of changes in the digital modulation blocks that might help. There's still some work to be done with them, but the recovery loops used are more stable to the parameter settings than previously. It should help. My guess from your post above is that, yes, you are having some issues with overloading the transmitters. Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Issues with benchmark_tx and benchmark_rx codes
Hello All, I am trying to measure packet error rates for different modulation schemes using benchmark_tx and benchmark_rx codes. I run my codes on XCVR2450 USRP2 dughterboard and I am using the UHD_003_002_001 image (That image was downloaded on June, 2011 from the website, I believe). Now, I am getting strange results in terms of packet error rate. The benchmark_rx codes don't receive anything for d8psk modulation. It receives packets for dqpsk and qbpsk, but the work-ability depends on the inputs in a weird way. I am listing down some of the results that I have observed for different commands: Scenario 1: ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 20 -m dbpsk ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05 --gain-mu 0.01 Results: All packets receiverd. Scenario 2: ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m dbpsk ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05 --gain-mu 0.01 Results: All packets are received as false.( The only difference between scenario 1 and scenario 2 is the in the increase of --tx-gain (from 20 to 25).) Scenario 3: ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m dqpsk ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dqpsk --costas-alpha 0.05 --gain-mu 0.01 Result: All packets are received as OK. (The difference between scenario 2 and scenario 3 lies in the change of modulation (from dbpsk to dqpsk).) Scenario 4: ./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m d8psk ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m d8psk --costas-alpha 0.05 --gain-mu 0.01 Result: No packet gets received. The receiver sits idle waiting for the packets. I observed my transmitted signal in the spectrum analyzer and I did not see any carrier offset, i.e., the received signal was centered at 2.4 GHz. I think that the error is coming from either over-saturation of transmission signal or the costas-loop at the receiver. At present, I am simply walking in the dark and trying random input values to make the schemes work. Is there any suitable range for these options? (--tx-ampl, --tx-gain, --costas-alpha, --gain-mu, --rx-gain, etc.)? Please let me know if any of you have found a suitable range for these options. Your suggestions will be valuable. Thanks for reading the long email. Nazmul -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
