Sensor Data From an Arduino UNO to a Computer

Wireless & IoT
1

So looking from my title, my project seems very simple, but I have a very peculiar problem.

First off I have an Arduino UNO connected to an XBee Pro S1 through a Sparkfun XBee shield. I have configured the XBee to communicate with a coordinator XBee of the same model (configured as a coordinator using XCTU and in API mode) on the Sparkfun XBee Explorer dongle. My problem is that every time data is sent over serial from the Arduino-connected XBee I get somewhat ordered random characters before and after each transmission.

My code on the Arduino is:

int data[7];

void setup()
{
  //Create Serial Object (57600 Baud)
  Serial.begin(57600);
  
  //initialize all data values
  data[0] = 1261;
  for(int i = 1; i < 7; i++)
    data[i]=0;
    
}

void loop()
{
 //delay for 1Hz
 delay(1000);
 
 //loop for test incrementing of dummy values
 for(int i=1; i<7; i++)
 {
   data[i]++;
 }
 
 //declare toSend String
 String toSend;
 
 //loop for displaying values
 for(int j=0; j<7; j++)
 {
   String toConcat = String(data[j]);
   toSend = toSend + toConcat + ",";
   
 }
 
 //endl at last element of array
 Serial.println(toSend);
}

My output for the first couple seconds through the XBee connected to the explorer is:

y~ T 1261,1,1,1,1,1,1,

ï~ S 1261,2,2,2,2,2,2,

ê~ S 1261,3,3,3,3,3,3,

ä~ S 1261,4,4,4,4,4,4,

Any help would be appreciated.

2

First, do a direct connect from Arduino to PC without the XBees. Get this working correctly.

Then insert the XBees for a wireless link.

Those first characters are Extended ASCII (8bit instead of 7-bits). So check your code.

3

When I connect the Arduino directly to the PC, I get the correct output (1261,1,1,1,1,1,1, ect.), but I do have both XBees set to have 8 data bits. Could that be the problem?

4

raydar670:
… I have configured the XBee to communicate with a coordinator XBee of the same model (configured as a coordinator using XCTU and in API mode) on the Sparkfun XBee Explorer dongle. My problem is that every time data is sent over serial from the Arduino-connected XBee I get somewhat ordered random characters before and after each transmission.

The coordinator outputting API packets would explain that. The payload of the packet (your toSent string) would show through in the monitor, but the other bytes in the API packet looks like ordered (as most are static) but unintelligible characters to the human untrained eye (unless your name is Neo). However, it would look different than the output that you showed later in your post. API-packets are much longer than those 4-odd bytes preceding your dummy values. Not sure what goes on there. Any chance you have a non-english Windows or other characterset/language set in the Arduino IDE preferences?

Edit: Could be that some bytes in the API packet do not have a ASCII-symbol assigned to them and are simply not shown. It would be better if you could use a serial terminal program that shows all received bytes as hexadecimal values, AND as normal text. The Arduino serial monitor fall seriously short in this regard. It does not show every byte that comes in.

5

Thanks for your reply. I’ve downloaded Realterm to read the output, and here’s what I get when put to Ascii mode:

~  A 1261,1,1,1,1,1,1,

~  A 1261,2,2,2,2,2,2,

ü~  A 1261,3,3,3,3,3,3,

ö~  A 1261,4,4,4,4,4,4,

ð~  A 1261,5,5,5,5,5,5,

ê~  A 1261,6,6,6,6,6,6,

ä~  A 1261,7,7,7,7,7,7,

Þ~  A 1261,8,8,8,8,8,8,

Ø~  A 1261,9,9,9,9,9,9,

Ò~  A 1261,10,10,10,10,10,10,

â~  A 1261,11,11,11,11,11,11,

Ü~  A 1261,12,12,12,12,12,12,

Ö~  A 1261,13,13,13,13,13,13,

Ð

And here’s what I have with Hex mode:

2C 0D 0A 04 7E 00 18 81 00 00 40 00 31 32 36 31 2C 32 2C 32 2C 32 2C 32

2C 32 2C 32 2C 0D 0A FD 7E 00 18 81 00 00 42 00 31 32 36 31 2C 33 2C 33

2C 33 2C 33 2C 33 2C 33 2C 0D 0A F5 7E 00 18 81 00 00 40 00 31 32 36 31

2C 34 2C 34 2C 34 2C 34 2C 34 2C 34 2C 0D 0A F1 7E 00 18 81 00 00 41 00

31 32 36 31 2C 35 2C 35 2C 35 2C 35 2C 35 2C 35 2C 0D 0A EA 7E 00 18 81

00 00 40 00 31 32 36 31 2C 36 2C 36 2C 36 2C 36 2C 36 2C 36 2C 0D 0A E5

7E 00 18 81 00 00 40 00 31 32 36 31 2C 37 2C 37 2C 37 2C 37 2C 37 2C 37

