TELECOM Digest     Thu, 26 May 94 14:55:00 CDT    Volume 14 : Issue 255

Inside This Issue:                           Editor: Patrick A. Townson

    Re: Caller ID With Serial Port (John Harris)
    VIVE Caller ID Device Problems (Evan Gamblin)
    Even More on VIVE Caller ID Box (Dan Lanciani)
    Need Distinctive Ring Line Splitter (Al Cohan)
    Re: Replace POST-MAIL by FAX (Timothy L. Kay)
    Re: What Kind of Capacity is in VBI? (Robert Berger)
    Re: "Erlang" the Programming Language (Steven King)

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and GEnie.
It is also gatewayed to Usenet where it appears as the moderated
newsgroup 'comp.dcom.telecom'. 

Subscriptions are available at no charge to qualified organizations
and individual readers. Write and tell us how you qualify:

                 * telecom-request@eecs.nwu.edu *

The Digest is edited, published and compilation-copyrighted by Patrick
Townson of Skokie, Illinois USA. You can reach us by postal mail, fax 
or phone at:
                    9457-D Niles Center Road
                     Skokie, IL USA   60076
                       Phone: 708-329-0571
                        Fax: 708-329-0572
  ** Article submission address only: telecom@eecs.nwu.edu **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

*************************************************************************
*   TELECOM Digest is partially funded by a grant from the              *
* International Telecommunication Union (ITU) in Geneva, Switzerland    * 
* under the aegis of its Telecom Information Exchange Services (TIES)   * 
* project.  Views expressed herein should not be construed as represent-*
* ing views of the ITU.                                                 *
*************************************************************************

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

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

Date: Thu, 26 May 94 17:43 WET
From: joharris@io.org (John Harris)
Subject: Re: Caller ID With Serial Port


ddl@das.harvard.edu wrote:

> joharris@io.org (John Harris) wrote:

>> Try contacting  Vive Synergies Inc., 
>>                 30 West Beaver Creek Road, Unit 2,
>>                 Richmond Hill, Ontario  L4B 3K1
>>                 (905) 882-6107   Fax (905) 882-6238

>> This manufacturer advertises in the local paper as having a "CALL
>> EDITOR II" for $199.00

> Beware of this device.  The design is seriously flawed and Vive isn't
> interested in fixing it.  Here is something I wrote about it a while
> back when I (foolishly) bought one from HAL.  (HAL sells Vive's Call
> Editor II, obviously ...)

> The HAL box also has a fairly severe bug.  When a call comes in, you
> see a lot of garbage characters on the RS-232 interface before the
> actual CNID string.  Worse, what you are seeing is the box's echo
> of garbage characters that it thinks came in over the RS-232
> interface. 

/* text deleted */

> The third person said that it is the fault of the CNID chip that they
> use and cannot be fixed.  He insisted that all I needed to do was
> write a ``software filter'' to ignore the garbage.  He did not seem to
> understand that their command interpreter was seeing the garbage and
> could generate spurious dial commands (or who knows what else).  He
> also said that this isn't a problem with telephones in Canada (where
> they are).

It's true.  In Bell Canada territory, we are almost exclusively DMS-100
switches; and there are fewer problems than elsewhere.

I thought I recognized a problem typical of the GTD-5 switch with a
Motorola MC145447 Caller ID chip.  So I forwarded Dan's comments to
VIVE Synergies.

>             An ``engineer'' is supposed to get back to me sometime so I
> can tell him how to fix the firmware...

> (Needless to say, the engineer never called back.)

I will concede to Dan that some companies are hard to get hold of; but
having Carl's extension number makes a big difference.

The following comes from VIVE.  For point number 3, I confess.  It was 
I that didn't read the ad close enough to see that software was included,
too.


John Harris      BEL-Tronics Ltd, 2422 Dunwin Drive           
                       Mississauga, Ontario L5L 1J9
joharris@io.org  (905) 828-1002  Fax (905) 828-2951


