Rigol DHO804 Test and Compare Thread

[csuhi17]

I don't follow Siglent threads...

You can tell, but in this case make an exception and check out the appropriate thread, otherwise this is getting too offtopic.

OK, I just noticed this in the second post of the "SDS1000X HD coming" thread.



Let's see... 200Mhz bandwidth, 250MSa/sec .... doesn't that break Nyquist?   

ENOB 8.4??? 

These data do not seem real!
Based on the pictures in the topic linked above, 2Gs/s.

[2N3055]

It looks like Siglent is more closely on Rigol's tracks now with the SDS1000X HD

But can they compete on price? I doubt it. Not without an ASIC.

Does anybody have a price prediction or possible feature set yet? I don't follow Siglent threads...

You have no data at what prices Siglent buys parts.. Just saying...

There is another consideration here.. Is Siglent really so eager to sell cheapest possible stuff..
We already said that SDS1000X HD will be at least a level up from HDO1000...

Comparing it to DHO900 is just not correct.

[2N3055]

I don't follow Siglent threads...

You can tell, but in this case make an exception and check out the appropriate thread, otherwise this is getting too offtopic.

OK, I just noticed this in the second post of the "SDS1000X HD coming" thread.



Let's see... 200Mhz bandwidth, 250MSa/sec .... doesn't that break Nyquist?   

ENOB 8.4??? 

These data do not seem real!
Based on the pictures in the topic linked above, 2Gs/s.

That data is not correct. Incoming SDS1000X HD will have better specs.  It is all there in topic for it.
No need for poluting thread here with different models (Rigol and Siglent)

[ebastler]

I may have overlooked it -- has anyone tested serial decoding with the DHO800/900 yet? I was wondering whether it does a better job than the old DS1000Z series, which always uses only the data on the screen for decoding.

The two attached DS1054Z screenshots illustrate the limitation I am concerned about: Even in Zoom mode, when the beginning of the message is outside of the zoomed-in window, it will not be decoded and the decoder struggles to get in sync. The decoder ignores the available data just before the zoomed-in region, never mind that they are right there, displayed in the upper part of the screen.

Does the DHO800 handle this properly? And out of interest, does the MSO5000, if anyone happens to know?

[Fungus]

I may have overlooked it -- has anyone tested serial decoding with the DHO800/900 yet? I was wondering whether it does a better job than the old DS1000Z series, which always uses only the data on the screen for decoding.

