eVB/CE3: Binary data received is not what is being sent 
Author Message
 eVB/CE3: Binary data received is not what is being sent

Hi --

We're writing a program for a Windows CE 3.0 handheld device using embedded
VB. This program needs to connect to, and communicate with, a host computer.
The protocol requires single-byte binary communication (no Unicode).

We've run into a snag while testing the handheld on the real host software.
Sometimes the two computers will transfer data without a problem; others,
the host will reject data being sent from the handheld device. We narrowed
the problem down to erratic CRC16 checksums being sent to the host. From
there, we further narrowed the problem down to an apparent problem in
sending the actual bytes.

The code segment below illustrates the problem. Running on the handheld
device, this code will output 256 bytes, from 0 to 255 decimal (00 to FF
hex).

We run this code with the handheld device connected to a PC that's listening
on the comm port. The PC displays the decimal value of each byte received
from the handheld. The output of this test is also reproduced below.

The problem occurs with bytes 128-159. If you check the output table, you'll
see that the PC does not seem to be receiving the correct data (because the
handheld isn't sending the correct data?). When the handheld supposedly
sends out a 128, the PC receives a 172. When the handheld sends a 130, the
PC receives a 26.

The result within our application is that CRC16 checksums are being
misinterpreted by the host, and the host rejects the handheld's data
transfer.

We've been able to reproduce this problem on three different handheld
devices. Two run different releases of Windows CE 3.0; the third is a newer
Pocket PC device.

Why is this problem occurring, and how do we fix it?

Thanks,
CL

***** HERE'S THE TEST eVB CODE *****

Option Explicit

Public Declare Function WriteFile Lib "Coredll" (ByVal hFile As Long, ByVal
lpBuffer As String, ByVal nNumberOfBytesToWrite As Long,
lpNumberOfBytesWritten As Long, lpOverlapped As Long) As Long

Private Sub Command1_Click()

Dim lpBytesWritten As Long
Dim i As Integer
Dim lDummy As Long
Dim bArray(255) As Byte

If Comm1.PortOpen = False Then
    Comm1.CommPort = 1
    Comm1.Settings = "9600,N,8,1"
    Comm1.InputMode = comInputModeText
    Comm1.RThreshold = 1
    Comm1.InputLen = 0
    Comm1.PortOpen = True
End If

For i = 0 To 255
    bArray(i) = Chr(i)
Next i

For i = 0 To UBound(bArray)
    lDummy = WriteFile(Comm1.CommID, bArray(i), 1, lpBytesWritten, 0)
Next i

End Sub

***** AND HERE'S WHAT THE HOST PC SEES COMING THROUGH *****

         0       1       2       3       4       5       6       7       8
9

       10     11     12     13     14     15     16     17     18     19

       20     21     22     23     24     25     26     27     28     29

       30     31     32     33     34     35     36     37     38     39

       40     41     42     43     44     45     46     47     48     49

       50     51     52     53     54     55     56     57     58     59

       60     61     62     63     64     65     66     67     68     69

       70     71     72     73     74     75     76     77     78     79

       80     81     82     83     84     85     86     87     88     89

       90     91     92     93     94     95     96     97     98     99

     100   101   102   103   104   105   106   107   108   109

     110   111   112   113   114   115   116   117   118   119

     120   121   122   123   124   125   126   127   172   129

       26   146     30     38     32     33   198     48     96     57

       82   141   125   143   144     24     25     28     29     34

       19     20   220     34     97     58     83   157   126   120

     160   161   162   163   164   165   166   167   168   169

     170   171   172   173   174   175   176   177   178   179

     180   181   182   183   184   185   186   187   188   189

     190   191   192   193   194   195   196   197   198   199

     200   201   202   203   204   205   206   207   208   209

     210   211   212   213   214   215   216   217   218   219

     220   221   222   223   224   225   226   227   228   229

     230   231   232   233   234   235   236   237   238   239

     240   241   242   243   244   245   246   247   248   249

     250   251   252   253   254   255



Mon, 28 Mar 2005 13:56:23 GMT  
 eVB/CE3: Binary data received is not what is being sent

Quote:
> We're writing a program for a Windows CE 3.0 handheld device using
embedded
> VB. This program needs to connect to, and communicate with, a host
computer.
> The protocol requires single-byte binary communication (no Unicode).

[Snipped very long description]

I don't have any really good explanations, but I would like to know this:
1) Is the problem the same if you try to call WriteFile with the whole
buffer in one go instead of byte-by-byte?
2) What happens if you send a score of the offending bytes (like 5 times
repeated). Is the result on the PC side the same?
3) Have you tried sending from the PC and see what the result will be on the
PDA? If yes, is it the same characters that gets mangled?

