Go Down

Topic: Arduino Lightsaber (Read 388305 times) previous topic - next topic

billpealer

#135
Dec 04, 2015, 04:48 am Last Edit: Jan 27, 2016, 04:14 pm by billpealer
DJ, i can't even begin to understand till you post a sample of the code that interacts with the accelerometer.  if i had to guess, id say you have some noise in the PWM of the speakers,.. distorted how?  can you make a video?

also the clicking? ,.. hmm. sounds like the accelerometer is tweaking the arduino to send junk to the WT.    why dont you just drop $3.50 and do analog sensors like Jakes MKII.  i did.  they are good.  more than good. fine and dandy.  as long as you position them correctly and understand how they work,..  you can move in contrived ways that really make the thing sing.   also,.. if you want perfect sounds during a good rough duel,..  seriously,.  nothing on the market will do it. i have seen very expensive light saber duels, and they sound like poorly dubbed videos, and the smacking of polycarbonate will be louder than it all.

ok i am guessing that the +5V in #6 indicates the 5V regulator which connects to both boards in the diagram. and the led mossfet gates i think i have figured out.
do not use a regulator. waste of space. the arduino does it for you if you go to the RAW in pin.  5v-12v unregulated power... AKA a battery.



also,. no offense to Jake,..  his diagram does not go  into proper mosfet wiring nor how he delivers the correct voltage/current to the LEDs.  the attached photo will walk you thru how to do it with out a regulator, and WITH an led DRIVER, and how to wire the mosfet. the mosfet is tied to the WT588 and the LED in my setup.  turning off both LED and WT when there is no audio to play is not a bad thing.

also,.. to bypass default or interrupt hum,.. just program the WT so that every activation sound, except for blade off, is followed by 20-30 seconds of hum looped. it wont take up any more space on the device and plays seamlessly with less or no gaps.

so in the WT programer:

0x00 off sound,..  no hum.
0x01 on sound, followed by 30 seconds of hum
0x02 swing sound, 20 seconds of hum,
0x03 clash sound, 20 seconds of hum

etc
etc


you need 6 arduino commands,.

//button toggle code of choice
turn on led (or truly, send a pin HIGH state to the MOSFET)
turn off led (send a LOW state to the MOSFET

//button toggle code of choice
play on sound (0x01)  ( this should play 10ms after the turn on LED high state.  the WT needs 5-10ms to.. "boot up")
play off sound (0x00)
play clash (0x03)
play swing (0x02)

[img http://forum.arduino.cc/index.php?action=dlattach;topic=261980.0;attach=152407[/img]

if you are using an accelerometer,.  all of the above info may be moot.  i actually like the analog swing sensors. and the alternating debounce button codes with 100ms delays seems to really kill it!!  good swings, nice clashes,.and also a reversed debounce function to throw in alternating swing and clash sounds, if they happen close together,.  meaning..    a single swing with go HUM.  a full 360 or 2 swing triggers in less than 1000ms but more than 200ms will go zHum, VRhurm.  one hit will go CLAShh!  2 hits in less than 1000ms, but more than 200ms will go Clashh, Cleeerchzzs!  

capice?

sometimes the above doesn't work perfect or the same everytime, and gets rather random with you are moving around for a few minutes and holding the saber in wierd positions before you swing or clash it,..  but  random is fine with me too!  the real key is the right sound type plays when it should.

i don't even have a hum command or interrupt for arduino. heck i don't even have one on the WT,.  the sound is of course loaded to the WT, bu no Hex address has it to play.  it is just the tail of all the other sounds

in my off LED command,  i also give it (1200) delay so,.. the LED turns off, JUST as the off sound resolves,..  the LOW state also cuts power to the WT sound module.  this is so there are no false positives from the swing and clash sensors.  and again, less arduino code to mull over.  nothing says OFF like cutting the power.  no code needed.



DJWing79

This code uses the 3-line serial mode and ADXL335 accelerometer, WT588D, Arduino Pro Mini 3.3v and the OneButton library. I got it working pretty well. But I am trying to move over to the 1-line serial mode and it isn't playing nice. that's what I mean. I hope this helps. I am also trying to develop a RGB color changing scheme via the buttons that I saw from another forum.

DJWing79

oh and I apologize for the code not being more streamlined and neat.

chivotenkai

why use a 5V regulator for WT588D?
The arduino nano have a 5V output.
regards

JakeSoft

do not use a regulator. waste of space. the arduino does it for you if you go to the RAW in pin.  5v-12v unregulated power... AKA a battery.
This is good advice if you are using both a 5V Arduino board and a WT588D-u (the one with the built in USB). The WT588D-u board lets you get away with just powering the VDD pin which can operate at 5V. You used a Nano which has a 5V regulator built in, so you are all set.

The 16-pin WT588D works differently. It won't operate unless you power both the VDD and VCC pins. (The manual may not say that, but that's how it really seems to work.) The VCC pin needs to be 3.3V.

So, let's say you are working with a 3.3V Pro Mini like I used and a 16-pin WT588D. The VDD pin on the WT588D may also be 3.3V just like the VCC (meaning you won't need an external regulator) but won't be as loud as if you give it 5V. So, if you are running with a 3.3V Arduino board or a 16-pin WT588D, then you need an external regulator for maximum loudness because you need both a 3.3V and a 5V source. However, it will work if you jumper both the VCC and VDD pins to 3.3V, it just won't be as loud. I'm not sure what happens if you give 5V to both VCC and VDD. I assume bad things like fried flash on the WT588D, but who knows?

