Trying to acquire Arduino UART with oscilloscope

[TillmanZ]

Hi there!

I am trying to acquire and then eventually decode the serial communication between an Arduino and a GSM board.
The Arduino is running a bare bone sketch relaying all serial communication from the h/w serial ports (pins 0,1) to a soft-serial (pins 2,3).
The communication actually works fine.
But having a Rigol DSO with RS232 decoding capability I figured I want to put that to use.
Seems like I am doing something wrong though because instead of expected square waves of the highs and lows of the UART I see two things:
1) some low voltage 32MHz noise
2) every time I send some data on the serial connection I do see spikes of voltage followed by something which seems to look like bouncing

Using "AUTO" the scope tries to home in on the 32MHz "signal" but also when I try to trigger the spikes manually I miserably fail.
I have tried the RS232 trigger mode with appropriate serial settings to no joy.

Any ideas what I am doing wrong?
...and I hope I have not missed any crucial info...

Best,

Tillman 

[nsxrr]

Hi,

Do you know how to use an oscilloscope ?

If not, this is a god starting point
 

What you need maybe inside Ch3 "Tutorial: How to use an Oscilloscope #3 - How to capture a signal event / glitch / "

cause it use a Rigol basic oscilloscope.

Best Rgds,
nrxrr

[suicidaleggroll]

You need to set your scope to trigger on a falling edge with the trigger threshold set to somewhere around half of Vcc and your time scale set somewhere appropriate for your baud rate and message length.  Then set it up for a single event trigger and send your serial data.

[TillmanZ]

The falling edge was a great hint!
When set to 500mV and 200us with a falling edge trigger set to 210mV I can successfully trigger the communication in single shot mode.

So how would I take this a step further? I did try to use the RS232 trigger mode in auto and single shot but to no joy.
I watched the Rigol YouTube video on RS232 but for some reason (most likely because I am doing something wrong ) the Rigol doesn't catch my RS232 data.

Thanks for your help guys!

Best,

Tillman

[SL4P]

is your scope probe connected to the serial port ground?
Otherwise the high-Impedance probe is floating, and the signal pins will act as an antenna to all sorts of things... including the CPU clock...

[retrolefty]

The falling edge was a great hint!
When set to 500mV and 200us with a falling edge trigger set to 210mV I can successfully trigger the communication in single shot mode.

So how would I take this a step further? I did try to use the RS232 trigger mode in auto and single shot but to no joy.
I watched the Rigol YouTube video on RS232 but for some reason (most likely because I am doing something wrong ) the Rigol doesn't catch my RS232 data.

Thanks for your help guys!

Best,

Tillman

 Not an owner but perhaps your Rigol RS232 function is expecting bipolar voltages for triggering and not usable with an Arduino's "TTL serial" voltages?

[suicidaleggroll]

The falling edge was a great hint!
When set to 500mV and 200us with a falling edge trigger set to 210mV I can successfully trigger the communication in single shot mode.

So how would I take this a step further? I did try to use the RS232 trigger mode in auto and single shot but to no joy.
I watched the Rigol YouTube video on RS232 but for some reason (most likely because I am doing something wrong ) the Rigol doesn't catch my RS232 data.

Thanks for your help guys!

Best,

Tillman

RS232 != UART

The basic comm protocol is the same, but the voltage levels are completely different.

[nsxrr]

Sounds like you already got the 232 data show on the oscilloscope screen.   
What else you want to do?
I do not own a Rigol scope, for the RS232 trigger function really make sense, you may need to setup what "pattern/code" you want to trigger (my guess).

[TillmanZ]

RS232 != UART

The basic comm protocol is the same, but the voltage levels are completely different.

  - so here I was wondering why the scope didn't like to trigger on my data even though it was expecting a proper +12/-12 RS232 signal.

How would I need to go about triggering the TTL UART communication (and not just fire on a single character as I am doing right now)?
And would it be possible to use the RS232 decode option as the TTL UART should be encoded in a similar way albeit the different voltage levels.

Best,

Tillman

[suicidaleggroll]

