Products > Test Equipment

Arbitrary Waveform Generator with fast edges in ARB mode

<< < (4/7) > >>

nctnico:

--- Quote from: _pat_ on January 19, 2023, 05:39:09 pm ---At some point I should have a closer look at the internal architecture of the Keysight 33500B series, they've done something quite trick to keep the jitter waaaaay down, and I just can't see how you can get there with a fixed sample rate DDS type system....

--- End quote ---
Be sure to look at the Tektronix AFG31000 series as well. The bigger screen certainly makes it easier to deal with creating waveforms inside the instrument itself. I wanted to put the AFG31000 head to head with a similar Keysight generator but the local Keysight dealer didn't had a demo unit available for me. I ended up with the Tektronix AFG31022

_pat_:
2N3055,

Try before you buy is always a better option when available, but it requires an 8 hour round trip by car to do so. That being said I have been able to make arrangements to try to get a definitive answer regarding what these can or can't do. Watch this space :)

Joe,

Your description of the setup is indeed accurate. My application case is perhaps a little different insofar as my interest is in verifying that it is doing what it should, rather than ascertaining what it is doing / modifying things / reacting to them to close the loop. Agreed that some sort of data acquisition (such as your FPGA, a logic analyser etc) would be a better fit for your use case, whereas I can get away with a slightly less complex measurement setup.... but right now I'm still lacking a precise waveform source.

nctnico,

Good shout on the AFG31022, looks like a nice piece of kit. I'll have a closer look at its spec / datasheet / manual to see how it compares. I had been looking at the AFG3022C etc but the AFG31000 series looks interesting!

Cheers,

Pat.

joeqsmith:
If then you have an waveform source that is not perfect but you know where the edges are. And if you are able to synchronize with them with your measurement,  is there even a problem?   

_pat_:
Hiya Joe!

Knowledge of the imperfections of a signal can definitely help, but it still makes heavier work of something that would be easier but for an imperfect signal. Let me try to explain by way of example - fuel scheduling :

