Author Topic: Rigol DS1074Z-S - Random use videos  (Read 52166 times)

0 Members and 1 Guest are viewing this topic.

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
New Rigol DS1104Z - First Impressions
« Reply #25 on: November 05, 2013, 06:17:24 am »
Heads-up - this is where my "it's not a review" starts, but there are parts of this that are confused and confusing as it relates to decoding, and there are more confused and confusing posts I made that follow; if you want to follow my confusion - read them all; if you want to get closer to the conclusion read this post (#25) and then jump to reply #48 and continue from there.  (In between where you see posts from other members - those are worth reading; mine maybe not so much unless you are really into watching a new guy learn decoding.)  Just trying to help readers navigate and use their time effectively.   Thx, EF

Ok, here is where the rubber has met the road.

Attached are some photos from my new Rigol DS1104Z.  (I passed on the S version as I have a function generator that does some of what I need/want and I figured if I like the scope enough maybe I'll go for a DG4062).

First - Thanks! to the many EEVers here who have provided so many great posts.  If it wasn't for this site I might not have discovered Rigol and/or I might not have had the confidence that Rigol could build such a great scope.

This purchase represents about a half year of product research and anticipation.  (Somewhat thorough, maybe; quickly decisive on this, not so much.)  What had me thrown for a loop was my strong desire to find the intersection between DSOs and Logic Analyzers without having to jump too far up the food chain on a somewhat pricey MSO.  Anyway, today the 1104Z arrived - so my impressions are very preliminary - but I can also say the impressions are (knock on wood) very positive!

The Rigol packaging includes a nice double box.  The unit itself stuck me as compact in a good way and the construction appears solid with good workmanship.

Coming from an analog Tektronix (2247A) scope that I've loved using there was some possibility that I could have plugged-in and turned on the DS1104Z and said "so what's the big deal?" but I am happy to say I immediately recognized the big deal when I saw it.

As soon as it booted up I had my first serious "I get why this is very cool" impression.  I guess I should have expected that the difference between a vintage green screen and a color display would be notable.  A friend of mine who worked many years ago for Xerox said they taught him that color has "impact and distinction."  Indeed!

The next thing is that the screen is sharp.  While some of the lettering rendered on the screen is on the small side it is clear.  Overall I'd say my impression of the screen is "gorgeous" - but again my beloved (nearly vintage) Tek scope is the reference.  Speaking of relative, the fan on the DS1104Z sounds pretty close to whisper quite (or at least it's very minor backgroud noise) compared to the fan on the 2247A.  I don't know if I got an especially good fan in the Rigol or if other users were hoping for no fan sound whatsoever, but of all the things that would bug me the sound of this fan isn't one of them. 

I just started pressing buttons and turning knobs and my first reaction is that the controls are in very reasonable locations on the front panel, they have nice enough action, and the scope is very friendly overall.  I've already found a few menu items here and there where I could probably come up with a reason to change this or that but nothing serious at all - and I'm so new to the scope that I'm willing to forgo any judgments until I can better understand what might have been the reasoning behind the design.

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.)   In addition to being nearly blown away by the modern day advancement of color I found that a digital scope is MUCH easier for triggering and especially navigating signals than an analog scope.  Hello this century!

Moving further into modern technology I worked my way through the decoder options, and low and behold I was able to get the scope to decode my alternating high and low voltage waveform into ASCII U’s!  Next I was able to press the Format soft menu key to select BIN and what did I get? 01010101  Well, this might be really good or it might be a wif.  According to the documentation I have regarding ASCII characters, it appears that a capital U is in fact alternating 1s and 0s, but it should be 10101010 (not 01010101).  I have played with the soft menu to try various combinations of polarity and MSB and LSB but so far I haven’t been able to figure out what’s up with this.  It is possible that this is a software/firmware bug (this might be along the lines of some issues reported by AndyC_772) or this might very well be (probably is) my own user error.  On the other hand, when the U character is displayed under Format as a DEC setting it shows 85 which in fact is the right number according to the ASCII table I am using.  So unfortunately, I think it might be a firmware error.  My take on this is that if it is my error, shame on me; if it is a Rigol error no big deal – I’m sure they can and will fix it.

