Gen4: Understanding Time Domain (Raw) Data Request Commands

Eduardo M

Introduction to Vibration Data Acquisition Modes

The Vibration Sensors Generation 4 offers versatile data acquisition capabilities, primarily operating in its Smart Mode to provide intelligent insights into machinery health. This section provides an overview of the data types transmitted by the sensor and explains how to leverage its advanced functionalities for comprehensive condition monitoring.

Processed Data for Efficient Monitoring

In its default Smart Mode, the vibration sensor performs sophisticated on-board processing of its raw measurements. It efficiently samples acceleration across the X, Y, and Z axes multiple times per measurement cycle. These measurements are then intelligently processed to generate concise values such as RMS acceleration, maximum spectral peaks, and overall vibration severity.

For most users, this processed data is highly effective. It is typically more than sufficient to:

Quickly identify the presence of an issue within the machinery.
Diagnose the probable cause of a fault by analyzing frequency peaks (e.g., distinguishing between misalignment, imbalance, or worn bearings).
Optimize data transmission by sending only the most relevant information, thereby conserving battery life and network bandwidth.

Accessing Raw Data: Unlocking Deeper Analysis

While processed data offers significant diagnostic value, there are scenarios where a more granular view of the vibration signature is required. For such cases, the sensor provides access to Time Domain (Raw) data, often referred to as ‘Raw mode’. This mode delivers the literal Time Domain (Raw) measurement values captured across all three axes for every sample point during the acquisition period, amounting to thousands of data points.

Accessing this Time Domain (Raw) data allows users to:

Perform detailed, in-depth analyses using external tools.
Conduct advanced signal processing, such as Fast Fourier Transform (FFT), to generate a full, high-resolution spectrum of the vibrational signature at the precise time of measurement.
Store raw data separately for archival purposes or specialized forensic analysis.

We have detailed articles on the subject of vibrational analysis you can find at the links:

Time Domain (Raw) Data transmission

The new Generation 4 Smart Vibration Sensors offer two distinct and powerful methods for accessing detailed Time Domain (Raw) vibration data: Automatic Transmission and On-Request Transmission.

Automatic Time Domain Data Transmission

The Automatic Time Domain (Raw) Data Transmission is a new feature available when the sensor operates in Smart Mode. This allows users to configure a transmission interval, after which the sensor will automatically send Time Domain (Raw) data following a processed data transmission. Crucially, this automatic raw data transmission is intelligently conditioned by the Smart Algorithm, leveraging Smart Threshold and Smart Skip Interval settings to ensure data is only transmitted when truly relevant (refer to the User Manual and our dedicated Smart Mode article for more details).

Understanding Data Transmission in Smart Mode

On-Request Time Domain Data Transmission

The On-Request Time Domain (Raw) Data Transmission empowers users with precise control. After receiving a processed data transmission, users can send a specific command to request the raw data. This method is ideal for creating custom logic based on various conditions—such as vibration thresholds, time values, or asynchronous events—to strategically trigger raw data requests. This provides flexibility, allowing you to obtain raw data only when your application truly requires it (we will explain these request commands in more detail below).

Important Both Automatic and On-Request Time Domain (Raw) data transmissions involve significantly higher battery consumption compared to processed data transmissions. Frequent raw data transmissions can rapidly deplete the sensor's battery. Therefore, we highly recommend evaluating your specific application needs and implementing smart logic (especially for On-Request methods) to trigger raw data transmissions only when absolutely necessary, ensuring optimal battery life while gaining invaluable insights.

On-Request Raw Data Retrieval: The Request Mechanism

Following the transmission of a standard Processed data packet based on its Smart algorithm, the sensor does not immediately return to its low-power smart sampling state. Instead, it enters a brief listening period, defined by the ‘On Request Timeout‘ parameter (configured in seconds).

During this critical window, if the sensor receives a specific request command to transmit Time Domain (Raw) data, it will promptly assemble and transmit the detailed raw data packet. This intelligent listening mechanism allows for on-demand retrieval of high-fidelity raw data, providing flexibility without constant high-bandwidth transmissions.

