Bounty for working MS Bluetooth stack on TP2

[PPCFreak]

Wirelessly posted (VZW TP2: XV6875 Opera/9.50 (Windows NT 5.1; U; en))

i for 1 would like PAN option. sucks that my old apache 6700 could do this but a new $350 tp2 doesnt work for this. carrying around the usb cord incase i need to tether sucks cause sire enough when ineed to tether it wil prob b when i dont have the usb cord with me.
Count on $20 from me.

[mikee4fun]

Originally Posted by helix139

Headsets aren't hanging up, Voice command is having all kinds of problems, redialing isn't working, etc. There are numerous threads on this and if the Widcomm stack works fine for you, then great, but there are a great many of us who are VERY dissatisfied with it.

If Widcomm works for you, then fine. No need for you to post in this thread. Not to be a jerk, but this thread is for contributions to the bounty for those who want the option of using the MS stack only.

I thought I would chime in and at least help on the widcomm end call issue. I found a real working solution for headsets not hanging up. You have to disable internet being always on. You can use hd or diamond tweak to do this. I would not use advanced config as it causes a lag in answering the phone. I have cooked quite a few roms and can confirm this does work. I stumbled across this fix when I went to hang up the phone, quite a few times I would get a could not connect #777. So if you set your connection to disconnect after 10 minutes and then soft reset the phone. You will no longer have end call lag.

Another post by apristel's Avatar
apristel http://forum.ppcgeeks.com/showpost.p...73&postcount=1 is to go into this registry key and change it. I have had it at 0 and at 1000 and see no difference. But I thought I would add this to my post.

Registry Edit:

[HKEY_LOCAL_MACHINE\Software\HTC\PHONE\PhoneExtendS etting]
"EndCallTime"=dword:1000

1000 = 1 second

If this helps your end call lag, which it will, please give me a thanks.

Cheers,

Mikee

[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 mikee4fun

I thought I would chime in and at least help on the widcomm end call issue. I found a real working solution for headsets not hanging up. You have to disable internet being always on. You can use hd or diamond tweak to do this. I would not use advanced config as it causes a lag in answering the phone. I have cooked quite a few roms and can confirm this does work. I stumbled across this fix when I went to hang up the phone, quite a few times I would get a could not connect #777. So if you set your connection to disconnect after 10 minutes and then soft reset the phone. You will no longer have end call lag.

Another post by apristel's Avatar
apristel http://forum.ppcgeeks.com/showpost.p...73&postcount=1 is to go into this registry key and change it. I have had it at 0 and at 1000 and see no difference. But I thought I would add this to my post.

Registry Edit:

[HKEY_LOCAL_MACHINE\Software\HTC\PHONE\PhoneExtendS etting]
"EndCallTime"=dword:1000

1000 = 1 second

If this helps your end call lag, which it will, please give me a thanks.

Cheers,

Mikee

The problem with the data issue is if you use push email it is not workable. This stack is just plain bad.

[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.

[Boo Boo]

wonder if htc will fix it and collect the pot.

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

[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