Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31617
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: How to snif full-duplex UART protocol between two nodes |
| Date | 2023-02-21 04:11 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <tt28tr$143as$1@dont-email.me> (permalink) |
| References | <tsvh99$mpm3$1@dont-email.me> <87y1ost36d.fsf@nightsong.com> <tt24mf$13hu9$1@dont-email.me> |
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!
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
How to snif full-duplex UART protocol between two nodes pozz <pozzugno@gmail.com> - 2023-02-20 11:16 +0100
Re: How to snif full-duplex UART protocol between two nodes Don Y <blockedofcourse@foo.invalid> - 2023-02-20 04:17 -0700
Re: How to snif full-duplex UART protocol between two nodes Theo <theom+news@chiark.greenend.org.uk> - 2023-02-20 12:23 +0000
Re: How to snif full-duplex UART protocol between two nodes Richard Damon <Richard@Damon-Family.org> - 2023-02-20 07:59 -0500
Re: How to snif full-duplex UART protocol between two nodes Paul Rubin <no.email@nospam.invalid> - 2023-02-20 13:52 -0800
Re: How to snif full-duplex UART protocol between two nodes pozz <pozzugno@gmail.com> - 2023-02-21 10:59 +0100
Re: How to snif full-duplex UART protocol between two nodes Don Y <blockedofcourse@foo.invalid> - 2023-02-21 04:11 -0700
Re: How to snif full-duplex UART protocol between two nodes Theo <theom+news@chiark.greenend.org.uk> - 2023-02-22 11:33 +0000
Re: How to snif full-duplex UART protocol between two nodes Don Y <blockedofcourse@foo.invalid> - 2023-02-22 05:08 -0700
Re: How to snif full-duplex UART protocol between two nodes Rick C <gnuarm.deletethisbit@gmail.com> - 2023-02-21 14:05 -0800
Re: How to snif full-duplex UART protocol between two nodes Paul Rubin <no.email@nospam.invalid> - 2023-02-21 16:55 -0800
Re: How to snif full-duplex UART protocol between two nodes Brian Cockburn <brian.cockburn.1959@gmail.com> - 2023-04-22 07:03 -0700
Re: How to snif full-duplex UART protocol between two nodes Grant Edwards <invalid@invalid.invalid> - 2023-02-20 22:18 +0000
Re: How to snif full-duplex UART protocol between two nodes Clifford Heath <no.spam@please.net> - 2023-02-21 09:58 +1100
Re: How to snif full-duplex UART protocol between two nodes Andrew Smallshaw <andrews@sdf.org> - 2023-02-21 07:05 +0000
Re: How to snif full-duplex UART protocol between two nodes Andrew Smallshaw <andrews@sdf.org> - 2023-02-21 07:07 +0000
csiph-web