A lot of experimenting to figure all that out.




also,. no offense to Jake,..  his diagram does not go  into proper mosfet wiring nor how he delivers the correct voltage/current to the LEDs.  the attached photo will walk you thru how to do it with out a regulator, and WITH an led DRIVER, and how to wire the mosfet. the mosfet is tied to the WT588 and the LED in my setup.  turning off both LED and WT when there is no audio to play is not a bad thing.
No offense taken. Thanks for filling in the gap! It was clever how you exploited the VF of your chosen LED the way to did.  One question, though: How do you achieve maximum LED brightness if you are using something like a Cree XPE2 that has a forward voltage of ~3.5 v @ 1000ma? Or what if you are using a Lux Rebel red with a forward voltage of 2.4V @ 700ma? Is the LM2596 adjustable?

also,.. to bypass default or interrupt hum,.. just program the WT so that every activation sound, except for blade off, is followed by 20-30 seconds of hum looped. it wont take up any more space on the device and plays seamlessly with less or no gaps.
Hey! You stole my trick! :-) Yeah, this is by far the easiest way to get gapless transition to hum after a clash or swing.

if you are using an accelerometer,.  all of the above info may be moot.  i actually like the analog swing sensors. and the alternating debounce button codes with 100ms delays seems to really kill it!!  good swings, nice clashes,.and also a reversed debounce function to throw in alternating swing and clash sounds, if they happen close together,.  meaning..    a single swing with go HUM.  a full 360 or 2 swing triggers in less than 1000ms but more than 200ms will go zHum, VRhurm.  one hit will go CLAShh!  2 hits in less than 1000ms, but more than 200ms will go Clashh, Cleeerchzzs! 
I totally agree. Although adding an accelerometer allows you to do some cool things, people seriously underestimate what a PITA is to get it working properly while simultaneously underestimating what you can do with a tilt sensor. If you want to detect swings along another axis with simple tilt sensor, you can add a second sensor and orient it perpendicular to the first one. This is how the MR/Hasbro Force FX lightsaber sound boards work and people are putting them in custom sabers all the time. Reading what Bill posts here makes me want to revisit my Mk. II code and play with what can be done.
 
I've said it before, but there are many many MANY ways to wire/code this so it'll work. Thanks Bill for presenting one more by sharing your design.

billpealer

yup yup yup.

all that he said  /\
                      ||

the 5v regulator is needed because the 3.3v pro mini VCC will only send 3.3 v to the WT. i forgot you are using a pro mini 3.3v.  jake man,  have you found a decent amp? 

