Could not read waveform vib sensor V3

When we receive the data and parsing it out, we send immediately the request command to read raw (waveform), looks the sensor responded but we cannot parse it:

command: 7e 00 13 10 00 00 13 a2 00 42 29 e8 4a ff fe 00 00 f4 4f 13 00 00 4a
-MAC: 00 13 a2 00 42 29 e8 4a (OK)
-cmd: f4 4f 13 00 00 (Based on Manual)
-Check sum: 4a (OK, based on Digimesh API)

The sensor responded with something that I cannot parse it based on Manual:
respond: 7e 00 13 90 00 13 a2 00 42 29 e8 4a ff fe c2 7c 65 00 00 50 00 01 2c
MAC: 00 13 a2 00 42 29 e8 4a
Unknown: c2 7c 65 00 00 50 00 01 ???

After we received nothing else. I am not sure what I am missing. Please could you help.

Please Bhaskar, any update on the waveform issue. I am kind of stuck here trying to read the waveform. Sometimes after sending the request command the sensor respond with the message I mentioned before but other times doesn’t respond to it. Thanks

its an error response for wrong command sent
the correct command for requesting data is “0xF4,0x4F,0x00,0x00,0x50,0x13”

for dual probe sensor raw data probe one command “0xF4,0x4F,0x00,0x00,0x50,0x13,0x01”
raw data probe two – "0xF4,0x4F,0x00,0x00,0x50,0x13,0x02’

Thanks, I will give a try.

a) Does the response of 205 bytes for waveform packages follow same structure regardless if it is one probe sensor or dual probe sensor?
b) In case of dual probe sensor, should I wait until the first one is completed, to read the second one, or should we handle simultaneously and send command to both at the same time?

  1. correct. the packet does contain the info if data is from probe one or two
  2. You can request data only from one probe in one instance.

I am getting an error every time want to parsing waveform following the manual. Looks something is missing.
I am getting frame of 205 bytes except last one is 46 bytes. The header info is parsed well, I checked with Node-Red. Now lets take 205 bytes of the entire frame, the payload = 205 - 4 (first 3 bytes + check sum). So we have payload of 201 bytes, after we took the standard payload info (Frame type, HW address,… until status) which are total of 21 bytes before the data sensor starting. In our case will be 201 - 21 = 180 data sensor length.
Now working with sensor data, according to the manual, it shows first 9 bytes of data sensor are for header info (oper mode, … current pack) . So from 180 -9 = 171 are the remaining bytes for parsing waveform. the waveform consist of 6 bytes (2 bytes per axis X,Y,Z). Which means we expected 28 packages, plus 3 bytes more. What the 3 bytes are for? I couldn’t find in the manual.
Waveform, Raw data, total length = 205, payload length = 201
7e 00 c9 90 00 13 a2 00 42 29 e8 4a ff fe c2 7f 65 0b 03 f8 01 00 50 00 (24 bytes)
Sensor data (180) : 01 0a 47 00 21 09 eb 1d 01 (first 9 bytes - this match manual so far+ 171 remaining to extract 2 bytes x axis?)
waveform (171) : 02 e0 01 6f f0 40 03 11 01 2f f0 7b 02 f7 01 66 f0 7e 02 eb 01 5b f0 6f 02 f4 01 40 f0 7e 02 e3 01 46 f0 3a 02 fa 01 35 f0 89 02 fa 01 66 f0 84 03 2e 01 43 f0 7e 02 f1 01 4f f0 75 03 00 01 58 f0 6c 02 da 01 75 f0 5e 03 00 01 69 f0 09 03 31 00 fa f0 d9 02 c8 01 8c f0 60 03 3d 01 0f f0 b0 03 03 01 3b f0 98 02 e6 01 66 f0 4f 03 06 01 2f f0 b8 03 3a 01 15 f0 aa 02 8e 01 d2 f0 0e 03 51 01 20 f0 aa 03 1d 01 0f f0 81 03 0b 01 61 f0 35 03 06 01 58 f0 78 02 f7 01 81 f0 2f 03 31 01 09 f0 b5 02 c0 01 a1 f0 60 (02 c8 01) ??
Check sum 11


