On 11/21/2020 08:28 AM, Dustin Widmann wrote:
Marcus,
I tried it without timed commands last night. It was landing on the
same frequencies as it did with timed commands i.e. didn't fix that
problem.
Dustin
OK, thanks for doing the test.
I wonder if you have a precise signal generator so you can confirm that
the RX side is on-frequency?
On Wed, 2020-11-18 at 20:05 -0500, Marcus D. Leech wrote:
On 11/18/2020 07:34 PM, Dustin Widmann wrote:
On Wed, 2020-11-18 at 18:27 -0500, Marcus D. Leech via USRP-users
wrote:
Marcus,
Oh, sorry, I missed the first bit. I'm using the on-board clock.
And
perhaps I should explain the table with a little bit more detail:
* 1st col: The *target* frequency. The RX was tuned to this
frequency.
The TX was tuned to that frequency + an offset (in this case, 50KHz
for
all datapoints).
* 2nd col: Where the tone is expected to land, both bin and
(baseband)
frequency; in this case, a 50KHz offset for all datapoints, which
corresponded to bin 524 with a 2^20 FFT.
* 3rd col: where the tone was observed (both bin and frequency).
* 4th col: difference between the target and expectation
* 5th col: dsp freq (from uhd::tune_result_t.actual_dsp_freq)
* 6th col: what the difference would be if I offset the observed
frequency by the claimed dsp frequency
Dustin
Right, I understand the chart now.
So, this is rather odd.
I assume this is under timed commands, yes? What happens if you
don't
use timed commands--just to check to see
if the DSP frequency change is getting skipped under timed
commands?
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
