Menu
Menu
Menu
This tutorial will introduce you to a very basic use case for the Vibration sensor in order to take you from setting it up to getting your first data set. It will be divided in the following sections:
Note: The software, drivers, etc. in this example are for Windows, however, they are also available for MacOS and Linux via their respective repositories.
This section will briefly explain the network structure one requires to utilize the example vibration sensor and process the data into human readable values.
As there is a built in FFT, data for the measurement components in frequency domain is available in raw form if one needs additional analysis. One can choose to either have the raw data transmitted or not.
As this is an Industry 4.0 device, it possesses advanced capabilities and measures directly and relays the data wirelessly. In order for this to work we need a gateway or a modem to act as a transceiver forwarding the data to whatever platform we have chosen for processing it.
We are not going to go into detail about the differences between a modem and a gateway (a detailed comparison can be found in this article). In short, the modem does not process the data in any way to translate it to human readable format, it can however convert it from communication protocol to another, however it still transfers data bytes in a binary format. This reformatted data is later on processed to give it meaning. Thus, we would require an additional component that processes the data after the modem, in this case we will be using Node-RED.
Gateways on the other hand add another layer of functionality on top of the Modem, they process the data from the raw sensor measurement bytes into meaningful values, like temperature, humidity, acceleration, etc. At this point the data is already parsed and can be ingested by a human, unless it is transferred for further processing.
NCD Gateways are compatible with most popular Cloud platforms, like AWS, Azure, or Losant. They utilize MQTT to efficiently forward the measurement results preserving bandwidth (especially valuable in data limited scenarios).
Note: As gateways process and convert sensor data they need periodic updates to account for new sensors being introduced to the NCD line of devices. This is not required when using a modem as it does not process data beyond translating it from one protocol to another.
NCD offers a range of Modems with different interfaces used for PC connectivity. One can get USB, RS-232, RS-485, Ethernet, Wi-Fi, and Bluetooth. All Modems offer identical functionality, with the exception of the data interface, they provide up to 2 miles of range and have no limit on the connected device. Do note that if you plan to use many devices and send data frequently the RF medium will get congested and they will interfere with each other. For this reason, NCD recommends you limit the maximum number of devices per Modem to 128. You can always add another Modem and create a new group of devices using the Pan ID feature (both Modems and Sensors support it).
For the purposes of this tutorial, an USB modem will be used to transfer the data to a Windows PC where an instance of the Node-RED platform will be running. Most modern PCs have an USB port which the Modem can connect to. The Modem has a built-in FTDI chip that converts Serial data over the USB interface, provided the necessary drivers are installed (instructions are in the next chapter). Using the Modem an an entry point, Node-RED will handle the following tasks:
With all the aforementioned components a system will be created that can obtain sensor data, and relay it over the modem to the Node-RED platform where it is processed and displayed for evaluation in a readable format.
Before installing the sensors, we need to make sure we have set up our software properly. This is essential the measurement data needs to be sent to a device that has the capabilities to process it and display it in a human readable way. NCD has provided all the necessary tools to do this, thus the following components need to be installed.
Drivers for the modem’s USB to Serial converter chip (FTDI FT232) are required for proper data flow. These should automatically be installed, however it is considered a good practice to install them manually in order to avoid issues.
You can download the package from the link here. The installation process is very straightforward just follow the prompts.
Now that you can properly communicate with the modem, it is time to power it on. Make sure to install the antenna before you do this, screw it to the antenna port on the side. Insert a Micro USB cable into the connector opposite the antenna side on the device. You can remove the top cover at this point to check on the Status LEDs (it is held by 4 screws, should be loosely tightened).
USB: Lights up when the USB port is connected and the Modem is powered on
TX: Blinks when the Modem is transmitting
RX: Blinks when the Modem is receiving
RS: Indicated the Modem being reset
Only the USB LED should be alit, as there is no communication going at this point.
The virtual COM port should be recognized at this point, check it in Device Manager.
Take note of the port number a; you will need it as an input parameter when configuringour Node-RED Flow.
You will need two components in order to install Node-RED – Node.js and npm. These are both installed via the latest Node.js LTS package you can find via the link.
Once the installation is complete double check that both are properly installed by checking their versions via the commands below.
node --version && npm --version
You should get a response similar to the one below (you might have a newer version depending on the time you are reading this guide).
Having the prerequisites, you are now ready to install Node-RED. This will also add the node-red command to your system path:
npm install -g --unsafe-perm node-red
You should now be able to run Node-RED via the command:
node-red
If your installation went well you should have a folder created in your home directory named .\node-red. For example, on a Windows PC given that the current user is NCD:
C:\Users\NCD\.node-red
The last thing we need to do is open up a command line window, navigate to the aforementioned directory and install the NCD Wireless Sensor Line package that we are going to be using with Node-RED. For example:
cd C:\Users\NCD\.node-red
npm install ncd-red-wireless-2
This should install the two necessary blocks we are going to be using to connect the USB modem and configure the sensor.
If you import the following json file into your Node-RED flow you should end up with the proper setup and you only need to configure the two nodes.
If you take a look at the image below it shows what the imported flow should look like. You should have 2 nodes in gray, one for the Modem (Wireless Gateway) and one for the Vibration sensor. Each of those is connected to a debug blog so we can see the messages they receive/send.
Let’s start by configuring the Modem.
Double click on the block, this will open the Properties window. Navigate to the Serial Device drop down menu, this is where serial devices you have created can be selected. As this is your first one, it should be empty, thus you need to set up a new one by pressing on the Pencil icon marked in red in the image below:
You can now add the proper configuration for your mode. Configure the following parameters and leave the rest with the default values.
Modem Type: USB (Serial)
Serial Port: COM9 (you can look yours in Device Manager)
Baud Rate: 115200 (default for this Modem)
Once done, press the red Add button and this will create the Serial device for you, it should be populated as in the image below. Press Done and you are ready configuring the Modem.
Next, we configure the Sensor, open up its Properties.
We need to set up the following:
Serial Device: COM9 (115200) – your port number might differ
Serial Device for Config: COM9 (115200) – your port number might differ
Sensor Type: One Channel Vibration Plus (find it in the drop-down)
Auto Config: Enable (allows to configure more parameters later)
Take note that this sensor supports OTF (On The Fly) configuration, make sure you enable this so we can change sensor settings without having to put it in configuration mode manually.
Press on the Done button to accept the changes.
Everything should be configured at this point, so you can press on the Deploy button in order to initiate the changes.
The sensor comes with batteries included and it is turned off in order to preserve them. The antenna and the sensor probe are delivered disconnected and you need to connect them before powering on the device.
The smaller connector is the RP-SMA antenna one and the larger one is the M12 sensor probe.
With the antenna and probe now connected you need to move the switch from OFF to ON by sliding it towards the casing wall in order to start up the device.
Refer to the image below in case of doubts.
Once all of the above has been accomplished assuming the modem has been powered on as well your sensor will connect wirelessly to it and start transmitting data.
The sensor executes a specific procedure every time it is started up, either for the first time or after a reset. With our current configuration (OTF mode enabled) it executes a series of commands, which is represented by the diagram below.
Every subsequent packet will adhere to the updated configuration parameters. Once an hour the sensor will check for any configuration updates so it will pull them automatically, unless you reset it beforehand which will push them manually. This way it always remains up to date.
Let us take a look at that last Data Packet more closely. We will not go into details in all of the measured data, however we will discuss its overall structure and the most important metrics.
If you expand the “object” field you will see the list of parameters as displayed in the figure below:
mode: 2
This indicates the current sensor mode, in this case Processed + RAW In this mode the sensor will send the processed data (image above) and also the raw measured data that can be extracted if one needs detailed info.
odr: 800MHz
This is the Output Data Rate, from the sensor. Make sure that this is at a frequency that is greater than the frequency of the vibrations you are trying to measure if you want accurate readings.
temperature: 22.25
The current temperature the probe head is measuring. The sensor needs some time to acclimate itself so make sure to give the sensor sufficient time to temper itself.
X axis metrics
x_rms_ACC_G: 0.045
The Root Mean Square acceleration in [g] over the X axis. The value indicates the device under observation accelerated in the direction, however very minimally on average.
x_max_ACC_G: 0.048
The Maximum acceleration in [g] over the X axis. The value indicates the device under observation accelerated in the direction, not a lot at its peak compared to the average.
x_velocity_mm_sec: 0.4
Velocity in [mm/s] over the X axis. The value indicates there was movement in the X direction, but a relatively slow one.
x_displacement_mm: 0
Displacement in [mm] over the X axis. In this case there was no difference between the starting and ending position of the device under test.
x_peak_one_Hz: 194
Frequency of the vibration over the X axis where the First highest peak value is.
x_peak_two_Hz: 0
Frequency of the vibration over the X axis where the Second peak value is.
x_peak_three_Hz: 0
Frequency of the vibration over the X axis where the Third peak value is.
Y axis metrics
y_rms_ACC_G: 0.05
The Root Mean Square acceleration in [g] over the Y axis. Similar acceleration to the X axis
y_max_ACC_G: 0.049
The Maximum acceleration in [g] over the Y axis. Again, similar to the X axis
y_velocity_mm_sec: 0.45
Velocity in [mm/s] over the Y axis. The devices moved over both the X and Y axis with comparable velocity.
y_displacement_mm: 0
Displacement in [mm] over the Y axis. No displacement on both X and Y axis.
y_peak_one_Hz: 194
Frequency of the vibration over the Y axis where the First peak value is. Same as the Y one.
y_peak_two_Hz: 146
Frequency of the vibration over the Y axis where the Second peak value is. In comparison there was no Second peak over the X axis
y_peak_three_Hz: 164
Frequency of the vibration over the Y axis where the Third peak value is. There was no peak for the X axis.
Z axis metrics
z_rms_ACC_G: 0.038
The Root Mean Square acceleration in [g] over the Z axis. Over the z axis the device under test moved the least.
z_max_ACC_G: 0.026
The Maximum acceleration in [g] over the Z axis.
z_velocity_mm_sec: 0.69
Velocity in [mm/s] over the Z axis. The value indicate there was movement in the Z with somewhat greater speed compared to the X and Y
z_displacement_mm: 0
Displacement in [mm] over the Z axis. In this case there was no difference between the starting and ending position of the device under test.
z_peak_one_Hz: 194
Frequency of the vibration over the Z axis where the First peak value is. Same as the other 2-axis.
z_peak_two_Hz: 97
Frequency of the vibration over the Z axis where the Second peak value is. Lower than Y.
z_peak_three_Hz: 49
Frequency of the vibration over the Z axis where the Third peak value is. Lower than Y.