Question Mark in Rigol RS 232 Decoder

[eev_carl]

Hi,

I'm running a simple Arduino example program that reads a button press on D0 and Serial.printlns the int value.  It's working perfectly on the Serial Monitor hooked up to the IDE.  0's scroll by until the button is held and then 1's scroll by.

I'm getting a question mark icon on my MSO 1104Z decoder and was wondering what that was.  I verified the same 9600,8N1 settings.

Is this a setting problem on the scope or something I can fix with the circuit.  This is the schematic https://www.arduino.cc/en/Tutorial/DigitalReadSerial .

Thanks,
Carl

[rstofer]

From the User Manual (of the DS1054Z in this case) there are two conditions under which a question mark (or two) will be displayed.  A framing error or check error.

A framing error occurs if the number of stop bits anticipated by the scope is more than the device is sending.
A check error occurs if parity is specified but a) isn't present or b) doesn't match.

I would expand those two bytes and walk through the bits.  Also check the scope settings.  My guess is the scope settings need to be twiddled.

[eev_carl]

I took a look at the bits.  Some of the extra characters are backspace, j, and NAK.  Maybe I'm not using the protocol correctly?  I don't have anything going in to RX (I put it to ground and to high as a test) on the microcontroller.

[rstofer]

I  would change the delay(1) to delay(10) or even more so I could separate the characters strings.  I don't know what could account for the invalid chars you are receiving but I also don't know how the decoder is set up.  Maybe a photo with the decoder settings would help.

I guess it might help to know how you are probing the circuit.  I'm thinking of a loose connection but I can't justify that when the '0' strings display properly.

You can add a digital signal to the mix that goes high just before serial.println() and put this into channel 2.  Then trigger on channel 2.  Expand the horizontal scale until just one transmission displays (3 chars?).  Drop the trigger signal just before the delay() line.

If the error you are getting is a framing error, the scope won't be able to find the stop and start bits and will always receive jabberwocky.  You can see if 2 stop bits will help (leave the scope set for 1 stop bit).

Code: [Select]

mySerial.begin(9600,SERIAL_8N2);


[hexreader]

The Rigol decoder is very simple (dumb) and tries to decode what is on screen.

It might simply be that the on-screen information starts part way through a character, and takes (in this case) two characters to synchronise.

A logic analyser (even a cheap one) is likely to do a far better job of decoding than your Rigol scope will.

The Rigol is good for a few characters with big gaps between messages, but rubbish at decoding long streams of back-to-back characters.

Just my thoughts - feel free to ignore

[eev_carl]

I have a logic analyzer on the MSO 1104Z.  Will it make a difference if I decode from there?  It's 9600 bps so I didn't think I'd hit any kind of boundary.  I can redo the test circuit as well.

[hexreader]

I have a logic analyzer on the MSO 1104Z.  Will it make a difference if I decode from there? 

Not tried logic analyser in a while (because it is a pile of poo), but if my memory serves, decoder is just as dumb with logic analyser as it is with an analogue trace.

Spend $10 on a cheap USB logic analyser

[eev_carl]

I don't understand.  Are you saying that the logic analyzer on my unit is worse than a $10 one?

Is there a technical reason that a logic analyzer that decodes would be better than the scope function?

[hexreader]

In some circumstances (such as the situation discussed in this thread), a cheap LA can be better than your MSO.

Your Rigol is a fantastically good scope for the money, but I find the LA and decoding to be lacking. Not worth the extra cost over a bare DS1054 IMHO.

The difference is in the decoding and storage capability. A USB LA uses all the resources of a PC to do better decoding and storage.

Cheap USB LA has limitations too (perhaps low bandwidth and limits to input voltages), but is dedicated to doing one job well.

All just my opinions of course...  ... but based on experience

[eev_carl]

I tried the LA (D0 versus Ch1) on the Rigol and got the same question mark chars on the screen.

What part of the Rigol is lacking in this decoding?  Is it something in the software? I'm surprised that 9600 bps would be a problem for a 100MHz, 1GSa/s scope.

Do you think these might be extra control chars that are hidden in the Arduino IDE Serial Monitor?

[eev_carl]

Maybe a photo with the decoder settings would help.

These match the 9600,8N1 default in the Arduino Serial.begin(9600) function.

[RoGeorge]

The oscilloscope decodes what it sees on the screen, it has a software decoder.
1. Make sure the screen shows full characters, i.e. does not start in the middle of a character (you can move the trace left-right to achieve that, or try a different sweep speed)
2. You may want to enable the 20MHz bandwidth filter, so you can get rid of those huge spikes.

[rstofer]

Your polarity is set to idle high.  Ordinarily, for TTL RS232 this is correct.  Real RS232 idles low.
Since there is no delay between character strings in your first post, it is pretty difficult to determine that it is idling high.  I probably is but I can't prove it.

It's not likely you can get time between characters but if you change that delay(1) to something much longer, you will see the idle condition between strings.

I'm going to assume the problem is framing.  The DS1054Z, as noted above, decodes the SCREEN, not the data.  So, if the trace doesn't start at an exact idle point, it is almost guaranteed the first char will have a framing error.  You can adjust the trigger position toward the left edge of the screen rather than at the center.  Then, when you stretch the delay, the first thing in the trace is a LONG idle condition.  Then come some chars followed by a long inter-string delay followed by more chars.