Zooming out (figuratively), I am ecstatic that what I imagined was doable on an oscilloscope – the ability to observe waveforms and decode characters in ASCII, Binary, Hex and Decimal is not only doable, but it is pretty straight forward and easy (and fun) to use – and it is doable at a very nice price point with a very good looking scope.

I haven’t gotten around to finding a reason yet for why I had to have 4 channels (instead of getting a bigger display with better performance on the DS2000 series) but hey, it’s my first couple hours with the scope.  My initial reaction is that by the time I get 4 channels displayed at the same time the display might be kind of small/cramped but maybe the idea is that you can have all 4 channels hooked up and ready to observe and then you can turn each channel on and off as needed.  My guess is that with all 4 channels doing something useful (SPI?) it will be cool.

So far (knock on wood): :-+ :-+   
« Last Edit: November 05, 2013, 01:47:25 pm by Electro Fan »
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
DS1074 More Decoder Stuff
« Reply #26 on: November 05, 2013, 08:37:27 am »
Big caveat:  could be lots of user error here.
Here is an image showing both decoders working on the same signal.  Setup is for transmit and receive with one decoder Format set for BIN and the other for ASC.  For some reason Rigol labels the top 2 green decoder lines B1 and the second 2 B2; I'm wondering why they didn't lable them D1 and D2 (as in Decoder 1 and Decoder 2)?

Also, I'm still wondering if the LSB and MSB settings aren't reversed.  I'll try to post another image showing my question/reasoning on this.

« Last Edit: November 05, 2013, 09:25:09 am by Electro Fan »
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Rigol DS1104Z LSB and MSB Decoding
« Reply #27 on: November 05, 2013, 09:02:39 am »
Another Standard Disclaimer:  Could be lots of User Error here
Ok, here are two images of the same waveform - only difference is the Order setting.  One is with LSB the other is with MSB.

Notice that in the LSB image the byte on the left is a lower case u and it is associated with 01110101.  The byte on the right is an upper case U and it is associated with 01010101.  Per the earlier posts, the upper case U supposedly is represented by a symetrical sine wave which is the case here, but also as per the earlier posts the upper case U supposedly is 10101010 (rather than 010100101).

Be all that as it may, the lower case U (represented by 01110101) sits below a waveform that seems to have symetrical highs and lows at the beginning of the byte and a long/continuous low at he end of the byte.  IE, the 1s and 0s look bass ackwards from the waveform above.

To help make this point, take a look at the second image labeled MSB.  In this image we see that with the order set for MSB we get a Binary readout of 10101110 - which seems to nicely correlate with the shape of the waveform above.  However, we can also see that both this byte (on the left) and the other byte (on the right) are now decoded as a "." (period) rather than as a U (either upper or lower case).  The image doesn't show it, but if I turn the Format on the MSB waveform from ASC to DEC the scope says 174 for the byte on the left and 170 for the byte on the right.  174 is supposed to be the registered trade mark sign and 170 is supposed to be the feminine ordinal indicator.

Long story short, I think it is very very cool to be able to see the decoder lines line up on the highs and lows of the waveform and in theory the ability to decode into various formats (Binary, Hex, Decimal, ASCII and Line - although I'm not clear on the difference beween Binary and Line) is very cool, but I think it would be good for me to figure out how to use this better, or if the firmware isn't working right then that should be fixed.

- For what it is worth Wikipedia claims:  "The X3 committee also addressed how ASCII should be transmitted (least significant bit first)"

Either way, I can see the promise in this and it is somewhere between outstanding and exquisite  :)
« Last Edit: November 05, 2013, 09:24:54 am by Electro Fan »
 

Offline casper.bang

  • Frequent Contributor
  • **
  • Posts: 311
  • Country: dk
  • Pro SE, amateur EE.
    • BangBits
