On Jan 31 08:57 96, Paul Edwards of 3:711/934.9 wrote:

PE>> 1. After receiving an "AT" command at a particular baud rate,
PE>> the modem does not adjust to that baud rate, and instead stays
PE>> at the rate at the time of last "AT&W".

DH>> That's common to nearly every high performance modem I know of nowdays.  
DH>> Any change in the locked baud rate to the UART requires a fresh
AT&W.  

DH>> Complicated by the fact that there are circumstances where the USR isn't 
DH>> too happy to accept a ATZ.

PE> I'm not sure if I described it satisfactorily...

PE> The last &W was done at 57600.  I then go and use 38400.  I type
PE> in ATZ.  It auto-detects the AT and sends the response, "OK" back
PE> to me at 38400.  I then proceeds to send the "RING" word to me
PE> at 57600.  It's either designed wrong, or it's a bug.  There is
PE> absolutely no sense in using two different baud rates to my session.
PE> Didn't happen with my Spirit II either.

This is as dangerous as walking on razor blades.  It's held together by the
dynamic ATZ that it may or may not see in time.  If the RING comes in
first, you get rubbish.

It's not USR's fault - it's inherent in the situation.  After a reset, the
modem has no record of the DTE baud rate - but it can, and does, remember
the last AT&W baud rate, that's permanent.

PE> You reckon this happens on Rockwell-based modems?

Yep.  Including the Spirit.  Do a power up, say nothing to it, and send in
a ring.  Guaranteed, "RING" will come out at the speed of the
last AT&W.

"Power up" includes a glitch on the supply that didn't reset the
computer, at least now and then, on most modems I've seen.  The cyclic init
that Bink does is a genius class idea, to handle a very necessary
situation.

PE>> 2. Regularly getting 26400 connects with a Netcomm instead of
PE>> 28800.

DH>> Such be life.  Is that line capable of 28800 with negligible errors?

PE> He can connect to others at 28800.  I can connect to others at
PE> 33600.  I would have expected at least one of his calls to get
PE> through successfully at 28800.

So would I.  Do the final transfer bit rates still match 26400?

PE>> 3. Modem is initiating a retrain straight after each connect,
PE>> even with V32bis modems.  I would expect that the initial
PE>> negotiation would have figured that out, no need for a retrain
PE>> on every single bloody call.  Yet the ATI6 does not show that
PE>> a retrain was requested.

DH>> SOP.  

PE> ???

"Standard Operating Procedure".  Works better.  Much.  The
handshake time is going on while the equalizer is settling, the exchange is
still buggering about, and generally the worst of all possible worlds.  10
seconds later is a lot more stable.  As near as I can see, what USR have
done is to do a fast and rough approximate, and make it on the conservative
side.  Follow through with a final polish on the desirable parameters for
this call several seconds in.

DH>> This is the major reason for success where other modems fail - the 
DH>> USR is designed to connect VERY conservatively - then train up if 
DH>> indications warrant. Training going on during connect phase
isn't all that 
DH>> reliable.  If you watch it, eventually you'll see it -not- train up - the 
DH>> line wasn't good enough.

PE> So it trains up after every call by design?  Ok, then why doesn't
PE> ATI6 show the retrain?

'Cause it's not a genuine retrain, which would take extra time.  It's a
forced "fall forward".  Don't know the V34 spec well enough to
hit the exact terminology.

PE>> 4. Having problems talking to a Supra modem, 50% dropouts where
PE>> previously there were none (with a Spirit Thunder modem).

DH>> Supra on v34 or VFC?

PE> V32bis.

Bloody HELL.  That's a serious indication of drastic problems.  14400
should get through almost a barbwire fence.

PE>> 5. AT&F1 sets S56 equal to 16 instead of the default of 0 listed
PE>> in the manual.

DH>> Confirm.  There's a fair amount more of that as well.

PE> Want to document some of them?  BTW, David Drummond says the
PE> default on his is "definitely 0".

The word just coming through to me is to fall back to his SDL version.

I/D seems to be both supervisor and datapump dated 5 July, 1995.  To be
advised, not tried here yet.  Watch this space.

PE>> 6. A Spirit Thunder is getting connects with me at 2400 bps far
PE>> more often than 19200.  1200 bps connects too.

DH>> El yuck.  This -could- be the Spirit.  Your setup on your Thunder got 
DH>> 19200 to my USR regular as clockwork for some time.  Setup or hardware.  
DH>> What did that site get while you had a Thunder online?  (I'd suspect 
DH>> excellent..)

PE> He got 14400 all the time when I had my Thunder online.  That
PE> is because I had V32ter disabled on my Thunder (for incoming
PE> calls).

PE>> 7. USR to USR connect failed due to a retrain failure.  Also,
PE>> USR to USR is showing 21600/2400 as the connect rate.

DH>> This one is being chased.  It's not the USR, it's telstra.  Reasonably 

PE> BTW, I dial you using Optus, with "145602-xxxxxxx"

Same equipment.  The only thing that changes via Optus local calls, so far,
is an additional digital routing leg to the Optus gateway exchange and back
again.

Otherwise, it's routing via the Telstra trunks and exchanges.  This -will-
eventually change, as Optus get fiber laid, I'd suspect.  To be seen.

DH>> recent, and it's the same thing that used to plague us during the early 
DH>> VFC days when "sudden disconnect" was the order of the
day.  Wildly split 
DH>> baud rates are the hallmark of the fault at the moment.  You'll find this 
DH>> happening to top quality lines - good connect, transfer rolling at high 
DH>> speed - sudden halt, frantic attempts to retrain, all fail, exit with one 
DH>> direction only affected, and it at some ridiculously low speed
as the last 
DH>> attempted.

PE> How do you know it is Telstra, BTW?  The results of ATI6 (defying
PE> the laws of physics) make it look like the USR is screwed.

It's not happening to just USR's.   The USR diagnostics are good enough to
rub your nose in it - but once knowing it was there and how to look for it,
I got exactly the same thing with a pair of Hayes 28800 Optima vFC's.

Jury's still out on what the dickens it is.  That it exists is no longer in doubt.

PE>> 8. Failed to connect to Hayes modem at all.  Very weird sounds
PE>> coming out.  No problem when I was using a Spirit.  This actually
PE>> happened with an older revision of the ROMs, and cannot confirm
PE>> at this stage whether it still exists because the modem was 
PE>> taken offline so that I could connect.

DH>> Unknown situation.  I connect Hayes/USR nearly every day, both
VFC and V34 
DH>> models.  Possibly setup, possibly defective modem, possibly very early 
DH>> Rockwell set with major bugs still present.   And possibly a wierd bug 
DH>> still in the USR - hard to tell without definitive tests.

PE> Even harder to tell with the modem no longer online.  :-)

PE>> 9. A Netcomm modem (PCMCIA or something) gets connects of 1200, 
PE>> 2400, 14400 and 28800 with me.  This also happened with the
PE>> older ROMs, and the caller has not called since I changed ROMs,
PE>> so cannot confirm the continued existance of this problem.

DH>> ????

PE> You need the exact brand of the modem?  I'll have to ask.  

Doubt the brand is going to help.  Just dunno.

Regards,
Dave Hatch.

--- Msgedsq 3.20