GRC pure FSK with USRP1 board sampling troubles

GNU Radio
1

Hello, everyone.

I have been coming here for all of my GNURadio and GRC problems, and
everyone seems beyond knowledgeable. That being said, I have come to
the
end of my recourses and am forced to pose a question. I hope this
hasn’t
already been answered, but I’ve been searching for a while, and have not
found anything relevant to what I’m about to post.

I am trying to implement FSK over the air using the USRP1 boards within
GRC.
I have successfully sent large files between two computers, but am now
trying to implement sending a .wav via the .wav source (and in the
future,
live audio with the audio source). In the case of pure bytes, the only
thing that controls the sampling rate is the USRP, ie
128M(samples/second)/interpolation. However, in the case of a .wav file
with a set sampling rate seems to be much harder. The following is the
signal chain I’m using, and the chain of my logic as well.

Transmit:

Bit pipeline<<
-Source: .wav at 44.1khz.
-Multiply constant: 127 times the values within [-1,1] from the .wav
source.
-Float to short,
-Short to float: This essentially truncates the float output [-127,127]
of
the .wav to 255 discrete values (since I don’t know an easier way to do
this
within GRC)
-Float to char: Now we take those discrete values from [-127,127] and
map
them to a byte each.

FSK Modulation<<
-Simple framer: Since the framer appends a barker code to the beginning
of
my packet that is 8 bytes, a byte for the sequence number, and another
byte
at the end of the packet (according to the code, the byte is 0x55, why
this
is there, I still don’t know), I set the packet length to 4086 (ie
4086+10=4096 total packet length, a multiple of 128, as per
http://old.nabble.com/RFX2400%2BUSRP-buffers-td19415046.html#a19415046
http://old.nabble.com/RFX2400%2BUSRP-buffers-td19415046.html#a19415046
).
SAMPLE RATE: I have assumed it to be about the same, since the bytes
added
are negligible compared to the packet length
-Packed to Unpacked: Bits/chunk=1, therefore, for each byte put into
the
packed to unpacked, I receive 8 bytes out.
SAMPLE RATE: 44.1kHz8 = 352.8kHz.
-Chunks to symbols: Since I’m only doing 2 level FSK, I only care about
the
value of the MSB, but I’m pretty sure the code for chunks to symbols
reads
all the bits anyway, so again, our sample rate is not affected.
-Interpolating FIR filter: Set to length 8, with taps = 1. This
spreads
the effective mark and space bits out a little bit, ensuring full
periods
from the output of the FM mod block. Therefore, for each float in, I
get 8
float out.
SAMPLE RATE = 352.9kHz8 = 2.8224MHz.
-FM mod: This is where my confidence drops. I have selected my symbols
as
2 and 4 in the previous block, and set sensitivity to pi/16. Therefore,
for
every “0” (symbol = 2), I get a full sinusoidal period in 8 samples, and
2
full periods in 8 samples of a “1” (symbol = 4).

Now, I’m stuck. I have kind of assumed the sample rate at the output of
the
FM mod block to be equal to that going in, ie 2.8224MHz. The USRP
broadcasts
at 128M(sample/sec) / interpolation. Therefore, 129M/2.8224M ~ 45 (my
interpolation).

I guess this is where I am stuck. I’m not going to post the details of
the
receive side, as it’s essentially exactly the same, but backwards, but
I’m
not getting a coherent .wav a the output of my speakers. It goes on for
a
small amount of time, and then the USRP outputs garbage (actually it
looks
like a sinusoid with very low frequency) for a split second, then back
to
the regularly scheduled program. I am wondering if there is, and how a
buffer in the USRP (either block or actual hardware) treats a signal
that is
being “fed” either too fast, or too slow. And if so, do I have to add a
rational resampler? I’m thinking I do, but I don’t think anything will
get
the two sampling rates to match exactly

I know this is a long one, but I’m at the end of the road of fully
understanding FSK within GRC and the USRP board, and am pleased with my
previous results. Now that there are two competing sampling rates, I
don’t
know what to do.

Thanks for your infinite wisdom,

Justyn

–
View this message in context:
http://old.nabble.com/GRC-pure-FSK-with-USRP1-board-sampling-troubles-tp31650945p31650945.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

On Thu, 2011-05-19 at 12:44 -0700, justynnuff wrote:

trying to implement sending a .wav via the .wav source (and in the future,
source.
at the end of the packet (according to the code, the byte is 0x55, why this
value of the MSB, but I’m pretty sure the code for chunks to symbols reads

the regularly scheduled program. I am wondering if there is, and how a
buffer in the USRP (either block or actual hardware) treats a signal that is
being “fed” either too fast, or too slow. And if so, do I have to add a
rational resampler? I’m thinking I do, but I don’t think anything will get
the two sampling rates to match exactly

I think your transmit side is fine. The .wav source should be
unthrottled. The receive side is where you’re going to run into trouble.
This is the classic two-clock problem. Basically, you’re exactly right
– the two sample rates are never going to match exactly. You do need to
add a resampler to get your sample rates to match (assuming perfect
clock accuracy), but in reality the soundcard clock and the USRP clock
are going to drift with respect to each other. 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. The Gnuradio audio source/sink don’t include this part, and so
they don’t work so great with a USRP or other independently-clocked
hardware.

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.

–n

3

On Thu, May 19, 2011 at 03:34:09PM -0700, justynnuff wrote:

Nick F.-4 wrote:

I think your transmit side is fine. The .wav source should be
unthrottled. The receive side is where you’re going to run into trouble.

Indeed you’re right. Upon further research, I realised that nothing
throttles the Tx side but the USRP. So, according to my previous math, all
I need is 128Msam/sec / interpolation > 2.8MHz.

Am I missing something here? The “transmitter” should be a source and
multiplier to get the carrier frequency to the USRP and throttled by
the USRP sink. There should be no underruns. The audio file should
be throttled to it’s bit rate and used to modulate the “carrier”. Thus
the modulation bit rate should be recovered at the demodulator in the
receiver and right to feed a soundcard. The two-clock problem should
only be between the soundcards. If there is a audio source rather than
a file, it should throttle the modulation at it’s own rate.

–
LRK
gr-user . ovillatx.sytes.net

4

On Fri, 2011-05-20 at 07:34 -0500, LRK wrote:

Am I missing something here? The “transmitter” should be a source and
multiplier to get the carrier frequency to the USRP and throttled by
the USRP sink. There should be no underruns. The audio file should
be throttled to it’s bit rate and used to modulate the “carrier”. Thus
the modulation bit rate should be recovered at the demodulator in the
receiver and right to feed a soundcard. The two-clock problem should
only be between the soundcards. If there is a audio source rather than
a file, it should throttle the modulation at it’s own rate.

No throttle. Rule of thumb: never use throttle on real hardware, only on
flowgraphs that don’t use a soundcard or a USRP or anything else that
has its own clock. In this case, you upsample, not throttle, the audio
to whatever you set the USRP sample rate to.

The two-clock problem exists between the soundcard clock and the USRP
clock, because they use separate crystals for clock generation. It won’t
exist on the transmit side of the flowgraph since he’s using a .wav
source and not the mic input. The underrun in the transmit flowgraph is
due to something else, probably sample rates not being matched
somewhere.

You can check your receive flowgraph by writing to a .wav sink instead
of an audio sink.

–n

5

Nick F.-4 wrote:

I think your transmit side is fine. The .wav source should be
unthrottled. The receive side is where you’re going to run into trouble.

Indeed you’re right. Upon further research, I realised that nothing
throttles the Tx side but the USRP. So, according to my previous math,
all
I need is 128Msam/sec / interpolation > 2.8MHz. I chose interpolation
44.
This ensures my signal will always transmit at 2.909MHz. That means
with a
decimation on the Rx side of 22, I receive the signal at 2.909MHz.
That’s
still fine, since on the receiving end I have USRP > quadrature demod >
simple correlator > char to float. I simply undo everything I did on
the Tx
side sampling-rate-wise , ie 2.909MHz/64 ~ 45.4kHz. I’m not worried
about
the USRP clock and audio clock mismatch. I’ll deal with that after more
immediate matters:

On my transmit side, I’m still getting the whole “uUuUuU” bit at the
bottom
of the screen. That is, “not enough samples to send to the USRP.” This
coupled with the fact that when I get those interruption bursts on the
receive side, both my scope right off the USRP shows at interruption and
the
“seqno” from the simple correlator at the bottom of the screen slow
down.
this leads me to believe problems are happening on the transmit side.
But
since both as you said, and as I discovered, nothing is throttling the
USRP
but the USRP, I don’t know what it is.

I think the only answer is that my computer is simply not providing
enough
data over the USB as the USRP needs.

Right?

–
View this message in context:
http://old.nabble.com/GRC-pure-FSK-with-USRP1-board-sampling-troubles-tp31650945p31660072.html
Sent from the GnuRadio mailing list archive at Nabble.com.