Pat, the Editor

27 Years of the Digest ... founded August 21, 1981

Classified Ads
TD Extra News

Add this Digest to your personal   or  

 
 
Message Digest 
Volume 28 : Issue 247 : "text" Format

Messages in this Issue:
  Re: Texting (and cell phone usage) while driving movie: the consequences 
  Re: Texting (and cell phone usage) while driving movie: the consequences 
  Re: Texting (and cell phone usage) while driving movie: the consequences 
  Re: Dr. James Marsters, TTY deaf service developer 
  Re: Dr. James Marsters, TTY deaf service developer 
  Re: Dr. James Marsters, TTY deaf service developer 
  Re: Texting (and cell phone usage) while driving movie: the consequences 
  Re: Tymnet 
  Re: Where Have You Gone, Bell Labs? 


====== 27 years of TELECOM Digest -- Founded August 21, 1981 ====== Telecom and VOIP (Voice over Internet Protocol) Digest for the Internet. All contents here are copyrighted by Patrick Townson and the individual writers/correspondents. Articles may be used in other journals or newsgroups, provided the writer's name and the Digest are included in the fair use quote. By using -any name or email address- included herein for -any- reason other than responding to an article herein, you agree to pay a hundred dollars to the recipients of the email. =========================== Addresses herein are not to be added to any mailing list, nor to be sold or given away without explicit written consent. Chain letters, viruses, porn, spam, and miscellaneous junk are definitely unwelcome. We must fight spam for the same reason we fight crime: not because we are naive enough to believe that we will ever stamp it out, but because we do not want the kind of world that results when no one stands against crime. Geoffrey Welsh =========================== See the bottom of this issue for subscription and archive details and the name of our lawyer, and other stuff of interest. ---------------------------------------------------------------------- Date: Sat, 05 Sep 2009 19:57:38 -0700 From: Thad Floryan <thad@thadlabs.com> To: redacted@invalid.telecom.csail.mit.edu Subject: Re: Texting (and cell phone usage) while driving movie: the consequences Message-ID: <4AA32522.20209@thadlabs.com> I just wanted to slip in a few final references so we can have closure of this thread that's become off-topic for comp.dcom.telecom without angering Bill (the moderator). The following references should suffice for anyone wishing additional information. The DARPA Grand Challenge was established as a result of a Congressional mandate which was part of the (USA) National Defense Authorization Act of 2001. Section 220 of the FY2001 Defense Authorization Act (H.R. 4205/P.L. 106-398 of October 30, 2000) states, "It shall be a goal of the Armed Forces to achieve the fielding of unmanned, remotely controlled technology such that (1) by 2010, one-third of the aircraft in the operational deep strike force aircraft fleet are unmanned; and (2) by 2015, one-third of the operational ground combat vehicles are unmanned." Item (1) has already been accomplished (re: UAVs, etc.) The successes of the 2007 competition are encouraging and suggest the 2015 goal will also be met: http://www.darpa.mil/grandchallenge/index.asp http://www.darpa.mil/GRANDCHALLENGE/overview.asp http://www.darpagrandchallenge.com/ Additionally, as trickle-down and fallout of the DARPA contests, Southwest Research Institute established MARTI (Mobile Autonomous Robotics Technology Initiative) for autonomous control of cars, trucks, and tractors. http://www.swri.org/4org/d10/its/ivs/marti.htm And some high-end production cars already can automatically parallel park the vehicle on public streets. The ones I know about include Lexus LS460, 2010 Lincoln MKT or MKS (Ford's Active Park Assist), and BMW's Autopark system; there may be others. ------------------------------ Date: Sun, 6 Sep 2009 03:09:05 +0000 (UTC) From: David Lesher <wb8foz@panix.com> To: redacted@invalid.telecom.csail.mit.edu Subject: Re: Texting (and cell phone usage) while driving movie: the consequences Message-ID: <h7v94h$cbu$1@reader1.panix.com> John Levine <johnl@iecc.com> writes: >ObTelecom (Hi, Bill!): Phone switches have been controled by >computers since the 1970s, and they are to put it mildly, rather >reliable. They do this by a combination of conservative EXPENSIVE >hardware design, software designed to be EXPENSIVE & reliable (as >opposed to designed by marketers' wish lists), and redundancy. These >techniques are all equally applicable to automated vehicle controls. Note additions [shown in capital letters in quoted material above]. CO switches & their software are insanely expensive but like a Apollo stack, reliability is not cheap....nor easy in production. [A half-day's car production by the smallest provider exceeds ten year's worth of ESS's...] The failure modes for some of the threats a car faces are predictable & can be engineered around, but not all. There is no doubt that Detroit has done amazing things in reliability, but we have a long way to go before autonomous vehicles will be viable. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433 ------------------------------ Date: Sun, 06 Sep 2009 17:01:39 -0500 From: bonomi@host122.r-bonomi.com (Robert Bonomi) To: redacted@invalid.telecom.csail.mit.edu Subject: Re: Texting (and cell phone usage) while driving movie: the consequences Message-ID: <ermdnZbZcMferDnXnZ2dnUVZ_vydnZ2d@posted.nuvoxcommunications> In article <h7v94h$cbu$1@reader1.panix.com>, David Lesher <wb8foz@panix.com> wrote: >John Levine <johnl@iecc.com> writes: > >>ObTelecom (Hi, Bill!): Phone switches have been controled by >>computers since the 1970s, and they are to put it mildly, rather >>reliable. They do this by a combination of conservative EXPENSIVE >>hardware design, software designed to be EXPENSIVE & reliable (as >>opposed to designed by marketers' wish lists), and redundancy. These >>techniques are all equally applicable to automated vehicle controls. > >Note additions [shown in capital letters in quoted material above]. The addition is *GROSSLY*INACCURATE*. 'Expensive' is not a design criteria of those systems. It is what unavoidably happens when you design for long lifetimes, and very high reliability with minimal maintenance. It's not that difficult to build hardware with a million-hour MTBF, -if- you allot 4-5 hrs for PM every 200 power-on hours. >The failure modes for some of the threats a car faces are predictable & can >be engineered around, but not all. Yup. 'Threat avoidance', or 'threat handling', is generally a relatively _easy_ part of the task. Once you've figured out what to do (in broad terms), figuring out -how- do do it is a comparatively simple decision tree. 'Threat _identification_' (and deciding "what to do") is much harder -- especially when something happens that the designers didn't think about. Like for, example, a piece falling off an airplane and landing on the highway. Or a sinkhole opening up. When the "utterly unexpected", all the pre-planned contingencies go out the window, and it's "what the h*ll do I do _NOW*?" time. Things that 'were' entirely unacceptable (like swerving/crashing into the car beside you) are suddenly back in consideration, when that 50 ton piece of the mountainside falls onto the road 100 ft in front of you. >There is no doubt that Detroit has done amazing things in reliability, but >we have a long way to go before autonomous vehicles will be viable. Make that 'autonomous vehicles _operating_in_an_uncontrolled_environment_', and I'll agree. There are presently numbers of autonomously operating _passenger-_ _carrying_ systems in production use. A number of airports have 'people- mover' systems that transport passengers between terminals, parking, and other facilities, without any on-board 'staff', for one example. ***** Moderator's Note ***** This is veering (pun intended) away from telecom again. ------------------------------ Date: 6 Sep 2009 09:05:40 -0400 From: kludge@panix.com (Scott Dorsey) To: redacted@invalid.telecom.csail.mit.edu Subject: Re: Dr. James Marsters, TTY deaf service developer Message-ID: <h80c34$8ck$1@panix2.panix.com> John Levine <johnl@iecc.com> wrote: >>> Who invented modems that could automatically dial .... >> >>The 'Bell 801 automatic calling unit' handled that, external to the >>modem itself. Existed more than a decade before Hayes. > >It did, but the control of the dialer was separate from the data path. >Hayes' important innovation was to combine the data and control >channel so any old crummy microcomputer with a minimal serial port >could autodial. Actually, at the time there were a bunch of modems (including the Anchor Signalman II) which used the DTR line to control the hookswitch. Doing this allowed software on the computer to toggle the DTR line and pulse-dial the modem. Then it would wait for the CD line to go high when the modem finally detected a carrier and locked up. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." ------------------------------ Date: Sun, 06 Sep 2009 13:32:56 -0400 From: Bill Horne <bill@horneQRM.net> To: redacted@invalid.telecom.csail.mit.edu Subject: Re: Dr. James Marsters, TTY deaf service developer Message-ID: <8Y6dnZM18erUbz7XnZ2dnUVZ_qmdnZ2d@speakeasy.net> Scott Dorsey wrote: > John Levine <johnl@iecc.com> wrote: >> Robert Bonomi wrote: >>> <hancock4@bbs.cpcn.com> wrote: >>>> Who invented modems that could automatically dial .... >>> >>> The 'Bell 801 automatic calling unit' handled that, external to the >>> modem itself. Existed more than a decade before Hayes. >> >> It did, but the control of the dialer was separate from the data path. >> Hayes' important innovation was to combine the data and control >> channel so any old crummy microcomputer with a minimal serial port >> could autodial. > > Actually, at the time there were a bunch of modems (including the > Anchor Signalman II) which used the DTR line to control the hookswitch. > Doing this allowed software on the computer to toggle the DTR line and > pulse-dial the modem. Then it would wait for the CD line to go high > when the modem finally detected a carrier and locked up. > --scott > The "Claim To Fame" for the Hayes modems was, as John Levine pointed out, that it could be used with only a three wire connection. This may seem like a solution in search of a problem today, but return with me now to those thrilling days of yesteryear, prior to the Borg -
  • There was no agreement on what connectors to use: my Heath H89 had both female and male 25 pin connectors for the DTE ports.
  • Retailers would sell anything that looked like a computer cable, no matter what the connector sex, the wire, or the pinout.
  • Operating Systems did NOT have complete control of the serial ports. CP/M required drivers that were written by OEM's, or even by end-users like me, and everyone was in an incredible hurry to get product to market, so "DSR" and "CD" leads were often ignored. Hell, it was hard enough to get the speed right, with some control programs requiring manual setup for the modem speed since they had no "auto detect" capability.
  • Software vendors advertised "technical support" very heavily, but what they provided was a long list of excuses for doing nothing: if the modem lights blinked, they would tell you it was a modem problem and refer you back to your modem vendor.
The Hayes modems worked if you could send them data and receive data, and they succeeded for that reason. It wasn't until the IBM PC took over the "baseline" position in hardware comparisons that a semblance of order was introduced, with DTE ports having male connectors and DCE using female, with machine-to-machine serial connections requiring null-modem cables, and with each OS properly handling supervisory lines. As with the Centronics interface for printers, the Hayes command set became the de facto standard and is used to this day. Bill Horne (Filter QRM for direct replies) ------------------------------ Date: Sun, 06 Sep 2009 16:30:05 -0500 From: bonomi@host122.r-bonomi.com (Robert Bonomi) To: redacted@invalid.telecom.csail.mit.edu Subject: Re: Dr. James Marsters, TTY deaf service developer Message-ID: <Z8CdnSPzdJBAtDnXnZ2dnUVZ_gGdnZ2d@posted.nuvoxcommunications> In article <8Y6dnZM18erUbz7XnZ2dnUVZ_qmdnZ2d@speakeasy.net>, Bill Horne <bill@horneQRM.net> wrote: >Scott Dorsey wrote: >> John Levine <johnl@iecc.com> wrote: >>> Robert Bonomi wrote: >>>> <hancock4@bbs.cpcn.com> wrote: >>>>> Who invented modems that could automatically dial .... >>>> >>>> The 'Bell 801 automatic calling unit' handled that, external to the >>>> modem itself. Existed more than a decade before Hayes. >>> >>> It did, but the control of the dialer was separate from the data path. >>> Hayes' important innovation was to combine the data and control >>> channel so any old crummy microcomputer with a minimal serial port >>> could autodial. >> >> Actually, at the time there were a bunch of modems (including the >> Anchor Signalman II) which used the DTR line to control the hookswitch. >> Doing this allowed software on the computer to toggle the DTR line and >> pulse-dial the modem. Then it would wait for the CD line to go high >> when the modem finally detected a carrier and locked up. >> --scott >> > >The "Claim To Fame" for the Hayes modems was, as John Levine pointed >out, that it could be used with only a three wire connection. This may >seem like a solution in search of a problem today, but return with me >now to those thrilling days of yesteryear, prior to the Borg - > >* There was no agreement on what connectors to use: my Heath H89 had > both female and male 25 pin connectors for the DTE ports. Actually, there was a 'default' standard. Before the micro-processor rage, most CPE (DTE and DCE) had DB-25M(!!) connectors, and cables were DB-25F <-> DB-25F, and came in precisely two varieties -- 'straight through', or 'null-modem' -- with -all- the signals carried. Modems and directly related devices were wired as DCE, and everything else was wired as DTE. Even 'glass' terminals with a capability to 'add on' a hard-copy device often had the same connectors for both the modem and the printer. When the hobby market developed, then things got seriously messy. If a computer was connected to a modem, it needed to look like DTE, because the modem was DCE. If it was connected to a terminal (or a printer, or, ....) it needed to look like DCE, because that 'other device' was hard-wired as DTE. "Some people" started differentiating the DCE/DTE ports on the computer with different connectors (usually by selection of gender). With NO agreement on gender -- they couldn't have 'agreement' if the various manufacturers weren't talking to each other, and they weren't. Heck, you couldn't even count on what KIND of a connector (if any!) was provided -- remember for the home market, a lot of this was 'kit' stuff, and a kit-builder was expected to supply most of the 'routine' parts themself. This kind of 'help' actually caused more problems than it solved. Now you had to find a cable with the right kind of a 'bastard' connector on the one end, and the proper wiring to the (more-or-less) standard connector on the other end. Did I mention that multiple manufacturers might use the same kind of 'non-standard' connector, with inconsistent usage of the pins on that connector? *SNARL* At least one vendor "got cute", and used a connector that could be plugged in two ways. One way, you got DTE, turn it over and you had DCE. This WAS 'really handy' a lot of the time, but it was a maintenance nightmare -- the plug wasn't labelled, and if it got 'unintentionally' unplugged, there was no way to tell which way was the 'right' way to reconnect. >* Retailers would sell anything that looked like a computer cable, > no matter what the connector sex, the wire, or the pinout. Yup. and it was the "right cable" for some hook-up, somewhere. Of course, figuring out "what" it was right for was almost as big a challenge as figuring out whether a box of unlabelled floppy disks could be used in your machine. (assuming you were one of the 'rich guys' with a floppy drive, that is. :) >* Operating Systems did NOT have complete control of the serial > ports. CP/M required drivers that were written by OEM's, or even by > end-users like me, and everyone was in an incredible hurry to get > product to market, so "DSR" and "CD" leads were often ignored. Hell, > it was hard enough to get the speed right, with some control programs > requiring manual setup for the modem speed since they had no "auto > detect" capability. It was even worse than that. In the early days, lots of "serial ports" simply did NOT have anything for the 'other' lines in the RS-232 specification. "Full serial port" chips were *EXPENSIVE*, but you could handle TxD and Rxd with little more than a couple of transistors, and (maybe a 'buffer' chip). *SOMETIMES* some of the other signals were 'faked' by hard-wiring to +12 or ground, other times the kit instructions suggested simply jumpering certain pins together, to 'fool' whatever was on the other end. But, frequently, all those pins were simply left "N/C". ------------------------------ Date: Sun, 06 Sep 2009 10:23:02 -0700 From: Sam Spade <sam@coldmail.com> To: redacted@invalid.telecom.csail.mit.edu Subject: Re: Texting (and cell phone usage) while driving movie: the consequences Message-ID: <WdSom.183463$Qg6.107225@newsfe14.iad> John Levine wrote: > > ObTelecom (Hi, Bill!): Phone switches have been controled by computers > since the 1970s, and they are to put it mildly, rather reliable. They > do this by a combination of conservative hardware design, software > designed to be reliable (as opposed to designed by marketers' wish > lists), and redundancy. These techniques are all equally applicable > to automated vehicle controls. > > R's, > John > Picking at Nits: some phone switches became computer controlled, starting with the first one in 1965. The nation-wide conversion wasn't complete until the early 1990s. In the early days of the No 1 ESS total control failure, although unusual, was not rare. Some of it was previously undetected software errors in program control, others were hardware failures. Even more common were line-control module failures, which tended to knock out several hundread customers, but not nearly the entire office. I wouldn't have wanted a No 1 ESS control system running my car. Not until the time division (digital) switches come along did we have true 100% computer controlled end-office switching. ------------------------------ Date: Sun, 6 Sep 2009 11:13:21 -0700 (PDT) From: "harold@hallikainen.com" <harold@hallikainen.com> To: redacted@invalid.telecom.csail.mit.edu Subject: Re: Tymnet Message-ID: <33469c77-f00b-4392-b214-a13488059555@x25g2000prf.googlegroups.com> I've enjoyed reading this history of Tymnet. I used Tymnet, or maybe Telenet, to connect to The Source in the late 1970s or early 1980s. On weekends, The Source cost about $2.50 per hour. It cost me another $5 per hour to call from San Luis Obispo CA to Ventura CA where the closest network dial-in was. So, I spent $7.50 per hour to use The Source. I used their MC6800 cross assembler to develop my first processor based product before I had a computer. Later I got a Cromemco Z-80 system and did development on that. Cal Poly San Luis Obispo also had open dial-in modems where you could telnet to pretty much anywhere. So, I got an account on the Cleveland Freenet. I then had access to Internet email. Stuff has changed... Harold ------------------------------ Date: Sun, 06 Sep 2009 16:17:47 -0400 From: Steve Stone <n2ubp@hotmail.com> To: redacted@invalid.telecom.csail.mit.edu Subject: Re: Where Have You Gone, Bell Labs? Message-ID: <h815df$dv0$1@news.eternal-september.org> > At my previous residence, as with my current residence, I maintain a land > line with only very basic service, the kind that costs about twenty dollars > a month In my area you can tack on another $12 - $15 in taxes and surcharges to that basic service. ------------------------------ TELECOM Digest is an electronic journal devoted mostly to telecom- munications topics. It is circulated anywhere there is email, in addition to Usenet, where it appears as the moderated newsgroup 'comp.dcom.telecom'. TELECOM Digest is a not-for-profit, mostly non-commercial educational service offered to the Internet by Patrick Townson. All the contents of the Digest are compilation-copyrighted. You may reprint articles in some other media on an occasional basis, but please attribute my work and that of the original author. The Telecom Digest is currently being moderated by Bill Horne while Pat Townson recovers from a stroke. Contact information: Bill Horne Telecom Digest 43 Deerfield Road Sharon MA 02067-2301 781-784-7287 bill at horne dot net Subscribe: telecom-request@telecom-digest.org?body=subscribe telecom Unsubscribe: telecom-request@telecom-digest.org?body=unsubscribe telecom This Digest is the oldest continuing e-journal about telecomm- unications on the Internet, having been founded in August, 1981 and published continuously since then. Our archives are available for your review/research. We believe we are the oldest e-zine/mailing list on the internet in any category! URL information: http://telecom-digest.org Copyright (C) 2009 TELECOM Digest. All rights reserved. Our attorney is Bill Levant, of Blue Bell, PA. ************************ --------------------------------------------------------------- Finally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of fifty dollars per year per reader is considered appropriate. See our address above. Please make at least a single donation to cover the cost of processing your name to the mailing list. All opinions expressed herein are deemed to be those of the author. Any organizations listed are for identification purposes only and messages should not be considered any official expression by the organization. End of The Telecom digest (9 messages) ******************************

Return to Archives**Older Issues