I'm going to apologize ahead of time for calling BS on what you are saying. Every person that has reported this issue gets the same answer there's a problem with the towers in your area. So I cannot believe that every person with an issue similar to the one I have with a Nexus 5 mind you that the towers happen to be down or with problems in that area. I also said that the problem that I am having at my house is the same issue that I had in a completely different city far away from my house, you are going to tell me that they're tower in that city also has issues? That doesn't make any sense, not only that, but I have family members that live in my house, 3 more people that live in my house what they use sprint, one of them has a 4G LTE HTC, the other one has an lg optimus and one an iPhone. None of them are having any issues with their phones, so how can you tell me that the towers are down or having issues and I'm the only one being affected. Again you giving us an answer just to give us an answer doesn't do anything else than frustrate us. Stop testing us like if we are idiots because we aren't.
This is the first time I've set the time manually and left it that way for an extended amount of time. The result is that when I go into an area with bad timing from the network, the time notifications on my texts and messages are now an hour off. So, if I receive a text right now, it says that it arrived an hour ago. Unless immediately checking messages as they arrive, I can't tell which have good time stamps. It throws off real life communications like "I'm at this place. Cone meet me."
Is it possible that the phone displays the correct time because it's set manually, but the messages from the network are stamped an hour behind? That would make sense because the towers were telling my phone it was an hour behind when I used network timing.
Further updates with setting the time manually while in an area where the towers are an hour behind: While the clock display on my phone is still accurate, there are more timing issues that just time stamps on text messages and alerts.
The entire Google calendar is shifted by an hour. So, an appointment that I set with a good time actually adjusts to be an hour behind when I am near a bad tower and have to manualy set the time in my phone. So, the manual time setting actually hurts the operation of the phone. This is no longer an inconvenience about receiving text messages. This is now affecting the ability to make and keep appointments.
I tried it out based on advice from this forum, but this has turned out to not be an acceptable solution.
I'm sorry I'm not sure if you are able to read the previous messages on this thread abs other parts of the forum. But if you notice there is a lot of peruke having this issue including me. As I write this I'm in CA currently my phone displays 11:08pm real time is 12:08am. I've had the same issues with my appointments, I almost missed a couple of work related appointments because I'd the time. At the time the time zone changes by itself to pacific standard time metlakatla. I've again we need this resolved, there are people living in my house with different brand phones in sprint who are not having this issues. So could you please give us an answer?
Both phones on my account have experienced this. 29485 at Wescott Blvd and Oak Forest Blvd, and 29406 at Aviation Ave and Core Rd, and at 95 GA Hwy 247 South in 31088. This spans across one city and extends into the middle of another state.
hey, i made a thread over at xda on the nexus 5 e.csfb issue, that helped me -
from within that, i delved into the inner working of sprint half baked network vision set-up nationwide,
what i found, is that the LTE part is actually an overlay on the cdma / evdo network (with sprint), so in essence, it's two separate networks the triband phones with single radio paths have to inter-roam between (or hand-off) to & from from data to voice services, & why they can't do them both at the same time.. when we at times saw *roaming* with full LTE service in incoming calls, it wasn't a flux, the nexus 5 was ACTUALLY inter-roaming within the network, from the LTE channel to the 1xrtt channel to serve the call..
somewhere in between, the phone app would get hung up in the processing because there was a fault on the network side -
i suspect when the google dialer froze on incoming calls, it came from the worse case scenario here ( it didn't happen all the tyme, but sporatically) -
"Call setup reliability
Another key issue for the voice call user experience is call
setup reliability—the ability to successfully establish an
incoming or outgoing call on the first attempt, or within
a time frame that doesn’t indicate call setup failure. The
target is to at least match legacy performance, which is
in the 98% range.
With CSFB switching between LTE and 3G networks, there
are two primary challenges to call setup success: changes
in IRAT conditions between measurement and acquisition
(for handover-based CSFB), and mismatches between
LTE and 3G geographic signal coverage areas that require
Changing IRAT conditions for handover-based CSFB
With handover-based CSFB, IRAT measurements can
change between the time the measurement is taken using
LTE and the time 3G voice network acquisition is attempted.
In that time, the cell identified and prepared for handover
may become unavailable, resulting in connection failure,
as visualized in Figure 10.
In handover-based CSFB, the measurement is performed
before—on average of 0.3 seconds before, as shown in
Figures 7 and 8 above—the IRAT transition. If the IRAT
conditions change negatively, there is a higher probability
of handover failure, especially in high mobility situations.
Historical experience has already shown somewhat
higher failure rates with inter-frequency handover or
IRAT handover (e.g. 3G to 2G), suggesting that delays
between IRAT measurement and network acquisition
can increase setup failures.
In contrast, redirection-based CSFB can be expected to
deliver higher call setup reliability than handover-based
CSFB, simply because redirection-based CSFB takes the
IRAT measurement immediately before attempting access
on the identified cell. Since the Release 9 SI Tunneling
and Release 8 Skip SIBs redirection-based CSFB methods
have only slightly higher call setup times, their higher call
setup reliability has guided the general industry trend to
rely on redirection-based CSFB approaches.
The reliability of redirection-based CSFB call setup has
been tested using device traces in field testing on live 3G
networks, and no call setup failures were observed out
of more than 160 calls, covering both good and bad RF
conditions for redirection-based CSFB to UMTS. These
results point to call setup reliability on par with legacy call
setup reliability. Similar traces collected on the network
side showed redirection-based CSFB reliability in the 99%
range, on par with UMTS legacy performance. Test data
for handover-based CSFB reliability has not yet become
available, due to its limited use to date.
the dialer app froze on totally different parts of town in my home in the suburbs, & inner city at work, i know not the particulars of the kind of sprint sites i was connected to ( was hoping to get that help from s4gur), allowing automatic in system select migitated the dialer freeze on incoming calls, to nil.."
that's where ehrpd comes to play, to *BRIDGE* lte & cdma / 1xrtt for seemless hand-offs, **lte doesn't have the capabilities for circiut switching within it's framework, cdma does, but, lte needs a flattened IP (internet protocol) bridge to evdo data, which then splits to 1xrtt for voice, for seemless transparent work..
on the time thingy, cdma should provide automatic network time sync from the cell sites to your phone, since those very towers are gps sync'd.. obviously when parked in LTE, that link somehow, was broken..