CompuServe Thread

#SupraFaxModem problems

15 messages in this thread
#96628From: john meggieApr 21, 1993 11:16 PM
Can anyone help me with a problem I am having with the SupraFaxModem V.32bis. When I log on to CIS at 9600, I can see the CONNECT 9600 prompt, but my modem displays 2400. My download rates are only 232 chars/sec (same as on my 2400 baud modem). On other BBS's I can download at 1650 chars/sec with the SupraModem. I get the same results with Whap, Autopilot, or JRComm. I have an A2000/040 and the Supra supplied cable. Any is help is very much appreciated.
#96699From: Steve AhlstromApr 22, 1993 11:14 AM
John, There are 2 baud rates you can have — the DCE rate (speed between your modem and your computer) and the DTE (speed between your modem and another). Check your Supra manual, but usually the "CONNECT" rate displayed is DCE — the Carrier rate is that between your modem and the other modem. With my modem, calling a 2400 baud node, I get a connect of 38400 (that's what I've got my DCE set to) and a carrier of 2400. In your specific case, you are more than likely not calling a 9600 CompuServe node. GO PHONES to get the 9600 number(s) for your area. -sja
#96966From: john meggieApr 23, 1993 8:23 PM
Thanks Steve. I did not know there were different nodes for 9600 baud. Everything is fine now :> John
#96702From: Jim Nangano/SYSOPApr 22, 1993 11:23 AM
John, Are you sure that you are calling a 9600-baud Compuserve node? Most of the nodes are _either_ 300/1200/2400 _or_ 9600 baud. Depending on how you have your modem configured, it could very well be reporting the CONNECT 9600 because you are talking to the modem at 9600 baud (between your computer and the modem), while it is connected to CIS at a negotiated 2400 baud carrier. This is why the modem displays 2400. If you enter a "GO PHONES" command on CIS, you can search for a 9600 baud node in your area. Hope this helps…. – BobR
#96967From: john meggieApr 23, 1993 8:23 PM
Thanks Bob. GO PHONES had a 9600 node for me. Nice modem, BTW. I can't read the messages as they scroll by anymore :> John
#96989From: Jim Nangano/SYSOPApr 23, 1993 10:54 PM
John, Glad you resolved the problem. One thing to watch out for with fast modems — you'll never be patient at 2400 baud again and don't ever try to do anything useful at 300 baud – you'll go blind. <grin> – BobR
#97084From: Paul IdolApr 24, 1993 7:42 PM
Doesn't the Amiga serial port only go up to 38.4k? So if I got a 14.4k modem, wouldn't compression be giving me up to 58.6k (or something like that) and thus be causing transmission errors? Does CI$ even have or plan to have 14.4k lines? Paul
#97112From: Jim Nangano/SYSOPApr 24, 1993 11:27 PM
Paul, I have a 14.4k modem and _never_ run my serial port faster than 19200. I never have problems, nor do I ever "peak out" in terms of throughput. CIS currently does not support 14.4, as far as I know. I have no idea what their future plans are. – BobR
#97165From: Ron LegroApr 25, 1993 2:07 PM
I have a 14.4K modem with my serial port set to 38K and I have no problems getting throughput up to 57K — you need to set the serial buffer in prefs to a healthy margin and to set the speed at which the Amiga and modem talk to 57,600. The buffer will handle most overflow situations even when you're running at a full-out 14.4K.
#97226From: Paul IdolApr 25, 1993 9:54 PM
Ah! Thank you. That clears everything up. I'll soon get one. Paul
#97623From: Ron LegroApr 28, 1993 7:05 PM
I should've noted that your mileage may vary, depending on what speed your Amiga runs at. A 7mhz 68000 may not be able to keep up with a 14.4K modem — 9600 may be more like it. But don't be too upset; most PCs can't either, even sometimes after they've been retrofitted with the latest "UART" chips (which we don't need). I told a guy on another BBS that I was downloading via my Amiga and Supra modem and hardware compression with effective cps rates of around 6,000 (not to be confused with bps) and he told me that was impossible. However, I'm not the only one doing it.
#97705From: Paul IdolApr 29, 1993 7:01 AM
Ah. Well, I should be OK w/ an 020, and when I get an 030 accelerator I guess everything will be fine. But if I'm correct, you're saying that the modem/software is able to keep track of how fast the computer is able to receive data at any given moment so as to not overload it? Paul
#97954From: Ron LegroMay 1, 1993 10:25 AM
I'm no expert, Paul, but the Supra has hardware flow control capability (RTS/CTS) which most telecomm software will let you use. The receiving modem must be capable of this. Most modems and software on other platforms uses software flow control (XON/XOFF) — again, so I'm told. The buffer itself isn't "smart" — it just gives the computer time to catch up if it falls behind.
#98001From: Paul IdolMay 1, 1993 5:27 PM
Ah. Well, I guess there are enough people using high-speed modems out there that I should be safe. So expensive though. Paul
#98253From: Graham ReedMay 3, 1993 10:29 PM
I'll just throw in a little more detail on this "hardware flow control," also known as Hardware Handshake, RTS/CTS handshake, or 7-wire handshake. (Yes, this _is_ on a so-called standard interface.) The chips in both the computer and modem which convert bytes of data to bit-streams are called either UARTs or ACIAs. These chips have, typically, two bytes of working space for receiving data: a shift register which is used to convert a bit stream to a whole byte, and a buffer to hold a byte until the computer can read it. When a byte is received in the shift register, it is put in the buffer so a second byte can arrive. If the computer doesn't manage to read the _first_ byte before the second is finished, then the ACIA/UART will turn off one of the handshake lines. These lines connect to the transmitter control on the other chip; when the transmitter sees the wire turned off, it will not send the next byte. This allows the hardware to pace itself to the software's ability to read incoming data without additional software overhead. You may also be familliar with the buffer setting in serial preferences. This buffer is used by serial.device (or equivelent) to hold data as it comes in from the serial port. This allows the computer to receive data when the application program is busy. Sometimes application programs need to do something momentarily, like a window operation or write data to disk. The computer still has enough time to deal with the serial port, but the application program isn't available to deal with all the data. A large buffer will allow a ZModem transfer to proceed at full speed, even though the computer can take quite a while to save files to disk. Notice that the transmitter doesn't have to use any extra wires to tell the receiver to slow down — all the important timing is encoded in the signal. I know this is a lot to read through, but maybe it'll help people understand some of the terms people toss around, and help you diagnose faults in your software. (For example, no handhaking gives missing data; buffer too small gives slow/inefficient transfers.) For comparison, I get transfers as high as 3600 bytes/second (38400 baud) on a 7.14 MHz 68000 with far too many commodities and the slowest hard-disks ever connected to a A2090A controller. I use BaudBandit.device instead of the stock C= serial.device; this is important for anyone on a slower processor.