kjh@pollux.usc.edu (Kenneth J. Hendrickson) (12/03/90)
I have called up the Practical Peripherals BBS, and read the messages there in the Tech Support section. (I also posted a message much like my review posted here, detailing the horrendous performance of the 9600SA in V.22bis 2400 bps mode.) There was at least one other person who had the same problem that I had. He couldn't connect to other modems at 2400 bps with his 9600SA. However, there is at least one person on this newsgroup who has no problems calling up 2400 bps modems. My current conclusions and recommendations: Some 9600SA's don't work at all at speeds <= 2400 bps. I can't recommend the Practical Peripherals 9600SA. I am willing to pay a lot more, for a modem that actually works. -- favourite oxymorons: student athlete, military justice, mercy killing Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (12/08/90)
Long, but informative discourse on Practical Peripherals 9600SA modem follows: (includes nasty [and greatly detailed] bug reports) After a recent call to my friendly (yeah, right) system operator, I 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 . . . 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.) THE ABOVE DOESN'T HAPPEN. Upon connection, the light for error 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. 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. 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 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. 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 connection. If you give "at &q8 s48=138" you SHOULD get a MNP 5 connection. In fact, you don't get either. I was calling a modem that had MNP5, and the connection would be made WITHOUT ERROR CORRECTION (to 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. 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 9600 bps speeds. The bad news is that the control software in the modem really sucks; it is full of bugs. 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? 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. In the meantime, I must recommend AGAINST the PPI 9600SA. -- favourite oxymorons: student athlete, military justice, mercy killing Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
lriggins@blackbird.afit.af.mil (L. Maurice Riggins) (12/09/90)
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.
reich@well.sf.ca.us (Richard Reich) (12/09/90)
Did you _ask_ if any of the bugs in our ROM are fixed at 1.18? (The 1.18 ROM is not a rumor -- if you ask, they will send it to you.) -r
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (12/14/90)
Recap: I got a 9600 SA for evaluation from a local vendor. It didn't work as advertised. I posted several messages to the net detailing problems with the 9600 SA, including some bug reports that I found. I was criticized (and corrected on some counts) by some people. However, a representative of PPI did indicate on the net that my bug reports were valid. I got a copy of the newer version of the software for the 9600 SA. I originally had v 1.05, and PPI sent me 1.18 upon my request. They also promised that they would continue to send new versions of the software - if they found and corrected any bugs - upon request. The newer software does in fact fix the bugs I previously reported. The modem seems to work well, but I still have many tests I'd like to do that I won't have time for until next week. More reports forthcoming. -- favourite oxymorons: student athlete, military justice, mercy killing Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
perez@andromeda.rutgers.edu.rutgers.edu (William Perez) (12/15/90)
Hi, I've been watching discussion on this modem and am considering buying it.
First of all, I used to have the 2400SA (no MNP) and hated it. Everytime my
refrigerator or lamp would go on/off, I'd get junk online and download errors.
To add, I'd get a random greek "pi" symbol. I got a new cable and no luck.
Tech support couldn't figure it out over the phone so I returned it for credit.
Perhaps I needed MNP.
Anyway, I've been watching bug reports on here and have a few questions...
1. What's the current price of this modem? I saw $499 in MacUser.
2. I know it has V.42 but how about V.32? V.42 incorporates MNP if the
connecting modem does't have V.42?
3. Are the bug fixes OK now?
4. Does it come with a hardware handshake cable?
Thanks!
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<>William Perez <> Internet: perez@andromeda.rutgers.edu <>
<>RPO 0043 POBox 5063 <> America Online: WilliWonka <>
<>New Brunswick, NJ 08903 <> <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>aburt@isis.cs.du.edu (Andrew Burt) (12/17/90)
In article <Dec.14.16.27.47.1990.25000@galaxy.rutgers.edu> perez@andromeda.rutgers.edu.rutgers.edu (William Perez) writes: >Hi, I've been watching discussion on this modem and am considering buying it. >1. What's the current price of this modem? I saw $499 in MacUser. Various mail order outfits have it at $450, but make sure they have units before you order -- they're in high demand right now. >2. I know it has V.42 but how about V.32? V.42 incorporates MNP if the > connecting modem does't have V.42? V.32, V.42, V.42bis, MNP2-5. >3. Are the bug fixes OK now? The 1.18 proms I received fixed all the problems I was having with the 1.05. Looking good... >4. Does it come with a hardware handshake cable? Only cable mine came with was a phone cable, but ask the sales people you order from... -- Andrew Burt uunet!isis!aburt or aburt@du.edu "Kwyjibo on the loose!"
kenh@hscfsas1.harvard.edu (Ken Hancock) (12/21/90)
>Various mail order outfits have it at $450, but make sure they have units >before you order -- they're in high demand right now. Best price I've seen is about $490. Any sources in particular for the $450 area? Also, ZOOM has just come out with a V32/42/42bis modem. Anyone have any experiences with them? Ken -- Ken Hancock | INTERNET: kenh@hscfsas1.harvard.edu Isle Systems | Disclaimer: My opinions are mine, Macintosh Consulting | your opinions are yours. Simple, isn't it?
cooper@plains.NoDak.edu (Jeff Cooper) (12/21/90)
In article <5134@husc6.harvard.edu> kenh@hscfsas1.harvard.edu (Ken Hancock) writes: > > > >Also, ZOOM has just come out with a V32/42/42bis modem. Anyone have >any experiences with them? > >Ken > There is a review of the Zoom modem in one of the Mac magazines (MacWorld, I think) and the reviewers loved it. They only tested two modems with 42bis (the other was a Hayes, I believe) and the Zoom was just about as good as the Hayes in almost every test and for $190 bucks you really can't go wrong. I've already ordered mine... :-) (now, if my NeXT would hurry up and get here...) --- "Life IS pain Princess, anyone who tells you different is selling something." - The Dread Pirate Roberts Jeff Cooper cooper@plains.nodak.edu
larry@nstar.rn.com (Larry Snyder) (12/21/90)
kenh@hscfsas1.harvard.edu (Ken Hancock) writes: >>Various mail order outfits have it at $450, but make sure they have units >>before you order -- they're in high demand right now. >Best price I've seen is about $490. Any sources in particular for >the $450 area? >Also, ZOOM has just come out with a V32/42/42bis modem. Anyone have >any experiences with them? Tech Data now carries a Sharp 9600 baud modem with MNP 5 - dealer price is $289. I wonder if this modem is V.32? -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar.rn.com, uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
yee@pawl.rpi.edu (Lester W Yee) (12/21/90)
Quite recently I brought a Practical Peripheral 2400 baud pocket modem at the local Egghead store. It works fine, I also owned a PP 1200 modem from them, I run PCPLUS and there is almost a transparent transfer of 1200 to 2400 baud modem. I strongly recommend it for people who want 2400B and want it cheaply. I brought it on sale for $109. It comes with a 5 year waranty. I have a question: Sometimes when there is a long pause, I can see garable characters on the screen. The computer is waiting for the otcomputer (host) computer to get data. I see garable characters, but it's like they are not there. ON WWIV BBSes which I call, after seeing the garable string, I immediately check the message that I was typing in, and the characters weren't there. It's sort of like these were invisible characters, that MY computer saw, but the host computer didn't see anything strange. What is this really? (computer, I'm running 386/33 mhz, with Windows 3.0 in enhanced mode). Kind of strange... I don't know what to make of it, other than that the speed of the computer is seeing idle characters on the serial port and reporting them as inputs from the host. HELP! I have never try to run PCPLUS outside of windows with my new modem. Don't know if that will help. yee@pawl.rpi.edu -- ------------------------------------ Signature File Test... Name: yee@pawl.rpi.edu
tnixon@hayes.uucp (12/21/90)
In article <~+L^*1*@rpi.edu>, yee@pawl.rpi.edu (Lester W Yee) writes: > I have a question: Sometimes when there is a long pause, I can see garable > characters on the screen. The computer is waiting for the otcomputer > (host) computer to get data. I see garable characters, but it's like they > are not there. ON WWIV BBSes which I call, after seeing the garable string, > I immediately check the message that I was typing in, and the characters > weren't there. It's sort of like these were invisible characters, that MY > computer saw, but the host computer didn't see anything strange. V.22bis modems use frequency division multiplexing to acheive full-duplex transmission. The calling modem transmits on the low frequency band (1200Hz carrier), and the answering modem transmits on the high frequency band (2400Hz carrier). The calling modem is thus more in the center of the channel, where the amplitude response and delay is more "flat"; the high channel, transmitted on by the answering modem, is generally somewhat more impaired and more susceptible to noise. It is therefore not uncommon for you to receive garbage characters that the other end doesn't see -- because they weren't generated by you and ECHOED by the other side, but were generated by noise in the high band which only the reciever on the high band (in your calling modem) would see. You could just have a slightly noisy phone line, or a slightly less than perfect modem (no modem is really perfect in terms of never seeing errors), etc. It's nothing to do with you software, I'm pretty sure. It is these minor, annoying line noise problems that modem-based error control (V.42, MNP) was designed to eliminate. -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
sysop@mixcom.UUCP (System Operator) (12/22/90)
In article <5134@husc6.harvard.edu> kenh@hscfsas1.harvard.edu (Ken Hancock) writes: >Best price I've seen is about $490. Any sources in particular for >the $450 area? I paid $436 COD from Computer Discount Warehouse (Chicago). 800-726-4239 With the 1.18 ROM the modem seems to work O.K. now. I had endless problems with the 1.05 revision ROM, and with PPI tech support telling me the problems were caused by me. After I demanded to speak with the manager of tech support, I got the 1.18 ROM. The moral is: The modem seems to be O.K. with the 1.18 revision ROM, but tech support leaves "a little" to be desired. Dean Roth -- Milwaukee Information eXchange (MIX), public access *NIX/Usenet MIX Communications, P.O. Box 17166, Milwaukee, WI 53217
al@qiclab.uucp (Al Peterman) (12/22/90)
In article <5134@husc6.harvard.edu> kenh@hscfsas1.harvard.edu (Ken Hancock) writes: >Best price I've seen is about $490. Any sources in particular for >the $450 area? Computer Discount Warehouse 1-800-4CDW. $439 plus shipping & COD came to $450.37 total! -- Alan L. Peterman (503)-684-1984 hm cse.ogi.edu!qiclab!al
aburt@isis.cs.du.edu (Andrew Burt) (12/23/90)
In article <128@mixcom.UUCP> sysop@mixcom.UUCP (System Operator) writes: >With the 1.18 ROM the modem seems to work O.K. now. >I had endless problems with the 1.05 revision ROM, >and with PPI tech support telling me the problems were >caused by me. After I demanded to speak with the manager >of tech support, I got the 1.18 ROM. The moral is: >The modem seems to be O.K. with the 1.18 revision ROM, >but tech support leaves "a little" to be desired. Odd... I found them to be very helpful. I was on the phone with them for a couple hours (at their expense) while we tried various things. I suspect the problem is that they find (like most tech support places) that the problems almost always ARE caused by the user, so resorting to hardware fixes is usually the last resort. For those of us who are pretty convinced we have a genuine problem, not just a settting wrong 'cause we didn't RTFM, I suggest mixing discussions of the problem with a little personal background: My problem is "X", and I'm reasonably convinced I've tried all the "usual" solutions, I'm a Unix kernel hacker by trade, so I'm pretty technically competent, blah blah... Working that in *politely* is hard, but I find most tech spt. folks respond in kind. But tech spt. people have their procedures of "dumb user" things too try, and sometimes that is the problem (mostly, I'm sure, for avg users). Though there are places that won't bend (e.g., Borland), PPI skipped most of the "dumb user" things when I "let slip" what my background was. It was one of the few times tech spt. didn't "insult my intelligence" with questions like "is it plugged in", etc. So I was extremely pleased with PPI's support. Just have to bear in mind who tech spt. is geared to help, and it ain't wizards. -- Andrew Burt uunet!isis!aburt or aburt@du.edu "Kwyjibo on the loose!"
Philip_Dath@f170.n771.z3.fidonet.org (Philip Dath) (12/23/90)
FSC-Control: EID:d3cc 159815a0
FSC-Control: PID: RA 0.04 1114
LY> I have a question: Sometimes when there is a long pause, I
LY> can see garable
LY> characters on the screen. The computer is waiting for the
I wouldn't woory about this too much. It is most probably line
noise. I experience this problem sometimes (as I guess most users do).
Funnily enough, I find it is worst while it is raining!
---
* Origin: Waikato Amiga CBCS Hamilton *NZ* 64-71-466-918 (3:772/605)
SEEN-BY: 770/101 771/110 170 180 772/20 50 140 774/501 605
FSC-Control: PATH: 774/501 772/20 771/170 kenh@hscfsas1.harvard.edu (Ken Hancock) (12/23/90)
In article <7264@plains.NoDak.edu> cooper@plains.NoDak.edu (Jeff Cooper) writes: >There is a review of the Zoom modem in one of the Mac magazines (MacWorld, >I think) and the reviewers loved it. They only tested two modems with >42bis (the other was a Hayes, I believe) and the Zoom was just about as >good as the Hayes in almost every test and for $190 bucks you really can't >go wrong. I've already ordered mine... :-) (now, if my NeXT would hurry >up and get here...) >cooper@plains.nodak.edu Except the modem I was asking about is ZOOM's 9600 V32/42/42bis modem. The modem reviewed in MacWorld is a 2400 with V42bis piggybacked on. Ken -- Ken Hancock | INTERNET: kenh@hscfsas1.harvard.edu Isle Systems | Disclaimer: My opinions are mine, Macintosh Consulting | your opinions are yours. Simple, isn't it?
squishy@casbah.acns.nwu.edu (Shishin Yamada) (12/31/90)
Hi, could someone please post info about the Practical Peripherals 9600 SA? Could you post some info about connection to UNIX and throughput. I am an undergraduate senior in electrical engineering, and I am looking into connecting to UNIX, Compuserve, and Prodigy, as well as to other modems. Most of the connections will be over local lines. I hope to get away from my old USR1200. Almost all of our university's (prime host) modems are USRobotics 9600 HST (or Dual Standards) since USR builds them about 3 miles away from Northwestern U. How does the PPI fair with USR's? I saw them for $485 at Elek-Tek in Chicago. Does it also support 300/1200/2400? I need 300 for the local library database (Haha!). And 2400 for CI$/Prodigy. Most of the work on UNIX is either interactive or Zmodem. What kinds of download efficiencies do you think I could expect? Thanks in advance! and Happy New Year! (: ----------------------------------------------------------------------- Shishin "Squish" Yamada Northwestern University (Evanston, IL) -----------------------------------------------------------------------
squishy@casbah.acns.nwu.edu (Shishin Yamada) (01/20/91)
Hello out there in netland: I recently jumped up from a USR 1200 Sportster to a Practical Peripherals 9600SA. Mostly, I call to our universities Sun SPARC running BSD UNIX v4.3 using USR V.32 connections. My questions are: I connect at 9600 with data and error correction on (EC shows green, I assume thats LAPM, and DC shows red, I assume thats V.42). My overall throughput increases as time goes. At 100Kbytes, a few seconds into transfer, output jumps to about 850 bytes/second. Doesnt it go faster? I heard numbers up to 2000 ch/sec. Also, it seems to be having troubles connecting to another service, namely Prodigy. I dont know why? I am trying to have it do the proper negotiation. Also, my Mac programis not able to keep up with the modem in terms of text scrolling. Any suggestions of comm programs would be appreciated. Any replies would be much appreciated. Thanks in advance! ------------------------------------------------------------------------- Shishin Yamada Northwestern University EE class of 91 Evanston, IL -------------------------------------------------------------------------
squishy@casbah.acns.nwu.edu (Shishin Yamada) (01/20/91)
Oh, I forgot to add. Does anyone know which are the better ROM versions. I find I have version 1.18. Should I call PPI or e-mail? -Shishin Yamada
tnixon@hayes.uucp (01/24/91)
In article <2786@casbah.acns.nwu.edu>, squishy@casbah.acns.nwu.edu (Shishin Yamada) writes: > Also, it seems to be having troubles connecting to another service, > namely Prodigy. I dont know why? I am trying to have it do the proper > negotiation. Prodigy doesn't support error control, and they don't like to see the detection patterns sent by error-control modems. Use "&Q0" in your initialization string or program it in your modem's non-volatile memory; this should help you to connect more reliably to Prodigy. > Also, my Mac programis not able to keep up with the modem in terms > of text scrolling. Any suggestions of comm programs would be appreciated. Smartcom II for the Macintosh from Hayes is very fast and can keep up with just about any modem. -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
squishy@casbah.acns.nwu.edu (Shishin Yamada) (01/24/91)
In article <3743.279dc6ae@hayes.uucp> tnixon@hayes.uucp writes: >In article <2786@casbah.acns.nwu.edu>, squishy@casbah.acns.nwu.edu >(Shishin Yamada) writes: (Toby Nixon) replys: > >> Also, it seems to be having troubles connecting to another service, >> namely Prodigy. I dont know why? I am trying to have it do the proper >> negotiation. > >Prodigy doesn't support error control, and they don't like to see >the detection patterns sent by error-control modems. Use "&Q0" in >your initialization string or program it in your modem's >non-volatile memory; this should help you to connect more reliably >to Prodigy. > Thanks Toby. You hit it right on the nose. Prodigy doesn't support flow control. It was SIMPLY corrected by adding the string "&Q0." Prodigy tech support is VERY familliar with this as it seems to affect practically all error correction/data compression type modems (MNP5 or V.42bis). Prodigy, by the way, doesn't support anything above straight 2400 baud. >> Also, my Mac programis not able to keep up with the modem in terms >> of text scrolling. Any suggestions of comm programs would be appreciated. > >Smartcom II for the Macintosh from Hayes is very fast and can keep >up with just about any modem. > Ahh, I've heard many good things about SmartCom II. I don't think it does, but could you tell me if it supports X-windows? Our universities Sun Sparcs is where I do all my work. By the way, I am now more broke as your typical techie college kid. I wish Hayes supported Academic Pricing like USRobotics, Apple, IBM, Zenith, and Microsoft do at our school. Hopefully I'll get a good term program when I graduate. Most of the problem occured with the back scroll buffer on my mac, so I re-worked some of its dynamics to make it faster. Now it's OK. Overall, getting used to 9600 baud is a big switch from the safe slow modems. There are SO many S registers and other soft switches to work with. Now that I am more aquainted, it is much better. I have found the PPI 9600SA to be quite good after all, and I have no complaints. I have found that for my uses, the reason I had not seen it go over 9600 bps is because our universities computer's network gateways at set to go 9600 at most. Henve I only see transfers around 900 chars/sec. I guess I got a modem technology a little ahead of our school. Anyways, I'm going to complain to them for a faster gateway. At least it is not the PPI's problem. Also, I had problems with quotation marks that was because of faulty INITs and CDEVs background programs on my MacIntosh. Thanks again! Your replies were very helpful! 8-) -------------------------------------------------------------------- Shishin "Squish" Yamada Squishy@casbah.acns.nwu.edu Northwestern University Electrical Engineering Class of '91 --------------------------------------------------------------------