What do you guys like on function generators?

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
I have a Tek FG504.  $50 on ebay.  Simple PS build.  Does sweeps.  Sine distortion sucks, but I love it.  Just my $0.02.
Best,
Bruno2000
 
gar381 said:
I use an old HP 3310.  Is a wonderful old war horse !!

Ebay has these cheap from time to time.  Got mine for $49 about 3 years ago.

Yeah, I looked at a bunch of those 3xxx units when I was on there. I think between the Loftech and all my sound cards, I'll probably just grab something cheap for the square waves. My power supply will be here today and I'm finally starting to think a bit more realistically about bench space. Need to build a shelf for some of these guys, but I'll probably wait for this freeze wave to pass.

George

PS- Some of those import circuits can supposedly produce user-defined pulse streams. Not that I need that feature right now, and I'm sure it's a PITA to set up with four little navigation buttons, but it seemed interesting. I guess you could use it to fake a clock signal or other data (depending on length?).
 
Yep I'm a fan of the old HP 3xxx series as well.  I bought an HP3312A off Ebay for about $50 and it works great for me.  One of the switches is sometimes fussy but a bit of exercise and all is well. 

I'm a little hesitant to recommend another bench tool as my first one (6205) turned out to be a job for you.  Good job on the switch repair!

regards,
Jeff
 
deveng said:
I'm a little hesitant to recommend another bench tool as my first one (6205) turned out to be a job for you.

Don't sweat it. I'm happy with what I got, and would probably get the same model again had I needed to send this one back. I sent the guy forty bucks back, and the shipping was around twenty, so I came out pretty well.

I'm going to hold off a minute on the generator. I think I'm good to go with my Loftech (or DAW) for sines, and I may build something simple to get squares. I found a 555 circuit which recommends a specific type of 555 to produce some really clean ones, so I may try it on my next Mouser order.

George 
 
I have a Loftech TS-1 I bought nearly 20 years ago.  Works great (thanks John Roberts)!  Just about a month ago though I went to turn it on and.....nothing.  Opened it and checked the power supply filter caps and found them to be bad, probably dried out.  Replaced them and its back up and running for another 20 or more. 
 
deveng said:
I have a Loftech TS-1 I bought nearly 20 years ago.  Works great (thanks John Roberts)!

Exact same deal here! Mine's at least twenty. Only issue I've ever had was that the meter cal. pot isn't quite rigid enough and flexes when you insert a screwdriver. I think I modded mine with a dowel to brace it way back when I got. I've been putting off digging into that, my scope, and one or two others which may need some new caps by now, but so far none of them are acting up.

BTW- If you have any hints on what to look at in that power supply, I'm open. I'm embarrassed to say that as long as I've been tinkering with this stuff I'm still no good at checking most active components. I poked around in it and verified a bunch of the voltages they give you in the schematic, and checked a bunch of parts in the neighborhood of that "current sampling resistor network" which switches in with ammeter mode, but the meters still lay dead when the switch goes in. I'm guessing it's dead or malfunctioning transistors or diodes. It's also possible that I popped something during the brief run where a few switch pins were jumped incorrectly, but I didn't get to run it much before I disassembled everything, so I'm not sure the current metering worked when I got it.

Take Care,

George
 
Is there any reason a $5 microprocessor with a built in 16-bit DAC, running in to a LPF / op-amp buffer wouldn't work?  I would think this should be capable of running pretty low THD, provided the jitter in the clock source was small compared to the maximum audio bandwidth (and I can't think why it wouldn't).

I have quite a few extra AVR XMEGA controller boards with DAC outputs, and it might make a useful side-project with only a tiny bit of code work.  Just a simple loop and a call to sin() to set the amplitude should do it.
 
Matador said:
Is there any reason a $5 microprocessor with a built in 16-bit DAC, running in to a LPF / op-amp buffer wouldn't work?  I would think this should be capable of running pretty low THD, provided the jitter in the clock source was small compared to the maximum audio bandwidth (and I can't think why it wouldn't).

I have quite a few extra AVR XMEGA controller boards with DAC outputs, and it might make a useful side-project with only a tiny bit of code work.  Just a simple loop and a call to sin() to set the amplitude should do it.

Coincidentally I make sine waves with cheap micros...