And a single solution (in fact a work-around):
Do byte-stuffing on the data. Each time, you see a character above 127,
precede it with char 255 (which survives) and map the data to between 0 and
127 by subtracting 128 from it.
Remember to stuff the data after generating the CRC (so that that also gets
stuffed), and un-stuff the data on the PC side before checking the CRC.

I haven't played with the serial functions on the PDA yet, so I can't
comment on the real problem.

Keld Laursen



Mon, 28 Mar 2005 14:28:08 GMT  
 eVB/CE3: Binary data received is not what is being sent
Hi --

1) I don't think that's been tried. I'd have to check to see if the actual
program is capable of sending a whole buffer, or if the protocol requires
byte-by-byte sends. I'll play around with it later today and see what I get.

2) Haven't tried that. I'll get back to you.

3) We haven't tried running this test in reverse, because we aren't having
any problems receiving data from the host. Either we've been extraordinarily
lucky with the checksums we've received, or the problem doesn't manifest
itself in reverse. All the problems we've been having are with the host not
understanding what we're sending it. (We send it a mangled CRC; it
calculates its own CRC and comes up with a different value; it rejects our
data.)

As for the solution: We don't have any control over the host application.
This is a commercial application in use in supermarkets throughout the
state. Whatever we do to fix this can only be done on the eVB side.

I do know that we've been in contact with another company working on a
similar project for one of their clients. They're communicating with the
same host and software that we are, but they wrote their entire app in
eVC++. They have checked and do not have this problem. We had been told
earlier Wednesday that the problem was caused by a bug in the CE kernel, but
apparently it doesn't affect eVC++ programs.

Thanks,
CL


Quote:


> > We're writing a program for a Windows CE 3.0 handheld device using
> embedded
> > VB. This program needs to connect to, and communicate with, a host
> computer.
> > The protocol requires single-byte binary communication (no Unicode).
> [Snipped very long description]

> I don't have any really good explanations, but I would like to know this:
> 1) Is the problem the same if you try to call WriteFile with the whole
> buffer in one go instead of byte-by-byte?
> 2) What happens if you send a score of the offending bytes (like 5 times
> repeated). Is the result on the PC side the same?
> 3) Have you tried sending from the PC and see what the result will be on
the
> PDA? If yes, is it the same characters that gets mangled?

> And a single solution (in fact a work-around):
> Do byte-stuffing on the data. Each time, you see a character above 127,
> precede it with char 255 (which survives) and map the data to between 0
and
> 127 by subtracting 128 from it.
> Remember to stuff the data after generating the CRC (so that that also
gets
> stuffed), and un-stuff the data on the PC side before checking the CRC.

> I haven't played with the serial functions on the PDA yet, so I can't
> comment on the real problem.

> Keld Laursen



Mon, 28 Mar 2005 14:54:44 GMT  
 eVB/CE3: Binary data received is not what is being sent

Quote:

> >bArray(i) = Chr(i)

> Do you really need chr()?  That's what's probably doing you in.
> (i AND 255) may do it, if i alone won't.

Leading me to the one thing that I thought of, but didn't mention in my
post:

4) Have you tried to dump the buffer contents on the PDA and see if it is
OK?

Keld Laursen



Mon, 28 Mar 2005 16:04:39 GMT  
 eVB/CE3: Binary data received is not what is being sent
Have you hooked up a standard PC and watched what comes in ?

I have a hunch that the following might be your problem :-

Fron VB Help Files :-

<snip>
The InputMode property determines how data will be retrieved through
the Input property. The data will either be retrieved as string or as
binary data in a byte array.

Use comInputModeText for data that uses the ANSI character set. Use
comInputModeBinary for all other data such as data that has embedded
control characters, Nulls, etc.
</snip>

