[SOLVED] Serial Command + LED pixels issue

Hi folks!

For a school project I’m working on an Arduino controlled LED crowd ball.

The prototype consists of:

  • Arduino Uno
  • Wireless Proto Shield + XBee S1
  • 5 Bliptronics LED pixels: I use (a slightly adapted version of) the library found in the link for controlling the LEDS.

The prototype receives the data sent with:

  • The serial monitor of Arduino 1.0.2
  • MacBook running OSX 10.8.2 Mountain Lion
  • Explorer Shield + XBee S1

For the data transmission I use this library: Arduino SerialCommand

What I want to do is change the parameters of the LED controls by sending them wirelessly to the prototype. So far I managed to get the LED control working when it’s connected through USB. The XBee’s are also able to communicate to each other cause the example from the SerialCommand worked flawlessly and I get feedback on both the prototype as well as the serial monitor:

The problem is that there seems to be some kind of interference when both are combined. I took parts of both examples (LED-pixels and SerialCommand) and mashed them up to create the program I wanted, but there is no response when I send my parameters to the prototype. The LEDs don’t start to blink with the tempo I’ve sent and the monitor stays blank, while it should return the parameter I had sent as input.

Does anyone know what I am doing wrong or how I can fix this?

Thanks in advance!

SOLUTION: Use the FastSPI library in stead of the original Bliptronics one…

Btw, this is the code I uploaded to the Arduino Uno:

#include <SerialCommand.h>                 //Wireless Library
#include <BLIP_LEDS_SPI_LPD6803.h>         //LEDS Library

#define NUM_LEDS 5                        // Set the number of LEDpixels in use here


SerialCommand sCmd;                        // The demo SerialCommand object

int Deelay;

void setup() {
  //Wireless
  Serial.begin(9600);
  // Setup callbacks for SerialCommand commands
  sCmd.addCommand("DEL",     Delay);  // Reads the BPM
  sCmd.setDefaultHandler(unrecognized);      // Handler for command that isn't matched  (says "What?")
  Serial.println("Ready");
  //LEDS
  BL.setLeds(NUM_LEDS);
  BL.init();                              // SPI interrupt will now send out data to LEDs. This happens in the background, pretty fast.
}

void loop() {
  sCmd.readSerial();     // We don't do much, just process serial commands
  strobe(Deelay);
}

//WIRELESS FUNCTIONS
void Delay() {
  
  char *arg;

  Serial.println("We're in Delay");
  arg = sCmd.next();
  if (arg != NULL) {
    Deelay = atoi(arg);    // Converts a char string to an integer
    Serial.print("Delay is: ");
    Serial.println(Deelay);
  }
  else {
    Serial.println("No arguments");
  }
}

// This gets set as the default handler, and gets called when no other command matches.
void unrecognized(const char *command) {
  Serial.println("What?");
}

//LED FUNCTIONS
void blank()                                      //Used to load all LEDs with no color value, clearing LEDs
{
for(byte Counter=0;Counter < NUM_LEDS; Counter++)
    BL.setPixel(Counter,BL.color(0,0,0));
    BL.show();
}  

void strobe(int flash_rate)                       //strobe effect
{
  for(int i=0;i < NUM_LEDS; i++)
  {  
    BL.setPixel(i,BL.color(31,31,31));
  }
  BL.show();
  delay(flash_rate);
  
  blank();
  BL.show();
  delay(flash_rate);
}

I think the problem is that both the XBee and the LEDs send their data through serial communication and the signals get mixed up in the Arduino. Is there a way I can keep these separated? Addressing each communication stream to a different channel or something?

I think the problem is that both the XBee and the LEDs send their data through serial communication

Not according to the web page for the LEDs. They use something like I2C to communicate with the LEDs.

You haven't said anything about the shield, except its generic name, that the XBee is attached to.

I use (a slightly adapted version of) the library found in the link for controlling the LEDS.

You don't think that we need to know what "adaptations" you made?

