How to digitally record a 10ms pulse then stretch it out into audio in real time?
ElectricAye
Posts: 4,561
I'm wondering if the Propeller can do this. Or if it can do this with a few external components such as ADCs or whatnot.
Let's say you are detecting bursts of data, one burst about every 10 seconds. In real time, each burst is about 10 ms long. If a device could digitally record and then immediately play back each burst slowed down by a factor of about 128, then each burst would be in the audio range and become intelligible to the human ear. Slowed down, the audio signals sound like they are around 1KHz to 5KHz.
So in real time, running continuously, the Propeller would have to do something like the following:
1. Perform an ADC of a burst when one occurs.
2.Store the ADC data somewhere.
3.Play back the ADC data into a DAC at a speed about 128x slower.
4.(optional) If a new burst appears before the previous burst is finished playing, then the new burst interrupts the older one.
Is this terribly difficult to do? Any chance it can be done for less than, say, $50???
Thanks
Let's say you are detecting bursts of data, one burst about every 10 seconds. In real time, each burst is about 10 ms long. If a device could digitally record and then immediately play back each burst slowed down by a factor of about 128, then each burst would be in the audio range and become intelligible to the human ear. Slowed down, the audio signals sound like they are around 1KHz to 5KHz.
So in real time, running continuously, the Propeller would have to do something like the following:
1. Perform an ADC of a burst when one occurs.
2.Store the ADC data somewhere.
3.Play back the ADC data into a DAC at a speed about 128x slower.
4.(optional) If a new burst appears before the previous burst is finished playing, then the new burst interrupts the older one.
Is this terribly difficult to do? Any chance it can be done for less than, say, $50???
Thanks
Comments
The Prop would need some help. If you want 5Khz you need to sample > 10KHz and that is the /128 playback, so the record side needs to be 1.28MHz - so an external ADC will be needed.
I take it you have already got a microphone that good ?!
That could stream into SPI SRAM, or maybe into On Chip Memory, if you want to be more frugal.
An advantage of on chip memory, is you can play back on one COG, as you record on another.
A playback DAC at Audio Speeds should be OK.
-Phil
The original burst signals don't come via a microphone pickup - the bursts are just analog signals resulting from an instrument. But by stretching out those signals in real time, the resulting audio signal might allow a person to monitor things and get a feel for what's happening rather than having to stare at a bank of boring ever-changing numbers.
Interesting! Thank you.
Phil, that sounds great. I'm guessing this wouldn't need very high precision - just enough to run a DAC well enough to make some varying tones. When stretched out in time, the resulting audio sounds a little bit like "whistlers" you might hear on some radio frequencies. So do you think a single Prop would be able to run a sigma-delta conversion, somehow store enough of that data (where? how?), and yet still be able to perform a DAC, too? Thanks!
If you follow Phil's lead, you can sample at 1.25MHz to ~6 bits, and pack 5 samples into 32 bits, to write at 250000/sec into HUB Memory.
10ms at 1.25MHz is 12500 samples, but you gain a little bit from 6/8 packing so need 9375 Bytes per 10ms.
A full memory load would store a tad over 30ms.
One COG records,and another COG plays-back.
Awesome! That's really cool. Thanks for the insight on this. It's fascinating this one chip could do this!
By chance are you using ultra sonic as your input?
Hi Beau,
no, it's actually for a radio monitoring application I was asked about. But it seems to me that developing some sort of signal stretcher like this could have uses in a lot of different applications. It's a lot more fun to listen to signals that sound like something rather than just "kkkkkkctkkk" on a speaker or numbers on a terminal.
Reason I ask, is because when I worked in prosthetic research and development we submitted a grant proposal for a device to assist the blind.
Essentially recording the ultrasonic signature out to about 15 feet, and then audibly playing it back at a lower (adjustable) speed. This was about 17 years ago, so most of the device was made with discrete IC's and a few FPGA's and micro controllers.
So... I would think the Propeller could do something like this in it's sleep with very minimal external component support. ... I think what you must decide on first is the quality of audio your willing to settle with and work backwards from there as far as memory and speed requirements.
Sounds interesting. (No pun intended.) So was it like the audible equivalent of a radar beam sweeping over an area - and the blind person sorta heard the "terrain" in front on them as the beam swept across or something? My only motivation is to provide something audibly interesting to an otherwise boring monitoring process. When you're trying to impress somebody with your tests and the only thing they hear is "kkkkcctttkk", then you tend to get a lot of "Is that all there is?" But if the signals sing a little, and reveal some of their character, I'm hoping it will help impress the unwashed masses of humanity who might otherwise ignore such otherwise earth-shaking test results.
An ultrasonic sensor just 'looked' straight ahead. Contrary to popular belief there is data (sound reflections) after the first echo. <- most everyone stops there. One of the key devices, popular in radio receivers was an Op-Amp with a reverse log amplification. This key element effectively linearized what would normally be a decaying (proportional to distance) signal from the ultrasonic sensor. Instead, it was more like a cliff at about 15 feet out, but up until then the signal was relatively linear.
To output a 5KHz signal from that incoming 10mS signal would require sampling at 1.28MHz and produce 12800 samples.
10 bits of resolution would be the most you could store in the prop's hub ram based on the incoming signal and the 128 speed factor.
The output audio can be easily handled by the prop but it might be worth considering one of the 12bit serial (I2C) ADC's ($2 – 3 dollars) capable of higher sampling rates for the input side.
-Phil
Given that the signal we want to perceive here is not music or speech but rather some horrible squawks from a machine one might never notice the difference between 6 or, say, 12 bits.
in the past I have done some sound processing with the prop. You will need to use pasm or a compiler. I used PropBasic.
I would recommend to use an external ADC. The onboard ADC does not deliver its calculated number of bits as resolution. I want to say there is some amount of noise.
There was a Parallax Oscilloscope using the Propeller. I don't have one but I think this could be hacked to do the job?
Good luck, Christof
It records via microphone and then plays back later...
Parrot_8bit.zip
That's right, fidelity is not a big issue. It's just a matter of getting a general sense of things.
Hey, this sounds like fun. Thanks for the code!
My mistake, that should have been SPI, not I2C, and there are several inexpensive serial and parallel 8, 10, and 12 bit ADC,s available that would handle that sample rate. In many cases the 12 bit ones are less expensive than the 8/10 bit ones.
If I were looking at doing something like this I would probably go for a 12 bit parallel ADC even though I may only use 8 or 10 of the bits. It makes for much simpler signal acquisition code.
http://www.mouser.com/Semiconductors/Data-Conversion-ICs/Analog-to-Digital-Converters-ADC/_/N-4c43gZscv7?P=1z0t28rZ1z0w0s5Z1z0vywfZ1z0w0o4Z1yzrz6v&Keyword=SPI&FS=True&Ns=Pricing|0
Okay. Makes sense to me. But I'm guessing I would need some sort of external memory to help store data before it gets played back. Any suggestions on what's fast enough to do that? jmg suggested SPI SRAM. Do you think the Prop could manage all the reading/writing/reading that would be necessary in real time using 12 bits?
Hey thanks! It's a nice resource.
If it can be "heard" real time, there are techniques suggested for Bat Detectors...
The-Bat-detector-from-Nuts-and-Volts
Audio-Frequency-Shifter-Hear-your-PING!
If you were using 8 or 10 of the 12 bits you could pack 10mS of data into hub ram but for 12 bits you would need external memory. Personally I would go for external memory. It does not add much cost and makes the resulting circuit more flexible.
I have not used the quad serial SPI ram chips yet so have no actual experience with them, but from the data sheets it sounds like they would be ideal for this application. Once set up the propeller only needs to output the data and clock signals to the chip.
Ideally, you want a Continuous conversion ADC that does not need extra trigger pins - not easy to find.
20MHz gives 16-clock frames at 1.25MHz, and the prop can give a 20MHz CLK, which is the SPI RAM limit.
Devices like the ADS7883/4/5 show some of the fish-hooks : SPI and 3Msps and an ok price...
but it has a CS/Start pin, with strict duty needs, and has a 16 clock frame..
The AD7276 looks is slightly more tolerant, but that timing still looks a challenge.
The Prop Counter module can also output carry pulses, which will be 12.5ns wide, at any rate you choose, so /4/16 would give the 1.25Msps trigger, but the AD7276 data is vague if that is legal.
I think it is ok on tQUIET, t1, t2 - something that would need a bench test methinks.
Then the phase of the CS and CLK will determine the offset of the data blocks in the SPI stream.
The Prop has no atomic control of both Counters, but you may be able to start them in a known phase with care.
CS without CLK looks legal so perhaps Start CS, wait-SW-sync on that, then start CLK, and it may be the first field is discarded.
Play back has to ping-pong with record.
The CLK line is SW controlled to prime the SPI memory : set address and write command, and then ready for whatever trigger you use to flip into Hardware control of SPI CLK.
OMG, my brain just exploded!
http://www.digikey.com/product-detail/en/AD7822BNZ/AD7822BNZ-ND/996997
@jmg, I'm still recovering from information overload in your previous post, still taping my brain back together. If I knew only half of what you were talking about, I'd probably feel compelled to get a real job for once.
It may not be 'faster', but is it likely to be easier to get working.
Ideally, you want an ADC that gives a new result, per clock, and does not have complex hand shaking.
ie The TI ADC1175 may be easier than that AD7822
ADC1175 says this
Data is acquired at the falling edge of the clock and the digital equivalent of the data is available at the digital outputs 2.5 clock cycles plus tOD later. The ADC1175 will convert as long as the clock signal is present at pin 12.
I did warn it was pushing into the realm of tricky, and of some fish hooks, but not impossible...
Thanks. I definitely need to start simple on this.
FF
FF