HDTenEightyP/NetNews huggingface dataset:
From: gerg@netcom.com (Greg Andrews)
Subject: Re: Telebits and TIES (was: Re: Boom! Our lawyer are tougher...)
Date: Wed, 29 Jul 92 06:07:30 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

john@jwt.UUCP (John Temples) writes:
>
>In article <1992Jul20.034928.14560@cubetech.com> andrew@cubetech.com (Andrew Loewenstern) writes:
>>Good modem manufactureres like Telebit and USR pay Hayes, so you don't
>>have to worry about it.
>
>Note that the WorldBlazer uses TIES, while the T3000 doesn't.  Or
>perhaps it now does --  My T3000 from last year used the Hayes-style
>guard time, which was replaced by TIES in the WorldBlazer upgrade.
>It's documented on the last page of the WB addendum.  I called tech
>support asking why (before I noticed it in the manual) and was told
>"we're trying to get out of paying Hayes."
>
>The way TIES is implemented on the WB is a bit unusual.  If you type
>+++ with appropriate guard time, you will get an OK prompt.  However,
>if you subsequently type any character which is not a valid AT command,
>the modem will issue the CONNECT string and go back online.  Is this a
>typical implementation of TIES?
>

Yep, one of the major goals of TIES is backward compatibility with
software that's been written for the Hayes-style escape sequence.
Most of the comm software I've seen just sends the three escape characters
and blindly pauses for 1.5-2 seconds.  Some software out there may send
the sequence and wait until it sees "OK" before continuing.  TIES needs
to take this into account.  If the modem sees the three escape characters
followed by a pause, it returns "OK" to encourage the software to send
an AT command (probably "ATH").  The pause isn't involved in changing
to command mode, just in returning the "OK".  The modem was already in
command mode after the three escape characters.

It's understood that the modem may falsely trigger on a sequence of three
escape characters.  If the modem detects a false alarm, it simply goes
back into data mode.  The two primary ways the modem detects a false alarm
is that the escape characters weren't followed by "AT", or the AT command
after the three escape characters is not a valid command.


-- 
 .------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
 |                 |   Internet: gerg@netcom.COM                    |
 `------------------------------------------------------------------'
From: john@jwt.UUCP (John Temples)
Subject: Re: Why is my WB that slow in PEP-mode ?
Organization: Private system -- Orlando, FL
Date: Mon, 20 Jul 1992 17:24:03 GMT

In article <1992Jul19.181846.17442@jr.rhein-main.de> joachim@jr.rhein-main.de (Joachim Riedel) writes:
>Have to disable compression at all ( ATS190=0 ).
>Then I have the same rates with either T2500 or WB.

I would say it's more correct to set S191=6.
-- 
John W. Temples -- john@jwt.UUCP  (jwt!john@peora.sdc.ccur.com)
Xref: sparky comp.dcom.modems:10928 comp.dcom.fax:1394
From: klxtho01@uctvax.uct.ac.za
Newsgroups: comp.dcom.modems,comp.dcom.fax
Subject: Dallas external V32bis fax modem
Keywords: Dallas, modem, V32bis, fax
Date: 22 Jul 92 15:49:46 GMT
Article-I.D.: uctvax.1992Jul22.134946.202077
Organization: University of Cape Town


I have been offered a V32bis modem made by Dallas.  I have a number of
questions:

1)  Can this modem work with a 9 pin serial port?  Some high speed modems use
more than 9 pins to communicate with the external modem - does this?

2)  Can anyone recommend one way or the other on the reliability and
compatibility of modems made by Dallas?

3)  If anyone from Dallas is *listening*, could you give me the address of the
local (South Africa, preferably Cape Town) supplier of this modem?  I do
represent a computer retailing firm.

4)  I have been told that it has a built-in splitter for incomming calls: ie it
can differentiate between fax, modems and voice calls.  Is this true?  How
reliable is it?

Please E-Mail

Thank you for you time

Cheers,
Barry.
Newsgroups: comp.dcom.modems
From: hope@huracan.cr (Theodore Hope)
Subject: Re: WorldBlazers and SLIP
Organization: Proyecto Huracan - Fundacion Nahual / San Jose, Costa Rica
Date: Wed, 29 Jul 92 12:33:04 CAM


In <1992Jul29.021155.2461@mccc.edu> pjh@mccc.edu (P. J. Holsberg) writes:

> What are the proper S-register settings for a WorldBlazer to connect via
> SLIP using KA9Q?

In general, lock the DTE side at some fixed rate (57,600 in your case),

MAKE SURE you have rts/cts flow control (NO XON/XOFF, OR YOU'LL HAVE PROBLEMS)
(I think it's s58=2 and s68=2) and tell ka9q that you have it (can't remember
right now, maybe the "cr" flag to "attach asy" command.)   If you have a
16550 (probably should if you're going to run as fast as the WB) make sure
ka9q is recognizing it.

Other than that, the rest will depend on what you want -- autodial when
the modem turns on, leased line mode, LAPM, Compression, etc....

 -Theodore Hope
  Proyecto Huracan - Fundacion Nahual
  San Jose, COSTA RICA
From: naddy@mips.ruessel.sub.org (Christian Weisgerber)
Newsgroups: comp.dcom.modems
Subject: Re: Connecting Supra to Supra
Organization: My Individual Private Site
Date: Sun, 26 Jul 1992 01:15:08 CET
	<OD.6badnetOA92-901-302p0_4bc3b8aa@piraya.bad.se>
	<H.mWacgF1UM&M@mips.ruessel.sub.org>
	<H.znI1RX&z5Bk@mips.ruessel.sub.org>
Reply-To: naddy@mips.ruessel.sub.org

In <zxmgn01.711733886@mailserv>, Philipp Knirsch writes:

> of USR users around, and the big prblem with the USR is that you CAN`T
> actually say what speed you are driving.

