[Bill]

You are using a version of Arduino that is still very much a BETA version. Drop down to the stable version 1.0.3 and see if the error persists.

Seems this is a noted problem with the BETA version already:

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

[Bill]

Did you ever get this working? If it’s working with one slave I can’t imagine why it wouldn’t work with the other.

[Bill]

No idea haven’t tested it on the new platform yet.

[Bill]

lystick = (ps2x.Analog(PSS_LY), DEC);

should be

lystick = ps2x.Analog(PSS_LY);

[Bill]

Cremo,

I’m recovering from surgery and I’m also getting married in 3 weeks. It may be a while before I can help you in such detail.

[Bill]

Check your baud rate settings in the serial monitor and make sure it matches the sketch. Also make sure you have the right board type selected.

[Bill]

Make sure you are trying all the steps in the troubleshooting guide. It could be a pull-up problem.

[Bill]

I don’t remember what the rules are but the Arduino environment handles strings in a funny way. Can you try using an array of characters instead? If you are still having problems with this I’ll have to sit down one weekend and try replicating your project. I wouldn’t have time for that for a few months though, sorry.

[Bill]

Sorry for the late reply chiliman, I’ve been recovering from surgery for a week and preparing to get married in 3 weeks.

Did you sort this all out?

To help you and others that find this, you shouldn’t ever try to use ET over a serial connection you are also using print() statements on. It’s like trying to talk on a phone while a fax is transmitting on the line.

Instead either use a software serial version of ET on different pins and print() out of the main serial port or vise-versa.

[Bill]

So have you gotten it figured out?

Sorry for the late reply, I’m recovering from surgery.

[Bill]

Have you compared the pin out of the two shields? IE is there a pin sharing conflict?

[Bill]

Have you tired all the troubleshooting steps?

[Bill]

Nader,

Give us more details on the types of sensors you are using and what code runs them. Are you sure they are analog sensors and not PWM output? I can see a problem trying to use PWM input sensors with the MP3 library as there would be simultaneous interrupt conflicts. However pure analog sensors should not interfere with the MP3 functions.

Try wrapping your sensor code in the MP3 data stream functions, like this:

 

 //disable interrupts to avoid collisions on the SPI bus between this code //and the MP3player library
  MP3player.pauseDataStream();

  //Sensor code here, for example if it's a PWM sensor
  digitalWrite(TRIG_PIN, HIGH); // Send a 10uS high to trigger ranging
  delayMicroseconds(10);
  digitalWrite(TRIG_PIN, LOW);

  // Now ping for objects
  int distance = pulseIn(ECHO_PIN, HIGH);        // Read in times pulse

  //enable interrupts to resume sending data to MP3 shield
  MP3player.resumeDataStream();

That’s what it would look like if you had a PWM based sensor.

[Bill]

Sorry, the confusion stems from two developers on this library. I wasn’t aware Michael put this in the example. The original intent for the said function is as I said, to avoid data collisions. Using it to pause the music is a side effect (if you stop the data stream long enough eventually the decoder runs out of song to decode).

I’m going to suggest the library get a additional and discrete “pauseMusic” function instead to clarify the difference between communication collision management and song controls. I’ll work with Michael on that. He should see this message and respond here, or I’ll email him otherwise.

[Bill]

PauseDataStream() should NOT be used to pause music. It is intended to simple free up the SPI bus for other uses with no risk of data collision. Using it to pause music will produce unexpected results.

[Author]

Posts