RS232 decoding vs UART decoding - Rigol ds1054z seems confused (or maybe I am)

[mbratch]

I'm using the Rigol DS1054Z to decode UART output form an ESP32 mcu.

What I'm finding is that the Rigol appears to have the decoding inverted and changing polarity causes it to get confused.

The UART output of the ESP32 is a 3.3v level output and so in stead state it is "high" (3.3v) and a "1" is 0 volts and a "0" is 3.3 volts. All sounds pretty normal so far.

When I attempt to decode using the Rigol RS232 decoder, if I set the polarity match this it decodes beautifully but the hex values are inverted. So I have to manually invert all the hex values it shows me by hand (or at least in my head as I'm reading them). I tried fooling it and selecting the opposite polarity, but then it was confused and gave question marks and completely incorrect values for the decode. I suppose it was confused about start/stop bits (?).

I haven't seen any other comments on this issue, so I assume I must be doing something wrong. Does anyone have a suggestion?

[langwadt]

The UART output of the ESP32 is a 3.3v level output and so in stead state it is "high" (3.3v) and a "1" is 0 volts and a "0" is 3.3 volts. All sounds pretty normal so far.

that's not pretty normal, a normal uart idles high and 1 is high and 0 is low

[mbratch]

The UART output of the ESP32 is a 3.3v level output and so in stead state it is "high" (3.3v) and a "1" is 0 volts and a "0" is 3.3 volts. All sounds pretty normal so far.

that's not pretty normal, a normal uart idles high and 1 is high and 0 is low

Ah ok... I was having trouble finding that information. That was my misunderstanding. Thanks!

So it appears that the UART driver in the ESP32 library inverts the bits, which I'll need to dig into.

[langwadt]

So it appears that the UART driver in the ESP32 library inverts the bits, which I'll need to dig into.

that would be very odd

[2N3055]

Inverting hex values could be about MSB/LSB (Bit order) setting.

[ebastler]

Levels can be confusing... "Proper" RS-232 has -12V as the logical high level, +12V as logical low. The "TTL serial" or "CMOS serial" ports common today use 0V for logical low, 3.3V or 5V for logical high.

So voltage levels actually are inverted between those two implementations. But a UART should always idle at its logic high level.

I am not 100% sure what the Rigol decoder assumes, but I seem to recall that is uses "proper" RS-232 conventions by default?

[Electro Fan]

Inverting hex values could be about MSB/LSB (Bit order) setting.

+1
try the opposite of what you have set for MSB/LSB (bit order) and see what happens

[pdenisowski]

Ah ok... I was having trouble finding that information. That was my misunderstanding. Thanks!

I made a (6 minute) video on UART basics that might be helpful - discusses idle high as well as some of the other topics mentioned here.

[pdenisowski]

I am not 100% sure what the Rigol decoder assumes, but I seem to recall that is uses "proper" RS-232 conventions by default?

Don't have the Rigol, but on most scopes the UART parameters should be configurable (screenshot from a different video)

[ebastler]

Don't have the Rigol, but on most scopes the UART parameters should be configurable (screenshot from a different video)

I no longer have my DS1054Z, but yes, the parameters are certainly configurable. That's why I mentioned being unsure about the default setting.

Nice and clear settings dialog in your screenshot.   Although "Idle state: high" still invites potential confusion -- does it mean logical high level, or physical high voltage? Probably the latter, in which case "Idle voltage: high" might be clearer?

[Njk]

Certain AWGs can generate such a waveform. No need to keep in mind every boring detail when the manual provides a good reference. That's why an instrument with poor manual is annoying to operate, similar to that with a broken knob or mangled connector

[TomKatt]

When I hear "hex values are inverted", I interpret that as Endianness - NOT inverted bits.  Bit inversion is not the same as high byte / low byte.  If you "flip" the hex values around, that infers those hex values are correct (so the bits are correct) but sent in a different order.  I'm not familiar with the DS1054Z to know if it has a setting to swap the decode results.

[pdenisowski]

Certain AWGs can generate such a waveform.

For most of my presentations, I usually simply use a Raspberry Pi or Arduino to generate test signals.  This also allows you to code in "fun" messages

[ebastler]

Certain AWGs can generate such a waveform. No need to keep in mind every boring detail when the manual provides a good reference. That's why an instrument with poor manual is annoying to operate, similar to that with a broken knob or mangled connector

All very true, but of limited relevance here, since we are talking about decoding rather than generating RS-232 signals?

Also, I note that the generator for which you attached the user manual apparently does not really support either of the critical parameters we were discussing here: Signal polarity and order of bits. One can invert the whole output signal, I assume, but then has to fudge the transmitted bit pattern by manually inverting the entered value. And likewise, one has to improvise an inverted bit order by fudging with the data byte once more -- especially annoying when it can be entered as a decimal value only.

So, while I applaud the manual for documenting these restrictuions clearly, I am not convinced by the generator itself. 

[langwadt]

it would be very odd for uart to not use the standard bit order or either invert all or none of the bits

[Njk]

All very true, but of limited relevance here, since we are talking about decoding rather than generating RS-232 signals?

In my view, the topic was started because the OP is not sure about the general formatting conventions. It does not make sense to discuss a complex or tricky cases when the basics are not clear. Meanwhile, in every more-less usable manual, we expect to see not only the numbers and how-tos, but also a brief introduction to the subject. That was the reason for the page attachment.

[Hexley]

Since the topic of how to generate serial test signals has come up, I'll point to this thread https://www.eevblog.com/forum/testgear/serial-data-generator-tool-for-siglent-sdg1000x2000x6000x-awgs/ that describes how to use a Siglent AWG to generate the waveforms.

There is a python script that takes an input text file and generates serial data output. The signal polarity can be chosen as logic level or RS-232, and the usual serial parameters are available (baud, parity, etc.).

Should be possible to modify the script to drive a different brand of AWG without too much trouble.

Here is a shot of the AWG in action: