#SupraFaxModem problems
15 messages in this thread
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.
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
Thanks Steve. I did not know there were different nodes for 9600 baud.
Everything is fine now :>
John
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
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
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
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
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
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.
Ah! Thank you. That clears everything up.
I'll soon get one.
Paul
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.
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
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.
Ah. Well, I guess there are enough people using high-speed modems out
there that I should be safe. So expensive though.
Paul
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.