Two Channel Vibration Sensor V4 User Manual

Explore the Two Channel Vibration Sensor V4 Capabilities

Click Here

Device Overview

Introducing NCD’s Two Channel Vibration Sensor V4. Lightweight rugged and reliable for accurate asset monitoring and boasting up to a 2-mile range using a wireless mesh networking architecture & Incorporating a 16-bit Vibration and integrated Temperature sensor.

This sensor combines these data with temperature data in a data packet, and transmits the result to modems and gateways within wireless range.  Once transmission is complete, the vibration sensor goes back to sleep, thus minimizing power consumption.

  • Small & lightweight for ease of installation.
  • IP65 rated sealed enclosure for dust & moisture protection.
  • Metal probe housing for durability in harsh industrial environments.
  • D-cell battery for long-lasting operation.
  • A versatile user-configurable sample rate for slow or fast-running machines
  • Integrated temperature sensor in base.
  • In-Built Machine Learning optimizes power consumption.
  • Asset On-Time Calculator automatically tracks operational status.
  • Hardware Accelerator enhances vibration sampling accuracy.
  • Available Frequencies – 900Mhz, 868Mhz, and 2.4Ghz
  • Supports MESH networking via DigiMesh
  • Fully open Node-RED library for configuration and data ingestion

Hardware Controls

Power Switch

The power switch on this device has three positions:

  • Battery Power
  • Off
  • External Power

The Battery Power position will use the onboard batteries to power the sensor and transmit data.

The Off position will power down all components of the sensor and no data will be transmitted

The External Power position will use the external power supply connected to the onboard barrel connector to power the sensor and transmit data.

Enclosure Type 1 -> Click to expand
Enclosure Type 2 -> Click to expand

RESET Button

The RESET button will power cycle the sensor. When the sensor first powers up it will send a sensor_mode message with the mode of RUN.

Enclosure Type 1 -> Click to expand
Enclosure Type 2 -> Click to expand

CFG Button

The CFG button serves two functions.

The first is change the mode of the sensor when pressed immediately after a power cycle of the sensor. See section Configuration Button Timing Overview for more information on this.

The second is to test for the presence of power on the sensor. If the CFG button is pressed the TEST LED on the board will light up indicating that the board has power. If no LED comes on check that the Power Switch is in the correct position and that the battery/power supply is good.

Enclosure Type 1 -> Click to expand
Enclosure Type 2 -> Click to expand

Hardware Mode Selection

Run Mode

Run Mode is the default state of the sensor when powered up. No hardware interaction is necessary to enter this state other than power. Pressing the Reset button will restart the sensor and put it in the RUN Mode state if no other buttons are pressed.

Configuration Mode

Configuration Mode is the state in which the sensor enters in order to change the sensor’s configurable parameters such as Reporting Interval, Transmission Power, and Network ID. When the sensor is in Configuration Mode it will change the settings of the wireless protocol temporarily. The network ID of PGM Mode is 7BCD.

You can enter in this mode by pressing and releasing the RESET button and then immediately pressing and holding the CFG button for ~5 seconds. Refer to the graph below for the precise timing of the CFG button press.

This is a temporary mode that is not intended for long-term operation. You will need to Reset the device after a successful configuration in order to resume normal operations.

See section Sensor Configuration Processes for more information on this configuration process.

Factory Default/Reset

A Factory Reset of the sensor will revert all changes and configurations made to the sensor to their default settings from the Factory. Immediately after a factory reset the sensor will go into Configuration Mode in order to be reconfigured with the desired settings.

You can perform a Factory Reset by pressing and release the RESET button, wait for a second, then press and hold the CONFIGURATION button, hold the CONFIGURATION button for more than 15 seconds, release CONFIGURATION button.

Immediately after a factory reset the sensor will go into Configuration Mode in order to be reconfigured with the desired settings. To activate RUN Mode, please wait for 3-5 seconds and then press the RESET button.

Refer to the graph below for the precise timing of the CONFIGURATION button press.

Configuration Button Timing Overview

  • Press and Release the RESET button
  • Configuration Button Pressed and held 1 second after reset for:
    • < 2 second – device starts normally in RUN Mode
    • 2 to 15 seconds – device goes into Configuration Mode
    • > 15 seconds – the device reverts back to the Factory Default Settings, which is followed by a Configuration Mode Frame
Click to enlarge

Default Configuration

ParameterDefault Value (Probe 1)Default Value (Probe 2)UnitNote
Output Data Rate1280012800Hz
Sampling Duration11sec
Low Pass Filter44
High Pass Filter20482048
Full Scale Range88g
Sampling Interval3030min
Filter StatusEnabledEnabled
Operation Mode3 - Smart3 - Smart
Data on Request Timeout11sec
Acceleration Dead Band2020mg
Acceleration Wake/Interrupt Threshold1010mg10*50 = 500mg
Payload Length180180bytes
Auto Raw IntervalDisabledDisabled
Auto Raw Destination Address0000FFFF0000FFFFhex
Smart Mode Skip Interval33
FLY Interval6060min
RPM Calculate StatusEnabledEnabled
Max Raw Sample40964096
Real-Time ClockDisabledDisabled
Clear Probe UptimersDisabledDisabled
Smart Mode Threshold1010mg10*50 = 500mg

Software Integration - Node-Red Overview

We built our primary software drivers into a software system called Node-Red. Node-Red is a visual based drag-and-drop low/no code flow builder. It allows you to build simple or complex logic and data dissemination applications quickly and easily. It can integrate with third party software/cloud services using a number of protocols such as MQTT, HTTP(S), TCP, UDP, and OPC UA.

For more information and a general introduction on what Node-Red is and how it works you can view Node-Red’s official web site at https://nodered.org/.

All Enterprise Gateway we offer will come with Node-Red and our library running as a service by default to allow quick and easy access to Node-Red and the sensor data from our sensors. If you are using your own gateway or computer you will need a USB or Ethernet Modem, Node-Red, and our library @ncd-io/node-red-enterprise-sensors.

You can find our library on Node-Red with the name: @ncd-io/node-red-enterprise-sensors

In this section will will go over the nodes introduced by our library, what kind of data they will provide your flow, and how to use them.

Wireless Gateway Nodes

Wireless Gateway Nodes are a virtual representation of the wireless protocol connected to your Gateway. They will output all incoming data from the wireless network and all of the sensors on that network into the connected flows from a single entry point.

This is the recommended method for ingesting data from large numbers of sensors at a single location in order to simplify data handling and reduce the complexity of the resulting flow.

Wireless Gateway Node Statuses

Wireless Gateway nodes have multiple states they can show in Node-Red to indicate their current mode or functionality.

Ready State

When the Wireless Gateway Node’s status indicates “Ready”, as shown in the picture on the right, it means that the wireless network is successfully connected to Node-Red and is ready to receive data from the sensor(s). Sensors that support FLY messages can be automatically configured while in this mode if a corresponding Wireless Device node is configured to do so. See section Sensor Configuration Processes for more information.
Wireless Gateway in the Ready State

Configuring State

When the Wireless Gateway Node’s status indicates “Configuring”, as shown in the picture on the right, it means that the wireless network is successfully connected to Node-red and is ready to configure any sensors entering Configuration Mode.

Any sensor put into configuration mode through the use of the Reset and CFG buttons will be seen by the gateway while in this mode. If Node-Red has a corresponding Wireless Device node for the sensor reporting in then Node-Red will begin configuring that sensor if set to do so. You can enter Config mode or leave Config mode to resume Normal Operations using the button on the left side of the node.

When the Wireless Gateway is in this mode the Wireless Network will change to the Configuration Network. This means that the network ID will change to 7BCD.

Wireless Gateway in Configuration Mode

Failed to Connect State

When the Wireless Gateway Node’s status indicates “Failed to Connect”, as shown in the picture on the right, it means that Node-Red was unable to connect to the wireless network. This usually indicates that incorrect settings were used while configuring the Gateway.

For more information on configuring your Wireless Gateway Node’s communications see section Wireless Gateway Node Configuration.

For more information on troubleshooting your Wireless Gateway Node’s communications see section Troubleshooting

Wireless Gateway node Failed to Connect State

Connecting State

When the Wireless Gateway Node’s status indicates “Connecting…”, as shown in the picture on the right, it means that Node-Red is waiting to initialize the connection to the Wireless Network. This state will last for 5 seconds before Node-Red attempts to open communication to ensure that all hardware and software is initialized.

