Time Series Data - Wireless Vibration Sensor V2

I’m using an Industrial IoT Wireless Vibration & Temperature Sensor V2 MEMS along with the Industrial IoT Wireless to Ethernet Modem.

I have 2 functionality questions that seem to be different than the manual. For the Time Series Flag, the manual states below.

In practice, I was not able to set the Time Series Flag to 0x00 as the command would return 0x10 (undocumented error) instead of 0xff (command success). However, I was able to set the Time Series Flag to 0x02 which seems to enable the sending of time series data.

Based on the manual, I expected to get the normal vibration packet with the option of requesting time series data, but with the Time Series Flag set to 0x02, the time series data has replaced the standard data transmission. I am receiving 12 time series data packets each transmission instead of the standard packet without prompting.

Is this functionality correct and the manual incorrect or is there an additional setting that I am missing?

Another question, are there any recommendations on how to identify the time series data from other sensor data? I was hoping that the time series data would have a different header than 0x7f that could be used. Short of using packet length (in bytes 1 and 2), I’m not sure how to distinguish since sensor type has different offsets for the same header.

I can’t answer your first question, perhaps @Bhaskar can. However for identifying time series data packets from other I check the sensor type and length of the payload data. If the sensor type is 40 and the payload length is 180 then I know it’s time series data. I agree that a different header byte would have been handy.

The sensor has 4 time domain data modes

  1. No time domain
    sample complete API packet
    7E00 1410 0000 0000 0000 00FF FFFF FE00 00F4 0800 0028 01CF
    Command – F4 08 00 00 28 01

  2. Only time domain data
    7E00 1410 0000 0000 0000 00FF FFFF FE00 00F4 0800 0028 02CE
    Command – F4 08 00 00 28 02

  3. Time domain data with each packet
    7E00 1410 0000 0000 0000 00FF FFFF FE00 00F4 0800 0028 03CD
    Command – F4 08 00 00 28 03

  4. Time domain on demand
    7E00 1410 0000 0000 0000 00FF FFFF FE00 00F4 0800 0028 04CC
    Command – F4 08 00 00 28 04
    on demand works like this

let say you see an abnormality in RMS, Max and Min data. Then you can send a command to request the time domain data. This command needs to be sent within 1 sec of data reception.

To enable on demand time domain data send this command in configuration mode

7E 00 14 10 00 00 00 00 00 00 00 FF FF FF FE 00 00 F4 08 00 00 28 04 CC

command – F4 08 00 00 28 04

F4 – command header

08 – sub command

00 – Node id

00,28 – sensor type

04 – enable on command time domain data

Once the gateway receives the data, it needs to send a command to request time domain data

7E 00 13 10 01 00 00 00 00 00 00 FF FF FF FE 00 00 F8 99 00 00 28 3A

Command – F8 99 00 00 28

F8 – Command Header

99 – Sub command

00 – node id

00,28 – Sensors type

Once the sensor gets this command it will send RMS, Max,Min, vibration data plus the time domain data.

1 Like

Thanks for the replies @Bhaskar and @TravisE_NCD_Technica.

I have a follow-up question about the sensor ODR, is it possible to adjust the ODR without manually putting the sensor into configuration mode or is there a setting to have the sensor cycle through ODRs?

I’d like to use lower ODRs for the higher spectral resolution at low frequencies.

ODR and filtering can be set in cfg mode.
command for ODR is

Thanks @Bhaskar, I saw that it could be set in config mode.

I’m guessing that it can only be set in config mode, but what I’m hoping to do is change it while in run mode to receive something like the following…

340 Samples @ 400Hz --> FFT 0 - 200Hz with resolution of ≈1.18Hz
…wait transmission interval…
340 Samples @ 800Hz --> FFT 0 - 400Hz with resolution of ≈ 2.35Hz

340 Samples @ 12800Hz --> FFT 0 - 6400Hz with resolution of ≈37.65Hz
…wait transmission interval…
340 Samples @ 25600Hz --> FFT 0 - 12800Hz with resolution of ≈75.29Hz

My thinking was to create a composite FFT out of the above FFTs if it is possible with the sensor.

got it… i will see if we can add this in the run mode. keep in mind it will drain the battery at a rapid speed.

Would power usage be significantly higher than what it already is in Mode 2? The number of transmissions would be equal.

I noticed on the PCB that there are (what look like) solderable +/- voltage headers. Could the sensor be wired to an external power supply through those headers? If so, at what voltage?

the power consumption will be slightly higher… because sensor will wait for a command to change ODR.

it could work like this … lets say current ODR is 400 … gateway receives a packet with 400hz ODR then it sends a command change ODR to 800… then when the sensor sends next data packet it will be taken at 800hz.

This product can be purchased with optional external power supply.

@Bhaskar, that functionality would make sense to me.

Another option could be to add an ODR setting that auto cycles through the ODRs. That has the advantage of not having to leave the radio on after transmission, but has a disadvantage that you may not want to cycle through all the ODRs depending on what type of system you’re monitoring. I think the way you’ve proposed would make the most sense.

Thanks again for your replies, I’ll look around the store and see if I can find the optional external power supply.