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).
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?
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?
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?
Is there something already available that I can use?
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.
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?
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?
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?
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.
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.
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?
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.
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:No. That won't work as the two transmitters could be trying to drive the
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? >>
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.
https://www.lammertbies.nl/comm/cable/rs-232-spy-monitor#full
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 307 |
Nodes: | 16 (2 / 14) |
Uptime: | 126:46:39 |
Calls: | 6,854 |
Files: | 12,360 |
Messages: | 5,417,484 |