Hi, We did the outdoor testing today to find out the relationship between RSSI and Distance and the relationship between RSSI and PDR with USRP and GNURadio. Mistakenly, the number of samples per symbol at the TX side was set to 4 and the number of samples per symbol at the RX side was set to 2. The modulation scheme we used was dbpsk:( . Would my wrong setting affect the final performance for the dbpsk case? I am very worried about that because we spent more than 5 hours on testing and at last found out that one argument was mistakenly configured to a wrong value. Could anyone give me a hand? Thanks! Bill

on 2009-03-06 04:22

on 2009-03-06 05:31

Bill Stevenson wrote: > wrong value. Could anyone give me a hand? > > Thanks! > > Bill Theoretically, no, it won't make a difference. It might if the rates of the transmitter and receiver were different because of mismatches in the decim/interp rate. Tom

on 2009-03-06 15:40

________________________________ From: Tom Rondeau <trondeau1122@gmail.com> To: Bill Stevenson <bill.stevenson07@yahoo.com> Cc: discuss-gnuradio@gnu.org Sent: Thursday, March 5, 2009 11:30:33 PM Subject: Re: [Discuss-gnuradio] does the number of samples per symbol for the dbpsk case really affect the PDR performance? Bill Stevenson wrote: > Hi, > > We did the outdoor testing today to find out the relationship between RSSI and Distance and the relationship between RSSI and PDR with USRP and GNURadio. Mistakenly, the number of samples per symbol at the TX side was set to 4 and the number of samples per symbol at the RX side was set to 2. The modulation scheme we used was dbpsk:( . Would my wrong setting affect the final performance for the dbpsk case? I am very worried about that because we spent more than 5 hours on testing and at last found out that one argument was mistakenly configured to a wrong value. Could anyone give me a hand? > > Thanks! > > Bill Theoretically, no, it won't make a difference. It might if the rates of the transmitter and receiver were different because of mismatches in the decim/interp rate. Tom Hi, Tom, Did you mean to say the sampling rate at the TX and RX side when you were talking about the rates of the transmitter and receiver? I think there are mismatches in the decim and interp rate because based on the fomular used to calculate the decim and interp, decim/interp should be 1/2, which would be 1 due to my mistake. Am I right? Thanks, :D. Bill

on 2009-03-06 17:03

On Fri, Mar 6, 2009 at 9:38 AM, Bill Stevenson <bill.stevenson07@yahoo.com> wrote: > Bill Stevenson wrote: >> hand? > Tom > Bill Yes, you are correct. There is a 2:1 difference in the interp to decim rates. However, the bps rate of the digital system is based on the number of samples per symbol and the interp/decim. r_tx = r_dac / interp / sps r_rx = r_adc / decim / sps Where r_dac is the DAC rate, r_adc is the ADC rate, interp is the interpolation rate, decim is the decimation rate, and sps is the samples per symbol. If you look in pick_bitrate.py, we make some calculations to determine what the actual bit rate is depending on what parameters are supplied based on these calculations above. If you want 500 kbps, then r_dac = 128 MSps, interp = 128, and sps = 2 Sps r_tx = 128e6 / 128 / 2 = 500e3 At the receiver, r_adc = 64 MSps, decim = 64, and sps = 2 Sps r_rx = 64e6 / 64 / 2 = 500e3 If you had specified a different sps for each side, then the pick_bitrate calculation would try to attain the specified rate of 500 kbps. It would find that with the receiver using 2, the interp rate should be 128, but at the transmitter with 4 Sps, the decim rate would be 32 instead. Under these conditions, both sides would be able to hit the 500 kbps rate exactly and you should have no problem. On the other hand, if you specified BOTH the sps and the decim/interp rates, then the resulting rate would be different by a factor of two and therefore your tests would be screwed up. OR if you specified the different sps and a rate that is a non-integer result to the equations above

on 2009-03-06 17:06

On Fri, Mar 6, 2009 at 9:38 AM, Bill Stevenson <bill.stevenson07@yahoo.com> wrote: > Bill Stevenson wrote: >> hand? > Tom > Bill Yes, you are correct. There is a 2:1 difference in the interp to decim rates. However, the bps rate of the digital system is based on the number of samples per symbol and the interp/decim. r_tx = r_dac / interp / sps r_rx = r_adc / decim / sps Where r_dac is the DAC rate, r_adc is the ADC rate, interp is the interpolation rate, decim is the decimation rate, and sps is the samples per symbol. If you look in pick_bitrate.py, we make some calculations to determine what the actual bit rate is depending on what parameters are supplied based on these calculations above. If you want 500 kbps, then r_dac = 128 MSps, interp = 128, and sps = 2 Sps r_tx = 128e6 / 128 / 2 = 500e3 At the receiver, r_adc = 64 MSps, decim = 64, and sps = 2 Sps r_rx = 64e6 / 64 / 2 = 500e3 If you had specified a different sps for each side, then the pick_bitrate calculation would try to attain the specified rate of 500 kbps. It would find that with the receiver using 2, the interp rate should be 128, but at the transmitter with 4 Sps, the decim rate would be 32 instead. Under these conditions, both sides would be able to hit the 500 kbps rate exactly and you should have no problem. On the other hand, if you specified BOTH the sps and the decim/interp rates, then the resulting rate would be different by a factor of two and therefore your tests would be screwed up. OR if you specified the different sps and a rate that produces a different rate for both the transmitter and receiver, then things could be screwed up. I suggest rerunning both scripts quickly with your exact settings you used in your experiments and see what the decim, interp, sps, and resulting TX and RX rates were. Tom

on 2009-03-07 00:57

________________________________ From: Tom Rondeau <trondeau1122@gmail.com> To: Bill Stevenson <bill.stevenson07@yahoo.com> Cc: discuss-gnuradio@gnu.org Sent: Friday, March 6, 2009 10:55:09 AM Subject: Re: [Discuss-gnuradio] does the number of samples per symbol for the dbpsk case really affect the PDR performance? On Fri, Mar 6, 2009 at 9:38 AM, Bill Stevenson <bill.stevenson07@yahoo.com> wrote: > Bill Stevenson wrote: >> hand? > Tom > Bill Yes, you are correct. There is a 2:1 difference in the interp to decim rates. However, the bps rate of the digital system is based on the number of samples per symbol and the interp/decim. r_tx = r_dac / interp / sps r_rx = r_adc / decim / sps Where r_dac is the DAC rate, r_adc is the ADC rate, interp is the interpolation rate, decim is the decimation rate, and sps is the samples per symbol. If you look in pick_bitrate.py, we make some calculations to determine what the actual bit rate is depending on what parameters are supplied based on these calculations above. If you want 500 kbps, then r_dac = 128 MSps, interp = 128, and sps = 2 Sps r_tx = 128e6 / 128 / 2 = 500e3 At the receiver, r_adc = 64 MSps, decim = 64, and sps = 2 Sps r_rx = 64e6 / 64 / 2 = 500e3 If you had specified a different sps for each side, then the pick_bitrate calculation would try to attain the specified rate of 500 kbps. It would find that with the receiver using 2, the interp rate should be 128, but at the transmitter with 4 Sps, the decim rate would be 32 instead. Under these conditions, both sides would be able to hit the 500 kbps rate exactly and you should have no problem. On the other hand, if you specified BOTH the sps and the decim/interp rates, then the resulting rate would be different by a factor of two and therefore your tests would be screwed up. OR if you specified the different sps and a rate that produces a different rate for both the transmitter and receiver, then things could be screwed up. I suggest rerunning both scripts quickly with your exact settings you used in your experiments and see what the decim, interp, sps, and resulting TX and RX rates were. Tom Hi, Tom Thank you! I understand what you said! Actually, in our experiment, the bitrates and number of samples per symbol were specified at both sides and only these two parameters were specified for our experiment. The decim and interp will be self-adjusted! I think that is the case! Bill