Re: Rigol DS1074Z-S - Random use videos
« Reply #28 on: November 05, 2013, 09:26:15 am »
Interesting stuff Electro Fan, keep it coming. :) I wonder, can you say something about the amount of data packets (bytes) you are able to record using the DS1000z's 12Msample memory? I suspect we're talking several hundreds bytes when dealing with RS-232 speeds of max. 115200 or?!
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Re: Rigol DS1074Z-S - Random use videos
« Reply #29 on: November 05, 2013, 09:41:32 am »
Still trying to figure this out.

In the image below I adjusted the decoders to use MSB and I changed the polarity.

In this arrangement the polarity shows high voltage as 1s and low voltage as 0s.

Together these settings show the alternating 10101010 binary string to be decoded as 85 which is an upper case U in the ASCII table.

This seems to fly in the face of the Wikpedia entry that claims that ASCII supposedly standardized on LSB.

Another area of (my) uncertainty is whether it is the ASCII convention or the RS232 convention that determines the polarity (ie, whether high voltage is represented by a one or a zero).  Either way, (whether it's ASCII code or the RS232 protocol that determines polarity) it does seem that using the combination shown below we have two "benefits":

1. the waveform pattern correlates with symmetry to the 1s and 0s
2. the Rigol decoder decodes 10101010 as an 85 which corresponds to the ASCII table

I'm ready for someone that knows more than me (pretty much all the EEVers here, I'm betting) to sort me out on what's what with ASCII, polarity, and significant bit ordering.

Thanks, EF
« Last Edit: November 05, 2013, 01:39:42 pm by Electro Fan »
 

Offline casper.bang

  • Frequent Contributor
  • **
  • Posts: 311
  • Country: dk
  • Pro SE, amateur EE.
    • BangBits
Re: Rigol DS1074Z-S - Random use videos
« Reply #30 on: November 05, 2013, 09:48:28 am »
Quote
Another area of (my) uncertainty is whether it is the ASCII convention or the RS232 convention that determines the polarity (ie, whether high voltage is represented by a one or a zero).

In my experience with RS-232, on the wire, a logical low is usually represented as high voltage and logical high as low voltage. If you start hooking up a "real" RS-232 signal and play with parity, stop bit etc. you can observe these things a little better perhaps.

In the screendump below, you can see almost 3 cycles where I captured 0x55, 0x00, 0xFF (being repeated) at 8N1.
« Last Edit: November 05, 2013, 09:55:40 am by casper.bang »
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Re: Rigol DS1074Z-S - Random use videos
« Reply #31 on: November 05, 2013, 09:53:31 am »
Interesting stuff Electro Fan, keep it coming. :) I wonder, can you say something about the amount of data packets (bytes) you are able to record using the DS1000z's 12Msample memory? I suspect we're talking several hundreds bytes when dealing with RS-232 speeds of max. 115200 or?!

Well, it's too early for me to say anything definitive about this (or much else other than I need some sleep) but on a very preliminary basis I think I found some record functionality buried in the menu system.  I'm concered that this is going to remind me of one of the reasons I was on the fence about the 1000z vs. the DS2000 series with it's beautiful big Nav knob prominently located where it can easily be found and used, not to mention the highly visible VCR-like lights.

With respect to how much memory at what sample rate is needed to do what I am barely able to figure out what's doing what to what along these lines.  Once I figure out how to decode something accurately I'm planning to move on to other key functions such as record and playback, and along the way I'll hopefully figure out the real world implications of the memory and it's relationship to sampling and the associated impact on waveform fidelity.  I get this stuff (almost) in theory, but after having been reading about it for 6 months it is a blast having the chance to work with it hands-on.  It's kind of like having been reading about the mountains while growing up in the plains states and now we're on vacation at the foot hills of the Rockies - very exciting - but I'm sure to the locals I look like a tourist :-DD
« Last Edit: November 05, 2013, 09:56:20 am by Electro Fan »
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Re: Rigol DS1074Z-S - Random use videos
« Reply #32 on: November 05, 2013, 10:04:01 am »
Quote
Another area of (my) uncertainty is whether it is the ASCII convention or the RS232 convention that determines the polarity (ie, whether high voltage is represented by a one or a zero).

