Matt,
I know all that. Asc("0"

is NOT 0. The problem is that characters actually don't arrive at the COM port as a string (and string being "readable data"

. But when reading it through the usual VB controls, you'll get a string, won't you? And this string, when printed contains the most serious rubbish you've ever seen, since it is not meant to be a readable string. So when anyone sending an actual 0 (ascii 0) into his/her COM port, the string returned from the receiving COM port will actually be this ascii 0 and not the ascii 48 (which would be a readable "0", if I'm not mistaking..).
So when reading byte data at the COM port you should always take ASC, since this is exactly the byte value it should represent. How else would you send a byte value of 234? This would mean that you need three bytes to send this value over ("2" + "3" + "4"

. People don't send over data this way. At least, I wouldn't (and I've also never seen data being send over that way). And EVEN if this would be the case, you'd still have to calculate the BCC like I did, since these are the acutal bytes that have been send / are to be send. After all; it's all about checking if the same data that has been send, also has arrived, isn't it?
And I did take in account the control byte, since my string says strTest, which is up to the user to enter any string he/she wants to test. Taking in account any control characters is up to the application, the loop just calculates the BCC of the specified string....
I'm probably very bad or, at best, very vague in explaining what I want to state. Still I hope you understand the point I'm trying to make here...
Greetings,
Rick