ClockManager

ClockManager owns the live Clock instances for the active hardware loadout, maps each RfConfig::ClockType role to the physical clock object that serves it, and mediates all configure and read operations that flow between HardwareManager and the underlying oscillator hardware. It inherits from SettingsStorage and persists the available clock output table so that the RF configuration UI can present the correct options without querying live hardware.

ClockManager is created by HardwareManager and runs on the HardwareManager thread. HardwareManager holds it via std::unique_ptr<ClockManager> pu_clockManager and calls setClocksFromHardwareManager() to hand off the current set of Clock pointers after any hardware sync cycle. When the runtime hardware map changes, HardwareManager calls updateClockManager() to rebuild the internal clock list and re-emit routing signals. Direct calls from other threads must go through HardwareManager’s queued connections — ClockManager’s public slots are not safe to invoke directly across thread boundaries.

Primary collaborators: HardwareManager (owner, signal forwarder, and caller of setClocks / configureClocks); RfConfig (source of the RfConfig::ClockType enum used as the routing key and of the RfConfig::ClockFreq descriptor passed in clock maps); HardwareLoadout (clock assignments are part of the loadout’s RF section and are persisted per FTMW preset). The Clock base class is a HardwareObject; ClockManager does not own the Clock objects — it borrows raw pointers from HardwareManager.

Clock-routing model

Each RfConfig::ClockType role (UpLO, DownLO, AwgRef, DRClock, DigRef, ComRef) is satisfied by exactly one Clock object paired with an output index on that clock. A single Clock device may expose multiple independent outputs (for example the Valon 5009 has two independently tunable channels), so one physical device can simultaneously satisfy several distinct roles — each on a different output port.

Internally, d_clockRoles maps every currently active ClockType to the Clock that serves it. d_clockList holds the full set of Clock objects that HardwareManager has provided; entries in d_clockRoles are always a subset of that list. When configureClocks() is called, the existing role map is cleared, each entry in the incoming QHash<ClockType, ClockFreq> is resolved against d_clockList by hardware key, the matching clock’s output is registered via Clock::addRole(), and the multiplication factor is written to the output via Clock::setMultFactor(). Roles that were present before the call but absent from the new map receive a clockHardwareUpdate(type, "", -1) signal so consumers know the role is no longer active.

The multiplication factor in RfConfig::ClockFreq accounts for clocks whose oscillator output frequency differs from the logical RF frequency by a fixed multiply-or-divide relationship (e.g., a ×2 doubler stage). When the factor is less than 1.0 the operation is RfConfig::Divide; otherwise it is RfConfig::Multiply.

The available clock outputs are persisted in SettingsStorage under the BC::Key::ClockManager::hwClocks array so that the RF configuration dialog can populate its output selector without polling live hardware.

Configuration flow

The typical configure path during experiment preparation is:

HardwareManager::initializeExperiment() calls ClockManager::prepareForExperiment(Experiment &exp).
prepareForExperiment() extracts the clock map from exp.ftmwConfig()->d_rfConfig.getClocks() and passes it to configureClocks().
configureClocks() resolves each ClockType → Clock* binding, sets the multiplication factor, calls Clock::setFrequency() on each affected output, and emits clockHardwareUpdate() for every newly assigned role.
After configureClocks() returns, prepareForExperiment() writes the achieved frequencies back into exp via RfConfig::setCurrentClocks(getCurrentClocks()).
When a mid-acquisition clock step requires a frequency change, MainWindow::clockPrompt calls HardwareManager::setClocks() via QMetaObject::invokeMethod; HardwareManager gates the FTMW digitizer during the transition and emits HardwareManager::allClocksReady() when all clocks have settled. That signal is connected directly to AcquisitionManager::clockSettingsComplete, which gates progression to the next acquisition step.

Frequency reads (readClockFrequency(), readActiveClocks()) forward directly to Clock::readFrequency(). Each Clock emits frequencyUpdate(ClockType, double); setupClocks() connects that signal to ClockManager::clockFrequencyUpdate, which HardwareManager then re-emits to the rest of the system.

For the end-user view of clock assignment see RF Configuration and FTMW Presets.

API Reference

class ClockManager : public QObject, public SettingsStorage 

Routes RF clock operations to the correct Clock hardware objects by role.

ClockManager owns the role-to-hardware mapping for all clock sources in the active loadout. Each RfConfig::ClockType role (e.g., UpLO, DownLO, AwgRef) is served by exactly one Clock object on one of that clock’s numbered outputs. A single physical clock may serve multiple roles on different outputs simultaneously.

ClockManager is created and owned by HardwareManager (pu_clockManager) and runs on the HardwareManager thread. HardwareManager hands off the current Clock* pointers via setClocksFromHardwareManager() after each hardware sync cycle, and calls updateClockManager() whenever the set of available clocks changes. Direct invocation of ClockManager slots from other threads is not safe; all cross-thread callers must go through HardwareManager's queued connections.