Forum Replies Created

Viewing 15 posts - 16 through 30 (of 204 total)
  • Author
  • in reply to: Easy Transfer Array Populating (from SD?) #3524

    As for your array issue I suspect something un-related to this library.


    the following snippet works:


    #define LENGTH_OF_ARRAY(x) ((sizeof(x)/sizeof(x[0])))

    int arraydata[] = {0x000000,0x0000ff,0x00ff00,0x00ffff,0xff0000};

    void setup() {

    // put your setup code here, to run once:


    while (!Serial) {

    ; // wait for serial port to connect. Needed for native USB port only


    Serial.println(“Hit any key to continue.”);

    Serial.flush(); //flush all previous received and transmitted data

    while(!Serial.available()) ;

    for (uint8_t channel = 0; channel < LENGTH_OF_ARRAY(arraydata); channel++) {







    void loop() {

    // put your main code here, to run repeatedly:



    with the following results:

    Hit any key to continue.







    in reply to: Easy Transfer Array Populating (from SD?) #3523

    I would recommend looking at the second answer at the following StackExchanage




    in reply to: Adding an LED.. #3517

    not much of an expert on audio signals. I believe LINE is typically 1V peak to peak. So +/- 0.2 equal 0.4Vpp. ruffly half. And then noting that the output of the VS1053 is not LINE, but a driver for low impedance speakers. either 8 or 16 Ohm. And think is some kind of D type amplifier.

    If you need more power I recall documenting somewhere in the github doc an API to change to mono and add the currents of both the outputs into one channel. Someone did this for a stuffed toy. So it would appear to be more current based then voltage.

    in reply to: Adding an LED.. #3515

    Extrace from

    Where the below documentation is from the current patch from their website and is more recent patch. That I have not converted to the SFEMP3 file binary format. So the library has the old version. There is a in the repo for creating new binary files from their patches.

    VU Meter

    SCI_STATUS bit 9 enables VU meter, which calculates a leaking peak sample value from both channels and returns the values in 1 dB resolution through SCI_AICTRL3. The high 8 bits represent the left channel, the low 8 bits the right channel.

    Note that the following has changed from the previous release.

    Values from 0 to 96 are valid for both channels. 0 means no sound, 96 is highest level. In practise the highest value will be 95, the signal is probably clipping if you get 96.

    The calculation does not take the volume setting into account.

    The VU meter takes about 0.6MHz of processing power with 48 kHz samplerate.


    from wikipedia i read:

    <span style=”color: #252525; font-family: sans-serif; font-size: 14px; line-height: 22.4px;”>0 VU is equal to +4 [dBu], or 1.228 </span>volts<span style=”color: #252525; font-family: sans-serif; font-size: 14px; line-height: 22.4px;”> </span>RMS<span style=”color: #252525; font-family: sans-serif; font-size: 14px; line-height: 22.4px;”> across a 600</span>ohm<span style=”color: #252525; font-family: sans-serif; font-size: 14px; line-height: 22.4px;”> </span>load<span style=”color: #252525; font-family: sans-serif; font-size: 14px; line-height: 22.4px;”>, or about 2.5 milliWatts</span>

    in reply to: Adding an LED.. #3513

    Please see step #2 in the documentation at

    The plugin patches are located in the repo at:

    The libraries initializing code of the VS1053 looks optionally for the “patches.053” in the root of the SdCard. If not found it issues a warning and moves on, as it is not needed for basic functions.

    in reply to: Adding an LED.. #3511

    I see right there in my documentation of the code at

    get current measured VU Meter

    Returns the calculated peak sample values from both channels in 3 dB increaments through. Where the high byte represent the left channel, and the low bytes the right channel.

    Values from 0 to 31 are valid for both channels.

    Warning :This feature is only available with patches that support VU meter.

    So I suspect that there are two issues. 1) need the patches and 2) use getVUlevel.

    Hope that helps.

    in reply to: Adding an LED.. #3509

    Not sure about it not working. Honestly has been over a year since I last fired it up. I recall testing it before committing it. hmm. It may require the DSP patches, as I see it is a read of SCI_AICTRL3 . a register in the DSP and those are affected by the patches.

    about “getVUlevel” and “getVUmeter”. The later basically reads back if it is enabled. where getVUlevel returns the actual VU level on the line. note in the demo code it enables it with


    then polls it

    vu.word = MP3player.getVUlevel();

    notice that it returns a word and the union splits that into a Left and Right for the print.

    in reply to: Occasional Pops/Glitches #3503


    You can try to increase the SFEMP3Shield::mp3DataBuffer from 32 to larger values. The minimum needs to be 32.

    hmm, “pop or glitch”… is odd. The MP3 file is frame of packets. There should not be glitches. It has been my experience if there is a lack of real time (too busy doing other things) then there are short pauses of silence, until the buffers catch up and resume playing. pops are an indication of lost data.

    FYI, the SdFat library reads the Card in chunks of 500 Bytes at a time in to local cache of RAM. and refills that as it needs to. And reads the next 32 it will send to the 1053. Where the 1053’s buffer is 32. So sending more may exceed the 1053’s buffer and sending less may cause more cycles to fill the 1053. But it is simple enough to try and mess with.

    I would be more suspiciuos of any periods of your code that may disable interrupts. with the cli() or noInterupt() commands that do something and then re-enable with sei() or interupt() commands. Excessive use of these cause the buffer to stall. It may be possible there are other libraries that you are using that may intermittently block interrupts. Example the NeoPixel library. If well written they can block for very short periods and then release. Others may not.

    in reply to: Adding an LED.. #3501

    I would recommend starting with the first code shown at

    The 2nd code is the same but has extra code for a matrix display. But look at that to. As it should store it for time.

    Also note that the 1053 and this library has a feature for measuring the transmitted power level at any time, called VUmeter.

    setVUmeter’s enable. then occasionally poll the getVUlevel and use this to replace the analogread data. Scale the output of the getVUlevel and then send it to analogwrite.

    There are set and get VU examples in both MP3Shield_Library_Demo.ino and FilePlayer.ino


    in reply to: Adding an LED.. #3499

    I do not believe it may be as simple and straight forward as your attempt may be.

    First electrically you don’t say what the schematic of it is. Note that the signal is AC and can be very small ranging from milli volts to 1vpp peak to peak. Note sure if you are isolating it through a cap. I believe that will need to be done, somewhere. The output amplifer of the 1053 is not isolated. And that will make it +/-. the minus will likely need to be clip the negative. So the ac signal will range from zero to positive peak, with a max of +1vp.

    the above code should likely map to rescale the analog input to the output scale.

    Also note about the Analog output; that it is really a duty cycle of a pulse. so if the signal was max of 1 vp, then that would be one fifth of the cycle. and noting even at max the signal is sinusoidal and only about a small portion is near peak.

    The other aspect of concern is your update rate. there is no delay between samples and updates of the analog-write. So your code is constantly re-writing the duty cycle, way more time then an actual cycle. I believe the default cycle is around 490 hertz ish. So you may re-writing it hundreds of times per cycle. And that may be freaking it out. Not sure. Just a guess.

    I would pass the audio input through a cap and low pass filter it. As to smooth/average out the audio energy and then sample that at 2 or 10 per second and then map (aka re-scale) that to a range that was visibly pleasing.


    in reply to: MPFlaga's Random Play Code #3496

    I see, that was an old GIST, and had not updated it when the library changed.

    So I have updated it, to include the missing sd.begin() and in a few other GIST’s.


    in reply to: MPFlaga's Random Play Code #3493

    refer to the trouble shooting section of it has several steps to investigate.

    That sketch will continuously play random tracks, back to back.

    in reply to: compile error: variable ‘bitrate_table’ must be const #3491

    I am not really able to tell you for MAC, or so for Linux, as these systems have AVR-GCC as a separate module that may be upgraded independantlly from the IDE downloaded from

    Where for window installs the AVR-GCC is included and have seen this library successfully compile for:

    1. arduino-1.0.5
    2. Arduino-1.0.5-ERW
    3. arduino-1.0.5-r2-windows
    4. arduino-1.0.6
    5. arduino-1.5.2-windows
    6. arduino-1.5.5
    7. arduino-1.5.5-r2
    8. arduino-1.5.6-r2
    9. arduino-1.5.7
    10. arduino-1.5.8
    11. arduino-1.6.0
    12. arduino-1.6.3-windows
    13. arduino-nightly.2014_11_03
    14. arduino-nightly.2015_06_30
    15. arduino-nightly.2015_08_29
    16. arduino-nightly.2015_10_30
    17. arduino-nightly.2015_11_02
    18. arduino-nightly.2016_02_02

    I also recall that around IDE 1.5.7(ish) the avr-gcc was updated to 4.7 and looks like somewhere in the 1.6.x they upgraded again to 4.8.

    to find out the version you are using, enable the verbose for compiling. Then using the log displayed from a compile locate the directory of avr-g++ and run it manually from a command prompt with the –version command.


    C:\projects\Arduino>C:\projects\Arduino\arduino-nightly.2015_11_02\hardware\tools\avr\bin\avr-g++.exe –version
    avr-g++.exe (GCC) 4.8.1
    Copyright (C) 2013 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO

    I also recommend reviewing Andy’s Workshop, he has several articles providing transition guidance between versions of avr-gcc. search his website for the version you may have or desire.



    in reply to: compile error: variable ‘bitrate_table’ must be const #3488


    I am not able to reproduce your experience with 1.6.6(arduino-nightly.2015_11_02) or with 1.6.7(arduino-nightly.2016_02_02). I cut and pasted your line from above and it compiled successfully.

    If you are Linux you may be running a newer version of avr-gcc. In windows the IDE supplies the avr-gcc and for both of the above it is avr-g++ (GCC) 4.8.1, but with linux you may have a more recent version of avr-gcc.

    in reply to: SDconflict Gameduino2 and Sparkfun MP3 shield #3311

    Referring to and

    There are several pins that are attempting being used by both shields.

    refer to they had similiar pin conflicts



    11inSPI MOSI
    12outSPI MISO
    13inSPI SCK
    8inGPU SEL*
    9inSD SEL*


    vs the SFEMP3Shield

    2  out MP3-DREQ*
    3  in  MIDI RX
    4  in  GPIO1
    6  in  MP3-CS
    7  in  MP3-DCS
    8  in  MP3-RST*
    9  in  SD-CS*
    11inSPI MOSI
    12outSPI MISO
    13inSPI SCK

    it is OK for MOSI,MISO and SCK to share.

    But rest 2, 8 and 9 are problems you will need to over come.


    In this case:

    Both shields are Wired to use INT0 on D2. The MP3 uses it as an interrupt. Not sure if the G2 does. Its code is very extensive. and I see it is not well documented as to changing its pins.

    Refer to it explains how to move pins. Also refer to


    The SFEMP3 has all its pins defined in the SFEMP3ShieldConfig.h. You can easily specify any changes you make.


    I would move the SFEMP3’s D2 to D3. Then make sure that SJ2 is open. MIDI-RX is not needed and we don’t want it to interfere. Then move SD-CS from D9 to D10 and move MP3-RST from D8 to A3.

    Then update SFEMP3ShieldConfig.h correspondingly. That should remove any conflicts.


Viewing 15 posts - 16 through 30 (of 204 total)