km@emory.uucp (Ken Mandelberg) (01/22/88)
Several companies seem to make "lanalyzers" which are just PCs with a
LAN interface, and clever monitoring software.
In the serial RS232 world, I have seen a number of special purpose data
analyzers, which seem quite expensive. Although I suppose they do other
things, a big piece of their functions is just accurately logging the
traffic in both directions, and triggering on certain sequences. It
seems to me that a PC with two serial interfaces could do much the same
thing, and that the software is not especially tricky.
Has anyone seen a product of this sort?
--
Ken Mandelberg | {decvax,sun!sunatl,gatech}!emory!km UUCP
Emory University | km@emory BITNET
Dept of Math and CS | km@emory.ARPA ARPA,CSNET
Atlanta, GA 30322 | Phone: (404) 727-7963gary@percival.UUCP (Gary Wells) (01/26/88)
In article 2600 of misc.wanted Ken Mandelberg asks: >In the serial RS232 world, I have seen a number of special purpose data >analyzers, which seem quite expensive. Although I suppose they do other >things, a big piece of their functions is just accurately logging the >traffic in both directions, and triggering on certain sequences. It >seems to me that a PC with two serial interfaces could do much the same >thing, and that the software is not especially tricky. >Has anyone seen a product of this sort? You don't even need 2 ports, just one. Most EIA (RS-232) drivers will handle a "bridged" connection, that is, will source multiple recievers. Just build yourself a Y cable, and run your PC communications program in capture mode. If possible, have it display, not act upon, control sequences. If you wanted to get fancy, you could build a little repeater, using line driver chips (4888, 4889). Various companies make these (both repeaters and Y's) under various names (like password grabber, Y, slave terminal driver, etc). I find this method more reliable ( not to mention cheaper) than the Spectron 601 Line Analsyer we have at work. What you don't get this way, is the abiltiy to trigger events from selected character sequences in the monitored stream, or the ability to translate one set of control codes into another. Most data analysers do these things, and more. On the other hand, I've never needed that ability. -- -------------------------------------------------------------------------------- Still working on _natural_ intelligence. gary@percival
jgy@hropus.UUCP (John Young) (01/27/88)
A company called "Frederick Engineering, INC." have a product called FELINE which probably does what you want. It consists of a card, extern i/o interface (looks like a large breakout box) and a floppy disk with there DOS software. We use it on IBM PC's and AT&T PC-630*'s. It will handle various sync and async protocols. It will save long running traces to disk for later analysis, enable you to search for specific things, decode X.25 packet info, time stamp, transmit so you can do primative emulation, etc........ Frederick Engineering 54 Cessna Court, Gaithersburg, Maryland 20879 301-926-6772
dale@lamont.Columbia.edu (dale chayes) (01/28/88)
In article <1063@percival.UUCP>, gary@percival.UUCP (Gary Wells) writes: in reply to: > In article 2600 of misc.wanted Ken Mandelberg asks: > > >In the serial RS232 world, .... special purpose data aalyzers, > don't .. need 2 ports.. Most EIA (RS-232) drivers .. handle > a "bridged" connection, Be careful. Adding extra load (another reciever) to a line that is marginal, may make it worse. There is nothing like finding out (much later) that your "test" equipment has been running you in circles. Gary's note suggests that "if you want to get fancy" you could build a buffer. If you are not really sure, you should do it for safety. An added attraction of a buffer is that you can add some protection from your computer inadvertantly sending data. Another thing to consider when you are probing around in unknown wiring, is the impact of connecting your pc's serial port directly to nasty things like power lines. A well designed buffer will help protect you from that also. I thought hard about doing using a "pc" as a serial data analyzer when we got our first compaq portable here, but concluded that it was too big and heavy to be a convienient piece of test eqt (we have been using a Tek serial data analyzer since then.) HOWEVER, my new Toshiba-1200 is about 1/2 the size, and far more powerful, which makes me rethink the problem. For that matter, any of the new portables would do very nicely. -- Dale Chayes Lamont-Doherty Geological Observatory of Columbia University usmail: Route 9W, Palisades, N.Y. 10964 voice: (914) 359-2900 extension 434 fax: (914) 359-6817 usnet: ...philabs!lamont!dale
michael@orcisi.UUCP (Michael Herman) (01/28/88)
> In article 2600 of misc.wanted Ken Mandelberg asks: > > >In the serial RS232 world, I have seen a number of special purpose data > >analyzers, which seem quite expensive. Although I suppose they do other > >things, a big piece of their functions is just accurately logging the > >traffic in both directions, and triggering on certain sequences. It > >seems to me that a PC with two serial interfaces could do much the same > >thing, and that the software is not especially tricky. > > >Has anyone seen a product of this sort? > > You don't even need 2 ports, just one. Most EIA (RS-232) drivers will handle > a "bridged" connection, that is, will source multiple recievers. Just build > yourself a Y cable, and run your PC communications program in capture mode. > If possible, have it display, not act upon, control sequences. I guess this could be done with a regular ASCII terminal as well?
rhes@igloo.UUCP (Richard H. E. Smith II) (01/29/88)
>In an article in misc.wanted Ken Mandelberg asks: > >>In the serial RS232 world, I have seen a number of special purpose data >>analyzers, which seem quite expensive. Although I suppose they do other >>things, a big piece of their functions is just accurately logging the >>traffic in both directions, and triggering on certain sequences. It >>seems to me that a PC with two serial interfaces could do much the same >>thing, and that the software is not especially tricky. > >>Has anyone seen a product of this sort? We (wearing my work hat at Sun Electric) have just received on trial a LM1 Protocol Analyzer made by Progressive Computing Inc. This is a board for IBMoid PCs, plus software. I believe it sells for about $1600. At first glance, it looks very good. Quick summary of claimed features: Menu driven protocol analyser Data display & capture (to memory and/or disk) Autoconfiguration DDCMP decodes BERT/BLERT Time-of-day stamping Interactive BASIC simulation Software breakout box Built-in ASYNC terminal emulation Capture at up to 72KBaud to buffer, or to disk at 9.6Kbaud DCE & DTE emulation dual protocol monitoring (different protocol on transmit & receive) SDLC/HDLC real time frame decode Optional ISDN, SNA, X.25 level 3 decode modules available DOS commands with monitor running in background One year warranty Free loaner One year s/w updates included I've been reading the manual, and am about to attempt to extensively test this unit by programming it using the customized BASIC (special emulation verbs added to a grungy interpretive BASIC) to emulate a BISYNC credit card network that our cash registers talk to... if it can simulate this network, it is outperforming $5000+ datascopes, which cannot pick fields out of records to create response records. At first attempt, the package performs "datascope" monitoring functions well, and sufficiently intuitively that a highly trained software engineer who is familiar with various different datascopes could operate it without reading the documentation. Your mileage may vary. The "autoconfigure" function could identify some easy ASYNC and BISYNC lines correctly, which is better than some older ARC 'scopes we now have usually do. I will be searching for hard tests, and will attempt to report more. I have nothing to do with Progressive Computing, Inc., which claims to be located at 28 Greenwood Court, Glen Ellyn, IL 60137. --------- In article <1063@percival.UUCP> gary@percival.UUCP (Gary Wells) writes: >You don't even need 2 ports, just one. Most EIA (RS-232) drivers will handle >a "bridged" connection, that is, will source multiple recievers. Just build >yourself a Y cable, and run your PC communications program in capture mode. >If possible, have it display, not act upon, control sequences. Sure, but if you do this, you will short the Tx & Rx leads unless you build a powered or mechanism... only a couple of gates, but not just a piece of cable. Even if you make the OR, you will still have trouble if the line you're trying to analyze is full duplex, and both sides send a character at the same time. Also, your PC's serial port is ASYNC only. I noticed that the PCI device described above uses the obvious hardware, namely Zilog SCC with appropriate gating. The SCC is a dual serial port device which is quite flexible.... ---------- Dick Smith ...ihnp4!ddsw1!igloo!rhes
brian@ncrcan.Toronto.NCR.COM (Brian Onn) (01/29/88)
In article <1063@percival.UUCP> gary@percival.UUCP (Gary Wells) writes: > >In article 2600 of misc.wanted Ken Mandelberg asks: > >>In the serial RS232 world, I have seen a number of special purpose data >>analyzers, which seem quite expensive. Although I suppose they do other >>things, a big piece of their functions is just accurately logging the >>traffic in both directions, and triggering on certain sequences. It >>seems to me that a PC with two serial interfaces could do much the same >>thing, and that the software is not especially tricky. > >>Has anyone seen a product of this sort? > >You don't even need 2 ports, just one. Most EIA (RS-232) drivers will handle >a "bridged" connection, that is, will source multiple recievers. Just build >yourself a Y cable, and run your PC communications program in capture mode. >If possible, have it display, not act upon, control sequences. But would you not miss some data?? I mean, to acurately monitor data and hardware lines from both the DTE and DCE under test, your PC would need a passive port, made up of only *line receivers*. Every PC I have worked with has had both line drivers and line receivers on it's serial port. Bridging two drivers is sure to affect the real data. I have seen some PC serial ports which are switch selectable to be configured as either a DTE or DCE. Perhaps if the hardware has enough receivers, then it could be set up so that it has some lines set up as DCE and others set up as DTE, to provide a receiver only interface. Of course, some special software would be required. So what is the net's concensus on the above?? Are most serial ports configurable as mentioned? If they are, then a software only solution is feasible. Brian.
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (02/02/88)
FYI
The current issue of Dr. Dobbs Journal contains a project (software
mainly) for turning an IBM PC (or clone -- anything that can run
Turbo Pascal) into an RS-232 analyzer. I haven't read the article
very closely, but as I recall most of it was simply something to
show the data going across the wire. But there was different
ways to trigger different events and so forth.
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- It takes more than a good memory to have good memories.gary@percival.UUCP (Gary Wells) (02/06/88)
There has been a LOT of technical discussion along the lines of "but what about" various aspects of bridging a second terminal or pc off of the RS232 line to use as a data analyzer. I know it sounds wierd, guys, but it also works. If you have feed back problems, open the Transmit data lead, making the 3rd unit recieve only. It's quick, it's dirty, it's CHEAP! -- -------------------------------------------------------------------------------- Still working on _natural_ intelligence. gary@percival
foster@seismo.CSS.GOV (Glen Foster) (02/08/88)
The Feb. 1988 issue (#136) of Dr. Dobb's Journal has an article on the PC as an RS-232 analyzer. It includes source (Turbo Pascal) and a schematic for a "tap" into the circuit. It appears to be fairly easily extensible if it doesn't address one's particular analysis requirements. I apologize if this has already appeared. Glen Foster