| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | DYnalinks V34+ modems |
On 08-25-96 Bill Grimsley wrote to Michael Raiteri... BG> At the risk of offending some Maestro owners (so what else is new?), BG> my BG> experiences with Banksia's V.34 modems have generally been BG> good, but some Maestros appear to suffer from the most BG> peculiar problems, such as their oft-faulty piezo BG> "speakers" which, for some inexplicable reason, stuffs up BG> high-speed connects. Their QA could do with some BG> improvement, IMO. Hmmm thats bad. My ISP is about to ditch Banksia and Microcom modems in favour of a total Maestro setup. I hope it doesn't affect me too much. BG> MR> BBS has. The BBS is BG> MR> QUANTUM LEAP ph 07 3805-1180. BG> BG> There is no mention of the brand in his log-on screens, BG> although the Courier's aftercall stats indicate that it's BG> probably a Rockwell-based V.34 modem, but neither a Spirit BG> Viper nor a NetComm (no LAPM/SREJ). I'd guess a Maestro? Believe it or not the sysop finally found time to reply and he said that its a Netcom V34 Roadster. Interestingly enough he said nearly all the high rate connects vary between 19200 and 26400. BG> MR> I'm seeing /ARQ connects alright but monly for 25 seconds :( BG> BG> In that case, it could well be that he has retrains BG> disabled at his end (this was unfortunately the default BG> with earlier Maestros, for example), and when your Dynalink BG> requests a retrain, the remote can't respond, then drops BG> carrier. Adding %E2 or %E3 at his end should fix that BG> problem (if that's the cause). Does the Netcom V34 Roadster have the same defaults. BG> MR> Dynalink couldn't shed any light on it. Their support reckon they BG> have never had the need to disable the V42 detect phase. BG> BG> They like seeing 28800/NONE connects, do they? What a BG> bunch of morons. The simple fact is that some Rockwells DO That I can't disagree with :) BG> have a dodgy implementation of V.42, which is why disabling BG> the USR's V.42 _detect_ phase solves that problem (thereby BG> forcing a non-negotiated LAPM connect). It's a similar BG> problem to that of some Hayes models with their faulty 3429 BG> symbol rate, requiring said symbol rate to be disabled when BG> calling these modems, otherwise they simply won't connect. BTW what specific Rockwell type modems do need those disabled so I can be on he lookout for them. BG> To avoid further long-winded comparisons between the BG> Dynalink's and the Courier's S-registers, here are the lot. BG> Please save this chart for future reference, and refer to BG> S27 in particular... <<<<<<<<<<<<< CHOMP CHOMP >>>>>>>>>>>>>>>>> Exactly my point - there are two specific different S registers one for Disabling V42 Detect Phase and one for Disable V42. Dynalink only has S15=128 =disable V42. I'm not saying that it's not meant to be disable V42 Detect Phase it's just thats its pretty ambiguous. BG> I'm buggered if I know either, but there's a pretty easy way to find BG> out; BG> simply call Dave's Courier with S15=128 in your dialling BG> string, and if it connects with LAPM, that bit only BG> disables the detect phase. If you see an MNP4 connect, it BG> has disabled LAPM only, and if you see no error correction BG> at all, then it will have quite obviously disabled V.42 BG> altogether. I did like you said. I dialled David's BBS with a dial string of AT&F1S15=128DT and i got the following connect 31200/ARQ/V32/MNP/MNP5 How do you interpret that? Cheers Mike ___ * OFFLINE 1.56 --- Squish/386 v1.11* Origin: JabberWOCky BBS +61 7 3868 1597 (3:640/305) SEEN-BY: 50/99 620/243 623/630 625/100 640/201 206 230 305 306 311 702 820 SEEN-BY: 640/821 822 823 829 690/660 711/401 409 410 413 430 808 809 899 932 SEEN-BY: 711/934 712/515 713/888 714/906 800/1 @PATH: 640/305 820 711/409 808 934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.