i just did something really interesting,..  i got the Nano to STACK onto the WT588d-U INSIDE my hilt.  i just shaved 1.24 inches of space.  I am soldering tonight. both USB ports face the same way, so you can reprogram both units,. with out even taking it out of the hilt.   i may do 2 tilt sensors with the  new space. or an amp.  i found one on ebay that should work. 

and no,. i have never achieved maximum output fomr my LEDS,..  but i am getting a good consistant 70% output, and no resistors burning up my batts, and YES, the step down buck converter IS adjustable...  but it adjusts kinds cruddy.  .3v increments. the potentiometer is shite.  the luxeon 3w blue rebel is rated for 3.4v and 450ma for it's optimal operation. yeah, it maxes out with some other numbers, but for mcd, i am right in the zone.

the buck step down settings i got are:
2.82v, 3.18v, 3.37v, 3.45, 3.51,.. for what ever reason.  i think as it gets higher, it becomes more acute.
I use the 3.37 for my green Luxeon rebels at 600ma with no issue, and the 3.45v for my blue at 650ma  with no issues yet.  the leds get warm. i have had them running for 10 minutes with no issue. 
The LM2596 buck is rated for 3A out. that must be at the higher spectrum of Vin.  at 8v in.. i have never been able to push more than 650ma at 3.45v.  i did crank the blue up to 3.6, and got 690ma,. but i tuned it down pretty quick.  the current must be auto regulated.  just the voltage is adjustable.

i seriously think 500-600 ma is plenty for these 3W leds,..  pretty bright.


also,.  by adding the reversed debounce code to the tilt, it will trigger a swing when the ball rolls from one side,.  OR if the ball is left to rest in the closed circuit position for more than 200ms, it will play an alternating swing sound when the circuit closes (low state).  so  it acts like 2 sensors. and vice versa.

billpealer

i learned the add hum trick back when i was just using local button mode.  worked like a charm.  so ..  i left it.

before i wreck my code,..  is there any proven reduction ratio to the 1 line serial mode delay times?,.. 600,200,200,600,100  respectively.

DK,. i think if you try to get rid of your If ,.. Hum statement,

}
    digitalWrite(switchLed, HIGH);


    if (digitalRead(WT588D_BUSY) == 1) {
      hum();
    }

that looks dangerously foul. you should not be using the busy pin as a trigger OR input sensor. can someone else take a look at the nugget?

Just add hum to the clash and swing sounds in the WT programmer, most of your issues will go away.  i am not sure because i can;t test it, but it looks like your interrupting your own resting state with hum, and giving it no delay,...  that sounds like the ticking you are hearing.  arduino is running the loop and finding the hum condition true and replaying it every 0ms,...  "Tk,Tk<tK,...."  Your "void hum ()" has no delay in it,..  whereas all your other sound statements have (5);

i say,. anywhere you have a delay in your code you are short changing your self.  all your 5s should be 10s,. and 10s to 20s.  and aslo,.  what the heck is this doing  ?
 
button.tick();
  delay(1);
  fadeValue = random(0, 105);
  fadeBase = random(15, 155);

delay 1?  really?  make that (10)

and also why all the serial prints?  is that for the accelerometer?

 

JakeSoft

#142
Dec 04, 2015, 08:17 pm Last Edit: Dec 04, 2015, 08:23 pm by JakeSoft
i just did something really interesting,..  i got the Nano to STACK onto the WT588d-U INSIDE my hilt.  i just shaved 1.24 inches of space.  I am soldering tonight. both USB ports face the same way, so you can reprogram both units,. with out even taking it out of the hilt.   i may do 2 tilt sensors with the  new space. or an amp.  i found one on ebay that should work. 
Really? That sounds cool. Send a few pics when you get it done, I'd like to see it. I always have to mount my 16-pin versions on a socket of some kind so I can pull the WT588D module out to reprogram it if I want to change the sounds. Having built in USB must be really useful here. Good thinking.


