HDTenEightyP/NetNews huggingface dataset:
From: riddell@netcom.com (Shane Riddell)
Newsgroups: comp.dcom.modems
Subject: REcommendations for fax/modem(V.32bis) needed.
Keywords: fax, modem, V.32bis, help
Date: 22 Jul 92 15:40:00 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


        Help!  I need to purchase another fax/modem, since I have
returned my Zoom which refused to connect to a USR Dual Standard.
Are there any good fax/modems out there that have V.32bis that
have all the bugs worked out of them?

        Any recommendations will be greatly appreciated!

shane
riddell@netcom.com
-- 
**********************************************************************
* shane                   * If I ever say or do anything, just to be *
* riddell@netcom.com      * politically correct, please, SHOOT ME!   *
**********************************************************************
From: saustin@bbn.com (Steve Austin)
Newsgroups: comp.dcom.modems
Subject: Re: Help on upgrade to 16550A UART
Date: 23 Jul 1992 01:07:13 GMT
NNTP-Posting-Host: bbn.com

willmore@iastate.edu writes:

>Now, what I want to know
>is does anyone have a program to detect what type of serial chip a
>computer has?  Some little .com file that says:

>port 1 is 16550
>port 2 is 16550
>port 3 is 8550

With Windows 3.1 you get a DOS program called MSD which gives you
a whole load of information like this (including what chip you have).

	Steve
Newsgroups: comp.dcom.modems
From: dirksch@rama.informatik.rwth-aachen.de (Dirk Schlossmacher)
Subject: V.32(bis)-pocket-modem(DC-power-supply)?
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: 28 Jul 92 17:01:06 GMT

Did anybody see or is currently developing a V.32(bis)-modem for
mobile use??
Possibly there is one to integrate in a notebook, and to be passed
by the german TELEKOM for their stupid FTZ/ZZF-Number?

Please give me a hint!!

Thanks 

Dirk


---------------------------------------------
EMail: dirksch@Pool.informatik.rwth-aachen.de
=============================================
From: leonard@qiclab.scn.rain.com (Leonard Erickson)
Newsgroups: comp.dcom.modems
Subject: Re: Serial and Parallel interface ??????
Date: 21 Jul 92 21:07:53 GMT
Article-I.D.: qiclab.1992Jul21.210753.8014
Reply-To: 70465.203@compuserve.com
Organization: SCN Research/Qic Laboratories of Tigard, Oregon.

vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau) writes:

>Nothing, really, apart from the mental block of manufacturers which associates
>modems with serial lines. It would also be a convenient way to get shot
>of the { tty | clist | namiaf | ... } processing that many computer 
>manufactureres assiciate with a serial line, and which is mostly unwanted
>these days (i.e. character echo, processing of bs, del, end of anything
>conditions, ... )

>Any PC I know of puffs out at 115200 bit/sec (or 11520 byte/sec) on the 
>serial ports, mostly because of this unwanted additional processing. On a
>common notebook parallel port I have seen 60 kbyte/sec sustained over several
>minutes with a parallel port SCSI or Ethernet adapter. With the usual cable
>used for parallel ports speeds of between 500 kbyte and 1 Mbyte/second 
>could easily be achieved - the cabling is electrically less demanding 
>than that for a SCSI bus - only two devices, no spurs.

Bzzt! Wrong!