Some people *can*.

a) You have a data transfer running. The throughput achieved pretty much
   tells you the current speed. When sending ARQ flashing will show
   errors and blocks being retransmitted. For receiving, take a look at
   the RD LED. If it shows a steady stream of data and throughput is
   low, you can be sure it fell down to a lower speed, which you can
   guess from the throughput. MR will show any fall backs/forwards, etc.
   etc.
   I have had mine for quite a long time now. With some experience you
   can extract a lot of information from the 12 LEDs.

b) When I'm in an interactive application and figure something is wrong
   with the line I enter command mode and type ATI6 which gives me the
   current link diagnotics.

Agreed, it takes more effort compared to modems that use displays but
you can figure out all the information you need. It just depends on the
user's proficiency :-)


bye
-- 
Christian 'naddy' Weisgerber, Germany           naddy@mips.ruessel.sub.org
"If you don't know what a baud is then you should probably be using 'bits
 per second' instead." --Mike Benna
From: pjm40@duts.ccc.amdahl.com (Paul J Milazzo)
Newsgroups: comp.dcom.modems
Subject: Re: Problem with ZOOM v32bis
Date: 24 Jul 92 18:11:13 GMT
Reply-To: pjm40@DUTS.ccc.amdahl.com (Paul J Milazzo)
Organization: Amdahl Corporation, Sunnyvale CA

In article <xjgm#4h.genie@netcom.com> genie@netcom.com (The Genie) writes:
>In article <1992Jul17.051926.4821@highlite.u> yarvin@highlite.gotham.com writes:
>>
>>I just bought a ZOOM v32bis modem from Egghead Software, and I'm
>>having some connection problems with it.  Sometimes it connects
>>fine, but sometimes it
>>
>>(1connects, goes through the handshaking sequence, then refuses
>>to issue a CONNECT message
>>
>>or
>>
>>pretends to connect successfully, but just prints some garbage and
>>never gets a proper connection.
>>
>>Is this a known bug, or is it more likely the result of the cruddy
>>comm package (EasyLink II)?
>>
>
>EasyLink II?  That's strange.  I ordered my v.32bisFAX from
>PC Connection, and it came with MTEZ made specifically with
>the Zoom in mind.  When I ran mtez, it automatically installed
>all the correct strings and init codes to get perfect 14.4k
>connections to everywhere...
>
>Although Mtez is fine, I prefer to run the Zoom under Telix, since
>I've been using Telix for 3 years now.  Telix works fine also.
>Try fiddling with your init string.  That is probably the
>cause of your problems.
>
>Gene


I'm using Qmodem with my internal Zoom v.32bis fax/modem and get the
same problems occusionally.  I haven't seen it happen in a while since I
set DTR Lock (or something that sounds like that) in the configuration.
My standard init string is AT&F&C1&D2S0=0S95=47.  The DTR Lock in the
modem toggle might have made a difference.
Only time will tell...
From: john@jwt.UUCP (John Temples)
Newsgroups: comp.dcom.modems
Subject: Re: Telebits and TIES (was: Re: Boom! Our lawyer are tougher...)
Date: 24 Jul 92 03:14:59 GMT
Organization: Private system -- Orlando, FL

In article <1992Jul23.001949.14222@ksmith.uucp> keith@ksmith.uucp (Keith Smith) writes:
>>If you type
>>+++ with appropriate guard time, you will get an OK prompt.  However,
>>if you subsequently type any character which is not a valid AT command,
>>the modem will issue the CONNECT string and go back online.

>Oh WOW!  I missed this ITFMU.

Actually, that part's not in TFM; at least, not that I've seen.  Just
the part about standard TIES is in TFM.
-- 
John W. Temples -- john@jwt.UUCP  (jwt!john@peora.sdc.ccur.com)
Newsgroups: comp.dcom.modems
From: tad@ssc.wa.com (Tad Cook)
Subject: Re: Why not PEP over cellular?
Organization: very little
Date: Wed, 22 Jul 1992 02:15:43 GMT

In article <BOB.92Jul17141605@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>In article <clemon.08f0@lemsys.UUCP> clemon@lemsys.UUCP (Craig Lemon VE3XCL) writes:
>   Generally it is accepted, however, that when trying to carry on a
>   high-speed data connection via cellular, you will have the sense to
>   stop driving :-).
>
>Why would I want to restrict myself to not driving while my connection
>is open?  After I conduct my interactive business and hit the road,

