16-bit sample & store, then readback & play, finally store to SD

(working past each other a little here...)

Well, I want to make an electric drum set, so the sound has to start playing as soon the drum is struck - can't really have any latency. Each drum card would only play 1 sound at a time. Playing like 20 beats per second, need to hear the initial strike from each hit, so a new sound to start playback at 22.7uS rate every 50mS. I suppose that's enough time to add say 4 samples from different times together and send to the DAC? Vs having 4 DACs and mixing them in analog realm. I couldn't envision doing that before, too complex a design with discrete logic chips. Not sure how it would sound either. Snare drum dies out quick, but tom-toms go longer, might just turn into a long rumble. I suppose I could force ongoing sounds to be quieter quicker as a new one starts. Not really sure how best to take advantage of the 1284 RAM. You think each 1284 could control several DACs at one time? So maybe 2 or 4 sounds at one time? This is getting farther along than what I was thinking was possible with 8 bits at 16 Mhz. Every 22uS, (transfer 2 byte from SRAM, to 3 bytes into the DAC,) * 4, = at 0.5uS/byte raw speed = 10uS, and if add some math to combine the sound... Hmm ,that's not going to leave time to capture the input level and multiply it accordingly before doing the adding. If I do it simply, say 1 of 8 levels, that's just shifting the data to the right by a bit to cut the sound by 1/2 with each bit shift, yes?

These guys will purchase & install the little SMT chips onto DIP adapters for a couple dollars on top of the chip price. http://www.proto-advantage.com/store/product_info.php?products_id=2200091 I have no confidence I can solder the little pads of the SOT-23-8 and MSOP8 parts myself and have them be functional afterwards.

If you think the AD5662 can be a good match with an SD card for sampling playback (pair up with AD7680 to capture samples & listen to immediately, then play back with drum strike from SD card or from SRAM) I'll order a couple of each and have them mounted so I have something to start testing. The Vref chips too.

First, I have attached a new version of the capture record/play prototype. It now has test functions for the AD5662 DAC.

See the readme.txt file for more details.

Looks like the AD5662 DAC and AD7680 ADC will work fine with an SD card.

You think each 1284 could control several DACs at one time? So maybe 2 or 4 sounds at one time?

I don’t think you can control more than one easily.

The only possibility would be to put the DACs on the two serial ports running in SPI mode at 8 MHz and the SRAM on the SPI port. You would need to read blocks from the SRAM to avoid the large overhead of sending the four byte instruction/address before reading data.

I can read large blocks from the Microchip SRAM at about 700 KB/sec.

It might be possible to send the six bytes required by two DACs from a timer ISR in a few microseconds. The serial ports have two bytes of buffering which would help.

I don’t think the AVR can do any “signal processing” like adding samples.

CrossRoads6Aug.zip (10.3 KB)

Any interest in an option to record a Wave format file? It could be a compile time define.

Wave is signed so the driver for the ADC and DAC need to complement the high bit. Zero is then at the middle of the range. There is no overhead for this in a bit-bang driver.

A Wave header needs to be added at the beginning of the file.

Having .wav format would likely make it easier to edit/manipulate on the PC, yes? Would that change the ADC required? Or just manipulate the data saved (driver change?) to subtract 0x8000 so that 5V is saved as 0x7FFF, 2.5V as 0,and 0V as 0x8000? (think I have the math right -5V: FFFF-8000 = 7FFF, down to around 2.5V: 8001-8000=1,8000-8000 = 0, 7FFF-8000 = FFFF, and then down tp 0V: 0-8000=8000).

Same ADC and DAC.

You just change how the high bit is handled in the driver. You complement the high bit. It will not change the execution time.

For ADC read you use this for bit 15:

  if (!fastDigitalRead(ADC_SDATA_PIN)) v |= (1 << b);

And remove the ‘!’ for the other 15 bits.

  if (fastDigitalRead(ADC_SDATA_PIN)) v |= (1 << b);