The 115,200 bps limit is a *hardware* limit. At that rate, the UART
chip is dividing the supplied clock signal by *one* to get the bit
timing. It can't go any faster than that *period*. The chips aren't designed
for a much higher bit rate than that anyway. If they, were, you'd need a new 
oscilator chip, *and* you'd have to throw out all your communications
software (most of which sets the bit rate by *directly* loading ther 
UART's divisor registers.

The other device are using different clock signals *and* substantially
different chips. Compare the cost of a serial card with the cost of
an ethernet card...

>The second hurdle is that those who have so far brought out devices for 
>parallel ports do not document what lines and protocols they are using.
>For example, on the (Epson-) Centronixs port the printer has the signal
>/paper-out, the computer the signal /auto-feed-xt, inducing the printer 
>to supply a line feed for every carriage return. It would be *nice* to 
>know if the other devices use these and what they use them for.

Funny, every card *I* own that has a parellel port has all the signals
described. They also describe how to set them for biderectional use
of the data lines. And they warn that such use is *not* standard.
(More specificly, that while their port will do it, many *won't*)

-- 
Leonard Erickson		      leonard@qiclab.scn.rain.com
CIS: [70465,203]			 70465.203@compuserve.com
FIDO:   1:105/56	 Leonard.Erickson@f56.n105.z1.fidonet.org
(The CIS address is checked daily. The others infrequently)
From: davidg@aegis.or.jp (Dave McLane)
Newsgroups: comp.dcom.modems
Subject: Re: Modem use in Japan?
Date: 28 Jul 92 13:23:05 GMT
Distribution: comp
Organization: Aegis Society, Kyoto Japan

dave@appi.iis.u-tokyo.ac.jp (David Wuertele) writes:

>Can you use a 9600bps modem in Japan?  I heard that they used to have at
>most 4800bps there.

I'm curious ... where did you hear that?  

Aegis supports 9600 on 3 lines and 14,400 on the other two (all
Telebits). The only reported problem is somebody with a USRobotics
can't link with MNP5 but otherwise no problems. 

IMHO the lines in Japan are quite clean. One person reports only
getting 2400/4800 on to Germany, and I myself had trouble getting
a 9600 link to the U.S. but not trouble with PEP (although the
CPS rate is only about 1,000).

Hope that helps,

Dave

--
Dave McLane 
JUNET: davidg@aegis.or.jp (ONLY within Japan: post otherwise)
Nagaokakyoshi, Kyoto Japan Tel: +81-75-951-1168 Fax: +81-75-957-1087



Newsgroups: comp.dcom.modems
From: gerg@netcom.com (Greg Andrews)
Subject: Re: Upload 5 times slower than download
Date: Wed, 29 Jul 92 04:12:34 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: all

ctan@solomon.technet.sg (Tan Chee Weei) writes:
>
>Using a Telebit T2500 and ckermit 5A, uploading a file on a 9600bps connection
>is somehow 5 times slower than downloading.  The system that is being dialed
>up operates through a terminal server.  During uploading, the SD/RD lights
>are observed to operate as follows: local modem sends, rather long pause,
>receives acknowledgement and sends out immediately and so on.  The problem
>seems to be the delay in receiving the acknowledgement from the remote
>modem for each packet sent. (Using 750 packet size with window size of
>4 and block check 2).  We are connect with v.42 and v.42bis enabled.  Using
>MNP alone, we constantly get corrupted characters during interactive
>usage. (to the point of being unusable) During download, the lights flash
>constantly without much delay as to be expected.
>
>Is there any explanation or solution to this phenomenon? Thanks.
>

Off the top of my head, it would appear that you're using different
packet or window sizes for uploading than you do for download.

The CKermit on Netcom's unix system (a Sun) can be configured to use
different packet/window sizes for uploading, so perhaps that's what
is happening to you...


-- 
 .------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
 |                 |   Internet: gerg@netcom.COM                    |
 `------------------------------------------------------------------'
Newsgroups: comp.dcom.modems
From: gerg@netcom.com (Greg Andrews)
Subject: Re: T3000 -> WB ROMS to ship July 10
Date: Wed, 29 Jul 92 06:13:02 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

bgi@stiatl.salestech.com (Brad Isley) writes:
>
>Super!  But  ** I don't think this fixes the uucp-g spoofing **.
>This addresses PEP backward compatibility.
>That's a different problem altogether.  The WB uucp-g spoofing tries to
>force the window size to 3, and ISC refuses a window size this small.
>

Not true at all, unless ISC's uucico is hoplessly broken (which I doubt).
Your ISC system is *requesting* a window size above 3, and that request
is tickling the bug.

>
>Now, has this been fixed yet?  My apologies for being vague before.
>

Both will be fixed soon.


-- 
 .------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
 |                 |   Internet: gerg@netcom.COM                    |
 `------------------------------------------------------------------'
From: michael@resonex.com (Michael Bryan)
Newsgroups: comp.dcom.modems
Subject: Re: Serial Interfaces
Date: 24 Jul 92 09:03:57 GMT
Organization: Resonex Inc., Sunnyvale CA

In article <1992Jul24.035342.20200@ksmith.uucp> keith@ksmith.uucp (Keith Smith) writes:
>
>Also I shouldn't post after a bottle of Cabernet ...
>

It's generally a good idea to ignore any articles posted by a bottle of
wine, and not post any followups, except in the newsgroups under rec.food.
They tend to not know that much about computers and modems, anyway...

;-)

-- 
Michael Bryan        michael@resonex.com                     |     ,_,
"Pretenders I meet are making a trail along the way.         |    /oo \
They say that they know how to show me a path to guide my    |    <>__|
way to truth..." --- David York, "The Quiet of a Candle"     |    |  U|
From: leonard@qiclab.scn.rain.com
Newsgroups: comp.dcom.modems
Date: 18 Jul 92 18:28 MDT
Subject: Re: Boom! You're Dead.
Nf-ID: #R:tymix.tymnet.com:2043:1992Jul18.142836.4351@qiclab.scn:1958954500:001:1328
Nf-From: qiclab.scn.rain.com!leonard    Jul 18 18:28:00 1992


karl@ddsw1.mcs.com (Karl Denninger) writes:

>Of course, you could set the escape character to something unprintable 
>(> 127) and use out-of-band control (like a BREAK) to get back to command
>mode.

>If you do that, you certainly CAN send your modem's own manual over the wire
>without problems.  That's a damn good idea anyway for unattended
>applications; having remote users intentionally take your modems to command
>mode isn't considered social.

>This is nothing more than unadulterated scare tactics, and unreasonable ones
>at that.  You see, modems which use TIES probably aren't subject to Hayes'
>monopolistic patents, and thus they want to make sure you don't buy modems
>that don't have a built-in bribe to Hayes in their pricing.

Tell you what. Set the escape sequence on one of these modems to (say)
128. Then wait until you get a binary file containing 3 128s in a row.
Boom! Instant command mode. 

Hayes *does* have it patented. So if you want to have in-band signalling
you are stuck with paying the royalties. Or do without the time delay
and watch the occasional file transfer crash.

-- 
Leonard Erickson		      leonard@qiclab.scn.rain.com
CIS: [70465,203]			 70465.203@compuserve.com
FIDO:   1:105/56	 Leonard.Erickson@f56.n105.z1.fidonet.org
(The CIS address is checked daily. The others infrequently)

Newsgroups: comp.dcom.modems
From: keith@ksmith.uucp (Keith Smith)
Subject: Re:   Serial and Parallel interface ??????
Organization: Keith's Computer, Hope Mills, NC
Date: Fri, 24 Jul 92 01:54:53 GMT

In article <clemon.08ii@lemsys.UUCP> clemon@lemsys.UUCP (Craig Lemon VE3XCL) writes:
>        Well, the particular problem that I was referring to is on an
>unaccelerated Amiga (7.14MHz 68000) it is possible under heavy multitasking
>that the serial service interrupts will not be serviced quickly enough and
>it will start to lose characters (only a 1-byte FIFO or so).  There are
>other problems with serial data, however.  You can only send bits so fast
>before capacitance and other problems reduce the intelligibility of the
>data (ie. the pulses are rounded off so badly that they barely qualify as

Hahaha,

Can you say ETHERNET, TOKEN RING?  All SERIALLY transmitted data.

>pulses).  There is going to come a time when another interface method will
>need to be added to I/O devices simply for throughput reasons whether it be
>SCSI or simple parallel or whatever.  Lining the bits up single file can
>only go so fast.  While we may not have reached this limit with standard
>high-speed modem technology yet, there will be other standards (ISDN
>perhaps) that will.

Not Likely ISDN is gonna fly past 10 Mbits/sec, but I will agree that
"standard" RS-232 is not going to go much past 115K.

>
>--
> Craig Lemon VE3XCL - Kitchener, Ontario. Amiga B2000  OS 2.04  UUCPv1.15D.
> +1 519 741 0297    +1 519 578 7817              | Silly people!  We all
> clemon@lemsys.UUCP clemon%lemsys@xenitec.on.ca  | know that the Universe
> IP/Packet: ve3xcl@ve3xcl.ampr.org [44.135.84.51]| revolves around UUNET!


-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
From: tsibouris@vms.macc.wisc.edu
Newsgroups: comp.dcom.modems
Subject: Looking for a Mac ARA script for a ZyXEL U-1496E modem
Date: 25 Jul 92 16:25:24 GMT
Organization: University of Wisconsin Academic Computing Center

I am looking for a Macintosh ARA (AppleTalk Remote Access)
script for a ZyXEL U-1496E modem.  Any suggestions?

George
Newsgroups: comp.dcom.modems
From: st901745@pip.cc.brandeis.edu (Alastair M. Bor)
Subject: Carrier detecting on a Cardinal V.32
Reply-To: st901745@pip.cc.brandeis.edu
Organization: Brandeis University
Date: Tue, 28 Jul 1992 15:21:54 GMT

I have a bunch of PCs out in the field with Cardinal V.32 modems. ATI6 which
is the date code of the ROM is 01114 (if that means anything!). Recently
I purchased a MEGAHERTZ 96/96FAXmodem (its a very small (battery operated)
modem for my portable). I have no problems logging on to any of my
PCs in the field.... nor any other modems (regardless of speed). My
problem is that the PCs out in the field dont detect the carrier loss
(from my MEGAHERTZ) until about 30 seconds after carrier drop. This messes
up my PC-ANYWHERE connections since PC-ANYWHERE knows of the imminent
carrier drop (since my portable PC tells it).. and then tries to reset
the modem while it has not figured out that the carrier dropped.
I have set ATS10=0 (time to drop after carrier loss=minimum).. but that
does not seem to work. I have some other PCs in the field which use
a different model of CARDINAL modem and they have no problem...

WHAT SHOULD I DO?


-Alastair M. Bor
st901745@pip.cc.brandeis.edu

Please reply by E-Mail if possible  
Newsgroups: comp.dcom.modems
From: brooke@cco.caltech.edu (Brooke Paul Anderson)
Subject: Problems with ZOOM 14400 faxmodem
Organization: California Institute of Technology, Pasadena
Date: Tue, 21 Jul 1992 11:32:34 GMT

I have the ZOOM 14400 faxmodem (the v.32bis, v. etc. one), and I'm
having problems with it when it first starts up.  I'm using OS/2
and the TE/2 comm program which I have automatically start when
OS/2 boots up.  The problem is that, the very first time I try to
dial out, the modem locks up usually.  It will dial and signal that
it has gotten the carrier from the remote modem, but will not
connect -- it just hangs and will not accept input from that point
on.  If, before dialing out, I type some commands (like "at" and
"at&v" a couple of times), the modem works as it should.

Also, I had problems with the modem echoing keypresses and accepting
initialization strings from the comm program initially.  The first few
keypresses would not be echoed, and the modem would not seem to accept
"atz" as an initialization string.  If I used "atz", then dialed, the
first "a" in "atdt5796440", for example, would be missing sometimes.

The modem would also lose the stored settings occasionally.  In other words,
even though I stored settings with "at&w0" and "at&w1", these settings
are occasionally lost even though I haven't issued new at&w commands.

The modem works fine once it is up and running and I have fussed around
with it before dialing out the first time.  From then on, it works as it
should.

Has anyone had this weird startup behavior?

I am thinking of taking the modem back even though it only cost $260.
At that price, it was definitely worth a try. :)
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: comp.dcom.modems
Subject: Re:  Serial and Parallel interface ??????
Date: Fri, 24 Jul 92 23:55:39 EDT
Organization: Izot's Swamp

vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau) writes:

> Ouch.
> 
> Even mint condition 1981 PCs are able to transfer 250 kbit/s through a serial
> line, bit serial, analog, via the floppy disk controller.

 ... with special hardware and, even then, with the CPU shut down to allow 
DMA.  That's real useful for file transfers or X terminals!

   Anyway, I think that your rebuttal to Craig actually argues *for* his 
point; we've been debating the need for an alternative to RS-232C, and a 
parallel scheme was suggested.  This was refuted by someone stating that "the 
serial connection is not the bottleneck", to which Craig said that, given the 
current standards, it is.

   Your suggestion - that a high performance but RS-232 incompatible - serial 
scheme exists, supported in hardware, is pretty much in agreement with the 
original statement that we should explore alternatives to the RS-232 
interface.  Whether it's a DMA-based system with a 512 byte buffer or a 
CPU-driven parallel system is not really the point in focus.

> It is just that serial (RS232) ports were perceived to be slow and in need of
> very careful processing. Thus the OSes start creaking, sort of like anything
> that tries to shovel tons of coal with an elaborate golden teaspoon.

   They are... the interrupt overhard of high-throughput byte-at-a-time I/O 
will cripple anything.  The 16550's 16-byte buffer helps, but what's needed is 
an intelligent serial card.

   Unfortunately for Craig, I don't believe that there are such things for 
