# How to drive an AD9850 at 100 kHz/s sweep using arduino or rasberry pi?

The basic problem I am interested in doing is using an ADXXX chip to make a linear frequency sweep through the HF bands, from 1-20 MHz. The sweep rate I would like to achieve is 100 kHz/s, which granted is an upper end requirement.

The chips I have been considering are the AD5930, AD9850/AD9851, and the AD9910. Ideally, we would drive this using either an arduino, teensy, or a raspberry pi.

My questions are the following:

1. For the AD9850, is it even possible to send bits fast enough to do a 100 kHz/s sweep? What calculations would I need to do to test the feasibility of this? At the very least, this would mean the full transaction of transferring the word and changing the frequency needs to happen in 10 µs.
2. Is running a DDS chip in a linear sweep mode a silly/stupid thing to do? Quite honestly, I have been told it is; I have seen a lot of fixed frequency circuit examples. What are the issues with trying to accomplish this task?

I am looking for ideas on how to direct an undergraduate. We have focused a lot of time on the AD5930 which seems to have the right features, but we have had difficulty trying to communicate with the chip using a teensy and arduino.

• I don't think an RPi is appropriate for this unless you do some hard-real-time kernel mods. Something like the Teensy 4 should handle generating a 100Khz signal, or even an Arduino if it has some hardware features. – Ron Beyer Feb 10 '20 at 16:15
• @RonBeyer you're wrong! This is about changing the frequency over time, so kHz/s is a perfectly sensible unit (and equivalent to ~(s⁻²)) – Marcus Müller Feb 10 '20 at 16:16
• @MarcusMüller Thanks, I interpreted that wrong then, I removed that part of my comment. – Ron Beyer Feb 10 '20 at 16:17
• @TonyStewartSunnyskyguyEE75L linear steps and ideally continuous sweep. At some point, I want to set the sweep to start at GPS PPS, but right now the bigger question is feasibility. We also have a reference board you show. Want to implement not using the reference board, but driven using our own software. – AD0AE Feb 10 '20 at 17:12
• @AD0AE all what you're saying here in the comments should be part of the question! – Marcus Müller Feb 10 '20 at 18:00

linear steps and ideally continuous sweep.

For a continuous sweep, it makes no sense to use a DDS IC: continuous implies you'd update the frequency for every output sample, and then you could just calculate the output sample yourself and generate it using a DAC:

In fact, that'd be totally doable here:

linear frequency … from 1-20 MHz.

"only" requires 38 MHz of sampling rate (40 MHz is probably easier to generate, so go with that).

arduino, teensy, or a raspberry pi

• Arduino is pretty certainly not your platform of choice: Lower-end microcontrollers with an execution environment that's not especially optimized for real-time signal generation tasks
• Raspberry Pi: the modern raspberry Pis have plenty of compute power, but running Raspbian or similar they're really not real-time systems, so that'd make your task harder
• Teensy: there's different versions, and you're picking the outdated Teensy 3.2. That's an uneasy restriction: the MCU runs at 72 MHz, which makes frequent updates harder, but in essence, you can use this to update your DDC chip.

Really, though, using a separate DDC with a microcontroller here just makes everything harder:

• you need a clock source. That should be significantly higher than your maximum frequency – the 120 MHz input that the AD9850 can work with sounds like a good idea, but none of the controllers you propose can work with that, so you suddenly have either multiple independent clocks in your system (which will sooner or later mean jitter, probably pretty instantly), or a complex clocking tree that is way more complex to design than the rest of your system.
• you want a continuous chirp. One can implement that with a DDC, but that requires per-sample updates. Cool if your DDC is part of your controller. Not cool if it's on a separate IC.
• it's an expensive solution.

You can solve this in multiple ways. Either

1. you use the Teensy 3.2 you want, and live with the fact that you can only do stepped-frequency, not cintinous sweep; relatively easy: you program a timer interrupt service routine that triggers the frequency update.
2. you use a modern Teensy (Teensy 4.0) that is way faster, and can make your steps so short that it nearly looks as if you're continuous. (At 120 MHz clkin, the AD9850 can, I think, check the datasheet on that, update frequency at most 6.66... million times a second. With the 600 MHz CPU of the Teensy 4.0, you'd have more than 100 CPU cycles to calculate the new phase increment word and send it – that would work).
3. you use an FPGA, and implement a DDC yourself in that, and go through that with increasing speed. You'd connect a DAC to that. You exchange your happiness and sanity for continuous sweeping.
4. You use a more powerful computer (essentially, a PC or server or good laptop) and compute the chirp samples on that, and use a arbitrary waveform generator/SDR device to generate the analog signal.

Option 3. is definitely the "industry standard" way of doing this – but it also requires you to learn how to design FPGA applications and to have an FPGA eval board – not an easy requirement.

But honestly: PCs these days are fast, and SDR devices not that expensive. You could trivially implement a chirp in say, GNU Radio and use the so-cheap-it-hurts fl2k project as a DAC. No embedded programming necessary. So, I'd actually recommend option 4. However, using the extremely cheap FL2K solution would make incorporating PPS triggering impossible. You'd have to go for something like an Ettus N200 + BasicTX to allow for that.

• would we be able to take this conversation offline? How can I contact you? To clarify two points: I think the Teensy4.0 solution sounds best for my application, although Option 4 sounds very good too. Could the PPS be used an interrupt to start a sweep in gnuradio? Seems potentially possibly with rasberry pi. I do not have any problems with a stepped, but basically continuous sweep. The whole point of the project BTW is to try to come up with a relatively cheaper, but capable Ettus alternative. I know I could just hook up an Ettus N210 and be done with it! :) – AD0AE Feb 11 '20 at 2:20
• we could connect offline, but I'd be charging you my hourly consultation fees, which I doubt you'd want. As said, you can't trigger on PPS with an FL2K-based method, but could with a USRP N200 – that can not be a feature of the controlling computer, but must be a feature of the SDR device itself. Also, I recommended a PC for good reason: the Pi is too slow. – Marcus Müller Feb 11 '20 at 9:10
• OK, thanks again for the insight and unfortunately I do not have the money to pay your consulting fee. I am still a little bit confused as to why you cannot starting a gnuradio program which would presumably start the fl2k from some sort of GPS PPS pulse coming in, but that is probably another thread and my own ignorance. I think the Teensy4.0 solution is probably the best solution for what we want to do. I am concerned about multiple independent clocks, but my thinking was to keep the 'master clock' on the AD9850 as the high precision clock, maybe even driven by a gpsdo. – AD0AE Feb 11 '20 at 14:04
• it would start somewhen in the next 500 ms, maybe. I don't think that level of accuracy helps you at all. – Marcus Müller Feb 11 '20 at 15:35

caution ---- if you sweep the ADC sample clock, you will not preserve the modulation of the various RF carriers. IMHO you should step the sample clock, not sweep it.