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.
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
Only time domain data
7E00 1410 0000 0000 0000 00FF FFFF FE00 00F4 0800 0028 02CE
Command – F4 08 00 00 28 02
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
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
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.
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.
