I can’t prove this yet for sure but here is what I think about freezing (have the phone since April).

At first whenever 7135 froze I would simply soft reset as soon as it froze (no response to any input).

Then I installed a neat free app called Crash which automatically restarts the phone on a crash – expecting it to do so every time the unit froze. I noticed that 7135 would not auto reset even though it looked as if it did crash – no messages but also no response. So I would do a manual soft reset.

Then I noticed that this would only happen with the phone side turned on in a marginal signal area.

Then I noticed that these were not real crashes or freezes but rather momentary freezes – meaning if I waited a bit, 7135 would start responding again – the key was waiting without piling up input. I believe that it happens when the phone is in a marginal digital service area and dynamically switches back and forth between the digital and the analog signal.

Other observations that lead me to believe that this is the case:
- Bebopper skips ONLY when the phone is switching between digital and analog signals (my home!)
- Graffiti response hesitates ONLY when the phone is switching between digital and analog signals (my home!)

I continue monitoring this and it looks like none of the freezes that I experienced were actual crashes but rather the phone being busy looking for a signal that somehow takes over the CPU so that the PALM side is momentarily not being serviced. This perhaps may be aggravated by pushing too many keys while the unit is not responding.

Can anybody else confirm the same thing? Does this make sense?

If true then perhaps many reported crashes are not so – one just needs to wait a bit until the unit comes back because the culprit seems to be the signal strength. If so, perhaps what is needed is a simple message displayed saying “Busy looking for a signal – please wait until the massage goes away on its own” or something like this - making it clear to the user as to what is happening. Anybody wants to give it a try and create an app like this?

Afraid you may be right. Like your solution, if it is true.

Yet, telling the user to adapt their behavior, is not the answer people want to hear; it is the worse problem. Note: many heavy users have adapted their use and significantly brought down their number of resets.

If pulling the antenna out or pushing it in, affected the time in this situation; then it might indicate you are on to something.

wrapping ones head in alluminum foil and performing a slow 360 deg. piroette may increase your reception as well...
Seriously, yes I have noticed that. what firmware are you on? I wonder if that makes a difference as well.
On a similar note I wonder how many people that say they are getting lousy battery life are aware of their location within their carrier's coverage area. When I'm at the fringes of my coverage or in predominaltly analog are my battery life really drops.
mg

MGuzzy,

Yes, analog is a killer on the 7135 battery. Same was true with my old 6035.

I have the latest software: MZ 1.0.44 and SZ 1.0.29 - upgrade was done at a local VZ store in Nashua, NH, without any problems.

What seems to make a difference is the location in the home and the time of day. It is much better at night. During the day I often can not catch either signal no matter what I do. I live on the border of a digital coverage.

Your point on adapting is well taken. That is why I wish there was a more in-your-face indicator that the phone side is competing for CPU with the Palm side.

pzc, apparently you are in an ideal area to pick up on this problem.

Yes, not knowing how long to wait between user requests is one of the most frustrating problems of any computer; or for that matter any action humans initiate, a random delay is the most frustrating. (Random behavior is also the most additive.)

An indicator that a machine is busy and one should wait on farther input is natural. In interactive computers, a flood of requests will get you an indicator returned called 'denial of service'. (Are there times when a machine does not want to have an indicator? Yes, for example, with a mouse trap the human wants to be able to see that it is set, but you want the mouse instead to be attracted to the device.)

In computer interaction with a cellular network, the edge environment is probably the most studied. What I'm saying is that the situation you describe is well known and documented with Kyocera, and a rational decision was made to not throw up that screen indicator showing that the phone is busy. Didn't expect it to be a deliberate decision to not give that indicator, did you? Doesn't mean that it should not be reconsidered, and the firmware altered --- thanks to you that may happen. I say this because I think you are right, and more may very well be adversely affected than predicted.

Why would they knowingly not program a screen indicator that the phone is busy and wait on farther requests? Because the situation occurs much more often than what you may have considered. I think you will agree that priority of processsor time should go to maintaining a phone connection. Suppose you were moving at automobile speeds, encountering handoffs to different cells, and passing a myriad amount of signal obstructions; then you could imagine low signal strength occurs faster than even the low signal indicator could display. Thus, a screen showing the phone is dominating processor time and wait on farther request, would likely be very annoying and would add a request burden on the processor.

There is a middle ground and ways to program an indicator to occur for only when a set time frame of this situation is exceeded. I think Kyocera and Verison should both be evaluating the new information gained from mass deployment for these kinds of design improvements.

Also, I like your idea of asking developers to look into what they can offer. A solution designed only for people who spend a lot of time in weak signal areas may be a better option.

LonghairSteve,

Very interesting. Thanks for the comments. It could be informative to establish if those who seem to see crashes tend to be in a weak signal area whereas those that don’t tend to be in a strong signal area. From the other posts it looks like there are indeed both types of users (that is many crashes vs. few crashes on the 7135).

There are many ways of letting the user know that something is going on like flashing icons or LED lights. The issue is how to keep the user informed that something valid is going on so that one does not start stressing the unit even more with repetitive use of stylus and buttons – or even resort to unnecessary manual soft resets. The dynamics of interdependency between phone and Palm is something new and unexpected. Given your comments, it is possible that many frustrations reported on this forum are in fact related to this specific interdependency and that at least part of the user frustration is directed at the wrong target (broken phone, faulty software, etc) – but how would we know if the unit does not tell us?

Yep, exactly, that is why I used the phrase 'Afraid you might be right'.

Thanks for bringing up this issue. Personally, thank you very much for being considerate of my comments. It is such a pleasure to successfully communicate a line of thought on the Internet, whether the subject matter is important or correct - who cares - geekdom toys brings the world together.

Maybe something good will come out of these notes