In my experience with RS-232, on the wire, a logical low is usually represented as high voltage and logical high as low voltage. If you start hooking up a "real" RS-232 signal and play with parity, stop bit etc. you can observe these things a little better perhaps.

In the screendump below, you can see almost 3 cycles where I captured 0x55, 0x00, 0xFF (being repeated) at 8N1.

I am guessing this is correct - which means, I think, that a "0" is used to represent a high voltage and a "1" is used to represent a low voltage.  I'd be happy if this turns out to be standard RS232 convention  :)

In which case we just need to figure out what drives the choice between MSB and LSB.  If MSB is dictated by either ASCII or RS232 Rigol would seem to have it right.  If it turns out we need LSB I'm thinking Rigol might need to make an adjustment.  But to be clear - I don't know. So just read my posts today/tonight as the learnings of a guy trying to figure stuff out.  The DS1000Z is very cool.
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Alignment Question
« Reply #33 on: November 05, 2013, 10:10:14 am »
Another observation/question:

Regardless of the convention, LSB or MSB and the polarity, why don't the BIN and DEC decode bytes align?

In my mind, the decode boxes should line up on the start and end of the waveform bytes they are decoding.  The BIN and DEC boxes should be horizontally consistent with each other, no? 
« Last Edit: November 05, 2013, 10:11:47 am by Electro Fan »
 

Offline casper.bang

  • Frequent Contributor
  • **
  • Posts: 311
  • Country: dk
  • Pro SE, amateur EE.
    • BangBits
Re: Rigol DS1074Z-S - Random use videos
« Reply #34 on: November 05, 2013, 10:39:36 am »
It almost looks like one of the interpreters got the start-bit wrong. Why don't you try to send an ASCII "p", bit-pattern 0111000? It would show a little easier which one is wrong (one of them has to be wrong). Also, is this consistent from the get go, or could it perhaps have something to do with you adding interpreters and triggering on an ongoing signal?
« Last Edit: November 05, 2013, 10:44:22 am by casper.bang »
 

Offline evanh

  • Contributor
  • Posts: 45
  • Country: nz
Re: Rigol DS1074Z-S - Random use videos
« Reply #35 on: November 05, 2013, 10:55:24 am »
For RS232, line driver levels are positive polarity.  They internally invert the signal, as do the UARTs.  This means the intermediate logic levels are negative polarity.

I'm gonna guess, not having my scope to play with right now, there is separate settings for MSB and LSB decode options.  I say this because it appears your example LSB decode is using negative polarity, 10101110, while at the same time the MSB decode is using positive polarity, 10101000.

The reason for the one bit offset is due to the requirement of start bit sync'ing.

With positive polarity a stop is high and a start is low - Making the first low a start bit, which, in turn, makes the second high on the display the most significant bit of the data byte.

With negative polarity a stop is low and a start is high - Making the second high a start bit since the initial state must be an idle (stop bit), which, in turn, makes the second low on the display the least significant bit of the data byte.
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Re: Rigol DS1074Z-S - Random use videos
« Reply #36 on: November 05, 2013, 10:56:59 am »
It almost looks like one of the interpreters got the start-bit wrong. Why don't you try to send an ASCII "p", bit-pattern 0111000? It would show a little easier which one is wrong (one of them has to be wrong). Also, is this consistent from the get go, or could it perhaps have something to do with you adding interpreters and triggering on an ongoing signal?

I don't think it's a matter of the sequence of 1s and 0s; the green decode boxes (whether they are displaying ASCII or Decimal or Binary) should align with one another - as well as with the waveform.
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Re: Rigol DS1074Z-S - Random use videos
« Reply #37 on: November 05, 2013, 11:10:00 am »
For RS232, line driver levels are positive polarity.  They internally invert the signal, as do the UARTs.  This means the intermediate logic levels are negative polarity.