Amigae, and I doubt that his budget permits an Ethernet card and a TCP/IP 
terminal server. <grin>

Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
Newsgroups: comp.dcom.modems
From: rdippold@cancun.qualcomm.com (Ron Dippold)
Subject: Re: Why not PEP over cellular?
Organization: Qualcomm, Inc., San Diego, CA
Date: Thu, 23 Jul 1992 19:28:23 GMT

wtm@uhura.neoucom.edu (Bill Mayhew) writes:
>Something else to keep in mind is that cellular telephones in the
>US transmit on a frequency of approximately 900 MHz.  At such a
>high frequency, multipath distortion and other signal quality
>vaggaries are pretty strong in the case of a moving transciever.
>The continuously variable delays and echo intensities effectively
>reduce the usable bandwidth.

>Fancy digital processing techniques can be applied, but the DSP
>window size is going to have to be small enough that rapidly
>changing transmission characteristics may be accomodated.

Time to plug CDMA again - we use the multipath to make a stronger
signal.  If we have one signal coming in at -20 dBm Ec/I0 from the
cell, and another one coming in a few chips later at a lower power,
say -40 dBm, and even another one at a lower or higher power, we can
combine all three into one signal by effectively shifting the time on
each one and using a combiner to result in a stronger signal than any
of the three.  We lock on to each of the paths, and track them as they
shift around due to movement of the vehicle (or just due to the
vagarites of the signal).  Thus multipath helps us rather than hurts
us.  The original implementation of CDMA was on a number of DSPs, so
it can be done, and with todays modern DSPs it might only take one.

