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 -- Motorola Cellular Infrastructure Group ------------------------------ End of TELECOM Digest V14 #255 ****************************** -------------------------------------------------------------------------------