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
