Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!sun-barr!lll-winken!ncis.tis.llnl.gov!blackbird!lriggins From: lriggins@blackbird.afit.af.mil (L. Maurice Riggins) Newsgroups: comp.dcom.modems Subject: Re: Practical Peripherals 9600 SA (long) Summary: Misunderstandings - not bugs Keywords: Make that "ultra" long :-) Message-ID: <1796@blackbird.afit.af.mil> Date: 9 Dec 90 00:26:50 GMT References: <28692@usc> Distribution: na Organization: Air Force Institute of Technology; WPAFB, OH Lines: 271 I don't know where to really begin a reply to this, but it's one of the best examples I've seen for the netnews advice to wait a day before flaming! A short summary of the article reveals the writer is terribly frustrated. I cannot duplicate any of his problems. They may be real (he was too angered to provide his firmware revision) or they may be self-inflicted (he's done an awful lot of register manipulation). One of the problems seems to be that he is setting configuration one way with S-registers and another way with AT commands. Despite the length of this reply, prospective PM9600SA buyers may find it interesting. Anyway, here's his article and my reply: In article <28692@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: |Long, but informative discourse on Practical Peripherals 9600SA modem |follows: (includes nasty [and greatly detailed] bug reports) ^^^^^ ^^^^^^^^^^^ that's for sure! misunderstandings? |^L |After a recent call to my friendly (yeah, right) system operator, I ^^^^^^^^^^^^^^^^^^^^^ I wonder why? |decided to try something on my PPI 9600SA modem. By changing some S |register settings, I was finally able to connect at 2400 and 1200! | |Before you call me a BONEHEAD, read on . . . ^^^^^^^^ Is HOTHEAD more descriptive? Before I begin, let me just state that my firmware revision is 1.16. I can also add that I have my telecomm software set at 38400 baud and am using CTS/RTS hardware handshake. With all the modem settings and registers set to factory defaults, I regularly connect with v.32 with MNP only, v.42 HST at 2400 baud, and non-protocol 2400 and 1200 baud modems, letting the PM9600SA successfully negotiate these weird connections. | |I gave the command "at &q0" to disable all error correction, because the |1200 and 2400 bps modems that I was calling don't support error |correction. Voila, my 9600 bps modem that never worked before at 1200 |or 2400 bps now works just fine! But wait, the problem is not solved. | |When I call a modem that doesn't have error correction, and I have the |registers set as follows: s36=5 or s36=7, s48=128; the feature |negotiation SHOULD be disabled - immediate fallback to the setting in |s36 SHOULD occur. This setting for s36 indicates that MNP2-4 SHOULD be |attempted, and if this fails either a standard asynchronous (direct |mode) connection SHOULD occur for s36=5, or a (normal mode) connection |with ASB automatic speed buffering SHOULD occur for s36=7. (This is all |assuming that the &q setting is &q5. It was.) You didn't issue AT&Q5 AFTER you set S48 did you? If you did, you reset the registers back to the default values for v.42 operation (which is what AT&Q5 does). I don't think you understand what the AT commands do, because you could've saved all this register setting with a couple of AT commands. If you don't trust the modem to negotiate, you can set the connection with AT commands. There are 4 AT&Q commands that cover the 3 possible modes of operation. For non-protocol connections (such as those to the 1200 and 2400 baud modems), AT&Q0 and AT&Q6 set operation to non-protocol. They do not change registers S36 (error-checking), S46 (compression), or S48 (negotiation) because they just plain ignore them... they aren't appropriate. The only difference between &Q0 and &Q6 is that &Q6 lets you use hardware handshake and set your terminal/ host (called DTE) speed to one value and leave it there, regardless of what the modem to modem (called DCE) speed is. With &Q0 set, you must always set your DTE to modem connection the same as the modem you will be accessing. For MNP connections (to modems such as 2400MNP or 9600 baud MNP), AT&Q8 sets operation to MNP with fallback to ASB Asynch by changing S36 to 7. &Q8 doesn't effect S46 because compression or no compression are valid options. It also doesn't effect S48 because that only deals with how v.42 negotiates. For v.42 connections, AT&Q5 sets operation for v.42 error-checking protocol by setting S36 to 7. This means that it tries LAP-M first and if it fails, fall back to MNP (this is required in the CCITT specification of v.42). It does not effect S46 because compression or no compression are valid options. It does set negotiation to meet v.42 specs (try LAP-M first then fallback) by setting sS48 to 7. If you don't want to follow International Standards, you can, after using AT&Q5, set S48 to either go with LAP-M without negotiating or skip LAP-M and go to the fallback specified in S36 (which must also be changed away from International Standard AFTER using AT&Q5). | |THE ABOVE DOESN'T HAPPEN. Upon connection, the light for error ^^^^^^^^^^^^^^^^^^^^^^^^^ Yes it does if you leave the registers alone... |correction is lit, even though the answering modem doesn't have error |correction. This indicates that the Practical Peripherals 9600SA modem |has defective control software. The modem spits out terrible noise for |10-15 seconds, and then finally looses the connection. The PPI firmware |authors are the BONEHEADS, and not I. You don't say how the light is lit. The EC light has 4 states: OFF when the connection is non-error control, non-buffered RED when the connection is non-error control, but ASB YELLOW when the connection is MNP (the manual calls this color orange) GREEN when the connection is LAP-M (v.42) If you are using &Q6, or you've fallen back from &Q5 or &Q8 to some combination that results in non-protocol ASB operation the EC light is red. If you are using &Q0 or fallen back to non-ASB, the EC light is OFF. I've tried it with your S36/S48 register settings and that's the way it works... as it is supposed to. (BTW, the "noise" is negotiation in progress). Also, the DC light has only 2 states: OFF when the connection is not using compression RED when the connection IS using compression. Which compression depends upon whether MNP or v.42 error checking is used. | |In addition, I found some more bugs/features. If you give the command |"at &q0" followed by "at &q5", or "at &q8" followed by "at &q5", the |values of the s36 and s48 registers will be set to 7, regardless of what |was previously set in them. I think this is a bug. Maybe PPI thinks it |is a feature. In any case, you must give a separate command AFTER |"at &q5" to set the s36 and s48 registers as desired. It doesn't matter what you or PPI think... &Q5 selects v.42 EC, which, by CCITT definition, attempts to fall back to MNP (S36=7 and S48=7). You can override the specifics after selecting. But if you don't want v.42 to begin with, why in the hell are you using &Q5 in the first place? The only bug here is in your logic. | |There is another bug. This cannot possibly be construed as a feature, |no matter how hard you try. If you give "at &q0", or "at &q8", followed |by "at &q5", YOU WILL NEVER AGAIN ACHIEVE A CONNECTION WITH ERROR |CORRECTION OR DATA COMPRESSION OF ANY TYPE. It doesn't matter what the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I tried it both ways and I DID get a normal EC/DC connection. With all the dinking around with registers you've done, you probably had something set weird. No bug here, either. |settings in the relevant S registers are. You have to cycle the power, |if you ever want to get a connection with EC or DC again. Why cycle power? Have you heard of the command ATZ? Unfortunately, that won't help if you are saving your dinking with the &W commands. But there is hope... there's a command to restore factory defaults... AT&F I suggest you use it. | |There is yet another bug. Again, the modem just doesn't work as |advertised. If you give "at &q8 s46=136" you SHOULD get a MNP 2-4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TRUE |connection. If you give "at &q8 s48=138" you SHOULD get a MNP 5 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you mean s46=138, TRUE again |connection. In fact, you don't get either. I was calling a modem that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NOT TRUE... works for me as advertised! Again, you may have left something in a weird state from previous dinking. |had MNP5, and the connection would be made WITHOUT ERROR CORRECTION (to ^^^^^^^^ Are you sure the modem you were calling had MNP5 and it was enabled? |say nothing about data compression). You can work around this one, by |first giving "at &q5", and then "at s36=7 s46=136 s48=13?". However, |there is no excuse that I will accept for "at &q8" not working as |advertised. Well, you really are trying to convince me you ARE a BONEHEAD. If you call setting S36 to 7 (the factory default value) a "work-around," I know you've really screwed it all up! I assume you really didn't mean you are setting S48 to 13? but to 128? You're using &Q5 to set everything up one way and then going in with the registers to undo it all another way. Why not just use the correct value for &Q in the first place? | |The good news is that my testing and evaluation has led me to believe |that the filtering, modulation, and demodulation functions of the PPI |9600SA modem work well. They appear to work well at 1200, 2400, and ^^^^^^^^^^^^^^^^^^^^^^ Finally, we agree on something! |9600 bps speeds. The bad news is that the control software in the |modem really sucks; it is full of bugs. ^^^^^^^^^^^^^^^^^^ ^^^^ If you don't understand it. Mine isn't, but then I understand it. | |I heard a rumor about a new software version, 1.18, from PPI. I don't |know what bugs this revision will correct. I don't know if I should |take another chance. If the PPI software engineers were boneheads, and |didn't correct these bugs, how can I trust that the next firmware will be |any better. If the PPI testing department engineers didn't find the |bugs, and are thus boneheads, how can I trust that they will find the |bugs in the next version to be released. If the PPI marketing |deptartment is staffed by boneheads, and says "ship it", even with the |bugs, how can I trust that PPI will ever ship a quality product? If you lash out like this whenever you don't understand something, I can see why the local sysop isn't so friendly! Lighten Up! | |I want the price of a PPI modem, but I also want quality. I guess I am |willing to pay for quality. If I ever find it, I'll get on here and |recommend it. Instead of paying for quality you don't need, why not pay for some education? | |In the meantime, I must recommend AGAINST the PPI 9600SA. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Well I sure can recommend it... so can others! Rather than all this, why don't you tell us your ROM revision number, and maybe some other pertinant data such as serial port settings, pin out, handshake, etc? Hell, none of us know it all. There's no shame in not understanding something... but there is in proving you don't by trashing others to cover it up. | |-- |favourite oxymorons: student athlete, military justice, mercy killing |Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh One last postscript: One thing new users of high-speed modems may need to check is the timeout value of the system they are calling into, particularly if it is using a low-speed, non-negotiating modem. The v.32 modem will take a long time negotiating. If the answering non-negotiating modem has the S7 register set to too low a value (some are set as low as 15-20 seconds) it may hang up before the v.32 modem finishes negotiating. Also, some v.32 modems take 5-10 seconds between the time they raise CARRIER DETECT and the time they send the CONNECT [Baud Rate] and let data start to flow. This is particularly true if they had to fallback during negotiation. In the meantime, the answering non-negotiating modem saw CARRIER DETECT back when the calling modem did and the system has been waiting for some kind of input (Return or Break) to start up. Sometimes the system (BBS software or whatever) times out before the v.32 user can even login. The PM9600SA isn't the only v.32 modem that experiences this. Our dial-ins here (UDS MNP models) experience this also with users who connect in at 1200 or 2400 non-protocol. They complain because they pound the Enter key for 5 or 6 seconds after getting a CONNECT before our UDS modems connect with the Ethernet and pass their signals. But if they wait too long (8-9 seconds) the system times them out and hangs up the modem (we're working on it). Ideally, the timeouts should be increased, so the v.32 has time to connect. But failing this, the use of AT&Q6 (or AT&Q0) for non-protocol systems (or AT&Q8 for MNP systems) will cut down the time needed to establish a connection and result in fewer disconnections. That's why Ken found success with &Q0. Anyway, there are a lot of other issues new users of high speed modems should be concerned with... like getting rid of Xon/Xoff and the proper use of hardware handshaking. -- Maurice INTERNET: lriggins@blackbird.afit.af.mil (129.92.1.2) Opinions expressed here do not reflect those of my employer nor constitute an official position of any U.S.Government agency.