I am in need of a basic arb gen with somewhere about 50MHz of bandwidth. I really like the deep memory of the DG1000Z and the cost.
My first question is anyone have anything good or bad to say about this instrument?
How is the Rigol software? any good or will I have to write my own?
Well, this forum does actually have a search function you could have used, which would have lead you to a review I wrote not too long ago:
https://www.eevblog.com/forum/testgear/rigol-dg1062z-arbitrary-waveform-generator-short-review/msg512306/#msg512306 (https://www.eevblog.com/forum/testgear/rigol-dg1062z-arbitrary-waveform-generator-short-review/msg512306/#msg512306)
I have heard varying things about the Rigol software and it seems like I my have to write my own to fix some of my needs.
I and my your as well would love to see the insides of this instrument. Is the bandwidth controlled by software? and can this be changed?
It's been a while since I wrote that review, and after some serious use my opinion that the software is really bad has only been reinforced. Why manufacturers like Rigol believe they can get away with such piss-poor programs is beyond me. Unfortunately at the moment I don't have much time to write my own, which is why I'm considering splashing out the money for a Tek AWG which works with ArbExpress.
My guess would be that the 30 MHz version is limited by software and that the hardware is the same, but that's just a guess.I am interested to try to hack it for bandwidth of the 30 MHz and the memory. I am not sure why the 60 MHz would have more bandwidth, as it is 60 MHz is close to the Nyquist sampling limit of 100 MHz for the 200MSPS. This is not even counting the need for oversampling to lower distortion and improve effective resolution.
I doubt that the 60MHz version can be hacked for a higher bandwidth, though.
What would be interesting however would be a hack to enable the full 16M of sample memory.
QuoteIt's been a while since I wrote that review, and after some serious use my opinion that the software is really bad has only been reinforced. Why manufacturers like Rigol believe they can get away with such piss-poor programs is beyond me. Unfortunately at the moment I don't have much time to write my own, which is why I'm considering splashing out the money for a Tek AWG which works with ArbExpress.
So when I get mine I will be sure to write something and post it for the world to use. I am at Python and C/C++ guy, what you think of using Qt for the application? and only doing connection over Ethernet to save the complexity of USB and drivers. What function do you think is needed in a software package for a arb gen?
QuoteMy guess would be that the 30 MHz version is limited by software and that the hardware is the same, but that's just a guess.I am interested to try to hack it for bandwidth of the 30 MHz and the memory. I am not sure why the 60 MHz would have more bandwidth, as it is 60 MHz is close to the Nyquist sampling limit of 100 MHz for the 200MSPS. This is not even counting the need for oversampling to lower distortion and improve effective resolution.
I doubt that the 60MHz version can be hacked for a higher bandwidth, though.
What would be interesting however would be a hack to enable the full 16M of sample memory.
I am surprised that I have not found anything on software hacks for the Rigol DG1000 and DG1000Z.
So when I get mine I will be sure to write something and post it for the world to use. I am at Python and C/C++ guy, what you think of using Qt for the application? and only doing connection over Ethernet to save the complexity of USB and drivers.
What function do you think is needed in a software package for a arb gen?
I am surprised that I have not found anything on software hacks for the Rigol DG1000 and DG1000Z.
If you really need a lot of sample memory, take a look at the Hantek HDG2000 series. There is an effort right now to build an open source replacement firmware for it that will hopefully be easier to use, less buggy, and more powerful than the default hantek firmware. Additionally, it will hopefully be able to support 128 M points on one channel at 250 M samples per second. (the unit supports 64 M per channel out of the box, but there is no reason why that could not be divided unevenly if the FPGA configuration is built correctly - there is more than enough memory bandwidth).
Oh, and just to be sure: no Java!No problem, I don't think any one has to tell me that, lol. I am a fan of Qt as it is cross platform and covers up some of the shortcomings of C++ for user interface stuff.
Shame I really like the large memory of it. I am working on a real time control system with some real hard timing requirements, so I was planning building a hardware in the loop test bench, and the large memory makes that possible.QuoteI am surprised that I have not found anything on software hacks for the Rigol DG1000 and DG1000Z.I guess that the DG1000z doesn't sell that well. It's pretty expensive compared to the older DG1000 or the Siglent kit. And with a price close to the DG4000 most people are probably opting for higher bandwidth over the larger sample memory of the DG1000z.
If you like Python, then take a look at Python IVI. It's open source and cross platform and it supports communicating with instruments over GPIB (linux-gpib/NI visa via pyvisa), LXI (VXI-11), USB (USBTMC), and serial. The idea is to provide common APIs for different instruments so they can be interchangeable. It's more intended for writing scripts, but it could certainly be leveraged as the back end for an application.I have seen that, I have had some trouble with it in the past for projects at work. I will definitely keep it in mind, I believe in the practical solution to problems and if seems reasonable then I will go for it.
I have a dg1022.guess it is that bad, I am not really a LABview kind of guy for a couple reasons. I have even used NI-CVI for work and I am not a fan. I have no problem writing even the "visa" from scratch.
While the supplied software is terrible,
You can make some really nice software interfaces with the LABview VI's that rigol supplies.
Have a look at Tektronix ArbExpress which is their free utility for their own AWGs, which is the best one I've seen so far and very useable. If your program was a clone of ArbExpress then I'd gladly pay some money for it.I will be sure and take a look at the Tek software. I have written some software for work to control different VNA's of differing models and manufactures and I never could quite figure out a good way to make it definable using something like XML files or JSON files. There are always little differences that I have found in the way the instruments behave or perform that make it that much harder than just having a dll for each instrument.
Ideally the program would also be flexible to be adapted to other AWGs, i.e. by storing the device-specific configuration in XML files so that other AWGs can be added in the future.
If you really need a lot of sample memory, take a look at the Hantek HDG2000 series. There is an effort right now to build an open source replacement firmware for it that will hopefully be easier to use, less buggy, and more powerful than the default hantek firmware. Additionally, it will hopefully be able to support 128 M points on one channel at 250 M samples per second. (the unit supports 64 M per channel out of the box, but there is no reason why that could not be divided unevenly if the FPGA configuration is built correctly - there is more than enough memory bandwidth).
This is all great stuff but the potential features are worth nothing if the hardware is crap (it's Hantek after all!) and the software buggy. And I'm not even touching the complex task of writing and maintaining(!) reliable firmware for that thing that is not a pain to use, and this is under the assumption that the project won't be abandoned when the next hackable cheap-ass AWG comes out.
I'm not a Rigol fan but the DG1000z hardware quality is worlds apart from anything I've seen so far carrying the Hantek label.
QuoteHave a look at Tektronix ArbExpress which is their free utility for their own AWGs, which is the best one I've seen so far and very useable. If your program was a clone of ArbExpress then I'd gladly pay some money for it.I will be sure and take a look at the Tek software. I have written some software for work to control different VNA's of differing models and manufactures and I never could quite figure out a good way to make it definable using something like XML files or JSON files. There are always little differences that I have found in the way the instruments behave or perform that make it that much harder than just having a dll for each instrument.
Ideally the program would also be flexible to be adapted to other AWGs, i.e. by storing the device-specific configuration in XML files so that other AWGs can be added in the future.
I am a fun of having some sort of scriptability and programmability in applications, would there be any objects to this part being python? maybe allow for signal manipulation with numpy and scipy? or maybe even the GNURadio libraries for things like filters?
Right now, python-ivi can be used to transfer numpy-generated waveforms to arbitrary waveform generators. Extending that could produce a very powerful (and open) platform. I suppose the only main concern is speed; if you want to do real-time high performance DSP (e.g. software radio), then python is not really the best choice. But if this is just intended for offline processing, then I think leveraging python makes a great deal of sense.I am not sure if real time performance is of any interest here, I wish common waveform generators could do direct digital synthesis of waveform from a data stream from a PC. This is a feature that I have payed top dollar in the past in the form of SDR's. I think python for a different set of reasons is very good for SDR's. Its a very GNURadio and makes its flexibility of it possible. My thinking on using using the GNURadio libraries is for easy filtering and other functions of signal generation and a wide range of extensions for it. VOLK is another big plus, I believe in making the most out of what you have and a cheap gain in math performance is always a win in my mind.
I wish common waveform generators could do direct digital synthesis of waveform from a data stream from a PC.
Now that is a very interesting idea. This could certainly be doable for a low-rate generator channel that could be either output directly or used as a modulation input to a higher rate channel. Maybe this is something to implement in the open source HDG2000 firmware, if we can come up with a good architecture. It looks like the interface between the SoC and the FPGA can run around 30 to 40 Mbit/sec. That's sufficient to stream one channel at 1 or 2 Msa/sec with a 16 bit sample depth, and double that if you decrease the sample depth to 8 bits.Wow I did not know anyone was doing anything with opensource firmware for any test equipment, good to know. I would love this feature! As for the data rate I think there are a number of ways that the data stream could be compressed to make use the the USB 2 or Ethernet speed limits. That would make a great signal generator for a SDR and many other things. One thing that I would ask something like that would having the instrument to shift up in frequency the input frequency.
QuoteNow that is a very interesting idea. This could certainly be doable for a low-rate generator channel that could be either output directly or used as a modulation input to a higher rate channel. Maybe this is something to implement in the open source HDG2000 firmware, if we can come up with a good architecture. It looks like the interface between the SoC and the FPGA can run around 30 to 40 Mbit/sec. That's sufficient to stream one channel at 1 or 2 Msa/sec with a 16 bit sample depth, and double that if you decrease the sample depth to 8 bits.Wow I did not know anyone was doing anything with opensource firmware for any test equipment, good to know. I would love this feature! As for the data rate I think there are a number of ways that the data stream could be compressed to make use the the USB 2 or Ethernet speed limits. That would make a great signal generator for a SDR and many other things. One thing that I would ask something like that would having the instrument to shift up in frequency the input frequency.
I have a couple hours of work on the app(Nothing is the bigger picture) when I have something that I think looks good I will post it to github.
I'm actually working on the FPGA part of the open source firmware. It's just getting started right now, not sure if you are interested in helping out at all: https://www.eevblog.com/forum/testgear/hdg2002b-awg-firmware-reverse-engineering/ (https://www.eevblog.com/forum/testgear/hdg2002b-awg-firmware-reverse-engineering/) .Sounds interesting I will see what I can contribute, I know VHDL not Verilog tho. Should be a good chance to learn. I will have to get my hands on the hardware so that my take some time.
Anyway, the bandwidth limit is imposed by an SPI connection between the SoC and the FPGA inside the arb. It's designed so that the SoC/user interface can be isolated from the front end with digital isolators. They are not installed in the units, but the connection to the FPGA is limited to the single SPI interface. We're trying to work out the maximum rate possible over that interface right now, actually. Also, the FPGA is quite small so it may not be possible to implement much in terms of compression.
SPI? Really that seems kind of slow for this sort of device. That is going to be a bigger bandwidth limit then USB or Ethernet. From the looks of it some modest compression could be done on the Ethernet or USB connections (Maybe something like just the derivative of the signal as this should be value limited to less than 16bits, or maybe FFT compression). I am not sure there is anything can be done on the SPI bus.
Yeah, it is a little annoying. I suppose it was an engineering tradeoff - lower bandwidth to the front end, but support for front end isolation.Hmm yeah that is kind of old, there are parallel bus isolators.
Now, I'm thinking this may be far more useful as a modulating signal than as a baseband signal, and it could also be possible to send raw data bits and then generate symbols on the fly in the FPGA.I am sure I am not the only one that could use I and Q modulation of a signal and PRBS for symbol generation.
Well see how much space is available on the FPGA, it's a Spartan 6 LX 16, so there isn't a whole heck of a lot of space available. I think the main limit will be DSP slices; the chip has 32 of them that will have to be shared across both channels.What is the clock speed of the FPGA? I am not sure that 32 DSP slices is going to be a problem. How much math needs to be done in real time? There is only a slow connection to the DAC, it hinds at that the modulation is done in the SOC and only the modulation signal is generated in the FPGA and transferred over the SPI bus.
Well, a more standard interface would be to emulate an SRAM interface and then stick the FPGA on the SoC memory bus. However, this requires a large number of traces, and isolating this is not very straightforward. So using SPI means that only 4 pins need to be isolated instead of ~32.QuoteYeah, it is a little annoying. I suppose it was an engineering tradeoff - lower bandwidth to the front end, but support for front end isolation.Hmm yeah that is kind of old, there are parallel bus isolators.
QuoteWell see how much space is available on the FPGA, it's a Spartan 6 LX 16, so there isn't a whole heck of a lot of space available. I think the main limit will be DSP slices; the chip has 32 of them that will have to be shared across both channels.What is the clock speed of the FPGA? I am not sure that 32 DSP slices is going to be a problem. How much math needs to be done in real time? There is only a slow connection to the DAC, it hinds at that the modulation is done in the SOC and only the modulation signal is generated in the FPGA and transferred over the SPI bus.
I hope it doesn't sound stupid, but I'm curious if you can create I2C / SPI waveforms with Ultra Station ?
I actually meant more, can a (i.e. DG1000Z series) burst a I2C signal (i.e. a char) to a LCD (via MCP23006) ?
Anyway you can capture the Wave (DSO), send it to your AWG and replay it ?
Version?00.01.08.00.00 Date?2015-6-1
1 Support variable idle level in burst mode. Enhancement 2 Support screen shot with PNG format. Enhancement 3 Support multi-interface in remote mode, and update the LXI library, SCPI library and USB device library. Enhancement 4 Keep the phase deviation between CH1 and CH2 unchanged after re-opening output. Enhancement