No incoming or outgoing data will be handled while in this state. 

Wireless Gateway Node Connecting State

No State

When the Wireless Gateway Node has no status indication, as shown in the picture on the right, it means that the node is not configured properly and no communications have been indicated for the node. For more information on configuring the Wireless Gateway Node see section Wireless Gateway Node Configuration.

Wireless Gateway Node Messages

All messages from the Wireless Gateway Node will come through as Javascript Objects and are output by default as JSON representations when viewed or sent over most protocols. In Node-Red the primary object to reference the message will be msg. You can access sub-properties using msg.payload or msg.payload.nodeId etc.

Wireless Gateway Sensor Data Message (Processed)

Sensor data is the primary message that will come from a Wireless Gateway Node. These messages can be discerned from other message types by the topic which will always be “sensor_data”

To the right is an example of a Sensor Data message.

  • nodeID
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
    • For a unique identifier it is recommended to use the “addr” property as it is tied to the individual sensor’s wireless module and will always be unique
  • firmware
    • This identifies the firmware version of the sensor sending the packet
  • battery
    • The current voltage level of the batteries at the time of transmission
    • The batteries that come with the sensors drop off quickly once they reach 2.6 volts
  • battery_percent
    • The current battery percent at the time of transmission
  • counter
    • The number of transmissions since boot or counter rollover
    • The counter will rollover after a counter value of 255
  • sensor_type
    • The machine identifiable type of the sensor
    • It is recommended to use this property to dictate dashboard generation and/or data integrity checks
  • sensor_data
  • sensor_name
    • Human Readable Sensor Type Identifier
  • type
    • An easily passed message type declaration
    • This property will be a duplicate of msg.topic
  • addr
    • The unique identifier of the sensor that transmitted the data
  • received
    • Epoch indicator of when the data was received by Node-Red
  • original
    • Auxiliary information on the packet and underlying protocol
  • modem_mac
    • The unique identifier of the Gateway/Modem that received the data
    • Primarily used to tie locations/projects to sensors/sensor data
				
					{
  "topic": "sensor_data",
  "payload": {
    "nodeId": 0,
    "firmware": 14,
    "battery": "3.28",
    "battery_percent": "98.56",
    "counter": 26,
    "sensor_type": 111,
    "sensor_data": {
        "mode":0,
        "msg_type": "regular",
        "s1_odr":"800Hz",
        "s1_temperature":23.67,
        "x1_rms_ACC_G": 0.001,
        "x1_max_ACC_G": 0.002,
        "x1_velocity_mm_sec": 0.03,
        "x1_displacement_mm": 0.04,
        "x1_peak_one_Hz": 5,
        "x1_peak_two_Hz": 6,
        "x1_peak_three_Hz": 7,
        "y1_rms_ACC_G": 0.008,
        "y1_max_ACC_G": 0.009,
        "y1_velocity_mm_sec": 0.1,
        "y1_displacement_mm": 0.11,
        "y1_peak_one_Hz": 12,
        "y1_peak_two_Hz": 13,
        "y1_peak_three_Hz": 14,
        "z1_rms_ACC_G": 0.015,
        "z1_max_ACC_G": 0.162,
        "z1_velocity_mm_sec": 1.63,
        "z1_displacement_mm": 1.64,
        "z1_peak_one_Hz": 165,
        "z1_peak_two_Hz": 166,
        "z1_peak_three_Hz": 256,
        "rpm_1": 167
        "s2_odr":"800Hz",
        "s2_temperature":23.67,
        "x2_rms_ACC_G": 0.001,
        "x2_max_ACC_G": 0.002,
        "x2_velocity_mm_sec": 0.03,
        "x2_displacement_mm": 0.04,
        "x2_peak_one_Hz": 5,
        "x2_peak_two_Hz": 6,
        "x2_peak_three_Hz": 7,
        "y2_rms_ACC_G": 0.008,
        "y2_max_ACC_G": 0.009,
        "y2_velocity_mm_sec": 0.1,
        "y2_displacement_mm": 0.11,
        "y2_peak_one_Hz": 12,
        "y2_peak_two_Hz": 13,
        "y2_peak_three_Hz": 14,
        "z2_rms_ACC_G": 0.015,
        "z2_max_ACC_G": 0.162,
        "z2_velocity_mm_sec": 1.63,
        "z2_displacement_mm": 1.64,
        "z2_peak_one_Hz": 165,
        "z2_peak_two_Hz": 166,
        "z2_peak_three_Hz": 256,
        "rpm_2": 167
    },
    "sensor_name": "Two Channel Vibration Plus v4",
    "type": "sensor_data",
    "addr": "00:13:a2:00:42:37:73:52",
    "received": 1721424191583,
    "original": {...},
    "modem_mac": "00:13:A2:00:41:F5:2C:D3"
  },
  "time": 1721424191584,
  "_msgid": "d7f3341ef39225df"
}
msg.payload.sensor_data Breakdown
  • mode
    • The sensor works in one of 3 modes:
      • 0 – Processed – FFT is performed by the sensor and the measurement data is presented in condensed form (both time and frequency parameters)
      • 1 – Raw/time domain – the Raw/time domain data is gathered and transmitted and it is up to the client to perform the FFT if needed. This is a very large data packet.
      • 2 – Оn demand, sending Processed data regularly, with the option to request a Raw/time domain data packet
      • 3 – Smart – a cutting-edge operational setting. In this mode, the sensor delivers Processed Data (Overall Data) at user-defined intervals, with a Time Domain on Request option for requesting detailed Raw data packets, complemented by an Auto Raw Interval that dictates how often the sensor automatically transmits Raw measurement data for continuous insights. It features smart mode threshold, triggering data transmission when RMS acceleration exceeds a user-set value on any X, Y, or Z axis, alongside smart skip threshold, which intelligently skips sending data a specified number of times when vibrations fall below the threshold, optimizing efficiency, paired with 24/7 sampling to capture spontaneous issues—ideal for intermittent machine operation—ensuring real-time adaptability and comprehensive monitoring with precision.
  • msg_type
    • The message type:
      • regular – data send over regular intervals
      • motion – data triggered by the vibration crossing a predefined threshold
  • s1_odr
    •  This is the Vibration sample rate in Hz
  • ts1_emperature
    •  The temperature measured by the temperature sensor in Celsius
  • x1_rms_ACC_G
    •  The RMS Acceleration over the X axis in G
  • x1_max_ACC_G
    •  The MAX Acceleration over the X axis in G
  • x1_velocity_mm_sec
    •  The Velocity over the X axis in mm/sec
  • x1_displacement_mm
    •  The Displacement over the X axis in mm
  • x1_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • x1_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • x1_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • y1_rms_ACC_G
    •  The RMS Acceleration over the Y axis in G
  • y1_max_ACC_G
    •  The MAX Acceleration over the Y axis in G
  • y1_velocity_mm_sec
    •  The Velocity over the Y axis in mm/sec
  • y1_displacement_mm
    •  The Displacement over the Y axis in mm
  • y1_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • y1_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • y1_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • z1_rms_ACC_G
    •  The RMS Acceleration over the Z axis in G
  • z1_max_ACC_G
    •  The MAX Acceleration over the Z axis in G
  • z1_velocity_mm_sec
    •  The Velocity over the Z axis in mm/sec
  • z1_displacement_mm
    •  The Displacement over the Z axis in mm
  • z1_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • z1_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • z1_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • rpm_1
    • The rate of rotation of the machine in revolutions per minute
  • s2_odr
    •  This is the Vibration sample rate in Hz
  • s2_temperature
    •  The temperature measured by the temperature sensor in Celsius
  • x2_rms_ACC_G
    •  The RMS Acceleration over the X axis in G
  • x2_max_ACC_G
    •  The MAX Acceleration over the X axis in G
  • x2_velocity_mm_sec
    •  The Velocity over the X axis in mm/sec
  • x2_displacement_mm
    •  The Displacement over the X axis in mm
  • x2_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • x2_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • x2_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • y2_rms_ACC_G
    •  The RMS Acceleration over the Y axis in G
  • y2_max_ACC_G
    •  The MAX Acceleration over the Y axis in G
  • y2_velocity_mm_sec
    •  The Velocity over the Y axis in mm/sec
  • y2_displacement_mm
    •  The Displacement over the Y axis in mm
  • y2_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • y2_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • y2_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • z2_rms_ACC_G
    •  The RMS Acceleration over the Z axis in G
  • z2_max_ACC_G
    •  The MAX Acceleration over the Z axis in G
  • z2_velocity_mm_sec
    •  The Velocity over the Z axis in mm/sec
  • z2_displacement_mm
    •  The Displacement over the Z axis in mm
  • z2_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • z2_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • z2_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • rpm_2
    • The rate of rotation of the machine in revolutions per minute

