Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). We have now found out that we need a sampling rate of at least 2Msps which means we have to set the bandwidth to at least 2MHz (I read sth about that the USRPs have problems with higher decimation rates): ./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M ./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M The OFDM (bpsk) example is now working and all packets seems to be transmitted. Unfortunately, not all of the packets could be demodulated correctly as they are marked as ok: False - lets say a quarter of them. This would yield a really bad performance in terms of a reliable transmission. We also played around with the distance and the alignment of the omni antennas but ultimately, we could not get rid of the false packets. Have you encountered a similar bad performance? Have you also encountered such a strange behavior regarding the lower sampling rate? What else could we try? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On Tue, Jan 31, 2012 at 8:28 AM, Florian Schlembach florian.schlemb...@tu-ilmenau.de wrote: But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). We have now found out that we need a sampling rate of at least 2Msps which means we have to set the bandwidth to at least 2MHz (I read sth about that the USRPs have problems with higher decimation rates): ./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M ./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M The OFDM (bpsk) example is now working and all packets seems to be transmitted. Unfortunately, not all of the packets could be demodulated correctly as they are marked as ok: False - lets say a quarter of them. This would yield a really bad performance in terms of a reliable transmission. We also played around with the distance and the alignment of the omni antennas but ultimately, we could not get rid of the false packets. Have you encountered a similar bad performance? Have you also encountered such a strange behavior regarding the lower sampling rate? What else could we try? There is not channel coding on the packets. A packet of 1500 bytes is is 12000 bits. If a single bit is incorrect, the CRC check will fail and the packet is marked as bad. You'll have to take the OFDM basic examples and extend them with error correcting codes to get anything like reliable performance from it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On Mon, Jan 30, 2012 at 11:12 AM, Martin Braun martin.br...@kit.edu wrote: On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote: We have now extended our tests to the tests with two USRP2s with daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is receiving any packets. We checked the spectrum and tuned the gains as well. (OFDM) Now, we played with the benchmark files and tunnel.py located in the narrowband folder and therefore changed the modulation scheme from BPSK to GMSK and ultimately receiving all the packets!! That's strange. Does anybody knows what code be the problem that we can't establish any connection using higher order modulation schemes? Could it possibly be our slightly outdated UHD version? We are totally clueless, so we appreciate any idea/help! This won't really help, but I remember we had exactly the same troubles here. This was before UHD was even released, so I doubt that's the reason. Unfortunately, I can't remember how (or: if) we fixed it :( but I'll keep you updated if my memory comes up with something. But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). MB The benchmark OFDM scripts were made as simple examples of OFDM and were not made very robust. I can get them working within an office space fairly easily, but I seem to be the only one. When I moved everything over the using the UHD interface, I tested everything OTA successfully, so they do still work. One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. Try backing off on that (to around 0.2 - 0.3) and try again. You won't get much range from this signal, though. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. I'm thinking that too, there really should be some kind of warning when you drive the DAC to saturation. If you need more range use an external amp. On Tue, Jan 31, 2012 at 8:28 AM, Tom Rondeau t...@trondeau.com wrote: On Mon, Jan 30, 2012 at 11:12 AM, Martin Braun martin.br...@kit.eduwrote: On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote: We have now extended our tests to the tests with two USRP2s with daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is receiving any packets. We checked the spectrum and tuned the gains as well. (OFDM) Now, we played with the benchmark files and tunnel.py located in the narrowband folder and therefore changed the modulation scheme from BPSK to GMSK and ultimately receiving all the packets!! That's strange. Does anybody knows what code be the problem that we can't establish any connection using higher order modulation schemes? Could it possibly be our slightly outdated UHD version? We are totally clueless, so we appreciate any idea/help! This won't really help, but I remember we had exactly the same troubles here. This was before UHD was even released, so I doubt that's the reason. Unfortunately, I can't remember how (or: if) we fixed it :( but I'll keep you updated if my memory comes up with something. But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). MB The benchmark OFDM scripts were made as simple examples of OFDM and were not made very robust. I can get them working within an office space fairly easily, but I seem to be the only one. When I moved everything over the using the UHD interface, I tested everything OTA successfully, so they do still work. One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. Try backing off on that (to around 0.2 - 0.3) and try again. You won't get much range from this signal, though. Tom ___ 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
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On 31/01/12 08:37 AM, Andrew Davis wrote: One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. I'm thinking that too, there really should be some kind of warning when you drive the DAC to saturation. It's not the DAC that's typically the problem, it's the final RF amplifier on the daughter-card, and that's not precisely predictable from the software side. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On 31/01/12 08:28 AM, Florian Schlembach wrote: But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). We have now found out that we need a sampling rate of at least 2Msps which means we have to set the bandwidth to at least 2MHz (I read sth about that the USRPs have problems with higher decimation rates): ./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M ./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M The OFDM (bpsk) example is now working and all packets seems to be transmitted. Unfortunately, not all of the packets could be demodulated correctly as they are marked as ok: False - lets say a quarter of them. This would yield a really bad performance in terms of a reliable transmission. We also played around with the distance and the alignment of the omni antennas but ultimately, we could not get rid of the false packets. Have you encountered a similar bad performance? Have you also encountered such a strange behavior regarding the lower sampling rate? What else could we try? __ Frequency offset is the usual cause of such problems. The master oscillators on a USRP vary between about 10PPM and 20PPM, which at higher frequencies means on offset of several kHz. A narrow-band signal suffers much more from frequency offset issues that a wideband one--the frequency error constitutes a larger fraction of the overall signal. Frequency offset errors are normal in any radio communications system--since master oscillator frequencies are *never* perfect. Real-world systems typically have an FLL or AFT somewhere in the receive chain to compensate. This is why the last IF filter on a narrowband FM receiver is usually wider than would be suggested by the modulation bandwidth, and why there's usually some kind of AFT feedback. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
That's kinda odd now that I think about it, I had a similar problem and on an oscilloscope it looked like DAC clipping, but I could have been non-linearity in the final amp, what kind of problems do XCVR2450 have at high outputs? On Tue, Jan 31, 2012 at 9:00 AM, Marcus D. Leech mle...@ripnet.com wrote: ** On 31/01/12 08:37 AM, Andrew Davis wrote: One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. I'm thinking that too, there really should be some kind of warning when you drive the DAC to saturation. It's not the DAC that's typically the problem, it's the final RF amplifier on the daughter-card, and that's not precisely predictable from the software side. -- Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org ___ 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
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On 01/31/2012 08:21 PM, Andrew Davis wrote: That's kinda odd now that I think about it, I had a similar problem and on an oscilloscope it looked like DAC clipping, but I could have been non-linearity in the final amp, what kind of problems do XCVR2450 have at high outputs? All amplifiers will have non-linear operating regions up near their maximum output power. Clipping in the DAC shouldn't be approached until the signal magnitudes approach +/- 1.0. I don't believe the XCVR2450 is special in this regard. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote: We have now extended our tests to the tests with two USRP2s with daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is receiving any packets. We checked the spectrum and tuned the gains as well. (OFDM) Now, we played with the benchmark files and tunnel.py located in the narrowband folder and therefore changed the modulation scheme from BPSK to GMSK and ultimately receiving all the packets!! That's strange. Does anybody knows what code be the problem that we can't establish any connection using higher order modulation schemes? Could it possibly be our slightly outdated UHD version? We are totally clueless, so we appreciate any idea/help! This won't really help, but I remember we had exactly the same troubles here. This was before UHD was even released, so I doubt that's the reason. Unfortunately, I can't remember how (or: if) we fixed it :( but I'll keep you updated if my memory comes up with something. But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpx9MLweYYZj.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
Hey guys, we are trying to get run the tunnel.py / benchmark_rx.py (OFDM) in order to measure the datarate between two USRP2 (located with distance of 1 m) with daughterboards XCVR2450. We are running the benchmark_tx/rx.py as follows: benchmark_tx.py -f 2.4G --tx-gain=10 --tx-amplitude=0.8 -v benchmark_rx.py -f 2.4G --rx-gain=4 -v We already tried to tune the parameters by analyzing the spectrum by gnuradio-companion. It looks reasonable and the SNR is round about 20 dB which should be fine? Unfortunately, we don't get any packets transmitted. The RX side always says TIMEOUT. Our configuration is as follows: - Ubuntu 10.04 - gnuradio 3.5.1 (installed freshly) - UHD firmware version 003.003.001 - XCVR2450 Has anybody already got the tunnel.py/benchmark_tx.py run with a similar configuration? Has anybody an idea what we are doing wrong? Thanks in advance for your help! Best Regards, Florian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