I'm gonna guess, not having my scope to play with right now, there is separate settings for MSB and LSB decode options.  I say this because it appears your example LSB decode is using negative polarity, 10101110, while at the same time the MSB decode is using positive polarity, 10101000.

The reason for the one bit offset is due to the requirement of start bit sync'ing.

With positive polarity a stop is high and a start is low - Making the first low a start bit, which, in turn, makes the second high on the display the most significant bit of the data byte.

With negative polarity a stop is low and a start is high - Making the second high a start bit since the initial state must be an idle (stop bit), which, in turn, makes the second low on the display the least significant bit of the data byte.

Ok, this is good - let's take it a line at a time:

For RS232, line driver levels are positive polarity.  They internally invert the signal, as do the UARTs.  This means the intermediate logic levels are negative polarity.

- what does "intermediate" mean?  I am under the impression that voltage is either high or low; same with logic - it is either a 1 or a 0.  What is intermediate?  Please explain.  Thx

I'm gonna guess, not having my scope to play with right now, there is separate settings for MSB and LSB decode options.  I say this because it appears your example LSB decode is using negative polarity, 10101110, while at the same time the MSB decode is using positive polarity, 10101000.

- Yes, MSB or LSB can be set; separately the polarity can be set.

The reason for the one bit offset is due to the requirement of start bit sync'ing.

- each byte has 8 data bits and one stop bit.  The stop bits should always align as should the 8 data bits.  I see no reason (other than errors) for losing sync.

With positive polarity a stop is high and a start is low - Making the first low a start bit, which, in turn, makes the second high on the display the most significant bit of the data byte.

- there is no "start" bit; only 1 stop bit (and no parity).  Seems like there should be 8 data bits followed by a stop bit.  Every 9th bit should be the same (ie, the stop bit) everything else is subject to change according to the data characters being transmitted.  In my examples almost all the characters should have been upper case Us.  (It is possible that something else got inserted such a Line Feed or a Carriage Return here or there.)

With negative polarity a stop is low and a start is high - Making the second high a start bit since the initial state must be an idle (stop bit), which, in turn, makes the second low on the display the least significant bit of the data byte.

- Again, my setup doesn't specify a start bit but maybe by convention there is alwyas a start bit?  Even so, if there is anything resembling consistency, why wouldn't the decode byte boxes line up?  The only time they shouldn't align is if there is an error.  Once upon a time I thought I saw a demo somewhere saying some types of errors were flagged with a red marker - maybe that was on a different scope.
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Re: Alignment Question
« Reply #38 on: November 05, 2013, 11:24:49 am »
Another observation/question:

Regardless of the convention, LSB or MSB and the polarity, why don't the BIN and DEC decode bytes align?

In my mind, the decode boxes should line up on the start and end of the waveform bytes they are decoding.  The BIN and DEC boxes should be horizontally consistent with each other, no?

Ok, should have gone to bed much earlier - just answered at least one of my own questions.  Why don't the green decode boxes line up?  Duh, one set was on MSB and othe other was on LSB.   :palm: |O

__________

In the attached image MSB seems to correlate/align better with the waveform but MSB does not seem to be the popular convention, still trying to sort this out.
« Last Edit: November 05, 2013, 11:28:06 am by Electro Fan »
 

Offline evanh

  • Contributor
  • Posts: 45
  • Country: nz
Re: Rigol DS1074Z-S - Random use videos
« Reply #39 on: November 05, 2013, 11:27:27 am »
- what does "intermediate" mean?  I am under the impression that voltage is either high or low; same with logic - it is either a 1 or a 0.  What is intermediate?  Please explain.  Thx

I was meaning the electrical wiring, generically referred to as logic levels as opposed to line driver levels, between the UART serial controller and the hardened line drivers/receives.


Yes, UARTs always use a start and stop bit arrangement.  And idle between bytes in the stop state.  This way they can operate without any reference clock.

