Information about the Pilot pen positioning bug

It's fixed!

apparently, not completely fixed for all machines... see 31 Jan 98's entry...

Return to my home page

My initial message

I posted this message on several Pilot-related maillists:

I've discovered a problem in my new Pilot - I don't know if it's a
problem with *all* new Pilots or just a problem with mine.

I first noticed it playing Jeff Jetton's new game - every now and then
it would turn a card over when I didn't tell it to. (as if I'd
tapped in a different spot)

I thought it was a bug in Jeff's code (shoulda known better) but I've
now duplicated it in DinkyPad too.

So now I need your help (if you've got the new machine - it only
shows up on that one)

The problem manifests itself as an incorrectly positioned tap. If I
tap "hard" (normal pressure) it doesn't happen. The only times I've
seen it area a *light* tap (or slight swipe).

Here's how to test it:

Bring up DinkyPad, and select a new drawing.
Set it for 'pen' and '4' line width.
repeatedly tap *lightly* in the upper-right corner - anywhere in the
upper-right 1-inch area. I don't even tap hard enough (most of the
time) to make a dot _there_.

Three times now, I've either had a long *line* appear - with one end
*way* off from where I'm tapping, or a dot in an entirely different
area of the screen.
Didn't take long - maybe a minute or so of tapping.