Because if you don't, the link may crap out when the call is handed
off while moving from cell to cell.  If you stay in one place, this
generally does not happen, unless you are at the edge of a cell
and call traffic is heavy.


-- 
 Tad Cook     |  Phone:  206-527-4089  (home)     |   MCI Mail: 3288544   
 Seattle, WA  |  Packet: KT7H @ N7DUO.WA.USA.NA   |   3288544@mcimail.com 
              |  Internet: tad@ssc.wa.com        or...sumax!ole!ssc!tad
From: andyb@wndrsvr.la.ca.us (Andy Brager)
Newsgroups: comp.dcom.modems
Subject: WorldBlazer blazes along at 219cps
Date: 28 Jul 92 16:00:27 GMT
Organization: Public Access BBS for Southern California 1 310 3756089


ISC 3.0, HDB UUCP (version unknown). C-news patchdate Aug 91.


When called by another modem (T2500 or Practical Peripherals V.32bis)
more often than half the time, we get a 2400 baud connection, which is
characterized by the 219 cps steady state transfer.  I'm *told* that
the modems are making 9600 baud connections or better, but they act like
2400 baud connections.  If I call the PP, I can get a high transfer rate
(1000+ cps), but rarely do that well when they call me ( I never
call the T2500, since he is concerned about security and won't put
up a login prompt...)

The T2500 has tried with both PEP, and V.32.  The PP has tried with
both V.32 and V.32bis.

Makes me wonder why I didn't get something 1/4 the price if I'm going
to experience the same stupid problems.  I thought I was paying for
quality.  Maybe it's something I'm doing wrong, but after reading 
some other peoples stories, I seriously wonder what is wrong with 
Telebit's WorldBlazer.

Anybody know?   Thanks in advance!

-  Andy

-- 
		DO NOT BUY TOUCHE COMPUTERS -email for details
	Large Packages (1K+ Total): cerritos.edu!swc!wndrsvr!andyb
     Shake the hand, of the man, who shook the hand, of the father of TCP/IP!
	-I don't know but I been told; two sides to every story - Joe Walsh
Newsgroups: comp.dcom.modems
From: kensaga@diku.dk (Kenneth Fribert)
Subject: Re: Supra V.32bis ROM upgrades???
Date: Sun, 19 Jul 1992 20:36:35 GMT
Organization: Department of Computer Science, U of Copenhagen

cp77074@csie.nctu.edu.tw (Yeng-Chee Su) writes:

>    I've used it.  It cost a lot of money and doesn't work.  The FAX can't
>even work on Supra FAX.  I need a ROM upgrade to correct the bug.  By the
>way, I've mailed to the tech-support on compuserve.  They told me just send
>the registeration card and wait.  I DO send back about 14 days ago, but I
>can't find my registeration on the BBS (it's money again).  I don't think I
>have enough patient to wait for the ROM.  Any comment? 

Well, to say it short this is NOT the modems fault, I have used both v1.0
and v1.2, and have always been able to send faxes with my GPFax, I sent
in my card 4 weeks ago, but I am not on the BBS either, so what? They say
in the lines just above the search that it will not show up immediately, and
so it is. I sent them a fax explaining that I needed the v1.2, and 5 days
later I had them (I live in Denmark, so it is VERY fast).
I dont know what you mean with Supra Fax is it the program? Because I have
GPFax, and that is the same as supra fax, except supra fax is specialized
for Supra's only.

