oscillator bank 1

[skelmonsta]

Hi all, I'm a software/DSP guy currently a bit over my head designing some hardware. I have a design in mind for my problem, but it's based on technology I would have used to do this twenty years ago. So I am writing in hopes of getting a "sanity check" on my solution.

Problem: build an 128-oscillator bank. Frequencies: 24000 Hz, 24093.75 Hz, 24187.5 Hz, ... 35906.25 Hz. Each oscillator must be on a different physical connection, for a capacitive sensor application. The spacing corresponds to a 1024-point FFT at 96kHz. Since they are all within one octave, the signals can be square waves (only the fundamental matters). Frequency accuracy needs to be 0.01% (+-4 Hz at 40kHz). Power needs I'm not too sure of yet, let's say a handful of mW at 5V for each oscillator.

This is a prototype that I will have to build. If it were a product, my solution would be: hire someone to design something, probably involving an ASIC...

Solution: The outputs are driven by TTL octal latches. A microprocessor (PIC) addresses the latches a byte at a time through some more TTL logic. The microcode updates a software counter for each oscillator and updates the latches when needed.

A vague solution, but hopefully precise enough to ask: is this at all the right technology to use? The correspondence of the frequencies to the bins of the FFT led me to think about solutions that would use this property to advantage. But it's hard to see how to do that given the need for separate outputs.

 

[VEBill]

Huge memory. 128 bits wide (for square waves) and Least Common Multiple deep (pretty big but memory is free these days). Calculate in advance (once), fill it up, and then clock it out.

Obviously, stand-by for more elegant suggestions.

 

[VEBill]

If these frequencies were all on ONE output (a 'comb' in the frequency domain), then there was a 'Design Idea' several years ago where the goal was to provide a system that could transmit tunnel information on all FM broadcast channels (88-108 MHz) at once. The solution was to calculate the 100 carrier waveforms in advance, slide them back-and-forth in phase to minimize the peak amplitude of the sum, then sum them up one last time, and burn the resultant time-domain waveform data into a ROM.

 

[VEBill]

If the waveforms (or groups of waveforms) don't need to be all phase locked, then there would be many advantages in splitting the 128 parallel channels into smaller chunks (for example, batches of 8), instead of one huge memory. Doing so helps to reduce the LCM (probably drastically). And you can also mass produce the (8-bit wide, for example) cards. It's a design exercise the determine the optimum split.

 

[geekEE]

How about 128 programmable oscillators like Ecliptek's EPO series? Large distributors have the programmers to burn them to your desired frequencies, although I'm not sure what the minimum order quantities would be.

 

[geekEE]

oops. I think those oscillators don't go down to the frequencies that you need. You'd have to divide down.

 

[skelmonsta]

> Huge memory.

Thanks VE1BLL, this is a good idea. Since my frequencies don't have to be very accurate, I can probably fudge the LCM a lot too.

 

[skelmonsta]

geekEE, thanks for the pointer. I was hoping there would be some multi-oscillator chip out there.

 

[VEBill]

As you may know (but just to be clear), the Least Common Multiple (LCM) is required if you want all the waveforms to get back into perfect phase again so that you can jump back to address zero to start the cycle again with absolutely no phase-jump on any of the waveforms.

Be aware that the top end of the required address space will probably be set by your design parameters, and is unlikely to be a simple number like 2^N. In other words, assume at the outset that you'll need an arbitrary end point that may be a run-of-the-mill obscure number.

It used to common (well, relative to this very obscure topic) to look for opportunities to just store one-half, or even one-quarter, of the waveform and then combine counting backwards and inverting the output to complete the entire cycle. But these days memory is probably cheaper than counting backwards and certainly cheaper than inverting the output on command.

My gut just told me that you might have a clocking challenge as well. The tinyness of the time step (high F clock) required smells like it will be function of how accurately placed you need all the edges. This would be probably also be solved by breaking up the 128 into banks of a much smaller N (like 8 for example).

 

[MacGyverS2000]

At the kiloHertz range, I would do this with a couple of high pin count (say, 80-pin) processors running off of a single crystal. Some simple bit banging would easily get you what you need. You could go with latches, but I would think the hassle of addressing multiple latches, timing, etc. could be easily dismissed with two processors running in sync.


Dan - Owner

http://www.Hi-TecDesigns.com

 

[itsmoked]

I'm with mac on that. Course us micro boys can pound a lot of solutions into a micro sized box.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[VEBill]

