Sonsivri

http://www.soundracer.se/?p=98 (http://www.soundracer.se/?p=98) show a gizmo that output engine sound effect on FM radio.

I am interested on how it works, and wonder if I could put one inside my RC car.

I guess there will be two separate smart in the gizmo,
- an engine RPM reader that reads through the DC power line  and
- a midi player that plays appropriate sounds.

I am not well versed on car alternators and its subsequent filtering, would there be enough rpm noise carried over onto the DC line to be reliably extracted?

Next, am I correct in assuming MIDI sound being played? or would it be the same identical noise being played back on different interval that made the sound varies?

Scratching my head and slack jawed in this..
Par.

Yes, there is a bunch of noise on the DC line in cars, radios and other OEM stuff are hardened against these noises but even so many times addition noise suppression is needed in some cars when you get into non OEM equipment...


I highly doubt it's MIDI, it's no longer practical in this day and age for stuff like this...  My guess would be some sort of PCM wave (or proprietary codec, I have seen proprietary versions of ADPCM used on some of the cheap import sound effects chips currently on the market) hard coded in memory, probably multiple sounds banked something like an 'idle' wave and than the 'rev' sound that can be played back at different speeds to get the total effect with small sound samples...

For an RC car you have a speed controller signal you could tap off of if developing your own system for that use, that simplifies that part...  As for sound playback I would look into a simple PCM wave player and simply adjust the playback rate...  With some trial and error I'm sure something decent could be achieved without much hassle...  A lot of the playback speed testing could be done in a sound editing program on the computer with ease, and then simply ported to the device once it's all figured out...

I see they offer an Android App, you should be able to rip the sounds out of that and see how they are assembled, as well as basic program structure if decompiled...

Posted on: December 02, 2013, 03:52:21 03:52 - Automerged

---

OK you peeked my interest so here you go the decompiled source of the Android App...

All the wav files are in the 'res/raw' folder...

Thats Awesome CocaCola. 
Yes I did not think of PCM, not very much involved in music, my first thought is MIDI, but PCM would be much better.

Ok, will investigate more..  There ought to be a COB PCM chips in the marker for this..

You could just simply use an AM receiver tuned to the very low end of the band (no station frequency) and audio amp. Those are available as single chips these days.

I have come across a few from Asian OEM companies over the years, but I believe that since it's pretty simple to do yourself with a micro there isn't much demand as the memory requirements for PCM are not cost effective vs MP3 or other compressed audio in the mass market...   Also I have found most of the COBs nowadays are using a proprietary high compression codecs, or SD cards with FAT formatting, the FAT file system overhead can be problematic for real time looping and immediate file access, a 250-500ms delay is fine when you click the play button on a greeting card, but can be problematic when looping a file or fast switching between two files...  The proprietary codecs generally sound like greeting cards or toys, nothing convincing in an application like this...

Agreed, OTOH my knowledge of sound generation is dismally low.

 if the COB are cheap enough, it might save some coding headaches by having 3 or more boards working in turn, one is doing the NOW output, and the other two, one do the 500ms forward and one do 500ms backwards so you always have an overlap outputs.

Maybe it would work..

I have used the schematic of the Diesel Sound from TalkingElectronics site to create an engine sound based on the PPM (RC) signal. You can play with the components values until it sounds like (maybe) your motor. I put it in my RC tugboat in parallel with the ESC signal. Obviously you'll need a PPM to DC signal (PWM) convertor to create the variable DC needed to control the speed of the motor "strokes".

Though, one day I will have a PIC doing this job, as it is so easy to play sounds with a PIC. Time to find to do it, maybe this Holidays season.

You can use an ISD1820.. You can buy them as kits that cost very little and the circuits are very small... just grab the sound of an accelerating car off the internet somewhere and record it to the device, then hook the play button to a 5v source from the rc trigger... the longer you hold the accelerator on the more the little car will rev (as more of the track plays), when you take your hand from the trigger the sound will stop. Costs a few bucks and is good for some fun! should sound pretty awesome as you run it and drop it back etc

and all for under $10 for a pre built circuit from aliexpress!

ISD chips compression is optimized for human voice, get outside that frequency range and the compression really gets ugly and sounds horrible...  Honestly I wouldn't use one for anything anymore, they are a relic of their time, and there is no cost advantage over many of the newer options...  Don't get me wrong they had their time and they did the job but they are far inferior nowadays...

For example you can purchase an MP3 player module from China with an SD card slot for well under $10 nowadays, and get near CD quality playback...

Or you can build the most basic PCM/PWM audio player with a small PIC or AVR chip and an EEPROM for a couple of dollars, it won't be CD quality but it will sound better than an ISD chip...

Very interesting development.
Thank you for the inputs, more please.

I am starting to gather the voices to replicate the engine.
Cocacola' decompressed android sound is great to start at.

i made one not long ago. i just made a *.wav file and made it play faster over the original speed.
i used a pic 16F877a btw.

Care to Share?

Yes I would definitely be very grateful if you would share.

hello parmin, i think there exist a more cheapo option, an italian hobbys did a wav player using only a 12f1480 and an SD card...  i'll test in january ^^  but the page gives ya all the code:  (otherwise use the BTC algo from mr black)


https://dmitry.gr/index.php?r=05.Projects&proj=02.%20Single-chip%20audio%20Player (https://dmitry.gr/index.php?r=05.Projects&proj=02.%20Single-chip%20audio%20Player)

Tuco, sound player is not a big deal, it is the combination of the sounds that baffled me most right now.
Microchip also have MP3 player example on one of their PIC24 which playback sound quite convincingly.
I think a PIC 24 would be able to handle all the logic required, simultaneously with the extraction of the motor back EMF through the power supply line and I/O from the sound storage.

The requirements are as the engine rpm goes higher, the sound would need to be synchronized to match the engine noise, then as you slow down or use engine brake it must sound differently.

I think I have to make this project into 3 parts (if not more)
1. extract the engine (motor) RPM
2. select correct sound file to play for that instant in time
3. arrange the sounds to string convincingly without delays between the sound output.
and maybe
4. normalize the sound to output as even as possible.

Then the most difficult part IMHO is to classify and break the sound of an engine I wish to simulate into the sound files (like what extracted by CocaCola from the Android files). This require "golden ears" which I do not have.

Its going to be quite interesting :)

Posted on: 14 December 2013, 07:05:31 - Automerged

---

Forgot to add, recently Silicon Chip also have a V8 doorbell article that may help on this.

ok, i'll track the posts backwards to check the soundbits :)

As I stated above in my experience this is going to be the biggest challenge if a 'bigger' overhead file system is used on the storage device aka FAT...

For one client (proprietary project so I can't share) I hacked a FAT implementation down to the basics, it simply played files in the order they were put on the card, totally ignoring file names... There was still about a 250ms delay playing the first file, but I could advance to the 'next' file without much of a noticeable delay...  But, in doing this I skipped all the fail safes and checks that should have been done, basically the system would crash if the card wasn't perfectly formatted...  Also I was really only able to get rid of the noticeable delay when advancing to the next file, not when jumping around or even looping...  Maybe if I kept wasting time and optimizing the code or jumping into a bigger micro that had more resources I would have been to get that delay short enough, but due to time constraints, budget and target price I ended up skipping FAT and doing direct access from an EEPROM...