And, since we've been so interested in multipath, we've done a lot of
work on it - and I can back up your "pretty strong" statement.  Places
like New York are incredible!  The multipath is often stronger than
the signal, and the buildings provide crossing zones of cell control,
so that as you're driving you get one cell stronger, then another,
then another, then another, often twice a block.  With our soft
handoff this is no problem, but it can be murder on an FM phone.  And
in some places (Salt Lake City is particularly bad, due to far-off
cliffs which reflect back a _wicked_ signal) the multipath is so bad
that you have to search quite a large window, 128 chips or more.
Something like this is going to give a time-division system the
willies.


>Telebit did or does make a specific model called Cellblazer that
>attempts to deal with the issues above.  A regular v.22 or v.32
>type modem is likely to have a quite difficult time.

Amen.  Telebit makes some great modems - I really like their QBlazer
cube. 
-- 
Quark!  Quark!  Beware the quantum duck!
Newsgroups: comp.dcom.modems
From: jkim@m.cs.uiuc.edu (Jaewon Kim)
Subject: Transfer rate of Kermit
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 24 Jul 1992 06:00:24 GMT

 Although my modem supports V.32bis and V.42bis,
the highest transfer rate I can get with kermit is just
260 cps. Did I make something wrong? Or it's the best
of Kermit? 
Thanks!

-- 
 - Jaewon

------------------------------------------------------------
jkim@cs.uiuc.edu
Newsgroups: comp.dcom.modems
From: ujabanco@uxa.ecn.bgu.edu (John Abanco)
Subject: Re: Connect troubles with PPI PM14400FXSA?
Organization: Confounded Founders Foundation
Date: Wed, 29 Jul 1992 04:45:44 GMT

I too had problems when running Telix 3.15 and my FXSA. When I would
type, intermittent hangs would occur. The only way to fix that is to
shell to DOS and exit. After buying the 16550AFN, there were no more
problems with Telix.

One problem, though I don't know if it's a hardware or a software
problem, that I found was that I cannot run Telix from Windows 3.1. In
fact, I can't run ANY term program from Windows. If anybody has a fix
for this, please e-mail me. It used to work fine with my 2400/MNP, but
konked out when I plugged in my FXSA. I may have to go out and buy
Desqview if things don't work out.

...Money, more money, and even more money...when will this hobby end?

-- 
--My life is such a mess,I end  | INTERNET: ujabanco@uxa.ecn.bgu.edu
  up typing.... umop apisdn.    | FIDONET :
        John Abanco             | john.abanco@f769.n115.z1.fidonet.org 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: bender@oobleck (Duke of Canterbury)
Newsgroups: comp.dcom.modems
Subject: Re: Serial and Parallel interface ??????
Date: 29 Jul 1992 01:48:45 GMT
Organization: SPARK's R US
Reply-To: bender@oobleck.eng.sun.com
NNTP-Posting-Host: oobleck
X-Newsreader: Tin 1.1 PL3

keith@ksmith.uucp (Keith Smith) writes:
: Not Likely ISDN is gonna fly past 10 Mbits/sec, but I will agree that
: "standard" RS-232 is not going to go much past 115K.

Why can't "standard" RS-232 go much past 115K?  I think that the electrical
specifications of "standard" RS-232 such as the receiver input capacitance
and slew rate would cause the bit edges to start getting so mushy that
accurate recovery would become much more difficult past a certain speed (I
don't know what that speed is, but I'm sure there's someone on the net with
an HP-41C all fired up and ready to calculate it).

mike

--
The IQ requirement for being a phone operator may be pretty low, but the
required IQ for placing a call is just about vegetable level.  That's why
they kill sardines before canning them; if you let them swim around in the
can, it would heat up and explode.
Newsgroups: comp.dcom.modems