[comp.dcom.modems] MNP 10

jly33321@uxa.cso.uiuc.edu (John L. Yoon) (04/17/91)

I just read an article on Microcoms new cellular modems and I notice the 
implement MNP 10.  Does anyone out there have any info on MNP 10?  It 
looks very interesting....

John Yoon
jly33321@uxa.cso.uiuc.edu

Erik@tdkt.KKSYS.MN.ORG (Erik Jacobson) (04/22/91)

 > I just read an article on Microcoms new cellular
 > modems and I notice the implement MNP 10.  Does anyone
 > out there have any info on MNP 10?  It
 > looks very interesting....

I don't have a lot of info on it, but I do know that one of 
it's special features include a way to "hold on to carrier" 
up to (I think) 10 minutes before it drops.  (For hitting 
"static" or low areas).  I believe Microcom recently 
released it to a few companys to use in their modems.

--  
| Erik Jacobson, SysOp of The Dark Knight's Table BBS                |
| (612) 938-8924 (HST V32) Minnetonka, Minnesota                     |
| Domain: Erik@tdkt.kksys.mn.org -- It is impossible to make         |
| anything fool-proof...because fools are so incredibly ingenious.   |

bkc@am.dsir.govt.nz (Barney Campbell) (05/09/91)

tim@dal.fsd.mot.com (Tim Dawson) writes:

> ...  The problem is simply this: V.32 knows 9600 and 4800 baud - - - -
> PERIOD!  If you train down to 4800 and then retrain again and 4800 for
> some reason is not clean (line hit, etc) V.32 standard says to
> DISCONNECT - they are incapable of continuing from this point, and
> also cannot train back up to 9600 once fallback has occured.  This is
> not a problem with a vendor, this is a problem with a protocol - V.32
> does not have the same kine of robust error recovery and correction as
> PEP. ...  

Presumably this is the kind of problem Microcom is seeking to give a
solution for by providing MNP class 10 (Adverse Channel Enhancements [TM])
(including speed recovery) in for example the QX/4232hs V.32 modem.

Barney Campbell 

brian@telebit.com (Brian Lloyd) (05/09/91)

bkc@am.dsir.govt.nz (Barney Campbell) writes:

>tim@dal.fsd.mot.com (Tim Dawson) writes:

>> ...  The problem is simply this: V.32 knows 9600 and 4800 baud - - - -
>> PERIOD!  If you train down to 4800 and then retrain again and 4800 for
>> some reason is not clean (line hit, etc) V.32 standard says to
>> DISCONNECT - they are incapable of continuing from this point, and
>> also cannot train back up to 9600 once fallback has occured.  This is
>> not a problem with a vendor, this is a problem with a protocol - V.32
>> does not have the same kine of robust error recovery and correction as
>> PEP. ...  

>Presumably this is the kind of problem Microcom is seeking to give a
>solution for by providing MNP class 10 (Adverse Channel Enhancements [TM])
>(including speed recovery) in for example the QX/4232hs V.32 modem.

>Barney Campbell 

MNP 10 does not address the issue of the quality of the underlying
data pump.  This leads to a process whereby someone attempts to "cure"
the problem with a link by adding an error correction scheme.  This
will serve to buy you a few db but it won't solve the problem when the
data pump has insufficient S/N to retain synchronization.

I like V.32 and V.32bis (especially when I am running SLIP or PPP).
They work great over most landlines in the United States.  PEP is
still a win when the link is marginal as in a cellular phone or an
international call. 

Sometimes the right tool is a rifle and sometimes the right tool is a
shotgun.

Brian
-- 
Brian Lloyd, WB6RQN                              Telebit Corporation
Network Systems Architect                        1315 Chesapeake Terrace 
brian@napa.telebit.com                           Sunnyvale, CA 94089-1100
voice (408) 745-3103                             FAX (408) 734-3333