Annoying bug in Rigol DG4000 series Function Generator - Page 1
Forum section: electronics / testgear

author: TurboTom
author_rank: Super Contributor
timestamp: April 11, 2016, 12:18:37 am
content: I've got a fairly new Rigol DG4102, S/W 00.01.12, FPGA 00.01.11, H/W 01.03, K/B 06.02. As per Rigol's web site, the firmware is the latest version. I'm designing a microcontroller-based motor control system that's (currently still) using the "standard" radio control signalling as input, i.e. a variable pulse width signal between 1ms and 2ms pulse width to signal 0 to 100% vice versa. Since several different operational states need to be distinguished, pulse width discrimination is rather critical and I thought I got it spot-on in the microcontroller. My microcode translates the pulse width as specified before, additionally it identifies everything below 1ms as 0% and everything above 2ms as 100%.I've got a sequencing included that requires in order to recover from an over-speed situation to reduce the pulse signal to 1ms and then rise it again. Yet, I've never got this working correctly. I used the Rigol generator in pulse mode to provide the control signal which appeared to be working all right so far. Yet, as soon as I changed the pulse width on the generator, I got a reaction as if I reduced the signal to (less than) 1ms and increased it again. I already started questioning my logical abilities (I purposely don't talk of my programming skills...). After including all kinds of debug features in my code, everything pointed to a proble with the input signal.To cut a long story short, the Rigol DS4102 (I cannot tell for the other models since I've only got this one) in pulse mode produces a spike of 4µs duration and approx. half the preset amplitude before the leading edge of the pulse when changing the pulse width. It doesn't matter if the pulse width is changed by the rotary encoder or by digital entry of the new value. Please see the attached photo / o'scope screen shots for details. Can anyone who's got a DG4000 reproduce this? Thank you.Cheers,Thomas

author: TurboTom
author_rank: Super Contributor
timestamp: April 16, 2016, 06:58:41 pm
content: Thanks Peter for verifying this!I'm strugging with one more annoyance with this instrument. Maybe it's basically related to the fairly recent Keyboard version (6.02) in my unit and Rigol having changed something there: The increments aren't always referenced to the detents of the rotary encoder. Somtimes there are two increments between two adjacent detents and sometimes none. There doesn't seem to be a strict logic with this, it seems to be somewhat random. There may be two to five detents work okay and then sudently there's the described problem. It never seems to happen between two djacent detents and it also doesn't seem to be related to a mechanical position of the encoder. I even swapped in a new (quality) encoder (ALPS EC12 series) but the problem persited.Maybe Rigol got the orientation of the two encoder lines wrong, one line appears to change state right at the detents while the other always approx. half-way between them. Electrically changing the lines wouldn't help since this would reverse the direction of the encoder, albeit then probably changing values at the right positions. Swapping the lines and inverting them may work, but I guess it's not my job to do Rigol's work...Anybody else has this observation with his DG4000 ?Thanks and cheers,Thomas

author: Rescator
author_rank: Newbie
timestamp: April 17, 2016, 08:57:32 am
content: Hello,I have the same problem with my DG4062, software version : 00.01.12, FPGA : 00.01.11, Hardware version : 01.03, Keyboard : 06.02The spike appear when adjusting either width, trailing or leading time.Also bad increment values sometimes between adjacent detents.Gerard

author: TurboTom
author_rank: Super Contributor
timestamp: April 17, 2016, 05:50:42 pm
content: Gerard - thanks for verifying this. Actually, meanwhile I'm somewhat disappointed about these problems. And there's more like this:In both sine and ramp mode, when changing the frequency, the transition is continuous. If you chose sqare or pulse mode, the generator pauses the signal for approx. 5.8ms and then resumes at the new frequency! There are many situation where a behaviour like this is completely inacceptable. Why is Rigol selling such a crap? They had more than enough time to sort this via firmware updates! And the DG4000 series of function generators cannot be considered particularly cheap. My junky Hantek generator is performing much better regarding this, though it has enough other shortcomings.Anybody knows if bug reports to Rigol directly are of any use?Cheers,Thomas

author: Ivan7enych
author_rank: Regular Contributor
timestamp: April 18, 2016, 10:44:35 am
content: Quote from: TurboTom on April 17, 2016, 05:50:42 pmWhen they update generator memory it takes some time. Changing sine frequency don't require this, that's why it's instant. But changing frequency of a pulse (without scaling pulse width and rise-fall slopes) requires memory recalculation.

author: Someone
author_rank: Super Contributor
timestamp: April 18, 2016, 11:17:32 am
content: It's "normal" in these modern arbitrary function generators, as above a lot of the adjustments are computed in software and then placed into the playback buffer/memory. It sure caught me out the first time I saw it as the DUT put 10x more current through it than I was expecting as the pulse train stayed steady.

author: TurboTom
author_rank: Super Contributor
timestamp: April 18, 2016, 09:17:55 pm
content: Ivan & Someone -I guess you are right, if Rigol implements the square and pulse modes as arbitrary waveforms, the result is (has to be?) the observed discontinuity in the signals when changing parameters. Yet, I'm surprised that in an FPGA-driven generator like this, there isn't a "direct" square/pulse mode implemented with the fastest possible slopes that won't use any (pre-programmed or calculated) arbitrary functions. This mode could actually be automatically entered if "Zero" slope time is selected. Of course, this would result in a +-1ns slope jitter as a result of the 500MHz DAC clock but I guess for most users this would cause minor worries. An alternative could be a "proportional" square/pulse mode where the slopes scale with the frequency in favor for a continuous signal output. This shouldn't be too difficult to implement. I guess it might even be possible with a user-defined arbitrary waveform (didn't play that much with arbitrary settings so far...).Well, this mode isn't there and i doubt Rigol will ever implement it (or something similar).Thanks,Thomas

author: CustomEngineerer
author_rank: Frequent Contributor
timestamp: April 19, 2016, 01:39:27 am
content: Quote from: TurboTom on April 18, 2016, 09:17:55 pmYou give them too much credit. Software/Firmware isn't exactly Rigol's strong suit.

author: dpersuhn
author_rank: Newbie
timestamp: June 17, 2016, 01:19:20 am
content: Along similar lines in burst mode, has anyone else noticed that the timing of an internally triggered burst is only available in 0.8uS increments, starting at 1.6uS? IF this is the case, shouldn't the period adjustment reflect that instead of allowing you to adjust in 0.1uS increments and just get output to the nearest 0.8uS increment below the set period?New DG4102 running software 00.01.12, fpga 00.01.11, hardware 01.03Easily reproducible: n-cycle delay, single cycle, 0 phase, internally triggered, roll down the period and measure the on your scope to watch as 0.1uS adjustments do nothing until you hit 0.8uS threshold marks. Really annoying... It took me a bit to find this while debugging some microcontroller code that was expecting to pick up bursts that were no closer than 10uS apart (set the FG period to 10uS) and I kept seeing it count at a rate corresponding to 19.2uS periods. Came to find out the actual bursts were happening at 9.6uS and I was missing every other one.