[Michael P. Flaga]

here is a youtube video of the recommend modifications SFE MP3 Player D7 to D5 adaption. if a picture is worth a thousand words then a video is more.

Yes, The LED should be on. it is direct feed from Shields 3V regulator that is feed from the base Arduino 5V pin. It likely may be off due to the pins being shifted (miss-aligned). Have you seen the Red LED on the Shield on? (ever?).

The clicking could be many things, causing the output to pulse. There is no play button like sounds that it creates on its own. Likely a capacitive build up that is oscillating. The Shield will/should only play the file sent to it, as by the Arduino. So such sounds are not desired.

You should not need to solder anything to the VS1053 chip itself. But you will need header pins on the shields as to connect to the base Arduino. And it too will need header receptacles on the base ArduinoBT, if they are not there. It is possible to buy versions of the Arduino’s with or with out these header receptacles. And the SFE MP3 Player Shield comes with out them. Hence they need to be bought. A local RadioShack may have them.

Units are supplied without the headers as some customers don’t use the mechanics of shield structure but want to directly solder wires in there cases, or what ever.

Note the header pins on the shield are actually header receptacles, with very long pins that protrude through the bottom of the Shield as pins. Making them stackable headers. You can see this during the video. Note: the ICSP connectors male to female relationship is opposite of connection between shields.

Your description “the header polls are touching the circular metal rims of the mp3 player shield” is a likely source of the power not, illuminating the LED. Normally the Base Arduino has Female/Receptacles soldered to it, as to receive the male header pins from the attaching shield. As show in this picture, of two shields stacked, with out the bottom base Arduino.

Pins touching the annular rings of the solder pads are not sufficient. Either a solder connections of wires or solder connections to a good header/connector that applies the appropriate contact pressure, is required.

Note: there are various embedded web links are in this document, linking to referenced pictures and such.

 

[Michael P. Flaga]

1) Correct.

2) Currently, connect GBUF and LEFT to the speaker and set the VSdsp to Mono, using the MP3player.SetMonoMode(1); command.

3) The data sheet states the Full Scale output swing is 1.85V across 30 ohms. This equates to 6mA Peek to peek. for a 30 ohm speaker, or 0.114 watts. The same watts put into a 8 ohm speaker would result in 0.95 v peek to peek at 120mA. Approximately. Not sure where you get the 5V 50mA, unless you are referring to your speakers max abilities. which would then be a 5V*50Ma = 250 mW or 1/4W. Well above the VS1053’s standard/default output.

Note. I will add shortly support for the SM_DIFF feature. This will allow as stated “3.0 volts can be achieved with +-to-+ wiring for mono difference sound.” Then You connect a speaker between LEFT and RIGHT, then set the SM_DIFF bit in the mode register. Not using GBUF or GND and get more power out of the VSdsp. The data sheet does not spec this mode of operation, but it rational to think it was measured across a 30 ohm speaker as the rest of the spec’s were. This would yield 300 mW which would then be just beyond your 1/4W speaker. Setting or limiting the volume to -2dB would then limit the max power to approximately 80% (of 300mW) to 230 mW. Which is below the 250 mW speaker.

[Michael P. Flaga]

Un-power, disconnect shield.
Your description of mis-alignment can damage
I will try to get a picture , later
When i am back at computer

Have you cleared up the com port problem? to get serial fata back and forth

[Michael P. Flaga]

Yes, I do mean the Serial Monitor.

I can tell you your sketch works just fine on a normal Arduino using version 01.00.02 of this driver . I have just ran it. (note the most recent version on my mpflaga’s github has some difference’s stick to 1.0.2 for now, as on Bill’s github).

In your code above the music automatically plays, with out Serial Monitor interaction. In the MP3Shield_Library_Demo.ino it does not, requiring user input via the Serial Monitor. Hence from the Serial Monitor user input is needed from its menu. 1 and d are such menu commands.

There are many Arduino’s and clones out there. So it is hard to know what the problem is. Hence, my statements “Italian” referring to the original design versus some clone (which may have differences). Where most all Arduino’s are similar, but there some subtle differences. Such as: a Seeeduino Arduino may have different pin uses then a Original (Italian) Arduino. I don’t have a ArduinoBT to test it out on and not sure if it would be the same as yours. Where I dosee a difference between normal USB/Serial and the original “Arduino BlueTooth” . In that D7 is not open for general use. Rather it is tied to the BT’s reset.