Could anyone with a new Pilot and DinkyPad please try this and email
me with results? (and/or post 'em here)

If it's just this machine (as I hope) I'll get it swapped for a
working one.
If it's a problem with all new Pilots we've got a serious problem.
(imagine tapping somewhere in some app but getting a mis-positioned
tap on the "delete" key...)

Thanks for any assistance!

A Rapid response from US Robotics Developer Support

An hour after I emailed them, I received a quick response from Developer Support at US Robotics:
(this is the fastest I've ever gotten a DevSupp response! Good for you USR!)
Note that this was at 1:30am PST.

I have tried this on my Professional and was not able to reproduce your result.
I am trying to borrow a Personal from someone to further test this. In any
case, thanks for pointing it out - it's been forwarded on to a few bugbusters
around here for further research.

Confirmations - others can duplicate the problem

Since then I've received the following snippets of email:

One person wrote:
Yeah, I got the same result doing that. Sometimes it would just draw a dot in the lower left hand corner and sometimes it would draw a line connecting the point where I was tapping with the lower left hand corner.

Another wrote:
YIKES!!!!!! You're right. I duplicated the effect using Scribble
instead of Dinkypad. Before Alan's message, I had noticed a random and
hard-to-repeat phenomemnon that must be related, namely, that the cursor
would sporadically jump fields while I was entering data into the
Telephone Book. The scariest thing is, when I tested the effect using
Scribble, on one occasion instead of a misplaced dot or line, I
generated a soft resent.

USR is going to have to address this @#$@#% pronto.

And another wrote:
You can add me to your list of those who can duplicate the tap position
problems with the new Personal. Was able to duplicate it in
Dinky...though it took a considerable amount of tapping before I found
THE most sensitive area.

And another - this one mentions a problem with USR applications:
By the way, I just read another message from someone saying they'd
seen similarly strange behaviour in datebook on a new pilot, so it's
starting to look like it's a real problem, not buggy code.

I'll skip more "I found it too" messages - I'm getting lots of 'em.

Some have asked whether they should complain to USR, return their Pilots, etc.
I can't/won't tell you what to do, but here's my thoughts...

Theories and Suggestions

Someone suggested:
Perhaps this problem could be because of the backlighting. I have no
technical reasoning to back this up, just a gut feeling. I don't own a new
pilot, but someone mentioned that the screen has a different feel to it,
which leads me to believe it is made differently.

I have no idea how indiglo (or whatever the pilot uses) works, but perhaps
the screen has a "indiglo layer" or something, and if you tap only lightly,
the energy of the tap is dispersed through the indiglo layer, causing your
tap to appear somewhere else.

Just a theory...

I've since determined that it's clearly a software bug - jump to here...

Another added:
I also just replied to a message (the one above - ajw) saying perhaps it has something to do
with the backlighting being an extra layer on top of the screen ... I
don't know that this is true, having not seen one yet, but assuming it
is ... I've seen the same problem when trying to use Display Guards,
which add another layer, too.

I wrote back:
Interesting - I've been using WriteRights on my older machine with no
problem - I switched to a Display Guard for the new one.

And got the response:
As I say, I found that pressing at one point on the screen with the
DG on caused my beastie to think I'd pressed somewhere else. This was
a pain, so I just gave up. I now have one of those plastic post-it tags
just over the graffiti area and that seems to work fine. Doesn't look
all that pretty, but I don't care too much.

Several people have asked if I'd recalibrated the digitizer - good suggestion, but that's not it. In the case of this bug, most of the taps are correctly positioned, and the erroneous one is wildly off.

I've determined it's software.

I've swapped the memory cards between my 1000 (with 1-meg upgrade) and my PalmPilot Personal.

The problem follows the Personal's memory - whichever machine has it shows the problem.

It's software. Q.E.D.

Jeff Jetton builds a test program to demonstrate the bug

Jeff speaks:

I've whipped up a little application that may help some people diagnose
this problem. It's called Tap Tester, and can be found near the bottom of
my Pilot page at:

www.mindspring.com/~jetton/pilot/

It's free, and includes the source code, for those who may suspect it's a
bug in the application itself.

Regards,
- Jeff Jetton

Thanks Jeff!

Current status, my thoughts about calling USR

17 Mar 97 3:53pm EST

As I write this, I've not gotten any further word from USR - as soon as I do, I'll post it here and send an email to anyone who's written to me about this, and post a message on the maillist.

I guess I should post in the newsgroups, too - haven't been following them lately... (yet more to do!) :)

My inclination is to hold on for a couple of days - USR only heard about this a two days ago (on a weekend - and some poor guy who was probably just working late took the time to respond to my email).
I'd give them a day or two to come up with an answer before we all descend on them.

If you've only got a short time during which you can return your new Pilot - that's a decision you'll have to make. I'm keeping mine because (1) I use it for development, (2) the problem is annoying, but not catastrophic, and (3) I'm sure there will be a patch for it, or some other fix.

By the way, my web site was off the air for a while last night and through today - I'm on a cablemodem which is usually very reliable, but when it's not, I'm gonzo. (my web server is hosted hear at home) There's a known problem "upstream" from me, so my connection may be a bit twitchy until that's fixed.

- Al Weiner -

Short message from US Robotics

I left this off for a few days hoping for further info. Just for completeness, it's here in its chronological place.

Got word from US Robotics on 18 Mar 97:

We are still working on it, although there is no answer for you yet.

"I've got the positioning bug, but on the 1000/5000"

I've gotten a number of reports of similar positioning problems, but occurring on older machines (1000s and 5000s).

Several people have said they'd sent their machines back to USR and had them fixed, and that USR was aware enough of the problem that they didn't have to go through the whole "did you ..." rigamarole. I guess (and it is a guess) that it's a known failure mode on the older machines.

This is (as far as I know) a different problem than the new-OS bug. These seem to be hardware (since they're not on all machines by any means) and have been fixed by USR.

Some of the people who've emailed said that the problem doesn't happen often enough for them to send it back for repair. I guess this is personal preference. I'm certainly not going to advise you not to fix it - but if it isn't bothering you, then you have to decide if you want to be without your Pilot for the time it will take to get it fixed. On the other hand, if you don't fix it, will it get worse later? I don't know. (if anyone does know, please let me know and I'll put a note here) If you're near the end of warranty, maybe it is worth getting it fixed... (and it's a great excuse to buy a new machine... :)

For the record, my 1000 (with the 1meg upgrade) doesn't show any positioning problems at all. It does have a "dead spot" on it - a spot where the digitizer just doesn't work at all. It's had this problem for over a month - knowing the new machines would be out soon, and being so dependent on my Pilot, I've been waiting before sending it in for repair. I'll send it in soon... :)

One user says...

This is an email I received recently - he's come up with a simple test for the bug.
(posted here with his ok)

I did some more testing on my Pilot. The basic conclusion I came to was
that if you do not tap hard enough on the screen then it has problems and
you get the phantom in the low left corner. I found with my Pilot using
DinkyPad that tapping lightly in any of the corners would finally lead to
a line running over to the lower left corner.

Trying to rule out DinkyPad I ran an experiment of bringing up the calculator
and entering a number and then tapping on the +/- key to toggle the sign
on the number. I found that if I taped lightly, to the point where the
sign was not changing, sooner or later the number in the display would
change to 0, as if the clear key or zero key in the lower left was hit.

The calculator test gives me a way to try store display Pilots that do not
have DinkyPad. While I am out this weekend I figure I will hit a few of the
stores and try out their display versions. I tried one this morning and
it showed the behaviour, it was also a 2.0 version. I am trying to find
some down rev versions to try. Also going to hit up a few people at work
to try it on theirs, since they are all over the building.

However after all the testing, it is likely to matter little since, as
I said before it seems related to light tapping.

On a side note:
I did have a 5000 for a little while and then returned it to move up to
the Personal. It seems to me that I am getting more miss read letters
on the Personal v2.0 then I remember getting on the 5000. Have you had
any feedback from others along these lines.

I agree - it does seem to relate to pressure. I think this is why I'm less accurate with graffiti on my Personal than on my 1000 - as you go faster you will have more lighter strokes. I was pleased (well, sort-of) to have confirmation that others aren't as accurate either.

I've suggested the calculator test a few times recently. Here's my instructions:

Go to the built-in calculator
Enter "1 + 2"
tap repeatedly on the "+/-" key in the upper-right
(light taps are what *seem* to cause the bug - taps which touch, but
don't touch hard enough to press the key)
Eventually (as short as immediately, as long as a few hundred taps)
you'll see the display change to "0" as if one of the CE or C buttons
were pressed.
If that happens, then the bug is in the Pro, too. You can then press
"=" and if the display stays 0, then the C key was "pressed" (by the
bug - tap mis-positioning) if it shows 1 then the CE was pressed.

Another person pointed out that the Recent Calculations screen (off the menu selections) will show that the C (clear) key was pressed.
Kinda makes the bogus keypress stand out, doesn't it?

US Robotics Tech Support doesn't know about this?

This was posted on the Pilot maillist today (Tuesday, 25 Mar 97)
(copied here with permission of the author)

Hi. Pilot Personal.

I can reproduce the "tap bug" using Doodle. So I called USR this morning
at 11:00am. The support person was not able to reproduce the fault, which
I can reproduce in MemoPad (cursor jumps to the end of a memo, or pops you
up into the memo list). The problem was referred to "a member of [USR's]
engineering staff", who called me this afternoon.

The engineer and I spent ten minutes on the phone, she with her Pilot, I
with mine. I could reproduce the bug inside MemoPad no problem, she could
not. She said that she was aware of a problem with DinkyPad but she seemed
to imply that USR believed this to be a bug in DinkyPad rather than any
OS2.0 related problem.

She said that she wants to look at my ROM chip and as soon as she can find
a replacement 512K chip with OS2.0 ROM, she'd ship it to me and then I'd
ship mine back to her.

She said she monitors alt.comp.sys.palmtops.pilot and the listserv
regularly and hadn't seen this bug widely reported. Based on that, she
believes that there may be some defective OS2.0 ROMs in circulation, but
that these are isolated cases.

Having just lost a rather large memo to this bug, I'm somewhat concerned,
not only for myself but for others who may have a "buggy" OS (if such a
thing actually exists).

Oh...and she asked me _not_ to put her name on this message. ;-)

For what it's worth...

Personals only? or Professionals too?

I've gotten several responses from people with Professionals - two said they couldn't duplicate the problem; one said he could. I held off on reporting this until I could get further information. Early on, several Personal owners said they didn't see any problems, then emailed back saying they had gotten the bug to occur. I didn't want to raise or dash hopes with erroneous reporting.

But this evening I got a note from someone who's got some very interesting news: the bug shows on the released version of the Professional ROM, but not on the beta version of the ROM!

I'm not sure what to make of this, but it's sure intriguing to me!

I'm sure looking forward to getting my hands on a Personal ugrade...

(and I sure wish USR would fix this bug!)

Another person spoke with US Robotics Tech Support...

Another person emailed me with this:
(posted with permission)

I just spoke to [USR tech support person] at USR and they say they are aware of the problem and it "does not effect many Pilots"... except mine! They asked if it prevented me from using my Pilot Pro and if I wanted to wait until they "completely resolved the issue". I would since it isn't THAT destructive yet (I am waiting for Modatech to update PilotLink for Maximizer so I don't have any critical info on it), but I am also in my 30-day window with PC Zone. USR suggested I send it back to PC Zone for a new one. When I asked whether I would get another defective ROM/screen, they said it was unlikely. I asked if it would make more sense for me to exchange it directly with them for one they were sure didn't have the problem. [USR tech support person] said she would talk to her supervisor and call me this afternoon.

(Alan again:)
I called Tech Support also - basically got the same word. From everything I'm seeing this problem is pervasive - but maybe I'm only seeing the failures because they're more vocal.

One difference between the Personals and the Pros - initially email about the Personals was running about 90% with the bug, and 10% without. Most of the 10% without would email me back saying they had found the bug. So it was looking like all the Personals have the bug.
On the Pros, I'm seeing about 50-50, with only a few people emailing me back saying they've now found it.

I don't know why this is. It could be that there are different Pro ROMs out there - since USR is shipping the Pros with flash ROM (tech support told me the upgrades will be, too) maybe the code changed mid-stream. But if that were true, wouldn't a fix be easier to come up with? (maybe; maybe not - depends if the change were intentional or inadvertent - or worse, something that works sometimes based on whole other causes - position sensitive or whatever...)

26 Mar 97 4:30pm EST - latest word from US Robotics

I emailed USR asking about an update. The response came back within minutes. (praise for quick response again!)
They said it's still being worked on. Since it's not destructive to data, nor does it crash the Pilot it's not being treated as a "drop everything and fix it" priority.

The hardware behind the problem

This was posted to the Pilot maillist on 2 Apr 97; reproduced here with permission

> Hi - I am not a subscriber to this list - my company doesn't allow
> list subscription - but I am posting this at Steve Simmon's
> request. Hope this helps explain the ol' tap bug!
>
> I noticed this problem once with my new PalmPilot Personal. I
> have worked with all kinds of touch screens off and on over the
> past 8 years so I am very familiar with how they are constructed
> and how they are used. I will give you some background (probably
> more than you care to know) and then offer a theory for why this
> problem has surfaced.
>
> The type of touchscreen used in the Pilot is called an analog
> resistive type. It is made up of a sheet of glass with a resistive
> coating applied to its top surface covered by a thin sheet of plastic
> with the same type of coating applied to its bottom surface. (I think
> the coating is referred to as Indium Tin Oxide or ITO) Four buss
> bars made of silver-ink are deposited on the glass near the four
> sides of the glass.
>
> These bus-bars provide a low resistance path that shorts
> all of the ITO under the buss bar together. Now if you apply a DC
> voltage to two of the bus bars that are opposite each other on the
> glass, you set up a voltage field that varies across the glass from
> one bus bar to the other. Great care and special steps are taken
> when designing and constructing the touchscreen to attempt to ensure
> that the field developed is linear from one bus bar to its opposite
> partner.
>
> The top piece of thin ITO-coated plastic is separated from the
> ITO-coated glass by means of a thin non-conductive oil. When you
> press on the screen you force the top sheet to come in contact with
> the bottom sheet at the point where you are pressing. The position
> of the contact point can be determined by alternately applying a DC
> voltage to the buss bars at the sides (X) of the glass and to the
> buss bars at the top and bottom (Y) of the glass and by reading the
> resulting voltage developed at the touchscreen top plastic. If you
> know what the voltages are at the bus bars, and you assume the
> voltage varies linearly between bars then its an easy matter to
> determine the touch position between the bars given the voltage
> sensed from the top plastic. The Pilot uses an ADC to measure the
> touchscreen voltages.
>
> Unfortunately as you touch the screen there is not a clearly
> definable "instant" at which the top sheet comes through the fluid
> and contacts the bottom sheet. It is the job of the touch-screen
> driver to determine when that moment has arrived. This is usually
> done as follows:
>
> An equal voltage potential (usually system ground) is applied to
> all four bus bars simultaneously and the top sheet (usually referred
> to a the sense wire) is "pulled high" with a rather large value
> resistor. A touch down is detected when the voltage on the sense
> wire gets below some arbitrarily low level.
>
> At this time the touch-screen driver is invoked and the touchscreen
> is actively scanned - usually at the rate of several thousand times per
> second. This results in a stream of numbers, representing the X and
> Y voltage present on the sense wire, to come into the touchscreen
> driver. The driver performs some sort of digital filtering on the
> data to remove noise, if present, and makes a decision as to whether
> or not this is a good touch point. If the point is a valid touch,
> then the driver sends the information off to the OS or other program
> that is interested in touch points. If the point is not valid, the
> driver throws it away. The first point in a series is called a
> touchdown and the last point in a series is called a liftoff.
> If the driver makes a poor decision as to the validity of a
> point, then you can end up with "bogus" points being sent to upper-level
> software from the driver. There is a trade-off between being certain
> about the validity and stability of a touch point an the response
> time of the driver. In other words if you only had to generate 1
> good point every second - you would have lots of data to work with
> and you could be very sure that the point delivered was a valid one.
> However, if you want to recognize handwriting and you need to
> generate lots of points per second to the upper level software so
> that the pen stroke can be tracked and interpreted, then you might
> not be so certain as to the point's validity.
>
> Bogus readings, as you might expect, most often occur near
> touchdown and liftoff when there is a not-so-good contact between the
> top plastic and bottom glass. Also bogus readings will increase as
> the noise level of the system increases.
>
> Enter the new OS and the backlight. The backlight in the Pilot is
> an electro-luminecent type which is only important here in that it
> takes high AC voltage, usually about 80VAC, to operate it. I
> wouldn't be surprised if USR had to modify the touchscreen driver to
> filter out the extra noise that is generated by the backlight. As we
> know, any time you change something you have the possibility of
> introducing problems into it.
>
> Theory : Changes made to the touchscreen driver to deal with
> backlight noise and/or in attempts to decrease the response time of
> the touchscreen have introduced the "tap bug". OR No changes were
> made to the touchscreen driver after the backlight was added and
> noise from the backlight is screwing things up.
>
> If the latter is true then you should see the tap bug only when the
> backlight is on. Only USR knows if the former is true.
>
> BTW: Lightly tapping or lightly pressing on the screen is the
> harshest test of the touchscreen system since the contact between the
> upper plastic and the glass is marginal during light presses.
>
>
> Hope this helps shed some light on things.

Another User Dances With US Robotics

Another user posted these to the maillist. They're the mail back-and-forth with USR. (as usual, they're posted with permission)
I'll let you draw your own conclusions.
To protect the guilty and innocent alike, I've removed names where full names were used. If you'd prefer your name to be there, just let me know and I'll put it back in.
I realize this is silly, as the full text is available in the maillist archives, but I feel better protecting people's privacy in this manner. Consider it a quirk in my makeup...

Posted to the maillist 1 Apr 97:

A recap:

My Palm Pilot Personal has a bug which causes the cursor to jump to the
bottom left of the screen. For instructions on how to reproduce the
bug, check the bottom of this message.

Today I received this e-mail from USR Support:

---------- cut here ------------------
Dear [name removed - ajw],

Thank you for contacting U.S. Robotics Palm Division.

I see that you are still experiencing the same problem with the new
chip.

I have not been able to duplicate this problem myself. Nor, am I aware
of
any design flaw in the Pilot. Therefore, I have passed your problem
over to
our escalation group. You should be receiving a callback within 3-4
business days.

If you have any further comments or questions, please send them to:
support@palm.usr.com

Please post all replies under this message and include all previous
messages
when replying.

Thank You,

[name removed - ajw]
U.S. Robotics Palm Division
The Intelligent Choice In Information Access
------------------------------- cut here ---------------------------

Contrary to [name removed - ajw]'s assertion, I never received a new chip. USR *was*
going to send me a new chip and even called for shipping information.
Three hours later I received a call from an engineer telling me that USR
no longer felt that a chip replacement would correct the problem and
that no replacement chip would be sent.

Today I received a message from "Tim" at at USR. He called me to
confirm that USR is now calling the "tap bug" "a known problem" (quite a
different story from what the e-mail implies). He suggested that I
check the USR web site frequently, but was unable to offer any other
help.

Finally, I have received two dozen pieces of e-mail reporting this bug.
I know Alan Weiner is tracking reports. I have also received reports
from owners of the 5000, Personal and even some Pros that *do not* have
this bug.

Just passing it along. Draw your own conclusions.

As always, your mileage may vary.

To reproduce the bug:
---------------------
METHOD #1
1) load either DinkyPad or Doodle.
2) start a new drawing.
3) tap in the upper right corner many times.
4) eventually you may see a line segment appear crossing from upper
right to lower left. This may take 1 tap or 200 taps.

