[Michael P. Flaga]

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:

Serial.begin(9600);

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++) {

Serial.print(“arraydata[“);

Serial.print(channel);

Serial.print(“]=”);

Serial.println(arraydata[channel]);

}

}

void loop() {

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

 

}

with the following results:

Hit any key to continue.

arraydata[0]=0

arraydata[1]=255

arraydata[2]=-256

arraydata[3]=-1

arraydata[4]=0

 

[Michael P. Flaga]

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

http://stackoverflow.com/questions/25314702/data-in-sd-card-convert-it-to-array-arduino

also

http://forum.arduino.cc/index.php?topic=60939.0

 

 

[Michael P. Flaga]

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.

[Michael P. Flaga]

Extrace from http://www.vlsi.fi/fileadmin/software/VS10XX/vs1053b-patches.pdf

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 vs_plg_to_bin.pl 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>

[Michael P. Flaga]

Please see step #2 in the documentation at http://mpflaga.github.io/Sparkfun-MP3-Player-Shield-Arduino-Library/#Installation

The plugin patches are located in the repo at: https://github.com/mpflaga/Sparkfun-MP3-Player-Shield-Arduino-Library/tree/master/plugins

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.

[Michael P. Flaga]

I see right there in my documentation of the code at http://mpflaga.github.io/Sparkfun-MP3-Player-Shield-Arduino-Library/class_s_f_e_m_p3_shield.html#aed2dc5833ab0fa71c2994cf89e598f35

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.

[Michael P. Flaga]

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

MP3player.setVUmeter(1);

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.

• This reply was modified 8 years, 1 month ago by Michael P. Flaga.

[Michael P. Flaga]

 

You can try to increase the SFEMP3Shield::mp3DataBuffer from 32 to larger values. The minimum needs to be 32.  http://mpflaga.github.io/Sparkfun-MP3-Player-Shield-Arduino-Library/class_s_f_e_m_p3_shield.html#ab1027c13d5feef5d3b928f4d53e1f602

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.

[Michael P. Flaga]

I would recommend starting with the first code shown at

https://learn.adafruit.com/adafruit-microphone-amplifier-breakout/measuring-sound-levels

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

 

[Michael P. Flaga]

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.

 

[Michael P. Flaga]

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.

Thanks.

[Michael P. Flaga]

refer to the trouble shooting section of http://mpflaga.github.io/Sparkfun-MP3-Player-Shield-Arduino-Library/ it has several steps to investigate.

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

[Michael P. Flaga]

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 Arduino.cc.

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.

example:

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
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I also recommend reviewing Andy’s Workshop http://andybrown.me.uk/2015/03/08/avr-gcc-492/, he has several articles providing transition guidance between versions of avr-gcc. search his website for the version you may have or desire.

 

 

[Michael P. Flaga]

hmm,

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.

[Michael P. Flaga]

Referring to http://excamera.com/sphinx/gameduino2/ and http://cdn.sparkfun.com/datasheets/Dev/Arduino/Shields/MP3%20Shield-v13.pdf

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

refer to http://www.billporter.info/forum/topic/host-running-less-than-16mhz/#post-3309 they had similiar pin conflicts

 

Gameduino2

11inSPI MOSI
12outSPI MISO
13inSPI SCK
8inGPU SEL*
9inSD SEL*
2outINTERRUPT*
A2outACCEL_Z
A1outACCEL_Y
A0outACCEL_X

 

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 https://www.youtube.com/watch?v=behMgV3tUr4 it explains how to move pins. Also refer to http://www.freetronics.com.au/pages/stacking-arduino-shields.

 

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.

 

[Author]

Posts