In terms of what I would expect of what's on the display, I'd go for positive polarity and LSB.  That would make the bit pattern a STOP at the very left edge then START then 10101000 in little endian makes 00010101 in big endian (which is how we read numbers) which is 21 decimal, 15 hex, which in ASCII terms is a NAK or ^U.
« Last Edit: November 05, 2013, 11:53:16 am by evanh »
 

Offline casper.bang

  • Frequent Contributor
  • **
  • Posts: 311
  • Country: dk
  • Pro SE, amateur EE.
    • BangBits
Re: Rigol DS1074Z-S - Random use videos
« Reply #40 on: November 05, 2013, 11:38:03 am »
Once upon a time I thought I saw a demo somewhere saying some types of errors were flagged with a red marker - maybe that was on a different scope.

The DS2000 series scope can do this:
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Aye Yay Yae....
« Reply #41 on: November 05, 2013, 11:39:38 am »
Ok, here is an image - where both the Binary and the Decimal Decoders are set for LSB - but they don't align with one another.  I just don't see any reason to graphically represent the same waveform with two different types of decodes - which represent the same byte - but then place them at two different positions horizontally in time.
 

Offline nowlan

  • Frequent Contributor
  • **
  • Posts: 649
  • Country: au
Re: Rigol DS1074Z-S - Random use videos
« Reply #42 on: November 05, 2013, 11:43:44 am »
Asynchronous always use start bits. From what I can see, the LSB is sent first.

Suggest reading Port Serial Complete by Jan Axelson.
 

Offline evanh

  • Contributor
  • Posts: 45
  • Country: nz
Re: Rigol DS1074Z-S - Random use videos
« Reply #43 on: November 05, 2013, 11:45:03 am »
It would help if there was more of the preamble showing.  And with your input setting of 5.00 Amps/div it's hard to tell if that is line driver levels or logic levels.
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Re: Rigol DS1074Z-S - Random use videos
« Reply #44 on: November 05, 2013, 11:46:17 am »
Once upon a time I thought I saw a demo somewhere saying some types of errors were flagged with a red marker - maybe that was on a different scope.

The DS2000 series scope can do this:

If the DS1000Z can do it I haven't found it yet.

It's starting to remind me of the Windows 8 tablet commercial where MSFT finally finds some things to make fun of Apple and the iPad says "do you still think I'm pretty?"  :D
 

Offline evanh

  • Contributor
  • Posts: 45
  • Country: nz
Re: Rigol DS1074Z-S - Random use videos
« Reply #45 on: November 05, 2013, 11:51:05 am »
Once upon a time I thought I saw a demo somewhere saying some types of errors were flagged with a red marker - maybe that was on a different scope.

The DS2000 series scope can do this:
That's I2C.  Can you find a UART based example?
 

Offline casper.bang

  • Frequent Contributor
  • **
  • Posts: 311
  • Country: dk
  • Pro SE, amateur EE.
    • BangBits
Re: Rigol DS1074Z-S - Random use videos
« Reply #46 on: November 05, 2013, 11:58:22 am »
That's I2C.  Can you find a UART based example?

Ah right, so it is! No I guess I remembered wrong then.
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Rigol DS1074Z-S - Random use videos
« Reply #47 on: November 05, 2013, 12:22:38 pm »
EF, congrats on your new acquisition.  I was starting to wonder if you might be in an "infinite evaluation" loop.  :)

Once upon a time I thought I saw a demo somewhere saying some types of errors were flagged with a red marker - maybe that was on a different scope.

The DS2000 series scope can do this:

If the DS1000Z can do it I haven't found it yet.

I'm pretty sure it does, but the only way to trigger it with that decoder would be to send an ASCII character with bad parity.  Red markers flag errors, and you'd need a Parity error, or missing Stop bit to get a red flag.

