Can't sync to device through serial port

[Alzest]

I have to read data from a DSP related to an ECG. In order to do this I have to find 5 bytes (0x00 0x80 0x00 0x80 0x00) in a specific order that are sent through the port every second. I have monitored the data sent through the port and those 5 bytes are in fact getting received, however I havnt managed to find them with my VI. I've tried many different ideas without succes and perhaps Im doing something wrong. My latest attempt is using a Wait on Event so I wont miss any data. Ideas? Seeing anything I'm missing?
I would really appreciate any help!

[RavensFan]

Generally Bytes at Port is the wrong method to use to read from a Serial Port.  Why?  You wait on event.  Bytes start arriving at the port so you stop waiting.  Then you check the number of bytes at the port and read only that many.  Suppose you have a dozen bytes arriving?  If you wait on events and only the first few have arrived by the time you stop waiting and count the number of bytes at the port, you are going to miss the additional ones coming in.  Then it gets worse because then you go and flush the port which means they get erased.  (Flushing serial ports is generally a bad idea as well in my experience.)

Do you have an expected number of bytes to read?  Or a termination character?  (Probably no for both questions because it looks like you are trying to read binary data.)  What you should do is Wait on Events.  Go ahead and read the bytes at port and Read that many bytes.  Then check to see if you have what you are looking for.  You can probably use a Search string function to see if that byte combination exists.  If it doesn't, then put the string into a shift register.  Next loop iteration, concatenate that string with the new string you will read and search again.  You don't say what you are supposed to do if you do find that byte combination.  It might be to write data to a file, convert it to numerical data, graph it, ....  What you can then do is work with that data and store and excess string data into the shift register instead of the entire string.  DON'T flush the port or you will definitely lose data.

[crossrulz]

What Ravens described is very similar to what I had to do for a few systems.  I wasn't completely happy with it, but it worked very well.

Just an additional note.  If you don't find your sync in the stored string, you can throw away all but the last x bytes (x = length of your sync).  This will keep your string from getting abnormally long.

[Alzest]

Thank you very much! This is exactly the kind of highlights I need since I don't have much experience and miss a lot of things most of the time. I wil definetly try this and come back to tell you how it goes. And it is indeed a no to both answers, the DSP just sends the stream of data continously through the serial port and expects nothing back, no confirmation or anything. All I have to do is read the data it sends, the synchronization bytes I was talking about are sent along with 4 more bytes that indicate Packet Number (0), Heart Rate and Lead Status Low and High. Then it sends data from the ECG: 8 bits high waits 500us and sends low, those 2 bytes represent 1 Lead out of 8 for a total of 16 Bytes.  every 16 Bytes (8 ECG Leads) Packet Number goes up 1. Since the header with the 5 Sync Bytes is sent every second (along with the Packet Number being reseted to 0) the DSP manages to send 124 (0x7C) Lead Data Samples for a total of 1984 Bytes per second, according to my calculations. You can check this out if you take a look at the data samples I added to the post.

[Alzest]

Ok here's how it turned out. I followed your recommendations and managed to sync a few times however it's still missing something since it is supposed to syncrhonize each second and it does it a random number of times in a random period of time (say, after 10 seconds 2 synchronizations are made at once, then one 15 seconds later and so on).

I removed the flush and changed from working with byte arrays to strings and it simplified everything, thank you for that also.

[Alzest]

Ok check this out, assuming that there's at least 2 bytes sent per milisecond I switched from Wait On Event and Bytes at port to setting a constant to 5 for the byte count in Read and added a 1ms wait for each iteration. As the image shows I have found even more matches in the strings, however the time is still an issue.

[RavensFan · Accepted solution]

I think you are using the wrong function.  You are using Match True/False String.  Context Help says "Examines the beginning of string to see whether it matches true string or false string. This function returns a Boolean TRUE or FALSE value in selection, depending on whether string matches true string or false string."  Well, suppose the string is not right at the beginning but as another byte in front of it?  It won't find the searched for string.  And wiring the same search into True and False is odd because if it is found, then it matches both True and False at the same time.

You should be using Search and Replace String or Search/Split String to determine if and where the search string occurs in the larger string.  (I would pick Search/Split).  If the string is not found it returns a -1, otherwise it returns the location of the string.  And it has the advantage of returning everything after the match that you could feed into the shift register for a search on the next iteration.

[Alzest]

Well once again your solution worked out just perfect. After I changed to search/split I finally got my program to sync with the DSP without trouble, now I just need to separate and classify the data that comes after... but that's a different topic =). Thank you very much and greetings from Mexico!