03-26-2016 04:41 PM
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
03-26-2016 06:59 PM
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.
03-26-2016 07:23 PM
[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?
03-26-2016 07:45 PM
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.
03-26-2016 08:39 PM
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.
03-27-2016 06:35 AM
Here is the VI I'm using. Please let me know if I need to down-save it to LabVIEW 2014
03-27-2016 07:30 AM - edited 03-27-2016 07:31 AM
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.