Could you confirm which version of UHD you’re using? There has historically been a problem using both TwinRx and UBX on the same X310 due to clocking requirement conflicts.
But that has been fixed in UHD4 Want to eliminate that as a possibility first. Sent from my iPhone > On Nov 23, 2020, at 11:42 AM, Dustin Widmann <dw...@virginia.edu> wrote: > > Marcus, > > I do have access to sig gens, but I would have to take everything into town > to do that. (sanest thing to do during covid > was to bring portable things home...) > > What I do have handy though is a spectrum analyzer (albeit, not a > particularly good one, but when working with a narrow > span it should be able to give results that are good enough) > > What I observed is this: > tx freq MHz meas freq [MHz] deviation [Hz] 60.050 60.048800 > 1200 > 61.050 61.050100 -100 > 62.050 62.051200 -1200 > 63.050 63.052533 -2533 > 64.050 64.053600 -3600 > 65.050 65.054933 -4933 > 66.050 66.044000 6000 > 67.050 67.045067 4933 > 68.050 68...... Missed this one > 69.050 69.047733 2267 > 70.050 70.048800 1200 > > > For reference, what I observed with the twinrx was as follows > freq target bin/freq actual bin/freq diff bin/freq dsp > freq > 60MHz 524.288 (50e3) 512 (48,828) 12.288 (1,172) 1160 > > 61MHz 524.288 (50e3) 525 (50,068) -0.712 (-68) -61 > > 62MHz 524.288 (50e3) 538 (51,308) -13.712 (-1,308) -1282 > > 63MHz 524.288 (50e3) 551 (52,547) -26.712 (-2,547) -2503 > > 64MHz 524.288 (50e3) 563 (53,692) -38.712 (-3,692) -3724 > > 65MHz 524.288 (50e3) 576 (54,932) -51.712 (-4,932) -4945 > > 66MHz 524.288 (50e3) 461 (43,964) 63.288 (6,036) 6044 > > > Having taken the TwinRX out of the loop, it seems I'm getting very similar > results. > > Dustin > > >> On Sat, 2020-11-21 at 13:43 -0500, Marcus D. Leech wrote: >>> 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
