G'day Bill,

BG> but the M34F was normally only connecting at 26400/NONE or 28800/NONE (and
BG> even then, only around 20% of the time) unless the lesser link rate of
BG> 26400bps was forced from my end, following which it would
BG> connect with LAPM almost every time without fail.

IS> Exactly the same symptom as the Motorola Lifestyle calling
 IS> any of a rack of
IS> M34s (not sure what the rack model designation is, but
 IS> they're M34s) at the
IS> uni, from a site within sight, via maybe 2k round-trip to
 IS> the AXE exchange.

 BG> Do you happen to know if the M34Fs are using the 2.61
 BG> (latest) ROM code?  Paul's is, and I was able to briefly
 BG> borrow an M34F, also with the 2.61 code, and it would
 BG> connect with Paul at 26400/REL each time (no 28800
 BG> connects).

Perhaps time I went up to the uni and had a proper look .. my hunch would
be, probably not.  Maybe the thought of having to learn *nix on their Sun
to try sorting out their terminal adapter load-sharing problems, is too
scary .. :)

IS> The forcing lower speed trick was less satisfactory than having the
IS> Motorola set more fussy re BER for given speed connects,
 IS> which still allows
IS> 28800 on best lines / connects, but trains up lower initially.

 BG> True, it's most unsatisfactory, especially as V.34 is
 BG> supposed to analyse line conditions transparently, and
 BG> connect accordingly, no user intervention required at all.
 BG> This is not happening with an M34F on one end of the link.

I don't think it's a V.34 problem, as such.  The physical protocol connects
are solid enough, no dropouts reported on multi-hour connects, etc.  I
think it's a timing problem above that level, where the controller code,
having been returned a (say) 28800 connect by V.34, which is connected and
pumping, has to use that underlying V.34 layer to then negotiate error
correction - or not.

Where some modems might take a little longer, and recognise and acknowledge
the requests incoming for (say) a LAPM session, the Netcomm's decided it's
too late, and in its haste has declared EC off.  That's my take on it,
anyway.

Following on .. when the other end is being more fussy about line quality
(BER for a given connect speed), the extra speed negotiation time synchs
the EC negotiation better, and EC is thus readily achieved.  (Just gut
feeling .. but there are various older Rockwell-chip gadgets, including
Maestro 144FMs, that seem to share this tendency, though only on poorer
lines.)

IS> Noone's seemed to have discovered how to set the Netcomms to be more
IS> sensitive, that I've heard.

 BG> The Tx level can be forced as low as -9dBm I believe, but
 BG> nothing will make them receive any better.  Even when Paul
 BG> was playing around with different Tx levels, the CONNECT
 BG> 28800/NONE problem still occurred from here.

I don't think it's got much to do with levels at all, that's something else
that V.34 is supposed to be able to test, adjust and negotiate to suit. 
That people were reporting up to 33600/33600 connects, with what might
appear to be lowish Tx levels reported, may support that.

The timing problem (per my hunch) might or might not appear on especially
excellent lines / connects, I'm not certain, but this problem occurs on
lines that _should_ be excellent .. but I've as yet no facility to test
them myself.

IS> Can you adjust your Sportster, in that respect?  Ok, yours
 IS> is fixed anyway,
IS> but maybe for others .. ?

 BG> No, the Sportster Tx level appears to be non
 BG> user-adjustable, although the Tx level will still vary
 BG> according to prevailing line conditions anyway, but that's
 BG> just an inherent feature of V.34, not the modem itself.

Yes, but again I wasn't talking about levels, but at what BER (signal
quality) the modem decides that a (say) 26400 connect would be more
appropriate - perhaps sensitivity isn't the right term, but that's what it
comes down to ..

 BG> My problems are now academic anyway, as the V.34+ EPROM
 BG> arrived while you were absent, and my link rates have

I'm still mostly absent, but thought I'd better catch a few before they
drop off into text backups.  The echo, from a very scanty browse, seems to
be in pretty good spirits; perhaps I needn't be feeling quite so neglectful
:)

 BG> increased 1 to 2 x 2400 steps to those modems which were
 BG> giving less than 28800 connects, and my calls to Paul are
 BG> also connecting with EC every time, mostly at 28800,
 BG> occasionally at 26400, but there have been no other
 BG> problems at all.  Not bad when you consider how poor my
 BG> lines are.  Even my calls to Dave Drummond on his
 BG> immaculate lines generally only show a 33600/31200 connect
 BG> (and very occasionally, 33600/28800).  Funny thing is, it
 BG> ALWAYS receives at 33600, regardless.  I'm not complaining
 BG> though, as my frequency chart shows that I'm lucky to be
 BG> connecting at speeds higher than 26400 (and that's on a
 BG> good day!).  :)

Ah, I can still to look forward to some good on-line stats.  I've just
acquired a board that can, among other things, acquire a single analogue
channel, at 12 bits, at upto around 90kHz DMA.  I'm thinking it might be
interesting to peek at some line signals at that sort of rate .. :)

All the above may be referring to (as John Cleese might say) an ex-parrot. 
I'll suggest that firmware revision number to the uni bods, thanks.

Cheers, Ian

--- MaltEd 1.0.b5