METHOD #2
1) switch to the Calculator.
2) Key in a number.
3) Tap the +/- key as above.
4) If you have the bug, the display will go to "0" as if you'd pressed
the "C"lear key in the lower left corner.

Posted to the maillist 2 Apr 97:

I sent this today. I included my confirmation of the report of the tap bug
in the Graffiti area, as well as a copy of technical explanation supplied
by [name removed - ajw] (thank you Doug) courtesy of [name removed - ajw] (and thank you
Steve). At around 6pm I got the following reply from [name removed - ajw],
General Manager of Palm Computing (her name appears on the bottom of your 1
Mb upgrade notice).

I pass it along to the list for information purposes. At the request of
the engineers I spoke to, I have deleted their names from this message.

---------------------------- cut here ---------------------------------------
[name removed - ajw]... we're doing quite a bit of work on this problem to isolate it and
understand it. Our analysis is not yet complete. Thanks for continuing to
send along info ... we'll let you know when we come to some conclusions
after looking at all the factors.

[name removed - ajw]
______________________________ Reply Separator___________________________
Subject: 0000
Author: [email addr removed - ajw]
Date: 4/2/97 1:19 PM


RE: Call reference number [number removed - ajw].

I am now experiencing the "tap bug" in the Graffiti area of my Palm Pilot
Personal. The cursor jumps around the screen at random while I write
Graffiti strokes. I thought I was hallucinating until another user
confirmed my worse fears.