I wrote a “loop back” program that sends each value to the DAC, waits a few usec for the DAC to settle and then reads the value back with the ADC and write the result to a file.

My 12-bit breadboard setup seems to have a lot of noise since the ADC and DAC reference is just the Mega 5V.

I get 16 samples for each value with my 12-bit parts. I attached a plot of the result (divided by 16) for high values, near 4095 for 12-bit parts.

I removed the 7.4 units of offset and calculated the rms of the noise. It is 3.7 ADC uints or 4.5 mv. There are some nasty spikes.

I did a run where I averaged 64 readings at each step and the noise goes away.

LOOP04.pdf (89.5 KB)

LOOP04noise.pdf (89.1 KB)

I did the Wave option. I lifted most of the code from my Wave Shield library.

Three short files are attached, SINE440.WAV, SAW440.WAV and SQUARE440.WAV.

I recorded theses files with the MCP3201 12-bit ADC using my function generator as the source.

Seems to work, they play with Window player and QuickTime.

I looked at them with Audacity and they seem O.K.

Let me know when you have hardware and I will post the current version of the code.

SINE440.WAV (163 KB)

SAW440.WAV (161 KB)

SQUARE440.WAV (156 KB)

Oddly, I find the saw wave most pleasant sounding on my laptop.

Ok, I've got SMD parts assembled onto adapters ordered via www.proto-advantage.com. One of the Voltage references is backordered, their website only allows ordering of digikey instock parts, and not factory instock parts. Had to make a couple of calls to get that figured out. Was seeing instock, the word 'factory' not sinking in. Expect to have parts to play with next weekend.

I have attached the program, CrossRoads.ino, that records and plays 16-bit 44.1 ksps Wave format files.

There are now three debug sketches.

ScopeADC.ino - Basic ADC test that reads the ADC in a loop and prints the value to Serial.

ScopeDAC.ino - Basic DAC test that sends a counting pattern to the DAC.

LoopBack.ino - Sets all DAC values, read ADC value, and writes the result to a CSV file.

See readme.txt for more.

PM me when you find problems/bugs.

CrossRoads12Aug.zip (16.3 KB)


*although way over my head… some of the stuff mentioned (buffering/saving first sample of track/file…etc)… seems like good info to (keep) read, & the right track for seamless/gapless playback on the Adafruit/Uno WaveHC lib. I’ve been trying to get/achieve.

Thanks, am just waiting for SMD parts on DIP adapters to arrive from Canada. Taking my son to college next Tuesday (not tomorrow) so depending on when they arrive and how help he needs packing will determine if I get any time to play. Need more hours in a day!

I started to experiment with faster play. It occurred to me that you may need to interrupt a file before the entire content is played.

Seems that simulating something like a snare drum would require both rapid start and stop.

I would like to stop the current track and start a new track in under 50 microseconds. I would see this happening in a pin change ISR.

The stop is a slight problem since the only official way to terminate an SD block read is to clock out the entire 512 bytes.

I can start the new track from the first 512 byte block in memory. I then need to clock the remainder of a block from the previous track, if any, and read a block from the new track in about five milliseconds.

Looks like either the DAC needs to go on a serial port in SPI mode or two blocks of the new track need to be stored in RAM.

I have been testing use of a serial port in SPI mode. Looks like a great solution, it's really fast to send data to a DAC this way.

Any guidance would be appreciated. I looked at an article on recording a drum kit and was amazed at how many issues there are.

Recording, I would think not so hard, just planning to strike once & capture it. Clean up sound on PC to remove dead time, etc. Playback, Yes, snares need to be fast, something like 20 beats/second. 50mS between starts. Need to look on a storage scope again to confirm, might be even faster. Trying to count while I tap my fingers, can't do it! Pretty fast. That's what lead me to thinking SRAM originally - source is always there, multiple DACs might allow playback from multiple places at once. I think with serial data 8 MHz throughput rate might kill that idea, with parallel got 16x more time to play with.

I am not worried about recording, that should work fine.