To make a long story short, you need patience, and a telefax to Supra.
If you have any comments to this, or you need some help, please Email me.

Regards
-- 
|/                 Fido-net: 2:230/41.14    Phonenet: (+45) 31 743 455
|\enneth  Fribert  Snailnet: Nedertoften 39, 1tv,  Dk-2720 Vanloese, Denmark
System currently in use: Amiga 2000, GVP Series II, Quantum 105S, SupraFax v32b
                         10 mb ram, MultiVision2000
Newsgroups: comp.dcom.modems
From: les@chinet.chi.il.us (Leslie Mikesell)
Subject: Re: Boom! Our lawyers are tougher than your lawyers. You're Dead.
Date: Fri, 24 Jul 1992 15:00:02 GMT
Organization: Chinet - Public Access UNIX

In article <1992Jul23.183052.1972@qiclab.scn.rain.com> 70465.203@compuserve.com writes:

>After perusing my manual, I see *two* "possible" out-of-band signals
>for dropping into command mode. The first is dropping DTR. But I need
>that to drop the *connection* as well as enter command mode.

But why would you ever want to drop to command mode after making
a connection?  I've certainly never needed to do it on the same
call that was used for file transfers of arbitrary data.

>That leaves sending a "true break". Alas, I need that to get the attention
>the very machine I'm entering this message from! (I've had times when it
>was not possible to get it to pick the right port rate without hitting
>it with a break).

If there is modern equipment at the remote end and it is set up
properly, the speed matching can be done automatically by the
remote modem.  Or if it doesn't let the modem handle it, if it
expects the highest possible speed first, any character you send
at a lower speed will look like a break character and cause a 
speed switch.   Unfortunately, the person placing the call usually
doesn't have any control over what is at the other end...

>So now what?

Just decide ahead of time whether you want to talk to the modem
or the remote host.  If you are interested in the remote, disable
the modem escape sequence and don't worry about it any more.

Les Mikesell
  les@chinet.chi.il.us
Newsgroups: comp.dcom.modems
From: gerg@netcom.com (Greg Andrews)
Subject: Re: Boom! You're Dead.
Date: Wed, 29 Jul 92 05:00:50 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 


70465.203@compuserve.com writes:
>
>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.
>
>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. 
>

Not with most modems.  Most modems mask off the high bit before they
check the byte against the value in S2.  If the data byte were a 128,
it would be masked off to a 0.  Then you would have S2=128, the data
byte=0, and the compare would fail.  The modem didn't see you send
any 128s, so it wouldn't go into command mode.

In Telebit modems the masking is controlled by S48.  With S48=0, the
modem masks the byte before comparing it to S2.  With S48=1, the modem
doesn't mask the byte.  The default value of S48 is 0, for this very
reason.

The need to set S48=1 is EXTREMELY rare, limited to a very few systems
that run with their parity fixed to Even or Odd.  Even then, it can still
work.  A system fixed to 7E1 can't generate a 128.  Try to send a 0 and
the parity bit will stay off, sending a 0 and not a 128.  A system fixed
to 7O1 can't generate a 129.  Try to send a 1 (Ctrl-A), and the parity
bit will stay off, sending a 1 and not a 129.

All in all, a little brainpower will solve the problem...

>
>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.
>

No, you can disable the escape sequence handling.  It works fine, and
has done so for many years...