You can reproduce this bug by creating an 11 line memo, placing the cursor
in the top line of the memo and then tapping gently anywhere in the
Graffiti area.

This is escalating to the point where my beloved Pilot is almost unusable
since I cannot trust that it won't suddenly delete a memo or clear a line
of text.

I have had calls from two engineers, both of whom say that USR acknowledges
this bug. The last call from --- simply told me to keep my eyes on the USR
web site.

We have now received a plausible technical explanation as to why we are
seeing this bug which follows:

------------------------------ cut here ----------------------------
[this section contained the above hardware description - removed 'cause it's up above - ajw]
---------------------------- cut here ------------------------------

What steps is USR taking to correct this serious deficiency?
------------------------ end of quote ---------------------------

Posted to the maillist 4 Apr 97 (reposted; originally posted 2 Apr 97, but didn't show up):

Curiouser and curiouser...

This evening at approximately 7:00pm EST, I received two voice mail
messages from USR.

The first came from the very first engineer I spoke to (the person after
the front-line technical support person). It was a message saying that she
knew I'd be surprised to here from her again and that she wanted to discuss
the difficulties I'd been having with my Palm Pilot Personal and the Tap
Bug. Called back and got voicemail so I asked her to call back.

The second message was from someone who I assume to be a shipping
expediter, asking for my correct shipping address and a credit card number.
She went on to explain that USR was sending me a replacement Palm Pilot
Personal (!). USR will send me a replacement and I'm to send the other one
back, with the credit card number as security.

Seconds ago, the USR engineer returned my call, explaining that she was on
her way out and that she couldn't spend a lot of time on the phone with me,
but that USR wanted to have a look at my Pilot since I seem able to
reproduce the bug so easily (and USR apparently cannot). She said that
she'd arranged to have the unit sent directly to her for examination and
that she was pre-shipping a replacement unit.

I asked her why there had been such sudden movement on this. She explained
that the both she and the second engineer I'd spoken could only escalate
the problem so far. Subsequently, someone "much higher up" had made the
decision to bring my Pilot in for examination.

I asked whether USR was aware of [name removed - ajw] analysis of the touch screen
problem and she said that she (and, one presumes, USR) was aware of that
explanation (thank you [name removed - ajw]). She then offered to call me back
tomorrow to further discuss the problem. I accepted. I'll post when I've
spoken to her.

Go figure.

Posted to the maillist 4 Apr 97:

...and around and around we go...

For the story to date, read Pilot Tap Bug UPDATE #3. [that's the part above - ajw]

You'll remember that USR had called to ask for my shipping address so that
they could exchange my Pilot for another. Their engineer told me that they
wanted to see my Pilot since it was so easy for me to reproduce the Tap Bug
on it.

So today, USR calls and leaves a message. Presumably a shipping expediter
called to say that USR would _not_ be shipping a new Pilot to me today,
since they "were unable to locate one to send me." When I called back, said
expediter volunteered that USR had been unable to find a Palm Pilot to ship
to me to replace mine.

How curious.

As always, draw your own conclusions.

This continues on 8 Apr 97 as The Dance Continues

My thoughts based on latest information (as of 5 Apr 97)

I suspect that the device driver for the digitizer has been changed between the older models and the new model. Most likely to make it work better with the (electronically noisy) backlight. At a guess, the change was late in the development cycle - one report was that the late beta code didn't fail, while the released code did.
I suspect the change or changes introduced the tap-position bug.
I believe the bug is timing-related since it appears on most Personals, but only about half the Professionals. The Personals have an 8-bit memory bus while the Pros have a 16-bit bus. As a result, the Pros are faster; I suspect this reduces the timing window where the bug may occur. (you could think of it as the difference between taking a bath and taking a shower - since most people spend more time taking a bath it's more likely that the telephone will ring while you're in the bath than in the shower.)

I do hope that USR releases full details about this - I suspect they won't just because of corporate mentality, but I'm really curious about what's happening, how the bug was introduced, and what it took to track it down and fix it.

8 Apr 97 - The Dance Continues

The person who posted the messages above (see "Another User Dances With US Robotics") just sent me this:
(he also posted it to the maillist, and as usual it's here with permission)

I called USR to follow up on the delivery of a replacement Palm Pilot
Personal for my Pilot which exhibits the "Tap Bug". For a description of
the bug and an explanation of how to reproduce it, see the bottom of this
message.

I received a return phone call (on voicemail) from the 1st engineer I spoke
to at USR. She explained that USR is still out of stock on the replacement
boards, but that USR may not need to ship me a replacement since they "have
identified the problem and are working on a software fix for it". This fix
is scheduled for delivery in approximately 2 weeks, according to the engineer.

I have placed a followup phone call to get a more thorough explanation of
the problem and the proposed fix. If I get an explanation, I'll post it here.

--------------------------------------------------------------------
Description of the Tap Bug
---------------------------
The tap bug appears on some Pilots. It seems to appear more frequently in
Palm Pilot Personals, although there have been reports of its appearance in
early Pilots and the Pro.

The bug, which affects the screen area of the Pilot, causes "phantom"
screen taps; when you tap one part of the screen, the Pilot acts as if you
had tapped another area. This is *not* a digitizer alignment issue as
confirmed by USR. It may or may not affect both the display area and
Graffiti areas of the Pilot. On my Pilot, it affects both areas, causing
the cursor to jump to different fields or applications, delete memos,
select text and draw "phantom" lines at random.

It has been theorized by Doug DeVries that the bug was introduced into the
OS 2.0 ROM when the filtering threshold of the screen driver was lowered in
order to improve the backlit screen response time. There has been no
confirmation of this by USR, although USR has told me that they are aware
of Doug's theory.
-------------------------------------------------------
To Reproduce the Bug:

Method #1
The easiest way is to use Dinkypad or Doodle.
1) Load Doodle.
2) Start a new drawing.
3) tap lightly in the upper right hand corner of the screen.
4) After as few as a one tap or as many as...a whole bunch...you may see a
phantom line segment appear as if you'd drawn a line to the lower left of
the screen.