In non-zoom mode it works like the DS1054Z. In zoomed mode it seems to do a full memory decode. If you enable a lot of memory then the screen update starts to get really slow (the first time I've noticed these slow down...)

Here's some data on screen in non-zoom mode:


Here's what happens if you scroll it off screen:


This is zoom mode - going off screen isn't a problem.  Edit: If you look closely you can see that "B1" is shown in miniature in the top part of the screen, ie. it's definitely doing a full memory decode when zoomed.


You also get a full-memory event table in zoom mode. Scroll up/down to see it all...

[ebastler]

In non-zoom mode it works like the DS1054Z. In zoomed mode it seems to do a full memory decode. If you enable a lot of memory then the screen update starts to get really slow (the first time I've noticed these slow down...)

Great -- thank you very much for testing this! Seems like a decent implementation, offering the user both options: Fast interactive navigation in non-zoom mode (but with possible decoding glitches at the left edge); and proper, robust decoding in zoom mode.

If any MSO5000 users happen to follow along: Is it the same there, or is the MSO5000 as limited as the DS1054Z (i.e. without the robust decoding in zoom mode)?

[Fungus]

Great -- thank you very much for testing this! Seems like a decent implementation, offering the user both options: Fast interactive navigation in non-zoom mode (but with possible decoding glitches at the left edge); and proper, robust decoding in zoom mode.

It's worth noting that using a mouse* works really well in zoomed mode. You can scroll up/down the table using the mouse wheel and drag the zoom box around to areas of interest.



(*) Or stylus. Seriously, people, get a stylus...

[Martin72]

If any MSO5000 users happen to follow along: Is it the same there, or is the MSO5000 as limited as the DS1054Z (i.e. without the robust decoding in zoom mode)?

Maybe this could help:
https://www.eevblog.com/forum/blog/new-rigol-scope/msg2034745/#msg2034745

[ebastler]

Maybe this could help:
https://www.eevblog.com/forum/blog/new-rigol-scope/msg2034745/#msg2034745

Thanks! That suggests that the MSO5000 does use the deeper memory for decoding, not just the screen buffer. On the DS1054Z, decoding falls apart as soon as you can't make out the individual bits on the screen anymore.

[Martin72]

Decoding table export:
Only what is currently on the screen is decoded and displayed in the table.
If you then export the table, only what was displayed is included and rigol could also think again about the correct formatting.

[Fungus]

Decoding table export:
Only what is currently on the screen is decoded and displayed in the table.
If you then export the table, only what was displayed is included and rigol could also think again about the correct formatting.

Try it in zoom mode...

In zoom mode you should be able to set maximum memory depth then capture/decode a LOT of data.

[Fungus]

I guess you live in one of the countries where Microsoft decided the "Comma" part of "CSV" shouldn't be taken literally.



I think Excel has a special import option to fix it but don't ask me where.

Microsoft 

[ebastler]

I guess you live in one of the countries where Microsoft decided the "Comma" part of "CSV" shouldn't be taken literally.
I think Excel has a special import option to fix it but don't ask me where.
Microsoft 

Yeah, can't use a comma here to separate fields, because we use that to separate decimal places... Can't blame Microsoft, I guess; it's a German thing.  

Micrososoft either lets you switch this stuff globally, or specifically when importing a file. But both options are annoying...

[Martin72]

Try it in zoom mode...
In zoom mode you should be able to set maximum memory depth then capture/decode a LOT of data.

To be able to zoom in, you had extended your time base to 20ms/div.
This means that several packets can be seen on the screen and are also decoded.
And the table is then also filled accordingly.
Wait, I have to look at something (Webcontrol is great, the scope is running in the other room and I don't have to go there...)

[Fungus]

Yeah, can't use a comma here to separate fields, because we use that to separate decimal places...

Yes you can. The original CSV standard says to put quotes around fields that have a comma in them.

Can't blame Microsoft

Yes you can.

[Fungus]

I set horizontal to 2s/div and did a big capture.

It decodes OK but there's a limit...

[Fungus]

It decodes OK but there's a limit

But... I exported a CSV file and there's 3000 values in it.

Maybe the limit is only in the display.

Edit: I did one at 5s/div and it still exported 3000 values.

[ebastler]

It decodes OK but there's a limit

But... I exported a CSV file and there's 3000 values in it.

Maybe the limit is only in the display.

Is there a way to search in the results table (for a specific data value), and then jump to that position in the trace by clicking the table entry? Or scroll through the table, click a line, and go to the right trace position that way?

[Martin72]

I exported a CSV file and there's 3000 values in it.

From the table, right ?

but there´s a limit..

Sounds familar to me, siglent specifies the maximum number of packets in its data sheets, depending on the decoder.

[csuhi17]

https://www.copytrans.net/support/how-to-open-a-csv-file-in-excel/

[Fungus]

Is there a way to search in the results table (for a specific data value)

No.

and then jump to that position in the trace by clicking the table entry? Or scroll through the table, click a line, and go to the right trace position that way?

No, but the times are shown in both windows so it's not hard to find:

[ebastler]

Thank you for checking!

Not having the link from the data table back to the trace seems like a usability miss -- it would be such an obvious thing to do on the touch screen. And I can certainly see the use, when e.g. you see an unexpected byte in the table and want to check whether it's due to corruption of the signal.

[ebastler]

A quick UI question -- don't think I saw this mentioned anywhere:

Do the two "general purpose" encoders have detents? If not, do they suffer from the "Rigol disease" of liking to slip to the next position the moment you push down on the encoder knob?

(Or do you simply not push these knobs anymore, but rather tap somewhere on the touch screen to confirm data entry?)

[Fungus]

Do the two "general purpose" encoders have detents?

No.

(Or do you simply not push these knobs anymore, but rather tap somewhere on the touch screen to confirm data entry?)

You don't really push them. They just change numbers on screen when you turn them, no need to confirm anything.

[ebastler]

You don't really push them. They just change numbers on screen when you turn them, no need to confirm anything.

Thanks! Thinking about it, you probably hardly use the encoders for "discrete" selections -- menu entries or virtual keyboards -- at all, since these are more easily available on the touch screen. So they really are largely "analog" controls, in which case detents don't make much sense. And even if, say, a cursor moves by one pixel when you push the knob, that would not cause much harm.