[TELECOM Digest Editor's Note: The letter from John Harris included a
reply from VIVE, but that letter was also forwarded directly to me by
Evan Gamblin ... so I have deleted it here and present it as a stand-
alone message on its own immediatly following this one.   PAT]

------------------------------

Date: Wed, 25 May 1994 22:20:59 -0400
From: egamblin@ott.hookup.net (Evan Gamblin)
Subject: VIVE Caller ID Device Problems 


In an earlier message, Dan Lanciani (ddl@harvard.*) wrote:

>> Try contacting  Vive Synergies Inc.,
>>                 30 West Beaver Creek Road, Unit 2,
>>                 Richmond Hill, Ontario  L4B 3K1
>>                 (905) 882-6107   Fax (905) 882-6238

In the interests of getting Dan an answer, and maybe getting this
fixed, I forwarded the above to Vive (with whom I have no other
connection).  The president, Carl K.S. Too, replies as follows:

1. Call Editor II is a product that we supply:

i.   as part of a package consisting of Call Editor II + WindowsHinge, an
     interfacing software for use with all Windows applications in general
     and with ACT! For Windows in particular,
ii.  as part of a package consisting of Call Editor II + VIVE Vision,
     contact management software running under DOS and published by us, or
iii. as a hardware component with Caller ID capability for bundling with
     specific applications software (as in the case of HAL).

We supplied Call Editor II to Home Automation Laboratories (HAL) for use
with its Dynasty software.

2.  The Caller ID decoder used in Call Editor made by Sierra has some
inherent limitation in that it does not lend itself to noise filtering
to eliminate the noises that occur on the telephone line.  As such we
have to implement noise-filtering function in the software for use
with Call Editor II. Both WindowsHinge and VIVE Vision have such noise
filters implemented in the software. I believe Dynasty software has it
as well.

Dan Lanciani should have been advised of the limitation of use. In any
event HAL should not have offered Call Editor II for sale to people
who are not prepared or who do not have the knowledge to develop the
noise-filtering programs in their application software.

3. It was wrongly quoted in the previous message that "this mfr
advertises in the local paper as having a Call Editor II for $199".
The fact is Call Editor II + WindowsHinge as a package is offered at
C$199 in Canada and at US$149 in USA.

4. Dan Lanciani is only partially correct in his surmise about the
circuit design of Call Editor II. While we do not wish to discuss
details of our design, we would comment that the suggestion detailed
by Dan Lanciani for improvement to the hardware firmware is a valid
one, but our engineers believed that such modification would not be
sufficient to overcome the inherent weakness of the Caller ID decoder
used, with repect to the noises and the resultant stray characters. An
engineer would have contacted Dan Lanciani to discuss the technical
aspects of the proposed modifications with him if not for the fact
that unfortunately the telephone number given by Dan Lanciani was
inadvertently misplaced and lost.

However, readers should know that Dan Lanciani's experience with Call
Editor II is at least 6 months old. In our industry 6 months is a long
time. We have made many improvements to the product and have
introduced some other products for Caller ID applications in this
period.

Dan Lanciani is invited to call me to discuss our current products or
provide us with his mailing address so that we may mail him current
product information on our Caller ID products, including a multi-line
adaptor known as Concentrator (for use with multiple telephone lines
in a LAN environment) and a recent release known as TeleServer.


5. Call Editor II works very well with WindowsHinge and VIVE Vision as
they are designed to do.

6. Readers may be interested to know that we make another product
known as Call Editor RSA which uses a different Caller ID decoder that
enables it to output decoded data without "garbage" characters.
However, unlike Call Editor II it is not capable of standalone
operation, and must be used with a computer.

Dan Lanciani is advised to use Call Editor RSA for his application
instead of Call Editor II. With Call Editor RSA, he would not have to
worry about any noise interference.

Call Editor RSA + WindowsHinge as a package is being offered at
C$119.99 in Canada and at US$89.99 in USA. Call Editor RSA (as a
separate unit) is offered at US$80 in USA and C$100 in Canada.


Carl K.S. Too
President
VIVE Synergies Inc. 30 West Beaver Creek Rd, Unit 2, Richmond Hill, Ont
L4B 3K1. Tel 905 882-8107, ext 11. Fax: 905 882-8238

                  --------------------

Evan Gamblin   The Halifax Group
903-275 Sparks St  Ottawa, Ont K1R 7X9 Canada


[TELECOM Digest Editor's Note: In the next message in this issue, Dan
gives his response to the comments by Carl Too.   PAT]

------------------------------

Date: Wed, 25 May 94 20:22:18 EDT
From: ddl@das.harvard.edu (Dan Lanciani)
Subject: Even More on VIVE CNID Box


I'm sorry, but I can't let this pass without further comment:

 From joharris@io.org Wed May 25 17:43:56 1994

> ddl@das.harvard.edu wrote:

>> joharris@io.org (John Harris) wrote:

>>> Try contacting  Vive Synergies Inc., 
>>>                 30 West Beaver Creek Road, Unit 2,
>>>                 Richmond Hill, Ontario  L4B 3K1
>>>                 (905) 882-6107   Fax (905) 882-6238

>>> This manufacturer advertises in the local paper as having a "CALL
>>> EDITOR II" for $199.00

>> Beware of this device.  The design is seriously flawed and Vive isn't
>> interested in fixing it.  Here is something I wrote about it a while
>> back when I (foolishly) bought one from HAL.  (HAL sells Vive's Call
>> Editor II, obviously ...)

>> The HAL box also has a fairly severe bug.  When a call comes in, you
>> see a lot of garbage characters on the RS-232 interface before the
>> actual CNID string.  Worse, what you are seeing is the box's echo
>> of garbage characters that it thinks came in over the RS-232
>> interface. 

[my original technical description deleted]

Let me try once more to describe the problem.  I think maybe it's
so simple that some people are missing the forest for the trees
looking for a more subtle/complicated interpretation.

The device in question connects to the phone line and to an RS-232
serial interface.  The RS-232 interface presents a very simple command
interpreter "shell" to the user.  There are a few commands that the
user can type at this shell, including a Dial and a List command.

The microcontroller within the device has a single, built-in,
bi-directional serial port.  The output side of this port is routed
directly to the RS-232 interface.  The input side of this port is
switched between the RS-232 interface and a caller ID chip's serial
output.  In other words, some of the time the microcontroller is
receiving user keystrokes and sometimes it is receiving the output of
the caller ID chip -- all through a single serial port.  The
microcontroller uses one of its parallel output bits to switch between
the two uses of the serial port.  Most of the time the port is
connected to the RS-232 interface.  However, when a call is detected,
the port is switched to the caller ID chip.

The problem is that the microcontroller takes some bytes from the
caller ID chip as "shell" input.  That is, it thinks the user typed
these bytes at the RS-232 interface.  This may be caused by a failure
to clear the serial buffers after switching usage or perhaps by
setting usage flags at the wrong time.  The net result is that the
simple "shell" believes that the user (or program) has sent it these
bytes as commands.  Being an interactive ``shell,'' it echos the
garbage bytes back out the RS-232 interface AND ACTS ON THEM.  In just
a few minutes of trials I saw the box generate several unknown-command
messages when the garbage bytes managed to include a return character.
It is just a matter of time until the bytes include a "D" and a
return ... all the "filter" software in the world isn't going to
prevent this since it happens entirely within the unit.

If anybody is interested in examining the device, I'd be happy to make
mine available for loan.  (It certainly isn't going to be connected to
my phone line. :) Just cover the postage.  I suggest this might be a
good idea for anyone considering purchase.

[...]

> It's true.  In Bell Canada territory, we are almost exclusively DMS-100
> switches; and there are fewer problems than elsewhere.

This is not a switch problem.

> I thought I recognized a problem typical of the GTD-5 switch with a
> Motorola MC145447 Caller ID chip.  So I forwarded Dan's comments to 
> VIVE Synergies.