I don't know about a call to sin(), I write in assembler and there is no sin( ) instruction.  I guess you can calculate sin X using the trig identity SinX= X-(x^3/3!+(x^5/5!)-(x^7/7!).....  But there is no exponent or factorial function either, so a bunch of clock tics per sample calc... The factorials don't change but calculating enough exponents with good resolution will burn some processor time.

I just generate a look-up table ahead of time using excel spread sheet with say 1024 samples per cycle. Load than into the program memory and read them out at whatever rate needed to make different frequency sinewaves..

For my drum tuner I started out using +/-7B amplitude resolution (8 bit processor). My later 16b platform used around  9 bit amplitude resolution (using PWM output)  but the new processor I'm working on now has a 16b DAC built in so I'm pushing out 16b sine waves  ;D. I don't have a test bench to measure it but I suspect it's pretty good, it sounds clean.  Certainly good enough for my purposes.

JR

PS: Please don't tempt me.. I could make a new version of my old TS-1, smaller, better, faster with this chip.....but it is against my religion to design products that can be done just as well by a smart phone app.
 
These xmega CPUs I've been playing with run at 32Mhz, and have full C libraries (including math.h) for most of this stuff.  With 384K of code and 32K of SRAM I haven't felt the need for precomputed lookup tables in some time. :)

So I assume all that changes to make different frequencies is the rate you make calls to the next value of sin():  simple with a PWM interrupt which should theoretically give 12+ bits of precision to the waveform output frequency (maybe 16 bit).  That's sub 0.01Hz precision.

I assume it is still useful to LPF the resulting output wave at somewhere north of 20kHz?  If we only make tiny changes to the output voltage (e.g. slew rate limit the output signal) would aliasing artifacts still be an issue?
 
I may be the last dinosaur still writing in assembler.  :'( With my early micro platform I actually ran into problems with not enough clock ticks to service the sine wave interrupt written in assembler. I can't imagine compiled C keeping up. The new stuff runs faster and better (writing 8 bit code for a world that comes in more than 256 flavors, is a huge PIA).

I am unhappy about some of the Microchip support and documentation issues, so I won't pimp for them, but I generally like their parts. The new dsp micro I am messing with, has a 256x oversampled  16b DAC built onto the chip, so the noise from sampling rate is not a problem. The DAC has a 4 sample deep input buffer, so I can push data to it even slower. Since the DAC runs off it's own 256x clock you don't need to worry about interrupt sample timing consistency, etc. 

Back when I was using PWM output (as a cheap DAC) into a passive RxC filter for output, I actually generated and combined two PWM outputs that were complementary so at low amplitudes the two PWMs were mostly opposite polarity and cancelled each other out. I still had some beating since I sent this lightly filtered PWM output to a class D amp with free running clock to drive speakers. The new micro with over-sampled DAC no longer beats with the class D amp.    ;D

  JR
 
JohnRoberts said:
I may be the last dinosaur still writing in assembler. 

Hardly!  I still use quite a bit of assembler, but mostly for CPU-specific things (like only being able to unlock a main CPU PLL change if two requests are made to a special unlock register within 4 clock cycles) which are almost impossible with straight C.

So I'm just spitballing this (not even sure I'll have time), but the basic design would be like this.

1) If we want to reconstruct a worst-case 20kHz sine wave, the period of this signal is 50us.  At 32MHz main clock, this gives one clock every 31ns.  Or about 1600 clock ticks per revolution of the sine wave.
2) If we want to compute the sine "lobe" (up to pi/2 radians), we have to recycle the computation at twice the main frequency of the sine wave.  So this would happen at a 40kHz rate, or once every 25us, or every 800 main clock cycles.  We get the "other" sine lobe by taking the first and just multiplying everything by -1.
3) We have to step the DAC through the sine wave table.  If we split the lobe into something like 64 steps (this is essentially the sampling rate), this only leaves 800/64 = 12 clocks per step to calculate the "next" sine value.

So I can see this would be quite a challenge to compute on the fly. ;) Doing a load/store from a pre-calculated sine wave table would be done easily in 12 clock cycles, even with vanilla C.

Perhaps a hybrid approach is better:  take the step size as an input, run the sine wave table calculation in real time before the output signal is started.  Adjusting the frequency is simple changing the rate that we step through the table, which is a single PWM divider register.

With 128 steps every 50us, we need to run the PWM at a rate of about 2.5MHz.

