David, at 12:40 on Mar 17 1996, you wrote to Bill Grimsley...

DD> When I got up this morning, there was no mail! Shock horror!

Bloody hell, you must have gone into immediate email withdrawal too!  It's
not fatal, but awfully uncomfortable nonetheless.  Just quietly, that might
have been the ideal time to try that "configuration change"
you've been discussing of late, too...  :)

DD> I checked the logs and JabberWOCky had connected about 40 times with 
DD> marwick, then promptly hung up.

Oh shit, and presumably at 25 cents per time as well.

DD> I turned on the modem speaker and polled again.  It did exactly the same 
DD> thing.

Si this is going to be the blow-by-blow explanation, I take it?  :)

DD> After thinking I must have stuffed up the session password (the nodelist 
DD> compiled in the night), I thought I would poll Paul (Edwards) instead.  It 
DD> hung up on connect with him too!

I wouldn't be immediately jumping to conclusions though; that could simply
have been your system being discerning about who it rings.  Still, it's a
worry.

DD> It seems that with the "full connect info" screen turned
on, the NetComm 
DD> does NOT return a CONNECT 28800 string which Binkley seems to be looking 
DD> for to determine the connect.  I turned \V back to 0 and tried again. 

You're joking!  So doesn't the connect string appear on just one line then,
the same as the USR?  In fact, how exactly IS it reported on the M34F?  The
on-line help screens actually detail a number of different methods which
can be used, but that's an even worse "quirk" than the USR's ATZ
anomaly.  What if you'd been doing a sched pollfeed to say somewhere in
Zone 1 or Zone 2?  Urk!

DD> It worked!  Bloody bland stats though.

Yeah, they're fairly basic after the Courier, aren't they?  :)

DD> With \V9 the stats screen returns 

DD> Terminal: 57600 and  Line: 28800 

No big deal though, as all Rockwells show both DTE and DCE if you want.

DD> strings, so I got Binkley to look for the LINE one.  It acknowledged a 
DD> connect, but was unable to decide the speed and posted 57,600.  This plays 
DD> havoc with the transfer efficiency percentage (I got 3393 cps downloading 
DD> an EXE from Paul).

Calculated, of course, and not actual.  It'd certainly look good on your
board's USR_STATS screen too, wouldn't it?  :)

DD> I phoned the local M34F with the Sporty, and then the Sporty with the M34F:

Oh good, as these are the figures in which I'm most interested.

DD> Dialling into the M34F:
DD> =======================
DD> USRobotics Sportster 28800 Fax Link Diagnostics...

I keep forgetting that you're currently using Jill's Sportie, too.  Fairly
gives me the shits, having a 33k6bps modem, and not being able to use it. 
:)

DD> Recv/Xmit Level (-dB)    16/18

Bugger me!  Your Tx level is lower than your Rx level!  I bet Joe would
freak right out if you posted those stats in USR_Modems...  :)

DD> aty11
DD> Freq     Level
DD> 150      32
DD> 300      19
DD> 450      16
DD> 600      15
DD> 750      15
DD> 900      15
DD> 1050     15
DD> 1200     15
DD> 1350     15
DD> 1500     15
DD> 1650     15
DD> 1800     15
DD> 1950     15
DD> 2100     15
DD> 2250     15
DD> 2400     15
DD> 2550     16
DD> 2700     16
DD> 2850     16
DD> 3000     17
DD> 3150     17
DD> 3300     18
DD> 3450     21
DD> 3600     27
DD> 3750     37

What can I say?  Apart from "I hope your telephone exchange burns
down".  :)

DD> ================================
DD> and dialling into the Sportster:
DD> ================================

This ought to be interesting...

DD> at%q%l
DD> 017
DD> 050
DD> OK

So your EQM is once again between 17-19, and Rx signal level is -50dBm. 
That doesn't look right at all, given that you're only calling to the end
of the street and back.  How can the M34F claim that an EQM >10 is poor,
yet return such a high value on such a short distance call?  And that Rx
level is not right either.  -50dBm on Rx is so low that you'd hardly even
hear it.

DD> I'll let you feed these figures through your analyser and decide what they 
DD> mean :-)

Your guess is as good as mine, but something's definitely not right with
the NetComm.  There's no way those readings are accurate, none at all. 
Given that Joe reckons the Courier details its line probe levels
accurately, I'm beginning to suspect that the NetComm is severely broken in
that regard.  Trouble is, we still can't be certain who's at fault here,
and I'm not convinced that it's worth ringing NetComm's Brisbane office to
ask, as I have very little faith in the cretins up here; not after the last
debacle re the M5's ROM code.

Regards, Bill

--- Msgedsq/2 3.20