Advice sought on feasibilty of sound effect module (20X2 & serial EEPROM)


For some time I've been looking at making a sound effect system for model boats utilising recorded sounds - horns, guns, bells, asdic whoops etc plus repeated loops for engine sounds, clocked out at a variable rate proportional to the throttle setting. And yes, I know the latter doesn't necessarily work very well with all engine sound samples but a few minutes experimentation with Audacity will sort out the candidates that do work tolerably well. A huge library of sounds are available on the web in WAV format.

You can see my efforts at synthesizing an engine sound with the PICAXE here Those who are interested can follow a link from there to our boat club website where you'll find the code.

I decided at the outset I'd like to represent the sound waveform as a serial bitstream so that the D/A conversion was really cheap and simple - an RC filter. To that end I wrote a VB6 program to implement a software delta modulator to encode a WAV file into a serial bit stream and it allows me to play with the sampling rate to (experimentally) get the best compromise between conversion accuracy and file size (see attached)

I had planned to use up to eight different 1-bit sound files in a conventional 27 series 256Kx8 EPROM (file1=D0, file2=D1 etc) and use a binary counter to gallop through the addresses and an 8 way multiplexer to select which data stream was switched to the RC filter.

I was following the above hardware approach as I considered (but correct me if you think otherwise) that an 08M at 8Mhz and and a serial EPROM would be nowhere near fast enough to generate audio output. Web research shows it has been done with assembler, but I reckoned with intepreted BASIC it was a non-starter.

But having bought some 20X2s for their 11 ADC capabilities, I've been studying the command sets and now wonder whether it might now be possible to implement this project in PICAXE after all. But this is based on two observations made by someone who has never used the SPI !

(1) the 20X2 can be run at 64MHz.

(2) there is a (h=hardware?) "hspiout" which is "faster and more efficient" than the bit-banged "spiout"

It seems the data is shifted out in bytes, but a hardware parallel to serial conversion would be no great heartache (I note the "spiout" has the option to shift out a defined number of bits which could be set to unity)

With the example WAV file shown of duration 1.4 secs at 16x oversampling, 172K samples have to be output in that time which equates to 123Kbits/sec or 15.3Kbytes/sec. At 4x oversampling the RMS conversion error is still only a couple of percent which may not sound too terrible in this lo-fi application so the above rates could be further divided by four.

So gentleman, I seek your advice - the best way to get EPROM contents to the 20X2 pin or (8) pins and a maximum sample rate I could expect. BTW, the time taken to load the data into the EEPROM is of no consequence in this application.

Thank you in advance for the undoubtedly erudite comments that will follow!

(yes, I know I could spend £100 plus and buy a real one, but where's the fun in that!)



Senior Member
For non-repetitive sound effects (horns, guns, bells, asdic whoops etc,), what about using the SOMO-14D embedded sound module? Relatively straightforward to call up sound files stored on a µSD card, and not too expensive at $25. The westaus55's thread in User project - Audio/Visual.

However, it is not going to be fast enough to retrieve consecutive sound bites for repeated loops for engine sounds. Perhaps something like an ISD2560 sound chip could achieve this, but they are getting hard to find since they are no longer in production. Interfacing with a PICAXE is quite straightforward, but getting the sounds stored in the chip is somewhat challenging.

I have some code and PCB layouts for both of the above. In my case I select the sounds vial a 12 position switch/voltage divider and ADC input. It would be easy to use the pulse width from an RC receiver instead.

Another option for the engine sound effect could be a sound effect generator. I used one many years ago (SN76488N from Radio Shack), and seem to remember being able to generate quite realistic turboprop sounds, including changing engine speed. I do not remember the chip designation, but various mixers, VCO's, noise generators, oscillators and ramp functions were implemented.


Senior Member
123kbps is about 8us per bit, 64us per byte, and the simplest 20X2 command at 64MHz takes around 32us to execute. Even though you may be able to churn in the bits from Eeprom and churn them out via SPI at the required rate you may not be able to execute the commands fast enough to do that.

Rather than try and theorise what throughput you might get the simplest thing seems to be to try it.

#Picaxe 20X2
SetFreq M64
HI2cIn 0,( b0 )
HI2cIn ( b0 )
HSpiOut ( b0 )


Senior Member
The 20X2 does have a limited DAC capability which could slash your needed throughput. It needs to be buffered and only has 32 levels of resolution but may be good enough. You'll need to consult the Microchip 18F14K22 datasheet for further details.

#Picaxe 20X2

Symbol VREFCON1 = $BB
Symbol VREFCON2 = $BC


Symbol D1EN = bit7
Symbol D1LPS = bit6
Symbol DAC1OE = bit5
Symbol D1PSS1 = bit3
Symbol D1PSS0 = bit2
Symbol D1NSS = bit0

D1EN = 1 ' DAC is enabled
D1LPS = 0 ' Negative low power select
DAC1OE = 1 ' Enable output to leg 19, A.0
D1PSS1 = 0 ' Select +V as max
D1PSS0 = 0 ' Select +V as max
D1NSS = 0 ' Select 0V as min

PokeSfr VREFCON1, b0

b0 = 0
PokeSfr VREFCON2, b0
b0 = b0 + 1


Yes I had spotted the thread on the SOMO-14D a while ago. It seemed there were some issues with conversion to ad4 format and memory card compatibility which rather put me off at the time. It's rather more expensive here too - over GBP 20. For well under half of that I've been using a 'hacked' mp3 stick player with two different mono sound files on the two original stereo tracks. It works but is a real kludge.

After searching the SOMO down again today I also discovered an offering from Sparkfun - the "mp3 trigger" which (at greater expense still) is even better suited to my particular application. It would be worth checking out if I eventually decide to go the 'system building' route. Unfortunately neither of these products meet the requirement for seamlessly looping a (engine sound) sample and varying its pitch.

I've already visited the ISD2560 and but the results weren't something I could be very proud of. A hissy one second delay before the sound starts (feature of the 'answering machine' mode of operation) and very fiddley to try and terminate recording so there isn't a trailing period of hiss (and that is line-in recording with the agc turned off). Perhaps you had better luck with it but as you note the part availability is difficult so I'm not inclined to pursue it.

I've already had a good crack at synthesizing engine sounds (see the link in my original post) and am keen to try and improve things by using recordings of the real thing now.

But thank you for taking the time to pass on your wisdom and experiences. I may come back to you yet!

Thank you for trying to quantify the possible speed of data transfer for me. I'm sufficiently encouraged to knock up a test circuit (when I've sourced an EEPROM) and experiment along the lines you suggest. As I said I have no previous experience of SPI so I'm accepting the setups in your 18:17 posting and assume that after the first defining fetch from address 0 that the address pointer automatically increments with each successive fetch? And it rolls round at the end of memory?

I'm grateful that you were still thinking hard and came up with the further suggestion in your 19:54 posting. That would need a lot of studying of the Mikrochip datasheet I'm sure, but in general terms I'm at a loss to see how utilising an internal DAC facility speeds up the throughput in comparison to using external hardware parallel to serial conversion and RC low pass filter DAC which have no impact on the 20X2 software execution (other than the enforced reduction from 8 bits to 5 bits - but that is an option for the first approach anyway).

I'll be sure to keep you both informed of my progress - or lack thereof! Thanks again guys.