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