PaulS:

I think the problem is that both the XBee and the LEDs send their data through serial communication

Not according to the web page for the LEDs. They use something like I2C to communicate with the LEDs.

I assumed so cause the monitor stopped sending the right feedback. The monitor should say “Ready” when it’s ready to receive commands, but after startup it only shows “Re” which is sometimes followed by some gibberish. After that the LEDs don’t respond to my commands and the monitor doesn’t receive any feedback from any commands. The Baud-rate is correct so that shouldn’t be the problem…

PaulS:
You haven’t said anything about the shield, except its generic name, that the XBee is attached to.

It’s the standard wireless protoshield (link) put on an Arduino Uno that receives the data to controls the LEDS. The explorer shield that is used to send the data is one of Sparkfun. (link)

PaulS:

I use (a slightly adapted version of) the library found in the link for controlling the LEDS.

You don’t think that we need to know what “adaptations” you made?

The standard library was an outdated file that wasn’t compatible with Arduino 1.0.2, it only worked with older versions of the Arduino software.
The only thing I changed was in the beginning of the .h-file:
Original:

#ifndef __INC_SPIRGB_H
#define __INC_SPIRGB_H
#include <HardwareSerial.h>
#include <WProgram.h>
#include "string.h"
#include <avr/pgmspace.h>

Adapted:

#ifndef __INC_SPIRGB_H
#define __INC_SPIRGB_H
#include <HardwareSerial.h>
#if defined(ARDUINO) && ARDUINO >= 100
#include "Arduino.h"
#else
#include "WProgram.h"
#endif
#include "string.h"
#include <avr/pgmspace.h>

And that made the LEDs work perfectly in the latest version of Arduino.

I think that perhaps it’s time for you to measure free memory. Perhaps the issue is that you don’t have any (or enough).

It seems like it has nothing to do with the XBee's or anything of the wireless communication, because I just discovered that the problem is exactly the same when controlled via USB commands... So it must be a conflict between the Serial Command and LED-pixels libraries, no?

PaulS: I think that perhaps it's time for you to measure free memory. Perhaps the issue is that you don't have any (or enough).

Do you mean the sketch size? Because the program is only 5.788 bytes (of a 32.256-byte maximum)...

Do you mean the sketch size?

No, free RAM.

AWOL:

Do you mean the sketch size?

No, free RAM.

I managed to get the program working when i left out these two lines:

BL.init(); (Located in the void setup, library says about this line: "SPI interrupt will now send out data to LEDs. This happens in the background, pretty fast.")
strobe(bpm); (Located in the void loop, this recalls a function declared in the sketch.)

In that case I got the correct feedback and 1666 bytes of free RAM:

Without the 'strobe' function in only makes one loop:

And when the BL.init(); command is missing all the monitor says is 'ReRe'...

So it all seems to work fine, as long as there are no functions called in the loop and the data isn't sent to the LEDs.

Moderator edit: Code rendered legible.

So it all seems to work fine, as long as

it does nothing. Well, that's a strange definition of "works fine", but if you're happy, I'm happy.

PaulS:

So it all seems to work fine, as long as

it does nothing.

My point exactly.

I only said that because the problem must be caused by one of the two lines in the code.

I’ve found the cause of the issue on this URL Rainboard SPI LED Serial Conflict - Isomorphic Keyboard Research

The LED-library uses a lot of interrupts, also interrupting the serial rx causing the data loss…

The site stated this could be circumvented by using the SoftwareSerial library. But can I still send commands through the monitor via USB or XBee in that case?

But can I still send commands through the monitor via USB or XBee in that case?

Not through USB, but via XBee if the XBee is connected to other pins.

Of course, that site is full of crap. SoftwareSerial uses interrupts, too. At least as heavily as HardwareSerial, if not more so.

Looks like the original Bliptronics library was the cause of the problem. I use the FastSPI library instead now and it all works perfectly. Thanks for everyone's feedback!