Does the number of samples per symbol for the dbpsk case really affect the PDR performance?

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

Bill S. 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


From: Tom R. [email protected]
To: Bill S. [email protected]
Cc: [email protected]
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 S. 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 Fri, Mar 6, 2009 at 9:38 AM, Bill S.
[email protected] wrote:

Bill S. 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 Fri, Mar 6, 2009 at 9:38 AM, Bill S.
[email protected] wrote:

Bill S. 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


From: Tom R. [email protected]
To: Bill S. [email protected]
Cc: [email protected]
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 S.
[email protected] wrote:

Bill S. 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