I'm afraid I don't know the answer to that.  Every time I need to decode UART I just use a logic analyzer on it.  I don't know if the RS232 decoder in your scope is capable of decoding UART - even though it's the same protocol it may be hard-coded to look for +/- voltages.  Maybe if you use a voltage divider to split Vcc and use that as the scope ground it might be happy?  It won't hit the minimum +/- 3V RS232 spec, but it might be enough for the scope.

[128er]

Don't know the Rigol scopes. At my Agilent DSO-X 2000 scope I can individual set the threshold levels for the RS232/UART decode function. Maybe there is a menu somewhere to adjust the threshold levels?

Which scope do you have?

[hamster_nz]

What do you think of this suggestion.... If you don't suspect you waveforms are wrong, then the scope is the wrong tool, and even a good logic analyzer isn't want you need.

Get a USB->TTL RS232 adapter (here's one for < $7 - http://imall.iteadstudio.com/im120525005.html) , and just connect the ground and the RX line (or whichever one is actually the input - GRRR) to the line you want to monitor and leave the TX unconnected. Then you can watch one side of the conversation in a suitable terminal, in real time, in ASCII, without any faffing around.

If you get two adapters, you can watch both sides in different windows.

[dadler]

I've been able to decode UART/TTL voltages using the RS232 decoder on the Rigol scope. Source was a bus pirate in UART mode and various bauds 9600-115200.

Keep in mind it only decodes what is on the screen, and watch your time base/sample rate so that the data you are looking for is on the screen. You may find segmented memory useful here.

Also there is a voltage threshold set menu item under the RS232 decoder that you may need to muck with. This will be greyed out if "auto thresholds" is enabled.

[SL4P]

Can we please drag this thread into using the correct terminology!
e.g. "the RS232/UART decode function"

A UART is a hardware device to serialize data. RS232 is a signal level specification.  etc.
Neither has anything to do with encoding or decoding!

Most likely, you are trying to decode ASCII text/8-bit data that is embedded in a serial stream at XXX bps with N start, and N stop bits... with or without parity attached.

Ok, rant mode <off>
My point is that - no one will learn anything if we promote use of the nearest word that sounds techie enough - if it's not the right term!

[hamster_nz]

Can we please drag this thread into using the correct terminology!
e.g. "the RS232/UART decode function"

A UART is a hardware device to serialize data. RS232 is a signal level specification.  etc.
Neither has anything to do with encoding or decoding!

Most likely, you are trying to decode ASCII text/8-bit data that is embedded in a serial stream at XXX bps with N start, and N stop bits... with or without parity attached.

Ok, rant mode <off>
My point is that - no one will learn anything if we promote use of the nearest word that sounds techie enough - if it's not the right term!

I hear you, but....

I think most people look on RS232 as two parts - the protocol that isn't defined by the RS232 standards (e.g baud, start bits, stop bits, parity, etc) and then the physical layer (that is in the actual standard), but the protocol used has and become a de-facto standard - if you say 9600-8N1 I know what you mean, including bit ordering, idle levels, start and stop bit values.

So even if I refer to the fictional part of the standard and say "the RS232 protocol using [3.3V/5.0V] TTL logic levels" anybody who can give me a reasonable answer knows exactly what I. However "can my Rigol decode a TTL serial stream" can mean just about anything that talks over one wire - I2C, SPI, USB, RS232, Manchester encoded, 8b/10b, SAS, SATA, LSB first, MSB first, idle high, idle low, sync, async...

So I think it is perfectly valid to ask "can the Rigol RS232 protocol decode function work when using 3.3V TTL logic levels?" - I don't think that it is sloppy at all.

[SL4P]

...So I think it is perfectly valid to ask "can the Rigol RS232 protocol decode function work when using 3.3V TTL logic levels?" - I don't think that it is sloppy at all.

I agree mostly with what you've said - except that you added a lot of context...
e.g. What happens if you're trying to 'decode' an RS485 pair?  Where do you hang the scope shield.
it has nothing to do with serial or decoding...

We should not abandon standard terminology for convenience - look at the mess apple and Microsoft have created by redefining terminology and expectations...
 --- luckily processing power has allowed them to abstract and bury the many false assumptions under a skin of respectability!
Just sayin'

[SL4P]

Here is an example (Rigol DS-1052)
Ignore the cursors (my bad!), specific voltages and timing periods.
Trigger is set for one-off on falling edge (approx middle of the excursion range)

As you can see - this is serial data - not RS-232 or specifically ASCII text - It is simply a serial stream - which we can start analysing once it is captured.

You can see the voltage swing is only 1.4V - so it doesn't conform to any specific interface standard - but is in fact 8-bit serial binary data.

Sorry - my scope doesn't have an ASCII text / binary decode function - but you can do it by hand if you're hungry enough!
BTW - this is on the output side of an IR photo transistor - just happens to be a serial comms link.

[dadler]

The "A" of UART is very relevant here, beyond just "serial".

[SL4P]

The "A" of UART is very relevant here, beyond just "serial".

'
OK - just testing... what does it stand for, and how does it impact the conversation?

[hamster_nz]

The "A" of UART is very relevant here, beyond just "serial".

'
OK - just testing... what does it stand for, and how does it impact the conversation?

I'll let you know when I have something to say

[dadler]

The "A" of UART is very relevant here, beyond just "serial".

'
OK - just testing... what does it stand for, and how does it impact the conversation?

Serial can imply synchronous communication, such as SPI. You referred to serial in your comment and sort of glossed over the requisite agreed timing/implicit clock for asynchronous UART.


But I'll admit I was being pedantic - since you were hung up on terminology. Back to the original talking point, I think that many people use the terms RS232 and UART semi-interchangeably and this does not really lead to issues. Most recent RS232 transceivers operate fine at TTL voltages (although older and industrial equipment may be huge exceptions).

[hamster_nz]

One thing that nag me with async serial (e.g. async 9600-8N1 since I can't say RS232 and be correct ) is does async really mean completely async?

e.g. after a 10-bit frame (start bit, 8 bits data, stop bit), can the pause be a completely random period of time, or should it be an integer number of bit-times.

For RX, I've always coded assuming that the frame is 10 bit times from the falling edge of the start bit, and I sample at 0.5x, 1.5x, 2.5x... ...8.5x and 9.5x of the bit-time from the falling edge, but I know a lot of UART implementations oversample based on the bit-time and then check neighbouring bits match.

For the TX side I usually keep the signals idle for an integer multiple of the bit time, just to be safe, maybe throwing away up to a full bit time for every frame that isn't back-to-backed with the previous frame.

But I won't lie awake at night worrying about it...

[SL4P]

One thing that nag me with async serial (e.g. async 9600-8N1 since I can't say RS232 and be correct ) is does async really mean completely async?

e.g. after a 10-bit frame (start bit, 8 bits data, stop bit), can the pause be a completely random period of time, or should it be an integer number of bit-times.

A really good question... one that is rarely addressed in tutorials.
The inter-character delay (and inter-line delay) are strictly speaking, functions of how efficient the receiver is at unloading the character from the receiver's input shift-register.

Most hardware UARTs provide at least one word of buffering - so the Rx queue can begin shifting another character while the processor is popping the previous 'completed' character out of the FIFO.  Software UARTs (bit-bashing) may not be so accommodating - and incur additional CPU cycles.

With the performance of modern chips, it is reasonable to expect the CPU can be ready to pop a new completed character out of the receiver within one word time (n x bit periods), unless the serial data rate is particularly fast. (e.g. 1 bit @ 115200 bps = 8uS)

In theory, only one idle bit duration is needed between the end of the STOP bit and the beginning of the next START bit.  To get the best out of a serial handler - interrupt driven operation with simple FIFO/circular-buffers are the fastest way to handle longer serial data blocks reliably.
Interrupts (and ideally FMA) lets you move the received data from the UART buffer into RAM as needed - in the minimum time - freeing up the CPU to do other time sensitive stuff.

Using delay(), wait() or other blocking code is unhelpful when handling any asynchronous events - as the recovery period between edges is determined by the delay - not the data stream.

If the receiving program is unable to ingest the most recent character before the next one is 'ready' - then you'll see buffer over-run flagged by the UART module.
(I the bit timing is too far off spec between the TX and RX UARTs (or the bit-bashing code stretches some bits irregularly) - you'll get a framing error.)