Using an Arduino BlueTooth add’s extra challenges, likely the problem here. In a Normal Arduino the USB to Serial Port chip (aka FTDI) will automatically reset the Arduino’s CPU when the Serial Port’s DTR is toggled at connection of the Serial Monitor or other Serial Device. And out of boot the Arduino’s kernel looks for a special message as to upload. And if it does not get it and times out it runs the code already loaded. Where your ArduinoBT does not have this USB to Serial chip, but rather has a BlueTooth to Serial chip and it does not reset the CPU when the Serial Port is connected. Hence you need to manually hit the reset button, when loading. Also you can hit the reset after reloading, and it should time out and just run on. Allowing you to see all the prints, from the just out of reset. Normally these can happen before the Serial Monitor is fully displayed and be missed.

Additionally you need to match the Baud Rates. If I recall with the BT chip you need to be exactly at its baudrate. It may not be initially 115200, but likely either 57600 (aka 56K) or possibly 9600.

You likely have TWO problems.

First the COM3 error. This nothing to do with this Library. Have you been able to run other Arduino Code with Serial Ports. Such as …\examples4.Communication\ASCIITable\ASCIITable.ino It will stream out the ASCII table over the Serial Monitor. Likely your COM3 is used by something else, in addition to the Virtual Serial Port created by the BT driver. Try changing COM port to a different value.

Normally the IO pin D7 on most Arduino’s are free to use for anything. And the SparkFun MP3 Player Shield uses D7 as the XDCS signal. However, the ArduinoBT (likely yours) has D7 hard wired to the Reset of the BT chip. Hence when ever the MP3 driver sends data(music) to the MP3 chip the BT chip will get its reset pin toggled. Not good. Hence we need to re-route the XDCS function away from D7 and to the next unused pin, D5. This is a hard-mode and can be done with out cutting or soldering. Rather bending and jump wires. Bend the MP3 SHields D7 pin so that it wont mate to the Arduino’s header. This will separate the the MP3’s XDCS from base Arduino’s D7. Then changing the SFEMP3ShieldConfig.h MP3_XDCS from 7 to 5:

  #define MP3_XDCS             7 //Data Chip Select / BSYNC Pin
to

  #define MP3_XDCS             5 //Data Chip Select / BSYNC Pin

routes the XDCS signal to the unused D5 pin of the Arduino base board. Then on the MP3 Player Shield using a jump wire, jump D5 to D7 on the Shield. This then routes the XDCS signal from the base Arduino’s D5 back into the MP3 Player Shield’s XDCS input.

I believe 1.00.02 to be stable and best at the moment. With its example opening messages and error responses. But you need to get the opening messages first before moving on with the playback. Otherwise it is just guessing, what is wrong.  I always take things step by step.

Note there are more then one difference here, and that makes it more complicated for debugging. Hence the step by step. However, these extra complexities may make it worth getting a regular UNO for initial learning. Until you become more confident of typical Arduino’s and the hassles added by BT. I have several. Always good to have others for references, in case one breaks or gets weird.

P.S. Feel free to donate to Bill’s causes. However, I am separate from his causes. Just helping out.

[Michael P. Flaga]

I have fixed this in 1.0.2, released moments ago.

My bad. The usage of the byterate from the VSdsp broke this feature. Not sure how well it ran before.

I have fixed it and tested it. Along with putting in a Demo command.

Note that the codes’ serial input process’s each char, as a whole menu command. This preclude strings, hence the selected offset is hard coded in the example INO. Easy enough to change.

Warning there is an issue about running past the file’s end. somehow the volume and or track is not able to close correctly.

Also note that the requested milliseconds is a multiplied by the byte-rate to calculate the desired location. Where the byte-rate is the average, the VSdsp is playing. Hence it jitters a few tens of milliseconds. Should be close enough.

This helps with Variable rate as it is the average. Noting the VSdsp jitters for even constant bit rate.

[Michael P. Flaga]

Alex  says:

December 25, 2012 at 11:51 am

Great project!

