> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 2/21/2023 2:59 AM, pozz wrote:
>>> Il 20/02/2023 22:52, Paul Rubin ha scritto:
>>>> pozz <pozzugno@gmail.com> writes:
>>>>> Is there something already available that I can use?
>>>>
>>>> There is a traditional hack where you make or buy a Y cable that lets
>>>> you tap the serial i/o and listen to both directions from a PC. Then
>>>> just log the data going in and out. When I did it I used a simple
>>>> Python script and it was able to keep up with the device we were dealing
>>>> with (might have been 1200 bps, I don't remember). It's possible
>>>> something like that already exists for Wireshark.
>>>
>>> Do you mean "joining electrically" (AND for UART TTL levels) the two signals
>>> and connect the result to the RX signal of a single serial port on the PC?
>>
>> No. That won't work as the two transmitters could be trying to drive the
>> line (that they think only *they* own!) to different potentials.
>
> I think it could work with a 'diode-OR' (or open-collector) kind of a
> arrangement: either end can pull the line to the active state, but otherwise
> the line will fall back to the inactive state. The diodes prevent the line
> being driven to opposite potentials.
The problem is that you can't guarantee that the link will be run
half-duplex.
> It would only really work protocol-wise if you could be sure both sides
> weren't talking at the same time. That might work if there was a
> command/response protocol where you could be sure everything was
> half-duplex. And you also wouldn't be able to tell which end a byte came
> from, unless there was internal structure in the messages (like ASCII
> commands with carriage returns on the end).
.. assuming the reply doesn't get started *while* the "redundant fluff"
at the end of the command is still on the wire (e.g., if the only commands
are A, B, C -- each terminated by a CRLF -- then an implementation might
decide to act once it has received the A, B *or* C... without bothering
to wait for the CRLF.
The problem with all (?) EIA232 comms is that there really is no
(universally) defined protocol -- even the format of the characters
can be made to vary in real time!
[E.g., I've used BREAK and LONG_BREAK as out-of-band controls to
let me *hardware* reset the device at the other end of the line
(watch for the line to stay in a spacing condition for >> one
character time and yank on the RESET- signal when that happens).
If you want to store-and-forward that, will you reproduce the
exact same spacing condition?]
> But could work as a kind of poor-man's sniffer if you had no better option.
The implementation issue I see the OP facing will be getting two
"predictable" serial ports on the same *PC* host (or, whatever other
device he uses to host the logging software).
I have a bit of code that I use to piece together RPC "calls" with
their corresponding "returns" on an ethernet link. It's easy to
get confused thinking that THIS reply was for THAT request -- when,
in fact, it was for the one before (or after).
Given the amount of buffering in 16450-ish UARTs -- and likely more
in USB dongles (when you consider the USB stack as part of the
issue), can you ever be sure to get data from one port in any given
timing relationship to the data from another? Esp when the stack is
likely a black box to you?
At least with old (e.g., 6402) UARTs, the buffering was limited to
exactly what *you* did in software; you only had to worry about the
character potentially on the wire and the one queued up behind it
(or ahead of it, depending on your perspective).
Buffering is a PITA to work around. Hence the appeal of hardware
solutions; "I saw this before I saw that".
Reply by Theo●February 22, 20232023-02-22
Don Y <blockedofcourse@foo.invalid> wrote:
> On 2/21/2023 2:59 AM, pozz wrote:
> > Il 20/02/2023 22:52, Paul Rubin ha scritto:
> >> pozz <pozzugno@gmail.com> writes:
> >>> Is there something already available that I can use?
> >>
> >> There is a traditional hack where you make or buy a Y cable that lets
> >> you tap the serial i/o and listen to both directions from a PC. Then
> >> just log the data going in and out. When I did it I used a simple
> >> Python script and it was able to keep up with the device we were dealing
> >> with (might have been 1200 bps, I don't remember). It's possible
> >> something like that already exists for Wireshark.
> >
> > Do you mean "joining electrically" (AND for UART TTL levels) the two signals
> > and connect the result to the RX signal of a single serial port on the PC?
>
> No. That won't work as the two transmitters could be trying to drive the
> line (that they think only *they* own!) to different potentials.
I think it could work with a 'diode-OR' (or open-collector) kind of a
arrangement: either end can pull the line to the active state, but otherwise
the line will fall back to the inactive state. The diodes prevent the line
being driven to opposite potentials.
It would only really work protocol-wise if you could be sure both sides
weren't talking at the same time. That might work if there was a
command/response protocol where you could be sure everything was
half-duplex. And you also wouldn't be able to tell which end a byte came
from, unless there was internal structure in the messages (like ASCII
commands with carriage returns on the end).
But could work as a kind of poor-man's sniffer if you had no better option.
Theo
Reply by Paul Rubin●February 21, 20232023-02-21
Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Since this involves two devices communicating and two serial ports,
> one to monitor the data in each direction, wouldn't this be an X
> cable? Or am I missing something?
I guess you could call it an X cable. This has a diagram that looks
about right:
https://www.lammertbies.nl/comm/cable/rs-232-spy-monitor#full
I've never made one of these myself. I used one that a co-worker made,
and wrote the code to log the data. I said 1200 bps earlier, but I
think it was actually 9600 bps. The connected devices were a POS
terminal and a receipt printer.
Reply by Rick C●February 21, 20232023-02-21
On Monday, February 20, 2023 at 4:52:47 PM UTC-5, Paul Rubin wrote:
> pozz <pozz...@gmail.com> writes:
> > Is there something already available that I can use?
> There is a traditional hack where you make or buy a Y cable that lets
> you tap the serial i/o and listen to both directions from a PC. Then
> just log the data going in and out. When I did it I used a simple
> Python script and it was able to keep up with the device we were dealing
> with (might have been 1200 bps, I don't remember). It's possible
> something like that already exists for Wireshark.
Since this involves two devices communicating and two serial ports, one to monitor the data in each direction, wouldn't this be an X cable? Or am I missing something?
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
Reply by Don Y●February 21, 20232023-02-21
On 2/21/2023 2:59 AM, pozz wrote:
> Il 20/02/2023 22:52, Paul Rubin ha scritto:
>> pozz <pozzugno@gmail.com> writes:
>>> Is there something already available that I can use?
>>
>> There is a traditional hack where you make or buy a Y cable that lets
>> you tap the serial i/o and listen to both directions from a PC. Then
>> just log the data going in and out. When I did it I used a simple
>> Python script and it was able to keep up with the device we were dealing
>> with (might have been 1200 bps, I don't remember). It's possible
>> something like that already exists for Wireshark.
>
> Do you mean "joining electrically" (AND for UART TTL levels) the two signals
> and connect the result to the RX signal of a single serial port on the PC?
No. That won't work as the two transmitters could be trying to drive the
line (that they think only *they* own!) to different potentials.
Instead, you end up with 4 connectors -- the original two connecting your
"two communicating devices". Plus, two more that each have a single
connection to the RxD inputs of two serial ports on your PC (i.e., the
TxD connections from those two PC ports go nowhere).
This is a kludge as you have two receivers on each signal -- the receivers
on each of your two devices PLUS the receivers on the two PC ports.
And, you've got an extra ground involved -- the PC (but that won't typically
cause problems except in some special cases).
Alternatively, you can route the data *through* the PC; device A talks to
PC's port 1. PC echoes the stream to device B (keeping a log of the
content). At the same time, device B talks to PC's port 2 and the PC
similarly echoes the stream to device A (logging it).
The risk, here, is that the PC can introduce a delay in the transmission
between A and B. Likely this is not important in the example you cited.
And, if the PC can't keep up (because other things are happening in the
PC, at the time), then you risk losing characters.
Finally, this approach can be harder to implement completely if the
comms take advantage of other signalling means (like BREAKs). The
PC would have to recognize these in the data stream and reproduce them
in the same manner and in the same relationship to the surrounding
character transmissions.
> It couldn't work in my case, because the protocol could be full-duplex, so both
> nodes could transmit at the same time. The AND result would be corrupted.
Start simple. Monitor *one* device's output. See if it presents the
information of interest to you in a form that you can easily recognize
(or *extract* if you have to handle a control and data channel
sharing the same stream).
Then, the other to determine that it contains what you want/expect.
Finally, use a pair of PC ports wired to the two different transmitters
and collect both streams simultaneously.
Note that if you don't have genuine serial ports (e.g., USB), there may be
some delays in the delivery of the observed data to the PC (e.g., buffering
in the device as well as in the stack in the PC). This could introduce
jitter in the timestamps. Just something to watch for. It *won't* alter
the order in which data from each transmitter arrives at the PC but
could affect the skew between the two devices... if large enough,
you may see replies to commands (in your log) before you see the commands!
Reply by pozz●February 21, 20232023-02-21
Il 20/02/2023 22:52, Paul Rubin ha scritto:
> pozz <pozzugno@gmail.com> writes:
>> Is there something already available that I can use?
>
> There is a traditional hack where you make or buy a Y cable that lets
> you tap the serial i/o and listen to both directions from a PC. Then
> just log the data going in and out. When I did it I used a simple
> Python script and it was able to keep up with the device we were dealing
> with (might have been 1200 bps, I don't remember). It's possible
> something like that already exists for Wireshark.
Do you mean "joining electrically" (AND for UART TTL levels) the two
signals and connect the result to the RX signal of a single serial port
on the PC?
It couldn't work in my case, because the protocol could be full-duplex,
so both nodes could transmit at the same time. The AND result would be
corrupted.
Reply by Andrew Smallshaw●February 21, 20232023-02-21
On 2023-02-20, pozz <pozzugno@gmail.com> wrote:
> Many times I need to snif and log on a file the activity between two
> nodes that talk over a full-duplex UART (separate TX and RX lines).
>
> Is there something already available that I can use?
Try searching for "RS232 analyser", "RS232 datascope" and similar.
A quick look found a number of possible candidates. I won't make
any recommendation myself as last time I needed something like this
I went back to an old DOS tool.
--
Andrew Smallshaw
andrews@sdf.org
Reply by Andrew Smallshaw●February 21, 20232023-02-21
On 2023-02-20, pozz <pozzugno@gmail.com> wrote:
> Many times I need to snif and log on a file the activity between two
> nodes that talk over a full-duplex UART (separate TX and RX lines).
>
> Is there something already available that I can use?
Try searching for "RS232 analyser", "RS232 datascope" and similar.
A quick look found a number of possible candidates. I won't make
any recommendation myself as last time I needed something like this
I went back to an old DOS tool.
--
Andrew Smallshaw
andrews@sdf.org
Reply by Clifford Heath●February 20, 20232023-02-20
On 20/02/23 21:16, pozz wrote:
> Many times I need to snif and log on a file the activity between two
> nodes that talk over a full-duplex UART (separate TX and RX lines).
>
> Just an example, consider a host MCU that talks with a modem through AT
> commands. It's a half-duplex protocol because the MCU sends the AT
> command and the modem replies. However the modem is able to send URC
> messages that can be emitted at any time.
>
> I think the better approach is to use two different UART/USB converters,
> one for each signal (of course, both signals goes to the RX inputs of
> the converters).
>
> What about the sofware on the PC? It should open two serial ports and
> monitors both of them, joining together the messages on a single file. A
> great feature would be to have a timestamp for each message, where a
> message is "\r\n" delimited.
>
> Is there something already available that I can use?
You could fairly easily modify my "connect.c" to do this, works in Linux
or OS/X. It does two-way communication between a serial port and the
terminal console you run it from, similar to `cu`, minicom` and similar
programs - but this is very simple, you don't have to navigate a wealth
of features to make changes.
Change it to configure two serial ports and copy data between them,
logging data to a file in the same way the Unix program `script` does.
Then plug in two USB/RS232 dongles and connect your two devices.
<https://www.dropbox.com/s/q0tqsszqx0q5hf4/connect.c>
Clifford Heath.