Hi All,

I've developed an application that can send files to and from a mobile phone to an desktop.
2 applications one on the mobile the other on the desktop.

At first i thought the applications where running correctly.
I tested with small files, to speed up the development.
All worked great!

But when sending larger files, there seems to be a problem.
When sending images, the imagedata gets corrupted.
To make the situation even spookier, sending large files to the mobile workes fine.
Sending large files from the mobile device doesn't.
And both bluetooth communication handlers have the exact same code.

When comparing files using a hex comparer, it seems that occasionly extra bytes are added to the data.
Not perticullarly add the end but in between other data.

Does anybody have the same problem i have?
And what can i do about it ?

Any help would be greatly appriciated!!

 Thanks in advance!

 With kind regard,

Rob Smeets

Can you tell me about the two devices (mobile and desktop).  In particular are they running the MSFT and Widcomm or stack?  And which direction does the corruption occur?

Hi Allen,

Thanks for the reply.

The mobile is a HP IPAQ 914c and the desktop is a Dell Precision M6300 laptop.
And as far as i can tell both use the Microsoft stack.

The problem occurres when sending files from the mobile to the desktop.
I've included an image of the filecompare:

I hope this is enough information.

With kind regards,

Rob Smeets

Hi Rob

Can you show me the value of BluetoothRadio.PrimaryRadio.SoftwareManufacturer on each device.  Did you have to copy the 32feetWidcomm.dll to either end to get it to work?  iPAQs use Widcomm AFAIK.

Alan

Hi Allen,

Both statements return Microsoft.
And no 32feetWidcomm was needed...

With kind regards,

 Rob Smeets

We've had a report of extra two zero bytes being added under some circumstances, and that seems to match your case.  I am working with a user on debugging that case.  But that's with our Widcomm support.  With the MSFT stack our library doesn't touch the data at all, so the fault would have to be in the Microsoft code, either in .NET's NetworkStream or in the native sockets or bluetooth layers.  Hmm....

Hmmm... indeed...

Probably the first time i hoped I did something stupid .
So i could fix it.

Anything else, i could do? Is there a work around?
Strange thing is also it always happens at character 38522.

With kind regards,

 Rob Smeets

 Rob,   I also have noticed this issue.    I am currently taking data off a sensor and everything works fine, but after a while I notice the stream gets corrupt and I get data that is not expected and the error blows up the program.   I am using a dell axim v5.1 with windows moble 6.1.   I am very interested in the solutition to this.   Now that I know other people are having similar issues I will investigate more.

Thanks in Advance.

Greg

So chaps, I have three reporters of corruption.  One (Eric) reports it affects Widcomm, secondly Rob you report it affects MSFT and not Widcomm.  I'm surprised, as I thought nearly all iPAQs had Widcomm.  When does it occur for you Greg?  Does your Dell WM device use the Widcomm stack?

Eric and Rob report the addition of a pair of zero bytes added, same for you Greg.  For Eric "When it gets to about 65 bytes of data received from the device it starts to go bad"   For Rob "it always happens at character 38522."

Can I get access to your code then Rob as you have a reproducable case?

Allen,

Just to be safe. (don't know if the mail will work)  but i've send you an email.

 With kind regards,

 Rob Smeets

I am the one who had the problem with Widcomm.  I haven't had any problems with the Microsoft driver with large amounts of data.

I was able to work around this on the Widcomm side.  What I had to do was break up the data into smaller chuncks.  We own the BT device I am talking to so I don't know how well this will work for you, but I will give you what I did, and maybe it will help.

With our device I normally call it and say give me all your uncollected data (all data since last download).  That is 11 bytes per record.  With the Widcomm driver on Windows and Mobile devices I was getting corruption right around byte 65.  What I was able to do is tell our device that I only want 5 records at a time.  So when I call uncollected data at the most it sends me 5 records (55) bytes and to start the next 5 records I have to send another Write command.  This appears to reset something in the code and I can again recieve the next 55 bytes.  I keep doing this over and over until I have gotten all my data.

 With the Microsoft stack I never have to do this.

 I don't know if with your device you can state I only want to read 100 bytes in the read object and then do some generic write in betweeen each read.

I hope this helps.

Maybe you've already found the same Greg, but when we investigated the other two chap's problems we found that there was no problem in the library.  Both programs were assuming that Read always filled the buffer and thus were sometimes using garbage (zeros) from the unfilled part of the array.  I wish that Stream.Read enforced something like: [WarnUnusedResult("Stream.Read will return as soon _any_ number of bytes are available, use the result to check whether between 1 to count bytes were returned, or zero for end of stream.")]