Method #2
1) Start the Calculator App.
2) Enter a number (any number)
3) Lightly tap the +/- key, which should cause the number to alternate
between positive and negative numbers.
4) If the bug strikes, you'll see the display suddenly zero itself as if
you had tapped the "C" key.
-----------------------------------------------------------------------------

This message is presented for informational purposes. As always, draw your
own conclusions.
------------------------------------------------------------

10 Apr 97 - Somebody needs to tell Tech Support...

These are several messages "Charles" sent to Tech Support. Some support folks seem to know about the bug, others don't...

While the second response is humorous in its cluelessness, the first response brings joy and hope for a resolution to this tap-positioning bug. (which I ran into over 20 times in one hour this morning, as I attempted to enter a series of notes into a memo)

Charles sent this:
What progress has been made on the PalmPilot bug that causes a tap on the upper-right part of the screen to occasionally be interpreted as a tap on the lower left-hand corner? Since the level two tech was not aware of this bug (and did not believe that I had reproduced it on my Pilot but thought I was just repeating "talk" in the newsgroups - see call #2157979) please see http://aweiner.ne.highway1.com for details. I must return my Pilot Pro by 04/20 for a full refund. If you have a fix before then, I would like to keep it. A "Tim" has acknowledged that this is "a known problem".

Have fun,

Charles

And received this message back:
Hello Charles,

We are looking at making a patch for this situation. This should be ready in about 2 weeks. You will be able to download it from the web at:
www.usr.com/palm

[name removed to protect the innocent - ajw]
Customer Services

A while later he received this message:
Dear Charles,

Thank you for contacting U.S. Robotics Palm Division.

I see that you if you tap in the upper-right portion of the screen it is occasionally interpreted as a tap in the lower left-hand corner.

Unfortunately, this is not the same problem that you mentioned reading about at the aforementioned web site.
If you are experiencing the above display problems, I recommend trying a soft reset, which consists of using a paperclip to push the reset button through the reset hole in the back of the Pilot. This hole is just under the bar code and above the battery door and says "Reset" above it. If that
doesn't work the first time, try it at least once more. If there is no response, then HotSync and try a hard reset. A hard reset is the same as a soft reset except that you hold down the green power button the entire time (make sure that you press green button down before you start and continueto
hold it for a few seconds after you have finished with the reset). If that doesn't work, try taking the batteries out for an extended period of time, like at least 10 minutes.