Think of the packets as a train of bytes. The packet’s job is to move bytes around, it doesn’t know if it’s a complete packet or a half packet.
the acceleration data is stored like this x1,y1,z1,x2,y2,z2 ---------- xn,yn,zn

it is NOT true that a single packet contains a complete set ( by set I mean x,y,z). The packet can end with only x, and the next packet will start with y and z.

each packet contains the total number of the packet and the current packet counter. this info can be used to rebuild the entire packet.

Oh, now make sense. Ok, I will do it that way, I will store as train of bytes first, and after at the end when it is last packet, do the parsing.
Now this will work for single probe vibration sensor, please when have two probe vibration sensor is the same process?

The process will be the same for probe two.

In one go you can only request data from one probe. to request data form second probe you will have to wait till next interval

Hi Anil
We are sending the cmd (see at bottom) to the vib sensor (single probe) for reading raw data, I was happy because it responded with the completed waveform, it was good, but only first time. after when get processed data again, we send the same same command in ms but the sensor doesn’t replay back. I changed the timeout to 5 seconds, more than enough, doing same. Now interesting, I noticed if I go to the work flow, enable the flow, and forced to load the configuration again, I disable the flow, it will work fine the first time. I tried reset it, power cycle, and getting same result, only first time will work after reloading the configuration!
request: 7e 00 14 10 00 00 13 a2 00 42 29 e8 4a ff fe 00 00 f4 4f 00 00 50 13 fa
Not sure what I am doing wrong or missing part here.

if you are using the node red flow from my repo then you will have to active the inject node every time you need the raw data.

We are using the node-red only to configure. The reading process is thru our python driver. All the processed data is reading fine in our driver every time, but the waveform only the first time after the sensor is configured, not sure what is mystery here.
First picture is when reset sensor after configured in Node-Red, that we can read the waveform one time/

The second picture is the second time receiving processes data, and send the command out, but the sensor didn’t reply.

Set your node id to zero and test.

Doing the same. Only first time after configured the sensor send back the raw data, after 5 min or reset only broadcasting processed data but doesn’t respond to the request command. I tried multiple times, look he only way to make the sensor respond is forcing the loading of the configuration again.

I tried with the Comm Operator, and it is doing similar, couple of times that respond only after configured, after doesn’t respond any more but if I am doing very fast. Now if I wait little bit lets say 1-2 seconds without timing out , it will respond. So do we need wait little bit before send command out, maybe we are sending too fast?? Do we need special conditions for sending the command back on TCP?

did you set the node id to 0 and test ?
wait for 250 msec before you request the data.

Yes I set Node ID =0, doing same. This is seems a timing issue, because using Comm Operator doing same.
OK I will wait 250 ms, and see.

I did another testing just using Comm Operator. I reset the sensor, wait for the FLY message to show up, sent 3 times the request command (crazy because it is before the real data), then wait for the processed data, and send the command again, this will work, and from there when finish showing processed data (maybe manually around 1 sec), if I send the command, the sensor will respond. it is like unblocking something in this way, I don’t know. Could be related with timing or sync issue?. It looks when in the python driver is sending the command, something in the sensor gets blocked related with the mechanism of the waveform dispatch. I tried in the python to wait a range of ms until 1.5 sec, and it s doing same. I also sent each byte with a tiny delay, same. Only after doing the tricky mentioned, we can read at regular bases from Comm Operator. Please any thoughts?

There is no known issue like this.
When it sends FLY, it’s waiting for the CFG command, so if you are sending a data request command, it won’t work. set the raw on request timeout to 10sec. may be the mesh network is taking sometime to build. This could happen if the sensor and mode are rebooting.

@jacob in node red how long do we wait before sending raw on request command?