Wireless Gateway Sensor Data Message (Raw/time domain)

Sensor data is the primary message that will come from a Wireless Gateway Node. These messages can be discerned from other message types by the topic which will always be “sensor_data”

To the right is an example of a Sensor Data message.

  • nodeID
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
    • For a unique identifier it is recommended to use the “addr” property as it is tied to the individual sensor’s wireless module and will always be unique
  • firmware
    • This identifies the firmware version of the sensor sending the packet
  • battery
    • The current voltage level of the batteries at the time of transmission
    • The batteries that come with the sensors drop off quickly once they reach 2.6 volts
  • battery_percent
    • The current battery percent at the time of transmission
  • counter
    • The number of transmissions since boot or counter rollover
    • The counter will rollover after a counter value of 255
  • sensor_type
    • The machine identifiable type of the sensor
    • It is recommended to use this property to dictate dashboard generation and/or data integrity checks
  • sensor_data
  • sensor_name
    • Human Readable Sensor Type Identifier
  • type
    • An easily passed message type declaration
    • This property will be a duplicate of msg.topic
  • addr
    • The unique identifier of the sensor that transmitted the data
  • received
    • Epoch indicator of when the data was received by Node-Red
  • original
    • Auxiliary information on the packet and underlying protocol
  • modem_mac
    • The unique identifier of the Gateway/Modem that received the data
    • Primarily used to tie locations/projects to sensors/sensor data
				
					{
  "topic": "sensor_data",
  "payload": {
    "nodeId": 0,
    "firmware": 14,
    "battery": "3.28",
    "battery_percent": "98.56",
    "counter": 26,
    "sensor_type": 111,
    "sensor_data": {
        "mode":1,
        "msg_type": "regular",
        "probe": 1,
        "time_id":"0:20",
        "mac_address": "00:13:a2:00:42:53:64:53",
        "fsr": "8g",
        "odr": 827,
        "device_temp": 19.56
        "data": {
           "x": [-0.07, 0.1, ...],
           "y": [0, 0, ...],
           "z": [0, 0, ...]
  },
        }
    },
    "sensor_name": "Two Channel Vibration Plus v4",
    "type": "sensor_data",
    "addr": "00:13:a2:00:42:37:73:52",
    "received": 1721424191583,
    "original": {...},
    "modem_mac": "00:13:A2:00:41:F5:2C:D3"
  },
  "time": 1721424191584,
  "_msgid": "d7f3341ef39225df"
}
msg.payload.sensor_data Breakdown
  • mode
    • The sensor works in one of 3 modes:
      • 0 – Processed – FFT is performed by the sensor and the measurement data is presented in condensed form (both time and frequency parameters)
      • 1 – Raw/time domain – the Raw/time domain data is gathered and transmitted and it is up to the client to perform the FFT if needed. This is a very large data packet.
      • 2 – Оn demand, sending Processed data regularly, with the option to request a Raw/time domain data packet
      • 3 – Smart – a cutting-edge operational setting. In this mode, the sensor delivers Processed Data (Overall Data) at user-defined intervals, with a Time Domain on Request option for requesting detailed Raw data packets, complemented by an Auto Raw Interval that dictates how often the sensor automatically transmits Raw measurement data for continuous insights. It features smart mode threshold, triggering data transmission when RMS acceleration exceeds a user-set value on any X, Y, or Z axis, alongside smart skip threshold, which intelligently skips sending data a specified number of times when vibrations fall below the threshold, optimizing efficiency, paired with 24/7 sampling to capture spontaneous issues—ideal for intermittent machine operation—ensuring real-time adaptability and comprehensive monitoring with precision.
  • msg_type
    • The message type:
      • regular – data send over regular intervals
      • motion – data triggered by the vibration crossing a pre-define threshold
  • probe
    • this is the number of the probe that is measuring the vibration data
  • time_id
    •  The time when the reading was taken
  • mac_address
    •  The MAC address of the device (used to identify it on the network)
  • fsr
    • Full Scale Range of the sensor
  • odr
    • This is the Vibration sample rate in Hz
  • device_temp
    • The measured temperature
  • data
    • data over each of the enabled axis in “g”. You will have multiple samples here depending on the chosen rate

Wireless Gateway RUN Message

A RUN message received simply indicates that the sensor indicated in the msg.payload.mac is powered up and communicating with the wireless network. An example RUN message can be found on the right.
  • topic
    • Indicates the type of message this is
  • payload
    • Contains the primary data of the message
  • payload.mac
    • Indicates the unique address of the sensor sending the mode message
  • payload.type
    • Indicates the type of sensor sending the mode message
  • payload.nodeId
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
  • payload.mode
    • indicates the current mode of the sensor
  • payload.lastHeard
    • Timestamp of the message
				
					{
  "topic": "sensor_mode",
  "payload": {
    "mac": "00:13:a2:00:42:37:73:52",
    "type": 111,
    "nodeId": 0,
    "mode": "RUN",
    "lastHeard": 1721424191056
  },
  "time": 1721424191056,
  "_msgid": "f41dad7923ece27c"
}

Wireless Gateway PGM Message

A PGM message received indicates that the sensor indicated in the msg.payload.mac has been put into configuration mode using the onboard buttons. If Node-Red has a Wireless Device node with Auto Config selected corresponding to the sensor that sent the PGM then Node-Red will begin to configure that sensor. An example PGM message can be found on the right.
  • topic
    • Indicates the type of message this is
  • payload
    • Contains the primary data of the message
  • payload.mac
    • Indicates the unique address of the sensor sending the mode message
  • payload.type
    • Indicates the type of sensor sending the mode message
  • payload.nodeId
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
  • payload.mode
    • indicates the current mode of the sensor
  • payload.lastHeard
    • Timestamp of the message
				
					{
  "topic": "sensor_mode",
  "payload": {
    "mac": "00:13:a2:00:42:37:73:52",
    "type": 111,
    "nodeId": 0,
    "mode": "PGM",
    "lastHeard": 1721424000999
  },
  "time": 1721424000999,
  "_msgid": "36ac745134de68ee"
}

Wireless Gateway ACK Message

An ACK message indicates that the sensor indicated in the msg.payload.mac successfully received the command from Node-Red and is acknowledging successful completion. In most cases ACK messages will be received in response to configuration commands sent during Auto Config or FLY configuration. An example ACK message can be found on the right.
  • topic
    • Indicates the type of message this is
  • payload
    • Contains the primary data of the message
  • payload.mac
    • Indicates the unique address of the sensor sending the mode message
  • payload.type
    • Indicates the type of sensor sending the mode message
  • payload.nodeId
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
  • payload.mode
    • indicates the current mode of the sensor
  • payload.lastHeard
    • Timestamp of the message
				
					{
  "topic": "sensor_mode",
  "payload": {
    "mac": "00:13:a2:00:42:37:73:52",
    "type": 111,
    "nodeId": 0,
    "mode": "ACK",
    "lastHeard": 1721424002052
  },
  "time": 1721424002052,
  "_msgid": "6eeb3e249c6b583d"
}

Wireless Gateway PUM Message

A PUM message indicates that the sensor indicated in the msg.payload.mac has been factory reset. A PGM message will come from the sensor immediately after a PUM message is received so you can configure the factory reset sensor. Even if no configuration is triggered by the subsequent PGM message a reset of the sensor is required after factory reset to resume normal operation. An example PUM message can be found on the right.
  • topic
    • Indicates the type of message this is
  • payload
    • Contains the primary data of the message
  • payload.mac
    • Indicates the unique address of the sensor sending the mode message
  • payload.type
    • Indicates the type of sensor sending the mode message
  • payload.nodeId
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
  • payload.mode
    • indicates the current mode of the sensor
  • payload.lastHeard
    • Timestamp of the message
				
					{
  "topic": "sensor_mode",
  "payload": {
    "mac": "00:13:a2:00:42:37:73:52",
    "type": 111,
    "nodeId": 0,
    "mode": "PUM",
    "lastHeard": 1721424000789
  },
  "time": 1721424000789,
  "_msgid": "e361ba7bdfe0bc4b"
}

