AsynMon is a general purpose program to monitor a datacommunications
connection using an asynchronous protocol.
It has special features to view and analyse the dataflow between the
Interface of a digital modelrailroad and a computer with a modelrailroad
control program.
In addition to the input and output dataflow also the status changes of
control signals (such as the CTS signal) are being monitored.
All events are recorded with a high resolution time stamp in a trace file.
This makes AsynMon suitable to check the timing of data characters and
control signals, in particular the working of CTS flow control used by most
digital model railroad control systems.
A facility to perform protocol analysis on the command-level is provided
with a separate utility.
Acknowledgements go to
AsynMon is Freeware for private users. The aim of this gesture is to collect performance data, communications properties and peculiarities of all digital modelrailroad systems. When you use AsynMon for these purposes you are obliged to report the results of your findings by e-mail to the author.
The use of AsynMon for commercial purposes without explicit permission by the author is prohibited.
The minimum hardware requirements for AsynMon are:
AsynMon is a DOS-program. Although it will run also in a DOS-session under OS/2 Warp or Windows, the timing will not be as accurate and there is a higher chance of overruns.
Below an overview of the connection of the monitoring computer with the digital modelrailroad and the controlling computer.
The logical ports 'Port#1' and 'Port#2' can be any physical COM-port (COM1 to COM4). By default AsynMon assigns COM1 to Port#1 and COM2 to Port#2, but these assignements can modified by the user.
A fully wired cable will be required if you want to use AsynMon for multiple purposes, not only for modelrailroads. But before you start to make any cable, read the Wiring considerations.
When a 25-pins Sub-D connector is required on one of these connections, the following 'translate table' may help:
signal 9-pins Sub-D 25-pins Sub-D DCD 1 8 RxD 2 3 TxD 3 2 DTR 4 20 GND 5 7 DSR 6 6 RTS 7 4 CTS 8 5 RI 9 22
For most Digital modelrailroads only 3 signal wires will be 'tapped' (some require only 2, like Selectrix), plus ground.
When the 2-to-1 adapter is used, both the transmit and receive leads are monitored by a single COM-port, a variant of the simple tap-cable is required. See the scheme below for the connections of the involved components.
Note: The connections to RTS and RxD provide the 2-to-1 adapter with the necessary positive and negative power.
In general the quality of the tap-cable for AsynMon will not be of much importance when the total cable length does not exceed 10 meters, including the cable between controlling computer and Interface. With longer cables you may get signal distortion due to crosstalk or external influences, which will become manifest not only in the observations by AsynMon, but which will also have a negative influence on the communication between controlling computer and modelrailroad. If you have to use longer cables, then it is recommended to use 'twisted pair' cabling: every signal wire twisted with a ground wire.
A more important consideration is the choice between a 'universal' or a 'simple' cable. A universal cable might look preferable, but under certain conditions this may cause problems. Asynmon normally monitors all input leads of each COM-port, even the unconnected ones (it doesn't know which is wired and which not). When a wire is connected to one of the monitored leads, but is 'open' on the other end, false signals may be picked up. Transmitted data may cause pulses on the 'open' control signal wires (crosstalk). AsynMon considers these pulses as control signal activity and will report false modem status signal changes. This may not only lead to wrong interpretation of the communications protocol, it may also disturb the proper working of AsynMon itself, due to the extra interrupts.
Is is recommended to 'tap' only the signals which are really used and omit others.
AsynMon is designed to listen to the two-way conversation between 2 parties (point-to-point connection with two datastreams). But of course it can also be used to listen to a single datastream (such as a simplex datastream, a bus or one half of a duplex datastream) and then only one COM-port is required. Examples of these are Märklin/Motorola packet traffic and Lenz X-bus. For example on a system with only a COM1 port, when you want to monitor the Märklin Motorola packetstream, the following commandline would work:
AsynMon $ COM1 nulThis may also be specified the profile.
The DigiTrax MS-100 is not suitable to be tapped, its
characteristics do not match the RS-232 standard completely.
When you connect the tap-cable to the ports of the system running AsynMon
then the signal levels drop below the required values.
This results in data distortion, not only visible by the AsynMon machine,
but also to the machine running the Modelrailroad software!
John Jabour's LocoBuffer can be tapped without these effects.
To simply listen to Loconet activity (not monitoring the
traffic between a controlling computer and the Loconet) with an
MS-100 works fine, like with LocoBuffer.
In this case an ordinary modem-cable (all leads straight over) is
required in stead of a tap-cable.
Note: The MS-100 requires DTR=false and RTS=true, which is
provided for this purpose by AsynMon when Digitrax Loconet protocol is
selected.
Since DTR and RTS of the system running AsynMon are not wired through in the
tap-cables, setting the voltage of DTR and RTS is not of influence on the
datastream being monitored when using AsynMon 'normally' with a tap-cable!
There is no special commandline option or profile parameter for 'listen-only'. Since there is only incoming data, only Port#2 will show activity (Port#1 may be disabled). With the MS-100 the Loconet signal is echoed on the DCD lead. Beware this will be reported as Ring Indicate (RI) activity. Normally you won't need this information, and since it generates several interrupts for each data-byte(!), it may disturb data recording, especially on slower systems. Therefore it is recommended to disable all modem status monitoring for Port#2 by specifying "DTR- RTS- RI-" on the commandline or in the profile file AsynMon.Pro, in which case AsynMon does not enable modem status interrupts of the physical port. Alternately you may not connect (cut) the CD lead of the cable between MS-100 and PC running AsynMon!
AsynMon supports the Lenz X-bus protocol, but it has some special requirements, since:
This requires globally the following:
AsynMon supports Lenz X-bus protocol as follows:
When monitoring the Märklin/Motorola digital datastream on the track, you may want extra precautions to protect your COM-port. Damaging a COM-port can rather easily happen when your PC and Control Unit (Märklin, Uhlenbrock, etc.) use a different earth connection or when you interchange red and brown wire. So it recommended to use an opto-coupler in the cable between the tracks to your PC, for example the following method:
This chapter describes how to use AsynMon effectively.
Create a separate directory for AsynMon and unZIP the file ASYMONxy.ZIP archive in this directory. Check the packinglist to see if you have received what you may expect.
Although AsynMon is strictly a DOS program it may run with some restrictions in a DOS session under OS/2 or W95/98. In these cases the timing information will not be accurate, and it requires at least double the system performance compared to pure DOS.
When you want to run AsynMon in a DOS session under OS/2 the required DOS session properties are:
Using AsynMon to monitor high volume traffic ('direct drive', X-bus protocol, etc) in a DOS session of OS/2 or W95/98 will require a pretty fast computer (Pentium).
The commandline syntax is:
AsynMon Protocol [Speed] [Port#1] [Port#2] [{MSR-signal[+|-]}] [@Filespec]
In which:
Note: When no logfile is specified "AsynMon.Trc" will contain the log. When the file already exists the last characters will be modified into 1 -> 99 until a 'free' name will be found. Ultimately the logfile ending with 99 will be overwritten. When a logfile is specified on the commandline it will always be overwritten if it exists (you are supposed to know what you are doing!). After termination the actually used name will be reported.
When a profile file is present,
protocol, speed, MSR signal monitoring and logical port assignments are
taken from the profile, overriding the program defaults.
Parameters specified on the commandline will override those of the
profile and the defaults.
If you need a non-default speed, specify speed after protocol,
because a protocol specification resets the default speed.
The table below shows the protocols AsynMon recognises and has special
support for.
This includes at least the speed and character format, but in some cases
this may also include features for the online display of data.
The support of AsynMon is not limited to the protocols in the table.
When no line matches with the required COM-port parameters for your purpose,
you can still use AsynMon, as follows:
| Protocol letter |
Protocol description | Default speed |
Line control |
|---|---|---|---|
| Modelrailroad systems | |||
| B | DigiTrax LocoNet with John Jabour's LocoBuffer | 57600 | N,8,1 |
| D | DigiTrax LocoNet with DigiTrax MS-100 | 16457 | N,8,1 |
| E | EDiTS | 4800 | N,8,2 |
| I | Märklin Digital 6023 (TRAIN-ING Set) | 19200 | N,8,2 |
| L | Lenz Digital Plus (LI-100) | 9600 | N,8,1 |
| M | Märklin Digital and many other systems
(default if no protocol specified) |
2400 | N,8,2 |
| T | Trix Selectrix | 9600 | N,8,2 |
| U | Uhlenbrock Intellibox | 19200 | N,8,2 |
| X | Lenz X-bus (note 5). | 57600 | S,8,1 |
| $ | Special for the Märklin/Motorola packet stream on the rail
(note 1 and note 2). |
38400 | N,6,1 |
| Generic (note 3) | |||
| 1 | Generic 1200 bps | 1200 | N,8,1 |
| 2 | Generic 2400 bps | 2400 | N,8,1 |
| 3 | Generic 4800 bps | 4800 | N,8,1 |
| 4 | Generic 9600 bps | 9600 | N,8,1 |
| 5 | Generic 19200 bps | 19200 | N,8,1 |
| 6 | Generic 28800 bps | 28800 | N,8,1 |
| 7 | Generic 38400 bps | 38400 | N,8,1 |
| 8 | Generic 57600 bps | 57600 | N,8,1 |
| 9 | Generic 115200 bps | 115200 | N,8,1 |
| | Explicit "no protocol" selection (note 4). | (asis) | (asis) |
Other settings may be added on request!
After AsynMon has been started the protocol may be changed, see Protocol Selection.
In most situations only the name of the port needs to be specified, in which case the specification is limited to COM1 to COM4. Asynmon obtains the address of each COM-port from BIOS information and will use IRQ4 for COM1 and COM3, and IRQ3 for COM2 and COM4.
When a non-standard COM-port is used an extended specification should be used:
(Port,HexAddr,IRQ)This should be specified as a single string including the brackets and commas, and no embedded spaces.
Example: (COM4,FFE8,11) indicates that COM4 on address FFE8h
uses IRQ 11.
Note: Asynmon doesn't check if these specifications correspond to
the actually installed hardware, it just tries and may succeed or fail.
All commandline parameters (except log file) are stored in a profile file at termination, and restored when started a next time before interpreting the commandline. The profile is an ASCII file "AsynMon.Pro" in the current working directory. There is no initial profile file delivered with AsynMon, the default is Marklin Interface protocol ('M'), monitor all signals and use COM1 and COM2.
| parameter | description |
|---|---|
| Protocol-id | Single letter or digit: protocol identifier |
| MSR signals |
Up to 6 abbreviations of the control signals: DTR, DSR, RTS, CTS, DCD and RI. The presence of one or more of the mentioned abbreviations (optionally followed by a '+' character) is the indication for AsynMon to monitor the corresponding signals. A trailing '-' character means that monitoring of that signal should be disabled. |
| Ports | COM-ports to be used for Asynmon, specified as COM1, COM2, etc. The specification-sequence determines the function of the port. AsynMon interprets the data and control signals on the first logical port, Port#1, as transmitted data and control signals CTS, DSR and DCD. The data and control signals of the second logical port, Port#2, are interpreted as received data and control signals DTR, RTS and RI. |
| Speed | Interface speed when different than the default speed for the selected protocol. When a speed is specified, it is used for both ports. |
Below a screen shot of a testrun with a 2-to-1 adapter and an Uhlenbrock Intellibox using P50X binary protocol (P50Xb) as impression of what you may expect to see with AsynMon.
The top-line shows the actual port settings and the recording time.
On the bottom line you'll see which control signals are involved: the
actually monitored signals are displayed bright, others dimmed.
Also the actual protocol letter and name are shown.
The captured data is displayed in hexadecimal format on pairs of lines.
The upper line of a pair displays the data of Port#1 (transmitted data) in
normal video, the lower line the data of Port#2 (received data) in reverse
video.
For some digital model railroad protocols the first byte of a frame or
command is highlighted.
Two other types of events will be displayed inline with the data:
All recorded events can be analysed later 'offline' in detail.
For performance reasons AsynMon writes directly to screen memory, and therefore wil operate only in 80x25 mode. ANSI.SYS should not be active (changed since version 2.3).
The partial screen capture below is similar, but in this case an Intellibox is controlled from a program using P50X ASCII (P50Xa) protocol. It shows a bad and a good behaviour of a computer(application) with respect to CTS output flow control.
The Intellibox uses CTS output flow control to stop transmission of data by the computer when its receive buffer becomes full, generally after it has received 4 or 5 bytes. After CTS is turned off the PC should stop transmitting data (one byte may follow).
On the first pair of lines you can see that a long command was sent to the Intellibox:
F20, 1, 1, 1, 1, 1, 1, 1, 1
You'll see that the computer continues sending data even during periods that the the Intellibox keeps CTS down. Obviously the sending computer(program) does not handle CTS output flow control correctly.
On the second pair of lines the IB is reset after the application has changed it flow parameters, followed on the third line by some empty commands (only for alignment!). On the end of the third line-pair, continued on the fourth a new long command was sent to the Intellibox:
F20, 0, 0, 0, 0, 0, 0, 0, 0
Now the computer(application) behaves correctly: as soon as CTS is dropped by the Intellibox, no more data is sent, and after CTS has become high again, the transmission is resumed.
At startup AsynMon initialises the port(s) to the settings corresponding
to the selected protocol
(see Table with built-in Protocol selections).
During monitoring the protocol may be changed by hitting the key
corresponding to the desired protocol identifier.
At that moment the settings of both ports will be changed and the
screen re-initialised.
This activity may cause temporary errors being reported in the log due
to current line activity, even when the protocol is not changed.
Unsupported keys are simply ignored.
Note: When an explicit speed was specified on the commandline
this setting will not be changed, regardless protocol selection.
For most protocols AsynMon will show the data traffic realtime on the
screen.
This is not very useful with protocols with a very high traffic volume, like
Märklin Packet protocol, and may have a severe negative influence on
the performance, possibly resulting in lost events
(see also Performance Considerations).
For these protocols realtime data display is suppressed by default.
Hitting the space bar will switch online data display between 'on'
and 'off' (toggle switch).
Recording of traffic in the trace file is independent of the realtime
display.
By default AsynMon monitors and records not only data, but also changes
in 'modem' status and control signals (DTR, CTS, etc).
With commandline parameters or in the profile this can be selective.
Of non-monitored signals the changes are ignored and not recorded
(since AsynMon version 2.3).
Monitoring can also temporary be suppressed with the '!'-key
(exclamation mark) for both ports and for all signals simultaneously.
In this situation MSR interrupts are disabled, with the effect that control
signal activity is not passed to AsynMon, which may improve AsynMon
functioning on slower systems with a high traffic volume or a high rate
of modem status changes.
Consequently also the log will not contain any control signal
activity!
Pressing the '!'-key again re-estabishles the monitoring of the previous
set of control signals.
The bottom line of the screen shows always the actual monitoring selection,
with different colors for 'actively monitored', 'temporarilly not
monitored' and 'permanently not monitored'.
The '!'-key has no effect when during startup of AsynMon monitoring of
all modem status signals has been disabled.
When a 2-to-1 adapter is used, DCD and DSR monitoring will remain
enabled, because these are used by AsynMon internally.
AsynMon is terminated by hitting the 'Esc'-key.
The COM-ports are quiesced, the logs closed, the profile written, the screen
cleared (except for the top-line) and a termination message is displayed.
During monitoring Ctrl-Break and Ctrl-C are intercepted and ignored to
prevent erroneous termination and not quiescing the COM-ports properly.
AsynMon may terminate prematurely due to errors.
An error message appears, indicating the reason of the problem.
After termination AsynMon displays some statistical information in the
form of interrupt counts.
These statistics are mainly meant to check if an excessive number of
interrupts have occurred, which may adversely influence the proper working
of AsynMon.
For example, when there are many MSR-interrupts, other events like incoming
data (even on the other port) might have been missed.
This check is particularly important when you have suppressed
monitoring of one MSR signal of a port but not the others, since the
formatting utility will not show suppressed interrupts.
Without being aware of missed events you might be misleaded by the results.
See also Suppressing Control Signal Monitoring,
Profile for how to suppress control signal monitoring
and Appendix A for information which signal is
monitored by which Port#.
Although AsynMon is optimized for performance to be able to monitor and
record high volume datastreams, there is always a limit!
AsynMon uses hardware interrupts to timestamp events (every incoming byte,
every modem signal change and every transmission error), it may have to
handle thousands of interrupts per second.
Obviously the higher the traffic volume and the more signal changes the
faster the system has to be.
When the system is not fast enough interrupts may be missed.
In most cases this will remain unnoticed, but it will definitely make
proper data analysis impossible.
Sometimes it will lead to system hang-ups or spontaneous system resets.
Two relevant question are:
In case of system hang-up or system-reset then it is simple, otherwise you have to watch for signals that indicate possible performance problems.
When you observe one or more of these signals you may consider the following
The logfile created by AsynMon is in a binary encoded compact format for optimal performance. The formatting utility AsynFmt is provided for detailed analysis of the recorded traffic.
Remember that the name of the logfile may be changed by AsynMon with start-up when a logfile already exists! At termination of AsynMon the name of the actual logfile is reported.
The log or trace file can be formatted with the utility AsynFmt. AsynFmt requires the name of the binary encoded logfile of AsynMon, and optionally some other parameters. The commandline syntax is:
AsynFmt [LogFile] [FormatFile] [FrameTraceFile] [FormatFlag] [#[TimeCorrection]]
In which:
| Flag | Description |
|---|---|
| * | Force display of polling activity of Lenz X-bus protocol,
which is suppressed by default.
This is only possible when DCD monitoring has not been suppressed with AsynMon. |
The internal format of the log records is not documented here yet, maybe later. Since the format of the recorded data may change between versions, AsynFmt accepts only traces of the corresponding version of AsynMon.
The listing below shows the start of a monitoring session of a Märklin modelrailroad.
AsynMon version 2.3c - by Rob Hamerling
Log file 'AsynMon.Trc', recording started on 2001/12/20 at 11:49:07
---------------------------------------------------------------------------
time | Port#1 xmt | Port#2 rcv | Status event details
(secs) | status data | status data |
| |xx c asc| |xx c asc|
------------+--------+--+-+---+--------+--+-+---+--------------------------
0.0000 | MSR 10 | | | | [init] DCD 0 DSR 0 CTS 1
0.0000 | | | MSR 00 | | [init] DTR 0 RTS 0 RI 0
8.3889 | | | MSR 33 | | DTR 1 RTS 1
8.6740 | MSR 01 | | | | CTS 0
8.6778 | |60 ` 96| | |
8.9248 | MSR 11 | | | | CTS 1
8.9551 | MSR 01 | | | | CTS 0
8.9590 | |C0 . 192| | |
8.9593 | MSR 11 | | | | CTS 1
8.9865 | MSR 01 | | | | CTS 0
8.9902 | |81 . 129| | |
9.0033 | | | |F0 . 240|
9.0083 | | | |00 . 0|
9.0083 | MSR 11 | | | | CTS 1
9.0177 | MSR 01 | | | | CTS 0
9.0215 | |00 . 0| | |
9.0218 | MSR 11 | | | | CTS 1
9.0223 | MSR 01 | | | | CTS 0
9.0261 | |0A . 10| | |
9.0663 | MSR 11 | | | | CTS 1
Every line in the formatted log is the representation of an event (interrupt on any of the COM-ports). This can either be a data byte being sent or received, a change of one or more control signals or the detection of an error situation. After a state change a control signal is displayed as '1' when the signal is currently 'true', or as '0' when 'false'.
Looking at this sample output of AsynFmt you can see the following sequence of events:
You'll notice that the Märklin Interface drops CTS immediately at
the start of reception of every byte
(see Hints and Tips for more details).
The summary report is not shown here, but straight forward:
it contains the count of log records in and out.
When possible to determine it shows also some performance information.
For example with a Märklin Interface it shows runtime and the
totals of the time of CTS=true and CTS=false,
giving an impression of how busy the Interface was.
Note: 'runtime' is defined as the time between the first time CTS became
false and the last time it became true.
For generic protocols this data is not presented.
For some situations AsynFmt provides extra help with the analysis of the recorded data:
When looking at the output of AsynFmt you may sometimes be puzzled by what you see. If you are not so familiar with the internals of a COM-port, you might draw wrong conclusions. Here are some Internals to prevent misinterpretation:
For some protocols AsynFmt creates an output file in DigiAPI-trace format in addition to the character / modem-signal level output. This file can be formatted with the DigiTrc utility.
Data characters are assembled into frames (commands or replies) for the following protocols:
The frame-level output file is in binary format and can be formatted with DigiTrc1, provided with this AsynMon package. There are some dependencies that have influence on success:
A possible procedure for this multi-stage analysis may look like:
AsynMon U
The first parameter determines P50/P50X(a/b).
An optional second parameter should be the speed which the
application will use (AsynMon defaults to 19200 for 'U').
AsynFmt AsynMon.Trc AsynMon.Fmt AsynFrm.Trc
It will pickup AsynMon.Trc as input file.
Produce a char-level report in the file AsynMon.Fmt.
Build a frame level binary trace file in AsynFrm.Trc.
DigiTrc1 AsynFrm.Trc AsynFrm.Fmt.
This will pickup AsynFrm.Trc as input file.
Produce a frame level report in AsynFrm.Fmt.
Specification of '#' in steps 2 and 3 on the commandline of AsynFmt and DigiTrc1 will give you the time in the format 'hh:mm:ss.ttt'.
Technical background information about COM-ports.
The meaning of the bits of MSR (Modem Status Register) and LSR (Line Status Register) as used by AsynMon are explained here briefly. For a more general reference you'll have to see the technical information of the family of UARTs commonly used in PCs (8250, 16450, 16550, etc) and/or datacommunications manuals.
AsynMon monitors both on Port#1 and Port#2 a part of the control signals.
The Modem Status Register contains information about the behaviour of the control signals. A change in any of 4 control signals results in an Interrupt on the COM-port, which is registered by AsynMon and the contents of the MSR is stored in a log record. The least significant 4 bits indicate which signal-change caused the interrupt, and the most significant 4 bits give the current status of all 4 control signals.
AsynMon monitors on each port at most 3 control signals, depending on the wiring of the tap-cable. The universal tap-cable has 3 signals wired to Port#1, and the other 3 to Port#2.
The bits of the MSR are assigned as follows (bits counted from right to left):
| RS232 | AsynMon Port#1 | AsynMon Port#2 | ||
|---|---|---|---|---|
| bit | abbrev | description | use | use |
| 7 | DCD | Data Carrier Detect | Data Carrier Detect Note 1 | Ring Indicate |
| 6 | RI | Ring Indicate | (not used) | (not used) |
| 5 | DSR | Data Set Ready | Data Set Ready Note 2 | Data Terminal Ready |
| 4 | CTS | Clear to Send | Clear to Send | Request to Send |
| 3 | deltaDCD | change of Data Carrier Detect | DCD status change | RI status change |
| 2 | trailRI | Trailing Edge Ring Indicate | (not applicable) | (not applicable) |
| 1 | deltaDSR | DSR status change | DSR status change | DTR status change |
| 0 | deltaCTS | change of Clear To Send | CTS status change | RTS status change |
Notes:
The Line Status Register contains information about the status of the
transmission process.
Its use by AsynMon is limited, because AsynMon is just listening to a
communication of others (eavesdropping).
One exception is the occurrence of a 'break' signal.
A break signal is used by some hardware to reset both partners of a
(probably failing) communication to a predetermined state.
The correct functioning of AsynMon is dependent on the setting of its
port parameters!
If errors occur you'll definitely see it in the data being displayed.
Via LSR-events it will also report problems of its own functioning, which
will be logged for later analysis.
| bit | AsynMon Port#1 and Port#2 |
|---|---|
| 7 | (not used) |
| 6 | (not used) |
| 5 | (not used) |
| 4 | Break
(may also be caused by incorrect speed) |
| 3 | Framing Error
(incorrect character format or speed) |
| 2 | Parity Error
(maybe incorrect parity setting) |
| 1 | Overrun Error
(AsynMon system too slow!) |
| 0 | Data in buffer
(not explicitly used) |
Instructions on how to connect the LZ100 to the COM-port of a PC to monitor X-bus traffic.
Work carefully, the exercise may damage your LZ100 and your computer if you make the wrong connections: shortcuts or wrong voltage levels! Make or break connections only with all devices powered off!!
A separate COM-port card is recommended for at least 2 reasons:
The 1.8432 MHz crystal on the COM-port has to be replaced with a
2.0000 MHz crystal.
When a port uses a crystal with a different frequency the new crystal should
have a proportional frequency (20000/18432).
For example a crystal of 22.118 MHz should be replaced by one of
24.000 MHz.
Desolder the old crystal, solder a suitable socket and insert the new
crystal in this socket.
Clean the pins of the old crystal for later replacement (in the socket).
The Lenz LZ100 works internally with TTL level power (5V). The cable will be a direct connection between the TTL-level of the LZ100, and the TTL level on the COM-port (not to the RS232 connector). A 3-wire cable is used to make the following connections:
This text has been checked carefully, and verified by knowledgable
people, but may still contain errors!
The author can not be hold responsible for any
damage to modelrailroad or computer equipment.
"By hook or by crook" it is possible to use AsynMon with a single COM-port and still be able to watch and record both transmit and receive datastreams. To make this work:
With a '2-to-1' adapter the transmit and receive datastreams are combined
to a single datastream and fed to the COM-port RxD input data lead.
The direction of the corresponding data is signaled on the DCD lead of the
COM-port of the AsynMon computer.
When DCD is true, the captured data is of the transmit datastream, when DCD
is false, the captured data is of the receive datastream.
The 2-to-1 adapter contains also a circuit to check if the datastream is
really half duplex.
Although the detection is not full proof, in most cases it will signal
(on DSR) simultaneous transmit and receive activity.
This 'collision detection' is not reported by AsynMon on the screen, but
only shown in the output of AsynFmt.
The scheme of the adapter is:
The leftmost pair of NOR gates is switched as set-reset flipflop.
Without data traffic both TxD and RxD are negative.
A positive pulse - typically a startbit - on TxD or RxD turns over the
flipflop to the active side.
This flipflop has 2 functions:
(1) to derive a signal to indicate which datastream is active, and
(2) to control a filter to pass only the active datastream.
The filter is formed by a second pair of NOR gates.
It selects either the TxD or RxD datastream to be passed.
A final NOR-gate restores the original polarity of the data signal.
The flipflop turns over with any data activity on the 'other' side.
When the traffic is not strictly half duplex, this could be in the middle of
a character!
When this happens you may (or may not!) observe distorted characters,
framing errors and parity errors.
The remaining three NOR-gates form a collision detection circuit.
When both TxD and RxD are positive (meaning simultaneous data transport)
this condition is passed to DSR.
This collision warning can occur several times per transmitted character.
But it is not full-proof, some collisions may not be detected at all.
The adapter needs a dual voltage power supply of at least +4.5V and -4.5V. Since a only few milliAmperes are required the power can easily be delivered by the COM-port of the computer running AsynMon, see the schematics below.
As you can see RTS provides the positive power voltage, and TxD provides the negative power voltage.
Below a layout of a sample experimental strip-board ('VERO-board') of approximately 6 by 3.5 cm. It includes power supply for the adapter, provided by the COM-port of the computer running AsynMon.
The component side of the sample adapter then looks like:
Since both the transmit and receive leads are monitored by a single COM-port, a variant of the simple tap-cable is required. The cable between the 2-to-1 adapter and the computer with AsynMon should be sufficiently wired. A regular modem-cable will do.
The photograph below gives an impression for a possible housing. This the authors prototype, the components are slightly differently positioned than on the final design.
To indicate to AsynMon that a single COM-port with 2-to-1 adapter is used the same COM-port must be specified for both logical ports, either on the commandline or in the profile file. This is the signal for AsynMon to:
The display of data and events by AsynMon will be as if two physical COM-ports were being used.
Overview of history of AsynMon and AsynFmt.