-- 
 .------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
 |                 |   Internet: gerg@netcom.COM                    |
 `------------------------------------------------------------------'
Xref: sparky comp.dcom.modems:11267 can.uucp:181
From: woods@eci386.uucp (Greg A. Woods)
Newsgroups: comp.dcom.modems,can.uucp
Subject: Re: UUCP 'g' vs. MNP & V.42
Date: 27 Jul 92 19:38:24 GMT
Organization: Elegant Communications Inc.

In article <mN8FoB2w164w@zswamp.UUCP> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
> Just the facts so's the folks make the best decisions:

Remember that unless you understand the relationships between
different protocols being used (i.e. how they interact), and the
effects that may be due to particular implementations or due to
parameters set in particular connections, you cannot use "common
sense" in making statements about communications issues, even if you
know many of the details about each protocol.

> woods@eci386.uucp (Greg A. Woods) writes:
> > MNP-4 is link-layer protocol that retries erroneous packets.  UUCP 'g'
> > is a link-layer protocol that retries erroneous packets.  Guess what
> > -- the don't get along very well!
> 
>    This is *completely* untrue!  While MNP may increase latency compared to a 
> normal link, it does not in any way interfere with the data being sent.

Except where that latency will cause problems with some other file
transfer or error correcting protocol that's being encapsulated by MNP-4.

We're talking about UUCP 'g' here, and with "normal" parameters,
uucico will often wait (and sometimes timeout while waiting) for
ACKs.  This degrades throughput.  It is effectively a loss of ~15%
when MNP-4 and UUCP 'g' are used over V.22bis, and as much as 50% when
used over V.32.  These are measured results.

>    There is no harm in using an error-correcing protocol over an 'error-free' 
> link (I put that in quotes because MNP guarantees no errors between the 
> modems, not no errors between the computers), unless the protocol imposes a 
> significant overhead.  Since, in this case, the overhead is more than made up 
> for by start and stop bit removal, there is no reason not to use MNP under 
> UUCP-g, at least not at 2400 bps where the increased latency should not push 
> past the window size.

Sorry, but that is *NOT* the case, as measured in actual connections
with UUCP 'g' window size at both 3 and 7.  Even the 20% gain in
efficiency courtesy of MNP-4 is still not sufficient to overcome
timing problems.

[No, at 2400 bps the increased latency of MNP-4 without spoofing does
not usually cause *timeouts* with UUCP 'g' at a window size of 3,
packet size of 64, but will cause delays.  Note however that line
noise will immediately increase the latency, and thus the chance of a
timeout.  So, spoofing is a double win -- 1) the host-to-modem link is
guaranteed error free; 2) the DCE-DCE link latency does not affect the
file transfer protocol.]

So, any other questions about why UUCP sites everywhere use Telebits?  :-)
-- 
						Greg A. Woods
woods@Elegant.COM, woods@robohack.UUCP  VE3TCP	ECI & UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]	Toronto, Ontario; CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL
Newsgroups: comp.dcom.modems
From: wlsmith@valve.heart.rri.uwo.ca (Wayne Smith)
Subject: 2400/9600 FaxModems & CCITT Standards (What's the story?)
Organization: The John P. Robarts Research Institute, London, Ontario
Date: Tue, 21 Jul 1992 19:54:21 GMT


I have a few questions concerning the capabilities of the
Best Data Products Smart One Fax/Modem (9624FQ), with regards to
CCITT standards.

This modem is described as a 9600/4800 bps SEND/RECEIVE FAX &
2400/1200/300 bps DATA MODEM.   

Technical information:

Compatability:		Data Modem Standards:
			CCITT V.22bis 2400 bps
			CCITT V.22    1200 bps
			Bell 212A     1200 bps
			Bell 103      0-300 bps

			Send/Receive Fax Modem Standards:
			CCITT Group III send/receive
			Fax format CCITT T.30 and T.4
			CCITT V.29 at 9600 bps with fall back to 7200 bps
			CCITT V.27ter send & receive at 4800, 2400 bps
			CCITT V.21 Channel-2 send & receive at 300 bps
			EIA-578 Service Class 1 Commands

Error Correction:	CCITT V.42, MNP 2-4
			Supported through the Rockwell RPI driver	 

Data Compression:	CCITT V.42bis and MNP level 5
			Supported through the Rockwell RPI driver
 

What I would like to know is if this modem is capable of a higher data
baud rate by using MNP 5.  There is no mention of turning on MNP 5
in any of the registers. 
And what does 'Supported through the Rockwell RPI driver' mean?
Does that mean this 'driver' is a software driver?
If this thing can talk to fax machines at 9600 baud, then why can't it
talk to other 9600 baud modems (or other modems of the same make at
9600 baud)????

Who knows the real scoop on these 9600/2400 baud fax/modems.???

Newsgroups: comp.dcom.modems
From: larry@trauma.rn.com (Larry Snyder)
Subject: Re: Transfer rate of Kermit
Organization: Gator Conferencing Systems - 219-289-0777 - 6 lines
Date: Sat, 25 Jul 1992 18:22:02 GMT

jkim@m.cs.uiuc.edu (Jaewon Kim) writes:

> 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? 

try increasing the packet size to 1000 and increasing
the window size to 3

-- 
Larry Snyder                                    internet: larry@gator.rn.com
4950 Estero Blvd, Ft. Myers Beach, FL            uucp: uunet!rde!nstar!larry