Re: [Discuss-gnuradio] GRC pure FSK with USRP1 board sampling troubles

[Nick Foster]

On Thu, 2011-05-19 at 12:44 -0700, justynnuff wrote:
> 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.1kHz*8 = 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.9kHz*8 = 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 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

> 
> 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
> 
>