I went ahead and locked the USRP2 to my signal analyzer's reference clock and that seemed to knock the error down to about 11-14%, which is obviously much improved.
However, I then looked at the signal on an oscilloscope and it looks like the USRP2 is sending out short bursts of data instead of a continuous signal like I see when using the USRP1. Both boards are using the Flex1800 daughterboard and are transmitting at 1.8GHz. Is there some reason the USRP2 would not be able to send data continuously even if the programs I've been running are exactly the same? On Wed, Jul 7, 2010 at 2:53 PM, Matt Ettus <m...@ettus.com> wrote: > On 07/07/2010 11:43 AM, Garrett Wenger wrote: > >> I am not quite sure what data rate I am getting. I've been using a >> signal analyzer to receive and demod what I'm transmitting and it can >> generally pick up the bit sequence that I am now sending out, but I get >> an error rate the fluctuates from about 5% all the way up to 70% or >> higher. >> My cpfsk mod index is set to 1 and the distance between the peaks is >> about 10kHz, so it really seems like my data rate is somewhere around >> what I want it to be, but the error rate is just way to high. >> > > The problem is likely to be frequency offset. I don't know your carrier > frequency, but at 1 GHz, 10 ppm is 10 kHz. So your 10 kHz wide signal at 1 > GHz could be completely out of the passband if the oscillators are off by 10 > ppm or more. The USRP1 oscillator is typically 5-10 ppm but the spec is 20 > ppm, and the USRP2 is typically 10-20 ppm when not locked. > > > >> Also, I went ahead and added in the interpolating filter like you >> suggested, but just for future reference, what is bad about having a >> high samples per symbol value? >> > > In theory, nothing. In practice, a couple of things. The higher the > samples per symbol the longer your filters need to be. Also, the filters in > there are chosen for good timing recovery properties, not for out of band > rejection. By having so many samples per symbol, you get a lot more out of > band energy which needs to be rejected. > > Matt >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
