I am currently working on robot and utilize Xbee communication to send commands to the robot from Matlab via a Sparkfun USB Xbee explorer connected to to my computer and the robot's Xbee sits on a breadboard adapter and I use jumpers to connect the necessary pins. However, in the early stages I have run into some issues when trying to get the Arduino Mega 2560 to receive said commands. Mind you, I have been able to get the robot to transmit data to the computer just fine, to both Matlab as well as XCTU. I have also successfully been able to create this TX/RX command structure using a Sparkfun Xbee shield sitting on a Arduino Uno and the same PC setup, so I know it is something with my Mega's setup.
Here is a more detailed description of my setup:
Matlab or XCTU --> USB --> XBEE <===> XBEE <-- Arduino Mega 2560 (D14,D15, 3.3V, GND)
- Both xbees have 10ed firmware on them and are operating with the default configurations, same PAN ID, channel, baud(9600), pull-up resistors enabled, etc.
Here is what I have tried in terms of troubleshooting this issue.
- I have tried just about every PCINT digital pin combination on the mega, even swapped the pins in each run to make sure I connected the Xbee to the Mega properly
- I have tried specifying the destination addresses in the Xbee firmware
- I have tried configuring the Mega's Xbee to broadcast a global message all Xbee's can read
- I have scoped the data lines and have come up with a few interesting wave forms (below)
This image shows the signal I am getting from the Uno when probing the digital pin breakout. (I know its at 5V but it still worked and I think there is something wrong with my Sparkfun shield).
This image shows the signal I am getting from the Uno when probing the corresponding pin on the micro itself (pin4 aka D2)
These two traces from the Uno appear to be exactly the same, aside from the slight warping of the display of the signal in the micro's pin trace.
This image shows the signal I am getting at the breakout pin of the Mega which is coming directly from the Xbee. As you can see it is the same message I get from probing the Uno, and at ~3.3V.
Now this is where it gets interesting, this is the trace from reading the Mega's micro pin. It seems there is an extra bit of data tacked onto the end of the message. From what it looks like, it seems to be tacking on another byte of data from somewhere. I replicated this result multiple times to verify it wasn't a one time thing.
Here is the code I am using: (mind that I have also tried to run this without the pinMode assignments as well as with every combination of INPUT and OUTPUT assignments for each pin)
#include <SoftwareSerial.h>
// Xbee serial setup
SoftwareSerial xbee (14,15); // RX,TX
// state of received data compared to expected
boolean startState = false;
// stores incoming data
String response = String("");
// data compare
String expected = String("START");
void setup() {
pinMode(2, INPUT);
pinMode(3, OUTPUT);
// begin xbee com
xbee.begin(9600);
}
void loop() {
// loops through checking received buffer for new data to compare to expected
if(!startState){
if(xbee.available())
{
while(response.length() < expected.length()) {
response += (char) xbee.read();
}
// If we have a match, success
if( response == expected) {
startState = true;
}
}
delay(100);
}
// If we have success, start sending data every second
if(startState) {
xbee.print("running...");
delay(1000);
}
delay(100);
}
So in all I think there is something I am not doing properly in my setup on the Mega or possibly, but less likely, there is an issue with my Mega. I have not tried to replicate these results on a different one since I only have one Mega at the moment.
On a side note. I have also encountered the issue where I am unable to change configuration parameters using XCTU. For instance, I will change the DL or RO parameters and it will show up as changed. However, when I refresh the list, the parameter I changed reverts back to the previous value I just overwrote. I even have updated the firmware and unchecked "Force module to keep its current configuration". Missing something here as well.
Thank you for any help,
--Larry
