serial data myrio

[JCG77]

Hi everyone,

I've got a touchscreen connected to teh myRIO and I'm trying to read serial data form the touchscreen. The data I need is 10 bytes long and has a distinct first and second byte. When I'm reading the data it does not always come in starting at the start bit. It might come in starting in the middle of the string of 10 bytes. Can anyone please explain to me why this is happening?

Thanks,

James

[crossrulz]

If the touch screen is sending data fairly constantly with little gap between messages, then this is a common problem.  The issue is that you start reading when the source is half way through a message.  So you have to do something to get in sync with the message.  Could you explain more of how the data packet looks?  I'm sure it is smart enough to leave a way to know if you have the complete message.

[JCG77]

[55] [54] [04] [FC] [0C] [A8] [0E] [FF] [00] [6A]

The table below shows the function of each byte.

55 54 04 FC 0C A8 0E FF 00 6A

Lead-in

Command

Status

Xlo

Xhi

Ylo

Yhi

Zlo

Zhi

Checksum

And the table below explains the function of each.

Lead-in* Command Status** Xlo Xhi Ylo Yhi Zlo*** Zhi Checksum*

55	The first byte of a SmartSet serial data packet is always 55 hex
54	In ASCII, this is a 'T', which identifies a Touch response
01, 02 or 04**	01: Initial touch; 02: Stream touch; 04: Untouch.  The 0 is replaced by an 8
00 - FF	X-axis (horizontal) data
00 - 0F	8 bits of low byte data, 4 bits of high byte data
00 - FF	Y-axis (vertical) data
00 - 0F	12 bits total data, for a range of 0 - FFF hex, or 0 through 4095 decimal (both X and Y)
00 - FF	Only 8 bits of Z (touch pressure) data
00	No high byte data for Z
00 - FF	All previous bytes are added; result is put here

This is what one data packet looks like from start to finish. When the data gets read I can see these numbers only every time I read them I get many 10 byte strings of data. I have a loop that reads the data. If I read the data at the same speed as the baud rate do you think that will work?

[crossrulz]

When your program starts, you should read 1 byte at a time until you find the 0x55, then read 9 bytes.  If the CRC checks out, continue to your main loop, reading 10 bytes at a time.  If not, repeat reading until you get a 0x55 and a valid CRC.

[JCG77]

That's sort of what we're trying to do. I'm not at school right now but I'll show you my program first thing when I get there tomorrow. We're using a queue state machine to pick out the 10 byte strong by filtering using the start but 55 and the second but 54. If the program finds a string starting with these two bytes then the string is queued and then used somewhere else. If the 5554 bytes are not found then the producer loop continues until it finds it. The problem is the producer loops sends data to the consumer loop every time it gets the correct 10 byte string but when the producer loop needs to reiterate a bunch of times our consumer loop just waits. And the time the consumer loop waits results in a sort of jerky motion. It would be nice if we could make this process smoother. I wonder if speeding up the producer loop would help or if data would just build in the queue and cause problems there. I guess you could say that the problem is our producer loop and the consumer loop do not match times. 

[JCG77]

Here is the VI I'm using. Please let me know if I need to down-save it to LabVIEW 2014

[crossrulz]

Let's start with making sure your serial data is in sync first.  Here is what I propose.  You have a state on the read of whether or not you are in sync.  If you are not, you read a single byte until you find the 54 and then read the other 9 bytes.  Do whatever checks you have to in order to verify you are actually in sync.  Once you verify, then the status goes to TRUE and you just read the 10 bytes, verify them, and send the data through the queue.