Hello to you too At our university we have seen this behaviour as well. Our setup is a USRP N210 with a 2400 daughterboard into a Rhode & Swartz spectrum analyzer. We also get these sidelobes, and if you trawl the archives, you will find others have as well.
Currently we are working on a theory that it might be the CORDIC algorithm in the FPGA that causes the disturbance. I have managed to create Matlab and Python code showing some of the same characteristics, and am currently working on implementing this into a block, so that a channel model can be done. I believe the reason is the way the CORDIC algorithm is implemented. In the verilog code, there are two hints that it might be written better, but that it is difficult because of the verilog language. It is however almost trivial using VHDL, so I am currently considering rewriting the CORDIC in VHDL, although this will probably not be untill we have handed in our Masters Thesis (The main object of the thesis is not correcting possible errors, but documenting their impact). We would very much like to use the very descriptive images you have provided in our work, if that's okay with you. Best Regards Paul M. Bendixen Stud. Scient EE 2011/10/26 justynnuff <[email protected]> > > Hello all: > > We have been working on an APCO P25 project at my university, and are > fortunate enough to have 4 USRP N210's all equipped with the WBX boards. > > As the project has progressed we have accomplished many of our goals. > However, one thing that has haunted us throughout the entire project is > transmission from USRP to USRP results in very high bit errors. We also > have 2 P25 handsets available and when Tx'ing from a handset and receiving > from a USRP or Tx'ing from the USRP and receiving from a handset, > everything > is fine, we have no perceivable bit errors (we haven't really dug into the > exact bit error measurements, however, we are working with a DVSI AMBE > vocoder/FEC, which implies the bit errors are large enough to screw up the > error correction, which, no matter how you cut it, shouldn't happen with > two > USRP's 2 feet from each other). > > So we ran some tests with the 4 USRP's > > We used a two-tone test at +1kHz and -2kHz. We used GNU Radio and GRC with > a fairly simple set up that consisted of reading the MATLAB generated > two-tone sample data using the "file source" block into the "UHD USRP > sink." > On the Rx end, it was the same, but reversed. I have supplied figures of > the received data, but guessed the GRC setup code isn't necessary. > > In the first figure, we saw that using the same USRP for Tx and switching > USRP's on the Rx end resulted in very odd data. In the second, we used > USRP > 1 to Tx and 2 to Rx (what we believe to be the "worst" USRP's in the > bundle) > and attached them to an external clock. It can be seen that as far as the > two tone test goes, the peaks were right on the money. > > Another thing we noted is that by changing the gain on the Tx end, the > harmonics shown don't scale with the power. At low power, the harmonics > are > far too close to the main peaks, which is worrying (initially we had the > gain of the USRPs marginally under the maximum gain because we initially > thought the errors were caused by the RF front end going into some kind of > saturation state. From this data we see this isn't the case). Also of > note > is that at the time the first figure was generated, the USRP's were > approximately 2 feet from each other. In the latter figure, they were > about > 5 feet apart. It is obvious that the harmonics in the second figure are > higher, relative to the main peaks, than the first. I don't really have a > solid question to ask other than is this behavior normal? > > It is apparent that the poor results in the first figure are caused by > clock > drift, but the harmonics are also very worrying. Especially USRP 4 in the > first figure, which shows a relatively high harmonic right next to the main > peaks. Since the time we have sampled the supplied data, we have been > progressing forward in the project, so we haven't been able to test the P25 > waveform from USRP to USRP, and can't verify that the initial bit error > problems are alleviated by getting rid of the clock drift, or if they are > caused by the harmonics. Is there something we can do to remedy this > problem, or, again, is this behavior normal? > > > http://old.nabble.com/file/p32726685/Rx_DualTone_1.jpg > > > http://old.nabble.com/file/p32726685/external_clock_dual_tone.jpg > -- > View this message in context: > http://old.nabble.com/USRP-N210-Benchmarks.-tp32726685p32726685.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -//
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
