• Am able to send data from visual studio program to the Arduino but the response is still not working for some reason.
• Need to find a proper 15+ watt amplifier, which can be controlled digitally, for the bass shakers.  Once I find one we can order those and the other 1 watt transducers.
• The main Arduino sketch is now in RCS controller format but still needs many of the functions filled in as well as the communication stuff I am still trying to work the bugs out of.

Tones and Speakers:

• Chords, although bad sounding, are much louder and vibrate more then single tones.
• 1 Watt may not actually be enough power for what we are trying to do.  Both the mini-speaker and the hacked cone-less speaker have the same volume.  The hacked speaker provides more vibration but too much pressure on the voice coil stalls it.
• A speaker with high sensitivity like the ones in my sony headphones might be good.  They can produce over 100db with 30mw of input.  The low power makes me think these will still stall, not vibrate enough, and if you remove the cone they will be quiet.
• I did not see these when I was looking for transducers before but these may be perfect: http://www.parts-express.com/pe/showdetl.cfm?Partnumber=300-379.
• Not sure how we would power them or what amplifiers we would need but these may be good for providing a thump on initial contact: http://www.parts-express.com/pe/showdetl.cfm?Partnumber=300-388

Comm:

• BYTE as defined by windows.h is an unsigned char.  It is also defined in the standard arduino library.
• Sending commands for each step of volume is slow.  Its better to send the change in steps and let the arduino handle it.
• Notes from conversation with Phil:

COMMAND
INIT
SETVOUME
PLAYSOUND
MUTESOUND

RESPONSE
ECHO SERIAL STATUS
EXECUTING
DONE

COMMAND ARRAY:  COMMAND, SERIAL, DATA (3 Bytes)

• Cleaning up arduino sketch an rewriting the parts from the examples.

Tone Generation:

• Tried to get this working on my desktop but then remembered my sound card was fried and I was using the mobo one.  The mobo doesn’t support sound output recording.
• Considered getting a new sound card but they were all expensive
• Tried again with my laptop.  Took a couple hours of deleting and reinstalling the drivers and restarting the computer a bunch of times but eventually got it working with “Stereo Mix.”
• Started Recording various tones.   I think square tones will be more useful then sine tones.  They seem to have a more gritty tone to them which may help vibration.
• Software used:  NCH Tone Generator(producing tones) and Audacity(Recording)

Arduino Sound Controller:

• Got the amplifier working.  There were a couple wiring problems, need to look at the diagram better next time.
• Used oscillator chip to test the amplifier.  Speakers seem to peak out much lower then advertised.  Oscillator frequencies may not work as well as actual sounds since this is a speaker as opposed to a buzzer.
• HIGH_SIGNAL(high resistance) may be out of range.  Does not seem to be consistent when I decrease the Volume.
• Step speed is good.  It should not be a problem to send it varying step commands quickly during collisions.
• Will try it with the SOMO tomorrow.

Arduino Audio:

• Some commands need two bytes of data sent from the computer to the arduino.  For these commands I added a serial.read() after they happen to get the second byte.
• Mostly done with the sketch for audio control.  Only a couple more functions to code.
• Once I get this working I will try to read the strain gauge amplifier with the arduino.

Arduino Audio:

• Got the SOMO working.  Had to move the 3.3volt power leads closer to the SOMO on the breadboard and put in 2.2k resistors on the serial lines.
• Tried out the new speakers.  Its a bit quiet using the built-in SOMO amplifier.
• Working on combining code from SOMO demo program and my volume controller so I can use the amp.
• Only using the functions I need for the SOMO to keep it optimal.
• Eliminated some of the delays that are only there for direct user interaction.
• Shortened delay in command send to 100uS down from 200uS
• Have not tried reading the force signal amplifiers yet.  Should be pretty straight forward.  Will try it once I get audio working well.
• Tried to get the add-on for Visual Studio to work but I cannot find the add-on folder in any of the places it should be.  Oh well,  the arduino software is okay I guess.

Other notes:

• Yet another idea of mine, being worked on by someone else:  http://www.macotakara.jp/blog/index.php?ID=11085
• It is a bit better then my idea because mine would have required head mounting.
• Oh well eventually I will think of something unique….  Haven’t seen anyone doing my math app yet (keyword yet…).

• Finally got I2c to work.  Not sure if it was just addressed wrong all this time or if I fixed it when rewiring.  The address used was 0x2c.  I am pretty sure I tried this before which is why I think it was the wiring.
• SOMO won’t work right now.   Wanted to test the speaker but somethings wrong.
• Wired one speaker so its good to go when i figure out why the somo isn’t working.
• The first time in order to got it working, there was a problem with the serial lines not having a resistor on them.   Pretty sure it should be 2.2k on each line.

Eliminating the need for i2c-usb module:

• Switched the rheostat(AD5243) circuit to use the Arduino power source instead of the usb module
• Added commands to the Arduino sketch to control the rheostat
• Learned how to use the wire library to transmit data to rheostat.  One trick with the library is that the read/write bit is handled by the arduino so the first byte needs the right most bit removed.  After that data bytes can be sent in standard 8 -bit format.
• Two main benefits of doing this:

1. Only one com port to worry about.  When you have more then one, it can get complicated when switching machines because you’ll have to keep track of more randomly assigned ports.  There are ways to use port enumerators which scan the registry but this seems like it may be unreliable at times.  The other way to alleviate the problem is to add custom drivers but at this point that seems like more work then its worth.
2. The other benefit is that, you can send 16-bit string commands to the Arduino to trigger the command pattern.  This simplifies the implementation in the actual control system.

• Pretty sure the sketch will work but I have not tested it yet.

Arduino – SOMO interfacing:

• Hooked up the SOMO with a 220uf capacitor on the power supply going to ground and put one 2.2k resistor between the arduino pin and the SOMO pin for each of the serial wires.
• First memory card(PNY) was not compatible.  Needed to get a sandisk 2gb uSD.
• At first i had the speaker hooked up directly to the SOMO.  This produced good sound but had far less range with only 7 steps.  Once I knew this was working I put the output wire through our amplifier.
• The piezoelectric speaker that i had from my computer motherboard is really only designed for tones so it might be blown.
• Eventually I am going to have the i2c resistor controlled through the arduino instead of the FTDI chip we are using.  I am not sure how often this will happen but there was a conflict with the com ports.
• Spent a good amount of time trying to find the best speaker for the job.  Eventually I found these: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=668-1206-1-ND
• 13mmx13mmx4mm is a good size for fingertips and we probably embed them into the surface of the next prototype(if that is not insanely hard to do).  They get up to 85db which is about the same as someone singing loudly so that should be good.  Not sure how much it resonates, but we can probably increase that through mounting techniques.
• Tomorrow, I will start working on the rcs system code to prepare it to work with our original prototype so we can test this method.  A lot of its already written, just have to add the SOMO commands and fix the parts that I couldn’t test before.  We can probably use our big cone speaker while we wait for the fingertip sized ones.

Aurdino – SOMO 14D interfacing:

• Serial communication is a bit more difficult then I thought it would be because the SOMO does not follow any standard protocol.  Instead you have to time the clock cycles and data timings manually.  Luckily someone has translated the 4D Systems sample code to work with the arduino:  http://forum.sparkfun.com/viewtopic.php?f=14&t=21388
• The code doesn’t do exactly what I want but the main important part is the sendData(int) function:

1. void sendData(int ThisSong)  //it says this song but it can be any 16 bit command
2. {
3. int TheSong = ThisSong;
4. int ClockCounter=0;
5. int ClockCycle=15;//0x0f;
6. digitalWrite(pinClock,HIGH); // Hold (idle) for 300msec to prepare data start
7. delay(300);
8. digitalWrite(pinClock,LOW); //Hold for 2msec to signal data start
9. delay(2); //2msec delay
10. while(ClockCounter <= ClockCycle)
11. { digitalWrite(pinClock,LOW);
12. if (TheSong & 0x8000)
13. {digitalWrite(pinData,HIGH);
14. }
15. else
16. {digitalWrite(pinData,LOW)
17. }
18. TheSong = TheSong << 1;
19. delayMicroseconds(200); //Clock cycle period is 200 uSec – LOW
20. digitalWrite(pinClock,HIGH);
21. ClockCounter++;
22. delayMicroseconds(200); //Clock cycle period is 200 uSec – HIGH
23. }
24. digitalWrite(pinData,LOW);
25. digitalWrite(pinClock,HIGH); // Place clock high to signal end of data
26. }

• Considering there may be a time I will not have the code given to me, its best to explain whats going on here so that I know how to do this with just data sheet timings.

1. Lines 3-5 set up are pretty basic.  Declare a counter, declare a maximum, pass the parameter into the function.
2. Lines 6-7 set the clock to high for 300ms to ensure a data reset between consecutive commands
3. Lines 8-9 a two ms low tells the SOMO that the data stream will begin.
4. lines 10-23 is the while loop.  16 cycles for the 16 bits of data
5. line 11 sets the clock to low between bits.  The first run its already low so it doesn’t really matter but it doesn’t hurt to set it to low again
6. lines 12-17 was really confusing to me at first.   I am used to only using Boolean operations within if statements.  & is a bit wise function comparison function.  Instead of checking the whole thing to see if its the same it checks each bit and only produces a 1 when both are 1 and 1.  Every other combination produces a 0.  So by comparing the command to 1000000000000000(0x8000) you will only get a non-zero value(true) if the leftmost bit is a 1.  If its true it sends a high and false sends a low.
7. line 18 bit shifts left to test the next leftmost bit during the next cycle
8. lines 19-22 I am not sure why this has a 400us delay.  The total cycle period is supposed to be 200us,  high should be 100us, and low should be 100us.  I guess as long as its consistent and under 1ms it will work.  The two delays are in place to ensure the clock cycle takes at least 400us(it should be 200us).
9. lines 24-25 are just used to set the idle state.  A high on the clock line lasting more then 2ms stops that data transmission.  The data line doesn’t have to be set low during idle but why not.