I think it will be easy to start/stop fast enough in playback with one DAC from an SD. It will only take a few microseconds to switch streams if the first 512 byte block is buffered in RAM. You just need to change the buffer pointer and buffer index so the timer ISR will read the new stream. You then have 5.6 ms to read the next block from the SD.

I think two streams with two DACs will be possible with SRAM. I have not ruled out two streams from SD.

I have a DAC driver for the AD5662 using a Serial port in SPI mode that pulls CS low, sends three bytes, and pulls CS high in 4 usec.

The bit-bang driver takes just over 12 microseconds. This means that it should be possible to use two DACs on the serial ports with less CPU time than the bit-bang driver and one DAC.

Amazing! You can't use any of the Mega serial ports in SPI mode! None of the clock pins are brought out to a header.

The clock pins are:


The Arduino company decided not to connect any of these chip pins to a header.

I have been experimenting with an Uno which has XCK0 on PD4.

Is there any problem with using Serial port 1 in SPI mode for DAC on your 1284 board? TXD1 is PD3 and XCK1 is PD4 on 1284 chips.

Guess I need a 1284. I have an ancient Sanguino maybe I can use that.

Edit: Got the old Sanguino to work and ordered a 1284P chip.

Got the ADC/DAC chips on adapters from proto-advantage. Just need a bit of free time. Want me to send you a 1284 board to play with? Or are you good with just breadboarding stuff?

Got the ADC/DAC chips on adapters from proto-advantage.

Great, I will be waiting for news.

Want me to send you a 1284 board to play with? Or are you good with just breadboarding stuff?

I have the 644P Sanguino working with mighty. I ordered two 1284P chips and a socket from Digi-Key. I may replace the 644P and I have everything else to build a simple 1284P board.

I have a SPI USART1 DAC driver working on the 644P.

It is really fast so I have attached yet another version of the software.

I am now going to optimize the SD read part of play. Performance is looking good for play. Play uses much less than 50% of the CPU with a 16-bit 44.1 ksps Wave file. I need do the instant start stuff yet.

Too bad people with a Mega won’t be able to use this code, a lot of users want seamless play of several Wave files. I wonder why The Arduino people didn’t bring XCK out for any of the four Serial ports on the Mega.

CrossRoads17Aug.zip (19.1 KB)

Don't know about the mega design process. Getting our son ready for college, driving him out Tuesday. Lot of little last minute stuff to find.

Bill, What do you think of this op-amp wired up per Fig 8 of this app note, with Vref the Mic/Line input, Vin at 1.125V, and Rf = 2Rg, so Rf = 20K and Rg = 10K,

Vout = Vin*Rf/Rg - Vref * Rf/Rg = Vin*2 - VRef 2 Set Vin to 1.125V, Vref say +/- 1.0, thus Vout = 2.25V +/- 2(mic input), so 0.25 to 4.25V output total.

This & AD7680 both powered from REF194 which is 4.5V, 30mA capable.

How would that play with converting to .wav format thru the AD7680?

http://www.ti.com/lit/ds/symlink/tlv2470.pdf TLV2472CP (dual op amp, 0-70C temp range; 2470, 2471 not in stock at digikey) http://www.ti.com/lit/an/sloa030a/sloa030a.pdf See Figure 8

I'm ordering some 3.3V regulators for '1284 kits (managed to order 5V regulators in 2 sizes somehow) so will get some of these op amps too. All I have on hand is older TL072, TL084 chips, and some other 1986 vintage parts, all bought for use with +/-12V supplies at the time.

It look good to me but I am not real knowledgeable.

I built a mic amp using a similar TI part, TLV2372IP, to record 8-bit voice quality audio using the AVR ADC.

Looks like your amp has lower noise and a similar gain-bandwidth number.

TI says this about the two devices:

The device has the SAME FUNCTIONALITY and PINOUT as the compared device but is NOT an exact equivalent. Vs range = 2.7 to 6V; 2.8MHz BW; RRIO