I didn’t do that at first because the level shifter hookup guide shows as its example a 3.3V LV connection from what would be Tsunami in my case. I know of no 3.3V output pin on Tsunami so I first tested by ignoring this.
I did do a subsequent test, following the literal direction of the hookup guide text. I just put that back into place. Zero sound output. Here is how it is hooked up now:
Uno Pin 8 → HV4==LV4 ← Tsunami Serial TX0
Uno Pin 9 → HV3==LV3 ← Tsunami Serial RXI
Uno GND → GND==GND ← Tsunami Serial GND
Uno 5V → HV==LV ← Uno 3.3V
So I AM now providing 5V and GND to the HV side of the level shifter, and 3.3V and GND to the LV side, with GND being shared between Uno, the level shifter, and Tsunami.
Zero sound out.
My sketch command is:
tsunami.trackPlayPoly(1, 0, true);
This DOES work with good sound using manual trigger, and using a tsunami.ini file that supports a MANUAL trigger event.
This does NOT provide any sound output using the serial trigger, as hooked up here, and using a tsunami.ini file that supports an ACTIVE trigger event.
Success! (For first assigned phase.) It turns out I had multiple errors.
Yes, I needed to reconnect my power reference sources to the level shifter. But the reason that did not work before was a bad .hex file. I might have also had a bad .ini file as well but all of that is fixed. I can now meet the first challenge: I can send a play command via serial from Arduino to Tsunami.
Now I need to be able to receive data BACK from Tsunami. Before I proceed, I want to confirm earlier guidance. Please confirm that I do NOT need to connect the Tsunami TX to the Arduino RX via the level shifter. Does keeping the level shifter in this path add any unnecessary issues? Is it harmless in this path? Is it a good additional level of safety?
Normally, driving a 5V input from a 3.3V output works fine, since 3.3V is above the level required for a 5V input to register as “high”. However, if you inadvertently configured the Arduino TX input pin as an output and happened to drive it high, you would likely damage the Tsunami TX output pin GPIO. Since you already have the level shifter available, the prudent thing would be to use it.
Thanks. I agree to leave it in place for the sake of safety. I am reading your answer as explaining that it will cause zero issue with communications back from Tsunami via TX to Uno via RX.
-
Do I need to be concerned about communication speeds in order to ensure working comm back?
-
My plan is to again start simple, taking another baby step and pulling a few more lines from the tutorial just to try and get anything back. Something like:
tsunami.setReporting(true);
delay(100);
Serial.println(“Get number of tracks”);
delay(100);
gNumTracks = tsunami.getNumTracks();
Serial.println("Number of tracks = " + gNumTracks);
Serial.println(“Get version”);
delay(100);
tsunami.getVersion(gTsunamiVersion, VERSION_STRING_LEN);
Serial.println(gTsunamiVersion);
Ok. More decent progress but with interesting side effects.
This code does work:
Serial.println(“Get version”);
delay(100);
tsunami.getVersion(gTsunamiVersion, VERSION_STRING_LEN);
Serial.println(gTsunamiVersion);
I get back:
Tsunami v1.00s (c)2017
The test code lines I am using DO work, but the usage of printing output to the Serial monitor has hiccups.
This version of the code:
gNumTracks = tsunami.getNumTracks();
Serial.println("Number of tracks = ");
delay(2000);
Serial.println(gNumTracks);
Results in the following output:
Number of tracks =
17
(Yes, I DO have 17 test WAV tracks on the microSD card)
But the following version of this code, taken straight from the tutorial:
Serial.print("Number of tracks = " + gNumTracks);
Results in the following output:
=
Yep. Only an equal sign. Not very helpful should I need to use the serial monitor for troubleshooting as I get more advanced with this. And the same is true with:
Serial.println("Number of tracks = " + gNumTracks);
So if I can get an explanation as to what is happening and how to repair the Serial monitor reporting, I am good to proceed with more advanced tests.
Ultimately, my project needs are:
-
make sure I have a microSD card with tracks loaded. [DONE]
-
play any specific track on demand. [DONE]
-
find out when the current track is complete. [TBD] (Although knowing how many milliseconds remain would be better.)
-
pause any track current playing, and resume that track later at the point it was paused, if possible. [TBD]
-
while one track is playing out stereo output #1, play any other track using the same stereo output. [TBD]
5a) combining with #2 above, know when each of multiple tracks playing concurrently are done. [TBD]
Dangit. Two steps forward and one step back. I took my microSD card out of Tsunami and copied the files off so that I had a complete set of a working lab, and when I put it back into Tsunami I can now see no WAV files. They are all there and they all work, but Tsunami sees none of them. Not even after a reformat and re-population of the working files. The serial request for file count comes back “0”, and not even moving back to manual triggering works. Something is seriously touchy here. I have new cards on the way as it is but this progress is at a halt until I can figure this out.
The good news is that as part of my trying to figure this out this latest part of my adventure, I was able to flash the microcode. I am now running Version 1.09s. So Tsunami likes my SD card for flashing microcode.
I dunno anymore.
I went back to my first board and used it in my lab setup instead of my new board. Maybe I didn’t fry it after all? Turns out that I didn’t. I am back to being able to send serial command to play any track, AND I am able to send a command to get back the version of the board, AND the board is communicating back to my Arduino with the version info.
BUT…the command to fetch the track count still comes back with “0” for some unknown reason. No change to code. I do notice that the old board, since I have not applied my firmware patch test, is running v1.00s if that is any clue.
Maybe I had a loose wire in my lab setup that I resolved without knowing when I swapped back to the old board. Maybe it is something about seating the microSD card that is touchy and I got that right this time when I swapped boards. Maybe the SD slot on the new board got damaged. I have no explanation for why my serial command can play tracks now versus yesterday. Hopefully, as I keep manipulating my lab the cause will reveal itself.
Meanwhile, I absolutely do need to know why my command:
gNumTracks = tsunami.getNumTracks();
is coming back with “0” when there are 17 tracks on that card and I can play them all via serial command.
While I wait on any advice, I am going to sample other commands that I need to have working, such as:
tsunami.isTrackPlaying()
5/19/2020 UPDATE:
I actually have some semblance of a working system! If I can get it stable I will feel confident enough to create an Instructable. There are a few things about that stability issue, though.
- I am pretty concerned about AltSoftSerial maybe being the culprit for why text printed to the serial monitor is so jacked up. The text being printed to the serial console is so bad (missing, truncated, padded) that it renders the serial console unusable. This is a huge problem for me because I depend heavily on the console for programming development and troubleshooting.
I did try and comment out the AltSoftSerial line in the tsunami.h file and the library declaration itself in my code, and moved my connections back to the hardware TX/RX pins. That made things worse. It looks like a speed problem. I will go back and do more trials there once I get past my stability problem.
-
The Tsunami is acting real flaky. I will have it working perfectly fine (I am doing a lengthy multi-hour test where I walk through a long series of WAV files, testing and validating each) one day, and then come back the next day after MAKING NO CHANGES, and re-power the lab and attempt to restart my test and Tsunami won’t play a file. It can sound as though it has a mis-read of the SD card or sound like heavy clipping. Multiple power cycles and checking of cables make no difference. What CAN make a difference is to just let the lab sit for an hour or so and then try again. And then mysteriously things will start working OK. It’s pretty chronic. Maybe about 50% of the time it works on power up and 50% of the time it does not. And I have no more ideas about how to create stability. Or…files will be playing for an hour or so and then - BAM! - clearly an audible error as Tsunami just generates noise and needs to be reset (hopefully coming back up in one of those 50% good windows). This latter problem is why the reporting to the serial monitor window is so important. I would like to know what particular track it is that might cause Tsunami to lock up (I have 280 WAV files in my project). I could attack that file, make sure I have a clean one, and restart my test… Or I could move that track else where in the playlist and see if Tsunami locks up again when it hits it, or just locks up after some lengthy period of time. Bad console output is degrading my troubleshooting, inhibiting my ability to validate my hardware and my WAV file content.
-
One clue about stability is that within those 50% of the times when things work, I notice that Tsunami is off and running and playing WAV track #1 without any specific command from the user. The StopAllTracks command shuts that off, but why did that start? And is there something creaky under the covers that is happening at power up that I cannot see or track (because of the shaky output to the serial monitor) which we see evidence of by way of Tsunami taking off without manual direction, and is also capable of causing that 50% of failure sessions?
-
I have been fiddling around with test code, and using the github example code as my reference. I am trying to understand how it is that the example code is monitoring when the current track completes. This code section here has me confused:
if (!tsunami.isTrackPlaying(2)) {
Serial.print(“Track 2 done\n”);
tsunami.trackFade(1, -6, 500, false); // Lower the music volume
tsunami.trackLoop(4, 1); // Enable Track 4 looping
tsunami.trackPlayPoly(4, 0, true); // Start Track 4 poly
gSeqState = 3; // Advance to state 3;
}
The way this code reads to me is:
-
wait until the current track is done (this looks like a code error to me, monitoring track 2 and then fading out track 1?).
-
now that the track is done, meaning it’s no longer playing, we fade out the volume on that track.
-
then we go ahead and play the next track (track 4 in this case).
So how is it that we are fading out a track that has already stopped playing?
My project could use a fade function from track to track but that is not critical. What IS critical is to have a solid way to monitor when a track ends and control the program to take action upon that event. I have used this example to accomplish that but my code is ugly, and stinks of brute force. It’s an IF test stuck inside LOOP:
if (playlistMarker == 3) { // we are tracking playlist #3
if (!tsunami.isTrackPlaying(playlistCounter)) { // watch for current track to end
playlistCounter++; // now ended, increment the track counter
if (playlistCounter < (RFplaylistStopPos + 1)) { // make sure we are not at the end of the playlist
tsunami.trackPlayPoly(playlistCounter, 0, true); // start the next track
tsunami.update(); // update
delay(2000); // give Tsunami a 2 second breather
Serial.println("Now playing track " + playlistCounter); // report to the console where we are
}
else {
Serial.println(“Playlist is complete.”); // otherwise we hit the end of the play list
playlistMarker = 0; // clear the flag for this particular playlist
}
}
}
This is fine for now because I am still all about hardware stability and basic testing. But I really want to understand how to properly use the tsunami.isTrackPlaying() function for flow control.
As always, thanks for any assistance or commentary,
E
I was wondering if this board can send the filename (string format) through the serial communication [similar to the listfiles example from SD library on Arduino]. What I want is to be able to read the complete file name of all the files in the SD card, then parse the string to do certain actions based on it. In the tsunami serial control library there’s isn’t any function to get the full filename (only the track number). thoughts ? thank you
There’s no function to retrieve filenames from the card so you can’t retrieve filenames.
The Tsunami at least supports something similar to what you are asking although I don’t think it currently is doing so but I also don’t see what would prevent it from being able to do so either.
https://robertsonics.com/tsunami-user-guide/
Tsunami indexes the .wav files into track numbers based on the filename. In order to be recognized by Tsunami, .wav file names must begin with a number between 1 and 4096. This number can be from 1 to 4 digits and leading 0’s are not required. Additionally, and only for use with MIDI, if the track number is immediately followed with “_FN”, where F = “L” or “S” and N = 1 – 8, this will specify whether the track is to be looped and what output it should be routed to. If the “_FN” is omitted, then the track will not loop (single-shot) and will be routed to output 1. Again, this “_FN” field is only used when the track is started with a MIDI Note-On command.
The remainder of the filename does not matter and long filenames are allowed.
The following are examples of valid filenames and their meaning:
1-Music Loop 21.wav: Track 1
438_Barking Dog.wav: Track 438
0101_L3 Violin A3.wav: Track 101, when triggered by MIDI will loop and appear on output 3
4096_S4 Flute B3.wav: Track 4096, when trigger by MIDI will not loop and appear on output 4
All .wav files must be located in the root directory of the microSD card.
The WAV Trigger also seems to do so?
https://robertsonics.com/wav-trigger-online-user-guide/
To be recognized by the WAV Trigger, .wav files must be named starting with a 3-digit number, which becomes the “track” number. The remainder of the file name doesn’t matter, and it can be as long as you wish. Both “001Track.wav” and “403_Sneezing_Elephant.wav” are both valid file names. The WAV Trigger currently recognizes “001…” through “999…” as valid track numbers. For the remainder of this document, the word “track” will be used to refer to an appropriately named .wav file.
Beginning with firmware v1.20, .wav files may begin with either 3 or 4-digit numbers, and the WAV Trigger recognizes “001…” (or “0001…”) through “2048…” as valid track numbers.
Beginning with firmware v1.30, the WAV Trigger recognizes “001…” (or “0001…”) through “4096…” as valid track numbers.
All tracks must be located in the root directory of the microSD card.
You might have to slightly modify the serial access code but in theory it should be able to read what you are asking. Although not sure how easy that would be to do exactly. In theory the seller could update their code to simply add that command which might be the easiest. No idea if they would be willing to do so or not but you could ask them and see.
If you still have problems, here are a few things to check:
- Make sure your WAV files are named properly (refer to the above) and are located in the root directory of the microSD card. When you first power on the WAV Trigger, it will locate and index the files and then blink 3 times to indicate that it found at least one WAV file. One long blink means that it either couldn’t read the card or it didn’t find any WAV files.