Requesting Time Domain (Raw) Data: Command Types

The Vibration Generation 4 sensors offer three distinct methods for requesting Time Domain (Raw) data, each with specific conditions and outcomes. These requests are designed to retrieve detailed, Time Domain (Raw) acceleration measurements for in-depth analysis.

Regular Request
Custom Request
Smart Request

1. Regular Raw Data Request

Description: This command initiates a transmission of Time Domain (Raw) data based on the sensor’s currently configured Output Data Rate (ODR) and sample duration settings.

Trigger Condition: The sensor must receive the “Regular Raw Request” command within the designated ‘On Request Timeout’ window (default: 1 second) immediately following its transmission of processed data.

Behavior: Upon successful receipt of the command within the timeout window, the sensor will transmit the Time Domain (Raw) data without further conditions on vibration levels.

				
					// Regular Raw Request Command
[0xF4,0x4F,0x00,0x00,0x50,0x13,0x01] -- type 110, 112 or 114
[0xF4,0x4F,0x00,0x00,0x50,0x13,0x01] -- type 111 probe one
[0xF4,0x4F,0x00,0x00,0x50,0x13,0x02] -- type 111 probe two
[0xF4,0x4F,0x00,0x00,0x50,0x13,0xFF] -- type 111 probe one and two

2. Custom Raw Data Request

Description: This command allows for a flexible retrieval of Time Domain (Raw) data by enabling the user to specify the desired sample rate (ODR) and sample duration directly within the request command itself.

Trigger Condition: The sensor must receive the “Custom Raw Request” command within the designated ‘On Request Timeout’ window (default: 1 second) immediately following its transmission of processed data.

Behavior: Upon successful receipt of the command within the timeout window, the sensor will transmit Time Domain (Raw) data using the ODR and sample duration parameters specified in the request command, irrespective of current vibration levels.

				
					// Custom Raw Request Command
[0xF4,0x4F,0x00,0x00,0x00,0x54,0x01,ODR,Sample Duration] -- type 110, 112 or 114
[0xF4,0x4F,0x00,0x00,0x00,0x54,0x01,ODR,Sample Duration] -- type 111 probe one
[0xF4,0x4F,0x00,0x00,0x00,0x54,0x02,ODR,Sample Duration] -- type 111 probe two
[0xF4,0x4F,0x00,0x00,0x00,0x54,0xFF,ODR,Sample Duration] -- type 111 probe one and two

Sample Rate (ODR) Values

				
					0x07 -- 400sps(Range 6.25 – 100 Hz)
0x08 -- 800sps(Range 12.5 – 200 Hz)
0x09 -- 1600sps(Range 25 – 400 Hz)
0x0A -- 3200sps(Range 50 – 800 Hz)
0x0B -- 6400sps(Range 100 – 1600 Hz)
0x0C -- 12800sps(Range 200 – 3200 Hz)
0x0D -- 25600sps(Range 400 – 6400 Hz)

Sample Duration Values

				
					Valid Range: 
0x01 to 0x64

0x01 - 1*50 = 50 miliseconds, 
0x02 - 2*50 = 100 miliseconds,
...
value * 50 = Sample Duration in miliseconds

3. Smart Raw Data Request

Description: This intelligent command for requesting Time Domain (Raw) data is optimized for operational awareness. It provides raw data only when the monitored motor is confirmed to be active, preventing unnecessary data transmissions when the motor is off.

Trigger Condition: The sensor must receive the “Smart Raw Request” command within the designated ‘On Request Timeout’ window (default: 1 second) immediately following its transmission of processed data.

Behavior: Upon successful receipt of the command within the timeout window,

If the sensor detects that the motor is ON: It will transmit the Time Domain (Raw) data.
If the sensor detects that the motor is OFF: It will transmit a “Motor Off” (MOFF) message instead of raw data. This indicates the sensor’s assessment that the asset is not running.

				
					// Smart Raw Request command