Wireless Gateway FLY Message

A FLY message indicates that the sensor is in RUN mode, but is entering a temporary state where it can be configured. The sensor will send the FLY message on boot and once an hour after boot to check in. Once the sensor sends a FLY message Node-Red has 2 seconds to respond with a configuration or extend this temporary configuration mode.

If Node-Red has a Wireless Device node with Auto Config and OTF Config selected corresponding to the sensor that sent the FLY message then Node-Red will begin to configure that sensor.

An example FLY message can be found on the right.

  • topic
    • Indicates the type of message this is
  • payload
    • Contains the primary data of the message
  • payload.mac
    • Indicates the unique address of the sensor sending the mode message
  • payload.type
    • Indicates the type of sensor sending the mode message
  • payload.nodeId
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
  • payload.mode
    • indicates the current mode of the sensor
  • payload.lastHeard
    • Timestamp of the message
  • reported_config
    • Contained the reported configuration parameter values
  • reported_config.firmware
    • Displays the current firmware version installed on the sensor
  • reported_config.destination_address
    • Shows the current destination address configured on the sensor. The default setting is broadcast mode “00:00:FF:FF”
  • reported_config.mode
    • Indicates the current operating mode configured on the sensor
  • reported_config.odr
    • Specifies the current number of samples the device captures per second
  • reported_config.sampling_duration
    • Reflects the amount of time over which the sample is taken
  • reported_config.filter_status
    • Indicates whether the sensor’s filters are currently enabled or disabled
  • reported_config.lpf_coeff
    • Displays the current value assigned to the Low Pass Filter
  • reported_config.lpf_freq
    • Shows the current frequency for the Low Pass Filter, calculated as Frequency = ODR / Low Pass Coefficient
  • reported_config.hpf_coeff
    • Displays the current value assigned to the High Pass Filter
  • reported_config.hpf_freq
    • Shows the current frequency for the High Pass Filter, calculated as Frequency = ODR / High Pass Coefficient
  • reported_config.sampling_interval
    • Indicates how often, in minutes, the sensor wirelessly transmits measurement data
  • reported_config.on_request_timeout
    • Specifies how long, in seconds, the device remains active while awaiting a Raw data request command before returning to sleep mode
  • reported_config.deadband
    • Represents the minimum acceleration threshold required for the sensor to register a measurement
  • reported_config.payload_length
    • Indicates the size of the data payload (in bytes) transmitted by the sensor with each message
  • reported_config.fsr
    • Shows the maximum range of acceleration the device is capable of measuring
  • reported_config.rpm_compute_status
    • Indicates whether the RPM calculation feature is enabled or disabled
  • reported_config.auto_raw_destination_address
    • Displays the current destination address for Time Domain Data transmission. The default is the broadcast address “00:00:FF:FF”
  • reported_config.auto_raw_interval
    • Specifies the frequency, in minutes, at which Time Domain Data is transmitted
  • reported_config.smart_mode_skip_count
    • Shows the number of times the sensor will skip sending data if the vibration level falls below the smart mode threshold
  • reported_config.smart_mode_acc_threshold
    • Indicates the minimum acceleration value required to trigger data transmission in Smart Mode
  • hardware_id
    • This value indicates the hardware version of the device
  • reserved
    • Refers to a value reserved for future use or internal purposes
  • reserved.tx_lifetime_counter
    • Tracks the total number of data packets transmitted by the CPU since the device first booted
  • machine_values
    • The Raw data the sensor reports
				
					{
  "topic": "sensor_mode",
  "payload": {
    "mac": "00:13:a2:00:42:37:73:52",
    "type": 111,
    "nodeId": 0,
    "mode": "FLY",
    "lastHeard": 1721424000789
  },
  "reported_config": {
    "firmware": 1,
    "destination_address": "00:00:ff:ff",
    "mode": "Smart",
    "odr_1": "800Hz",
    "odr_2": "800Hz",
    "sampling_duration_1": "1000ms",
    "sampling_duration_2": "1000ms",
    "filter_status": "Enabled",
    "lpf_coeff_1": 4,
    "lpf_coeff_2": 4,
    "lpf_freq_1": "200Hz",
    "lpf_freq_2": "200Hz",
    "hpf_coeff_1": 64,
    "hpf_coeff_2": 64,
    "hpf_freq_1": "12.5Hz",
    "hpf_freq_2": "12.5Hz",
    "sampling_interval": "15 Minutes",
    "on_request_timeout": "1 Seconds",
    "deadband": "20mg",
    "payload_length": "180 Bytes",
    "fsr": "8g",
    "rpm_compute_status": "Enabled",
    "auto_raw_destination_address": "00:00:ff:ff",
    "auto_raw_interval": "disabled",
    "smart_mode_skip_count": 3,
    "smart_mode_acc_threshold_probe_1": "500mg",
    "smart_mode_acc_threshold_probe_2": "500mg",
    "uptime_counter_probe_1": "1sec",
    "uptime_counter_probe_2": "1sec",
    "hardware_id": [...],
    "reserved": [...],
    "tx_lifetime_counter": 115,
    "machine_values": {
      ...
      ...
      ...
    },
  },
  "time": 1721424000789,
  "_msgid": "e361ba7bdfe0bc4b"
}

Wireless Gateway UPTHWRN Message

An UPTHWRN message indicates that the sensor’s threshold is set too low, causing it to trigger frequently. This can lead to battery drain.

An example UPTHWRN message can be found on the right.

  • topic
    • Indicates the type of message this is
  • payload
    • Contains the primary data of the message
  • payload.mac
    • Indicates the unique address of the sensor sending the mode message
  • payload.type
    • Indicates the type of sensor sending the mode message
  • payload.nodeId
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
  • payload.mode
    • indicates the current mode of the sensor
  • payload.lastHeard
    • Timestamp of the message
				
					{
  "topic": "sensor_mode",
  "payload": {
    "mac": "00:13:a2:00:42:37:73:52",
    "type": 111,
    "nodeId": 0,
    "mode": "UPTHWRN",
    "lastHeard": 1721424191766
  },
  "time": 1721424191767,
  "_msgid": "5f6f01b6651b2f82"
}

Wireless Gateway modem_mac Message

A modem_mac message indicates the unique address of the wireless module connected to the Wireless Gateway Node. This message is sent when Node-Red is deployed and when the Wireless Gateway is put into Configuration Mode or Ready Mode. An example modem_mac message can be found on the right.
  • topic
    • Indicates the type of message this is
  • payload
    • Contains the unique address of the wireless module on the Wireless Gateway Node
  • time
    • Timestamp of the message
				
					{
  "topic": "modem_mac",
  "payload": "00:13:A2:00:41:F5:2C:D3",
  "time": 1721424259706,
  "_msgid": "83ad39df1328dea7"
}

Wireless Gateway Node Configuration

Wireless Gateway Edit Pane

You can edit a Wireless Gateway node by double clicking on it once placed in a flow. Below is a description of the primary elements of this edit pane corresponding to the elements numbered to the right.
  1. Name
    • An arbitrary name given to this node
  2. Serial Device*
    • A drop down to choose between configured communication interfaces
    • The default Serial Device for our Enterprise Gateways is “/dev/ttymxc2”
    • To add a new configuration option you will want to choose “Add new ncd-gateway-config…” from this dropdown
  3. Serial Device Edit Icon
    • Clicking this icon will take you to a submenu to edit the particulars of the device chosen in the Serial Device dropdown
    • To add a new configuration option you will want to choose “Add new ncd-gateway-config…” from this dropdown
    • For More information on the submenu this icon bring up see section ncd-gateway-config Nodes​
  4. Output data from Unknown Devices
    • Enabling this feature allows other devices using the Digimesh wireless protocol to send their data to Node-Red
    • When selected, data from unknown devices will be output from a secondary output
Number diagram of Wireless Gateway Node edit pane
Click to enlarge

Wireless Device Nodes

Wireless Device nodes are a virtual representation of a single sensor or a type of sensor. These nodes will output all sensor data and configuration messages from the sensor.

Wireless Device nodes are the primary method of configuring individual or groups of sensors. Their message structure is slightly different from the data coming from a Wireless Gateway.

Wireless Device Node Statuses