Let's say that at the current operating point we want an injection end angle of 360 degrees BTDC. Let's also say we're operating without an angle clock so we have to switch between time and angle domains. Let's say, for argument sake that the desired pulse width is 1.00000ms. As the crank wheel spins you measure the inter-tooth (gap) time. Since you know the gap angle you can work out the RPM, the number of degrees per millisecond and also the number of clock ticks per degree. Every now and then you check if you are in a position to schedule the pulse. You do this by finding the appropriate start angle by multiplying the desired pulse time by the number of degrees per millisecond and adding it onto the end angle (since we're talking BTDC numbers here, higher is earlier). If you're currently at a good place to schedule that start event then you try to do that. When you then get to the scheduled angle you turn on, and schedule an off event to happen 1.00000ms later. Again just taking some numbers for example, perhaps you checked at 540BTC, found that you needed to start at 376.21875 BTDC, and that would make you stop at 360 BTDC. You will be dealing with at least two RPM measurements. One at the 540TDC tooth, where you determined it was a sensible to try to schedule. This RPM value will determine the start angle. Then at the 380 BTDC tooth you work out the current RPM, so you can compute how long between NOW and when the crank will get to 376.21875. If the test signal is perfect then the two RPM readings will be the same and everything works out as it should - a pulse started at 376.21875 BTDC and 1.00000ms long will end at 360.000 BTDC. But now imagine that the signal is imperfect - the RPM value used at 540BTDC is now different to the one measured at 380. We can still start at 376.21875 BTDC [and MAYBE we are lucky and have time to re-compute the start angle for the updated RPM, or maybe we don't]. Due to the small angular distance between 380 and 376.21875 degrees BTDC, you can still pretty accurately schedule that, but since RPM is no longer a constant, the end time, whilst still 1.00000ms after 376.21875 BTDC is now no longer at 360.000 BTDC. If you're looking at the trailing edge of the generated pulse, you can't just put errors down to the code or timers, you now have to also capture the entire waveform, so that you can determine where the error came from [what part of the error is down to waveform imperfections?]. Moreover that process may change... if the desired pulse width gets too long then perhaps it needs to start before 540BTDC, and so that is no longer a good time to compute and schedule its start point - which means the reference gap used is not always the same, nor is the tooth closest to the event start. The ground is moving under your feet. [And yes, I know that real engines do vary in RPM between successive teeth - the point here is to prove that the hardware and code is good - that it doesn't ever break due to some weird race condition no one ever dreamt could happen etc... it's also far easier to deliberate break a perfect pattern for testing than it is to repair an imperfect one].

So, yes, if the pattern from the wavegen is deterministically imperfect then you could cope with that one set of imperfections, but if anything changes, then you need to re-evaluate where errors can creep in. And if the aim of the exercise is to prove that it "never" breaks then you *must* expose it to every possibility. You can avoid that headache / chore if the signal itself is "perfect" to start with. It behooves one not to add more variables than are absolutely necessary :)

Cheers,

Pat.

_pat_:
All,

it looks like the lack of fast edges on ARBs is perhaps a whole lot less common than I first thought and may be a peculiarity of the Rigol DG1022Z. It seems that the insistence of making the waveform exactly 8192 samples long is somewhat less common than initially thought. Yes, there are models out there where the manuals suggests that for DDS mode there MUST be 2^N samples, but it also appears to be the case that there are others where other number of samples are acceptable.

The suggestion to look at the AFG31000 series was enlightening. The Rigol DG2052 shares some characteristics - eg both seem to run in DDS mode for "normal" ARB, and both seem to offer a SEQUENCE mode where they run in point-to-point / sample rate mode. The DG1022Z was perhaps an oddball insofar as it offered both modes in its one and only ARB implementation (doesn't have sequence mode). It was also enlightening that I couldn't find any mention of interpolation (other than as part of the build in waveform editor when drawing lines)... and the fact that it purports to have sub-10ns edges available in both Basic ARB and also Advanced (Sequence) modes (even with ARB data).

So on the one hand there are things like SiFi, SiFi II, TrueArb, TrueForm etc to try to clean up the fact that a DDS may repeat a sample many times before moving on to the next entry by way of interpolating between those values (which will of course drop the higher harmonics, which is great if you want something like pure like a sine wave but that may have some feature that can't be synthesided by the standard non-ARB waveform option).

Furthermore it looks like perhaps the point-to-point implementations are based off PLLs rather than trying to synthesis that clock using modulo N.M from (say) a 300MHz clock. The fact that it is possible to get jitter down to the hundred if not single pico second range on some of these units suggests that it "must" be using something like that - you can't generate a 150.000001MHz signal from a 300MHz clock using phase accumulator / overflow type architecture without getting jitter in the nanosecond region due to 3.3ns quanta. If, on the other hand you can genuinely generate pulses at 6.4516128616025ns then of course you can have pico second jitter timing.

What is perhaps also interesting / telling is the fact that the DG1022Z was generating artefacts when in Sample Rate (point-to-point) mode and the Si570 datasheet says you can only swing 3500ppm before it needs to re-configure itself, causing at least a 10ms outage. That would likely preclude the possibility of at least temporal modulation (FM, PM, PSK, FSK etc) so perhaps they just decided that modulation was too hard. I'm only using Si570 as an example here and not suggesting it is in use in any of these units - just that it COULD provide a REALLY good frequency source for point-to-point operation. Coming to think of it I don't recall seeing [maybe didn't look close enough] anything about modulation when in Advanced (sequence) mode in the AFG31000. Can't immediately think of a good reason why you couldn't modulate the sample rate (and modulating the amplitude would be "easy" anyway)... well other than the fact that PLLs need to lock and that can take time to settle... maybe a YIG oscillator is a better option here (and we all know they ain't cheap).

Cheers,

Pat.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod