[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Understanding flow control
From: |
Matt Ettus |
Subject: |
Re: [Discuss-gnuradio] Understanding flow control |
Date: |
Fri, 15 Jan 2010 18:21:34 -0800 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 |
On 01/15/2010 03:53 PM, Tom Gross wrote:
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.
It is very hard to help when we don't have information about what you
are trying to do. The important piece of information is that you are
transmitting and receiving at the same time when you see this problem.
This indicates that there may be flow control tuning issues.
Is the RX stream ok and the TX has a problem? Or is it that the TX is
ok and the RX has a problem? Or is it both?
Do you have a TTL serial port hooked up to J305? Do you see characters
there? Do you see "S" characters on the receive application window?
Are you trying to use 2 separate programs (1 tx, 1 rx) to talk the the
USRP2, or are they in the same app?
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?
No, for 2 reasons:
- Even if the host had a clock, clocks drift relative to each other
- The USRP2 might need to hold off on sending for some reason.
This is a system that requires feedback and there is no way around it.
On the USRP1 the feedback is done by the flow control built into the USB
protocol. On the USRP2 the feedback is done by the flow control built
into ethernet. You could imagine doing a different feedback mechanism
using your own protocol, but it would still involve the device telling
the computer when to go and when to stop.
Actually there is one way around it -- have infinitely large buffers in
the USRP2, but that would add to the cost :)
Matt
- Re: [Discuss-gnuradio] Understanding flow control, (continued)
- Re: [Discuss-gnuradio] Understanding flow control, Eric Blossom, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Tom Gross, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Eric Blossom, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Tom Gross, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Tom Gross, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Matt Ettus, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Tom Gross, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Johnathan Corgan, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Matt Ettus, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Tom Gross, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control,
Matt Ettus <=
- Re: [Discuss-gnuradio] Understanding flow control, Tom Gross, 2010/01/16
- Re: [Discuss-gnuradio] Understanding flow control, Matt Ettus, 2010/01/16
- Re: [Discuss-gnuradio] Understanding flow control, Tom Gross, 2010/01/18
- Re: [Discuss-gnuradio] Understanding flow control, Jeff Brower, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Tom Gross, 2010/01/15
- Re: [Discuss-gnuradio] Understanding flow control, Matt Ettus, 2010/01/15