UMA not totally working on the 8220
So, we know that UMA works fine on my 8320 Curve with a Linksys WRT54G with DD-WRT loaded. But with my wife's 8220 Flip, UMA cuts out, won't stay connected and just doesn't work well in general. I'm thinking that it is an OS issue, because the 8320 got better over time. But, in the mean time, I just put her back to having the WiFi off.
Anybody else having the same issues?
Welcome to the party, I have been having the same issues on my 8320 since the device launched. Its a known issue with TMO since the 8320 launched. I also get tons of dropped calls from UMA to EDGE.
But, the issue is with the wife's 8220. My 8320 works fine on the network under UMA. That is what makes me believe that it is the 8220 OS.
I have several types of tmo phones with wifi and had simular problems with all of them, My wife and I's BB 8120's seem to work the best, but here is something i did that might work for you.....
On your wireless router, try changing the default channel to 1 or 11, these channels have the least interferance, one other option is to give the phones a static address. this seemed to resolve inconsistency issues when you have multiple wireless deices present. let me know if that helps
I am already running the router on channel 10 because of what the neighbors are running. But, I tried a test on her phone yesterday. I set the phone to get a DHCP address from the router. Then, I called my phone (which is also running on UMA with DHCP) and connected them. Then I sat them down and left them connected while I timed how long they would stay connected. The 8220 would disconnect at around 3 minutes. Then, I set a static IP on the 8220 and did the same test again. It never disconnected in this configuration. So, I left the static IP on the phone and it seems to be working fine under UMA.
not too sure why DHCP is so inconsistant, maybe because of newer technology with these phones. Anyways, im glad that the static worked for you
I've got a TMo branded 8220. UMA works with .151 and .174 but it often drops calls when transitioning from UMA to EDGE. EDGE to UMA works perfectly 100% of the time. I have service inside my home and decent service outside (about 85db). Can't figure out why it won't transition. Tried a Dlink DIR-655 with no encryption, WPA and WPA2 (AES) same result with all. I also set the advanced routing settings the way RIM recommends in the support tech article. No difference.
I then tried a Linksys WRT54G. Same issue. All with latest firmware and have spent hours using different settings.
TMo's UMA support won't help further unless I try the TMo Linksys router. I guess I could spring for the $80 and get the new @home vertical router and give it a try but I'm fairly confident it won't give me any different results.
I'm wodnering if a future BB OS will improve the UMA to EDGE handoff or if TMo needs to do some work on their backend?
BTW, I have both Comcast and at&t DSL in my home. Tried the wifi router with both and got the exact same result.
Aside from the UMA to EDGE handoff, UMA works OK.
I'm surprised .174 didn't do it for you. It works great for me. Check to see the "allow inter-access point handover" is marked. Go to Connections>WiFi options>[name of connection]>menu>edit>[x]allow inter-access point handover
The most reliable UMA phone for me thus far has been the 8820 with the latest 4.5 OS as of the date of this post. It does everything as it should in regard to UMA to GSM transitions and back. It also lasts longer on battery than the Pearl 8120 and 8220.
My 8220 has done pretty well though. It is certainly not as bad as my 8320 was! I was so annoyed with the 8320 with UMA dropping calls and resetting that I got rid of it for an unlocked 8310 without Wifi.
I have 8220 running on Linksys WRT54G without any DD-WRT hacks loaded. In fact, it is pretty much default WRT54G configuration with password and MAC filtering enabled.
No problems whatsoever for UMA on 8220. Device run OS 188.8.131.52
|All times are GMT -5. The time now is 01:31 PM.|
Powered by vBulletin® Version 3.6.12
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.