I need to reproduce a certain sound wave form, specifically, the sound of a heartbeat, and I need to do it with only a few dozen bytes of ram, on a PIC MCU. The sample itself is 250ms long, and I have it in uncompressed audio format at 11khz, 8 bits, mono. Is there a way to create a mathematical algorithm to generate the sound on the PIC? Otherwise I would need 344 bytes of ram, and thats more than the PIC has total not including the ram needed for code and all the other stuff I am doing on it. The heartbeat must be exacly reproduced, so I cant just generate an approximation.
You say you say that the heartbeat must be exactly reproduced, but in practical digital sampling and sound reproduction there are only better or worse approximations to the original. How bad can you accept?
If you just want to play back the one sound then there's no need to store it in RAM. Put it in program ROM using a jump table and the RETLW instruction. But where does the figure 344 bytes of RAM come from? Are you already compressing it? It seems to me that if you stick to 250ms at 11Khz you will need 2750 bytes.
If you just store it in ROM, it will require 2750 words of memory (assuming 12 or 14-bit instructions, half that with 16-bit instructions), and almost no RAM. ADPCM is a compression scheme that requires little processing and might be suitable for you. Any lossy compression scheme is not going to be an "exact" reproduction.
Do a Fourier analysis and see where the energy is. I just tried that with a sfx 'heartbeat', and most of it was below 1500Hz, so maybe you could go lower on the sample rate. If you could use 5500Hz and use 1/2 word per sample, it would only be 690 words of ROM.
Now, algorithmically- the sfx heartbeat looks like about half a dozen cycles at around 100Hz, decreasing in frequency, followed and preceded by some ~80Hz with a little 800Hz on top, fairly constant amplitude before and lower/decreasing with time amplitude (envelope) after. This sfx sound would not be that hard to program, and would use less ROM.
Best regards, Spehro Pefhany
--
"it\'s the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Spehro Pefhany's comment about looking at the FFT is good, though I'm not sure that will get you anywhere close to the "few dozen bytes of RAM" region. I'm not sure why you can't use flash or ROM to store the image, but let's say you can't do that for some reason and want the absolute smallest possible footprint.
I don't have direct experience with this, but you might take a look at the possibility of using linear predictive coding and Huffman compression. Take a look at "Numerical Recipes" for some discussion.
Some creativity may be needed, as well. One thing that comes to mind also is continued fractions, but a discussion of the idea would take a while and I'm not even sure exactly how to consider applying them without thinking a lot more about it. Or if, in fact, the idea even can be well applied.
Or a 50-cent 8-pin 32-K SPI SEEPROM, but where's the fun in that, eh?
Best regards, Spehro Pefhany
--
"it\'s the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
First, to get the principles out of the way, you have an approximation with your recording. It may be a good approximation, but it's still only an approximation. Your decision is going to be how good must your new approximation be, and what are the real criteria for deciding what your approximation should look like?
Second, where do you get the 344 bytes number? 11KHz * .25 second =
2750 samples, which sounds very much like 2750 bytes. And, since the typical heartbeat period is around 850ms, what do you really have? Only the most obvious pulse, with none of the little stuff that goes on between big pulses, or not even all of the main pulse?
Now, you have to decide what kind of accuracy you need in your approximation. You already have a rather coarse 8 bits in your sample, so experimenting with various piecewise leastsquares curve fits may give an approximation as good as what you have, and save you some RAM at the expense of some processing time. Or, a simple linear interpolation between pairs of points at times selected to minimize slope errors -- assuming that's even important.
Next, if you have it pre-recorded, why not use a much better processor than the PIC? For what you want to do I don't know of any processor worse designed than the PIC (at least the 16... series, which are all I've used). Use a decent processor and you can copy your entire sample set out from flash at 11KHz.
John Perry
PS -- The PIC16 is atrocious for this kind of job, but it works OK for other kinds of applications. Don't read more into my comment than I say.
A thought based on minimal information....Try outputting a square pulse then analog filtering it with a multipole filter to make a click into a thump. If you can get a single thump sounding just about right, then it might be just a matter of the micro outputting the right length digital pulses, which should be esy to do with your memory allowance.
If you have got access to a least square curve fitting package it may be able to find you a moderately simple mathermatical function that you can fit to the waveform by adjusting two or three parameters - many real impulse signals can be fitted as an exponential decay (where the exponent is complex, in the sense of including imaginary numbers).
Whether you can then generate the function in the remaining bytes of RAM is an open question.
Or better yet, use one of the many 8051 like chips that has 64K or so of code space. The 8051s can nest subroutines more than 40 deep. This would allow a lot of reuse of segments of the curve with fairly simple coding.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.