SparkFun Forums

[exeng]

Trying to use the isTrackPlaying(trk) method to prevent a re-trigger of a sound the is triggered by a PIR motion detector. The idea is once playing to not start playing again until the first instance completes. I believe I'm doing all the right things according to docs and examples but I'm not getting status back from update() calls.

There is and initial burst of info probably at the first call to update() but nothing after that for subsequent calls.

I can initiate sound but always get 0xFF for voiceTable[trk] when displaying all tracks via debug additions.

Version: v1.28
Serial: both rx/tx connected (3.3v) (on Serial3 for a Due equivalent)
setReporting is on
update calls made periodically
isTrackPlaying always returns false

Is this a defect? Has anyone successfully used this feature? How to I get WAV Trigger support?

[robertsonics]

I answered your post on the github page, but you provided more info here so I'll answer again here.

I believe the problem is that you're not using the updated WAV Trigger firmware that goes along with the latest library. Firmware v1.30 (on the WAV Trigger downloads page) is the first to support asynchronous track reporting.

http://robertsonics.com/wav-trigger-downloads/

Anticipating the next question, you'll need a USB-to-serial adaptor, like the FTDI-Basic to update the WAV Trigger firmware to v1.30 using the flasher app, also on the downloads page.

Also, calling update() does not directly cause serial traffic. Incoming message from the WAV Trigger are stored in a serial buffer and update() simply looks in the receive buffer and processes anything that has come in since the last call to update.

Hope this helps.

[exeng]

@robertsonnics Robert, Thank you for responding so quickly. Nice to know that you are monitoring this forum and Github.

I do have a FTDI Friend and will give the 1.30b a try to see if this fixes the problem. I saw the new prelim release but did not want to add another variable.

Again, Thanks for the response. I will post my results here and if this resolves the problem then close the Github issue that I posted.

[exeng]

@robertsonincs Robert, OK updated firmware to 1.30b and in the project version of my sketch now works as expected. There is a but though...

I have a test sketch version that I was using to try and narrow down the problem with and there I see some strange behavior where the voiceTable[] does not seem to reflect the status of the voices. At first I thought is was related to whether or not a sound was looped (even though faded out) but I saw one example where the sound was not set to loop and it (sound number) also remained in the voiceTable even after calling stopAllTracks. It could be an artifact of how my test program is structured but it does seem to be an unexpected and strange behavior. I'll ignore this for now and try to create a simpler example that exhibits the problem. Right now it starts multiple sounds, some looped some not.

Bottom line is with 1.30b the sketch I was having a problem with is working as expected. Additional PIP motion detects do not re trigger sound as isTrackPlaying is reporting the sound as playing. Looking forward to continuing to develop around this board. Thanks.

BTW, firmware update was smooth and easy to do.