For the A-open FM56-P use the beta driver on the web site
http://www.aopenusa.com
At 11:23 99-06-17 , you wrote:
>Rather than complaining about faulty modem code, I think the more=
productive
>thing to do is directly address client modem issues and find out just where
>all the problems lie. Unfortunately, I can't give detailed information at=
this
>time but I think this is a start. I do realize that a PM3 can't be=
everything
>to everyone, I think the problem is more along the lines of producing modem
>code that is more accommodating to modems that are outside of V.90 spec.
>
>On a side note, Some of our techs say that the PM3's are "Too Aggressive"=
in
>determining connect speed, (IE. Letting a client modem connect too fast for
>the line conditions.) so they have to manually kick down the top speeds for
>stable connects. This seems to be a reoccurring thing. Is there a way for=
the
>modem code engineers to make the server side modems behave more=
conservatively
>when it comes to initial speed handshaking?
>
>All of our PM3A-2T's are running ComOS 3.8.2c2 ... PRI, ESF & B8ZS. I don't
>plan on downgrading.
>
>I would also like to suggest perhaps that Lucent release a white paper
>(Perhaps just specific to Lucent clients?) that
>explains precisely how a chassis negotiates and establishes a V.90=
connection
>with a client modem. What the tolerances are, what tones the server side=
puts
>out and expects from the client modem? Perhaps if the clients can describe=
the
>problems in better detail by using terms that are a bit more technical,=
they
>could aid the modem engineers better.
>
>I do honestly hope that the information below is of some use. Perhaps that
>might persuade the Lucent Modem Code engineers to purchase each one of the
>modems below (If they haven't already) and find out precisely where the
>problems lie.
>
>I have had a discussion with our technical support dept and here is what=
they
>say the majority of the problems are:
>
>Rockwell HCF V.90 code is broken. Won't handshake until you set the
>client
> side to use kFlex only. This is only a workaround.
>
>USR 56k Winmodem Will not handshake properly, slow data xfer when it=
does
>connect.
>
>AOpen 56k's (FM56-P) Only one version of firmware, doesn't appear to=
help
>at all.
> Modem doesn't connect, same phasing problem. Will
>not handshake,
> rapid disconnection's (within secs of establishing=
a
>connection) a
> lot of the time, the modem will just stop=
responding.
>
>Any Cirrus Logic Modem Handshake/phasing problem. Similar to the=
AOpens.
>Will not
> connect. (chipset CL-MD56xx typically)
>
>Any ESS modem No documentation available for modem. Have a
>suspected fix, but
> haven't had the opportunity to test it yet. They
>appear to be
> bastardized USR's.
>
>
>-
>To unsubscribe, email 'majordomo@livingston.com' with
>'unsubscribe portmaster-modems' in the body of the message.
-- C=E9dric Tardif support@destination.ca=20 --=====================_79257652==_.ALT Content-Type: text/html; charset="us-ascii"For the A-open FM56-P use the beta driver on the web site http://www.aopenusa.com
At 11:23 99-06-17 , you wrote:
>Rather than complaining about faulty modem code, I think the more productive
>thing to do is directly address client modem issues and find out just where
>all the problems lie. Unfortunately, I can't give detailed information at this
>time but I think this is a start. I do realize that a PM3 can't be everything
>to everyone, I think the problem is more along the lines of producing modem
>code that is more accommodating to modems that are outside of V.90 spec.
>
>On a side note, Some of our techs say that the PM3's are "Too Aggressive" in
>determining connect speed, (IE. Letting a client modem connect too fast for
>the line conditions.) so they have to manually kick down the top speeds for
>stable connects. This seems to be a reoccurring thing. Is there a way for the
>modem code engineers to make the server side modems behave more conservatively
>when it comes to initial speed handshaking?
>
>All of our PM3A-2T's are running ComOS 3.8.2c2 ... PRI, ESF & B8ZS. I don't
>plan on downgrading.
>
>I would also like to suggest perhaps that Lucent release a white paper
>(Perhaps just specific to Lucent clients?) that
>explains precisely how a chassis negotiates and establishes a V.90 connection
>with a client modem. What the tolerances are, what tones the server side puts
>out and expects from the client modem? Perhaps if the clients can describe the
>problems in better detail by using terms that are a bit more technical, they
>could aid the modem engineers better.
>
>I do honestly hope that the information below is of some use. Perhaps that
>might persuade the Lucent Modem Code engineers to purchase each one of the
>modems below (If they haven't already) and find out precisely where the
>problems lie.
>
>I have had a discussion with our technical support dept and here is what they
>say the majority of the problems are:
>
>Rockwell HCF V.90 code is broken. Won't handshake until you set the
>client
> side to use kFlex only. This is only a workaround.
>
>USR 56k Winmodem Will not handshake properly, slow data xfer when it does
>connect.
>
>AOpen 56k's (FM56-P) Only one version of firmware, doesn't appear to help
>at all.
> Modem doesn't connect, same phasing problem. Will
>not handshake,
> rapid disconnection's (within secs of establishing a
>connection) a
> lot of the time, the modem will just stop responding.
>
>Any Cirrus Logic Modem Handshake/phasing problem. Similar to the AOpens.
>Will not
> connect. (chipset CL-MD56xx typically)
>
>Any ESS modem No documentation available for modem. Have a
>suspected fix, but
> haven't had the opportunity to test it yet. They
>appear to be
> bastardized USR's.
>
>
>-
>To unsubscribe, email 'majordomo@livingston.com' with
>'unsubscribe portmaster-modems' in the body of the message.
--Cédric Tardifsupport@destination.ca--=====================_79257652==_.ALT--
- To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-modems' in the body of the message.