2C 0D 0A DF 7E 00 18 81 00 00 40 00 31 32 36 31 2C 38 2C 38 2C 38 2C 38

2C 38 2C 38 2C 0D 0A D9 7E 00 18 81 00 00 40 00 31 32 36 31 2C 39 2C 39

2C 39 2C 39 2C 39 2C 39 2C 0D 0A D3 7E 00 1E 81 00 00 40 00 31 32 36 31

2C 31 30 2C 31 30 2C 31 30 2C 31 30 2C 31 30 2C 31 30 2C 0D 0A E3 7E 00

1E 81 00 00 40 00 31 32 36 31 2C 31 31 2C 31 31 2C 31 31 2C 31 31 2C 31

31 2C 31 31 2C 0D 0A DD 7E 00 1E 81 00 00 40 00 31 32 36 31 2C 31 32 2C

31 32 2C 31 32 2C 31 32 2C 31 32 2C 31 32 2C 0D 0A D7 7E 00 1E 81 00 00

40 00 31 32 36 31 2C 31 33 2C 31 33 2C 31 33 2C 31 33 2C 31 33 2C 31 33

2C 0D 0A D1

I tried to time both of them so there would only be 13 transmissions. Also I output the Hex code where there would be spaces in between because I assume they’d be easier to read.

Thanks for your help.

Sidenote: Is there a way to have a “show spoiler” button so it’s not a pain to scroll through the post?

6

As I suspected in that edit in my post. Those are multiple API receive packets. They start with each hex value 7E. To avoid this set the Coordinator to AT mode. But then you will not know from which module the data came from (if you have more than one transmitters).

This is what the API frames interpreter function of Digi’s XCTU NextGen progam returns:

RX (Receive) Packet 16-bit Address

7E 00 18 81 00 00 42 00 31 32 36 31 2C 33 2C 33 2C 33 2C 33 2C 33 2C 33 2C 0D 0A F5

  • Start delimiter: 7E

  • Length: 00 18 (24)

  • Frame type: 81 (RX (Receive) Packet 16-bit Address)

  • 16-bit source address: 00 00

  • RSSI: 42

  • Options: 00

  • RF data: 31 32 36 31 2C 33 2C 33 2C 33 2C 33 2C 33 2C 33 2C 0D 0A

  • Checksum: F5

The Arduino Serial monitor, and Realterm in Ascii mode is able to show the comma seperated numbers, and the end-of-line and carriage-return codes in the stream. All that other garbage is just the header and Checksum of the packet displayed out-of sequence. This is the translation of the RF data line into Ascii characters. Looks familiar:

1261,3,3,3,3,3,3,

“show spoiler”

No, never seen it on the forum. And tried the tags the other day, but no go. Something to request to Sparkfun I guess. But the [ /code] tags do collapse the windows. But then other BBcodes for text formatting do not work in it.

7

Ok, that’s good that we know the problem is API mode, but I do eventually want to be able to send commands between 3 XBees to start and stop transmission. Also, ideally, I was hoping to take advantage of the sleeping modes built into the XBees, but I’m not sure how to do that. Also, if API mode sends those header and Checksum values how do I actually use API mode to get clean data?

Thanks and I’ll test out the coordinator in AT mode to see if that changes anything.

8

Well API is not a problem, it is a feature. :wink: You can either study the Xbee series 1 manual, and learn how to interpret API packets( and code this into your sketch), or implement one of several Xbee libraries for Arduino to do it for you. No, make that you should study the xbee manual anyway. As sleep modes are complicated enough already.

However, you are getting both the serial output of the Arduino AND of the Xbee in your serial monitor/realterm terminal. This is nice for debugging. But not if you want only the Arduino to communicate with the pc, and the arduino to interpret the API packet. As they might talk at the same time and disrupt the others communication. To seperate the Xbee communication, there is a switch on the shield (and there are some solder jumpers to bridge). Then you can use a software serial library (using digital pins D2 and D3 iirc) to communicate with the xbee.

9

I’ve looked at some example code and got SoftwareSerial working. I had an interesting problem though. Because I don’t have a separate breakout yet for the XBee I’ve been using an UNO with that SparkFun shield to get the code working. The final assembly will be an Ardweeny running on 3.3V so I absentmindedly switched my UNO (this clone has a switch for 3.3V and 5V) which messed with the data transmission over the digital pins because of the level shifting done by the shield.

As for API mode I read a bit from the XBee S1 manual, and it looks quite complicated. If I understand correctly a Coordinator in API mode can send AT Commands which change the settings of the XBee. I’m going to be configuring the XBees beforehand so that shouldn’t be needed. It also looks like that the Coordinator can send out transmit requests. Are these automatic or controlled in code? I might have to do some more reading, but from what I understand right now API mode is required to send commands between more than two XBees. Commands might not be the right language, but I would like to control two Arduinos (Ardweenies) remotely and, through serial, start and stop data collection and transmission of the data. I think API mode is required to do this because the Coordinator needs to discriminate between the two End Devices.