JakeSoft

i learned the add hum trick back when i was just using local button mode.  worked like a charm.  so ..  i left it.
I actually built a lightsaber with no micorcontroller whatsoever by leveraging that capability.

https://youtu.be/C-JO2Te4g5E

DK,. i think if you try to get rid of your If ,.. Hum statement,

}
    digitalWrite(switchLed, HIGH);


    if (digitalRead(WT588D_BUSY) == 1) {
      hum();
    }

that looks dangerously foul. you should not be using the busy pin as a trigger OR input sensor. can someone else take a look at the nugget?

Just add hum to the clash and swing sounds in the WT programmer, most of your issues will go away.  i am not sure because i can;t test it, but it looks like your interrupting your own resting state with hum, and giving it no delay,...  that sounds like the ticking you are hearing.  arduino is running the loop and finding the hum condition true and replaying it every 0ms,...  "Tk,Tk<tK,...."  Your "void hum ()" has no delay in it,..  whereas all your other sound statements have (5);

I think it's fine to leave that in there, but Bill is right about why you are hearing a "tick tick tick". You aren't giving your sound module any time to react. That busy pin on the WT588D can take anywhere from 15 to 50 ms to change state after you send the command. You need to wait longer after you send the hum command before you check the state of the busy pin.

DJWing79

thanks for the responses guys, some clarifications. that code i posted works 95% flawlessly, but only in 3-line serial mode. once I try to adapt it to one-line serial mode (to save on how many wirings I need) then I get that weird ticking and clicking sound. the serial print is from the code I found for the accelerometer (from a motion alarm no less!) and I have not had the time to really go through and clean up the code, hence my apologies. I am not opposed to not using the busy pin, but am still fuzzy on the syntax. so should it be something like this?


Code: [Select]

if isOn {                         //isOn is my variable for the momentary button turning unit on and staying on
sendCommand (0x01);
sendCommand (0xF2);
}



or should the repeat come before? I am not sure, can you give me a suggestion?

billpealer

thanks for the responses guys, some clarifications. that code i posted works 95% flawlessly, but only in 3-line serial mode. once I try to adapt it to one-line serial mode (to save on how many wirings I need) then I get that weird ticking and clicking sound. the serial print is from the code I found for the accelerometer (from a motion alarm no less!) and I have not had the time to really go through and clean up the code, hence my apologies. I am not opposed to not using the busy pin, but am still fuzzy on the syntax. so should it be something like this?
dude i just realized,..  the busyPin is NOT in 1 line serial mode.  ergo,.. your hum command won't work.  Der!

look at the code!  in one line serial mode, the busypin is gone from the WT code, homes.  you can assign it a pin in the int (which you did, because it is a hold over from your one line mode) or state in void setup (which you did not), but there is no code jamming in the WT 1line mode to change its state. right?!

so you need a different boolean arduino thinger to trigger your hum.

or you can listen to me, a schmuck that actually got a damn good working unit from listening to people, like Jake.  Or listen to Jake, the godfather- and take out your Hum statements.  and make your On command, and swing and clash commands just end with 20-30 seconds of looping hum,..  and that is done IN the WT programmer uploader application.

my setup code...  no busypin.
Code: [Select]
#define WT588D_SDA 9 //Module pin "P03" or pin # 10

int button = 2;         // the buton
int sw_sensor = 11;
byte file_count = 1;
bool saber_is_on;
bool swing_sound;
bool clash_sound;
int MOSFET_switch = 8;
long time = 0;         // the last time a sensor pin was toggled
long debounce = 200;   // the debounce time, increase if the button output is glitchy

void setup() {

   
  pinMode(WT588D_SDA, OUTPUT);   
  pinMode(button, INPUT_PULLUP);
  pinMode(sw_sensor, OUTPUT);  //swing sensor
  pinMode(cl_sensor, OUTPUT);  //clash sensor
  pinMode (MOSFET_switch, OUTPUT);  //one switch to rule them all and in the darkness bind them.
  digitalWrite(button, HIGH);
  digitalWrite(sw_sensor, HIGH);
  digitalWrite(cl_sensor, HIGH);
  saber_is_on = false;
  swing_sound = false;
  clash_sound = false;
  digitalWrite(WT588D_SDA, HIGH);
  digitalWrite(MOSFET_switch, LOW);
}