If you have any further comments or questions, please send them to: support@palm.usr.com

Please post all replies under this message and include all previous messages when replying.

Thank You,

[name removed to protect the guilty - ajw]
U.S. Robotics Palm Division
The Intelligent Choice In Information Access

Email about a patch

I got this message from another person yesterday - sounds good! (as you'd expect, it's posted with permission, and names have been sanitized...) :)

Hi,

I just received this e-mail from USR tech support. Thought you'd be
interested.
-----
Date: Tue, 15 Apr 97 08:13:05 pst
Subject: Re[2]: 0000

This is a known bug, and our developers are currently internally
testing a patch that will fix this problem. This patch should be
publicly available within the next two weeks. I would continue to
check the Customer Support section of our webpages for further
updates. Currently the patch is ~1K.

[technician's name removed - ajw]
Technical Support
U.S. Robotics, Palm Computing Division

It's fixed!
USR Releases a patch file!

This is what I originally posted - it's updated below

USR has released a patch file for the new PalmPilots which fixes the tap-bug fix.

It's located at http://www.usr.com/palm/custsupp/os201rdme.html

I haven't been able to check that page (although I have the patch) because of a problem with my Internet Service Provider.

Yee-ha! End of the road for this bug's history!

The tap-bug fix has been included in later OS updates...

The latest OS update (2.0.4) is located at http://www.3com.com/palm/custsupp/upgrade.html

Some PalmPilots still have a tap problem which isn't fixed by the patches (at least up through 2.0.4)

click here to go to Gary Duke's OS2.04-resitant tap bug page

Return to my home page