Visa find byte

[kiandr]

Hi:

What is the way to begin a loop based on a spisific byte, which this byte changes and the same value aprears again in the data?

The VI here, reads the streaming byte, but I want to begin the reading of the Case loop, as soon as a value =14 aprears. I need to synchronize the bytes and start reading of packet of 25 bytes at spisific value. 

Imagin a code like:

if (Serial.avaliable()>0) // if bytes are coming

{

 int inByte[0] = Serial.read(); // read the first byte

 { if ((inByte[0] == 14) && (boolian_Variable==ture)) // if that byte is equal to 14 and the loop has not been started then read 24 bytes

    { for ( int i=1; i<24; i++)

       { inByte[i]=Serial.read())} // save 24 bytes into an array

   boolian_Variable=false; // set boolian false, in order to avoid runing this loop again

   Serial.print("inByte[3]); // serial print the desirable value

}

}

}

My apologies to friends who would wish to reply that that I run labview 9 on my machine. I will upgrade my system. 🙂

Thanks. 
KD.

[Ranjeet_Singh]

Why dont you read entire response then from the string palette retrieve string begin from desired byte ?

use one termination character to terminate & give number of byte to be read as bit higher.

Any difficulties in this 

[crossrulz · Accepted solution]

What I've done in the past is read all of the data available at the serial port.  I then use a search string to find the start character.  Then I use split string to get the 24 bytes of the message.  Save the remainder of the string in a shift register.  Repeat.  Append the newly read data to the old remaining data before performing the search again.

[Mark_Yedinak]

First, you should not initialize your serial port every iteration. It only needs to be done once in the beginning. Also, there is no need to convert the string to a byte array. You can use string VIs to handle the string itself. In fact you code use regular expressions to process the data. How well behaved is the data that you are receiving? Will there be other data that should be ignored in teh stream or is it basically repeating the "packet" with different data? If your data is consequtive packets than you should simply read 25 bytes at a time. You can tes that the first byte is the correct value (14) and then parse the remaining data. Do your packets have a specific terminator?

I would handle this a bit differently. I generally read data in a dedicated loop and pass that data to a processing task. This task would then parse the data. Depending on how your data is streamed you can use a regular expression ("\0E.*{24,24}" to extract the packet. This can then be parsed for the individual fields. I would recommend putting the parsed data into a typedefed cluster is it represents different values.

[kiandr]

Thanks all for replying.

1- The data has no termination character. 

2- The streaming data looks like the attached. There are 25 packets of five bytes which are being pasred into the serial three times a second. So there are data coming simultaniously. 

3- The tricky part is that I need to read only the Byte#4 from each packet and put it into an array or indicator or anything like that. Then I have to make sure that the reading will begin from the STAT2 which never changes its value, that is euqal to 14. The rest change constantly. 

4- The containing of bytes are not string, they are numbers from 0 to 255. For example the heart rate in Byte#4 being splited into two bytes, Most significant comes before the less significant byte. That i have to convert them into binary then add two into a 16bits packet, then convert into string or number. 

Q:Would it be possible to read or just listen to incoming bytes#4, as soon as value equal to 14 aprear read the rest of communication ?

Currently the problem that I am facing is that each time I run the sketch,  the order of bytes changes in the array. Once begin from STAT2 and other time from E-SPO2. 

The altimate gaol is to extract three bytes form that array in real time, 1- HR MSB 2- HRLSB and last SpO2. 

Am I in the right track, or there is a bette way to extract those value form the streaming bytes?

There have been some other suggestions, like making an array of 25*5 and extract the data. But, I could not do that simulaniously. My loop would read fill only the frist row of the table. Any suggestion or recomendation for that solution would be appriciated. 

Thank you all. 

[kiandr]

Mark would you be able to visualizse the idea please.

Thanks

[Mark_Yedinak]

Let me think on it a bit.

[kiandr]

Sure. 

[kiandr]

Guys, this is what I have came up with.Sounds like a solution. 

Solution: 

1- Search for the byte that you are looking for within the streaming data.

2- Use seach tool, that brings you back the index of that byte. 

3- Once you know where is the value that yo uare looking for, find the distanc of the desirable values from that data point. We call it Pointers in programming language.

4- Once the pointer has been identified, go over the array and extract the value. 

5- Note, that since the array lentgh is 25, the pointer value migh come anywhere between 0 to 25, thus, the worst case senario is that pointer is 24 and distance of value from that pointer is also 24. 

6- Change the size of the initial byte into double, in this case to 50, thus 25+25=50. change also the number of  loop "FOR" into 50. 

Is there any thing that I am missing?

Cheers Crossrulz, for the idea.

Thanks all for contribution.  

[Mark_Yedinak]

That may not work in the general case. What you need to do is find a way to sychronize yourself with the device. Once you are sychronized you can imply read 75 bytes at a time and you will get the complete packet. At that point the data you are interested in will always be in a defined location per the specification. The tricky part is getting sychronized since there doesn't seem to be a good constant in the data stream to key off of. Simply looking for the value of 14 may not work since it would be perfectly valid for any one of the data fields. If you are guaranteed to start reading the stream from the beginning I would simply read 75 bytes at a time. Otherwise you need a good algorithm to get in synch with the data stream. This particular protocol is not very nice in that regard.