The Wireless Device node will display a status based on the last message received to easily identify what is going on with the sensor. Below we will cover each status the Wireless Device node can enter and what it means.

Wireless Device Running Mode

When the Wireless Sensor Node’s status indicates “Running”, as shown in the picture on the right, it means that the wireless sensor has successfully sent at least one packet to the configured Wireless Network. The packet must be a sensor_mode message with a mode of RUN or a sensor_data message.

Wireless Device No Mode

When the Wireless Sensor Node has no status, as shown in the picture on the right, it means that the wireless sensor has not sent a packet over the wireless network since Node-Red was run. The packet must be a sensor_mode message with a mode of RUN or a sensor_data message.

Wireless Device FLY Mode

When the Wireless Sensor Node’s status indicates “FLY”, as shown in the picture on the right, it means that the wireless sensor has sent a FLY message to check in for OTF Configuration. These FLY messages will come in shortly after boot of the sensor as well as once per hour after boot.

For more information on using the FLY message to configure the sensor see section OTF/Automatic Configuration.

Wireless Device with Status of FLY in Node-Red

Wireless Device Config Mode

When the Wireless Sensor Node’s status indicates “Config Mode”, as shown in the picture on the right, it means that the wireless sensor has sent a PGM packet to the receiver and is ready for configuration.

If this Wireless Device node has Auto Config enabled then Node-Red will attempt to configure the device with the settings configured in the Wireless Device edit pane.

Wireless Device Configuration Acknowledged Mode

When the Wireless Sensor Node’s status indicates “Configuration Acknowledged”, as shown in the picture on the right, it means that the wireless sensor has sent an ACK message to the wireless network in response to a command.

This generally indicates that a device is currently being configured.

Wireless Device Config Complete Mode

When the Wireless Sensor Node’s status indicates “Config Complete”, as shown in the picture on the right, it means that all configurations have been sent to the sensor and the sensor has either responded or the responses have timed out.

It is recommended to use the Config Results message that is sent when the node reaches this status to confirm all configurations were successful.

Wireless Device Module was Factory Reset

When the Wireless Sensor Node’s status indicates “Module was factory reset”, as shown in the picture on the right, it means that the correlating sensor has been factory reset.

Immediately after sending this message the sensor will also send a PGM message to allow for configurations after the factory reset.

Wireless Device Node Messages

Wireless Device Node Sensor Data Message

Sensor data is the primary message that will come from a Wireless Gateway Node. These messages can be discerned from other message types by the topic which will always be “sensor_data”

To the right is an example of a Sensor Data message.

  • topic
    •  Indicates the type of message this is
  • data
    • Contains the sensor data and all other pertinent details of the sensor
  • data.nodeID
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
    • For a unique identifier it is recommended to use the msg.data.addr property as it is tied to the individual sensor’s wireless module and will always be unique
  • data.firmware
    • This identifies the firmware version of the sensor sending the packet
  • data.battery
    • The current voltage level of the batteries at the time of transmission
    • The batteries that come with the sensors drop off quickly once they reach 2.6 volts
  • data.battery_percentage
    • The current battery percent at the time of transmission
  • data.counter
    • The number of transmissions since boot or counter rollover
    • The counter will rollover after a counter value of 255
  • data.sensor_type
    • The machine identifiable type of the sensor
    • It is recommended to use this property to dictate dashboard generation and/or data integrity checks
  • data.sensor_data
    • Object containing all sensor data related to this sensor
    • This property is a duplicate of the payload property
  • data.sensor_name
    • Human Readable Sensor Type Identifier
  • data.type
    • An easily passed message type declaration
    • This property will be a duplicate of msg.topic
  • data.addr
    • The unique identifier of the sensor that transmitted the data
  • data.received
    • Timestamp of the message
  • data.original
    • Auxiliary information on the packet and underlying protocol
  • data.modem_mac
    • The unique identifier of the Gateway/Modem that received the data
    • Primarily used to tie locations/projects to sensors/sensor data
  • payload
  • time
    • Timestamp of the message
				
					{
  "topic": "sensor_data",
  "data": {
    "nodeId": 0,
    "firmware": 3,
    "battery": "3.28",
    "battery_percent": "98.56",
    "counter": 26,
    "sensor_type": 111,
    "sensor_data": {
        "mode":0,
        "msg_type": "regular",
        "s1_odr":"800Hz",
        "s1_temperature":23.67,
        "x1_rms_ACC_G": 0.001,
        "x1_max_ACC_G": 0.002,
        "x1_velocity_mm_sec": 0.03,
        "x1_displacement_mm": 0.04,
        "x1_peak_one_Hz": 5,
        "x1_peak_two_Hz": 6,
        "x1_peak_three_Hz": 7,
        "y1_rms_ACC_G": 0.008,
        "y1_max_ACC_G": 0.009,
        "y1_velocity_mm_sec": 0.1,
        "y1_displacement_mm": 0.11,
        "y1_peak_one_Hz": 12,
        "y1_peak_two_Hz": 13,
        "y1_peak_three_Hz": 14,
        "z1_rms_ACC_G": 0.015,
        "z1_max_ACC_G": 0.162,
        "z1_velocity_mm_sec": 1.63,
        "z1_displacement_mm": 1.64,
        "z1_peak_one_Hz": 165,
        "z1_peak_two_Hz": 166,
        "z1_peak_three_Hz": 256,
        "rpm_1": 167
        "s2_odr":"800Hz",
        "s2_temperature":23.67,
        "x2_rms_ACC_G": 0.001,
        "x2_max_ACC_G": 0.002,
        "x2_velocity_mm_sec": 0.03,
        "x2_displacement_mm": 0.04,
        "x2_peak_one_Hz": 5,
        "x2_peak_two_Hz": 6,
        "x2_peak_three_Hz": 7,
        "y2_rms_ACC_G": 0.008,
        "y2_max_ACC_G": 0.009,
        "y2_velocity_mm_sec": 0.1,
        "y2_displacement_mm": 0.11,
        "y2_peak_one_Hz": 12,
        "y2_peak_two_Hz": 13,
        "y2_peak_three_Hz": 14,
        "z2_rms_ACC_G": 0.015,
        "z2_max_ACC_G": 0.162,
        "z2_velocity_mm_sec": 1.63,
        "z2_displacement_mm": 1.64,
        "z2_peak_one_Hz": 165,
        "z2_peak_two_Hz": 166,
        "z2_peak_three_Hz": 256,
        "rpm_2": 167
    },
    "sensor_name": "Two Channel Vibration Plus v4",
    "type": "sensor_data",
    "addr": "00:13:a2:00:42:37:73:52",
    "received": 1721424191583,
    "original": {...},
    "modem_mac": "00:13:A2:00:41:F5:2C:D3"
  },
  "payload": {
        "mode":0,
        "msg_type": "regular",
        "s1_odr":"800Hz",
        "s1_temperature":23.67,
        "x1_rms_ACC_G": 0.001,
        "x1_max_ACC_G": 0.002,
        "x1_velocity_mm_sec": 0.03,
        "x1_displacement_mm": 0.04,
        "x1_peak_one_Hz": 5,
        "x1_peak_two_Hz": 6,
        "x1_peak_three_Hz": 7,
        "y1_rms_ACC_G": 0.008,
        "y1_max_ACC_G": 0.009,
        "y1_velocity_mm_sec": 0.1,
        "y1_displacement_mm": 0.11,
        "y1_peak_one_Hz": 12,
        "y1_peak_two_Hz": 13,
        "y1_peak_three_Hz": 14,
        "z1_rms_ACC_G": 0.015,
        "z1_max_ACC_G": 0.162,
        "z1_velocity_mm_sec": 1.63,
        "z1_displacement_mm": 1.64,
        "z1_peak_one_Hz": 165,
        "z1_peak_two_Hz": 166,
        "z1_peak_three_Hz": 256,
        "rpm_1": 167
        "s2_odr":"800Hz",
        "s2_temperature":23.67,
        "x2_rms_ACC_G": 0.001,
        "x2_max_ACC_G": 0.002,
        "x2_velocity_mm_sec": 0.03,
        "x2_displacement_mm": 0.04,
        "x2_peak_one_Hz": 5,
        "x2_peak_two_Hz": 6,
        "x2_peak_three_Hz": 7,
        "y2_rms_ACC_G": 0.008,
        "y2_max_ACC_G": 0.009,
        "y2_velocity_mm_sec": 0.1,
        "y2_displacement_mm": 0.11,
        "y2_peak_one_Hz": 12,
        "y2_peak_two_Hz": 13,
        "y2_peak_three_Hz": 14,
        "z2_rms_ACC_G": 0.015,
        "z2_max_ACC_G": 0.162,
        "z2_velocity_mm_sec": 1.63,
        "z2_displacement_mm": 1.64,
        "z2_peak_one_Hz": 165,
        "z2_peak_two_Hz": 166,
        "z2_peak_three_Hz": 256,
        "rpm_2": 167
  },
  "time": 1721424191584,
  "_msgid": "48e99332fc104565"
}
msg.payload Breakdown
  • mode
    • The sensor works in one of 3 modes:
      • 0 – Processed – FFT is performed by the sensor and the measurement data is presented in condensed form (both time and frequency parameters)
      • 1 – Raw/time domain – the Raw/time domain data is gathered and transmitted and it is up to the client to perform the FFT if needed. This is a very large data packet.
      • 2 – Оn demand, sending Processed data regularly, with the option to request a Raw/time domain data packet
      • 3 – Smart – a cutting-edge operational setting. In this mode, the sensor delivers Processed Data (Overall Data) at user-defined intervals, with a Time Domain on Request option for requesting detailed Raw data packets, complemented by an Auto Raw Interval that dictates how often the sensor automatically transmits Raw measurement data for continuous insights. It features smart mode threshold, triggering data transmission when RMS acceleration exceeds a user-set value on any X, Y, or Z axis, alongside smart skip threshold, which intelligently skips sending data a specified number of times when vibrations fall below the threshold, optimizing efficiency, paired with 24/7 sampling to capture spontaneous issues—ideal for intermittent machine operation—ensuring real-time adaptability and comprehensive monitoring with precision.
  • msg_type
    • The message type:
      • regular – data send over regular intervals
      • motion – data triggered by the vibration crossing a predefined threshold
  • s1_odr
    •  This is the Vibration sample rate in Hz
  • ts1_emperature
    •  The temperature measured by the temperature sensor in Celsius
  • x1_rms_ACC_G
    •  The RMS Acceleration over the X axis in G
  • x1_max_ACC_G
    •  The MAX Acceleration over the X axis in G
  • x1_velocity_mm_sec
    •  The Velocity over the X axis in mm/sec
  • x1_displacement_mm
    •  The Displacement over the X axis in mm
  • x1_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • x1_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • x1_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • y1_rms_ACC_G
    •  The RMS Acceleration over the Y axis in G
  • y1_max_ACC_G
    •  The MAX Acceleration over the Y axis in G
  • y1_velocity_mm_sec
    •  The Velocity over the Y axis in mm/sec
  • y1_displacement_mm
    •  The Displacement over the Y axis in mm
  • y1_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • y1_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • y1_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • z1_rms_ACC_G
    •  The RMS Acceleration over the Z axis in G
  • z1_max_ACC_G
    •  The MAX Acceleration over the Z axis in G
  • z1_velocity_mm_sec
    •  The Velocity over the Z axis in mm/sec
  • z1_displacement_mm
    •  The Displacement over the Z axis in mm
  • z1_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • z1_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • z1_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • rpm_1
    • The rate of rotation of the machine in revolutions per minute
  • s2_odr
    •  This is the Vibration sample rate in Hz
  • s2_temperature
    •  The temperature measured by the temperature sensor in Celsius
  • x2_rms_ACC_G
    •  The RMS Acceleration over the X axis in G
  • x2_max_ACC_G
    •  The MAX Acceleration over the X axis in G
  • x2_velocity_mm_sec
    •  The Velocity over the X axis in mm/sec
  • x2_displacement_mm
    •  The Displacement over the X axis in mm
  • x2_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • x2_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • x2_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the X axis
  • y2_rms_ACC_G
    •  The RMS Acceleration over the Y axis in G
  • y2_max_ACC_G
    •  The MAX Acceleration over the Y axis in G
  • y2_velocity_mm_sec
    •  The Velocity over the Y axis in mm/sec
  • y2_displacement_mm
    •  The Displacement over the Y axis in mm
  • y2_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • y2_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • y2_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the Y axis
  • z2_rms_ACC_G
    •  The RMS Acceleration over the Z axis in G
  • z2_max_ACC_G
    •  The MAX Acceleration over the Z axis in G
  • z2_velocity_mm_sec
    •  The Velocity over the Z axis in mm/sec
  • z2_displacement_mm
    •  The Displacement over the Z axis in mm
  • z2_peak_one_Hz
    •  The frequency at which the First Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • z2_peak_two_Hz
    •  The frequency at which the Second Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • z2_peak_three_Hz
    •  The frequency at which the Third Highest Energy/ Amplitude Peak occurs in Hz, over the Z axis
  • rpm_2
    • The rate of rotation of the machine in revolutions per minute
  •  