As for using API mode, I found a library in Processing that could be of use ([link), but first I’d like to make sure that API mode is even required for this. I’d like to keep the system as simple as possible. Sorry if I sound redundant, but I’m just trying to cover my bases as I am quite new at Serial communication and using XBees.](XBee API Library for Processing – Rob Faludi)

10

Yeah, it’s not a simple subject. It might require 2, 3 or more times to read and understand. Also, there have been some manual revisions over the years. Make sure your manual reflects the firmware that the Xbees have.

An Xbee does not need to be in coordinator mode. They work without establishing a master/slave hierachy by default. (peer to peer mode by default) Any Xbee can send configuration commands to a another remote Xbee, but it must be sent over serial in API mode. It cannot be done in the regular AT command-mode. The commands are basically the AT commands as typed in command-mode, but encapsulated in the API packet frame. If you want to send serial data over to another Xbee, or when receiving data from other Xbees, then the API-identifier byte value will be different (and the rest of the packet payload. The nice thing about API packets is you know who sent them because the source adress is contained in it. You cannot know who sent the data in transparent mode. Of course you can enter AT-command mode each time and change the DL and DH registers to send to a different Xbee, but you can’t tell where in-comming bytes are from. To be honest, I never tested if another Xbee data could be received while in transparent mode. But there is simply no way of knowing the origin, even if it was received. I suspect the Xbee simply ignores any incomming transmissions that is not from the DH,DL address.

I do not understand what you mean with transmit request commands being automatic or controlled. It is a request from the Arduino (or whatever microcontroller/pc) to the local XBee module to send the data to the adress that is in the packet. The sending Xbee may have to wait for the RF channel to be free to do so. The modules send each other acknowledge messages over the RF link to enable the sending Xbee to know the transmission or remote configuration command packet was received and what the result was. If this isn’t received the sending Xbee does a few retries. (optional) The sending XBee then a Transmit Status API packet back to the microcontroller/pc if it was succesfull or or not. Obviously receive API packets do not come with another status report, as they already contain the transmission. If API packets sent on the serial port are somehow corrupted and do not match the checksum value at the end then they are simply ignored by the XBee module.

PS: “Processing” seems to be a different programming language as Arduino. I know they exist for Arduino for sure. But I personally have used these for arduino yet. As I only got an arduino bord recently. This should get you started in the right direction: http://code.google.com/p/xbee-arduino/

But there might be other kind of Arduino XBee libraries.

11

Ok, I’ve done a little more reading, and I think I’ll do without having an XBee in coordinator mode just to simplify the network (also if the coordinator goes down the whole network goes down so that would be bad). I still need to do more research about API mode, but thank you for your clarification. I do know that I’ll have to deal with addressing to differentiate between the two Arduinos when sending them commands. Quick clarification question, although you might have already answered it, can XBees send address specific transmissions in AT mode? My guess would be no, but just asking to double check.

On a happier note, I just got some XBee breakout boards which will allow me to connect to the Ardweenies without jerry-rigging the XBee Explorer board I have.

So I have done some testing with three XBees in transparent (AT) mode, and it doesn’t seem that there is any interference. Both transmissions get through. Now I think the things for me to decide is to see whether I should differentiate commands by figuring out XBee addresses or manually parsing what’s coming through serial and just have different commands for each Ardweeny.

12

raydar670:
…Quick clarification question, although you might have already answered it, can XBees send address specific transmissions in AT mode? My guess would be no, but just asking to double check. …

You would have to get into AT command mode (with the +++ procedure) and change the DL and DH registers each time you would want to address a different module. The waiting period after the +++ sequence can be reduced, so this does not have to slow down your network. API mode is more flexible when addressing different modules, as you only need to change some bytes in the packet header. But this header overhead might become a substantial part of your total bandwidth if your actual data payload is only few bytes each time. You will have to make some calculations which method is more efficient in regards to bandwidth use, or if you need to frequently address different modules on the fly.

13

Oh ok, that makes sense. Right now I’m leaning towards using API mode and just manually parsing through the API packet headers (it doesn’t look too bad especially with all the documentation). But I have made a breakthrough in the configuration of the three XBees. Right now I have one connected to my computer which is receiving the output from two others connected to Ardweenies with sensors. The one connected to the computer will be the only one issuing commands, so I don’t want any cross-talk between the XBees connected to the Ardweenies. I finally figured out how to broadcast commands from the computer to the XBees and how to use the MY parameter to prevent cross-talk between the XBees on the Ardweenies.

Thanks for all your help. I’m think I’m pretty close to being done with the networking aspect of this project.

Quick note–the reason I don’t mind having the commands being sent to both of the Ardweeny XBees is that I can just use different ASCII characters to trigger each of them.