|
|
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)
******************************
|
or 