[Added later: OR, in the presence of noise or some other glitchy interfering signal, have the voltage level deformed enough that one of your data bits was damaged, caused the Parity to fail; or your Stop bit not to be detected properly.  That's the strength of having a multi-channel scope, vs. a pure LA analyzing your signals.  The LA may tell you something went wrong, but with the DSO you can see exactly why and where.  With the LA you operate "blind", and hope/assume your threshold levels are capturing the 0's and 1's correctly... and sometimes they are not.   :scared:]

Quote
It's starting to remind me of the Windows 8 tablet commercial where MSFT finally finds some things to make fun of Apple and the iPad says "do you still think I'm pretty?"  :D

I started to put together an explanation of what you were interpreting incorrectly or overlooking, but the list got too long, so I scrapped it.  ;)  Suffice to say that in spite of the ubiquity of ASCII data streams, RS232 data links, etc. that it's not completely trivial at the physical layer.  You can have polarity inversion, endian inversion, start bits, stop bits, parity bits, etc.  And when you look at it in that unfamiliar domain, it can be confusing.

But that's the whole reason you have the decoders in the first place... to sort all that out for you, and shift things from the physical to the logical domain.  If it was trivial to just read the bit stream off the scope (and RS232 is one of the simpler ones), then there'd be no need for decoders!  So you're doing things like looking at the physical patterns, and scratching your head wondering why they don't match up exactly with the logical... because they don't!   :phew:

Thanks for all the screen shots though.  I already learned something I didn't know... which was that you can have more than one decoder interpretation on the screen at the same time, for the same data stream.  In your case, binary & decimal.  Not overly useful, but I'd think you'd only get one. 

[Oh, and they use B1 to denote Bus1, copying those who came before them.  They'll need D1, D2, ... later for the 16 digital channels on their MSO.]
« Last Edit: November 05, 2013, 12:42:58 pm by Mark_O »
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Starting to dial-in decoding on the DS1104Z
« Reply #48 on: November 05, 2013, 12:41:32 pm »
It would help if there was more of the preamble showing.  And with your input setting of 5.00 Amps/div it's hard to tell if that is line driver levels or logic levels.

Here you go - set back on volts as it should be and more of the waveform has been captured for display.

The only way to get the 1s and 0s (the Binary Decodes) to align with the waveform is to set the polarity as shown in the attached image and to set MSB for the Binary Decodes - no other combination of polarity and bit order will allow the 1s and 0s to have alignment and symmetry with the waveform.

Keeping the polarity as shown in the image for both decoders is essential to accurately achieving the two forms of decoding.  (The two decoders must use the same polarity.)

Despite the above, the only way to get 85s (which I am sure is the number for capital Us) is to set LSB, not MSB for the second decoder (ie, the Decimal Decodes).  This will both yield the correct Decimal Decode (ie, show 85s) and also time align both decoders (the Binary and the Decimal), but it requires setting the two decoders to opposing orders (one for MSB and one for LSB) - which makes no sense.  If the second decoder is set for MSB (like the first decoder), it will yield incorrect Decimal Decodes.

I am about ready to say that Rigol has something out of wack - I wouldn't bet super heavily on it, but I'm leaning that way.

In summary

1. Some combination of settings should allow the 1s and 0s to appear with alignment and symmetry relative to the waveform.
2. The sequence of 1s and 0s must decode properly into ASCII, Hex, and Decimal.
3. The waveform and the two selected forms of decodes should all time align with one another.


So far it does not appear that any combination of settings will allow for all three of these statements to be true.

EF

Check out the symmetry and alignment between the waveform and the 1s and 0s in the image below - it is perfecto, beautiful, magnifico!!!  It is completely doable - we are looking at it here.

Check out the symmetry and alignment between the waveform and the 1s and 0s in the image below, and also the alignment with the second decoder (showing the decimal information) - again it is perfecto, beautiful, magnifico!!!  It is completely doable - we are looking at it here.

The only thing that is not right is that these results were achieved by jiggering the MSB and LSB settings - these results should have been achieved by using the same (LSB or MSB setting) on both decoders (one is right and the other is wrong - and Rigol should fix the one that is wrong).  If they get this squared away they have a Kick-A _ _ (Butt) solution.
« Last Edit: November 05, 2013, 01:53:34 pm by Electro Fan »
 

Online Electro Fan

  • Super Contributor
  • ***
  • Posts: 3160
Re: Rigol DS1074Z-S - Random use videos
« Reply #49 on: November 05, 2013, 12:50:32 pm »
EF, congrats on your new acquisition.  I was starting to wonder if you might be in an "infinite evaluation" loop.  :)

