Is it possible to generate signal consisting of a sequence of sinusoidal bursts at different frequencies with a signal generator?

Question

I need to generate a signal that looks like this: at first a sine wave of frequency \$f_{in} \approx 1 MHz\$ that goes on for \$N\$ cycles (\$N\$ could be in the range 1-10), then staying at 0 V for a certain time \$T\$ of the order of tens of microseconds; then, another sine wave of frequency \$f_{in}+\Delta f\$ going on for N cycles, then again 0 V for a time T, and so on, until I reach frequency \$f_{end} \approx 2 MHz\$. The frequency step \$\Delta f\$ should be around \$10-100 kHz\$.

Ideally I'd like to do this using my 33220A AWG from Agilent. I've tried with uploading my own waveform generated with Matlab onto the instrument but the results aren't great, especially because the number of points is fairly limited and the signal ends up being very coarse.

Any idea of a better way to do this?

Answer 1

The problem is that your memory in your arbitrary waveform generator is too small to store the waveform. Also, they chose a strange format for arbitrary waveforms. Seems to me they had pretty specific waveforms in mind when they designed how waveforms are stored!

So, as Neil very correctly points out your problem is universally solved when you get a DAC and attach it to something that feeds it with digital samples: you can truly generate any arbitrary waveform (given that it is low in bandwidth enough to fit through the reconstruction filter at the output of the DAC).

The good news is that you don't need an FPGA board (and learn how to use the tools and languages to design a digital implementation of how to get the samples to the DAC for an FPGA), because your bandwidth is pretty low: You end at approximately 2 MHz, and if we wanted to produce any waveform that has energy between 0 and 2 MHz, the Nyquist-Shannon Sampling theorem tells us that any sampling rate > 4 MHz suffices to fully represent the signal.

Due to how hard it is to filter in analog, you would want to higher than the critical 4 MHz, to at least 5 MHz sampling rate.

If you can then feed samples directly from a PC into the DAC at that rate, you'd be fine!

So, you'd need roughly this:

                      +----Device----------+         +------------+
 +--------+           |                    |         |  Low-Pass  |
 |software|           | +--------+ +-----+ |         |   Filter   |
 |running |---------->|-| Buffer |-| DAC |-|-------->|            |------> Analog out
 | on PC  |           | +--------+ +-----+ |         |  (recon-   |
 +--------+           |                    |         | struction) |
                      +--------------------+         +------------+
             USB or
            similar      Buffer because              Reconstruction
              bus      computer will deliver             Filter:
                        data in packets, so          DAC      produces
                       need to make sure DAC         "images" (copies)
                       doesn't rum "dry" on          of  signal  spec-
                            samples.                 trum at multiples
                                                     of sampling rate.
                                                     You only want the
                                                     O Hz–2 MHz image,
                                                     not the  F_sample
                                                     to F_sample+2 MHz
                                                     copy.  Hence, you
                                                     filter out every-
                                                     thing above 2 MHz

OK, I trust you can throw together a 2 MHz low-pass filter (using an opamp, one to three resistors and a capacitor), but you wouldn't want to build Device from this figure.

Luckily, you don't have to; such things are commercially available. They exist in the shape of Software-Defined Radios (like, say, an Ettus N210 with a LFTX daughterboard), or, even simpler: USB VGA adapters!

VGA is an analog signal, high bandwidth, and for each of the red, green and blue signals, amplitude of the signal on the cable pretty much the brightness of the color on the screen, when you scan the screen in a zigzag pattern. Now, every PC has its pixels in digital form, so there's a DAC in your good olde graphics card that takes a stream of digital brightness values and converts them into a continuous stream of analog brightness signal. Most USB cards won't let you just stream pixels as to be directly played back via the DAC – instead you write the pixels to a Buffer, and then there's logic that reads the buffer, adds blanking samples to the end of each row and at the end of each frame (because VGA monitors had to reposition a beam at that point).

But: there's at least one class of very cheap USB-to-VGA "adapters" that puts the whole task of precomputing these values on the CPU of the host computer and just let that stream continuously samples as to be directly converted to analog by the hardware.

^{"FL2000 based devices" by steve-m, on the osmocom wiki, CC-by-SA 3.0}

The osmocom osmo-fl2k project has written a driver for that so you can directly just send samples of your desired waveform to the frontend!

It's relatively easy to use. You'll need cmake and a C compiler (GCC, clang) and libusb (which exists for everything from Linux to Windows and Mac).

git clone https://osmocom.org/projects/osmo-fl2k/wiki/Osmo-fl2k osmo-fl2k
cd osmo-fl2k
cmake -S . -B build -DCMAKE_INSTALL_PREFIX=$HOME/prefix
cmake --build build

That installs the fl2k_file tool. It's easy to use:

build/src/fl2k_file -s 8e6 signal.samples

to play back the samples in the file signal.samples at 8 MS/s. (If I remember correct, the samples are simply signed 8-bit integers, so trivial to produce using numpy or your favourite programming language)

Answer 2

Such a thing is trivial if you have the right hardware. The question is, does anybody supply it ready-built, or do you need to build it?

What you need is an FPGA, driving a DAC.

That's such a common core component of modern complicated modulation transmit systems, that I would suspect many manufacturers of FPGAs or DACs already supply evaluation boards with those components on. Now all you have to do is drop in some DDS IP (Direct Digital Synthesis)(so ubiquitous it will be free from the major FPGA players), and some timing logic to control it.

As an alternative, buy a DDS evaluation board (cheaper, and no FPGA learning curve), and program it on the fly to different frequencies with a suitable MCU. Cheap DDS chips probably aren't able to mute their output, but more capable ones should let you control the output amplitude as well as the frequency.

Answer 3

I'm somewhat certain, that you can "generate a waveform" on your PC and download it to the device to "replay" it.

This is what ARBs usually do.

33220A AWG Datasheet states:

"Use the 33220A to generate complex custom waveforms. With 14-bit resolution, and a sampling rate of 50 MSa/s, the 33220A gives you the flexibility to create the waveforms you need. It also lets you store up to four waveforms in nonvolatile memory. The Keysight IntuiLink arbitrary wave­form software allows you to easily cre­ate, edit, and download complex wave­forms using the waveform editor."

Waveform-Builder PRO Datasheet states:

The software supports USB, LAN, and GPIB interfaces. The software can open and save files in various formats such as IntuiLink (.wvf), CSV (.csv), Binary (.bin), Text (.txt), ASCII (.arb), Binary (.barb), Sequence (.seq), Dual-channel Sequence (.dseq), and more. The BenchLink Waveform Builder Pro Software is a powerful and versatile tool that enhances the capabilities of Keysight signal generation instruments and oscilloscopes. It helps engineers create custom waveforms faster and gain deeper insights into their signals.

Regarding your problems:

With 50MSamples/s youll have trouble "encoding a nice looking" 2MHz sinus. Gives you 25Points/Full cycle or ~15° resolution.

Youll either need a faster ARB or come up with some other sort of configureable Sinus-generator.

Edit:

Maybe youll get lucky and you can find a Pyhton/Matlab/C#/Whatever library to controll the device via USB.

Per Datasheet, a frequency change takes only 1.5ms ... Surely not the desired us and not a "set to zero V"... Maybe youll have to scale your requirements as well.

Answer 4

If you asked me, I’d get a better ARB with faster sampling and more memory, and with Ethernet interface. It may already support fast enough frequency switching that you won’t need the AWG function per se, just quick frequency changes driven from a Python script (for example).