Serial Device Communication Issues

[crossrulz]

---

@ROtake wrote:

It looks from the manual that the instrument will continuously spit data over serial every second. So you can use the function "bytes at port" that will return the number of bytest at the serial port. Wire that byte number into the Read function.

Every time it executes, it will check the serial buffer, and read the amount of bytes at the port. You will need then to find a way to extract the number from Air, xxx, MPS.

---

DO NOT USE THE BYTES AT PORT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (still not enough emphasis)

Unfortunately, it looks like this device just sends 3 values with a comma after each value.  The message does not have a real proper termination character.  I would like to see the actual hex values to confirm that.

At the top of my head, I would probably set a comma to be the termination character (44, 0x2C).  Then do 3 reads.  The first read can have a "long" timeout and then the other 2 have really short timeouts.  In theory, your first read will take up to 1 second and the other 2 will be immediate.  If you don't get the last 2 really quickly, you are not properly synchronized to the message and you need to wait for the next set of data to come through.  But if successful, scan the second read to get your measurement.  This is more complicated than it really should be as you will be needing to change the timeout back and forth between 1250ms and 10ms (values that I would probably choose).  But these kinds of hoops are what you have to go through if the ASCII messages are not properly terminated.

[fmorqT3]

Here is the hex display for the read buffer. Unfortunately there does not seem to be a termination character.

I appreciate your response and I'll give that a shot, although I'm not sure how well that'll go. If it's too complicated I might be better off just using Parallax Serial Monitor and then cleaning up that text data instead.

Out of curiosity, why is it inadvisable to use Bytes at Port? Most of the posts I saw about serial devices have comments saying to not use it and I was just wondering why.

Thanks for your help!

[crossrulz]

---

@fmorqT3 wrote:

Out of curiosity, why is it inadvisable to use Bytes at Port? Most of the posts I saw about serial devices have comments saying to not use it and I was just wondering why.

---

Your 14 byte capture is a prime example for why it is inadvisable.  Notice that your read spans 2 messages.  By using a termination character, you are more properly synchronizing to the message frame.  This makes parsing A LOT easier

[AeroSoul]

---

@crossrulz wrote:

At the top of my head, I would probably set a comma to be the termination character (44, 0x2C).  Then do 3 reads.  The first read can have a "long" timeout and then the other 2 have really short timeouts.  In theory, your first read will take up to 1 second and the other 2 will be immediate.  If you don't get the last 2 really quickly, you are not properly synchronized to the message and you need to wait for the next set of data to come through.  But if successful, scan the second read to get your measurement.  This is more complicated than it really should be as you will be needing to change the timeout back and forth between 1250ms and 10ms (values that I would probably choose).  But these kinds of hoops are what you have to go through if the ASCII messages are not properly terminated.

---

Would reading 13 bytes, checking the "width" of data, then reading one more byte if "width" is more than 4 work?

Aka if full message would be "Air,10.23,MPS,", you'd read 13 bytes and get "Air,10.23,MPS" see that data is "10.23" with 5 bytes width, then read one more to get the last ",". If the data would be e.g. "9.98", the width is 4 and you don't need to read any extra bytes.

[crossrulz]

That would workk if you assume you are starting at the beginning of the message.  What if your read starts in the middle?  For example, what if you read "0.23,MPS,Air,1".  Now what will you do to get your data?  How will you sync back up?  This is why termination characters are so important when dealing with ASCII data.  It is very simple to just read until the termination character and then process the message since the termination character does the synchronizing for you.

[AeroSoul]

Couldn't you discard the incomplete data and then let the timeout handle syncing?

[crossrulz]

---

@AeroSoul wrote:

Couldn't you discard the incomplete data and then let the timeout handle syncing?

---

Due to the rate at which this instrument sends out the data, you may get away with it (1 second is an eternity to a computer).  The method I outlined above would also depend on the "long" timeout in order to synchronize to the beginning of the full message.