Products > Test Equipment
REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol
GermanMarkus:
--- Quote from: Teneyes on July 13, 2013, 04:36:25 pm ---
--- Quote from: GermanMarkus on July 13, 2013, 01:04:39 pm ---So there seems to be an internal difference between the STANDARD 57600 baud decoding and the USERDEFINED 57600 baud decoding in the DS2072. So I tuned down the userdefined baudrate to approx. 56200 baud and at this baudrate the decoding showed exactely the same incorrect decoding like the STANDARD 57600 baudrate mode.
--- End quote ---
Did you find what the higher limit of the UserDefined Baud rate also failed? 59,000?
To see what the tolerance band is.
Does it look like the program is sampling at 56,000 hz and not 57,600hz?
AS 14,400, 28,800, 57,600.... are called 14K 28K and 56K Baud
--- End quote ---
Hello Teneyes and all the other folks :-+
Thanks for the reply!
So it seems like Teneyes assumed: The "standard" serial decoding on the DS2000 series apparently has some issue with the baudrate decoding timing: Selecting 56700 baud in "standard" mode uses 56000 baud to decode and NOT 57600!! But if you select the user defined baudrate and set this one to 57600 it works perfect! Tuning down in user defined baudrate to 56000 baud the decoding shows exactly the same problems like in standard 57600 mode. Maybe the DSO uses also 14000 (instead of 14400), 28000 (instead of 28800) in standard decoding mode - I dont know and have not tested that baudrates yet.
I´m using the latest FW 00.01.01.00.02!
So it´s not a big deal if you know what´s going on because you always can use the user defined baudrate - BUT SEEMS TO BE A FW BUG!
Take care and have fun with the DS2xxx´s anyway.
Markus
marmad:
--- Quote from: GermanMarkus on July 14, 2013, 11:52:24 am ---Maybe the DSO uses also 14000 (instead of 14400), 28000 (instead of 28800) in standard decoding mode - I dont know and have not tested that baudrates jet.
I´m using the latest FW 00.01.01.00.02!
So it´s not a big deal if you know what´s going on because you always can use the user defined baudrate - BUT SEEMS TO BE A FW BUG!
--- End quote ---
Thanks, Markus. If you could figure out the full parameters of the bug (e.g. by testing the other rates so that we know the extent), we can add it to the FW bug list - and report it to Rigol.
tinhead:
--- Quote from: Teneyes on July 13, 2013, 07:49:59 pm ---FFT
--- End quote ---
wondering a bit about that picture, FFT center is 3kHz (so full span 6kHz) but FFT sample rate 10kSa/s ? That didn't make any sense. Or is that zoomed in and moved to left side?
GermanMarkus:
--- Quote from: marmad on July 14, 2013, 12:13:45 pm ---
--- Quote from: GermanMarkus on July 14, 2013, 11:52:24 am ---Maybe the DSO uses also 14000 (instead of 14400), 28000 (instead of 28800) in standard decoding mode - I dont know and have not tested that baudrates jet.
I´m using the latest FW 00.01.01.00.02!
So it´s not a big deal if you know what´s going on because you always can use the user defined baudrate - BUT SEEMS TO BE A FW BUG!
--- End quote ---
Thanks, Markus. If you could figure out the full parameters of the bug (e.g. by testing the other rates so that we know the extent), we can add it to the FW bug list - and report it to Rigol.
--- End quote ---
Hi Marmad,
you and the others guys do pretty great stuff here - keep on with your work and thanks a lot!
So I´m trying to contribute a little bit too and was doing some more investigations with an independant serial transmitter (in this case I just was using an ordinary PC for generating quite long serial strings with approx. 100 characters each).
The result is that all of the standard decoding baudrates (2400, 4800, 9600, 19200, 38400 and 115200) work perfect! The only one who decodes with the wrong baudrate timing is the 57600 one. This decodes with 56000 baud!
So this is definitely a FW bug (I´m using the latest FW 00.01.01.00.02) and it would be great if you can put this issue on your FW update list - Thanks!
Anyway - as described before - the workaround for this kind of minor bug is quite easy: If you want to decode a 57600 baud serial string, just use the user defined baudrate and set this one to 57600 and everything is decoded fine!
Have fun in life and with the DS2xxx!
Markus
GermanMarkus:
--- Quote from: Teneyes on July 14, 2013, 07:42:52 pm ---
--- Quote from: GermanMarkus on July 14, 2013, 02:00:32 pm ---[]The only one who decodes with the wrong baudrate timing is the 57600 one. This decodes with 56000 baud! [/b][/color]
the workaround for this kind of minor bug is quite easy: If you want to decode a 57600 baud serial string, just use the user defined baudrate and set this one to 57600 and everything is decoded fine!
--- End quote ---
Hi Markus
SET THE RS232 TRIGGERING
--- End quote ---
Hi Teneyes,
I think the triggering has nothing to do with the timing of the serial decoding, so when triggering on the rising edge and in single mode it will trigger as soon as there will be the first communication character. I was triggering on all the other tested baudrates the same way and only in 57600 baud decoding the timing for the decoding is wrong. I think the timing for the decoding is completey independent of the triggering - am I wrong?
As you can see in my pictures the first character was decoded correct and then the decoding was wrong, that means the timing for the decoding was running wrong...
So I still assume this is a firmware bug...
Greez, Markus
EDIT: So, for being absolutely sure I was doing my tests again, this time with RS232 triggering but the result is the same: WRONG decoding in 57600 baud mode - all other baudrates work fine in decoding! So, it´s not a big thing, but it´s a BUG;-)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version