But function skipTo is not working for me (((

It’s always jump to beggining of the file.

Not to the position in ms.

It’s so sad (((

[Michael P. Flaga]

nonlinearmind had asked about getting most volume possible.

SS_SWING of the SCI_STATUS allows you to go above the 0 dB volume setting. Value 0 is normal mode, 1 gives +0.5 dB, and 2 gives +1.0 dB. Settings from 3 to 7 cause the DAC modulator to be overdriven and should not be used. However, I doubt the receiving device will be able to handle it with out clipping.

At this time the released public GITHUB driver does not support a public member function to change this. Assuming 0dB should be loud enough.

[Michael P. Flaga]

Note to reset it after the Serial Port is already established. Some error prints may be missed just after boot. but before you may have enabled the serial port.

Is the Serial input/output unresponsive, after you execute the play? Assuming your are entering “1” to play track001.mp3. If unresponsive then its locked up on an interrupt. Not sure what then.

Otherwise; Does the “d” command verify that it can read the SdCard and show the correct filenames expected?

Try the test files as provided by SFE. They are bells and symbols crashes. quick to test. These are nice as they are Immediately LOUD. I wonder if your track001 ramps up the volume. And you are not hearing the initial 1 second of the first refill() being a quite lead in. And subsequent refill()’s are not happening. if you enter 1 repeatidly the repeaded refill() will increament play 1s at a time. confirming this.

The latest version has a SineWave Test. “t” will toggle a clear sinewave tone on or off. Not needing a file. You should hear that. Also try “t” after you have started a file to play. If it is actually trying to play it, it will print an error message. If not then its not playing, then the file is over.

Are the files really mp3. Their may be an issue where it does not play files that are not mp3 but have the extension of filename.mp3. The code may not play it if it reads bad ID3 Tag info of mp3 files, if falsely finds it. (doubt this).

Assuming it is Italian Arduino BlueTooth. I do SEE D7 is a conflict between MP3-DCS and BT_RESET. Both you it as an output, so it should compile. And likely work. Where I would expect any actual playing of sound would cause the BT chip to reset. and you loose your serial data. but I would suspect it still actually play. Regardless of the BT.

I would bend D7 out when stacking, as not to seat in the header, then jumper D7 on the SFEMP3Shield to D5 and change the SFEMP3ShieldConfig.h #define MP3_XDCS from 7 to 5. This removes the BT_RESET issue.

Hope one of the above solves it.

Let me know which one. (if)

[Michael P. Flaga]

Thanks for pointing out the typo.

As for the other issue. You appear to be appointing out a compile error. I thought from above comments you had it working on the Leonardo. So what changed or is different at your end? As I don’t see an issue at my IDE 1.0.1 & UNO. I have just upgraded to IDE 1.0.2 and it appears fins here too.

That said I do read in the release of 1.0.2 there was an addition to the Leonardo’s Serial.Write functions. Maybe there is an issue here with the Leo. As the bug report of this on the 1.0.1 indicates a similar scenario.

Perhaps trying 1.0.2 will work. If this the issue.

[Michael P. Flaga]

The manual is documented in the github page HERE

Please take note of the Troubleshooting & Non-Blocking Limitations section

• "Error code: 1 when trying to play track"

  • See the above Limitations. about Non-Blocking.
  • Remember to check your audio cables and volume.

The limitation describes why and how to poll for playing.

example:

if(!MP3player.isPlaying()) {
  Serial.println(F("Currently playing."));
}

[Michael P. Flaga]

Volume is documented in the github page HERE

Change line 214 of SFEMP3Shield.cpp from 20 to 2

SetVolume(2,2);

I have thought about adding a feature to store the volume into Flash, as to persist between power cycles. But I hesitate as being fringe (too host specific) and not part of the core scope of this example. And requires additional libraries.

[Michael P. Flaga]

Thanks. I appreciate the confirmation.

I have preliminarily loaded the change to my GitHub Fork As to automatically correct the interrupt based on the processor being identified as the Leonardo’s __AVR_ATmega32U4__ flag.

[Michael P. Flaga]

Great, I have already patched that to automatically occur for Leonardo’s. And will get flushed up in the next minor release.

Can you confirm that you did need to jump the wires, and that the jump instructions were correct?

It looks a little inconvenient to get the jumpers off the Leonardo’s ISCP header.

[Michael P. Flaga]

Actually simpler than all that above. Change line 145 of SFEMP3ShieldConfig.h from

#define MP3_DREQINT          0 //Corresponding INTx for DREQ pin
to

#define MP3_DREQINT          1 //Corresponding INTx for DREQ pin

This will swap the interrupts and should match the Leonardo.

If that works I can put in a Flag to auto select the correct value based on board type.

[Michael P. Flaga]

This symptom is typical of the interrupt not triggering the refill(). I bet if you play that or any other file, the music will advance about one second at a time, then stop.

I apologize for not being familiar with the Leonardo, as I don’t have one. So I am getting up to speed vicariously. Some Google Foo, leads me to see there are Issues with attachInterrupt(). Our method of establishing the pin’s interrupt to the refill(). INT.0 and INT.1  are SWAPPed. (nice). And that initial release of the Arduino IDE 1.0.0 had all INT’s outright broke.

So make sure you have IDE 1.0.1 or higher. As 1.0.1 fixed INT 0 & 1. IDE  1.0.2 also fixes INT 2 & 3. But note the Leonardo still has the pins of 2 and 3 swapped.

 

Two solutions:

1) put a jumper between D2 and D3. Remembering to leave D3 (not used by our example) as INPUT. I have actually done this on my UNO to validate that other INTs will work on this driver. (just not on a Leo).

 

2) Change line 174 of SFEMP3ShieldConfig.h to :

#define USE_MP3_REFILL_MEANS USE_MP3_Polled

It is by default: USE_MP3_INTx

You can also try USE_MP3_Timer1

[Author]

Posts