On Thu, 10 Oct 2002 01:56:23 -0400, "Charles Lavin"

Quote:

>Hi --

>We're writing a program for a Windows CE 3.0 handheld device using embedded
>VB. This program needs to connect to, and communicate with, a host computer.
>The protocol requires single-byte binary communication (no Unicode).

<snip>


Mon, 28 Mar 2005 16:13:37 GMT  
 eVB/CE3: Binary data received is not what is being sent
Hi Charles

Have you seen my message "Binary comms and chr(26)"? (10 Oct).
I think both of us are experiencing the same problem. What I have noticed is
that the position and the amount of these extra chars can vary with every
reception.

Please let me know if you find a solution

Many thanks

Mark.



Mon, 28 Mar 2005 19:46:35 GMT  
 eVB/CE3: Binary data received is not what is being sent
Your description said binary data, but you set the input to be text.  I
don't necessary think that is a problem, but it is inconsistant with your
requirements as stated.

Have you considered putting some error checking code to check the return
from WriteFile?  WriteFile returns a pass/fail boolian as well as the number
of characters written.  It may already be trying to tell you that there is a
problem, but you are not listeing!

I agree with Keld, you should try his tests.

--
--
Bruce Eitman
Senior Engineer
Accelent Systems Inc.
www.accelent.com


Quote:
> Hi --

> 1) I don't think that's been tried. I'd have to check to see if the actual
> program is capable of sending a whole buffer, or if the protocol requires
> byte-by-byte sends. I'll play around with it later today and see what I
get.

> 2) Haven't tried that. I'll get back to you.

> 3) We haven't tried running this test in reverse, because we aren't having
> any problems receiving data from the host. Either we've been
extraordinarily
> lucky with the checksums we've received, or the problem doesn't manifest
> itself in reverse. All the problems we've been having are with the host
not
> understanding what we're sending it. (We send it a mangled CRC; it
> calculates its own CRC and comes up with a different value; it rejects our
> data.)

> As for the solution: We don't have any control over the host application.
> This is a commercial application in use in supermarkets throughout the
> state. Whatever we do to fix this can only be done on the eVB side.

> I do know that we've been in contact with another company working on a
> similar project for one of their clients. They're communicating with the
> same host and software that we are, but they wrote their entire app in
> eVC++. They have checked and do not have this problem. We had been told
> earlier Wednesday that the problem was caused by a bug in the CE kernel,
but
> apparently it doesn't affect eVC++ programs.

> Thanks,
> CL





> > > We're writing a program for a Windows CE 3.0 handheld device using
> > embedded
> > > VB. This program needs to connect to, and communicate with, a host
> > computer.
> > > The protocol requires single-byte binary communication (no Unicode).
> > [Snipped very long description]

> > I don't have any really good explanations, but I would like to know
this:
> > 1) Is the problem the same if you try to call WriteFile with the whole
> > buffer in one go instead of byte-by-byte?
> > 2) What happens if you send a score of the offending bytes (like 5 times
> > repeated). Is the result on the PC side the same?
> > 3) Have you tried sending from the PC and see what the result will be on
> the
> > PDA? If yes, is it the same characters that gets mangled?

> > And a single solution (in fact a work-around):
> > Do byte-stuffing on the data. Each time, you see a character above 127,
> > precede it with char 255 (which survives) and map the data to between 0
> and
> > 127 by subtracting 128 from it.
> > Remember to stuff the data after generating the CRC (so that that also
> gets
> > stuffed), and un-stuff the data on the PC side before checking the CRC.

> > I haven't played with the serial functions on the PDA yet, so I can't
> > comment on the real problem.

> > Keld Laursen



Tue, 29 Mar 2005 00:19:00 GMT  
 eVB/CE3: Binary data received is not what is being sent
Hi --

I'll look for your post. But here's something I got from my post on the
DevBuzz forum:

"While it doesn't seem to be affecting you, the first problem I see is that
you're using Chr() which is a Unicode function - you should be using ChrB().
"

CL


Quote:
> Hi Charles

> Have you seen my message "Binary comms and chr(26)"? (10 Oct).
> I think both of us are experiencing the same problem. What I have noticed
is
> that the position and the amount of these extra chars can vary with every
> reception.

> Please let me know if you find a solution

> Many thanks

> Mark.



Tue, 29 Mar 2005 00:34:07 GMT  
 eVB/CE3: Binary data received is not what is being sent
Hi --

Yes, we've been running tests with a PC between the handheld and the host,
checking what comes and goes on the comm port.

Thanks to all for your suggestions. I've recently been brought in on this
project, and I'll check everything suggested here on the actual app code.

Thanks,
CL


Quote:
> Have you hooked up a standard PC and watched what comes in ?

> I have a hunch that the following might be your problem :-

> Fron VB Help Files :-

> <snip>
> The InputMode property determines how data will be retrieved through
> the Input property. The data will either be retrieved as string or as
> binary data in a byte array.

> Use comInputModeText for data that uses the ANSI character set. Use
> comInputModeBinary for all other data such as data that has embedded
> control characters, Nulls, etc.
> </snip>

> On Thu, 10 Oct 2002 01:56:23 -0400, "Charles Lavin"

> >Hi --

> >We're writing a program for a Windows CE 3.0 handheld device using
embedded
> >VB. This program needs to connect to, and communicate with, a host
computer.
> >The protocol requires single-byte binary communication (no Unicode).
> <snip>



Tue, 29 Mar 2005 00:32:42 GMT  
 eVB/CE3: Binary data received is not what is being sent

Quote:
> Hi --

> I'll look for your post. But here's something I got from my post on the
> DevBuzz forum:

> "While it doesn't seem to be affecting you, the first problem I see is
that
> you're using Chr() which is a Unicode function - you should be using
ChrB().
> "

Upon re-reading your original mail, I would also think that this could be
part of the problem.

That is the reason for your having this chr() in there at all? You shouldn't
need to cast these data at all.
(OK, I admit that you might have a reason for casting in the final app., but
not during test).

Keld Laursen



Tue, 29 Mar 2005 14:30:10 GMT  
 eVB/CE3: Binary data received is not what is being sent
Hi Charles

I've read your post and replies at devbuzz.
The problem has been solved in the test program because now you've altered
the transmission string by using chrB() instead of chr(). Will you be able
to do this in your app?
The problem I have is that I cannot change the transmission string, I have
to accept what is being sent.

Mark.


Quote:
> Hi --

> I'll look for your post. But here's something I got from my post on the
> DevBuzz forum:

> "While it doesn't seem to be affecting you, the first problem I see is
that
> you're using Chr() which is a Unicode function - you should be using
ChrB().
> "

> CL



> > Hi Charles

> > Have you seen my message "Binary comms and chr(26)"? (10 Oct).
> > I think both of us are experiencing the same problem. What I have
noticed
> is
> > that the position and the amount of these extra chars can vary with
every
> > reception.

> > Please let me know if you find a solution

> > Many thanks

> > Mark.



Tue, 29 Mar 2005 17:01:47 GMT  
 eVB/CE3: Binary data received is not what is being sent
On Fri, 11 Oct 2002 09:01:47 +0000 (UTC), "Mark Warren"

Quote:

>Hi Charles

>I've read your post and replies at devbuzz.
>The problem has been solved in the test program because now you've altered
>the transmission string by using chrB() instead of chr(). Will you be able
>to do this in your app?
>The problem I have is that I cannot change the transmission string, I have
>to accept what is being sent.

>Mark.

For i = 0 To 255
    bArray(i) = Chr(i)
Next i

ChrB( i )  ????

Surely   bArray(i) = i

Otherwise who knows what horrible conversions will take place



Tue, 29 Mar 2005 17:25:51 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. I am trying to update a record, i am not using data control

2. I am trying to update a record, i am not using data control

3. I am learning VB.NET and am wondering....

4. When is 5:00 AM not 5:00 AM? When it's 5:00 AM.

5. i am angry about evb

6. Hardwaretasten am IPAQ unter eVB

7. Binary files - what am I doing wrong?

8. email me ny vbs scripts i am making a huge prog with any features u send

9. email me ny vbs scripts i am making a huge prog with any features u send

10. i am getting error sending stdPic to out-of-Process Component

11. I AM AN END-USER, NOT A PROGRAMMER

12. shared variable not working what am I missing?

 

 
Powered by phpBB® Forum Software