XBee: API and AT modes speed comparison

Projects Networking, Protocols, and Devices
1

Hello guys,

I am working on a project of a vibration sensor wireless network. Have two Arduinos UNO with MPU6050 and XBee S1 sampling data and transmitting to a coordinator, which is an Arduino UNO with a XBee S1 connected to my PC via USB, that by its turn sends the data to PC and MatLab plots graphs with it in real time.

My doubt is related to the communication modes I can use: API and AT.

  1. First of all, a very basic doubt: Do you know if it is possible to build a three node communication using AT? I know I can`t just say to sensors -"Scream all your data to coordinator as you sample", cause this would create packet crashes, but is there anyway to coordinate this transmission using AT in a reasonable speedy way? This question is just to see if I am in the right track, since I have eliminate the possibility of using AT from the very beginning because couldn't find anyone saying this would be possible.

  2. Is there any difference in terms of transmission speed between API and AT? For what I have learned, the way the XBee "physically" transmits is the same for both modes and the difference relies on how the code treats the data sent and received: while in AT I have just to say Serial.print and Serial.read in API I have to build/read the entire package. So, supposing I am sending the number "1" using both methods, would one be faster then another, in terms of transmissions completed per, lets say, second?

  3. All these questions are because I am facing a problem with my project. I was trying to reach sampling rates (in other words, I needed to sample from MPU) between 100Hz and 10000Hz. BUT, the coding I have produced, with my very limited knowledge, using the XBee API library, only allows me to reach around 40 Hz. The code of sensor basically follows the logic:

  • Sample data and keep in an array;
  • Listen for data request from coordinator: if yes send array, if not do another sampling
    The code from coordinator just alternate data request between the two sensors.
    I am kind lost because I cant identify if the capping is on my code or on hardware specifications. Tried to read the datasheets but it seems to arid for me yet, still trying to extract useful information about this matters.

I am not including my codes because the forum says I am exceeding 9000 characters, but I am attaching it. I think it is not necessary to read it to answer the questions, but nonetheless will include it if anyone is interested. Please consider this is my first Arduino project and this is by far not the final version, as I am still experimenting on it (so there might be some variables declared which are not being used in the code), although I think the gross structure is there, since it works (but far from the speed I intended).

Regards

*Obs: Tx is acctually the code for the Receiver (coordinator). Rx is the code for the Transmitter (sensors). Sorry for this confusion.

XBee_Tx_-tentativa_1-MODIFICADO-_2_sensores.ino|attachment (9.68 KB)

XBee_Rx_-tentativa_1-MODIFICADO_-2_sensores-_simplex.ino|attachment (4.9 KB)

2

Do you know if it is possible to build a three node communication using AT?

It is, but it is not easy. You have to have each sender send some ID along with the data. You have to have each receiver receive all messages, and then decide whether it is the correct recipient.

Why bother, when API mode means that the XBee itself can handle the sending of data only to the one recipient?

since I have eliminate the possibility of using AT from the very beginning because couldn't find anyone saying this would be possible.

Well, now you have. But, still, AT mode should be eliminated. It puts the burden of knowing who is sending data, and to whom, on the Arduino rather than the XBee.

  1. Is there any difference in terms of transmission speed between API and AT?

No. A byte takes a fixed amount of time to send. It does not matter whether that byte is part of an API packet or part of an AT packet.

For what I have learned, the way the XBee "physically" transmits is the same for both modes and the difference relies on how the code treats the data sent and received

Correct, except that there are two microcontrollers involved - the Arduino and the one on the XBee. In AT mode, the XBee microcontroller passes on all data to the Arduino. In API mode, it does not. It passes on only the data that it is supposed to receive.

while in AT I have just to say Serial.print and Serial.read in API I have to build/read the entire package.

Or, use Andrew Rapp's XBee library, and let it do the work of building the packet.

So, supposing I am sending the number "1" using both methods, would one be faster then another, in terms of transmissions completed per, lets say, second?

The two packets will not be the same size, so sending an API packet will take longer than sending an AT packet. But, the Arduino may have less work to do, dealing with packets meant for other nodes, so you can't really compare speeds directly. Unless there are only two nodes...

  1. All these questions are because I am facing a problem with my project. I was trying to reach sampling rates (in other words, I needed to sample from MPU) between 100Hz and 10000Hz.

Where is the bottleneck? Is it getting data from the MPU? Is it getting the data, via the serial port, to the XBee? Is it in the XBee-to-XBee over-the-air transfer? Is it decoding the data on the receiving end?

The code of sensor basically follows the logic:

  • Sample data and keep in an array;
  • Listen for data request from coordinator: if yes send array, if not do another sampling

You shouldn't need to do this. Each Arduino should send data at a fixed rate. The XBees will manage, if possible, resending data, if there is a problem receiving data (a packet is not acknowledged).

I looked at the code. It didn't make sense. Why does the receiver have an MPU attached? The senders should have the MPUs.

  Serial.begin(38400);
  myxbee.begin(9600);
  xbee.setSerial(myxbee);

Speaking slowly does not help with the concept of conveying the most information in the least amount of time.

    Serial.print("-------------------------------------------------------INICIO:        ");

Does wasting time sending all that crap really convey more information than:

    Serial.print("INICIO:");

I thought you said that speed was of the essence. I missed something, I guess.

      if (rx16.getData(0) == 13) { //the code to send packet has been verified. Prepare to send packets: fisrt - packet with number of samplings. second - packet(s) with samples.
        // If the number of samples has been transmitted, now we can send the packet with samples

You really need to get your enter key fixed...

  delay(10);

Speed is of the essence, eh?

3

PaulS:
Or, use Andrew Rapp's XBee library, and let it do the work of building the packet.

So, this is a doubt I have. Since I have to use a library and much more "lines of coding" (functions to decode API packet, etc), wouldn't this add extra burden and lower overall process speed? Although this might not imply lower speed since, since, as you explained to me, AT and API modes use the microcontroller in different ways... Well, guess saying which mode is quicker is not straightforward. I will try to make some tests for comparison and if they work will post the results here.

PaulS:
Where is the bottleneck? Is it getting data from the MPU? Is it getting the data, via the serial port, to the XBee? Is it in the XBee-to-XBee over-the-air transfer? Is it decoding the data on the receiving end?

Sorry if I didn't get your expression "bottleneck", but I understand you are asking me where do I need to reach 100Hz to 10000Hz. So, my practical problem is I need to measure a vibration frequency that will be between 100Hz to 10000Hz, and therefore the sampling in MPU needs to be higher than the frequency I am measuring otherwise I can't represent it well. So, I think that at sensors I need the process "sampling from MPU + sending data" be completed between 100Hz to 10000Hz (any value higher than 100Hz would already satisfy me, since I am getting only 40 Hz). At the coordinator, I obviously need to just read data at higher rate it is received.
Other meaning I get from bottleneck is you are asking me what is restricting the speed I am getting. This I am not able to determine yet and will need to do lots of testing before having any clue. I was wondering if it is a hardware limitation of XBee, but I have read applications where transmissions are faster than 40 Hz, so it might not be the case.

PaulS:
You shouldn't need to do this. Each Arduino should send data at a fixed rate. The XBees will manage, if possible, resending data, if there is a problem receiving data (a packet is not acknowledged).

I looked at the code. It didn't make sense. Why does the receiver have an MPU attached? The senders should have the MPUs.

So a packet request is not necessary? But if I don't do that there is risk of packet collisions, isn't it? Can I just make the two sensors keep sending data continuously and don't worry if the packets will be mixed? (this is something I took for granted, please explain it to me better).

One idea I had at the very beginning was each sensor sending data at a given moment, and so I would avoid both of them trying to send data at same time, or having their bytes mixed and packets crashed. But that would require them to be synchronized and I supposed this would delay the entire process in comparison to requesting data to each sensor individually.

And I have confused the files name... Where is Rx should be Tx, and vice-versa. So, you looked at the file named Rx, which is actually the sensor code. Sorry for that.

PaulS:
Speaking slowly does not help with the concept of conveying the most information in the least amount of time.

Wow, thanks for that. I really didnt see that that. I will change that and will post here how much it have improved the overall speed.

PaulS:
Does wasting time sending all that crap really convey more information than:
I thought you said that speed was of the essence. I missed something, I guess.

I have a reasonable explanation for this... Actually I do not. :confused: It is probably garbage from past experimentation.

PaulS:
You really need to get your enter key fixed...

Ops... And I will erase that delay(10) as well.

PaulS, thanks for all the help. You already have clarified some fundamental points about XBees for me.

Best regards

4

So, this is a doubt I have. Since I have to use a library and much more "lines of coding" (functions to decode API packet, etc), wouldn't this add extra burden and lower overall process speed?

I don't know. I don't know what the receiver is supposed to do with the data. I would be having the XBee/Arduino do nothing more than sending data to a PC for logging/analysis, so unpacking would not be a burden (or a necessity, since the PC would do it).

Sorry if I didn't get your expression "bottleneck", but I understand you are asking me where do I need to reach 100Hz to 10000Hz.

No, the term bottleneck refers to the thing that stops you from reaching those speeds. Look at a bottle. The neck is the smallest part of the bottle, and restricts the speed at which you can empty the bottle.

So a packet request is not necessary? But if I don't do that there is risk of packet collisions, isn't it?

I don't think it is. Sometimes there will be collisions, and only one packet will get through. The packet that didn't will be sent again, by the XBee automatically.

Can I just make the two sensors keep sending data continuously and don't worry if the packets will be mixed?

If, by mixed, you mean that the packets will be in order like 1,2,2,1,1,2,1, then there is no problem. If, by mixed, you mean that part of a packet from one XBee will be spliced with part of a packet from another XBee, then, no, that won't happen.

P.S. I like that you can smile at my subtle digs, rather than being offended.

5

PaulS:
I don't know. I don't know what the receiver is supposed to do with the data. I would be having the XBee/Arduino do nothing more than sending data to a PC for logging/analysis, so unpacking would not be a burden (or a necessity, since the PC would do it).

That is exactly what I intended, just transmitting for PC. By unpacking you mean getting the real data from the payload, right? Because that is a great idea I didn't have. In my code, the Arduino is reading the payload received and building the samples from it (each sample is a 2 byte number, so it uses a union to do that). Perhaps it will be better to just get payload and send it to the PC, and let it do the work.

I don't think it is. Sometimes there will be collisions, and only one packet will get through. The packet that didn't will be sent again, by the XBee automatically.
If, by mixed, you mean that the packets will be in order like 1,2,2,1,1,2,1, then there is no problem. If, by mixed, you mean that part of a packet from one XBee will be spliced with part of a packet from another XBee, then, no, that won't happen.

Well, THAT really changes things for me. I thought that, for example, if XBee 1 sends a payload of 3 bytes containing (1,2,3) and XBee 2 sends a payload of 3 bytes containing (4,5,6), without the implementation of a packet request protocol, or something like that, there was the possibility that the Receiver understand XBee 1 packet as (1,4,2).

Just to make sure I get it right now: that really doesn't happen right? I mean, if packets are like 1,2,2,1,1,2,1 there is no problem for me, as you said. What I don't want is a measure of XBee 1 be taken as made by XBee 2.

So, now as curiosity to improve my understanding about XBee protocol, why this splice, mixage of data from packets does not happen? Is it because a XBee will only transmit if the channel is clear for a given period of time, which would not occur if another XBee is in the middle of its transmission?

P.S. I like that you can smile at my subtle digs, rather than being offended.

Perhaps our senses of humour match.

Thank you very much PaulS, you really gave me lots of useful information.

Regards

6

By unpacking you mean getting the real data from the payload, right?

Yes.

Just to make sure I get it right now: that really doesn't happen right?

Correct. Once an XBee starts reading data, in API mode, from one XBee, it ignores data from others until the end of the API packet that it is reading arrives.

Like your TV is able to receive data from lots of stations at one time, but only displays data from one station at a time, without interference from other stations.

7

Well, I know it's been a while since the last reply, but I see no point in creating another topic if the subject is the same.

I have tried a configuration with the two sensors sending data continuously without the coordinator requesting data from each one separately each one in a time, when the payload was filled.

I got the strangest result. Considering 100 packets have been sent, I got around 30% of Sensor 1 and 70% of Sensor 2. In other words, it appears that one sensor "dominates" the channel and dont let the other send the data.

I have tried looking in books such as "Making things talk" or "Building Wireless Sensor Networks" but could not find an answer on how the situation of two XBees trying to send at the same time for the same XBee is handled. Do both transmissions go through the channel at the same time, or one XBee needs to wait the other to complete its transmission before transmitting?

How can I find more information about this? I have tried searching about protocols, transmission handling, three sensor network... but all have been unsuccessful.

8

Do both transmissions go through the channel at the same time, or one XBee needs to wait the other to complete its transmission before transmitting?

Once one XBee is recognized, the other ones are ignored, until the first one is done. So the others need to wait (actually, the XBee will retry for a while, knowing that another XBee may be blocking access).

How can I find more information about this?

digi.com or experience.

How big are your packets? Smaller packets are better.