Nick Foster-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.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio