Need DDS module, 2nd round

Essentially up to 10KHz base frequency and the sweep could be +/-50% of base. So any old digital register will do.

True, but slowly this one section is turning into a little monster with lots of parts :-)

ing

hip

ewhat

two

hose

of

nd by..

Joerg, This trick looks perfect for you. I'm hoping you'll show me how to to get the lower harmonics down below 60dB. :^) The only bit I wanted to add is that I first used a 6-pole Butterworth LP, but it looked like crap in the time domain at the edges, and I switched to a Bessel.

George H.

at the frequencies needed it is also easy in an MCU, but he wants display and buttons so you'll need to find some hardware with that and afair he also needed 2Vrms in 50R so also needs an output buffer

and while it wouldn't take long for someone with experience with an MCU it would take some time if you need to start from scratch

if he could do with a user interface via usb or serial port and an unbuffered DAC output it could be whipped up in few hours on almost any of the cheap cortex boards

one of stm32 discovery boards has a headphone amplifier so maybe that could work but it still leaves the user interface

-Lasse

ing

hip

ewhat

two

hose

of

nd by..

Ja, Ja, lotsa parts! (maybe 5 different R's) George H.

And a 4017. And some capacitors for the Bessel. And some inductors :-)

But it sure is an idea that would work.

Oh yeah, we had a bunch that came in kits best suited for starter electronic people from a particular source that were packaging them. . Also, back then surplus centers were very popular and you could find these chips there and more than likely they were seconds but they made their way out there in equipment where they didn't belong..

These days things are laser trimmed and that isn't such an issue any more.

With today's methods of fabbing chips, I would bet a chip like that could be reproduce with a much better yield and precision.

Jamie

be

lowpass.

active audio filters

with a sine wave table,

sweep from f1 to f2.

get

here.

a C

pseudocode.

DAC) and

ADC

short and

DDS uses a long (typically around 48 bits) integer phase accumulator which conveniently overflows every 2pi radians with no additional code. The top N bits (say, 10 or 12) are mapped through a sine table and drives the DAC. It's very simple, just a few lines of code. You'd need double floats, overflow tests, some sort of sine algorithm, and a float-to-fix conversion for the DAC. That would require hardware floats, and probably woundn't work as well as the integer version.

The IIR would take longer to execute than the DDS algorithm.

bits

some

If you assume emulated floating point is infinitely slow but usually it isn't. I have used emulated floating point in a signal processing application on ARM before and I know it does have its advantages.

all

to

der.

ch

p N bits

very

ts, some

would

er

using the usual fixed point phase accumulator and then doing sin() in float makes sense

but doing the phase accumutation in floats I'm not so sure about, forever doing an accumulation modulo 2*pi sounds iffy

with fixed point it is exact since 2^n is defined to be 2*pi

-Lasse

bits

some

I made some crude measurements on a 120MHz STM32F2, emulated floating point and gcc:

Double Precision: 0.415us / 49.852 cycles /multiply 0.378us / 45.403 cycles /add 2.414us / 289.702 cycles /divide

Single Precision: 0.194us / 23.350 cycles /multiply 0.250us / 30.052 cycles /add 0.610us / 73.202 cycles / divide

Pretty respectable I thought.

bits

some

As compared to 1 cycle for add/sub/shift/mul on an ARM.

There's no reason to use any floats in a DDS sinewave generator.

bits

very

some

would

Well no, was just responding to point about floats needing to be in hardware, if they *were* used.

harder.

bits

very

some

would

That's true, but you'd pay another dollar or so for hardware floats, and Joerg wouldn't like that.

Floating point is always an approximation just like a fixed point integer. In this case top few bits of a float will vary between 0 and

Yes, but not transcendental calcs.

STM32F2 is an ARM Cortex M3.

No, but it might make calculating the frequencies during a sweep a bit easier.

I'd be interested in how long a sin(x) or tan(x) (probably about the same) takes for non-trivial angles. Or ln(x)/exp(x).

e:

ote=

Nic=

er =

oat=

har=

angle=

whi=

to=

t's=

tes=

at =

teg=

how would you do it?

float phase += (f/fsample)*2*pi;

if(phase > 2*pi) phase -= 2*pi;

output = sin(phase);

or?

int phase += (f/fsample)*2^32;

output = sin(2*pi*phase/2^32);

-Lasse

DAC = sine_table(int_phase >> 22)

Two lines of code!

OK, one could use floats to compute F, then map that to an integer for the phase accumulation.

But to do a sweep, why not make the delta-f increment a long integer too? Hell, work in 64 bit ints:

F = F + DELTA ; sweep frequency or whatever

A = A + F ; phase accumulate

DAC = sine_table(A >> 52) ; sine conversion into DAC

At 100 KHz hit rate, 32 bit math gives 23 uHz resolution, minimum sweep rate about 2 Hz/sec, which is probably good enough. But 64 bit integer math is no big deal on an ARM.

Its hard to say without a real project. My gut says the all float implementation will be faster. Float to integer conversions are 'expensive'. So are doing too many calculations.