Visa find byte

[kiandr]

Mark,

I totally agree. However, the synchronization is tricky. I have not found a stright forward way to sync with device. 

Cheers.

[Mark_Yedinak]

---

@kiandr wrote:

Mark,

I totally agree. However, the synchronization is tricky. I have not found a stright forward way to sync with device. 

Cheers.

---

That was the part that I have been thinking about. As I said the message protocol of the device is not very well defined in this regard.

Are the STAT2 and SREV bytes guaranteed to be a constant value while you are receiving data? If so they can be used to synchronize the data by looking for those two bytes appropriately spaced in the data stream. From there you can move to the start of the next message and establish synchronization. Another alternative would be if teh reserved fields are always a constant value (hopefully the same value) you can look for the pattern of 3 consecutive reserved bytes followed by 3 sets of 2 consectutive reserved bytes. Again with the proper spacing between them. The start of the next message would be the first byte passed the checksum of the last reserved byte.

I haven't tested this but this should be the regular expression to match the data from the first set of 3 reserved bytes, assuming they have a value of 0, through the last set of 3 reserved bytes: "\01..\00.\01..\00.\01..\00[\00-\FF]{81,81}\01..\00.\01..\00.". The next data packet will be the next data after the match. From there you should be able to simply read 75 bytes at a time.

[kiandr]

Mark, 

The only byte that the device sends and remains constant in the datastream is the byte STAT2, which  is equal to 14. 

Let me attach a picture of the incoming data. 

The array_Byte4, reshaps the incoming byte #4. Each values in this arraye chages after 25 bytes been recieved at the buffer. So the second byte in this array is the 50th byte in the buffer. 

How would you adjust this VI according to your recomendationto sync the device? 

cheers.

KD

[Mark_Yedinak]

Can you read about 300 bytes from the device and do nothing at all with the data. Don't process it in any way. Just put it inot a string indicator. Copy that string indicator into another VI, change it to a control and save the value as the default value. Then post that VI here. Your data in the array is not mathcing the specification that you posted earlier. I would like to take a look at the raw data you are getting.

[kiandr]

Sure, give me few minutes. 

[kiandr]

Mark, 

Her you are 300 samples. I read them right from the serial port.

Cheers

KD

[Mark_Yedinak]

Ok, here is an alogorith to get you sycned up with the data packet. I looked at the specification again and the first set of 5 bytes in a packet does contain a frame sync bit in the status field. The value of that field will be odd if it is the start of the data packet. Your solution of looking for the 4 byte equal to 14 is not reliable because it is possible that one of the values for any of your other data sets can also have a value of 14. This algorithm reliably syncs you up with the data packet. Once you get synched up you can simply read 75 bytes at a time.

This algorithm looks for a byte value of 01. It then calculates the checksum for the it and the next three bytes and checks if it equals the 5th byte. This would indicate you have a valid set of 5 data bytes. It will also check to see if teh status byte is odd. If both conditions are met you have found the start of a data packet.

[kiandr]

Indeed, I never look into the check sum option. Thank you.

Can you please help me to undrestand the funtionality of your algorithm. What is the output of the algorimth?

I connected that into the serial read and can not realize the operation of the loop. Would you please tell me what hppens As soon as the loop read 1?

Thanks

[Mark_Yedinak]

Going back to my earlier comment about reading in a separate loop and then passing the data to a processing loop the algorithm is expecting a larger buffer of data then reading a few bytes at a time. What this algorithm does is analyze the data buffer looking for the sync frame bit that appears in the first status byte of the 75 byte data packet. As specified each set of 5 bytes in the data packet begin with 0x01. This code looks for the first 0x01 in the data buffer. When it finds it it looks at the next four bytes and calculates the checksum. It compares the calculate checksum against the 5th byte after the 0x01. If the checksum matches that indicates we have an actual 5 byte data set. It then looks at the status byte to see if the synch bit is set. As defined this is the least significant bit. Only the first 5 byte data set in the data packet will be an odd value. If both the checksum matches and the sync bit is set the algorithm returns the index in the buffer of the data packet. Once you find that your are synced up and can process the data 75 bytes at a time. I did not implement the algorithm to handle the case if it does find the sync bit within the buffer. Since the device will return three sets of data every second you can let your read task read 225 bytes at a time. It can pass this to the processing task via a queue. The processing task can use the algorithm just to get the initial synchronization and then just read 75 bytes at a time from the buffer. If you consume the entire buffer and don't have a complete data packet you just have to wait for the receive task to pass more data. Concatenate the new data with the remaining data and begin processing 75 bytes at a time again.

If you don't want to use two loops you would have to read enough data to get in sync and then just read 75 bytes at a time from the device.

[kiandr]

Thank you Mark. I do really appriciate your time today.

Indeed, I could not do that all on my own.

Thanks.

KD.