DD> For a bug it seems well documented.

BG> Furthermore, only Paul Edwards thinks it's a bug,

RS> Nope, the ATZ quirk is clearly a bug, and ISNT documented AT ALL.

BG> Dunno, I've played around with that some more since last time, and I can't 
BG> repeat that sequence at all.  I'm sure I'm not doing anything differently 
BG> either (maybe the first example was flawed?).  The only time I get 
BG> gibberish on an incoming RING is if I change the port speed in my comms app 
BG> without issuing an AT command (other than ATZ) to the modem.  I can't even 

Yes, you are right.

BG> use ATI4 to check the modem's port speed, as that immediately auto-bauds 
BG> the modem and then shows the same as the app's altered speed.

Which is exactly what you said yourself a few days ago.

BG> I don't accept that the failure of ATZ to auto-baud the modem is a fault or 
BG> a bug at all.  In fact, I'm more inclined to suspect that it's been done 
BG> that way intentionally for some obscure reason (but yes, it should be 
BG> documented).

It's fucked by design if done intentionally.

BG> whilst the other 5 million Courier owners are obviously too thick to 
BG> realise it...

RS> Well, if you never change the port from the speed used for
RS> the &W you wont see the bug, so thats hardly very surprising.

BG> Can you give me just one valid reason for even needing to alter the port 
BG> speed on the fly?  Not these days, although USRs have been around since the 

What do you mean "on the fly"?  What happens is I decide to find
out whether my system can cope with 115200, so I change my terminal
speed to 115200 in my comms program.  I don't expect to go and have
to issue a command to the USR to save to NVRAM, that's what auto
baud rate detect is all about.

RS> And since it only affects ATZ, even those who do use a port speed thats
RS> not the one that was used in the &W wont see it unless they only have an
RS> ATZ modem init string. And presumably most of those dont use their modem
RS> for incoming calls so wont notice the RING effect even if they do either.

BG> Aside from the gibberish response, the mode still works though.

RS> Its an absolutely classic genuine bug, not documented AT ALL.

BG> Nope, I can't believe that USR aren't aware of that behaviour, as fixing it 
BG> would be a trivial exercise in their flash-ROM code.

But Bill, how can they be aware of it when NOT ONE SINGLE PERSON
in the ENTIRE WORLD (your stats) has EVER REPORTED this problem
before?  And the few that did find out (after I told them) assure
me that ALL of their comms programs regularly change speed after
an ATZ is issued to go back to the speed of the last NVRAM save,
so that's exactly the behaviour they want from USR!  BFN.  Paul.
@EOT:

---