JakeSoft

dude i just realized,..  the busyPin is NOT in 1 line serial mode.  ergo,.. your hum command won't work.  Der!

look at the code!  in one line serial mode, the busypin is gone from the WT code, homes.  you can assign it a pin in the int (which you did, because it is a hold over from your one line mode) or state in void setup (which you did not), but there is no code jamming in the WT 1line mode to change its state. right?!

The busy pin functions on the WT588D any mode. It's even programmable to go either high or low when a sound is playing. I have used it in key, one-line, and three-line modes with success.

B-Movie

Just wanted to give a quick thanks to everyone contributing on this thread, I'm getting questions answered before I get the chance to ask them and have things coming together. Also great to get the hows and whys so I can learn it too, rather than just copying someones complete sketch. Awesome work everyone.

billpealer

The busy pin functions on the WT588D any mode. It's even programmable to go either high or low when a sound is playing. I have used it in key, one-line, and three-line modes with success.
but did you look at his attached code in entirety? he obviously is using it in high state. an the WT's high state voltage is not the same as the Arduino's, AND in 3 line mode,  the busy pin on the Arduino is set to go from high to low with delays for the WTsend_command funtion.  a full arduino 5v to 1v arduino high to low.  so THAT is making his hum sound work,. a full high state, a full low state and Delays,..  coming from the void Send_command(); function.  NOT from the WT's local busy signal.  or i still don't understand the cascading order of how arduino executes all the code from top down.  what else could it be?  if you remove the variables?  what changed from his 3 line to 1 line code?  only one friggin thing...  the Busypin is not being kicked on the send_command(); it is only being kicked local at the WT,.. no delays and maybe not enough difference tween high and low states.

}
    digitalWrite(switchLed, HIGH);


    if (digitalRead(WT588D_BUSY) == 1) {
      hum();
    }

and #define WT588D_BUSY pin#

is the only mention of "WT588D_BUSY" in dj's code.  plus the above code is pretty general,..  and DJ? why is the switchLed pin, being told to send a high state.?  shouldn't the LED be already on dude?

and the if the busypin is in a 1 (HIGH state), play hum function,..  is a global interrupt that will trigger the hum every loop cycle, with no delay as long as the busy pin is high, which it will be as long as there is a sound playing,..  it just reminds me of a non delaying feedback loop, and the tk,tk,tk you are hearing sure seems to support that.



so,. as long as a sound is playing, the WT device will send a mid voltage to pin 6? (or what ever he had assigned)  anyone ever take a V+ read off the WT's busy pin to confirm my assumption? if it is less than 3v,  would the arduino digitalRead even acknowledge that as a 1?  wouldn't that be a 0?  or can you  you say..
if (digitalRead(WT588D_BUSY) > 0)


plus there is no delay(20); in the end of the "void hum();"  the sole purpose of the busypin in the WT is to trigger a " lit while playing LED" . i still can't comprehend why the arduino (C) 3 line serial mode needs to send HIGH states down to the WT's busypin,.  especially since the busypin will be in a high state (at least 3v and 40ma to run a dinky LED, because the WT manual recommends putting a resistor in series at the busy pin and an LED.)

DJWing79

the LED is the blade, so when I turn the blade on, the hum comes on. Like I said, that code works pretty dang well in 3-line mode, don't ask how, since I had help with the code and don't fully understand it.Once I have it cleared up more, I plan to post of a video of the saber in action. It responds very well to the accelerometer and instantly to the clash sensor (thank you interrupts!) and the hum just loops. I am trying to save wiring space by switching to 1-line serial mode. if I can't make that work, am just going to stick with 3-line and then post the cleaned up code and video with schematics.

Go Up