| Products > Test Equipment |
| REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol |
| << < (471/566) > >> |
| Mark_O:
--- Quote from: Teneyes on April 08, 2014, 03:13:37 pm ---Just to make it Clear to all; --- End quote --- Good idea. Make it clear to all, and not just me. ;) --- Quote ---Zooming has no effect if there are Decoding errors. The decoding is done on the full un-Zoomed data. --- End quote --- Thanks for showing it's possible to zoom in beyond the point where decoded data is showable, yet still properly detect and show the byte boundaries. However, that doesn't imply that decoding is done on the raw data, unzoomed or otherwise. Everything I've ever seen or read indicates decoding is done from the screen display data. And it's actually unnecessary to go beyond that. If you consider how many decoded chars you can get on the screen at once (about a dozen), or even the collapsed <...> bytes (about twice that), it's still well within what would be expected when working from the 700 display samples (down to 240 bit-cells, in that case). --- Quote ---Below I show 3 displays where the errors still exists. Note you can see the error gaps --- End quote --- Yes, I can. Thanks! I find it quite interesting that, in spite of your hypothesis that whenever the samples/bitCell is <28, it fails, in fact it is still working, most of the time (82%). And look at the pattern... 2 correct, 1 skipped, 3 correct, 1 skipped. Repeat. This suggests that it's phasing in and out, or something similar. The ones it missed didn't have any fewer samples/bit than the ones it handled properly! I also like your grabs, which demonstrate that the Rigol displays the contents adaptively. "Data: 0xNN", to "D:0xNN", to just "0xNN", to <...>. --- Quote ---Also Note that if there are errors in non- Record mode there will be errors in the recorded frame ( same recorded points are used, Not the display data) --- End quote --- Well of course if there are any errors at any point in the acquisition process, there will be errors in Recorded frames. However, A implies B doesn't mean the converse is also true. |
| kff:
Is anyone else seeing a screen flicker in their ds2072a? It is especially noticeable on grays, and is probably caused by backlight leds. I would estimate the frequency at 40-60 hz. I searched here and on Google and surprisingly didn't find any posts mention this. Did I get a bad unit, or are you all less picky than I am? The scope is not modified in any way. |
| Teneyes:
--- Quote from: Mark_O on April 09, 2014, 05:02:13 am --- I find it quite interesting that, in spite of your hypothesis that whenever the samples/bitCell is <28, it fails, in fact it is still working, most of the time (82%). And look at the pattern... 2 correct, 1 skipped, 3 correct, 1 skipped. Repeat. This suggests that it's phasing in and out, or something similar. The ones it missed didn't have any fewer samples/bit than the ones it handled properly! --- End quote --- I was wrong I did more tests and I think I can show the limit for samples per bit for good decoding The setup: 14K Pts 500us/div 2MSa/sec 400Kb/s , 500Kb/s , 666Kb/s , 900Kb/s See Displays for: 5 Samples per Data Bit 4 Samples per Data Bit 3 Samples per Data Bit 2 Samples per Data Bit A quirky Display My Conclusion, The requirement for good decoding is 4 samples per Bit (RS232) |
| Circlotron:
--- Quote from: kff on April 09, 2014, 07:26:45 am ---Is anyone else seeing a screen flicker in their ds2072a? It is especially noticeable on grays, and is probably caused by backlight leds. I would estimate the frequency at 40-60 hz. I searched here and on Google and surprisingly didn't find any posts mention this. Did I get a bad unit, or are you all less picky than I am? The scope is not modified in any way. --- End quote --- I noticed it a little when you are looking down toward the screen maybe 60 deg off axis but not when looking straight on. Mostly when the menus were showing and I *think* just after switch-on. |
| Mark_O:
--- Quote from: Teneyes on April 09, 2014, 03:53:54 pm --- --- Quote from: Mark_O on April 09, 2014, 05:02:13 am --- I find it quite interesting that, in spite of your hypothesis that whenever the samples/bitCell is <28,... --- End quote --- I was wrong I did more tests and I think I can show the limit for samples per bit for good decoding ... My Conclusion, The requirement for good decoding is 4 samples per Bit (RS232) --- End quote --- Nicely done. I concur that 4 samples/bit is the magic number here (and not 28). :-+ (Though it may not specifically be a requirement for those 4 samples, but rather that anything less will result in the start/end phase of a bit-cell falling out of sync tolerance.) Think about what that implies for acquiring comms-type data in segments, in RecordMode! Properly adjusted, the duration and size can be quite amazing. At just 4 samples/bit, that's 7x(!) as long as you originally thought possible. |
| Navigation |
| Message Index |
| Next page |
| Previous page |