Have been working with the VMUSIC2 quite a bit in the last few weeks and just thought I'd post some of the things I've found about it. Some of them I discovered and then later found in the firmware manual or the VS1003 spec, but here they are:
1. Volume resets to max when power is cycled, but sticks to last setting between songs.
2. VSV (volume) settings are logarithmic…. Every tic is 0.5db, quite reliably (ie, 20 tics is 10db, etc)
3. Play will interrupt a current play, without needing to issue a Stop (VST).
4. Firmware images need to be renamed exactly “ftrfb.ftd” before putting them on the USB stick for upgrade. Use the “.ftd” files on the VMUSIC website
5. Don’t try to Open a file during mp3 play…. Won’t work
6. While playing an mp3, the VM2 is VERY slow to respond to ‘VSV’ volume changes – often 3-4 seconds! It does queue them up and can buffer 5-6 of them, eventually responding (15-20s to execute them all and ack each with “D:\>” !). This makes it impossible to do a quick-fade control while playing an mp3…. And VERY awkward to even continue playing music from one VM2 at reduced volume while over-dubbing with another VM2. This sucks. ‘VSV’ response time when NOT playing an mp3 is about 1ms! Tried VWR directly to volume register on VS1003 but same problem. Tried pause/resume via ‘E’/CR too, same incredible slowness responding to the pause (‘E’).
7. RTS does go high if you send too much data to the VMUSIC. Specifically try this sequence:
a. Send “MKD testdir” followed immediately by 3 “DLD testdir” cmd’s
b. What you’ll see is that partway through the 3rd DLD sequence, RTS will be asserted and will stay asserted for nearly 600ms (which not surprisingly is approx the typical response time for a MKD cmd).
c. The RTS must be getting asserted at ‘near’ buffer full, as even the 3rd DLD cmd is properly responded to with a “Command Failed” response later, indicating that all of the command was received (if not all received then it would have responded with “Bad Command”
d. So my guess is that VMUSIC2 has approx 40 bytes of input buffer…. Assuming that the MKD cmd was already taken from the buffer and being executed, it seemed that it still took (3) DLD cmd’s and executed them properly.
8. I have put the VMUSIC into a strange state on several occasions, where it will say “Bad Command” to valid commands that I send it, and removing/reinserting the disk did not get the normal disk-diags (nothing sent in fact). Had to cycle power to clear the bad state. Fortunately I’ve only seen this after some real msg-bombarding to the VMUSIC when I was testing the RTS and input buffer length.
9. After playing an MP3, when the VMUSIC sends “Stopped”, followed by “D:\>”, if you detect the “D:\>” msg and immediately send another “VPF” command, there is a small audio hiccup (beep) at the end of the 1st file before the 2nd file starts…. It seems as if the VMUSIC has a little music still buffered up when it sends the “D:” message, and an immediate VPF command aborts a little of the 1st file and you hear a little glitch before the 2nd file plays. In fact this glitch sounds exactly like the glitch-beep you hear when you send a 2nd VPF command during an mp3 play. To have a no-glitch transition between the 1st and 2nd file, wait about 20ms after getting the “D:\>” msg before sending the next VPF command…. Unfortunately this also causes a little quiet time between the files, which is probably the normal start-playing time for any mp3 after VMUSIC gets the VPF command (haven’t measured it but sounds like about 500ms). I guess I could alternate between the two VMUSIC’s in order to minimize this startup delay (when I get “D:”, send VPF to 2nd VMUSIC2 with no 120ms delay).
Also – for cmd’s that don’t work WHILE playing an MP3 (‘CD’ is example – returns ‘File Open’), if you send that during this short interval after getting the ”D:\>” response, it will fail. Predictable since it seems the VM2 is actually still ‘playing’ the mp3 file. I’ve also found that if you only wait for the ‘Stopped’ response, the window where another CMD fails is quite wide (about 120ms), but if you wait for the D: response, the window is short and usually the next cmd will run…. Better to put in a small delay even after rx’ing the D: response.
10. Waiting for ‘Stopped’ (-vs- ‘D:\>’) to indicate that an mp3 is done playing has the disadvantage mentioned above (ie, the mp3 is actually still playing for another 120ms or so, AND any cmd’s that cannot be executed during mp3 play – CD for example – will fail during that 120ms window), but has a nice advantage also: If you tell the VM2 to play an mp3 that doesn’t actually exist in the dir, it responds with ‘Stopped’ & ‘Filename Invalid’ but no ‘D:\>’…. So waiting on ‘D:\>’ will hang, whereas waiting for ‘Stopped’ will not hang. I’ll likely use just ‘D:\>’ and be very careful about filenames, etc….. mainly because of the timing issue mentioned in #9 above.
11. If you are already in directory ‘x’, and you issue a cmd, “CD x”, it will return “Command Failed”….
12. Here are the responses that I’ve seen:
Stopped - file was played
Filename Invalid - tried to play a file that wasn’t on the disk
Bad Command - sent unrecognizeable cmd
D:\> - given after many successful commands, and after <CR> when disk is present
Command Failed - tried to play a file but no disk was present, tried to delete a non-existent directory, etc.
No Disk – given when just <CR> sent and no USB drive connected
File Open – given when mp3 playing and you issue CD cmd, or [likely but not checked] when file open for write and you CD
It would probably be a good idea to get rid of the embedded MP3 file-info as the VMUSIC2 prints this info to serial port when the file is played…. Could confuse your program if the wrong words happened to be in there!
=============================== Recorded Example Sequences ============================
Sent "VPF 1.MP3" command and allowed 5-sec file to play to completion
Playing 1.MP3
These 5 lines are where VMUSIC tx’s MP3-header info – this mp3 had blank headers
T $00 $00
T $01 $00
T $02 $00
T $03 $00
T $04 $00
Stopped
D:\>
=================================================
Sent "VPF 1.MP3" command then send a volume-change command “VSV $01” during play
Playing 1.MP3
D:\>
T $00 $00
T $01 $00
T $02 $00
D:\> “VSV $01” sent here
T $03 $00
T $04 $00
Stopped
D:\>
=================================================
Sent “VPF 2.MP3” when ‘2.MP3’ did not exist on disk
Stopped
Filename Invalid
D:\>
=================================================
Sent a “VPF 1.MP3” command when there was no disk
No Disk
Command Failed
Sent <CR> when no disk present:
No Disk
=================================================
Sent “DLD testdir” when there was no directory “testdir” on the drive:
Command Failed
1. Volume resets to max when power is cycled, but sticks to last setting between songs.
2. VSV (volume) settings are logarithmic…. Every tic is 0.5db, quite reliably (ie, 20 tics is 10db, etc)
3. Play will interrupt a current play, without needing to issue a Stop (VST).
4. Firmware images need to be renamed exactly “ftrfb.ftd” before putting them on the USB stick for upgrade. Use the “.ftd” files on the VMUSIC website
5. Don’t try to Open a file during mp3 play…. Won’t work
6. While playing an mp3, the VM2 is VERY slow to respond to ‘VSV’ volume changes – often 3-4 seconds! It does queue them up and can buffer 5-6 of them, eventually responding (15-20s to execute them all and ack each with “D:\>” !). This makes it impossible to do a quick-fade control while playing an mp3…. And VERY awkward to even continue playing music from one VM2 at reduced volume while over-dubbing with another VM2. This sucks. ‘VSV’ response time when NOT playing an mp3 is about 1ms! Tried VWR directly to volume register on VS1003 but same problem. Tried pause/resume via ‘E’/CR too, same incredible slowness responding to the pause (‘E’).
7. RTS does go high if you send too much data to the VMUSIC. Specifically try this sequence:
a. Send “MKD testdir” followed immediately by 3 “DLD testdir” cmd’s
b. What you’ll see is that partway through the 3rd DLD sequence, RTS will be asserted and will stay asserted for nearly 600ms (which not surprisingly is approx the typical response time for a MKD cmd).
c. The RTS must be getting asserted at ‘near’ buffer full, as even the 3rd DLD cmd is properly responded to with a “Command Failed” response later, indicating that all of the command was received (if not all received then it would have responded with “Bad Command”
d. So my guess is that VMUSIC2 has approx 40 bytes of input buffer…. Assuming that the MKD cmd was already taken from the buffer and being executed, it seemed that it still took (3) DLD cmd’s and executed them properly.
8. I have put the VMUSIC into a strange state on several occasions, where it will say “Bad Command” to valid commands that I send it, and removing/reinserting the disk did not get the normal disk-diags (nothing sent in fact). Had to cycle power to clear the bad state. Fortunately I’ve only seen this after some real msg-bombarding to the VMUSIC when I was testing the RTS and input buffer length.
9. After playing an MP3, when the VMUSIC sends “Stopped”, followed by “D:\>”, if you detect the “D:\>” msg and immediately send another “VPF” command, there is a small audio hiccup (beep) at the end of the 1st file before the 2nd file starts…. It seems as if the VMUSIC has a little music still buffered up when it sends the “D:” message, and an immediate VPF command aborts a little of the 1st file and you hear a little glitch before the 2nd file plays. In fact this glitch sounds exactly like the glitch-beep you hear when you send a 2nd VPF command during an mp3 play. To have a no-glitch transition between the 1st and 2nd file, wait about 20ms after getting the “D:\>” msg before sending the next VPF command…. Unfortunately this also causes a little quiet time between the files, which is probably the normal start-playing time for any mp3 after VMUSIC gets the VPF command (haven’t measured it but sounds like about 500ms). I guess I could alternate between the two VMUSIC’s in order to minimize this startup delay (when I get “D:”, send VPF to 2nd VMUSIC2 with no 120ms delay).
Also – for cmd’s that don’t work WHILE playing an MP3 (‘CD’ is example – returns ‘File Open’), if you send that during this short interval after getting the ”D:\>” response, it will fail. Predictable since it seems the VM2 is actually still ‘playing’ the mp3 file. I’ve also found that if you only wait for the ‘Stopped’ response, the window where another CMD fails is quite wide (about 120ms), but if you wait for the D: response, the window is short and usually the next cmd will run…. Better to put in a small delay even after rx’ing the D: response.
10. Waiting for ‘Stopped’ (-vs- ‘D:\>’) to indicate that an mp3 is done playing has the disadvantage mentioned above (ie, the mp3 is actually still playing for another 120ms or so, AND any cmd’s that cannot be executed during mp3 play – CD for example – will fail during that 120ms window), but has a nice advantage also: If you tell the VM2 to play an mp3 that doesn’t actually exist in the dir, it responds with ‘Stopped’ & ‘Filename Invalid’ but no ‘D:\>’…. So waiting on ‘D:\>’ will hang, whereas waiting for ‘Stopped’ will not hang. I’ll likely use just ‘D:\>’ and be very careful about filenames, etc….. mainly because of the timing issue mentioned in #9 above.
11. If you are already in directory ‘x’, and you issue a cmd, “CD x”, it will return “Command Failed”….
12. Here are the responses that I’ve seen:
Stopped - file was played
Filename Invalid - tried to play a file that wasn’t on the disk
Bad Command - sent unrecognizeable cmd
D:\> - given after many successful commands, and after <CR> when disk is present
Command Failed - tried to play a file but no disk was present, tried to delete a non-existent directory, etc.
No Disk – given when just <CR> sent and no USB drive connected
File Open – given when mp3 playing and you issue CD cmd, or [likely but not checked] when file open for write and you CD
It would probably be a good idea to get rid of the embedded MP3 file-info as the VMUSIC2 prints this info to serial port when the file is played…. Could confuse your program if the wrong words happened to be in there!
=============================== Recorded Example Sequences ============================
Sent "VPF 1.MP3" command and allowed 5-sec file to play to completion
Playing 1.MP3
These 5 lines are where VMUSIC tx’s MP3-header info – this mp3 had blank headers
T $00 $00
T $01 $00
T $02 $00
T $03 $00
T $04 $00
Stopped
D:\>
=================================================
Sent "VPF 1.MP3" command then send a volume-change command “VSV $01” during play
Playing 1.MP3
D:\>
T $00 $00
T $01 $00
T $02 $00
D:\> “VSV $01” sent here
T $03 $00
T $04 $00
Stopped
D:\>
=================================================
Sent “VPF 2.MP3” when ‘2.MP3’ did not exist on disk
Stopped
Filename Invalid
D:\>
=================================================
Sent a “VPF 1.MP3” command when there was no disk
No Disk
Command Failed
Sent <CR> when no disk present:
No Disk
=================================================
Sent “DLD testdir” when there was no directory “testdir” on the drive:
Command Failed