Serial Read: maybe Termination character?

[benndamann33]

Sorry but I'm not getting any better results with that. with reading 6 bytes at a time I get quick plotting but it's dependent on when i press start... at the right time I get perfect results, at the wrong time I get nothing. The number i'm actually sending is ff99. With a long byte read it plots one data point every 2000 bytes and isn't any more accurate. I attached screenshots and a VI so if you can tell me how I'm implementing this incorrectly that'd be really helpful... do you think I need to do the checksum thing??

Thank you

Ben     

[benndamann33]

and here's the new code(cleaner) and a little altered

[RavensFan · Accepted solution]

The problem is the termination character is wrong for a space.

In your version 3 VI, the termination character was a front panel control set up for hex display, default 0A which is decimal 10 or a new line character.  You want it to be space, which is hex 20 or decimal 32.

You changed the control to a constant which happened to change the display of the constant to decimal.  So when you entered 20, you did not put in hex 20 (space) but decimal 20 (DC4 code).

Change your 20 to a 32 and try again.

[benndamann33]

that did line it up perfectly(thanks a ton)... one last problem(I hope) sorry for being such a rookie but I'm really not sure why this isn't working seems like it should be perfect now, but the hex string to number command must be outputting all 0s(the graph is graphing.. just everything is a zero!) Any idea's why?

Ben     

[RavensFan]

Perhaps you can post your code with some indicators set on different parts of the wire such as the string read.  Run it, save the values as default, then post the VI.

If I had to guess, the hex conversion is just not handling the string properly, perhaps there is an extra character?  The space is getting through.??  Hard to day without seeing the code as it stands now and some actual data that has been streamed in.

[benndamann33]

ravens fan,

thank you so much you saved me so much debugging time. The solution for the last part was just an extra character but i changed the offset to "1" ont the hex string to number and it worked perfectly ... thanks again!

Ben

[benndamann33]

Wow, unfortunately, I have discovered that I can no longer send strings with the pic, it's too slow. I spent hours to get this working how it was some am not too happy about this realization. Now I have a labview problem that I'm not sure I can solve... that is, now I send a high byte and a lowbyte, but I send their ascii equivalent because I'm sending a char! This means that i'm sending like "zz_" where _ is actually just space i'm just representing it as that. Is really 122 122. But 122 is the high byte... so really it's 31354... but is coming to labview as zz. I stil think  I can use the termination character method... but reading zz seems to throw my current labview file off. Any suggestions on how to modify this such that I can conver this character to a number... I guess I just really am lost from there. Very disappointing but if any ideas, please let me know. Thanks

Ben     

[benndamann33]

Here is my current attempt. Not sure what to do for two reasons now though: termination  value of space is not valid because could be a legitimate data point(corresponding to 0 in the low or high byte). MY conversion is right and works fine if I'm only sending 1 data point(one high one low) but once I get over that I'm running into the problem of lacking sync again. Any suggestions? Thanks

Ben   

[RavensFan]

So are you saying you are no longer sending a series of characters in 0-9,A-F  to represent bytes but are sending them directly as values.  If so, you aren't going to be able to use a termination character as any character could be part of a valid data stream whether it is the high byte or low byte.  You will need to read an even number of bytes at a time.  The hardest part will be aligning the bytes on your initial read because if you miss the first byte of a two byte pair, your data will always be off.

The best thing to do in this case would be to have one device send a query byte and waits for the other device to send data.  The other device does not send its two byte data packet until it receives the query byte.

By the way, look at the Join Numbers function on the Numeric / Data Manipulation pallette.  This will take 2 8 bit integers and join them to 1 16 bit integer (or 2 16's to a 32-bit).  It will make a little cleaner code than multiplying 1 byte by 256 than adding it to the other.  You can even use it with Decimate array.  This takes an array of 16 bit integers and converts it to an array of 32 bit integers.

Message Edited by Ravens Fan on 10-27-2008 09:29 AM

[benndamann33]

Okay, I'll try that although I'm not positive I'll be able to implement this on the pic or not. I'll try my best. Also... i am only sending 12 bits of real data... but sending two 8 bit numbres. So really I could start my low byte with 0 and high byte with 1... and do some sort of detect... should I be doing that?

Thanks much

Ben