[0xF4,0x4F,0x00,0x00,0x65,0x50,0x01] -- type 110, 112 or 114
[0xF4,0x4F,0x00,0x00,0x65,0x50,0x01] -- type 111 probe one
[0xF4,0x4F,0x00,0x00,0x65,0x50,0x02] -- type 111 probe two

Reference:

Type 110 – One Channel Vibration Plus Sensor gen4
Type 111 – Two Channel Vibration Plus Sensor gen4
Type 112 – Condition Based/Predictive Maintenance Sensor gen4
Type 114 – Standalone Smart Vibration Sensor gen4

How to request Time Domain (Raw) data via Node-RED

Node-RED, combined with the NCD library, provides a powerful and flexible tool for managing your vibration sensor data. This section will guide you through exploring a Node-RED flow designed to intelligently request Time Domain (Raw) data.

This flow evaluates incoming processed data messages from your NCD sensors and, based on defined conditions, constructs and transmits the appropriate raw data request command. The central component for this interaction is the Wireless Gateway node. This versatile node not only facilitates receiving all messages from NCD sensors via its output terminal but also enables the transmission of specific command structures for Time Domain (Raw) data requests through its input connection.

We have made it easy for you and incorporated the required API request commands into a Node-RED flow. Utilizing it, you can easily evaluate and transmit the request command to the sensor in order for it to respond with a Time Domain (Raw) data message after it transmits its processed data packet.

Important! For the best results in Time Domain (Raw) transmission, we recommend to set the Destination Address to match your Modem or Gateway’s address—check the side sticker on your Industrial IoT Wireless to USB Modem or Enterprise IIoT Gateway Lite for the address, and you can configure it using Node-RED.

NCD Sensor Configuration guide using Node-RED

Depending on the type of request command we have available basic Node-RED flows for each case, below you can access the GitHub repository for each one.

Here are the steps to copy and import the corresponding flow to your workspace in Node-RED

Step 1. Access to On request GitHub Repository, then click on ‘Copy raw file’:

Step 2. Go to Node-RED, click on Main menu and select ‘Import’ option from drop down menu:

Step 3. Paste JSON code into text input, then click on ‘Import’ button:

Step 4. Go to Flow Raw Request tab, the double click on Wireless Gateway node and select the corresponding Serial Device from drop down options. (For Gateway is ‘/dev/ttymxc2‘).

Step 5. Click on Done button.

Understanding the On-Request Time Domain (Raw) Data Flow

In this section, we will thoroughly explain the functionality of each node within the provided On-Request Time Domain (Raw) data flow. Understanding the logic embedded in this flow is crucial for its effective implementation. You can utilize this pre-built flow to test the On-Request Time Domain (Raw) data functionality for your Vibration Generation 4 sensor. Furthermore, it serves as a foundational template, allowing you to easily add more nodes or modify the logic to precisely fit your specific application requirements.

sensor-data (Switch Node):

Purpose: Filters incoming messages from the Wireless Gateway to isolate sensor data transmissions.
Functionality: The Wireless Gateway transmits various message types, including modem_mac, RUN, sensor_data, FLY, PGM, etc. This switch node checks the msg.topic property (which identifies the message type). If msg.topic is ‘sensor_data’, the message is allowed to pass to the node’s output; otherwise, it is blocked.
Output: Only sensor_data messages will proceed from this node’s output.

type (Switch Node)

Purpose: Filters sensor_data messages by a specific sensor type.
Functionality: This switch node inspects the msg.payload.sensor_type property within the sensor_data message, which contains the unique type identifier for all NCD sensors. It is essential to configure this node with your specific Vibration Sensor Generation 4 type (e.g., 110, 111, 112, or 114). The default is set to type ‘114’.
Configuration: You must access this node’s settings and specify your sensor’s exact type.
Output: Only sensor_data messages for the specified sensor type will proceed from this node’s output.

mac (Switch Node)

