Re: [Discuss-gnuradio] Sounding signal output power and spectrum
On Sat, Nov 29, 2008 at 9:55 AM, Qi Chen [EMAIL PROTECTED] wrote: 1. The gr-sounder default transmit amplitude is 4096, is there a particular reason why this number is chosen? My guess is because a 12-bit DAC is used. You are correct. This app uses a custom FPGA image for transmission, and unlike most GNU Radio applications, the amplitude here is directly converted to the DAC output values. This is the maximum amplitude. 3. I did a indoor measurement with TX-RX separation of 50 meters (w/ LOS), the received channel impulse response has 5 chunks of CIRs instead of one, and the number of samples between each chunk is always 800 chips, I am sure those CIRs are not multipath delays since in an indoor environment the corresponding delays can't be 800-chips apart from each other(way too long). Am I missing something here? You need to post your command line parameters for the transmitter and receiver. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sounding signal output power and spectrum
On Dec 1, 2008, at 2:24 PM, Johnathan Corgan wrote: On Sat, Nov 29, 2008 at 9:55 AM, Qi Chen [EMAIL PROTECTED] wrote: 1. The gr-sounder default transmit amplitude is 4096, is there a particular reason why this number is chosen? My guess is because a 12-bit DAC is used. You are correct. This app uses a custom FPGA image for transmission, and unlike most GNU Radio applications, the amplitude here is directly converted to the DAC output values. This is the maximum amplitude. That makes sense. Do those measured output power values make sense? 3. I did a indoor measurement with TX-RX separation of 50 meters (w/ LOS), the received channel impulse response has 5 chunks of CIRs instead of one, and the number of samples between each chunk is always 800 chips, I am sure those CIRs are not multipath delays since in an indoor environment the corresponding delays can't be 800-chips apart from each other(way too long). Am I missing something here? You need to post your command line parameters for the transmitter and receiver. I am using the default parameters for both tx and rx. My command lines are as follows: Tx: sudo ./usrp_sounder.py -t -f 2.44G -v -D Rx: sudo ./usrp_sounder.py -t -f 2.44G -v -D -F output.dat I use read_complex_binary.m to read the log file. The resulting channel impulse response looks like this: Figure 1: http://www.ittc.ku.edu/~chenqi/cir1.jpg Figure 2: http://www.ittc.ku.edu/~chenqi/cir2.jpg Figure 1 is the first cycle of the recorded impulse response. Figure 2 shows five chunks of CIRs the first and second group of CIRs are 800 chips apart. Any clue on that? -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sounding signal output power and spectrum
On Dec 1, 2008, at 4:04 PM, Qi Chen wrote: On Dec 1, 2008, at 2:24 PM, Johnathan Corgan wrote: On Sat, Nov 29, 2008 at 9:55 AM, Qi Chen [EMAIL PROTECTED] wrote: 1. The gr-sounder default transmit amplitude is 4096, is there a particular reason why this number is chosen? My guess is because a 12-bit DAC is used. You are correct. This app uses a custom FPGA image for transmission, and unlike most GNU Radio applications, the amplitude here is directly converted to the DAC output values. This is the maximum amplitude. That makes sense. Do those measured output power values make sense? 3. I did a indoor measurement with TX-RX separation of 50 meters (w/ LOS), the received channel impulse response has 5 chunks of CIRs instead of one, and the number of samples between each chunk is always 800 chips, I am sure those CIRs are not multipath delays since in an indoor environment the corresponding delays can't be 800-chips apart from each other(way too long). Am I missing something here? You need to post your command line parameters for the transmitter and receiver. I am using the default parameters for both tx and rx. My command lines are as follows: Tx: sudo ./usrp_sounder.py -t -f 2.44G -v -D Rx: sudo ./usrp_sounder.py -t -f 2.44G -v -D -F output.dat Oops, correction: Rx: sudo ./usrp_sounder.py -r -f 2.44G -v -D -F output.dat. Simple copy and past typo. I use read_complex_binary.m to read the log file. The resulting channel impulse response looks like this: Figure 1: http://www.ittc.ku.edu/~chenqi/cir1.jpg Figure 2: http://www.ittc.ku.edu/~chenqi/cir2.jpg Figure 1 is the first cycle of the recorded impulse response. Figure 2 shows five chunks of CIRs the first and second group of CIRs are 800 chips apart. Any clue on that? -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sounding signal output power and spectrum
Hi all, I have been doing some channel sounding measurements with the USRP, and there is something that I am not sure about. 1. The gr-sounder default transmit amplitude is 4096, is there a particular reason why this number is chosen? My guess is because a 12- bit DAC is used. 2. All my measurements were conducted with RFX 2400 d'board, and the d'board is connected directly to a spectrum analyzer, the measured output power levels are listed below: 128:-28 dBm 256:-23 dBm 512:-17 dBm 1024: -11 dBm 2048: -6 dBm 4096: 1 dBm so far so good(roughly 6dB step when I double the tx amplitude), and all signals cover 32MHz bandwidth, but when I change --tx-amplitude to 8192, it gave me a spike at the center frequency with very narrow bandwidth, the power measured is about 11 dBm, any tx amplitude value greater than 8192 yields a small power (-61dBm) with 32MHz bandwidth. I am sure this has something to do with the DAC and PA, but not sure exactly how to explain it. 3. I did a indoor measurement with TX-RX separation of 50 meters (w/ LOS), the received channel impulse response has 5 chunks of CIRs instead of one, and the number of samples between each chunk is always 800 chips, I am sure those CIRs are not multipath delays since in an indoor environment the corresponding delays can't be 800-chips apart from each other(way too long). Am I missing something here? Thanks in advance for any help. Qi Chen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio