Stockholm - Sunday October 1st, 2006.
I posted this question in an SPV-developer forum and "only" received this answer thus far:
For the transport delays, perhaps you should check the COMMTIMEOUTS values (by using GetCommTimeouts) on the COM port you opened to get the BT data. If your ReadFile is trying to get more characters than have been sent from the BT HCI layer to the virtual COM port, then the value of ReadTotalTimeoutConstant comes into play, and this is typically set by default to 1 second.
Could anyone with longer experience from Win Smartphone 2003 SE and MS bluetooth stacks perhaps fill us out on the:
(Mauricio Freitas has been counselling on bluetooth since 2003 -- any Microsoft BT specialists?)
(A) possible inter-dependencies between the different SW components/layers;
(B) the idea discussed in the old article/forum post I found re. the 1003 ms timeout;
(C) reasons for slow initial bonding, slow re-pairing and protracted data flow delays;
== == ==
Compared to the quick (1-2 sec) bluetooth connection e.g. between an earpiece and a Sony-Ericcson,
when connecting either a bluetooth scanner or a bluetooth printer to either a Qtek8080 (=SPV E200)
or an i-mate SP3 (=SPV C500), the former using Win Smartphone 2003 and the latter Win SP 2003 SE
we experience long delays, whatever procedure stage we're at - initial bonding can fail or take 40 sec
and re-pairing 20-30 seconds.
Our suppliers of the hardware blame the poor performance on the "bad MS bluetooth stack", and that
there is nothing to do. While we're not interested in upgrading to WM5.0, one engineer actually said:
"This problem is Microsoft-stack-related, it has even gotten worse on Windows Mobile 5
(they have added one more window to close!).
I don't know any solution for this, unfortunately and I doubt there's one at all..."
I don't quite follow him fully, perhaps anyone also could comment on this?
Obviously - the important question remains;
(1) Is all this related to a poor MS bluetooth stack?
(2) Is there nothing to do about it? MS stack upgrades; separate from ROM/firmware patches etc.?
(3) What may cause an initial bond to work fine Day1 and not even find the same HW Day2?
(4) Is the above suggestion to modify COMMTIMEOUT settings worthwhile / part of the problem?
(5) If so, how would you go about committing setting changes on a fleet of Smartphones?
(6) Is there any 3rd party bluetooth SW for surveillance, and ibid, re. COM-port allocation?
A Smartphone freshly flashed always shows up with "Incoming Port: COM6", almost by default,
and as e.g. bluetooth printers also default to COM6, we must manually change the latter to COM7
to run the printing applications.
The Incoming Port is used for the "Discoverable" mode, and as we do our connections from the
Smartphones to the peripherals, we tried to see what happens if we delete the Incoming Port
and let the initial bond for a printer remain at its default COM6.
Result - printing via COM6 has some intermittent hick-ups, every 6-7 print is lost inexplicably!!
(whereas printing is 100% over COM7 manually selected and with Incoming Port on COM6)
(7) What process is it that creates this "Incoming Port", and why does it default to COM6?
(8) Similarly, why would also a bluetooth printer want to default to COM6?
(9) If the Incoming Port is deleted, is there a "risk" of later problems/conflicts on COM6
-- e.g. would the BT stack try to recreate the Incoming Port at some stage (Discoverable-mode)
(10) What might explain the occasionally lost prints over COM6 (without Incoming Port) vs. COM7 ?
(11) Any other suggestiong to attain a stable, speedy bluetooth solution for our app's?
Yes, and why do we bother -- the end-user should not have to do any manual setting changes,
he/she should experience quick BT partnership connexions and be able to trust that the HW
and SW bluetooth-based applications perform exactly the same each workday.
Anything less, and one can kiss user-friendly and quality mobile work applications goodbye,,,
(of course - at this time we make do with a lot of error-handling instead)
Hope someone can enlighten us about all this!
(and perhaps suggest detailed troubleshooting reading)
In searching for an answer why the transfer of data over a SPP bluetooth link from a scanner to a Smartphone (OS=MS Smartphone 2003) I came across the below forum entry, which I would like to ask you to comment on.
We have a C++ application running on the Qtek's developed in Visual Studio, using the scanner manufacturer's driver libraries, and many times we experience a difficulty already in the pairing of the two devices.
Secondly, the data transfer (a barcode of a few bytes) between these two devices seems to persistently take seconds, whereas the upload and subsequent ascii-code reply over GPRS from the server to display the validated data is much quicker once that data channel is up.
Where do we start the troubleshooting, and what can you perhaps say re. the BT stack problem here below? Probably the "timeout" it speaks of should really be referred to by some other term, no?
Looking forward to your analysis, AND please alert me by email of any blog/forum response!
"I was not sure if the slowing part was the phone or the "Bluetooth to RS232" dongle.
So I wrote a test application that sends a char over ther serial port and measure the time it takes to get a echo response.
When I use a serial cable between PC and my Qtek 8080 (HTC) I got 10 ms in response time. Thats OK.
So changed to bluetooth connection.
The response time was now 1002 ms!!
I removed the "Bluetooth to RS232" dongle and connected a TECOM "Bluetooth to USB" dongle at the PC side. The TECOM use WIDCOMM 1.4210 bluetooth stack.
The responce this time was 1003 ms.
The Qtek 8080 (HTC Voyager) has microsoft bluetooth stack inside.
A conclusion of this is that the microsoft bluetooth stack has some kind of timeout that is set to 1000 ms.
It takes some time to pack/unpack data on the bluetooth link, but it should not take 1000 ms to do this.
Wonder if there is some way to change this timeout?? [?]
URL of this text = http://franson.com/forum/post.asp?me... 63&FORUM_ID=3