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
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
Sent "VPF 1.MP3" command then send a volume-change command “VSV $01” during play
T $00 $00
T $01 $00
T $02 $00
D:\> “VSV $01” sent here
T $03 $00
T $04 $00
Sent “VPF 2.MP3” when ‘2.MP3’ did not exist on disk
Sent a “VPF 1.MP3” command when there was no disk
Sent <CR> when no disk present:
Sent “DLD testdir” when there was no directory “testdir” on the drive:
Very useful. I've copied it to User-Projects/Audio-Visual where it will be found much more readily.
It's a real shame about volume control being so unresponsive because my plan is for a music player which will fade music away then stop it, all over a period of about 1.5 seconds. That doesn't look possible without an external digital pot :-(
Thanks for this it has been very helpful. But I was also wondering if anyone knew the power consumption of the vmusic2 module in mA or mAh? I need to know this as im running it off a 9v battery and need to know how long the battery will last for the project im doing.
Im also running a 28x chip and parallax rfid reader if anyone has any suggestions
The module is not bad for a kid's toy like I made for my son. The 2 things that stopped me from making a real good from the shed is...
1. It doesn't like bitrates > 128K
2. A 128Mb stick with around 25 songs takes around 3-4 seconds to initialise. A 1Gb stick would be around 30s. I was thinking about an 8Gb player for the shed... no way though! 4 mins to boot up? Sounds like Microsoft!!
3. I could never get the nice commands listed in the above posts to work for me... tried reading into variables and deciphering - never got the answers I was expected.
Now, Hippy's IDE drive - part 1, STA013 - part 2, DAC - part3. 33% of the way there?
A 128Mb stick with around 25 songs takes around 3-4 seconds to initialise. A 1Gb stick would be around 30s. I was thinking about an 8Gb player for the shed... no way though! 4 mins to boot up?
I haven't tested it but it would be interesting if someone could. There's always going to be some initialisation overhead on anything which communicates with a USB device and it may be that these few seconds are constant regardless of the size of USB stick added.
I don't see any technical reason why the boot time would need to lengthen considerably for a larger USB stick but that would depend on how the firmware was implemented.
I've got to replace one of the NiMH batts in my son's player this weekend... if I remember I'll load up a 1 Gb stick with mp3s and see how long it takes to boot. I remember reading an article somewhere - maybe SC - that said their 1Gb took so long they wondered if it was doing anything at all.
"IMPORTANT NOTE: Upon powerup it can take over a minute for the VMUSIC2 to enumerate the 1GB memory stick. During this time it looks like nothing at all is happening. This had us confused for many hours, thinking that the module was not working! After powerup have a cup of coffee and wait for the LED on VMUSIC2 to go green. The drive LED should also be on - if not try reinserting".
I couldn't find other complaints about slow enumeration on the WWW so it may depend upon make of USB stick and version of firmware installled, which was also noted for resolving some USB stick problems.
It would also be worth checking what maximum sized USB sticks any particular firmware supports. FAT16 supports a maximum size of 2GB ( with 32KB clusters ) but users report up to 4GB working so success could also depend on how / with what a USB stick is formatted.
Did anyone have any answer for AndrewBrown in Post #3 on current consumption ?
I couldn't find anything in the datasheets or elsewhere but the VNC1L USB Host controller chip draws 25mA ( 2mA in standby ), the VS1003 seems to vary depending on what it's doing but looks like it could go up to 50mA, plus the USB stick and the rest of the electronics, including any amplifier there may be in the module.
A ballpark guesstimate could be 100mA. Perhaps not so good for 9V batteries which are often somewhere around 250mAh rated, but not too bad for a mains PSU supply. While not 'green', leaving a system powered up should avoid enumeration time, and at 100mA would be the equivalent of around 5kWh over an entire year.
I too just started playing with the VM2 last night.
For those interested: Initialising a 1G stick took about 4 seconds. (PICO brand $4.95 from Officeworks) EDIT- ahh but I only had 3 files on it.
But a problem I have encountered:
I plan to use it for a warning annunciator - "Its raining, bring the washing in!" etc
I have had it cycling 3 messages, 2 very short (1 verbal word), and 1 very long (by message standards) 13 seconds. I wait for the "Stopped" to come back before I play the next file. I have left it run, and it eventually gets stuck waiting for the "Stopped" message.
I kept getting "Playing file.mp3". Can't say how long this took as I just walked away and let it run, came back hours later.
Anyone run into this?
Last edited by BDG; 02-04-2009 at 09:42.
@BDG - yes, I had all kinds of trouble trying to get the PLaying/Stopped feedback from the VM2 to make sense to me, plus I had a migraine at the time and couldn't get my head around hptr this and that, some of the 'new' tricks the 28X1 was doing with the module.
In the end, I simply looked at each song length manually, stored that at the start of my program so whichever song it's playing, it knows (or at least, you the coder knows) when it's finished. I remember reading there was a way of storing TXT on the USB stick that the VM2 could read - never had the chance to play with that.
@Hippy - again from memory, my VM2 uses about 40 - 50mA. It starts off low then starts to guzzle noticeably when reading from USB. Combined with my baby amp, step-up circuit, picaxe 28x1, the total draw is around 200mA (amp using most). I use 3 x 1.2V AA rated at "2500" mAh, so I get reasonable playing time.
Still keen to throw a 1Gb stick in it this weekend when I'm replacing one of the dead batts. I'll load it up with 128K tracks and put a stopwatch on it.