Ah rookie mistake on my part! I went ahead and made the sample rates consistent (40.96k) across the schematic and an interesting thing happened.
So I set these parameters: frequency to recover: 100Hz fft size: 4096 sample rate: 40.96k Sps to have a nice FFT bin number at 10 The interesting thing is that when receiving AND transmitting the expected bin is half of what I thought it would be. (ex: Recovering 100Hz should have been in FFT bin 10, when TX-ing it ends up in bin 5) Does the B200 do some kind of "split" with the sample rate when using the full duplex? Maybe dedicates half to each operation?(Not a huge issue) Side question: The resultant FFT bin seems to "blip" once in a while (half or full duplex). Is it some kind of artifact of a Log Power FFT block? I was looking around for documentation on it and if I could stabilize the output bin with any of it's parameters. If I can't do it in block my other ideas are: - Use some kind of sample and hold logic to make the system non-sensitive to small change. - Decrease the bandwidth and low pass filter potential noise - Increase power output from the board that's transmitting the tone Would any of these be viable? Any nudge in the right direction would be fantastic! Thanks and very much appreciated! On Tue, Jun 14, 2016 at 4:51 PM, Marcus D. Leech <[email protected]> wrote: > On 06/14/2016 02:37 PM, Santos Campos wrote: > > Hello, all! > This may be more of a board specific problem, so apologies if this is the > wrong place to ask. > > I'm sending a tone from one b200 usrp to a receiving one. I was trying to > recover the frequency of the original tone and was able to do so while only > receiving. > > However, when I tried to add a transmitting functionality, it seems that > my received samples are "corrupted" and the frequency I was trying to > recover bounces all over the place. I was pretty sure that they supported > full duplex, so I'm not sure what it might be. > > Any thoughts and suggestions are much appreciated! > > -Santos > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > So, another thing that leaps out at me is that your signal source and many > of the intervening processing blocks think that they're operating at 32K, > when in fact, they'll be operating at the hardware rate of your sink of > 40.96ksps. The "math" will be all wrong. Either adjust the parameters of > your intervening blocks so that they know you're operating at 40.96ksps, or > put in an interpolator. > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
