Forum: GNU Radio problems connecting wavfile_source to usrp_sink.

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
A2dc950b271501eb279dc4959d4f4b03?d=identicon&s=25 Justin G. Eskesen (Guest)
on 2009-05-13 22:27
(Received via mailing list)
Greetings,  I'm new to the list, though I've been using gnuradio for
about 6
months now.  I'm using the USRP connected to an acoustic transceiver for
underwater communications/data collection.

I'm having some trouble sending data from a file, specifically a
wavfile_source, to a usrp_sink_c.  The block diagram is as follows:
gr.wavfile_source ->blks2.rational_resampler_fff -> gr.float_to_complex
->usrp.sink_c.  It doesn't give me any errors (other than a few "uU"s)
but I
get garbage on the other end of the transmission.

I've tested out most of these parts individually, and they work fine.
The
usrp_sink works fine when I use the signal generator.  I can read the
wavfile_source, resample it, and pipe it to an audio_sink or a
wavfile_sink
and it does the resampling properly.  Assuming I've done everything
correctly, am I missing something?  Is there some fundamental reason why
one
would be unable to read a file & send it via the usrp?  I've gotten the
reverse (usrp_source -> wavfile_sink) to work just fine.

Any help would be appreciated.

Justin

P.S. I've tried both wavfile_source & file_source & neither work.  I'm
aware
of the -1.0 to 1.0 normalization in wavfile_* & have commented that
portion
of the code out.  If I get this to work, I'll write a wavfile_source &
sink
that do no rescaling & take shorts because I'm doing too many unecessary
conversions.
B22e1b01ee2edc1bdd77eeb90fd4d5b4?d=identicon&s=25 Martin Braun (Guest)
on 2009-05-15 09:58
(Received via mailing list)
On Wed, May 13, 2009 at 04:25:39PM -0400, Justin G. Eskesen wrote:
> P.S. I've tried both wavfile_source & file_source & neither work.  I'm aware of
> the -1.0 to 1.0 normalization in wavfile_* & have commented that portion of the
> code out.  If I get this to work, I'll write a wavfile_source & sink that do no
> rescaling & take shorts because I'm doing too many unecessary conversions.

For the start, it probably would have been better to put in a
gr.multiply_const_ff() after the filter with a value of something like
20000. In the setup you mentioned, reading shorts from the WAV file
would not have helped, since you're using a float FIR afterwards, and a
short FIR would introduce too much quantization noise.

I've tried pretty much exactly the same setup before (but with the
multiplier) and it worked. Also, for debugging, I recommend using a
file_sink (not a wavfile_sink) instead of the USRP and check the sample
values in that file scale well in the DAC range. Actually, if you /did/
pipe it to WAV or audio, it should /not/ work, since they rely on data
being between -1 and 1.

Should you do ever do write a short wavfile_* and also want to support 8
Bit, remember that scales differently.

Hope this was what you wanted.
MB
A2dc950b271501eb279dc4959d4f4b03?d=identicon&s=25 Justin G. Eskesen (Guest)
on 2009-05-15 16:54
(Received via mailing list)
Thank you Martin.

Knowing that there is no fundamental reason that this setup would not
work,
led me to investigate a different section of my code & I discovered that
I
was running with a usrp decimation too low for my system & a wav file
with
too high a sample rate.

As for the short int wav file, I'm writing this code so that a number of
students, who don't use anything but matlab, will have access to the
usrp
board for their various experiments. I can cut out the FIR filter if I
desire & require a compatible input wav file sampling rate... I was just
trying to make it flexible to input wav files of varying sample rates.
I
have a competing desire to make it efficient, as I my be running this on
a
333 mHz PC-104 board.  So, its a tradeoff.

That said, it works beautifully now.  Thanks again.

Justin
This topic is locked and can not be replied to.