Once upon a time I thought I saw a demo somewhere saying some types of errors were flagged with a red marker - maybe that was on a different scope.

The DS2000 series scope can do this:

If the DS1000Z can do it I haven't found it yet.

I'm pretty sure it does, but the only way to trigger it with that decoder would be to send an ASCII character with bad parity.  Red markers flag errors, and you'd need a Parity error, or missing Stop bit to get a red flag.

[Added later: OR, in the presence of noise or some other glitchy interfering signal, have the voltage level deformed enough that one of your data bits was damaged, caused the Parity to fail; or your Stop bit not to be detected properly.  That's the strength of having a multi-channel scope, vs. a pure LA analyzing your signals.  The LA may tell you something went wrong, but with the DSO you can see exactly why and where.  With the LA you operate "blind", and hope/assume your threshold levels are capturing the 0's and 1's correctly... and sometimes they are not.   :scared:]

Quote
It's starting to remind me of the Windows 8 tablet commercial where MSFT finally finds some things to make fun of Apple and the iPad says "do you still think I'm pretty?"  :D

I started to put together an explanation of what you were interpreting incorrectly or overlooking, but the list got too long, so I scrapped it.  ;)  Suffice to say that in spite of the ubiquity of ASCII data streams, RS232 data links, etc. that it's not completely trivial at the physical layer.  You can have polarity inversion, endian inversion, start bits, stop bits, parity bits, etc.  And when you look at it in that unfamiliar domain, it can be confusing.

But that's the whole reason you have the decoders in the first place... to sort all that out for you, and shift things from the physical to the logical domain.  If it was trivial to just read the bit stream off the scope (and RS232 is one of the simpler ones), then there'd be no need for decoders!  So you're doing things like looking at the physical patterns, and scratching your head wondering why they don't match up exactly with the logical... because they don't!   :phew:

Thanks for all the screen shots though.  I already learned something I didn't know... which was that you can have more than one decoder interpretation on the screen at the same time, for the same data stream.  In your case, binary & decimal.  Not overly useful, but I'd think you'd only get one. 

[Oh, and they use B1 to denote Bus1, copying those who came before them.  They'll need D1, D2, ... later for the 16 digital channels on their MSO.]

I'm fully ready to believe that with LAs and DSOs stuff doesn't line up - that's why I've been on my mini-crusade to either find an affordable MSO or learn to live with 4 channels plus good decoders on an affordable DSO.

I will buy into B1 and B2 as being A-OK so we can save D1 and D2 for the MSO; that's very good.  Thanks

On the rest of this stuff though I'm holding out for symmetry and alignment.

I see no reason why the 1s and 0s shouldn't decode coincident with the waveform.  I don't care if we call high 1 and low 0 or low 1 and high 0 - the 1s and 0s should be visually evident relative to the waveform.

Next, if we use a given polarity to decode one form of information (ASCII, Decimal, HEX, or Binary), we should use that same polarity for the other forms.  Same with LSB/MSB - the same one should be invoked for each decoder used.

Next, the decoder boxes showing any of the forms of information (not just the Binary) should align with the waveform and also with any other displayed decoder box.

I think it is possible with a properly designed scope (ie, with properly designed decoders) to do this.


That's my opinion and I'm sticking to it (until some hits me with an EEV gong that brings me to my senses - which is something I realize could happen any moment now.)  :box:

« Last Edit: November 05, 2013, 01:06:30 pm by Electro Fan »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf