Issue with null character inserted into data stream when using SPP

[MattWhitfield]

Hello again

O/S WinXP SP3 - WIDCOMM stack v5.5.0.3200 - WCL 6.7.4

More issues - I have connected to the device I am using (custom device implementing standard SPP), and I am asking the device to send me data on a regular basis. At some times, without a pattern that I can see, the data that is returned via the OnData event has one of the valid characters replaced by a NULL (\0) character. I log out the data from the event as soon as it is received by the application.

I have tested exactly the same scenario, but using the WIDCOMM software to make the connection to the SPP, and the corruption does not happen. Therefore I can be reasonably certain that this is a problem in the WCL library.

There is a background process running discovery all the time, but I simulated this using the WIDCOMM software by constantly refreshing the device list. Still, WIDCOMM = no corruption, WCL = corruption.

I cannot provide you with any replication steps, seeing as this happens randomly, and I cannot see any pattern to it.

Thanks

Matt

[Mike Petrichenko]

Hi,

Please, refer to this topic: http://forum.btframework.com/index.php/topic,337.0.html

Information, you provided, is not enough to fix the issue.

[MattWhitfield]

1. Describe your problem in details.
I have given you as much detail as I can.

2. Which bluetooth drivers you are using and version of the drivers.
I have specified this.

3. Wihch Bluetooth Framework version you are using.
I have specified this.

4. Which programming language you are using and its version.
C#, 3.5. Not that it matters, it's a .NET library.

5. What your are doing (and what i must to do) to reproduce the error/problem.
I have specified what I am doing, and also told you that it's not reliably reproducible because the error is random.

6. For GSMModem the log file from PortMon (http://www.sysinternals.com) will really appricated.
This does not apply.

7. For your own services then GUIDs of the service.
This does not apply.

8. If you are using own application on mobile device for communicate with PC - the application or the demo wich works like your application will be very good help for me to find the problem.
This does not apply.

9. The code part where problem accours or the description of what you do.
I have specified this.

10. Do not post multiple posts for the same problem.
I have not.

11. If you need provide code part of the BTF use private forum section (the registered users forum section). If you have started topi in public section but need provide the code from BTF please let me know - I'll move the topic into private section.
This does not apply.

12. Do not use PM for error/bug reporting.
I have not.

13. If you send request by e-mail do not post it here.
I have not.

14. If you have made changes in BTF code (I hope you have read the license agreement before doing this) let me knw what and where you have changed.
I have not.

[Mike Petrichenko]

Hi,

I have just tested it on my phones: SE K750i and Nokia N95 with Dialup Networking service (as it uses SPP profile) and with OBEX services (as they use SPP profile too) - all works without any issues and data was not corrupted when I executing AT commands or when I uploading or downloading files. So it looks like issue on your side or with your custom device.

[MattWhitfield]

If the problem occurred using the standard WIDCOMM stack software, then I would agree. But, to state again:

1) This does not happen using the standard WIDCOMM stack software. This means that it cannot be an issue with the custom device, as that has not changed.
2) I log the data that comes in to me directly from the OnData event. I write the content of e.Data directly out to a log file. This means that it cannot be an issue with my software, as I am writing what I receive from the OnData event directly out, I do not do anything with it.

Perhaps the OBEX layer has some sort of checksum / retry that is masking the issue when you try it with OBEX?

[Mike Petrichenko]

I am really sorry but our telepator has been damaged few days ago and we can not "see" what your application do and what your device send. As described in the topic I posted a little bit erly - provide us with application/code which can reproduce the problem on our side and we will be more than happy to fix the issue as it is more our interest than your I think. But with information you provided we can not reproduce the problem. As soon as we can not reproduce it - we can not fix it.

1. That means absolutly nothig as I do not know how your code works and how you reproduced it with using widcomm software and with using WCL.
2. This does not give us any idea how we can reproduce it.

OBEX does not have any check summ and uses the same OnData event (internaly in wclOPPClient and in wclFTPClient) and the same receivin g and writing mechanism. wclClient is base class for all OBEX based components.

[MattWhitfield]

What more information do you expect me to be able to provide you with? If you want to ask a specific question then I am more than happy to give you the answer, but making a jibe about your 'telepator' is hardly going to enable me to provide you with more information is it?

And yes, it is in your interest to fix the problem.

1. If I am logging the data as soon as I get it from OnData, then how on earth does what my application does with the data thereafter have any influence whatsoever? If you can see any problem with this code, or can suggest a way that I can somehow subvert what this event provides me with through telepathy, then do let me know:

Code: [Select]

        private void client_OnData(object sender, wcl.wclDataEventArgs e)
        {
            using (TextWriter tw = new StreamWriter("C:\\data.log", true))
            {
                tw.WriteLine(DateTime.UtcNow.ToString("yyyy/MM/dd HH:mm:ss"));
                foreach (byte b in e.Data)
                {
                    tw.Write(b.ToString("X") + " ");
                }
                tw.WriteLine();
            }
        }

2. Nope, for the third time - this is a problem that I cannot see a pattern to.

[MattWhitfield]

Here is some extra information, although probably still not enough...

It does seem to be related to discovery. If i turn the background discovery process off, then the corruption does not happen. I can then cause the corruption reasonably reliably by using the WIDCOMM software to do discovery while the application constantly requests data. This will usually happen after 1-3 times of running discovery using the WIDCOMM stack.

Does that help fix your telepator? 

[MattWhitfield]

Ok, sorry - but I have managed to reproduce this using the standard WIDCOMM stack too! AAAARRRGGHHHH!!! Not a good day!

When using the WIDCOMM stack software it takes a much higher number of discovery repeats to cause the corruption, but it happens in exactly the same way - null byte in the data stream. So I'm now reasonably convinced it's not WCL.

Feel free to delete this thread / cast voodoo spells on me! 

[MattWhitfield]

P.S. Can you recommend any way that I can debug down into the stack level, or somehow get some protocol analysis data to try and track this down further?

Thanks

[Mike Petrichenko]

May be USB Sniffer? I can help to decode/parse USB data stream onto bluetooth data packets

[MattWhitfield]

That's a really good idea - thanks! I think I will be OK with decoding, I will just look for a particular corrupted sequence of bytes in the payload.

Thanks again and sorry for getting my wires crossed!

[Mike Petrichenko]

You are very welcome!