mirror of
https://github.com/saymrwulf/uhd.git
synced 2026-05-15 21:01:26 +00:00
c176425b85
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.
|
||
|---|---|---|
| .. | ||
| pyusrp_periphs | ||
| tests | ||
| usrp_mpm | ||
| aurora_bist_test.py | ||
| CMakeLists.txt | ||
| copy_python_module.cmake | ||
| e320_bist | ||
| n3xx_bist | ||
| setup.py.in | ||
| socket_test.py | ||
| test_lmk.py | ||
| usrp_hwd.py | ||
| usrp_update_fs | ||
| x4xx_bist | ||