Wireless Device Node Sensor Data Message (Raw/time domain)​

Sensor data is the primary message that will come from a Wireless Gateway Node. These messages can be discerned from other message types by the topic which will always be “sensor_data”

To the right is an example of a Sensor Data message.

  • topic
    •  Indicates the type of message this is
  • data
    • Contains the sensor data and all other pertinent details of the sensor
  • data.nodeID
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
    • For a unique identifier it is recommended to use the msg.data.addr property as it is tied to the individual sensor’s wireless module and will always be unique
  • data.firmware
    • This identifies the firmware version of the sensor sending the packet
  • data.battery
    • The current voltage level of the batteries at the time of transmission
    • The batteries that come with the sensors drop off quickly once they reach 2.6 volts
  • data.battery_percentage
    • The current battery percent at the time of transmission
  • data.counter
    • The number of transmissions since boot or counter rollover
    • The counter will rollover after a counter value of 255
  • data.sensor_type
    • The machine identifiable type of the sensor
    • It is recommended to use this property to dictate dashboard generation and/or data integrity checks
  • data.sensor_data
    • Object containing all sensor data related to this sensor
    • This property is a duplicate of the payload property
  • data.sensor_name
    • Human Readable Sensor Type Identifier
  • data.type
    • An easily passed message type declaration
    • This property will be a duplicate of msg.topic
  • data.addr
    • The unique identifier of the sensor that transmitted the data
  • data.received
    • Timestamp of the message
  • data.original
    • Auxiliary information on the packet and underlying protocol
  • data.modem_mac
    • The unique identifier of the Gateway/Modem that received the data
    • Primarily used to tie locations/projects to sensors/sensor data
  • payload
  • time
    • Timestamp of the message
				
					{
  "topic": "sensor_data",
  "data": {
    "nodeId": 0,
    "firmware": 3,
    "battery": "3.28",
    "battery_percent": "98.56",
    "counter": 26,
    "sensor_type": 111,
    "sensor_data": {
        "mode":1,
        "msg_type": "regular",
        "probe": 1,
        "time_id":"0:20",
        "mac_address": "00:13:a2:00:42:53:64:53",
        "fsr": "8g",
        "odr": 827,
        "device_temp": 19.56
        "data": {
           "x": [-0.07, 0.1, ...],
           "y": [0, 0, ...],
           "z": [0, 0, ...]
    },
    "sensor_name": "Two Channel Vibration Plus v4",
    "type": "sensor_data",
    "addr": "00:13:a2:00:42:37:73:52",
    "received": 1721424191583,
    "original": {...},
    "modem_mac": "00:13:A2:00:41:F5:2C:D3"
  },
  "payload": {
        "mode":1,
        "msg_type": "regular",
        "probe": 1,
        "time_id":"0:20",
        "mac_address": "00:13:a2:00:42:53:64:53",
        "en_axis": 7,
        "fsr": "8g",
        "odr": 827,
        "device_temp": 19.56
        "data": {
           "x": [-0.07, 0.1, ...],
           "y": [0, 0, ...],
           "z": [0, 0, ...]
  },
  "time": 1721424191584,
  "_msgid": "48e99332fc104565"
}
msg.payload Breakdown
  • mode
    • The sensor works in one of 3 modes:
      • 0 – Processed – FFT is performed by the sensor and the measurement data is presented in condensed form (both time and frequency parameters)
      • 1 – Raw/time domain – the Raw/time domain data is gathered and transmitted and it is up to the client to perform the FFT if needed. This is a very large data packet.
      • 2 – Оn demand, sending Processed data regularly, with the option to request a Raw/time domain data packet
      • 3 – Smart – a cutting-edge operational setting. In this mode, the sensor delivers Processed Data (Overall Data) at user-defined intervals, with a Time Domain on Request option for requesting detailed Raw data packets, complemented by an Auto Raw Interval that dictates how often the sensor automatically transmits Raw measurement data for continuous insights. It features smart mode threshold, triggering data transmission when RMS acceleration exceeds a user-set value on any X, Y, or Z axis, alongside smart skip threshold, which intelligently skips sending data a specified number of times when vibrations fall below the threshold, optimizing efficiency, paired with 24/7 sampling to capture spontaneous issues—ideal for intermittent machine operation—ensuring real-time adaptability and comprehensive monitoring with precision.
  • msg_type
    • The message type:
      • regular – data send over regular intervals
      • motion – data triggered by the vibration crossing a pre-define threshold
  • probe
    • this is the number of the probe that is measuring the vibration data
  • time_id
    •  The time when the reading was taken
  • mac_address
    •  The MAC address of the device (used to identify it on the network)
  • fsr
    • Full Scale Range of the sensor
  • odr
    • This is the Vibration sample rate in Hz
  • device_temp
    • The measured temperature
  • data
    • data over each of the enabled axis in “g”. You will have multiple samples here depending on the chosen rate
  •  

Wireless Device Node Config Results Message

This message will come from a Wireless Device node when it is configured. You can use this message to confirm that the configurations where successfully made to the sensor.
  • topic
    •  Indicates the type of message this is
  • payload
    • Contains the responses for each configuration command sent
  • payload.x
    • Each command will be listed as its own sub property of payload keyed by the command with a value of the command status
    • A command with the value of true indicates a successful command and a corresponding response from the sensor
    • Any other value indicates an error in the command or a failure of the sensor to respond
    • Some commands will never return a true such as reboot_sensor or the establish_config_network commands
  • time
    • Timestamp of the message
  • addr
    • Indicates the unique address of the sensor sending the configuration results
				
					{
  "topic": "Config Results",
  "payload": {
    "establish_config_network_1": {
      "res": "Broadcast mode, no target device",
      "sent": [...]
    },
    "establish_config_network_2": {
      "res": "Broadcast mode, no target device",
      "sent": [...]
    },
    "establish_config_network_3": {
      "res": "Broadcast mode, no target device",
      "sent": [...]
    },
    "network_id": true,
    "reboot_sensor": {
      "err": "No config err or ack, timeout",
      "sent": [...]
    }
  },
  "time": 1721424010563,
  "addr": "00:13:a2:00:42:37:73:52",
  "_msgid": "c29c7695c93ae747"
}

Wireless Device Node OTN Request Results Message

This message indicates that the sensor successfully extended the configuration window indicated by the FLY message. This message will not be received unless a Wireless Device node is configured for the target device with Auto Config and OTF Config enabled.
  • topic
    •  Indicates the type of message this is
  • payload.config_enter_otn_mode
    • A value of true indicates that the sensor successfully extended the temporary configuration mode
  • time
    • Timestamp of the message
				
					{
  "topic": "OTN Request Results",
  "payload": {
    "config_enter_otn_mode": true
  },
  "time": 1721424530709,
  "_msgid": "1014b31e53e5c7ac"
}

Wireless Device Node Configuration Options

Our Node-Red library lets you configure any of sensor easily, simply by adjusting a few fields in your Node-RED flow and triggering a configuration update either through the CFG button on the sensor or waiting for a FLY message sent every hour during normal operations.

You can edit a Wireless Device node by double clicking the node once it is placed in a flow.

Primary Wireless Device Node Configurations

These configurations are responsible for configuring the Wireless Device node and how node-red should interact with the sensor.
  • Name
    • Arbitrary name of this node
    • Primarily used for easy identification in the flow
  • Serial Device*
    • The primary communication interface used to receive data from the sensor
    • Clicking the edit icon will take you to a submenu to edit the particulars of the device chosen in the Serial Device dropdown
    • To add a new configuration option you will want to choose “Add new ncd-gateway-config…” from this dropdown
    • For More information on the submenu the edit icon brings up see section ncd-gateway-config Nodes​
  • Serial Device for Config
    • A secondary communication interface used to configure sensors without losing sensor data
    • If no option is selected the communication interface selected under Serial Device will be used for configuration
    • A second modem will be required to make full use of this option
  • Mac Address
    • Using this field allows you to choose a specific sensor that corresponds to this Wireless Device node
    • Leaving this field blank allows any sensor of the type chosen under the Sensor Type field to correspond with this Wireless Device Node
    • A search icon on the right can be clicked to search for Wireless Devices that the Serial Device has heard from to auto fill information for that device
  • Sensor Type*
    • This field limits the sensors that correspond to this Wireless Device node to a particular type of sensor
  • Auto Config
    • Checking the box next to this field tells Node-Red that the sensor(s) corresponding to this Wireless Device node should be configured when put into Configuration Mode manually
  • OTF Config
    • Checking the box next to this field AND having Auto Config checked tells Node-Red that the sensor(s) corresponding to this Wireless Device node should be configured when a FLY message is detected
*Required

General Sensor Configurations

These configurations are transmitted to the sensor when Node-Red configures the sensor. Node-Red will need to configure the sensor in order for these settings to go into effect.

  • Wait for Network Formation
    • This option sends three commands to all local devices on the wireless network to help form the mesh network
  • Destination Address
    • This option will tell the sensor to ONLY send its data to a single receiver
    • For more information on how to get the Address of the receiver module connected to Node-Red see section Wireless Gateway modem_mac Message
  • Network ID
    • This option allows you to change the Network ID that the sensor will use to report its data while in RUN module
    • You will need to make sure that a Gateway or Modem is configured to use this network ID in order to receive sensor data from it after configuration
  • Node ID and Delay
    • Node ID
      • Node ID allows you to set an easy to understand unique ID for a particular sensor
    • Delay
      • Delay is the time in seconds between sensor data reading transmissions
  • Power
    • This option allows you to set the transmission power level of the sensor
  • Retries
    • Sets the maximum number of retries the sensor will attempt before considering a packet transmission failed
General Configurations for Wireless Device nodes
Click to expand

Sensor Specific Configurations

Probe 1: Set Acceleration Wake/Interrupt Threshold

Set a breakpoint for sensor to wake up and broadcast readings. This is an interrupt based configuration ideal for devices with minimal workload/uptime.

This will be an integer value that increments the interrupt threshold by 50mg. A value of 1 means turn the wake the sensor if acceleration is above 50mg, 2 means 100mg, etc.

Valid Input Range: 0 – 40

A value of 0 will disable this feature.

Probe 2: Set Acceleration Wake/Interrupt Threshold

Set a breakpoint for sensor to wake up and broadcast readings. This is an interrupt based configuration ideal for devices with minimal workload/uptime.

This will be an integer value that increments the interrupt threshold by 50mg. A value of 1 means turn the wake the sensor if acceleration is above 50mg, 2 means 100mg, etc.

Valid Input Range: 0 – 40

A value of 0 will disable this feature.

Measurement mode

This lets you see what units are the measured metrics output in, you have a choice of 2 options. See image for reference.

Set On Request Timeout in seconds

This is how long the device will remain active and wait for a RAW data request command, before going inactive again.

Set RTC

Set the value for the Real Time Clock.

Full Scale Range

How large of a range the device can measure acceleration in. For example +/- 8g would mean that it would measure at most up to 8g and down to -8g.

Set Dead Band in mg

This value determines the minimum acceleration would have to be for it to be registered as a measurement. Values below the threshold it  would be perceived as 0.

For example, a value of 10 would mean that vibrations below 10mg would be considered as 0.

Payload Length

This is the size of the data payload the sensor sends when it sends a message.

Probe 1: Output Data Rate (ODR)

The data rate of the output signal. This would determine how many samples the output data has, which is directly related to the highest frequency components that can be measured. In accordance with the Nyquist equation:

f_max = ODR/2.56 Hz


Sample Rate (ODR)Sample Duration Max
200Hz40Sec
400Hz20sec
800Hz10sec
1600Hz5sec
3200Hz2.5sec
6400Hz1.26sec
12800Hz0.63sec
25600hz0.31sec
Probe 2: Output Data Rate (ODR)

The data rate of the output signal. This would determine how many samples the output data has, which is directly related to the highest frequency components that can be measured. In accordance with the Nyquist equation:

f_max = ODR/2.56 Hz


Sample Rate (ODR)Sample Duration Max
200Hz40Sec
400Hz20sec
800Hz10sec
1600Hz5sec
3200Hz2.5sec
6400Hz1.26sec
12800Hz0.63sec
25600hz0.31sec
Probe 1: Set Sampling Duration
Probe 2: Set Sampling Duration
Probe 1: Set Low Pass Filter

This setting will set the HPF freq to ODR divided by Selected Value
Example: ODR = 800 and Filter Coefficient = 64
HPF freq = 800/64 = 12.5Hz

Probe 2: Set Low Pass Filter

This setting will set the HPF freq to ODR divided by Selected Value
Example: ODR = 800 and Filter Coefficient = 64
HPF freq = 800/64 = 12.5Hz

Probe 1: Set High Pass Filter

This setting will set the HPF freq to ODR divided by Selected Value
Example: ODR = 800 and Filter Coefficient = 64
HPF freq = 800/64 = 12.5Hz

Probe 2: Set High Pass Filter

This setting will set the HPF freq to ODR divided by Selected Value
Example: ODR = 800 and Filter Coefficient = 64
HPF freq = 800/64 = 12.5Hz

Mode

Select the mode of operation:

  • Processed – only processed data is sent, as in the example in this document
  • Raw – full time domain data is sent (very large not recommended for prolonged periods)
  • Processed + Raw on demand – same as the first mode, but with the option to generate a Raw packet on demand
  • Smart – in this mode the sensor automatically samples and sends a data packet if the vibration crosses a defined threshold level
Sampling Interval

How often will the sensor transmit measurement data wirelessly.

Possible values:

  • 1 minute
  • 5 minutes
  • 10 minutes (default)
  • 20 minutes
  • 30 minutes
  • 60 minutes
  • 120 minutes
  • 180 minutes
Clear Probe Uptimers

When the measured vibration is above a threshold value we can deduct that the machine is on and start a counter to measure the uptime. This setting will zero out the uptime value.

Set Auto Raw Interval

The interval is determined by the sample interval. If the value is set to 1 and the sample interval is 30 minutes, Raw data will be sent every 30 minutes. If the value is set to 5, Raw data will be sent every 150 minutes.

Set Auto Raw Destination Address

This is the address where the Auto Raw data will be sent, we recommend setting this to your gateway’s address.

For example: 41D5EC37

Probe 1: Set Smart Mode Threshold

If RMS acceleration is above this in any axis, it will send data. This will be an integer value that increments the interrupt threshold by 50 mg. A value of 1 means to wake the sensor if acceleration is above 50 mg, 2 means 100 mg, etc.

Probe 2: Set Smart Mode Threshold

If RMS acceleration is above this in any axis, it will send data. This will be an integer value that increments the interrupt threshold by 50 mg. A value of 1 means to wake the sensor if acceleration is above 50 mg, 2 means 100 mg, etc.

Set Smart Mode Skip Interval

Sensor will skip sending data this many times if vibration is below the smart threshold.

Set FLY Interval

Set the interval at which the sensor performs Fly Mode transmissions in hours.

Enable RPM Calculate Status

When a measurement sample is taken you can choose to not calculate the RPM, this will shorten the measurement time and save on battery.

Set Max Raw Sample

Defines the maximum number of samples the sensor captures for time-domain data, by reducing the sample duration.

Options:
– 1024 Samples.
– 2048 Samples.
– 4096 Samples.
– 6400 Samples.
– 8100 Samples.

Sensor Configuration Processes

Manual Configuration Process

Sensors can be manually put into configuration mode by pressing and releasing the Reset button on the sensor and then wait for a second holding the CFG button on the sensor for 5-15 seconds. See section Hardware Controls for more information on this.

If the Wireless Gateway node in Node-Red is set to configuration mode then you will receive a sensor_mode message from the sensor indicating it is now in Configuration Mode and can be configured. If you also have a Wireless Device Node corresponding to the sensor that was put into configuration mode then Node-Red will begin configuring that sensor according to the settings entered on the Wireless Device node.

See section Primary Wireless Device Node Configurations for more information on how to set up a Wireless Device to configure a sensor.

Wireless Gateway Node in Configuration Mode with the Mode Toggle button highlighted.
The Mode Toggle button is highlighted in Red. This button allows you to enter and exit Configuration Mode.
Logic Diagram for Manual Configuration of Sensors

OTF/Automatic Configuration

This sensor supports configuration while in Run Mode. We call this configuration OTF or On the Fly. This configuration is initiated by a sensor_mode message from the Sensor with the mode of FLY. These messages are sent over the standard Run Mode wireless network so there is no need to change the Wireless Gateway nodes mode or manually manipulate the buttons on the sensor.

FLY messages are sent once an hour and on boot and tell Node-Red that the sensor is ready for configuration changes. Node-Red has two seconds to respond with a configuration or extend this temporary configuration mode.

If you have a Wireless Device node with Auto Config and OTF Config corresponding to the sensor that sent the FLY message then Node-Red will begin configuring that sensor according to the settings entered on the Wireless Device node.

See section Primary Wireless Device Node Configurations for more information on how to set up a Wireless Device to configure a sensor.

Logic Diagram for FLY Mode Configuration of Sensors

Troubleshooting

Check Sensor Power

First check that the Power Switch is in the correct position. See section Hardware Controls for more information and a diagram on the correct position.

Second press the CFG button on the sensor. If the TEST LED on the sensor lights up then the sensor has power. If the LED does not light up try swapping out the batteries or changing the external power supply.

If the LED still doesn’t light up after changing the power source please contact us for additional troubleshooting steps.

Factory Reset Sensor

If the power tests above show that power is on and the TEST LED lights up then you can attempt a factory reset. There are certain configurations that can be made to the sensor that will prevent data from being received properly such as Destination Address and Network ID. A factory reset will revert these to default settings.

  1. Factory Reset the Sensor
    • Factory reset by pressing and release the RESET button, wait for a second, then press and hold the CONFIGURATION button, hold the CONFIGURATION button for more than 15 seconds, release CONFIGURATION button, then Wait for 3-5 seconds, finally press and release the RESET button.
    • See section Hardware Mode Selection for more information
  2. You should receive a sensor_mode message with the mode of PUM and then a second sensor_mode message with the mode of PGM
    • It is recommended to have a Debug node connected directly to the Wireless Gateway node to see these messages

Multiple Gateways

If you have multiple Gateways in the vicinity of a sensor that is having issues you will need to make sure that only one Gateway is set to configure these sensors using OTF Config. Multiple OTF Configuration attempts simultaneously will cause failures during configuration.

Additionally if one Gateway is setting the Destination Address or Network ID of the sensor it will prevent the other Gateways from seeing its sensor data or being able to perform OTF Configurations to that sensor.

The recommended resolution is to make sure that only one gateway is set to configure the device. If communications are down to the intended receiver perform a factory reset of the device.

See section Hardware Mode Selection for more information on performing a factory reset.

Move Devices Closer

Its possible that there was an environmental change at the install location that is causing the Wireless range of the sensor to be reduced. To check for this it is recommended to move the sensor closer to approximately 3 feet or 1 meter from the gateway and press the RESET button to see if the sensor_mode message with the mode of RUN is received.

If it is determined that it is a range issue you can check that the antenna is fully seated. If there appears to be no issue with the antenna this can usually be resolved by adding a Repeater between the Sensor and the Receiver/Gateway running Node-Red.

If the range is limited to a few feet contact us for additional troubleshooting steps.

Check Module Frequency - WIP

Check Antenna Connection - WIP

Examples

Dashboard

We have built an example dashboard to display the sensor data from a single Vibration Sensor. You can find it by importing it directly into Node-Red.

  1. Click the menu in the top right of Node-Red (three horizontal lines)
  2. Import
  3. Choose Examples on the left side of the subsequent modal window
  4. Expand @ncd-io/node-red-enterprise-sensors
  5. Expand Type 111 – Two Channel Vibration Plus v4
  6. Select Quick Start Dashboard
  7. Select new flow along the bottom
  8. Click on Import

Example Flows

We have many examples of how to manipulate and disseminate data on our Github Repository. To view all of our example flows check out our Full Repository.