VMUSIC2 tips-n-tricks

fmr300

New Member
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
 

hippy

Ex-Staff (retired)
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 :-(
 

AndrewBrown

New Member
Vmusic2

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

thanks
 

nbw

Senior Member
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?
 

hippy

Ex-Staff (retired)
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.
 

nbw

Senior Member
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.
 

hippy

Ex-Staff (retired)
From Technical, Post #4, here ...

http://www.picaxeforum.co.uk/showthread.php?p=48969

"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.
 

hippy

Ex-Staff (retired)
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.
 

BDG

New Member
Hi,
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:

nbw

Senior Member
@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.
 

BDG

New Member
NBW,
I made a change last night that appears to have fixed the problem- at least it has run for 12 hours without stopping.

I had a pause to wait for the respons to come back from the VM2, but forgot that while pausing, the comms buffer is not getting filled. Needless to say, shortening the pause to 500ms allowed the "Stopped" message to get stored so i could read it. I'll let it run for the rest of the day.
 

nbw

Senior Member
@hippy - I measured the vmusic2, picaxe 28x1 and max dc-dc step convertor (couldn't measure current without disconnecting etc) - but as an indication these 3 IC circuits used 90mA. Perhaps 5mA for the 28x1, maybe 10mA for the dc-dc, so the Vmusic2 a little greedier than 1st thought - maybe 75mA.
 

nbw

Senior Member
p.s. I also put 154 tracks (mp3) on a 1Gb drive - it took 17 seconds from power on to the point where it handed control over to the 28X1. That's not *too* bad. I'm half toying with the idea of a 4Gb stick for music in the shed, if the vmusic2 module could keep the wait down to under 1/2 a minute.

A thought: about 80% of the mp3s had very long file names. Usually for actual playing I'd have them named 01.mp3, 02.mp3 etc. Just as a quick test, I just grabbed a whole bunch of them off my laptop. I wonder if the longer file names added to the start-up delay?
 

nbw

Senior Member
Quick note: I re-flashed from 3.54 to 3.65 - the VMUSIC2 wouldn't play any music at all. I flashed it with 3.64 and it worked ok. Boot up time is a bit quicker for the 128Mb drive - about 2s now rather than 4s.
 

SenseiTG

New Member
fmr300: you say RTS goes high when the buffer in the VMUSIC2 gets full? that seems like a very odd behaviour for a pin named RTS... it is usually request to send - ie it gets asserted (it's inverted - so asserted = low) as soon as a device wants to transmit data and then goes back to high as soon as the last byte has been sent. I have had some problems with the RTS pin not behaving as expected on the shipping firmware (it was always asserted regardless of whether the device had data to send or not). I have not tried it since upgrading the firmware because I had already modified my code to work around the problem. Can anyone verify fmr300's findings regarding this pin?

I have not have any trouble with late responses to the volume command. Note that I switch to the short command set as soon as I've done the regular E,e synchronization - perhaps that has something to do with it?

Getting rid of the ID3 tag information seems like a bad idea to me. Perhaps make an option out of it (unless there already is) but not remove it. Decoding that information manually would require alot more custom code - not to mention that "play all" "play random" "play folder" and their repeated brethren would be useless if you needed id3 information as well - you'd have to traverse directories and fetch id3's "manually" which would probably introduce a significant delay between songs. You can *always* expect the same number of lines of ID3-tag information directly after a "playing" message - hence correctly designed software should not be confused.

Regarding power consumption, the specification says 25mA. Whether this is correct or not I cannot say - but I've read the same numbers on forum posts as well. I do know that my my regular simple ampmeter gives incorrect readings when measuring anything that plays music (ie fluctuates in a random manner) and I never hooked it up to my digiscope to find out the truth...

I read how some of you are having boot-time problems. I know that the device seems to be easily "confused" by the CTS signal upon startup preventing it from booting in a timely fashion. Keeping CTS high (NOT clear to send) prevents the unit from booting at all. Intermittently I too have problems with long boot-times, but only because I pulse the CTS line due to the way my software based "uart" works... most of the time the unit boots in roughly 2-3 seconds regardless of what size memory I am using and I have used 1,4 and 8gb memories, a camera with a cf card and an mp3 player with built in memory. Seems to me theres something else going on here...

I am using fw ver 3.66 so I suppose it's a tad bit newer than yours perhaps the bugs have simply been fixed? Theres nothing in the release notes regarding any of this though. Did find that "End-of-stream detection" has been improved - an upgrade to 3.66 might help those of you who are having problems with that weird command response delay after a stopped command?
 

caramorim

New Member
Music With PICAXE

Hi!

I saw your post and I found it very useful, since you have some experience with Music and Picaxe chips. Congratulations!

However, I need some help to make work an idea from some of my students. So, they want to make some kind of an virtual instrument, using some sensors as inputs and getting the sound of a note, from a real instrument, saved on mp3 or wav format. For example: 5 sensors and the sound of 5 diferent parts of a drum set.

Do you think that would be possible? Are you able to help me on this? Thank you!

Best Regards,
Carlos
 

SenseiTG

New Member
Hi!

Do you think that would be possible? Are you able to help me on this? Thank you!

Best Regards,
Carlos
I do not have experience with PICAXE, but I can still tell you that the VMUSIC will not let you do this for two reasons:

The unit will NOT allow you to adjust the pitch/playback speed of a sound.
There is a significant delay between issuing the play command and actual sound output.

Also, it cannot play more than one sound at a time.

You would probably be better off using either a synthesizer chip or using software to resample and mix waveform data from an eeprom or flash memory.

I am *very* doubtful that the picaxe would have enough processing power to be able to do this "properly" in software. With a limited number of channels and a simple sample-skipping pitch algorithm it *might* be possible - but the quality would not be all that good. An alternative way may be to use one PICAXE for each channel, and mixing their outputs in hardware. In any case you will have to have an external memory that is large enough to hold the samples in raw format (there is no way you will be able to decode mp3 on a picaxe) and fast enough deliver them in time.

I have done a similar project on a PIC (4Mhz/1Mips) where I fethed raw sample data from an SPI memory and played it back at the processors full capacity. It is possible to reach roughly 15Ksamples per second on this setup if you do not perform any kind of mixing or scaling. For good sound quality you need alot more than that (i'd say min 20Ks, preferably 40Ks = CD quality)

Switching to a better processor with a real bus would be the right way to go if you absolutely want sampled (recorded) instruments and most would be fast enough to fetch data, resample and mix several channels. How many depending on architecture and clock speed. There are many suitable CPUs in DIL capsules (I guess you don't want to go surface-mount) available.

Personally I would go for a simple synthesizer chip, mostly because they are easy and fun. But you will not be able to use sampled (recorded) instruments - on such a chip each instrument is defined by a set of parameters instead of a recording.

No matter what path you choose, I would be glad to help out - given that you have at least some basic understanding of digital electronics and programming yourself.

On what level is your student (ie how much experience has he had with this kind of stuff)? It would be easier to recommend a solution if I knew (I used to be a teacher too)...
 
Last edited:

behem0t

New Member
VMUSIC 2 Help

My project consists only on 6 push buttons that control 6 different playlist. So, each button jumps to the next track in the playlist: if the track ends without a push, it stops, otherwise, just jumps to the next.

I red your note about sound glitch, and tried a few variations, but i can't get rid of the glitch:

- send a stop before the play;
- send a volume down, a stop, a volume up, a play;
- different delays in between.

The code altogether was this:

mySerial.print("VSV ");
mySerial.print(0x100,BYTE);
mySerial.print(0x0D,BYTE);
delay(100);
mySerial.print("VST");
mySerial.print(0x0D,BYTE);
delay(100);
mySerial.print("VSV ");
mySerial.print(0x0,BYTE);
mySerial.print(0x0D,BYTE);
delay(100);
mySerial.print("VPF ");
lastPlayedSong = playList[cursors[cursorIndex]];
mySerial.print(playList[cursors[cursorIndex]]);
mySerial.print(0x0D,BYTE);


Can you Help Me?
 

nbw

Senior Member
On a quick but related note, am I right in saying that 3.68 is the latest firmware for the VMUSIC2? I had a scout around the vinculum website - I think this is the latest?
 

nbw

Senior Member
Groan

Just got another VMUSIC2 module, flashed it to the latest version 3.68. However, when playing, it plays for a few seconds, then seems to reset itself and starts playing the song again, then goes for a few seconds... etc. It's really bizarre. I'm using a 28x1, same code I used for my previous VMUSIC2 module. I have pin 6 portc going to orange on the VM2, portc 7 going to yellow.

Oddly enough, this hiccuping stops when I am downloading a new program! Then off it goes back into the pattern again.

I have tried formatting my 128Mb USB to FAT and FAT32, no difference there.

Has anyone else had this kind of problem? Is there anything blatantly wrong with my code that jumps out? cheers nbw

I've added the code here - it's so small! <code> symbol first_byte = b0
symbol point = b1
symbol temp = b2
symbol loopcounter = b3


INITIALISATION:


' initialise the USB chip
#picaxe 28x1
setup:

hsersetup b9600_4,%01
pause 2000

init:
hserout 6,("E",CR)
gosub get_response
if first_byte <> "E" then init

hserout 6,("vst",CR) : pause 300
HSerOut 6,("vpf 02.mp3",CR) ' play the selected track



get_response: ' usb initialisation
pause 300
point = 0
get point,first_byte
do
get point, temp
inc point
loop while temp <> CR

hserptr = 0
return</code>
 

nbw

Senior Member
It probably shouldn't make any difference - but I have tied the CTS (green) line to 0V as suggested on the forum. Blue and brown are not connected. I put a 0.1uF cap across the 5V and 0V pins near the VM2. The 3-way jumper - I haven't changed that since I took it out of the box. The jumper is across the 2 pins nearest the edge of the module. The leads for 5V 0V and RX / TX are lengthy but not what I would consider long. Including the little rainbox cable supplied with the module, probably < 40 cm.
 

nbw

Senior Member
OK, now this is weird. About every 2 seconds, an LED I have on pin 28 - OUT7! comes on for about 2 seconds, goes off for a second. Yet, there's nothing in the code that should be screwing around with OUT7!?!? I have the LED there for another part of the project.

I also tried using HSEROUT 0 as this was how it was set in my original code, no avail... it still plays a couple of seconds, then stops, then restarts etc.

It can't be glitches in the power supply - as soon as I hit the F5 download new program button it plays smoothly until the program complete message box appears.

<sound of head banging on table>
 

nbw

Senior Member
OK, fixed. One must let the VMUSIC2 play the track, instead of stupidly let it loop into the get-response routine, and start all over again.

<reaches for Dunce of the Week cap>
 
Top