In my experience with RS-232, on the wire, a logical low is usually represented as high voltage and logical high as low voltage.
In the screendump below, you can see almost 3 cycles where I captured 0x55, 0x00, 0xFF (being repeated) at 8N1.
So, without further ado I hooked up a PC with up my favorite HyperTerminal ASCII file consisting of all upper case Us so that I could observe some 1s and 0s. (Thanks again to ALM for turning me on to the extra nice square wave pattern generated with the capital Us.)
Bummer, I can sort of explain the 21, but I am having a hard time with the 121. This stuff can make your head hurt.
Start with something simplistic, like a 0x01 value. That way, the Start and End bits will be more visible, the character frame will be obvious, and you will immediately see that: a) the bit polarity of RS232 data is inverted, and b) the bits are sent out in LSB order. I.e., it's "upside down, and ass-backwards".
My HyperTermnal program specifies 8 data bits, 1 stop, no parity, and there is no mention of a start bit. (Earlier in my career I saw examples of 7 or 8 data bits sandwiched between a start bit and a stop bit, plus a parity bit, so I get that it is possible.) In my current setup it isn't clear there is a start bit.
Nonetheless, are you pretty sure I have a start bit in front of each byte?
Frankly, the only thing that I have really focused hard on is finding any combination of the variables that I have to work with that gets the waveform to synchronize with the 1s and 0s - which I have accomplished and which only seems to work with one combination of settings. (I'm pretty/very sure that I have 8 data bits, 1 stop bit and no parity. So mostly what is left is polarity and MSB/LSB settings.
...to be square we've heard from users here who bailed out on Rigol scopes because they found errors in the decoder.
So I think you can assume that while there is a good chance I haven't got all the setting right, there is also a chance (until you get your hands on a 1000Z) that there might be something in need of a firmware adjustment.
...but again, look at the last image and you will see that the image shows what strikingly looks like a high degree of symmetry and alignment between the binary code and the waveform. Obviously the viewing is limited by what practically fits on the screen, but the last image has what looks like 3 full bytes.
I'll see if I can get some other characters going - or feel free to post a specific repeating string you like and I'll give it a try.
Thx again for the help.
I need to get my head around this:
"E.g., while TX and Rx are inverted, the Control lines (RTS, CTS, DTR, DSR, etc.) are not. Once you get on the other side of the line-driver, your levels aren't shifted any more, and the bit polarities aren't inverted. They're still LSB though"
Are you saying that some of the 1s and 0s in my image might be RTS, CTS, DSR, etc.? If so, where would they be relative to the data bits and their corresponding waveforms? Is it possible that the decoder ignores the Control Lines and/or drops those bits on the floor? (Or perhaps since what I have caught on the scope is just a text file full of mostly Us rather than an actual one-way or two-way transmission between computers there were no Control Line bits at all?)
I need to get my head around this:
"E.g., while TX and Rx are inverted, the Control lines (RTS, CTS, DTR, DSR, etc.) are not. Once you get on the other side of the line-driver, your levels aren't shifted any more, and the bit polarities aren't inverted. They're still LSB though"
Are you saying that some of the 1s and 0s in my image might be RTS, CTS, DSR, etc.? If so, where would they be relative to the data bits and their corresponding waveforms? Is it possible that the decoder ignores the Control Lines and/or drops those bits on the floor? (Or perhaps since what I have caught on the scope is just a text file full of mostly Us rather than an actual one-way or two-way transmission between computers there were no Control Line bits at all?)
No, no. Those are separate Control lines. I tried to distinguish them from the Rx and Tx signal lines, but apparently I just confused things further. Sorry about that.
[But being able to see those signals (on Channel 3 or 4 of your shiny new scope) can be really handy when tracking down communications handshaking issues, e.g. I.e., a 2-channel scope can't see more than Rx and Tx. Or one direction, plus one control line. A PITA to fudge around.]
Record, yes. Playback, sure. Analyze, not available on the 1000Z, AFAICT. (Assuming the documentation is correct. An owner can confirm or refute that.) This may be the biggest downside to this unit, since the ability to scan and set markers in a large capture, based on a set of conditions, is a powerful capability on the DS2000 series. Navigate... just simple step fwd/rev, and fast scroll through the frames (or play back at various speeds).
Ok, I'll buy in that there is always a start bit, but to reconfirm regarding the 1000Z it must be hard coded in some covnentional manner because there isn't anyway in the menu to specifiy anything regarding the start bit. Perhaps we are seeing the start bit and the stop bit in between each green data bit box?
I'm not sure where you got your info from, Mark, but the DS2000 can't set markers or search through captures (deep memory or individual segments) based on conditions. I wish it could do BOTH of those things - since they (along with an improved EXTERNAL trigger usage) are, IMHO, the main features lacking from the DSO.
What it can do is analyze the difference between segments based on a template and provide a histogramatic result. Is this feature lacking in the DS1000Z series (assuming you have the REC option)?
If you are up for it, I'd like to focus on the bytes that don't decode nicely into 10101010 and their companion 85.
Hey, small discovery: My ASCII table lists U as 1010101, not 10101010; which is fair/understandable since ASCII is generally considered to have 7 bits (vs. EBCDIC's 8 bits).
So maybe although my HyperTerminal setting specifies 8 bits and the 1000Z is set for 8 bits we are seeing some "padding" with the extra 0 that is adding some confusion. I think I'll try again setting both HyperTerminal and the 1000Z to 7 data bits.
A small update - if you change data bits, start bits, or parity bit to anything other than the correct value the scope displays very distinctive purple question marks along the green decoder boxes - so I'm thinking those are set correctly.
That's a very powerful capability. Can't you also step between the "error" frames directly (skipping the others)? That would then essentially be a form of Marker function.
I'll defer to EF, or someone who actually has a DS1000Z to confirm for sure, but as far as the docs are concerned, it has no such capability. Record, Play, Step, Jump. That's about it.
...the main lack of the Marker feature is when moving around a single-shot, deep-memory waveform (although my RUU add-on software provides some of that capability).
QuoteI'll defer to EF, or someone who actually has a DS1000Z to confirm for sure, but as far as the docs are concerned, it has no such capability. Record, Play, Step, Jump. That's about it.
Good to know - although strange they wouldn't have included the Analyze feature as part of the REC package. Perhaps it's a firmware space issue (or maybe just marketing differentiation)?
A small update - if you change data bits, start bits, or parity bit to anything other than the correct value the scope displays very distinctive purple question marks along the green decoder boxes - so I'm thinking those are set correctly.
Yes, and that confirms it does flag error bytes. You do have those set properly, but I think you meant Stop bits, not Start bits, since there's no setting for the later. Parity, Stop, and Data bits are good. It's just the MSB and polarity you have screwed up.
Ok, I'll buy in that there is always a start bit, but to reconfirm regarding the 1000Z it must be hard coded in some covnentional manner because there isn't anyway in the menu to specifiy anything regarding the start bit. Perhaps we are seeing the start bit and the stop bit in between each green data bit box?
You are. Sort of. Look at the flat green line between each decoded symbol box. Then look above the the waveform during that interval. In every case, it appears to be a High, followed by a Low. Two bit-times. That's a Stop-bit, followed by a Start-bit, but the polarity is inverted! (In reality, it should be a Low=Stop and High=Start. Look at the earlier diagram.) That suggests a 1-bit skew, since the bits are always toggling during those intervals.
Electro Fan
I've just grabbed a screen shot of a correctly set up rs232 decode and trigger on my DS4K.
H time base is set at 104 µs to have exactly one bit per div (1/9600), it helps to isolate each bit when you have a long burst of 0 or 1's.
RS-232 trigger is set to the start bit to be sure to have the start of the frame at the left of the screen.
This is important as the decoders are starting to decode on what they "see" on the screen, so if for instance you have half a frame cut out of the screen, the decoder will start to try to decode from the first high bit (start bit) it thinks it sees, leading to evident decoding errors for the rest of what is on screen.
This is why it is uttermost important that the rs232 trigger is set correctly.
The accuracy of the decoding is tied to proper triggering and positioning of the frames on screen.
You can also note that the data display is correctly aligned with the "data" content of the frame, it starts at the first bit (LSB), after the start bit, and stops at the end of the last bit (MSB), just before the stop bit (which is MARK, just as the idle time between frames)
And the binary value displayed is perfectly consistent with the bit states of the frame (in reverse reading order of course as the frame is transmitted LSB first (left) and a binary value is read MSB first from left to right)
The data btw is a capital "U" as you seem to be fond of.
It's on a DS4K so the display may look a bit different, but still close enough.
The settings of both trigger and decoder are on "Normal" polarity here because I used a real rs-232 signal +12V for a 0 and -12V for a 1.
The polarity inversion is necessary when you are in the TTL domain, after a MAX232 for instance.
And both are on LSB as RS-232 normally transmits the LSB first.
Hope this helps.