I don't see how you could have concluded this from my comments.  The
problem is not with the caller ID chip.  It is with the incorrect
manipulation of the microcontroller's serial port.  Please re-read my
original explanation or the new one above.

[...]

> The following comes from VIVE.  For point number 3, I confess.  It was 
> I that didn't read the ad close enough to see that software was included,
> too.

> Response to Dan Lanciani's statements (surmises) on Call Editor II

[Comments following are from Too's response]

> 2. The Caller ID decoder used in Call Editor made by Sierra, has
> some inherent limitation in that it does not lend itself to noise
> filtering to eliminate the noises that occur on the telephone
> line.As such we have to implement noise-filtering function in the
> software for use with Call Editor II. Both WindowsHinge and VIVE
> Vision have such noise filters implemented in the softwares. I
> believe Dynasty software has it as well.

This is obfuscation.  You are confusing the interface of the caller id
chip (which is a component of your product) with the external
interface of the product itself.  You have a microcontroller in
between these two interfaces.

> Dan Lanciani should have been advised of the limitation of use.

Indeed.  The limitation is that it cannot be used reliably.

> In any event HAL should not have offered for Call Editor II for sale
> to people who are not prepared or do not have the knowledge to develop
> the noise-filtering programs in their application software.

This is more obfuscation combined with an almost-clever insult.  No
"noise-filtering programs" will help since the "noise" is being seen
and processed by the command interpreter of the product before it ever
gets to the external interface!

> 4.  Dan Lanciani is only partially correct in his surmise about the
> circuit design of Call Editor II.

Enlighten us!  As I mentioned, my analysis was based on only a few
minutes with a logic probe, and some of the ICs have their part
numbers obscured.  Still, it's hard to hide the functioning of such a
simple circuit.  A few years ago I would have fixed the firmware
myself just for an exercise.  Now, time has become too valuable.
Besides, there are plenty of competitive solutions that work out of
the box.

> While we do not wish to discuss details of our design,

If it were my design, I'd be embarrassed to discuss the details too.

> we would comment that the suggestion detailed by Dan Lanciani for
> improvement to the hardware firmware is a valid one but our engineers
> believed that such modification would not be sufficient to overcome
> the inherent weakness of the Caller ID decoder used with respect to
> the noises and the resultant stray characters.

Sorry, wrong answer.  The problem isn't with the caller ID decoder
chip.  It's how you use it.  Regardless of what "noise" the chip puts
out on its serial line, there is simply no excuse for sending those
bytes into your command interpreter.  You _know_ when the serial input
of the microcontroller is switched to the caller ID chip.  You should
not be treating caller-ID-chip-generated bytes (be they garbage or
valid characters) as user keyboard input.

> An engineer would have contacted Dan Lanciani to discuss the
> technical aspects of the proposed modifications with him if not for
> the fact that, unfortunately, the telephone number given by Dan
> Lanciani for contact was inadvertently misplaced and lost.

No comment.

> However, the readers should know that Dan Lanciani's experience
> with Call Editor II is at least 6 months old. In our industry 6
> months is a long time. We have made many improvements to the product ...

So, exactly what changes have you made and do they fix the problem?
Are you sending out firmware updates?  If, as you say above, you
didn't implement my suggestions, then how did you improve the situation?

> and have introduced some other products for Caller ID applications in 
> this period.

[remainder of advertisement deleted]

> 5. Call Editor II works very well with WindowsHinge and VIVE Vision
> as they are designed to do.

I truly look forward to the day when just the right combination of
"noise" has one of these units repeatedly generating hang-up calls to
a nice, litigious subscriber. :) Seriously, though, it's devices like
this that contribute to the growing problem of "flakey" systems.  They
work a lot of the time and we are expected to simply tolerate the
glitches as long as nothing too bad happens.  We build bigger systems
around them and then try to patch the problems with "filters" (otherwise 
known as quick hacks).  Eventually, circumstances conspire to make the
whole fail in an unpleasant way.  Then we start talking about software
engineering and project management and ...  (Well, this is turning into
a RISKS posting.)

