Tom- > Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ). > > We greatly appreciate the information and need to think about stuff on > our end. I've been deliberately vague about our application (not that > I could really explain it even if I felt authorized discuss it). The > thing to remember is that we believe (maybe we are fooling ourselves) > that we see easily reproducible problems when RX is ON but not when RX > is OFF. > > One more question was just sent to me to pass on, while I was > composing this email: > > crazy idea: is there any way to "clock" the host, i.e. keep track of a > time stamp in the host and gate/trigger the host outputs at a constant > sample rate that is consistent with the sample rate of the USRP2? > > just thought I would throw that out there...
"Clock the host" at multi-MHz rate? One way would be to connect the A/D converter directly to the PC and omit external radio hardware. Then you would not need FPGA de-modulation, GbE, etc. That would be a multi-year hardware and software effort, but sounds like something you and your mystery questioner might be willing to take on ;-) -Jeff > On Fri, Jan 15, 2010 at 6:24 PM, Matt Ettus <m...@ettus.com> wrote: >> On 01/15/2010 03:08 PM, Tom Gross wrote: >>> >>> yes of course we have two separate gig-e cards. if the usrp2 is >>> sending us "pause" commands then it seems evident the usrp2 is having >>> trouble keeping up, not the computer. >> >> First off, the USRP2 will only send pause frames when you are transmitting, >> not receiving. Pause frames are not generated due to the USRP2 being unable >> to keep up. Pause frames are not generated due to the computer not being >> able to keep up. Pause frames are generated as a normal part of the >> transmission process. This is fundamental, and you need to understand >> exactly why. >> >> >> >> When you are transmitting, the USRP2 can only consume samples at a fixed >> rate, determined by the clock rate (100 MHz) and the interpolation rate (4 >> or higher). No matter what that rate is, your computer should be able to >> generate samples faster than that. Since your computer does not have a 100 >> MHz clock to pace the generation of those samples, it will generate them too >> fast. When they are sent the USRP2, which can only consume them at a >> certain rate, they will pile up in the buffers of the USRP2. Once the >> buffers get full enough, the USRP2 will send pause frames back to the >> computer to tell it to wait until the samples it has can work their way >> through the pipeline. >> >> Again, this is completely normal and not because your computer is too slow, >> and not because the USRP2 is too slow. It is a normal consequence of the >> practicalities of generating samples asynchronously to their consumption. >> >> So in normal transmit operation, you will see large numbers of pause frames >> going from the USRP2 to the computer. Do not be alarmed. >> >> >> When receiving, the USRP only generates data as fast as samples are created >> by the ADC clock, divided by the decimation rate. If the decimation rate is >> 4 then the sample rate is 25 MS/s at 32 bits per sample, or 800 mbits. This >> fits just fine into gigabit ethernet, and so it all just goes out almost >> immediately over the ethernet, and nothing ever backs up and stalls. If >> your computer couldn't keep up, then it MIGHT WANT TO send pause frames, but >> we have disabled that. Instead, if your computer can't keep up it will drop >> frames and you'll see "S" in your terminal window. Get a faster computer or >> do less processing if you see this. >> >> If you were to try a decimation of 3 or lower, then you would be generating >> more than 1 gigabit per second, and the ethernet wouldn't keep up, and the >> buffers in the USRP2 would overflow and cause an overrun ("O") error. You >> shouldn't be doing this because it won't work. >> >> I hope this has cleared it up. To summarize -- each USRP2 needs its own >> Gigabit ethernet card to talk to EVEN if it is using only a tiny fraction of >> the total bandwidth. And those cards need to be configured to honor flow >> control. >> >> Matt _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio