BNMR: RF calculator

• BNMR overview
• Getting started
• Troubleshooting
• All BNMR pages
• Midas

Introduction

The RF calculator (rf_calculator_fe.py) is responsible to converting questions the user answers on the custom settings page into settings that can be used by the frontend and MUD data logger. This keeps lots of "messy" logic all in one place, allowing the other programs to be much simpler.

The program does most of its work at the beginning of each run, but also exposes a JRPC interface so that web pages can ask it questions (e.g. the settings page can ask it to validate the current settings and produce a graph of the PPG timing scheme that will be run, so users can examine it before starting an actual run).

Sanity-checks

The RF calculator checks the current mode and ensures various settings in /Scanning are set correctly. For example, if the mode has the Allows constant time flag set to false, RF calculator will force /Scanning/Global/Settings/Enable constant time mode to false. If the mode has the Allows constant time flag set to true, then RF calculator does nothing, as the user is allowed to enable/disable constant time mode themselves.

This code is in bnxr_common/rf_calculator_fe.py itself.

RF/PSM computation

I,Q pairs

If the user has requested that RF modulation is enabled (e.g. ln-sech, Hermite, Wurst modulation), RF calculator computes a list if I,Q pairs to be loaded onto the PSM. The generated list depends on the bandwidth specified by the user, as well as the hardware characteristics of the PSM version being used (e.g. the PSM3 can store more pairs that the PSM1).

The computed values are stored in the ODB beneath /Scanning/PSM/Computed/. The frontend program knows to look here for the computed results.

This code is mostly in cycling_framework/psm/psm_calculator.py.

Frequency list

If the mode loads a non-trivial list of frequencies onto the PSM (i.e. something other than a linear scan), RF calculator is responsible for computing the list to load.

There are currently two distinct options:

• A "custom list" of frequencies that gets computed based on user parameters (e.g. the "fine frequency" scheme used in mode 1x). These get written to the ODB at /Scanning/PSM/Computed/Custom list at the start of the run or whenever the user changes the settings in the ODB.
• A "parametric" list of frequencies where the user specifies a different formula for each channel and the RF calculator evaluates those formulae for a given value x (e.g. mode 1w). Currently the frontend calls the RF calculator via RPC to evaluate the formulae for a given range of x at the start of each run. The values are not currently stored in the ODB, though they could be.

In future, it would be reasonable to standardize the method of passing computed results between the RF calculator and frontend (either both options use the ODB or both use RPC).

This code is mostly in bnxr_common/rf_calculator_fe.py itself.

PPG computation

The PPG compiler needs a "program" to compile into bytecode. RF calculator creates this program for a given mode based on timing parameters and feature flags the user has set on the settings page. The programs are generated dynamically in python code, then converted to an ODB structure in /Equipment/PPGCompiler/Programming that the compiler will read.

Many timing modes are simple, with the user just specifying various time offsets. Others are more complex, with channels/pulses being enabled/disabled based on questions the user answers. For example, RF is optional in some modes, so pulses to enable the PSM gate must be enabled/disabled as appropriate.

The programs for each mode were generated based on a set of "template files" from the legacy DAQ. New timing schemes can be implemented directly in the code.

This code is mostly in bnxr_common/ppg_prog_helper.py.

MUD independent variable links

Some ODB parameters get recorded in the final MUD file. RF calculator makes an ODB directory of links to these parameters, as explained on the data logging page. Some of these values are parameters directly specified by the user, whilst others are derived quantities that are only used in the MUD file and nowhere else in the DAQ (for backwards-compatibility purposes with older files). These derived quantities are written to /Equipment/RFCalculator/Computed/Extra mud ind var.

The full list of quantities to be logged are stored as links in /Equipment/RFCalculator/Computed/Mud links/PPG/PPG20 etc (for mode 20).

This code is in bnxr_common/ppg_prog_helper.py and bnxr_common/mud_ind_var_links.py.