> Dan Lanciani is advised to use Call Editor RSA for his application
> instead of Call Editor II. With Call Editor RSA,  he would not have
> to worry about any noise interference.

Gee, thanks, but no thanks.  I'm perfectly happy with the simple,
direct caller ID<->RS232 interface I'm now using.  It generates plenty
of garbage characters, but it doesn't have a microcontroller trying to
act on them to dial my phone.  In any case, I think this answers my
question about whether the Call Editor II was fixed ...

> Carl K.S. Teo
> President,VIVE Synergies Inc., 30 West Beaver Creek Road, Unit 2,
> Richmond Hill, Ontario L4B 3K1.
> Tel:  905-882-6107 Ext.11,  Fax: 905-882-6238 

[address left for reference]


Dan Lanciani    ddl@harvard.*

------------------------------

Date: Thu, 26 May 94 12:32 EST
From: Al Cohan <0004526627@mcimail.com>
Subject: Need Distinctive Ring Line Splitter


I purchased a device from Lynx Automation, Inc. in Washington State
and the device is purported to sense the incoming ring cadence an
forward the call to either a phone system or fax. This unit is
available in two and four line versions corresponding to the four
distinct industry standard cadences available.

We now come to find out that the company says "Oh, it sometimes
doesn't work with 1A2 and some PBX's. It seems to work okay with the
newer electronic key systems". Well I am steamed! MY client is not
about to upgrade to a new system nor pay the $100 installation charge
for a residential line plus about $26.00 per month for low fax usage.

The select-a-ring option only cost $9 to install and $4 - $5 per month
for the second number on the line.

Now, what do I do? My client thinks I'm a damn fool and don't know
what I'm doing -- and isn't about to get a separate fax line.

Does anyone on the net know of another company or companies that
manufacture a ring decoder that actually *works*?  


Thanks in advance,

Al Cohan

------------------------------

From: timkay@netcom.com (Timothy L. Kay)
Subject: Re: Replace POST-MAIL by FAX
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Date: Thu, 26 May 1994 18:30:27 GMT


Herb Effron (herb@halcyon.com) wrote:

> I have never had a fax machine. Instead, I use a 14.4 fax modem (which is

>  New way #1:
> I now send a "Quick Fax" -- when I want to ask a brief question or
> New way #2:
> I now send _only_ fax correspondence (in place of 'paper') whenever

I agree that the concept of using a fax modem to handle my correspondences 
seems a good idea.  Unfortunately, I find that technology is letting me down.
Unlike Herb, I am trapped in the world of Microsoft Windows, and I have been 
unable make fax software work reliably.  I have tried Delrina (the market 
leader) Winfax Pro 3.0 and 4.0 and Sofnet Faxworks Pro 3.0. None of these 
packages will reliably receive faxes.  Winfax Pro 3.0 was by far the
best, but it has a very poor user interface.  The other two packages
are quite unreliable at receiving faxes.  And the upgrade to Winfax
4.0 disables version 3.0.  I'm finally so disgusted that I now leave
my old, dusty, curly-paper fax machine turned on to receive faxes.

Details: I am using a Supra Fax Modem V.32bis which is on the approved
list from both Delrina and Sofnet.  I upgraded to Supra's latest ROM
to make sure that the modem wasn't at fault.  My testing consists of
trying to receive a fax-back catalog from various companies.  The
testing is repeatable, and invariably fails with Winfax Pro 4.0.  It
is slightly less unreliable with Faxworks Pro 3.0 but still fails
frequently.  As I said, I can no longer test Winfax Pro 3.0.  My dusty
fax machine has no trouble receving any faxes.

I tried faxing a question to Delrina.  My note was very explicit, and
mentioned all relevant information.  I received back from them a fax
stating that, if I am to receive help from them via fax, then I must
fill out the attached form.  They then also included a ten page
document of troubleshooting tips which was completely inappropriate
for the problems I was experiencing.  To make matters worse, they had
problems sending the fax to me and kept trying, so I ended up with
about 50 pages of curly paper.  I have as yet been unable to get an
answer from Delrina.

For those of you familiar with the software, I will also mention that
I have applied the latest Winfax Pro 4.0 patches from Delrina.  Their
patch program took an hour to run!  And it didn't fix any problems.

D E L R I N A, are you out there??  All indications are that you have
many unhappy (want-to-be) users out here.

And I know it isn't my modem.  I talked to another user of Winfax Pro
4.0 who has a completely different modem, and he was having identical
problems.  We had to revert from the nifty concept of computer-to-computer-
communications-via-fax-modems to the (relatively) old-fashioned paper-to-
paper-via-fax-machines.

As for the matter of sending faxes, all of the programs work flawlessly.  
And I paste a scanned signature, and nobody ever complain. Personally, I 
would never accept a faxed signature, but that is a different matter.


Tim

------------------------------

From: rwb@alexander.alias.cs.cmu.edu (Robert Berger)
Subject: Re: What Kind of Capacity is in VBI?
Organization: School of Computer Science, Carnegie Mellon
Date: Thu, 26 May 1994 19:07:57 GMT


> A question I have is, for a U.S. signal, which I believe the Vertical
> Blanking Interval also exists, how much capacity is available on a
> single TV channel and at what speed can the data be sent? Is this
> related to closed captioning?  If not, what type equipment is needed
> to decode VBI data and what kind of costs are involved to build it?

The WST standard for NTSC puts 32 bytes on a VBI line. These lines are
per field, so with one VBI line you get:

    32 bytes x 8 bits/byte * 60 fields/second = 15 kbps

If you use all 10 available data VBI lines, you can get 150 kbps.

------------------------------

From: king@wildebeest.cig.mot.com (Steven King)
Subject: Re: "Erlang" the Programming Language
Date: 26 May 1994 19:13:52 GMT
Organization: Motorola Cellular Infrastructure Group
Reply-To: king@wildebeest.cig.mot.com


king@wildebeest.cig.mot.com publicly declared:

> Does anyone have any information on a programming language called
> "Erlang"?

Minutes after sending this inquiry I remembered that we have a very
nice technical library just upstairs from me.  In the immortal words
of Homer Simpson, "Doh!"

In any case, our library had the book.  In there I found contact
information for the authors.  One of the authors responded to my query
with a pointer to their ftp site.  Now I have *tons* of information on
the language, as well as a compiler for MS-DOS.  (Would have prefered
a Unix version, but hey ...)  Thanks to everyone else who responded to
me as well!

The email contact is erlang@erix.ericsson.se; the ftp location is
euagate.eua.ericsson.se (directory /pub/eua/erlang).  Here's the short
blurb I pulled from the site.  I'll let interested parties grab the
rest of the docs (mostly PostScript) themselves.

    Erlang - "Concurrent Programming in Erlang", J. Armstrong,          
    M. Williams & R. Virding, P-H 1993.                                 

        Classification:  Concurrent functional programming language
    for large industrial real-time systems. Untyped.  Pattern matching
    syntax.  Recursion equations.  Explicit concurrency, asynchronous
    message passing.  Relatively free from side effects.  Transparent
    cross-platform distribution.  Primitives for detecting run-time
    errors.  Real-time GC.  Modules.  Dynamic code replacement (change
    code in running real-time system, without stopping system).  Foreign
    language interface.

        Availability:  Free version (subject to non-commercial licence)
    with no support.  Commercial versions with support are available
    (Erlang Systems AB).

The language looks very interesting to me.  I'd still like to hear from
people who have direct experience with it.


Steven King <king@cig.mot.com> -- Motorola Cellular Infrastructure Group

------------------------------

End of TELECOM Digest V14 #255
******************************


-------------------------------------------------------------------------------