Overall, there's nearly 8 million transitions per second to manage (~30kHz * 128 * 2), so the totality is not really an audio-range challenge. 8 million transitions per second is perhaps not too bad with today's processors, but without careful planning, the sequential transitions (on different outputs) may be arbitrarily close together in time as things go in and out of phase.

In other words, there will be a minimum processing loop heart-beat that isn't likely to be perfectly in phase with the theoretically-perfect schedule of transitions. Unless you can arrange for the processor clock to be a LCM of the schedule (and that might be pretty high if the channel count per processor is high).

It might require some clever system design and programming to keep the phase noise in check. Part of the solution would be to slide the waveforms in relative phase to eliminate transitions that are too close together to accomplish with a given processing speed, and too far apart to combine in the schedule without causing excess phase noise.

Another trick would be, if using two packages, to distribute the too-close transitions between the two packages.

Or check the phase noise requirement. Perhaps it's wide enough that it's not really an issue.


What's that old joke?

"Daddy, what is 'Time' ?"

"Son, time was invented so that everything doesn't happen at once."

 

[geekEE]

I think the accuracy is going to be beyond what you can do with a micro. If it needs to be within 0.01% at 40kHz, that means the period needs to be 25us +/- 2.5ns

You're not going to be able to get your transitions to be within a window like that if you're polling a timer and banging ports. You'd have a lot more jitter than 0.01%.

 

[skelmonsta]

VE1BLL - the phases really don't matter, as long as their modulation doesn't move the frequencies outside of my pretty loose requirements. I am not locking to any phases, just determining overall amplitudes with every FFT. So if I go with the "big memory" solution, I think I can cut some corners.

macgyvers2000 - Thanks! Any examples of what kind of processors you mean? A TTL solution is appealing if I can get away without buffering each output after the logic -- don't know if that would be possible with a microprocessor.

 

[MacGyverS2000]

For inexpensive but high-pin count chips, I suggest PICs... this is a fairly low processing power need, and you really don't need the high power (and higher costs) associated with AVRs.

Since the phase doesn't matter, the accuracy is directly tied to the accuracy of the processor's crystal. Since you can order 50ppm crystals from Digi-Key for $2, that's taken care of nicely.

I take back my earlier statement... I might use external chips. In this case, some flip-flops would be useful. Have the PICs output a series of (93.75Hz * n) signals by setting up a timer to interrupt every (93.75Hz * 128) times and change the appropriate signal lines. Heterodyne the signals with a 40kHz wave using the flip-flops and you have a seriously large array of signals spaced at 93.75Hz intervals starting at 40kHz with 50ppm accuracy. Signals will be in-phase in groups of 8, but since that wasn't a requirement, who cares.


Dan - Owner

http://www.Hi-TecDesigns.com

 

[benta]

I would make one 93.75 Hz reference oscillator and multiply it up using PLL frequency synthesizers. 128 is a lot, of course, but the circuits are dead simple and cheap.
24000 = 93.75 * 256
24093.75= 93.17 * 257
etc.
This will give you 100% coherency between the output frequencies and phases.

Regards,

Benta.

 

[VEBill]

Hetrodyning is a potential useful suggestion. But you'd need to use a 'balanced modulator' approach to suppress the opposite sideband, because filtering would be problematic.

"by setting up a timer to interrupt every (93.75Hz * 128)"

I can't quite put my finger on it yet, but my gut tells me that the above isn't quite correct. I think that the multiplication function needs to be replaced with an LCM function. 12,000 Hz (93.75Hz*128) sounds much too easy.

Here's some LCMs just for laughs:
LCM (first 64, 24000 to 29906.25) = 2.6873E+255
LCM (first 77) = 6.0832E+302
LCM (first 78) = #NUM! (error)

The hetrodyning concept helps, but you still end up with three digit exponents.
LCM (93.75 to 5906.25, first 63) = 1.7139E+185

These will probably be the biggest numbers that you'll see all month. Except perhaps your post-Xmas credit card bill.

 

[benta]

That's not what I meant.
You'd first have ONE 93.75 Hz oscillator.
Then, for each frequency you have a phase/frequency detector, a VCO and a feedback counter.
This you could probably put into an FPGA 128 times. You'd need the VCOs to be external, but 128 counters and 128 phase detectors is a piece of cake. The simplest phase detector is just an EXOR gate.

Benta.

 

[VEBill]

My previous post was responding to macgyvers2000's.

 

[VEBill]

"multiply it up using PLL frequency synthesizers. 128 is a lot"

Neat concept. But it'll be a big box with all those VCOs.

But since ANY solution probably needs 128 BNC output jacks anyway, even a one-chip solution will probably end up in a the same size big box.