7.4.1 Device driver syntax for SNMP definitions

SNMP definitions are coded in the device driver file as special comment lines. This ensures, that new device drivers which include SNMP definitions can be run on older sat-nms systems which where delivered before this SNMP feature was introduced.

SNMP definitions involve two keywords, @class and @varbind . @class makes the device member of a certain device class and creates a row for tis device in the table of the referenced device class. @varbind maps a SNMP OID to a certain sat-nms driver variable. All @varbind definitions following a @class definition refer to this and may only map OID names which are valid for the device class defines above.

The example below explains how to define the SNMP mapping for a device:

    // @class   HPA
    // @varbind mncHpaTxOn         tx.on
    // @varbind mncHpaAttenuation  tx.attn
    // @varbind mncHpaOutputPower  tx.measuredLevel
    // @varbind mncHpaHelixCurrent meas.iHelix
    // @varbind mncHpaState        state

The @class definition identifies the device as a power amplifier and creates an instance for the device in the HPAs table. @class and the class name must appear in the same line and there must not be any trailing text right of the class name in the line. A list of valid class names may be found in chapter List of SNMP device classes and OID names The @varbind definitions below map the OIDs defined for one row of the HPA table to the corresponding variables in the driver. Each @varbind keyword must be followed by a valid OID name for this device class and then by the name of a device driver variable. Again, all three words must appear in the same line to be recognized correctly.

As mentioned above, a device may be part of multiple device classes at a time, it also may create multiple rows in the same SNMP table to map identical modules in the device to 'copies' of the device in the table. The example below illustrates this for a dual block upconverter:

    // @class   BUC 1
    // @varbind mncBucTxOn        tx.on.1
    // @varbind mncBucInputAtten  tx.attn.1
    // @class   BUC 2
    // @varbind mncBucTxOn        tx.on.2
    // @varbind mncBucInputAtten  tx.attn.2

Two @class definitions create two rows in the BUC table of the MIB. The number 1, 2 following the class name set the module index in the table, this can be used to differentiate between the two BUCs.

Device drivers maintained by SatService always list all @varbind OIDs defined for the @class of the device. Parameters which have no mapping for the particular device driver are listed with !varbind instead of @varbind. This prevents the parser from binding this OID to a variable of the driver, at the same time the complete list of @varbind OIDs stays visible in the device driver text for reference.

With the mncTarSelTargets @varbind (links the target names defined by a SatService ACU-ODM into the MIB), the software uses a * wildcard to denote the position of the target index in the sat-nms variable name:

    // @class   TARSEL
    // @varbind mncTarSelMoveToTarget      target.goto
    // @varbind mncTarSelTargets           target.*