• The 300ms delay(+20ms processing after command is received) between commands is a bit long.  Our amplifiers are much quicker(100ns per pulse cycle*steps) so this shouldn’t hurt response time too much except on initial contact.  I believe when you send the command for select track and it will auto play but if you have to do two commands to do this that would be over a half second delay…  I can probably minimize this by having a delta t function which measures the time between commands and delays the difference if its under 300ms.

Arduino – SOMO interfacing:

• Got a basic melody to play on the arduino by following this tutorial:  http://arduino.cc/en/Tutorial/Tone

• Was originally going to communicate with the SOMO 14D by using the push-button operations using the digital outs of the arduino because it only has one serial port.  There were a few problems with this approach.

1. Takes many digital outputs to control one SOMO
2. Cannot easily switch between tracks which are not right next to each other
3. Hard to control active-low switches without the use of a gate

• The solution is of course to use serial.  But one port is not enough for even a 2 finger prototype.  Lucky there is a way to make the other digital ports act like serial ports using the SoftwareSerial library.  An example of how this can be done is found here:  http://arduino.cc/en/Tutorial/SimpleSoftwareSerial
• Was not sure if the regulated 3.3 volt port on the arduino would work for the SOMO.  Found out it puts out 50ma and the SOMO’s peak consumption is 45ma.  This should work for one but we will probably need a 3.3v voltage regulator for any others.  Sparkfun(http://www.sparkfun.com/products/526) sells them so we can get them when we get the other SOMOs.  The ones sparkfun sells can output up to 800ma so one would be all we need to power all the SOMOs.  I think a decoupling capacitor on the power input protects the circuit from receiving too many amps.  The wiki article was a bit confusing on this matter.  I will read it a bit more in depth and ask Clift if I can’t figure it out.
• An interesting article on unregulated power supplies: http://www.sparkfun.com/tutorials/103
• Formatted uSD to have 16-bit fat file system.  Also changed some music files to .ad4 and copied them to the uSD.
• Should be ready to wire up the SOMO tomorrow.  The SOMO data sheet is poorly organized which has held me back a little bit.  I do not want to fry the thing out of carelessness.  Hopefully our memory card works, its not on the definitely doesn’t work list so that is good.

MISC:

• You can now scan to email with the printer.  The e-mail portion wasn’t working before because they changed the server after we moved here.  Now instead of using mail.fgm.com:25 we use spam.fgm.com:25.  This is the only easy way to scan documents for Windows 7 machines which do not have the HP Solution center software yet.

Finally have the Arduino, capacitors, and the SOMO 14-D.  Still need to figure out what micro-SD memory card to get for the SOMO as not all are compatible.

Computer Controlled Amplifier

• To reduce number of problems, the oscillator circuit will be used to produce the sound.  Later this will be replaced with the SOMO 14-D.
• Fried first amplifier because I had the pin numbering wrong.  Pin numbering on ICs is numbered down on the left side then up on the right side.  For some reason I thought it was down on both sides and got the VCC and GND pins reversed causing smoke.
• The capacitor used to filter the audio signal is not supposed to be polar but a polar capacitor will work as long as, the positive side is on the pin and the negative side goes to the audio source.  This seems strange considering the direction of the current but when I had it the other way no sound came out.  Luckily the audio signal isn’t strong enough to blow the capacitor.
• Switched piezoelectric speaker with regular speaker to make sure it wasn’t causing problems due t it having a higher resistance
• Realized that when the amplifier was changing volume the sound light sound would cut off.  I figured this was due to lack of power.  Took the whole circuit off the i2c-usb controller’s power and onto the power supply.
• Was not able to change the resistance on the the rheostat chip.  Realized that all i2c controlled chips must be grounded to the i2c controller gnd.
• Test class worked for controlling volume!
• The amp has to be muted digitally in order to get absolute silence.  The piezoelectric speaker, due to having a higher internal resistance, can be adjusted down to being “muted” without having to control the mode of the amplifier.
• The piezoelectric speaker seems to work well.  Not sure how good it will be for playing sounds, instead of tones.  Need to find out if I can get samples of those tiny speakers I mentioned in a previous post.

Arduino

• Considering part of the goal is to reduce the number of usb devices(not a very important goal but still), the mega would have probably been better then the Uno.  That said, the uno should be useful to see if it will work for our application, and should have enough outputs for a two finger prototype.  Another advantage of the mega is it can speak i2c which would eliminate the need for the usb-i2c adapter.  However, if I find its better to control the mute function on the amplifier with the second rheostat on the variable resistor chip, we will need two i2c channels in order to communicate with 5 amplifiers.
• Before I attempt to get the Arduino to communicate with the SOMO 14-D, I am going to try some basic tutorials to make sure I understand how to program it.

Speakers

• Spoke to a representative at Murata to see if we could get samples of the VSLBP2115E1200-T0.  He directed me to a local distributor Glen White Associates(434-385-6110).  He also said that the Speakers should be used with a audio amplifier for ceramic speakers.  There is no problem with using a regular amplifier but it may not be loud enough due to the higher impedance.