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!
How to snif full-duplex UART protocol between two nodes
Started by ●February 20, 2023
Reply by ●February 21, 20232023-02-21
Reply by ●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 ●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 ●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 ●February 22, 20232023-02-22
On 2/22/2023 4:33 AM, Theo wrote:> 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 ●April 22, 20232023-04-22
On Wednesday, February 22, 2023 at 11:55:31 AM UTC+11, Paul Rubin wrote:> https://www.lammertbies.nl/comm/cable/rs-232-spy-monitor#fullThat's exactly what is required.
