cec@cup.portal.com (Cerafin E Castillo) (01/05/91)
In order to answer all of the questions I have received in regards to
the Telebit T1600, I would like to share this technical information
with you all.
We finally received our first portion of Telebit T1600 the last week of
December 1990. I took one home for the weekend, opened it up, played with
it, etc., and found some very interesting features.
FIRMWARE
The first new feature is an entirely NEW command set. It has the look and
feel of a genuine Hayes AT command set. It is NOT comaptible with the current
Telebit command sets (enhanced command set) nor the conventional command set
found in BA5.XX/GAX.XX/GE6.XX/GF7.XX/FA1.XX firmware releases. It is entirely
new.
I was faxed a conversion table from Telebit in order to assist in converting
old Telebit command set and conventional command sets into the LA1.00 command
set found in the T1600. This conversion table consisted of 3 fanfolding
charts similar to the Quick Reference cards currently shipped with Telebit
Command Reference Manuals. These conversion charts are NOT INCLUDED with
the T1600 documentation.
This command set features macros which allow for front panel LED configuration
of the T1600 or AT&Fn, using a number for n, to configure the modem according
to pre-stored factory defaults for various applications including UNIX
Version 2 UUCP and HDB UUCP (BNU). I would strongly suggest that you stick
to using the Telebit UNIX UUCP configuration guides. This is due to the
fact that no further explanation of UNIX UUCP or dial-in/out set-up is
offered in the manual, beyond suggesting the Nutshell books. The two UNIX
macros themselves are not explained as to the reason or intended effects of
the chosen configurations.
I found some MAJOR problems that may be caused by these macros. AT&F3 for
System V (HDB-UUCP) and AT&F4 for Ver. 4.2-4.3 (BSD-UUCP) and SCO Xenix differ
in configuration by three registers. These registers handle DCD signaling
(&Cn), DSR signaling (&Sn), and serial interface speed (S51=nnn). The first
major problem is that these two macros DO NOT disable V.42 and V.42bis. While
V.42/V.42bis are great for use over V.32, this is not always the case for UUCP
Problems may be encountered in connecting to non-V.42/V.42bis modems or with
batched feeds which are compressed. On the HDB set-ups, somebody made a MAJOR
error and set the baud rate to be autobaud (S51=254). I guess you're not
supposed to run a getty if using the AT&F3 set-up macro. The UUCP support is
also enabled (S111=30), in V.32 mode, for use with other Telebit modems which
support V.32 UUCP spoofing. I believe that the spoofing in combination with
the V.42/V.42bis will mean trouble. I would disable ALL of these registers
and run vanilla V.32 for UUCP. These macro settings would work best for
interactive dial-up sessions. I wish that only one failsafe macro, at 9600 bps
would have been included for UUCP and getty use, to assist the novice in UUCP
set-up of the modem. This would have left a free macro that could have been
used for autoconfiguring SLIP/CSLIP/PPP use, again, for the novice user.
THERE IS NO REGISTER S39! This is listed in the configuration macros, but
is not documented in the manual. Telebit Tech Support informed me that this
was a feature that did not make it into the final release of the LA1.00
firmware. What this feature was, nobody seemed to know.
There are new commands for viewing and writing configurations, as well as an
on-line HELP mode. These are as follows:
Command Enhanced Command Set T1600
list configurations ATN? AT&N1 AT&N2 AT&V AT~V AT~V0 AT~V1
write configurations AT&W AT&W1 AT&W2 AT&W AT&W0(S255) AT&W1
list number directory ATN? AT~L
write phone number ATN0=<phone no.> AT~N0=<phone no.>
on-line help -none- AT~H AT~H0 AT~H[1-9]
enable debug mode ATJ6<debug register> AT~D1
HARDWARE
The T1600 features a Motorola 68302 CPU. This CPU has 3 built-in UART/USART
components which may account for the up to 38.4 kbps RS-232 interface speed.
I'm sure that this CPU also accounts for a lot more power in the modem. A
pair of DSP chips are used to perform the emulation of V.32 and the slower
modulations. The Texas Instruments TMS320C25 (40 MHZ) in combination with
a custom designed Ti CF93307PB chip supply the modulation horsepower in this
modem. From the explanation I received from my Telebit SE, this custom chip
acts similar to a gate array. There are two 1 MB ROMS which contain the LA1.00
firmware and a lot of surface space on the PCB. The rear panel contains the
same flakey Molex-style power supply connector. The power supply is the same
old brick and the enclosure is the same as the T2500/T1500/TB+. Two RJ-11
connectors and the female DB25 RS-232 connector are also included. The front
panel has a new LED order (facing front, from left to right):
MR OH CD HS EC DTR CTS SD RD
[modem ready/off-hook/carrier detect/high-speed (V.32)/error correction
(MNP-V.42)/data terminal ready/clear to send/send data/receive data]
The switch to a new command set supposedly frees up a lot of space in the
firmware EEPROMS of LA1.00. If this is true, then I believe that there
is space in this product for V.32 extended (V.32bis ??). Maybe even PEP!?
Telebit isn't promising us anything on these features, but I have already
received e-mail from people asking me about supposedly new Telebit products
that I haven't heard about. So much for being an authorized Telebit
distributor.
I hope this information helps. Telebit will be making official Spec Sheets
on the T1600 available to me in the next week. Please e-mail me for more
info on this product. The T1600 seems to be in short supply; we have only
recieved one-third of the units we originally ordered. I suspect this is due
in part to the amount of T1500s still sitting on distributor's shelves. Also,
it is possible that the OEM delivery limitations usually encountered when
using custom components such as a Rockwell chipset, or in this case the Ti
unit, might also be causing production limitations on the T1600. At $795
list, I'm willing to wait for more T1600s...
Hope this information helps. This posting is meant to be for the purpose
of providing requested technical information on this new product.
===============================================================================
Cerafin E. Castillo || //\\ ||\\ ||
Network Consultant || //__\\ || \\ || Los Altos
Los Altos Networks || // ---\\|| \\|| Networks
340 Second St. #6 ||___// \ | \ |
Los Altos, CA 94022
(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
INTERNET: cec@cup.portal.com
"...No hay mal que por bien no venga..."
===============================================================================benson@odi.com (Benson I. Margulies) (01/06/91)
Gee, uunet is selling t1600s for $545, and seems to have them by the truckload. I really don't see how the use of compression and the like with UUCP can be any different than for anything else, but I'm not the modem expert. -- Benson I. Margulies
tech@mich-ns.UUCP (Mich. Network Sys. TECH SUPPORT) (01/07/91)
In article <1991Jan6.004019.13502@odi.com> benson@odi.com (Benson I. Margulies) writes: >Gee, uunet is selling t1600s for $545, and seems to have them by the >truckload. I really don't see how the use of compression and the like >with UUCP can be any different than for anything else, but I'm >not the modem expert. > We will be getting a ton of T1600's in during the first week of Feb. and they'll be in short supply for a couple of months. We sell them for $519 with quantity discounts at 10 units and again at 20 units. -- Michigan Network Systems Technical Support Division Telebit/SCO/Digiboard Reseller BBS: +1 313 343 0800 1-800-736-5984
bob@MorningStar.Com (Bob Sutterfield) (01/07/91)
In article <37576@cup.portal.com> cec@cup.portal.com (Cerafin E Castillo) writes:
The first new feature is an entirely NEW command set. NOT
comaptible with the current Telebit command sets (enhanced command
set)...
Does it still support ATj6j0 or the moral equivalent?
(On older Telebit products, ATj6j0 returns several lines of status
information including number of retrains, cause of retrain, cause of
NO CARRIER, number of packets discarded because the receiver buffer
was full, number of packets retransmitted, number of framing errors,
number of overrun errors, size of long and short packets,
transmit/receive mode (long, short/long, micro/long), MNP class, and
other amazingly useful stuff.)cec@cup.portal.com (Cerafin E Castillo) (01/08/91)
From my discussion with Telebit, ATJ6J0 has been replaced by AT~D1.
No specifics as to its use were documented in the manual. Please
contact Telebit Tech Support for more info.
===============================================================================
Cerafin E. Castillo || //\\ ||\\ ||
Network Consultant || //__\\ || \\ || Los Altos
Los Altos Networks || // ---\\|| \\|| Networks
340 Second St. #6 ||___// \ | \ |
Los Altos, CA 94022
(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
INTERNET: cec@cup.portal.com
"...No hay mal que por bien no venga..."
===============================================================================dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (01/10/91)
In article <1991Jan6.004019.13502@odi.com> benson@odi.com (Benson I. Margulies) writes: >... I really don't see how the use of compression and the like >with UUCP can be any different than for anything else, but I'm >not the modem expert. Much UUCP traffic is already compressed (ie compressed, batched news transmissions). Attempting to recompress a byte stream that is already compressed will usually INCREASE the total size of the stream, thus decreasing throughput. If you use uucp to download sources from archive sites such as uunet, that stuff is generally compressed as well. Our uucp Dialer entry for uucico use on Telebits disables compression and explicitly requests uucp spoofing. Dan --- -- Daniel A. Graifer Coastal Capital Funding Corp. Sr. Vice President, Financial Systems 7900 Westpark Dr. Suite A-130 (703)821-3244 McLean, VA 22102 uunet!fciva!dag fciva.FRANKCAP.COM!dag@uunet.uu.net
casey@gauss.llnl.gov (Casey Leedom) (01/17/91)
Just got two T1600s for evaluation.
1. The new command set is pretty rational, but you have to play
tricks to disable ESCAPE (`+'), XON (`^Q') and XOFF (`^S') for
dial in and hardware flow control purposes. You have to set the
ESCAPE (S2), XON (S56) and XOFF (S57) characters to values
greater than 127 and make sure the control character mask
(S48) is set to 0 to prevent the control characters from being
recognized.
I preferred the old scheme of specifying that the ESCAPE should
either function as an ESCAPE or simply be treated as any other
data character. I also don't understand why the T1600 continues
to process XON/XOFF when I specify that I want only RTS/CTS
hardware flow control with no XON/XOFF flow control.
2. There is no factory prestored configuration for auto-baud dial
in applications other than one which sends result codes at the
DTE! Sheese!
Actually I disagree with Cerafin with regard to using the
prestored configurations. My inclination is not to bother
with them and do everything yourself. You know more about
your application needs than any number of Telebit engineers
guessing can. Besides, it's not that hard. All the knobs are
pretty simple to use.
3. The T1600 is holding the connection from my new house to our
T2500 rack!!!! My T2500 is unable to hold a V.32 connection
to the same T2500 rack. Thus, the V.32 implementation in the
T1600 looks to be better than that in the T2500 already!
I've talked to Telebit about V.32bis and PEP upgrades to the T1600 and
have been told that they are coming within six months. No figure on how
much it would cost or if they would charge more for a T1600 with V.32bis
and/or PEP.
More information later when/if I find anything interesting.
Caseycasey@gauss.llnl.gov (Casey Leedom) (01/18/91)
| From: kadie@cs.uiuc.edu (Carl M. Kadie) | | >From: casey@gauss.llnl.gov (Casey Leedom) | > | > I've talked to Telebit about V.32bis and PEP upgrades to the T1600 and | >have been told that they are coming within six months. No figure on how | >much it would cost or if they would charge more for a T1600 with V.32bis | >and/or PEP. | | I wonder if they could add fax to the modem too? Actually I'm very worried about this. What I've heard is that there'll be a new modem designated as the T3000 which will actually just be the same hardware as the T1600 but with support in the PROM for V.32bis and PEP. I can see them doing something similar with FAX support. I'm kind of torn on this issue. On the one hand I think that supporting more than one PROM set is silly, detracts from Telebit's resources and therefore increases Telebit's overhead costs and my costs for the modem. On the other hand, I couldn't give a rat's ass about FAX support and don't want my price for the modems to increase to cover the cost of developing FAX support. Oh well, I sure wish we could get past guessing what the upgrade options are going to be and when they're going to be available. I'm still upset that the best Telebit can promise for V.32bis support is ``within six months.'' V.32bis has been in DRAFT standard for more than six months. Very little changes between DRAFT standards and final approved standards. Is Telebit really waiting for the final vote to go down (the voting period ends at the end of January) before starting on their implementation of V.32bis??? If they're going to get buried by companies like USR which are already announcing V.32bis products. Don't get me wrong, I'm not truly unhappy with Telebit yet, but I sure wish I had a better feeling about them right now. We decided on telebits because of their reputation for reliable modems and always offering an upgrade path when they brought out new modems. But that doesn't help much if they don't bring out new modems incorporating the latest international standards till everyone else has had product out for six months or a year ... Casey P.S. On the positive side, the T1600 evaluation is going great. It's a nice modem (establishes and holds the connections I care about), is pretty well documented (but what values is one supposed to put in S59????) and the command set is pretty well thought out.
tnixon@hayes.uucp (01/18/91)
In article <89706@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes: > Oh well, I sure wish we could get past guessing what the upgrade > options are going to be and when they're going to be available. I'm > still upset that the best Telebit can promise for V.32bis support is > ``within six months.'' V.32bis has been in DRAFT standard for more than > six months. Very little changes between DRAFT standards and final > approved standards. Is Telebit really waiting for the final vote to go > down (the voting period ends at the end of January) before starting on > their implementation of V.32bis??? If they're going to get buried by > companies like USR which are already announcing V.32bis products. I'm not writing in defense of Telebit in particular, but of modem companies in general. I hope users understand that although V.32bis is backward compatible with V.32 and is similar in many respects, it is an order of magnitude more difficult to make a V.32bis modem work _well_. You're talking about the difference between a 32-point constellation (32 different phase/amplitude states) in V.32, and a 128-point constellation (128 different phase/amplitude states) in V.32bis. This requires much more precise components in the analog portion of the modem -- the internal parts of the modem itself much be less noisy, not to mention the phone line itself. It's a considerable engineering job to make a GOOD V.32bis modem. Sure, it's easy to slap one together on basically the same platform you used for V.32, but that won't be a very good modem (unless you had significantly over-engineered your V.32 modem to start with). What I'm saying is, don't be surprised if companies that are cautious about making sure they "do it right the first time" take a few months or more to ship V.32bis modems. Most companies recognize that the broad market is still just barely beginning to open up to V.32, and there's truly no need to rush V.32bis products to the market just to satisfy the early-adopters. Certainly there is a trade-off between delaying product introduction to make sure you've got it right, versus giving up the business of early-adopters to your competitors -- but isn't that better that frustrating those early-adopters by enrolling them in the "ROM of the Month Club" and effectively using them as involuntary beta-testers? It took six years for V.32 modems to become of sufficiently high quality and low price to be acceptable to the broad market. I jsut can't see why someone would predict a disaster if it takes a particular company a year to do V.32bis. I mean, God Forbid everyone doesn't have V.fast modems ready to ship on the day Study Gropu XVII approves the standard! -- 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
casey@gauss.llnl.gov (Casey Leedom) (01/19/91)
| From: tnixon@hayes.uucp (Toby Nixon) | | ... although V.32bis is backward compatible with V.32 and is similar in | many respects, it is an order of magnitude more difficult to make a | V.32bis modem work _well_. ... This requires much more precise components | in the analog portion of the modem ... | | It took six years for V.32 modems to become of sufficiently high quality | and low price to be acceptable to the broad market. I just can't see why | someone would predict a disaster if it takes a particular company a year | to do V.32bis. I mean, God Forbid everyone doesn't have V.fast modems | ready to ship on the day Study Group XVII approves the standard! But I want it now! :-) Actually, I thought the big issue wasn't analog components -- high quality analog components have been available for years -- but the signal processing requirements for V.32 that held it up. It just strikes me that all the requisite components are already available to do V.32bis. But, to be honest, the thing that's really bugging me about Telebit right now is that they keep on giving me the impression that they're waiting for final approval of V.32bis before they even start! I had to squeeze them to even admit that they would make V.32bis available. I'm not asking them to commit on a firm delivery date. I'm just asking them to tell me that they working on the problem now. If they don't start until final approval, they'll be way behind many of the other modem manufacturers who are developing product now. This is what happened when they finally decided to do something about V.32. On the other hand, Telebit came out with V.42/V.42bis support fairly expeditiously. And what you say with regard to not wanting to enlist your customers as involuntary BETA testers is definitely true. It's one of the best ways to lose your customers. So I will continue to wait impatiently, but will attempt to hold back my rhetoric. | It's a considerable engineering job to make a GOOD V.32bis modem. Sure, | it's easy to slap one together on basically the same platform you used | for V.32, but that won't be a very good modem (unless you had | significantly over-engineered your V.32 modem to start with). I can only hope that the T1600 is over engineered ... :-( Casey
lstowell@pyrnova.pyramid.com (Lon Stowell) (01/22/91)
In article <89752@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: >| From: tnixon@hayes.uucp (Toby Nixon) >| >| ... although V.32bis is backward compatible with V.32 and is similar in >| many respects, it is an order of magnitude more difficult to make a >| V.32bis modem work _well_. ... This requires much more precise components >| in the analog portion of the modem ... >| >| It took six years for V.32 modems to become of sufficiently high quality >| and low price to be acceptable to the broad market. I just can't see why >| someone would predict a disaster if it takes a particular company a year >| to do V.32bis. I mean, God Forbid everyone doesn't have V.fast modems >| ready to ship on the day Study Group XVII approves the standard! > > But I want it now! :-) > > Actually, I thought the big issue wasn't analog components -- high >quality analog components have been available for years -- but the signal >processing requirements for V.32 that held it up. It just strikes me that >all the requisite components are already available to do V.32bis. > Toby knows well of what he speaks. Actually the analog portion of a modem can have considerable effect even at V.22bis speeds of 2400 bps. Having done modem qualification testing using a TAS and a live international network, it was amazing how much different modems, ALL based on the same digital components, differed in their ability to provide connections on impaired links. V.32bis is pushing the QAM/Trellis technology considerably further than V.32. It matters not whether the impairments to the signal applied to the digital section are impaired inside the modem or outside in the telco network--the results are poor connections. Virtually ANY V.32/V.32bis modem will connect on average to slightly-below average lines. This applies to about 90% or more of all lines in North America--just about any V.32 modem will provide good connections. In Europe, this is only 70% or fewer of the lines... The greater number of code points in the constellation of V.32bis makes it more likely that impairments can shift at least 2 successive points from their intended positions...users of these modems may find it necessary to work WITH their local providers to obtain the newly available Data Conditioned Local loops--which have values for phase and amplitude jitter as well as group delay,-as opposed to the older data jack lines which only provide guaranteed loss figures at 1 KHz...