Start of frame (SOF) in Visa serial read

[Thrall]

Hello everyone!

I am trying to improve my communication protocol.

Basically, I have a microcontroller sending 5 data bytes + 1 EOT character to my bluetooth which then transmits to my VI. Everything works fine, and I can get the data precisely.

However, I would like to remove the EOT char.

So, I used the byte count parameter in the Visa Read block and it worked (some times).

The obvious synchronization problem is that my microcontroller keeps sending data even if the bluetooth isn't paired, causing the read to start in the "middle" of the whole message.

In my VI, there is a "connect" button to pair the bluetooth and start reading. So, to avoid this problem I was thinking about this: make the microcontroller start conversions after the bluetooth is connected.

In other words, when I press "connect", I send a character to the microcontroller to wait 2-3 seconds (so the bluetooth have enough time to pair) and then send the bytes continuously. This way, the very first byte that comes in will be my SOF. However I am not sure that the Visa Read will read all zeros in this meantime... if it does then this whole thing won't work because when the data comes in, it might start reading in the "middle" of the message.

But I am hoping that the Visa Read will begin to read only when a start bit appear, in which case it would wait those 2-3 seconds. So I assume this would work.

I couldn't find much about  this on google so that's why I'm asking here. And since I'm on vacation I can't test it. But I can't stop thinking about it.

Any thoughts about this matter?

Thanks =]

[Bob_Schor]

For most VISA reading, especially if there is an EOT character, a reliable "reading scheme" is to configure VISA to use EOT as its "Termination character", to never use "Bytes at Port", but to read 1024 (or some other large number) of characters (which will stop the read when the EOT is read).

In MAX, you can set VISA up to "Suppress End on Reads", which I assume means to not include the EOT with Reads.  There may be (and probably is) a similar VISA Property, but you can also simply take the String that VISA Read returns, lop off the last character/byte, and you're done.

Bob Schor

[Thrall]

Thanks the reply!

What you described is what I have for now. I read everything but I simply discard the EOT character and use only the Data frame on my VI.

I should have been clearer: I don't want to have to transmit the EOT character because by doing so, I can increase the speed of my transmission (instead of having to send 6 bytes, I send only 5).

In fact, there is another problem: if I use the EOT, VISA might end the transmission if the data frame has the same bit combination of that character. This gives me an error on the output, which I want to avoid. This is the main point here.

By the way, the solution I described in my first post, do you think it would work?

[Kevin_Price]

My advice is: be sure you have a really *good* reason to remove the EOT character from your protocol.  Without it, you make framing errors more likely and recovery from them more difficult.  Are those risks worth saving 1 byte per frame?  In my experience, that answer's only rarely "yes".

-Kevin P

[crossrulz]

How are those 5 data bytes encoded?  Are they always ASCII characters are are they raw bytes?  What are you using for an EOT?

Regardless of format, you are streaming data.  Therefore you need to have synchronization of some sort regardless of when the connection is made.

For ASCII messages, a termination character (typically a Line Feed) is used to mark the end of a message and that is all you need.

For raw data messages, I typically see a start byte, a message ID and/or data length, and a CRC.  Since your messages are always 6 bytes, you could get away without the message ID.  But binary messages should NOT be using the Termination Character setting in VISA.  I typically read 1 byte until I find the start byte, then read enough for the message ID/data length, and then read enough bytes for the rest of the message.  Finally, check the CRC to see if you got a good message.  If not, throw it away and start over.  If good, send it off to another loop for processing and start over.