Purpose: Filters sensor_data messages for a specific sensor based on its MAC address.
Functionality: This switch node compares the msg.payload.addr property (which contains the unique MAC address of the NCD sensor) with a pre-defined MAC address. If they match, the sensor data message is allowed to pass. This is particularly useful for isolating data from a specific sensor or for requesting Time Domain (Raw) data from a particular vibration sensor when multiple NCD sensors are present on the network.
Output: Sensor data messages from the specified MAC address will proceed from this node’s output.

mode (Switch Node)

Purpose: Identifies whether an incoming sensor_data message represents a processed data transmission or a Time Domain (Raw) data transmission.
Functionality: This switch node evaluates the msg.payload.sensor_data.mode property.

If mode is 0 (Processed data) or 3 (Smart Mode Processed data), the message indicates a processed transmission and is routed to Output 1. This signifies that the sensor has just transmitted processed data, making it eligible to receive an On-Request command within the ‘On Request Timeout’ window.
If mode is 1 (Time Domain data), the message indicates a raw data transmission and is routed to Output 2.

Flow Logic: Messages routed to Output 1 (processed data) proceed to the condition node, enabling the logic for potentially sending a raw data request. Messages routed to Output 2 (Time Domain data) can be directed to a debug window (e.g., via the time domain data 1 debug node) for immediate viewing.

condition (Switch Node)

Purpose: Defines the criteria for triggering a Time Domain (Raw) data request.
Functionality: This crucial switch node allows you to establish the specific conditions under which the request command will be built and sent to the vibration sensor. You can evaluate any message property or variable within the Node-RED flow to create custom logic.
Default Setting: By default, the condition is set to msg.payload is not empty, which will always evaluate to true. This allows for immediate testing of the On-Request flow’s functionality.
Customization: After confirming basic functionality, you should modify this condition to fit your specific application’s requirements for requesting raw data (e.g., based on vibration values exceeding a threshold, specific time intervals, or external asynchronous events).

Note Contact our support team if you require assistance in developing complex custom conditions for triggering the On-Request command transmission.

build-command (Function Node)

Purpose: Constructs the appropriate On-Request Time Domain (Raw) command structure.
Functionality: This node generates the command packet that the Wireless Gateway expects to receive for onward transmission to the target sensor. It dynamically includes the MAC address of the target sensor and the specific On-Request command type.
Configuration: You will need to modify the msg.payload.data property within this node’s code to select the desired On-Request command type (Regular, Custom, or Smart) based on your Vibration Generation 4 sensor and specific data retrieval needs.

At the output of this node, we will have something like the following, which is a valid input for the Wireless Gateway node:

				
					msg.payload = {
    address: "00:13:a2:00:42:53:64:53",
    data: [0xF4, 0x4F, 0x00, 0x00, 0x50, 0x13, 0x01]
};

Important! Time Domain (Raw) data can only be requested by sending the On-Request command within the 'On Request Timeout' window that immediately follows a processed data transmission. Requests made at any other time will not be successful.

delay (Delay Node)

Purpose: Introduces a brief pause in the message flow.
Functionality: This node applies a configurable delay to the message. This is essential to ensure that we has successfully received and processed the previous processed data transmission before the On-Request command is sent, respecting the ‘On Request Timeout’ window.

link node (Link Node)

Purpose: Provides a clean and organized way to connect distant parts of the Node-RED flow.
Functionality: In this flow, it acts as a visual convenience, hiding the physical wire connection between the delay node and the Wireless Gateway node input, thus simplifying the visual layout of complex flows.

Visual Demo

Below is a visual demonstration of the On-Request flow. Upon deployment, the flow waits for the next processed vibration data transmission. Once this data is received, the flow automatically build and sends the Regular On-Request command to the Wireless Gateway node. The Gateway then transmits this command to the sensor. Subsequently, the sensor processes the request and transmits the Time Domain (Raw) data.

To understand the detailed structure of both processed and Time Domain (Raw) data messages within Node-RED, please refer to the corresponding User Manual. Consult the sections titled ‘Wireless Gateway Sensor Data Message (Processed)‘ and ‘Wireless Gateway Sensor Data Message (Raw/Time Domain)‘.

Share this on

You Might Also Like