Driver to drive?

On Monday, March 4, 2013 1:22:44 PM UTC-5, Charlie E. wrote:

For wiring, I still like the idea of surface (baseboard) mounted

conduit that looks like molding I have also seen furring strips and

drywall installed over the panels to provide wiring space behind the

drywall...

That's dumb, even the foam core SIPs have chases:
The Structural Insulated Panels manufactured by Premier SIPs are both simple and easy for electricians to wire. It does require a small amount of advance planning. 1-˝” diameter wiring chases are provided in the panel cores for quick access by the electricians. The chases are typically located at 16" and 45” off the finished floor as well as vertically 4' on center. These locations as well as any custom chases should be verified during the shop drawing phase.
Type NM-B cable, as labeled by Underwriters Laboratories, passes UL-719 that mandates a maximum conductor temperature of 90oC (194oF). The conductor temperatures under normal loads will not exceed
60oC, due to the restrictions on amperage loading and breaker sensitivity.
The wiring used for most residential and light commercial structures, commonly referred to as “Romex”, is widely available with the NM-B designation labeled by UL and is acceptable for use with Premier SIPs.
Conventional studded wood panels are even easier, wiring is installed the same way as with on-site built.

 

[Spehro Pefhany]

On Mon, 04 Mar 2013 06:54:32 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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.

Yes, but not transcendental calcs.

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

STM32F2 is an ARM Cortex M3.

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

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).

 

[John Larkin]

On Mon, 4 Mar 2013 15:32:11 -0800 (PST), "langwadt@fonz.dk"
<langwadt@fonz.dk> wrote:

On Mar 4, 6:48 pm, n...@puntnl.niks (Nico Coesel) wrote:
"langw...@fonz.dk" <langw...@fonz.dk> wrote:
On Mar 4, 1:05=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 03 Mar 2013 22:35:28 GMT, n...@puntnl.niks (Nico Coesel) wrote:

John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Sun, 03 Mar 2013 20:38:07 GMT, n...@puntnl.niks (Nico Coesel) wrote=
:

Spehro Pefhany <speffS...@interlogDOTyou.knowwhat> wrote:

On Sun, 03 Mar 2013 18:49:31 GMT, the renowned n...@puntnl.niks (Nic=
o
Coesel) wrote:

John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Sun, 03 Mar 2013 09:48:31 -0800, Joerg <inva...@invalid.invalid=
wrote:

Just use
floating point. The chip is probably fast enough to emulate. After =
all
its one sin() and some additions to get the output. Some fast float=
to
integer conversion magic and its all done.

LPC43xx should be fast enough- it's got hardware floating point.

Floats don't help implementing the DDS core; they actually make it har=
der.

How come? IMHO generating a sine wave is a matter of output=3Dsin(angle=
)
* amplitude. Angle is incremented by a step which depends on the
sample rate and frequency. From memory: Say your samplerate is 10kHz
and your output frequency is 105.3Hz then the size of each increment
is (2pi / 10kHz) * 105.3Hz radians. That is very easy to program.
Ofcourse it will need some tweaks to make it fast but the basics are
simple.

DDS uses a long (typically around 48 bits) integer phase accumulator whi=
ch
conveniently overflows every 2pi radians with no additional code. The to=
p 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 tes=
ts, 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 integ=
er
version.

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.

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

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
2pi. The top bits of an integer phase accumulator will vary between 0
and the length of the lookup table.


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;

DAC = sine_table(int_phase >> 22)


Two lines of code!


--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation

 

[langwadt@fonz.dk]

On Mar 4, 6:48 pm, n...@puntnl.niks (Nico Coesel) wrote:

"langw...@fonz.dk" <langw...@fonz.dk> wrote:
On Mar 4, 1:05=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 03 Mar 2013 22:35:28 GMT, n...@puntnl.niks (Nico Coesel) wrote:

John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Sun, 03 Mar 2013 20:38:07 GMT, n...@puntnl.niks (Nico Coesel) wrote> >:

Spehro Pefhany <speffS...@interlogDOTyou.knowwhat> wrote:

On Sun, 03 Mar 2013 18:49:31 GMT, the renowned n...@puntnl.niks (Nic> >o
Coesel) wrote:

John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Sun, 03 Mar 2013 09:48:31 -0800, Joerg <inva...@invalid.invalid> >> wrote:

Just use
floating point. The chip is probably fast enough to emulate. After > >all
its one sin() and some additions to get the output. Some fast float> > to
integer conversion magic and its all done.

LPC43xx should be fast enough- it's got hardware floating point.

