dcmMETable

{
  "smi_kind": "OBJECT-TYPE",
  "definition": [
    "dcmMETable",
    "OBJECT-TYPE",
    "SYNTAX",
    "SEQUENCE",
    "OF",
    "DcmMEEntry",
    "ACCESS",
    "not-accessible",
    "STATUS",
    "optional",
    "DESCRIPTION",
    "\"This table is single-indexed by study number. It is used to control and read the state of each ‘Monitor Study’. A Binned Monitor Study shall return the bin counts for the current recording interval as defined by the ‘Data’ column of the Data Structure Table for Binned Data (note that in asciiData Monitor Modes, the number of octets per binned count is not sent). A PVR Monitor Study shall return one or more PVR/s as defined by the ‘Data’ column of the Data Structure Table for PVR Data (note that in asciiData Monitor Modes, the dcm device may translate the vehicle time tag to a more user friendly format (e.g. ‘mm/dd/yy hh:mm:ss’). An Event Monitor Study shall return one or more sensor events (Logical IO Events) as defined by the ‘Data’ column of the Data Structure Table for Event Data (note that in asciiData Monitor Modes, the ascii hex representation of each event record field will be sent since event records are defined in bits). The ‘Data’ column of the Data Structure Table is an OCTET STRING, it will contain the length of the data returned by the device for each type of Monitor Mode 2 (binary data). The OCTET STRING identifier and length field is not included for asciiData Monitor Modes. Note that it may possible for vehicles or sensor events (Logical IO events) to be missed if the device does not have sufficient buffer space to hold the data before being polled (specifically in Monitor Mode 2). This should only occur with either PVR or Event Monitor Studies. There currently is no mechanism to notify the central application that a data over-run has occurred. The best approach (if possible) would be to use Monitor Mode 1 allowing the device to stream out the data as it occurs. This however requires that the central application can keep up with the streamed data. Monitor Studies are typically used to verify operation of sensors and sensor arrays. For example, if the data in collected data files appear to be invalid, a user may want to configure an ‘Event Monitor Study’ (in the Study Configuration Table) that incorporates the same sensors in which the invalid data has been produced by. The user would then enable the ‘Event Monitor Mode’ from within this table. The user would examine the event data returned by the device to determine if all of the specified sensors appear to be operating correctly. Monitor Studies are typically turned on for a short period of time and then disabled. The data is sent to a hardware communications port and not saved to a data file. The study specified in this table must point to a ‘Monitor Study’. A ‘Monitor Study’ is defined as any study that has been configured in the Study Configuration Table with it’s ‘Study File Index’ set to 0. The asciiData Monitor Modes are intended to provide user-readable output without interpretation and is included for historical purposes. The Row Admin field is not required in this table. If a study is deleted from the Study Configuration Table, the device shall also delete any row associated with the same study number from this table.\"",
    "::=",
    "{",
    "dcmStudyDataSetup",
    "26",
    "}"
  ],
  "syntax_tree": [
    [
      "conceptualTable",
      [
        "row",
        "DcmMEEntry"
      ]
    ],
    null,
    [
      "MaxAccessPart",
      "not-accessible"
    ],
    [
      "Status",
      "optional"
    ],
    [
      "DESCRIPTION",
      "This table is single-indexed by study number. It is used to control and read the state of each ‘Monitor Study’. A Binned Monitor Study shall return the bin counts for the current recording interval as defined by the ‘Data’ column of the Data Structure Table for Binned Data (note that in asciiData Monitor Modes, the number of octets per binned count is not sent). A PVR Monitor Study shall return one or more PVR/s as defined by the ‘Data’ column of the Data Structure Table for PVR Data (note that in asciiData Monitor Modes, the dcm device may translate the vehicle time tag to a more user friendly format (e.g. ‘mm/dd/yy hh:mm:ss’). An Event Monitor Study shall return one or more sensor events (Logical IO Events) as defined by the ‘Data’ column of the Data Structure Table for Event Data (note that in asciiData Monitor Modes, the ascii hex representation of each event record field will be sent since event records are defined in bits). The ‘Data’ column of the Data Structure Table is an OCTET STRING, it will contain the length of the data returned by the device for each type of Monitor Mode 2 (binary data). The OCTET STRING identifier and length field is not included for asciiData Monitor Modes. Note that it may possible for vehicles or sensor events (Logical IO events) to be missed if the device does not have sufficient buffer space to hold the data before being polled (specifically in Monitor Mode 2). This should only occur with either PVR or Event Monitor Studies. There currently is no mechanism to notify the central application that a data over-run has occurred. The best approach (if possible) would be to use Monitor Mode 1 allowing the device to stream out the data as it occurs. This however requires that the central application can keep up with the streamed data. Monitor Studies are typically used to verify operation of sensors and sensor arrays. For example, if the data in collected data files appear to be invalid, a user may want to configure an ‘Event Monitor Study’ (in the Study Configuration Table) that incorporates the same sensors in which the invalid data has been produced by. The user would then enable the ‘Event Monitor Mode’ from within this table. The user would examine the event data returned by the device to determine if all of the specified sensors appear to be operating correctly. Monitor Studies are typically turned on for a short period of time and then disabled. The data is sent to a hardware communications port and not saved to a data file. The study specified in this table must point to a ‘Monitor Study’. A ‘Monitor Study’ is defined as any study that has been configured in the Study Configuration Table with it’s ‘Study File Index’ set to 0. The asciiData Monitor Modes are intended to provide user-readable output without interpretation and is included for historical purposes. The Row Admin field is not required in this table. If a study is deleted from the Study Configuration Table, the device shall also delete any row associated with the same study number from this table."
    ],
    null,
    null,
    null,
    null
  ]
}