-
Hello all!
I'm looking for some recommendations for an arbitrary waveform generator which is able to produce fast edges not just on their nominated square or pulse waveforms, but also on ARB waveforms :
I recently took delivery of a Rigol DG1022Z - based on its spec and manual it looked like it would do the job, but sadly it doesn't look like it will :
When operating in ARB mode, you have the choice of Sample Rate mode and Frequency mode. The manual is not best clear, but to any potential buyers beware : the deep sample memory (anything over 8k) is ONLY possible in Sample Rate mode, and whilst in that mode modulation does not work, moreover trying to manually sweep the frequency causes horrendous waveform artefacts (unusable). As an added "bonus" (show stopper for me) it also tries to interpolate between samples in the ARB data, which crucifies the slew rate when you actually want to generate fast edges (it's impossible).
If you elect to use the Frequency mode, then beware, the ARB data *MUST* be 8192 samples long, there are no other options, it's 8192 or not at all. The manual suggests 8 to 8192 - but that doesn't appear to be the case, indeed Rigol's own waveform editor software greys out the #samples when you choose Frequency mode for the DG1022Z. On the plus side, when you're in Frequency mode the unit does not apply interpolation to the sample data so you can get nice fast edges, but woe betides the user that needs a signal that can't be subdivided into 8192 pieces. The second plus is that modulation does work, and even when manually changing the frequency it does it without artefacts (it is quite usable)..... if only it could do it with fewer samples!
My use case pertains engine signal simulation, ergo it needs to somehow divide into 360 degrees.... ie 360 samples would be fine (one per degree), as would 3600 (one per 1/10th of a degree), 7200 (1 per 1/20th degree or 1 per 1/10th degree per complete cycle). There's no "clean" way to fit this into 8192 samples and still be able to get to integer degrees.... ie you can't place an edge at 10 degrees, it's got to be 9.975585938 or 10.01953125 degrees (and you'll get jitter as you try to round).
Looking at other manuals for units such as the 2000 series Rigol and also Siglent they're similarly uninformative.
My question, then, is if anyone has used a ARB wavegen for this kind of signal generation and managed to get fast (<15ns) edges out of it whilst also being able to use "random" sample counts ?
Many thanks,
Pat. -
A true arbitrary waveform generator with a variable clock, as opposed to a DDS-based arbitrary function generator, might work better here. See here for a brief description of the two types. Unfortunately I don't have a specific recommendation. I'm guessing that might well exclude all the cheaper B-brands like Rigol, GW-Instek and Siglent. Tektronix and Keysight would probably have something suitable.
However, transition times will still depend on a fast clock and output stage, which usually translates into expensive. You might want to consider if a programmable pulse generator / pattern generator can also do the job. They are generally more designed for fast edges than arbitrary waveform generators. -
Hiya Alm!
My leaning is normally toward good gear and so I had been looking at Agilent/Keysight and Sony/Tektronix. I found stuff on YouTube that *suggests* that maybe a 33512B could do it. Maybe. They certainly showed an example of an ARB waveform with spikes in it, where a DDS based solution was skipping some but theirs wasn't. Price and availability are "awkward". The ultimate irony of this is that I started looking because of a jitter bug in the wavegen of a Keysight scope, LOL.
The link seems to confirm pretty much my understanding of DDS.... that you have a fixed high frequency clock that is used with a fixed point accumulator to advance the address used to index into a memory array. This seems to match up nicely to the "Frequency" mode of the Rigol. The fixed size means that the Accumulator does not need to worry about overlfows... the integer part can just be 13 bits long. If it needed to overflow at (say) 7200 then it would need an additional comparator to see if it should subtract 7200.0000000 from the current value. It also makes sense that modulation is easy to achieve here since you're just changing the phase adder. It also makes sense that it steps since it doesn't necessarily "know" how many additions it will take for the integer part to increment, ergo it "cannot" interpolate. [yes, of course, there are mitigation measures you could use, but not trivial ones].
When it is running in Sample Rate mode it can be certain that after one sample period it will be at the next sample, and so it can interpolate between them. I guess the certainty of the next sample also makes the overflow comparator easier to sort out.... say with a sequence of 7200 samples and a 200M base clock, you'd need to advance the sample index every 27778 clock cycles for 1Hz (with an occasional 27777 to maintain a 27777.77777 average, so you may end up with 5ns jitter)... you'd have 27777 cycles to work out whether when you get to the end of that lot you need to overflow or not, as opposed to working that out *and correcting for it* 200 million times per second. It also makes a little more sense why modulation doesn't work properly - in the above example, if you were at 27770 and you sped up then perhaps you'd want to step at 27765 but you're already past that. The same issue doesn't affect the phase accumulator method.
I had actually been thinking that maybe the only way to do this right is to roll my own (hopefully not)....maybe based off Si570 or something like that clocking a Spartan6 or something like that. Fingers crossed that there are units out there that do what I need, without requiring a mortgage or shipping from Proxima Centauri...
In terms of pattern generator I guess I could try to get one into my 16902A (but then I seem to recall that they may not be compatible with stuff later than the 16700 series). I do have other options for generating digital signals with fast edges, but I was after a wavegen so that I can run it with fast edges when I need to check timing with utmost precision, but then go over to a simulated VR signal as well.... and I can't do that with a digital pattern generator
Cheers,
Pat.
-
...
My use case pertains engine signal simulation, ergo it needs to somehow divide into 360 degrees.... ie 360 samples would be fine (one per degree), as would 3600
...
Welcome to the forum Pat.
I also had a use for such an Arb. You could look at D-Space, ADI or other companies specializing in HIL. NI has something but I've never looked into it. Not sure with all the drama at NI, I would even waste any time looking. Still, you never know.
https://www.dspace.com/en/inc/home.cfm
In my case, I designed my own PCI card which is all digital. I suspect you could purchase something much nicer than mine from the big players.
-
Looks like ADI may be gone but doing a search on Google:
https://www.genuen.com/blog/what-is-hardware-in-the-loop-hil-testing
https://www.opal-rt.com/automotive-overview/
https://www.dspace.com/en/inc/home/applicationfields/foo/hil-testing.cfm
https://www.ni.com/en-us/innovations/case-studies/19/reconfigurable-hil-simulator-for-vehicle-dynamics-based-ecu-development.html -
Hiya Joe!
Thanks for the links for the HIL stuff
It seems to me that the requirement for fast ARB edges is pehaps a bit of a niche thing when it comes to wavegens, hence it's not as common as one might otherwise expect.
Still trawling the interwebs and stumbled upon a possibly useful Rigol application note :
https://beyondmeasure.rigoltech.com/acton/attachment/1579/f-08f4/1/-/-/-/-/16Bit%20and%20SiFi%20II%20Application%20Note.pdf
Also datasheet here :
https://beyondmeasure.rigoltech.com/acton/attachment/1579/f-77ca02ba-d59d-43be-8be5-fab20b27f26d/1/-/-/-/-/DG2000%20Datasheet.pdf
The app note looks to detail their SiFi II stuff. The user manual is not best clear on the SiFi II settings at all. It even seems to suggest that the filter setting is only in the advanced /sequence section. But the above application note seems to try to explain what it actually means (and it is counter-intuitive). The Datasheet suggests that the rise/fall time is > 8ns in Interpolation mode, 1/Fs in Smooth mode and 3/Fs in Step mode. The application note then goes on to suggest that in Interpolation mode you can choose the edge time to be between 8 and 90ns. Now I would have thought that "Step" mode would be going from one sample value to the next sample value as quickly as you can, and Interpolation might be taking your time about it but that's not how they see it.
The data is still not entirely clear. It's not obvious if it will allow arbitrary lengths of samples, or only 8192 or some other binary power. Then higher up the datasheet it says that ARB frequencies are from 1uHz to 15MHz but then in the timing part it says 10 Sa/s to 60 MSa/s when in "Interpolation" mode. Now given a minimum sampling speed of 10Sa/s and a maximum ARB length of 16Mpoints, I suppose that would come out somewhere near 1uHz - but you couldn't do it with 8 samples! To get to the stated max of 15MHz you'd need to have 4 samples. But the 60MSa/s doesn't appear to be model dependant, so it's not clear how the higher bandwidth models get to 20MHz. And all the while the ARB SiFi II details are under ARB *SEQUENCE*. Again, clear as mud.
It's at least showing some signs of promise, but whoever is writing these docs / specs / manuals is either doing the unit a huge disservice by obfuscating its true capability, or being delierately vague (as in the case of the DG1022Z) to obfuscate a limitation.
The Keysight info highlighted on YouTube is detailed a little more in their own literature on the 33500 and 33600 series. They certainly *suggest* that they will do point-to-point on a random (ie not fixed to a power of 2) length and they're capable of very fast edges and insanely low jitter, but they don't state exactly what happens between successive points when running at a slower sampling speed. Hey ho.
Cheers,
Pat. -
I have Siglent SDG6000X that has a choice of output filter interpolation in TrueArb.
When set to 0-Order hold it simply jumps from point to point (to the limit of it's output amplifier).
In that mode it behaves as clocked traditional AWG.
Both SDG1000X and SDG2000X have TrueArb mode but I don't know if output filter can be chosen. I don't have them.
But all of them should replay point to point, and depending on frequencies needed, maybe filter won't be important. -
I would start by defining what you need. Voltage levels, update rate, resolution (time/amp), jitter, channels, skew, .. In my case, they are all digital switching between battery and ground. Nothing goes on in my engines that would require the " fast (<15ns) edges" you mention. (Should mention there are analog sensors that I simulate as well. These are all PWM, which included the audio)
The first Arb I made for automotive was nothing more than some SEEQ EEPROMs, a counter and glue logic. I clocked it from my RF generator. It had transformers to simulate the VR sensors. Crude and as you can imagine, difficult to program. I'm sure I still have it laying in a box if you would like to see it.
Think about adding some details and maybe I and others could offer some suggestions. I used one of these for a while. A bit old in the tooth now. The trigger jitter was poor and I had to work with Tek detail how it worked. It's possible to clock it externally, so you can synchronize it with other equipment. I think it requires a 5X clock. I was running it around 6GHz.
https://www.ebay.com/itm/265846741508?epid=7055832840&hash=item3de5b35a04:g:CBQAAOSwbtBjBTRn&amdata=enc%3AAQAHAAAAwADzx%2B2Lqf4QMcpOpxGNV%2Fs8N9c5VS3JtO9%2Bf3ZSEk50Sz3zLeWR35IlYLPwZu7P7iQYgnmeSt6GY%2BUG1HWQRU%2FDlcd9vuA6Af7OJwUpoLyuF6tP8TuJdamBGKIi1Gd0X4UjrKyIzC2XA7o3OswLqXfR8vNjVuk%2Bn6w64gVxjrrzRqlNvr6UkQX9Oakn0rZnObY1GBn7CZb6nB5zZqt9zn9P7zlUKiSC%2BSnVFKMBMCLEWnRedsUsQ%2FcabxbtzNJoQg%3D%3D%7Ctkp%3ABk9SR-iBpaC5YQ -
2N3055,
Thanks for the recommendation. I spent quite a while trawling the Interwebs last night trying to glean some information, but it has been hard work. One of the documents that was perhaps a little more insightful was the Siglent programming manual, which does detail the interpolation mode employed in TrueArb mode, though that is not available on the SDG2000X series and if memory serves the SDG1000X doesn't allow user waveforms so those wouldn't be suitable even if the interpolation was configurable in TrueArb mode. On the plus side it looks like it is possible in DDS mode to have sample lengths other than powers of 2, though I haven't found any examples out there where someone has done that. I'm in the process of installing the Siglent waveform editor so I can try to create something with that. The Rigol PC software will not allow you to have anything other than 8192 samples for the DG1022Z when in Frequency mode, but it will in Sample Rate mode, which seems to correspond well with what the device does and does not support. I also found another DG1022Z manual that was much more forthright about the fact that in Frequency mode it is definitely always 8192 samples long. It looks like the SDG2000X may be a goer in DDS mode. Of course there will be the edge jitter associated with DDS but that should be limited to 3.3ns given that its DDS mode is clocked at 300MHz. They do employ a 1.2GS/s converter, but that is an oversampled / interpolated signal based off 300MSa/s input (for noise shaping purposes).
With regard to point-to-point, it seems to me like Rigol called that Sample Rate mode in the DG1000Z series, and that looks to interpolate the signal between points. Given a 7200 point waveform and clocked at 7.2kHz (1 Hz repetition) I am seeing a rise time of 133us (compared to the 12ns it does in DDS mode, or what they seem to call Frequency mode). Though this has just made an interesting point. What if it was 7.2 megasamples in length, clocked at 7.2MHz.... then the rise time could fall down to 133ns, which is much better, though of course still 10 times slower than in DDS mode. If only there was an option to turn off the interpolation in Sample Rate mode (and if only modulation worked, and if only manually changing the sample rate didn't create artefacts).
Further digging into the Rigol lineup suggests that the later SiFi II models have got an option to play around with the interpolation in Sample Rate mode. The docs are a little cryptic since they talk about Frequency mode in ARB (which might be DDS but it's not clear) but then they talk about Sample Rate in SEQUENCE mode. It looks like you could have a sequence with just one entry in it, and it looks like it should be possible to select a user waveform for that entry, so that could work. When in SEQUENCE mode you can select the Filter mode. It looks like setting that to "Interpolate" then gives you access to Edge timing, which you can then use to tweak the inter-sample rise/fall time(s).
Joe,
In terms of what I "need"... I need to be able to very precisely generate a simulated crank pattern in order to be able to check the system under test / development. The hardware timers are clocked at 80MHz and so I have a fundamental precision of 12.5ns (but there are caveats and gotchas). In an ideal world it would be great if the unit could do point-to-point without interpolation between successive samples when dealing with fast edges, or to turn on some type of interpolation if simulating something like a VR sensor. To that end, voltage wise I suspect -5 to +5V would be fine. Update rate is interesting because that depends on how that clock is generated (ie an update rate of 144Hz would actually be adequate for two rotations of 36-1 per second, but then it would also be useful to get 145.200000Hz to go up 1 RPM.... and at the higher end it would be useful to go from 14.4000 to 14.4012kHz for 1 RPM step higher up). Temporal resolution is again interesting because it depends on architecture - a 300MHz clocked DDS would have a 3.3ns temporal resolution but if you generated the clock with something like an Si570 then the temporal resolution could be in the attosecond region - think about the period difference between 1.000000000Ghz and 1.000000001Ghz). That's not to say that is necessary, but if you wanted extremely clean square / pulse signals then you can avoid the DDS jitter by clocking a point-to-point system with a very precise clock source such as Si570 (eg for 7200 Sa/s you could set Si570 to 943.71840MHz and then dividing that by 131072 for 7200.000000Hz. I digress). Channels would be at least 2. More would be nice but it's not entirely necessary. Skew should ideally be non-existant but it can be dealt with if it exists.
I know in real engines signals tend to be somewhat slower than the 15ns edge time I'm looking for (though there are some pulsed Hall sensors that give out some rather narrow pulses upon detecting a tooth). If I'm trying to schedule a 1.00000ms pulse which is supposed to coincide with a tooth edge, and the scheduling precision is 12.5ns, then it makes checking that is really what is happening very difficult when the reference edge is taking an eternity (122000ns) to rise. Agreed, in the real world it is not necessary for this level of precision, but in order to prove both hardware and code, it is useful to check that it is doing *precisely* what it is supposed to be doing, and the only way that is possible, is with a sufficiently precise reference waveform.
I know what you mean about the clocked / counted EPROM approach. Did something like that a few decades ago for some other project work unrelated to this current requirement
The Tek AWG is for sure a nice piece of kit, but it is bordering on mortgage territory (at least compared to the Rigol and Siglent units which might just work.... again, I can tolerate 3.3ns of jitter so long as the edges are clean).
Many thanks,
Pat. -
If all edges need to be fast, would running the signal through a Schmitt trigger be an option? Obviously this will result in pulses with a constant amplitude and offset.
-
Sorry you lost me on these 80MHz hardware timers.
-
IMHO a pattern generator fits the requirements much better compared to an AWG. And a pattern generator typically also has better software features to create pulse patterns. Maybe the Analog discovery 2 is an option. This has a 100Ms/s digital pattern generator.
-
alm,
A Schmitt trigger would indeed change the edges into very fast types, but it suffers from the same fundamental issue that I already have : when the slope is slow, then you are at the mercy of noise, which itself will introduce jitter into the produced signal. Let's say you have a 2.5V threshold, but there are a few mV of noise on the signal, then any timing issues in the system under test may be drowned in the noise generated by the slowly rising voltage plus voltage noise compared to the the threshold. When the edge is fast, this is less of an issue. To take an example, if you had 1V pk/pk of noise on a 5V pk/pk signal (trying to be really cruel here) but a 12ns rise time, the voltage noise would correspond to 1/5 of 12ns, or 2.4ns. But if the edge was 122us then the timing jitter introduced by the same voltage noise would be 1/5 of 122us or 24400ns. If you want to check the timing of a generated edge against a reference edge to a precision of 12.5ns, then you don't need the reference drowning in thousands of nanoseconds of noise induced timing jitter. Hope that explains why I prefer to use a fast edge from a precise source.
Joe,
The 80MHz timers are in the system under test / development, rather than the Wavegen. If I want to check that an edge generated by the system under test is precisely 1.00000ms after a reference edge, then the jitter on that reference edge needs to be small. There can (and will) be differences between the trigger points in the DSO threshold cct and the system's own comparators. The smallest error that could occur is 1 clock cycle (12.5ns, and of course if is is not out at all, then it isn't an error... ie you can't really have an "error" of 0), of course larger errors are also possible (multiples of clock cycles). Hope this makes sense. Additionally, how do you reliably trigger the scope when you have a reference edge with a reference rise time of 122us but a signal rise time in the tens of nanoseconds.... your reference waveform, once zoomed in so you can accurately measure the generated waveform, will be to all intents and purposes, flat rather than a defined edge.
nctnico,
You're most definitely right that a pattern generator would suit this one very specific task much better than an AWG. That being said, it should clearly be possible to generate a sensible pattern with an AWG, and that will likely be subject to the same jitter that the Analog Discovery board would have, BUT that jitter would still be very much smaller than that from the interpolated slope of the DG1022Z.
I've had a chance to have a look at the Siglent software as well now, and it does also allow random-length waveforms to be created for the SDG2000Z series (though it does have some fixed-length options too).
I am cautiously optimistic at this point that either the Rigol DG2052 or the Siglent SDG2042Z will indeed be capable of generating fast (DDS-esque) edges rather than interpolated (point-to-point-esque) edges. I should soon have units to try and would be happy to report whether or not they can do this.
The advantage, if it is possible (and there's no good reason it *cannot* be, it's only a question of time and effort on the part of the engineers in the test equipment companies), is that the AWG will also be able to simulate more "normal" signals, such as VR sensor outputs, without needing to have a separate piece of equipment.
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....
Cheers,
Pat. -
@_PAT_
If you can borrow units to try out, that is best option.... Shout if you need help.. -
So you are simulating your cam/crank signals to your test device which output some pulses relative to those cam/crank signals. Pretty much what I am doing in these videos with the same card. The FPGA is measuring the fuel injection and ignition times, where they start and end. No scope is used. In my case, I want to use this information to close the loop. All pretty common for HIL testing.
-
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....
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 -
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.
-
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?
-
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. -
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. -
Another option that just came to mind is the AimTTi TGF4000 series: https://www.aimtti.com/product-category/function-generators/aim-tgf4000. I have evaluated / tested this unit. The frequency accuracy isn't that great (*) so it wasn't fit for my purpose but it does have a specific pulse mode. I think this might be exactly what you are looking for.
* When locked to an external 10MHz reference and set the output signal to a frequency of 1Hz, it will be slightly off. Likely not a problem for testing engine ECUs. -
I should be clear that I am using the basic phase accumulator / overflow type. The master clock is lower than you describe (even more error). My Arb keeps track of the angle and because the measurement is all part of that same circuit, it also knows the angle. Time is tracked in separate circuit. All of the triggers are also hardware so the hardware collects everything. It's just one IC.
The interesting thing is the need to remove this error as the signals off the engine are not perfect. You talked about only having a 0.1 degree resolution. I wonder when you are putting the ECM together, I assume you are simulating much of it to know if the timing is correct and are just wanting some way to verify the everything works as expected once you put it all together.
Reread your post...
Nice chatting. Sounds like a fun project. -
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.
You may be overthinking this. All of the units discussed (Siglent, Rigol, Keysight 335xx, Tektronix AFG31000) run their DACs with fixed sample clocks. Low jitter is only achieved in "TrueArb", "Trueform", "Advanced" etc. modes, which are really just fancy words for resampling, involving polyphase interpolation/decimation filters.
If the interpolation filter is linear or sinc-type, then rise/fall-times will scale with sample rate and will be slow when the interpolation factor is high. However, as mentioned by 2N3055 it is quite possible to generate fast "stair-case" type signals with very low jitter this way if 0th-order hold interpolation is used instead. Specifically, the Keysight generators as well as the Siglent 6000X support this (the 2000X does not!).
The biggest disadvantage with this approach is that changing the sample rate involves changing the filter coefficients (and potentially the filter topology, these are really multi-stage filters in practice). So it is not really possible to implement sweep and FM modes in a straightforward way. You can string together waveforms with different parameters in sequence/list mode (if supported) but you cannot vary sample rate continuously.
If you need that and DDS mode (which can be FM modulated easily) is not adequate, the traditional approach is to use an AWG with deep memory and create the modulated signal offline. Or use a system with a programmable DSP/FPGA and generate the signal in real-time. -
Seems like the best solution is to learn to make/edit better 8192-byte signals so the Rigol is happy.
-
nctnico,
Good shout on the TTi unit. Looking at its datasheet it appears to be DDS only with a reasonably fast clock speed, though it may be limited to 16kpoints (been reading so many now it's becoming a bit of a blur, LOL). Its price is somewhere in between the value brands like Rigol / Siglent and the more established like Keysight / Tektronix.
Joe,
Sounds like an interesting setup you have there too If it's of interest you might want to have a look at how Motorola (back in the day) implemented the angle clock in the (e)TPU in devices such as the MPC555 / MPC5554. An interesting approach that avoids the need for division to get from time ticks to angle ticks
switchabl,
I have a propensity for throwing Occam's Razor out the window, LOL - so yes perhaps I am over thinking it. Though I also think we might be slightly cross threads here, so for the avoidance of doubt, I was referring to edge jitter on *square* edges, not zero-crossing jitter on sinusoids. I would be interested to know the source of your claim that even units such as the 335xx runs its DAC(s) at fixed sample clocks - because Keysight claim that with Trueform they can get edge jitter down to 1ps. I don't see how that is in any way possible for *square* edges unless you are clocking your DAC at 1THz (which they don't claim).
With regard to the TrueArb etc technologies, I have already acknowledged that there is some form of interpolation / oversampling etc but none of that mitigates the fact that a 250MHz has time quanta of 4ns, you cannot place an edge with any greater temporal resolution - which leads us on to polyphasic clocking. Even with a base clock of 1GHz, in order to be able to place edges with 1ps precision, you would need to have have at least 500 phases (assuming you can invert them all, which would then generate 1000 polyphase clock sources, allowing you to sub-divide the 1ns period into 1ps subdivisions). I'm not aware of any FPGAs that would support that many phases, moreover, normal polyphase setups may derive these phases from a faster PLL (decimation with phase shifted overflows)... so you'd need to have a master PLL running at 1THz for that (probably not happening), *OR* you'd need to have MANY PLLs (which are each then running much slower, but which you could likely enforce some sort of phase offset on). All of this to say that yes, agreed, polyphasic clocking will get you further than you could normally. Maybe you can have 8 phases, and maybe you can invert them to give you 16 phases in total, which might give you 62.5ps resolution with a DAC nominally running at 1GS/s. None of this touches on the fact that you're now dealing with essentially different clock domains, and crossing clock domains is never trivial... so then you need to pipeline it... work out the value *and* the phase of the sample after the next sample - that way at the point of modifying the phase, you're only having to worry about crossing skewed-phase clock domains at the very last point before the clock waveform and the data exits the FPGA. You also need to pay careful attention to delta-phase between successive sample so you don't end up with a timing violation (ie if you decided to advance 180 degrees in a single cycle then you have effectively doubled the frequency during that change, and that may be past the silicon's limit). Hope you can see why I was leaning toward them using a different approach which can generate a precise frequency to clock the point-to-point (or square / pulse wave) samples. Building a PLL with 1Hz resolution is considerably easier than dealing with THz signals.
Agreed on the difference between the Siglent 2000X / 6000X support for 0th-order. I think I did spot something like that in the Keysight info as well. Rigol SiFi 2 looks to have something similar (when you set the "Filter" to "Interpolate", which seem a misnomer but kind of makes sense given that you can then configure the edge slope ["interpolation"] whereas "Step" and "Smooth" look like it is akin to Sinc).
I did spend a little while checking if / what sort of FPGA are in use in these wavegens. In Dave's teardown of the SDG2000X series he suggested an Altera part, and I seem to recall mention of a Spartan in the DG800/900 series Rigols. All this to say that if it's FPGA based then functionality could be expanded /altered in the future, FPGA resources allowing.
Fungus,
As already alluded to in my reply to switchabl, I am referring to square edges (at 10 degrees in a 720 degree frame). Given that 720 and 8192 do not divide nicely, there is literally nothing that you can do to improve the data itself. The two workable solutions that do exist are a) allow sample lengths other than 8192 in DDS mode, or have an option to disable the inter-sample interpolation when running in Sample Rate mode. You are of course right that with "analogue" waveforms you can play around with the data to improve its fidelity. But to place an edge at a notional 10 degrees into a 720 frame, that edge would have to occur at sample 113.77777777 - so you are left with a choice of putting it at sample 113 or sample 114, so you end up with an error no matter what you do - you're introducing jitter as a result. Hope this makes sense.
Cheers,
Pat.