Re: GRC pure FSK with USRP1 board sampling troubles

Nick F. wrote:

In the “real world” this problem is usually solved by
dynamically resampling the audio stream at a rate controlled
by a feedback loop responding to the observed clock mismatch.

I have a USRP1 with a BasicTX daughterboard. When transmitting,
what is the proper method in a GNU Radio app for “observing” the
USRP, such that underrun (uUuUuU) errors are guaranteed not to
occur? [corollary: neither do we want queues to build up]

We’re of course assuming here that the CPU has plenty of power,
that the TX sampling rate is completely reasonable, etc., etc.

We’re also suggesting that our app might not necessarily have on
tap an infinite number of samples for immediate shipment to the
USRP at all times. (Think: just-in-time)…

We’re assuming that the design specs for our app say that:
“USRP underruns are totally unacceptable”
(is this a realistic goal to have in the “real world”?)

Is this capability available at all or is it hardware-dependent?
Or perhaps driver-dependent (UHD or whatever)?

If your ALSA-fu is strong and you have some free time, though,
it’d be super awesome to see this part taken care of. I’ve been
meaning to tackle this in the audio sink for a while now, but
put it off.

There are at least two cases I’ve been looking at which wouldn’t
benefit (at least directly) from this, unfortunately…

  1. audio sink is only half of it, audio source is also needed
  2. All the VOIP stuff seems to use a standard sample rate of 8,000

If GNU Radio does try to take a stab at the two-clocks problem
is it possible to generalize the solution beyond just ALSA users?

Thx & 73 de KA1RBI

Max

On 05/19/2011 09:49 PM, ikjtel wrote:

We’re assuming that the design specs for our app say that:
“USRP underruns are totally unacceptable”
(is this a realistic goal to have in the “real world”?)

While extended underruns are problematic, a short underrun should be
equivalent to
a noise-burst of some sort occurring on the channel. These are, after
all, radio channels
we’re talking about. They need to be reasonably robust in the face of
“stuff you can’t control”.

In the real world, glitches happen on analog channels. Which is why you
develop techniques to
cope with them. I see the occasional underrun/overrun as equivalent
to these glitches. You’d
rather they not happen often enough that they seriously impact your
channel BER.


Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs