diff options
author | Martin Braun <martin.braun@ettus.com> | 2022-03-18 11:56:09 +0100 |
---|---|---|
committer | Aaron Rossetto <aaron.rossetto@ni.com> | 2022-03-28 12:48:28 -0700 |
commit | c176425b852bca6f80141e66ea021f4d6bba3a9d (patch) | |
tree | 1a1bda4e8b3b8c65e2f6c74da452c3007aa8f643 /host/docs | |
parent | 7a59bb82da7f0108e0a41980d8a08a8073d91b3b (diff) | |
download | uhd-c176425b852bca6f80141e66ea021f4d6bba3a9d.tar.gz uhd-c176425b852bca6f80141e66ea021f4d6bba3a9d.tar.bz2 uhd-c176425b852bca6f80141e66ea021f4d6bba3a9d.zip |
mpm: Make default clock/time source values state-less
Currently, the default clock/time source is whatever the user configured
in the last session.
This fixes the scenario were you have any MPM device and do this:
$ benchmark_rate --args $args,clock_source=external
But whoops! You forgot to attach an external 10 MHz. PLL lock fails,
nothing works. No worries, you run it again:
$ benchmark_rate --args $args
With the previous behaviour, this would retain the setting to
'external', because there's nothing to overwrite it. You would need to
append `clock_source=internal` to get a working device again. Calling
multi_usrp::set_clock_source("internal"), or a similar API call, might
not be sufficient because the PLL lock failure might crash the program
before updating the clock source is possible.
The problem with this is twofold:
- All non-MPM devices behave differently, i.e., they have a fixed
default ('internal') which is always applied if no other option is
given. This is an internal inconsistency.
- Some applications (like gr-uhd's GRC bindings) simply don't set
a clock/time source when selecting a "default", or they try and update
the clock/time source using the API calls.
Therefore, we align the behaviour of MPM devices with the other devices,
and fall back to an internal source if nothing else is provided.
Diffstat (limited to 'host/docs')
0 files changed, 0 insertions, 0 deletions