Decoding RS232/RS485 on a cheap scope

[macstr1k3r]

Hello everyone,

Today's question is: Is there a way to decode serial(RS232/RS485) data using a cheap oscilloscope(ds1052e) or some other "cheap tool" that I could presumably get my hands on. I know the picKit2 can do this(I can get one of those) but what I'm more interested is rather the timing between the packets rather than the data itself.

The problem I'm faced with is I'm having some problems with my PC-PLC communication and I suspect there is a problem with the timings or something like that(the time between switching the pc from TX to RX mode)

PS I'm the software guy so please be gentle on me.

[dfmischler]

How about something like this (but working) HP 4952A protocol analyzer?  I had no trouble finding a fully working HP 4952A on ebay for less than $50 plus shipping.  The 4951C is similar, the 4951B uses a tape cartridge for storage rather than a 3.5" diskette, but I'm not sure those models do timing analysis like the 4952A.  Google for specs to make sure it will be useful to you.  The important items are the unit itself, the pod (such as 18180A for RS-232 and RS-449, other pods for other stuff), and the cable that connects the pod to the unit.  The power cord is IEC standard, typical serial cables (you could buy or make one with two males and a female if needed), etc.  Of course, it's not as useful as an oscilloscope for electronics but it is pretty good for looking at RS-232 (and similar) communications.

[mikeselectricstuff]

There are some RS232 monitor utiilities for the PC, but for good timing they need to run on a real COM port, not a USB one.
I'm sure some of the cheap PC logic analysers will do serial decode.

[daqq]

For a cheap logic analyzer that could do the kind of thing you want, you might wanna look at:

http://www.saleae.com/

It's not a scope, more of a logic analyzer. There are more like it out there.

[Electro Fan]

Do you need both RS232 and RS485?
Do you need to only see the timing relationships, or do you need to see specific voltage levels?

[Harvs]

Hello everyone,

Today's question is: Is there a way to decode serial(RS232/RS485) data using a cheap oscilloscope(ds1052e)

Assuming you've got access to a DS1000, have a look at this piece of software I wrote:
https://www.eevblog.com/forum/testgear/ds1000e-async-serial-decoder/

It was only ever a development build, and generally no one was interested so I never took it any further.  However, it still might help with your problem in a cheap way.

[alm]

Note that few logic analyzers will interface with RS-232 or RS-485 voltage levels (most logic analyzers have single-ended inputs, for starters), although you may be able to probe on the logic-level side of the transceiver. The cheapest solution would probably to take the data from the DS1052E (assuming you already have one), threshold it and import it in some freely available LA software with support for these protocols. This would likely involve at least some programming for the thresholding and format conversion. Harvs's tool sounds like something similar.

[slateraptor]

For a cheap logic analyzer that could do the kind of thing you want, you might wanna look at:

http://www.saleae.com/

It's not a scope, more of a logic analyzer. There are more like it out there.

Saleae Logic is unilateral 5V tolerant, not bilateral. Would need to sandwich a receiver and probe its output. The receiver will introduce propogation delays during level shifting, but if you're interested in relative timing between packets, then it shouldn't matter.

Hello everyone,

Today's question is: Is there a way to decode serial(RS232/RS485) data using a cheap oscilloscope(ds1052e) or some other "cheap tool" that I could presumably get my hands on. I know the picKit2 can do this(I can get one of those) but what I'm more interested is rather the timing between the packets rather than the data itself.

The problem I'm faced with is I'm having some problems with my PC-PLC communication and I suspect there is a problem with the timings or something like that(the time between switching the pc from TX to RX mode)

PS I'm the software guy so please be gentle on me.

From the bold highlight, I presume you're wanting to snoop 2-wire RS-485 with a 2-channel DSO; RS-232 is full duplex.

1) data+ = chA
2) data- = chB
3) use DSO math function to perform chA - chB; alternatively, chA + (invert chB)
4) adjust your time window accordingly and single-shot
5) manual analysis
6) repeat 4 and 5 as necessary

caveat 1) Your protocol is asynchronous, making manual decode difficult, but "what I'm more interested is rather the timing between the packets rather than the data itself"...
caveat 2) ...which begs the question: assuming you have a valid packet pair captured from a full half duplex bus and without serial decode, how will you interpret which is command and which is response?

[macstr1k3r]

caveat 2) ...which begs the question: assuming you have a valid packet pair captured from a full half duplex bus and without serial decode, how will you interpret which is command and which is response?

The system is designed such that at any give time, either the PC is sending a command(8 bytes long) or the controller is responding with a 8 byte long data packet. Wheather this 8 byte sequence is a req or response can be determined by looking at the second byte.

Anyway I'll give sniffing the RS485 traffic manually a shot.

[slateraptor]

caveat 2) ...which begs the question: assuming you have a valid packet pair captured from a full half duplex bus and without serial decode, how will you interpret which is command and which is response?

The system is designed such that at any give time, either the PC is sending a command(8 bytes long) or the controller is responding with a 8 byte long data packet. Wheather this 8 byte sequence is a req or response can be determined by looking at the second byte.

Anyway I'll give sniffing the RS485 traffic manually a shot.

Just in case the direction I was coming from wasn't clear, see attached image. Consider two single-shot scenarios, the first in which command happens to be first then response; for the second, response first then command. Without serial decode and knowing a priori that 1) the protocol is asynchronous, i.e. no explicit clock as reference, and 2) command/response are the same length, the task of manual decode becomes exacerbated.

Furthermore, suppose response == command...can your testbed ensure this won't occur? Can your testbed ensure that a capture of 2 sequential data packets is not host timing out and merely transmitting twice?

Some food for thought.

[ttp]

The system is designed such that at any give time, either the PC is sending a command(8 bytes long) or the controller is responding with a 8 byte long data packet. Wheather this 8 byte sequence is a req or response can be determined by looking at the second byte.

If your PC software is using serial port then google free serial port monitor - you fire it first then your software that uses the serial port and you can see all communication going through the port, tells you what goes out and what comes in.

If the PC software doesn't use serial port but the comms are over RS485 bus I'd just connect my RS485-RS232 converter and monitor that, you'll see all the traffic regardless of direction but if you know the protocol it is easy to work out messages and replies, eg. Modbus.

I've sniffed a lot of serial comms and rarely I had to monitor raw voltage on the wire, it's easier, faster and cheaper to try sniffing at higher level. BTW, there is also serial port logger, it will log all traffic to a file, for weeks if you need it.

[VladimirM]

You can use Docklight for this. You can log the data in both ways. It will be marked in different colors to clearly see what data is being sent to which side. They actually use 2 COM ports to forward data from one to another and vice versa, but this gives their program ability to monitor both ways communication without interfering. Something similar like wireshark does it for TCP. But here it is done for RS232 communication.

So no additional expensive hardware, you just use 2 com ports and there it is
https://docklight.de/

[Vtile]

PicoScope USB scopes do have UART decode feature, I'm not entirely sure of RS-485 since I can't recall the specifications of it, RS232 works well. It all is done PicoScope6 PC-program naturally.. Also comes with PicoRecorder software which is handy for datalogging.
https://www.picotech.com/support/topic22841.html

Of course this.


They have also open C++ libraries for the scopes IIRC..

While not the cheapest ones (120€ it seems for 2000 series), they are somewhat more trustworthy than generic noname china export soap box usb dongles. I would not take one as only scope for electronics, but it is handy for time to time scope need and doesn't take much room. There is their own limitations so homework is needs to be done.