Bounty for working MS Bluetooth stack on TP2

[grv]

$30 from me!

[pesok]

All bt headsets are gay, everytime i see a person that talks on one while looking straight at me makes me very violent, but i do agree its very usefull in the car or when you need both hands for washing your dog, just please dont wear it while walking down the street. I have a premier business paypal account with excellent feedback of about 8 years, if i can help(i dont have the problem with bt set though) let me know

[dishe]

Mike- interesting find... so basically, the delay has something to do with the data connection? Your solution may not be acceptable for those of us who rely on the data always being on for things like push mail, etc.

I don't have a TP2 myself (yet) so I can't test anything, but it sounds to me like the stack is simply telling the radio to terminate a session, assuming that session "x" is a voice call. Does the GSM version of the Rhodium have this problem as well?

Maybe someone with some radio protocol knowledge and a CDMA TP2 can look into this, but this is what I imagine is happening:
If you initiate a connection (be it voice 1x or data EVDO), it may dynamically name the session (lets call it session X). If a data call was initiated first, and then put on hold for another session (a voice call), perhaps it is given another name to reference the connection (lets call it Y). So, when the Widcomm stack sends the terminate connection command, it *may* be trying to end session "X", and not getting any response since the call is on hold.
If no data call was initiated first, and the voice call ends up being "X", than it works fine.

This would also explain why a GSM version possibly does not have this problem (again, I don't know, I'm just assuming since I haven't heard of this problem before now)- the GSM radio does not put calls on "hold", since voice & data can be operated simultaneously.

By the way, most people consider the Widcomm stack to be far superior than the MS one in many ways (I was following and even contributed to some of the initial efforts to port it to HTC devices in the days of the Wizard and Tornado because of MS stack quality issues). As far as I know, this marks the first CDMA device to use the stack, and therefore it is very possible that they were unaware of this potential problem. If this is really the only problem you are having, I think you'd all be better off fixing it than ditching the entire stack for the MS one. The Widcomm stack is more efficient on CPU time as well as battery (look at the side by side tests done at pocketpcmag), not to mention dramatic sound quality improvement with things like A2DP stereo.

Hope this helps...

[helix139]

Originally Posted by dishe

Mike- interesting find... so basically, the delay has something to do with the data connection? Your solution may not be acceptable for those of us who rely on the data always being on for things like push mail, etc.

I don't have a TP2 myself (yet) so I can't test anything, but it sounds to me like the stack is simply telling the radio to terminate a session, assuming that session "x" is a voice call. Does the GSM version of the Rhodium have this problem as well?

Maybe someone with some radio protocol knowledge and a CDMA TP2 can look into this, but this is what I imagine is happening:
If you initiate a connection (be it voice 1x or data EVDO), it may dynamically name the session (lets call it session X). If a data call was initiated first, and then put on hold for another session (a voice call), perhaps it is given another name to reference the connection (lets call it Y). So, when the Widcomm stack sends the terminate connection command, it *may* be trying to end session "X", and not getting any response since the call is on hold.
If no data call was initiated first, and the voice call ends up being "X", than it works fine.

This would also explain why a GSM version possibly does not have this problem (again, I don't know, I'm just assuming since I haven't heard of this problem before now)- the GSM radio does not put calls on "hold", since voice & data can be operated simultaneously.

By the way, most people consider the Widcomm stack to be far superior than the MS one in many ways (I was following and even contributed to some of the initial efforts to port it to HTC devices in the days of the Wizard and Tornado because of MS stack quality issues). As far as I know, this marks the first CDMA device to use the stack, and therefore it is very possible that they were unaware of this potential problem. If this is really the only problem you are having, I think you'd all be better off fixing it than ditching the entire stack for the MS one. The Widcomm stack is more efficient on CPU time as well as battery (look at the side by side tests done at pocketpcmag), not to mention dramatic sound quality improvement with things like A2DP stereo.

Hope this helps...

According to posters on XDA-Devs the problem is there for GSM versions also. This is also not the first CDMA device to use a Widcomm stack either as the XV6600/PPC6600 used one also. I remember at the time there were numerous complaints about how spotty bluetooth was and numerous different builds of the stacks floating around but nobody ever really got them working as intended.

Whatever the case, I'd at least like the option to use the MS stack and see for myself if the tradeoffs are worth it to me.

Agreed having the choice is always prefer...

[dishe]

Choices are great, but I think Widcomm was chosen because of the new chipset. I'm not sure drivers exist for this chipset and MS Stack.

[brent372]

Can we please get this thread back on the track that the OP started.
This is not a BT stack discussion.
This is a bounty.
I am in for $50 as well.

[helix139]

Originally Posted by brent372

Can we please get this thread back on the track that the OP started.
This is not a BT stack discussion.
This is a bounty.
I am in for $50 as well.

PM me please and I'll add you to the list

[Boo Boo]

wonder if htc will fix it and collect the pot.

or use it to pay for the class action on defective units

[dishe]

Hold on- before we go all gaga about this... are there any other problems you guys are having with the stack? Or is it just the hangup problem?

If HTC releases an update that fixes this one issue (which is entirely likely since it sounds like a simple bug), are you guys OK with the stack otherwise?

As someone who helped identify and fix a BT error on the Titan, I can tell you its more likely easier to fix the problem than port the entire stack...

EDIT: As for the PAN issue, there are workarounds to connect over BT I believe. Its funny, because originally when PAN came out, folks who were used to Dial Up Networking profile hated it because it was different. Now if we lose that, people are angry again. Funny, is all.