Floats don't help implementing the DDS core; they actually make it har> >der.

How come? IMHO generating a sine wave is a matter of output=3Dsin(angle> &gt
* amplitude. Angle is incremented by a step which depends on the
sample rate and frequency. From memory: Say your samplerate is 10kHz
and your output frequency is 105.3Hz then the size of each increment
is (2pi / 10kHz) * 105.3Hz radians. That is very easy to program.
Ofcourse it will need some tweaks to make it fast but the basics are
simple.

DDS uses a long (typically around 48 bits) integer phase accumulator whi> >ch
conveniently overflows every 2pi radians with no additional code. The to> >p 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 tes> >ts, 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 integ> >er
version.

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.

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

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
2pi. The top bits of an integer phase accumulator will vary between 0
and the length of the lookup table.

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

 

[John Larkin]

On Mon, 04 Mar 2013 16:42:08 -0500, Spehro Pefhany
<speffSNIP@interlogDOTyou.knowwhat> wrote:

On Mon, 04 Mar 2013 06:54:32 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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.

Yes, but not transcendental calcs.

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

STM32F2 is an ARM Cortex M3.

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

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

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.


--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation

 

[Nico Coesel]

"langwadt@fonz.dk" <langwadt@fonz.dk> wrote:

On Mar 4, 6:48=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
"langw...@fonz.dk" <langw...@fonz.dk> wrote:
On Mar 4, 1:05=3DA0pm, n...@puntnl.niks (Nico Coesel) wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 03 Mar 2013 22:35:28 GMT, n...@puntnl.niks (Nico Coesel) wrot=
e:

John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Sun, 03 Mar 2013 20:38:07 GMT, n...@puntnl.niks (Nico Coesel) wr=
ote=3D
:


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.

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

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
2pi. The top bits of an integer phase accumulator will vary between 0
and the length of the lookup table.


how would you do it?

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

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

output =3D sin(phase);

or?

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

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

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.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[langwadt@fonz.dk]

On Mar 5, 1:23 am, John Larkin <jlar...@highlandtechnology.com> wrote:

On Mon, 4 Mar 2013 15:32:11 -0800 (PST), "langw...@fonz.dk"









langw...@fonz.dk> wrote:
On Mar 4, 6:48 pm, n...@puntnl.niks (Nico Coesel) wrote:
"langw...@fonz.dk" <langw...@fonz.dk> wrote:
On Mar 4, 1:05=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 03 Mar 2013 22:35:28 GMT, n...@puntnl.niks (Nico Coesel) wrote:

John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Sun, 03 Mar 2013 20:38:07 GMT, n...@puntnl.niks (Nico Coesel) wrote> >> >:

Spehro Pefhany <speffS...@interlogDOTyou.knowwhat> wrote:

On Sun, 03 Mar 2013 18:49:31 GMT, the renowned n...@puntnl.niks (Nic> >> >o
Coesel) wrote:

John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Sun, 03 Mar 2013 09:48:31 -0800, Joerg <inva...@invalid.invalid> >> >> wrote:

Just use
floating point. The chip is probably fast enough to emulate. After > >> >all
its one sin() and some additions to get the output. Some fast float> >> > to
integer conversion magic and its all done.

LPC43xx should be fast enough- it's got hardware floating point.

Floats don't help implementing the DDS core; they actually make it har> >> >der.

How come? IMHO generating a sine wave is a matter of output=3Dsin(angle> >> &gt
* amplitude. Angle is incremented by a step which depends on the
sample rate and frequency. From memory: Say your samplerate is 10kHz
and your output frequency is 105.3Hz then the size of each increment
is (2pi / 10kHz) * 105.3Hz radians. That is very easy to program.
Ofcourse it will need some tweaks to make it fast but the basics are
simple.

DDS uses a long (typically around 48 bits) integer phase accumulator whi> >> >ch
conveniently overflows every 2pi radians with no additional code. The to> >> >p 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 tes> >> >ts, 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 integ> >> >er
version.

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.

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

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
2pi. The top bits of an integer phase accumulator will vary between 0
and the length of the lookup table.

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;

DAC = sine_table(int_phase >> 22)

Two lines of code!

I'd probably add the few lines of 2's complement trickery
so only one quadrant of sine table is needed or even use a taylor
series,
on a cpu with mul-acc is takes very few cycles

but the point was really that even if you use float to generate the
sine wave
I'd still use integers for the phase accumulator


-Lasse

 

[Nico Coesel]

"langwadt@fonz.dk" <langwadt@fonz.dk> wrote:

On Mar 5, 1:23=A0am, John Larkin <jlar...@highlandtechnology.com> wrote:
On Mon, 4 Mar 2013 15:32:11 -0800 (PST), "langw...@fonz.dk"


I'd probably add the few lines of 2's complement trickery
so only one quadrant of sine table is needed or even use a taylor
series,
on a cpu with mul-acc is takes very few cycles

The sine table doesn't need to be that long. If every value of the DAC
is used then you'd have a sine table which has the maximum accuracy
you can ever achieve. With some math that comes to 2*pi* dac
resolution. So a 10 bit dac should need a 1024*2*pi=6434 samples.

The idea behind it is that every DAC value should be used at least
once to get the maximum accuracy and no values need to be
interpolated. This means you need to know the angle which causes a
difference of 1 LSB where a sine wave is the steepest (=in the zero
crossing). A simple approximation is: lsb_angle=arcsin(1/dac
resolution). The number of samples in the table is 2*pi/lsb_angle.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[John Larkin]

On Mon, 4 Mar 2013 16:44:24 -0800 (PST), "langwadt@fonz.dk" <langwadt@fonz.dk>
wrote:

On Mar 5, 1:23 am, John Larkin <jlar...@highlandtechnology.com> wrote:
On Mon, 4 Mar 2013 15:32:11 -0800 (PST), "langw...@fonz.dk"









langw...@fonz.dk> wrote:
On Mar 4, 6:48 pm, n...@puntnl.niks (Nico Coesel) wrote:
"langw...@fonz.dk" <langw...@fonz.dk> wrote:
On Mar 4, 1:05=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 03 Mar 2013 22:35:28 GMT, n...@puntnl.niks (Nico Coesel) wrote:

John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Sun, 03 Mar 2013 20:38:07 GMT, n...@puntnl.niks (Nico Coesel) wrote=
:

Spehro Pefhany <speffS...@interlogDOTyou.knowwhat> wrote:

On Sun, 03 Mar 2013 18:49:31 GMT, the renowned n...@puntnl.niks (Nic=
o
Coesel) wrote:

John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Sun, 03 Mar 2013 09:48:31 -0800, Joerg <inva...@invalid.invalid=
wrote:

Just use
floating point. The chip is probably fast enough to emulate. After =
all
its one sin() and some additions to get the output. Some fast float=
to
integer conversion magic and its all done.

LPC43xx should be fast enough- it's got hardware floating point.

Floats don't help implementing the DDS core; they actually make it har=
der.

How come? IMHO generating a sine wave is a matter of output=3Dsin(angle=
)
* amplitude. Angle is incremented by a step which depends on the
sample rate and frequency. From memory: Say your samplerate is 10kHz
and your output frequency is 105.3Hz then the size of each increment
is (2pi / 10kHz) * 105.3Hz radians. That is very easy to program.
Ofcourse it will need some tweaks to make it fast but the basics are
simple.

DDS uses a long (typically around 48 bits) integer phase accumulator whi=
ch
conveniently overflows every 2pi radians with no additional code. The to=
p 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 tes=
ts, 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 integ=
er
version.

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.

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

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
2pi. The top bits of an integer phase accumulator will vary between 0
and the length of the lookup table.

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;

DAC = sine_table(int_phase >> 22)

Two lines of code!


I'd probably add the few lines of 2's complement trickery
so only one quadrant of sine table is needed

Only if you're hurting for flash space. I once did a 16-in/16-out sine table
with no folding, 128Kbytes of lookup table. Why not?


or even use a taylor

series,
on a cpu with mul-acc is takes very few cycles

but the point was really that even if you use float to generate the
sine wave
I'd still use integers for the phase accumulator


-Lasse

--

John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

 

[John Larkin]

On Tue, 05 Mar 2013 02:19:29 GMT, nico@puntnl.niks (Nico Coesel) wrote:

"langwadt@fonz.dk" <langwadt@fonz.dk> wrote:

On Mar 5, 1:23=A0am, John Larkin <jlar...@highlandtechnology.com> wrote:
On Mon, 4 Mar 2013 15:32:11 -0800 (PST), "langw...@fonz.dk"


I'd probably add the few lines of 2's complement trickery
so only one quadrant of sine table is needed or even use a taylor
series,
on a cpu with mul-acc is takes very few cycles

The sine table doesn't need to be that long. If every value of the DAC
is used then you'd have a sine table which has the maximum accuracy
you can ever achieve. With some math that comes to 2*pi* dac
resolution. So a 10 bit dac should need a 1024*2*pi=6434 samples.

The idea behind it is that every DAC value should be used at least
once to get the maximum accuracy and no values need to be
interpolated. This means you need to know the angle which causes a
difference of 1 LSB where a sine wave is the steepest (=in the zero
crossing). A simple approximation is: lsb_angle=arcsin(1/dac
resolution). The number of samples in the table is 2*pi/lsb_angle.

In practice, we'd make the table have 2^n entries, which might be 8192 for a
10-bit DAC. That's only 16K bytes, a small fraction of the flash space on an
LPC1754.

We've done DDS with table interpolation, but in FPGA hardware. It helps a
little, sometimes.


--

John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

 

[Uwe Hercksen]

Joerg schrieb:

What I need in my case is DC-100Hz of sweep or FM bandwidth. Operating
frequency under 10kHz and sweep range up to 2kHz. Of course I can whip
up an analog solution but it won't be as precise and most of all not
really programmable.

Hello,

Agilent has a DDS generator with FM:
http://cp.literature.agilent.com/litweb/pdf/5988-8544EN.pdf

programmable via GPIB, LAN or USB.

Bye

 

[Joerg]

Uwe Hercksen wrote:

Joerg schrieb:

What I need in my case is DC-100Hz of sweep or FM bandwidth. Operating
frequency under 10kHz and sweep range up to 2kHz. Of course I can whip
up an analog solution but it won't be as precise and most of all not
really programmable.

Hello,

Agilent has a DDS generator with FM:
http://cp.literature.agilent.com/litweb/pdf/5988-8544EN.pdf

programmable via GPIB, LAN or USB.

Well, yeah, I am using something like that from a Chinese manufacturer
right now. But that is not suitable because two of those would have to
go into a smallish analog interface box. When you open up one of those
generators the enclosure is quite full.

Currently I am hammering out an analog solution. Again. <sigh>

--
Regards, Joerg

http://www.analogconsultants.com/

 

[josephkk]

On Sat, 02 Mar 2013 12:37:10 -0800, Joerg <invalid@invalid.invalid> wrote:

Hi Folks,

Long story short, none of the DDS modules I've found so far has the
ability to be sweeped or FM-modulated. This one has a signal input
terminal block "SIN" but I received a response from the manufacturer
that it connects to nowhere, it has no function:

http://imall.iteadstudio.com/tools-and-equipment/im120723003.html

What I need in my case is DC-100Hz of sweep or FM bandwidth. Operating
frequency under 10kHz and sweep range up to 2kHz. Of course I can whip
up an analog solution but it won't be as precise and most of all not
really programmable.

Is there anything better? Cost is not a big issue but should be somewhat
small and a display would be nice.

So use the Armstrong method.

?-)

 

[josephkk]

On Sun, 03 Mar 2013 19:51:06 -0500, Jamie
<jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:

Joerg wrote:

Jamie wrote:

Joerg wrote:


Spehro Pefhany wrote:


On Sun, 03 Mar 2013 09:48:31 -0800, the renowned Joerg
invalid@invalid.invalid> wrote:



If I wanted to do that I'd probably just get a uC with ADC and a big
fat
flash area, then use it just for this job. Its ADC reads my PID output,
points to the corresponding LUT address, shoves data to the DDS.
That is
how I'd do the final system, or let it calculate (depending how easy it
is to avoid birdies and stuff).