Seems doable provided the DAC can settle at a reasonable rate (relative to the slew rate needed).  If we have to run between a 3.3V rail and ground (assuming half-code sits at Vcc/2), then the maximum slew rate happens at the first step, which is about 0.2V in 390ns or 0.5V/us.

So obviously the less steps we have to go through to reconstruct the sine then easier this gets:  the above is all worst case at 20kHz assuming 128 steps per half-phase.  I wonder if you run the output through a LPF (or reconstruction filter) how low one could drop the step size before the output sine became unusable?  Doesn't Nyquist say that so long as I maintain more than two samples per period that I should be able to get a clean sine from the reconstruction filter?
 
Matador said:
JohnRoberts said:
I may be the last dinosaur still writing in assembler. 

Hardly!  I still use quite a bit of assembler, but mostly for CPU-specific things (like only being able to unlock a main CPU PLL change if two requests are made to a special unlock register within 4 clock cycles) which are almost impossible with straight C.
i have been exposed to programming computers since having to punch Hollerith cards back in the '60s to run overnight on an IBM360 mainframe (FORTRAN), then basic, then C, but when I finally decided to get serious in embedded design I bought a C compiler but just found the examples in assembler easier to follow. Now years later I still prefer assembler. 
So I'm just spitballing this (not even sure I'll have time), but the basic design would be like this.

1) If we want to reconstruct a worst-case 20kHz sine wave, the period of this signal is 50us.  At 32MHz main clock, this gives one clock every 31ns.  Or about 1600 clock ticks per revolution of the sine wave.
2) If we want to compute the sine "lobe" (up to pi/2 radians), we have to recycle the computation at twice the main frequency of the sine wave.  So this would happen at a 40kHz rate, or once every 25us, or every 800 main clock cycles.  We get the "other" sine lobe by taking the first and just multiplying everything by -1.
3) We have to step the DAC through the sine wave table.  If we split the lobe into something like 64 steps (this is essentially the sampling rate), this only leaves 800/64 = 12 clocks per step to calculate the "next" sine value.

So I can see this would be quite a challenge to compute on the fly. ;) Doing a load/store from a pre-calculated sine wave table would be done easily in 12 clock cycles, even with vanilla C.

Perhaps a hybrid approach is better:  take the step size as an input, run the sine wave table calculation in real time before the output signal is started.  Adjusting the frequency is simple changing the rate that we step through the table, which is a single PWM divider register.
Back in my first generation relatively slow 8 bit platform, I only loaded in 90' of a lookup table then before I started the sine wave I calculated a full sine wave table and loaded it into ram for fast/easy recall. 
With 128 steps every 50us, we need to run the PWM at a rate of about 2.5MHz.
I used PWM output for first and second generation platforms. Period of the PWM increases the amplitude resolution while you want to keep that rep rate above the audio band. Faster processor clock helps PWM dynamic range, while it hurts battery life.
Seems doable provided the DAC can settle at a reasonable rate (relative to the slew rate needed).  If we have to run between a 3.3V rail and ground (assuming half-code sits at Vcc/2), then the maximum slew rate happens at the first step, which is about 0.2V in 390ns or 0.5V/us.
Which DAC?
So obviously the less steps we have to go through to reconstruct the sine then easier this gets:  the above is all worst case at 20kHz assuming 128 steps per half-phase.  I wonder if you run the output through a LPF (or reconstruction filter) how low one could drop the step size before the output sine became unusable?  Doesn't Nyquist say that so long as I maintain more than two samples per period that I should be able to get a clean sine from the reconstruction filter?

Nyquist is mainly talking about integrity of extracting the frequency component. Amplitude will also be altered by a sinx/x function. How many samples you need depends on how accurate and clean of a signal you need.

Again I am not pimping for MicroChip but the over clocked DAC built into their new DSPic series up-samples data at 256x for much better output resolution without taking up clock overhead to service it. The 4 deep buffer makes servicing the DAC even more efficient since you can calculate the next 4 samples at the same time. 

Again I feel pretty good abut being able to make a nice Audio test set using this technology, while i feel less good about it being a successful business venture. Since freeware and computer or smart phone sound cards can do it pretty damn cheaply. Just because you can is not a reason to do something.

I will continue designing a product that can't be done with a smart phone (while some try).

JR
 

Latest posts

Back
Top