Have you considered just buying something like my Rigol DG4062 and
using it for proof-of-concept? For $795 it might be worth it, and it's
generally useful afterward with the USB and Ethernet interfaces etc.



I have, and the price isn't so important. I've got a Mastech arb gen
that would work just fine and is under $400. But I need something that
isn't so large.

Probably the old XR2206 will work ok. I was just surprised that no
company seems to have pick up this chip after it went lalaland.


Well lets see, I remember years ago a bunch of those chips got out there
and used for kits or what ever that actually didn't pass QC in the
sine wave shaper section. Guess some one found a market for them in any
case.



Ouch. How did they get those QC rejects? Those aren't supposed to be
chucked into an accessible dumpster.



I see that TAYDA Electronics has them for $2.99 and Mouser has a couple
in stock for only $87.00 bucks, most likely those past QC, chump change.



Yeah, that has me concerned as well. But ... if the distortion is 2%
instead of 1% it's not a major problem.


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

They were sweet chips for their time, but now they are up against DDS
chips with 14+ bit dacs for not all that much. They can't compete, except
in the hobbyist market which way too small.

?-)

 

[Nico Coesel]

josephkk <joseph_barrett@sbcglobal.net> wrote:

On Sun, 03 Mar 2013 19:51:06 -0500, Jamie
jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:

Joerg wrote:

Jamie wrote:
=20
Joerg wrote:


Spehro Pefhany wrote:

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=20
more.

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

Jamie

They were sweet chips for their time, but now they are up against DDS
chips with 14+ bit dacs for not all that much. They can't compete, =
except
in the hobbyist market which way too small.

Well, FM and sweep seems to be a problem

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Joerg]

josephkk wrote:

On Sat, 02 Mar 2013 12:37:10 -0800, Joerg <invalid@invalid.invalid> wrote:

Hi Folks,

Long story short, none of the DDS modules I've found so far has the
ability to be sweeped or FM-modulated. This one has a signal input
terminal block "SIN" but I received a response from the manufacturer
that it connects to nowhere, it has no function:

http://imall.iteadstudio.com/tools-and-equipment/im120723003.html

What I need in my case is DC-100Hz of sweep or FM bandwidth. Operating
frequency under 10kHz and sweep range up to 2kHz. Of course I can whip
up an analog solution but it won't be as precise and most of all not
really programmable.

Is there anything better? Cost is not a big issue but should be somewhat
small and a display would be nice.

So use the Armstrong method.

What, erythropoietin? Some kind of growth hormone?



--
Regards, Joerg

http://www.analogconsultants.com/

 

[John Larkin]

On Wed, 06 Mar 2013 11:10:09 GMT, nico@puntnl.niks (Nico Coesel)
wrote:

josephkk <joseph_barrett@sbcglobal.net> wrote:

On Sun, 03 Mar 2013 19:51:06 -0500, Jamie
jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:

Joerg wrote:

Jamie wrote:
=20
Joerg wrote:


Spehro Pefhany wrote:

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=20
more.

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

Jamie

They were sweet chips for their time, but now they are up against DDS
chips with 14+ bit dacs for not all that much. They can't compete, =
except
in the hobbyist market which way too small.

Well, FM and sweep seems to be a problem

I think ADI has a DDS chip that sweeps.

Why is it that ADI is the only outfit that makes DDS chips? I asked
one of their guys, and he didn't know.

We mostly do DDS in FPGAs.


--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation

 

[Joerg]

John Larkin wrote:

On Wed, 06 Mar 2013 11:10:09 GMT, nico@puntnl.niks (Nico Coesel)
wrote:

josephkk <joseph_barrett@sbcglobal.net> wrote:

On Sun, 03 Mar 2013 19:51:06 -0500, Jamie
jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:

Joerg wrote:

Jamie wrote:
=20
Joerg wrote:


Spehro Pefhany wrote:

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=20
more.

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

Jamie
They were sweet chips for their time, but now they are up against DDS
chips with 14+ bit dacs for not all that much. They can't compete, =
except
in the hobbyist market which way too small.
Well, FM and sweep seems to be a problem

I think ADI has a DDS chip that sweeps.

Why is it that ADI is the only outfit that makes DDS chips? I asked
one of their guys, and he didn't know.

The usuakl reason would be some sort of patent protection. But that's
just a guess.

We mostly do DDS in FPGAs.

But then they probably need 10x the power

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Michael A. Terrell]

John Larkin wrote:

I think ADI has a DDS chip that sweeps.

Why is it that ADI is the only outfit that makes DDS chips? I asked
one of their guys, and he didn't know.

We mostly do DDS in FPGAs.

Here is a link to the demo software for the AD8950 that does sweep.
<ftp://ftp.analog.com/pub/www/techSupport/designTools/evaluationBoards/downloads/AD9850_51_V2.41_Win2KXP.exe>

I doubt that he can download it and get it to run, like so much other
software. I had it installed on another computer and it works. You can
use the parallel port to connect the demo board to the PC and see that
it works.

They have sample code for the 8051 processor

 

[Jamie]

Nico Coesel wrote:

josephkk <joseph_barrett@sbcglobal.net> wrote:


On Sun, 03 Mar 2013 19:51:06 -0500, Jamie
jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:


Joerg wrote:


Jamie wrote:
=20

Joerg wrote:



Spehro Pefhany wrote:


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=20
more.

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

Jamie

They were sweet chips for their time, but now they are up against DDS
chips with 14+ bit dacs for not all that much. They can't compete, =
except
in the hobbyist market which way too small.


Well, FM and sweep seems to be a problem

i have a DDS function generator that does all of that and it

does not have any problems?

I think you'll find if you don't have a latency problem with the
serial link to the chip, you should be able to do all the FMing you
want..

Jamie