Go Down

Topic: xbee serial.write question (Read 7190 times) previous topic - next topic

shawshaw

I have two xbees up, configured, and communicating (Coordinator API & Router AT). I can send hex commands using x-ctu without issue. I'm also trying to keep this sketch very light, so I want to write my own, thin packet processing.

What am I doing wrong? This does not work; I get no response.

Code: [Select]

byte turnondata[] = { 0x7E, 0x00, 0x10, 0x17, 0x05, 0x00, 0x13, 0xA2, 0x00, 0x40, 0x7E, 0x71, 0x53, 0xFF, 0xFE, 0x02, 0x44, 0x32, 0x05, 0x32 };
byte turnoffdata[] = { 0x7E, 0x00, 0x10, 0x17, 0x05, 0x00, 0x13, 0xA2, 0x00, 0x40, 0x7E, 0x71, 0x53, 0xFF, 0xFE, 0x02, 0x44, 0x32, 0x04, 0x33 };

void setup() {
  Serial.begin(9600);
}

void loop() {
  Serial.write(turnondata, sizeof(turnondata));
  delay(5000);
 
  Serial.write(turnoffdata, sizeof(turnoffdata));
  delay(5000);
 
}



Any assistance is appreciated!
Thanks!


JChristensen

Does it turn D2 on and off on the remote XBee?

PaulS

Quote
This does not work; I get no response.

No response from what? What is the other XBee attached to? Is this code on the coordinator or router?

Quote
I have two xbees up, configured, and communicating (Coordinator API & Router AT).

I don't think that this is a legitimate combination. I think they need to be both API or both AT, not a mix.
The art of getting good answers lies in asking good questions.

shawshaw

D2 turns off and on (test LED) on the remote xbee, but only when I send the packet using x-ctu.

With this program I get no response, local or remote.

Thanks!

shawshaw

This is a legitimate combination. See digi KB article:
http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=3221

JChristensen


This is a legitimate combination. See digi KB article:
http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=3221

Yes, absolutely.

You need to use AP=2 and escaped characters.  The 0x13 is not an allowed character, replace it with 0x7D, 0x33, recalculate the checksum and it should be good.

Not sure about that fifth byte (0x05), I use 0x01.

shawshaw

holy schnikes, that might be it. I didn't even catch that.

Thanks. I will test and report later.

JChristensen


Quote
I have two xbees up, configured, and communicating (Coordinator API & Router AT).

I don't think that this is a legitimate combination. I think they need to be both API or both AT, not a mix.


API vs. AT only specifies how the XBee communicates on the serial link with whatever it's connected to (an MCU or whatever). The radio communication between two XBees is the same, regardless of their mode (API or AT).

JChristensen


schnikes


New word, will add to my repertoire  XD

I honestly don't know why un-escaped API mode (AP=1) even exists. Not sure why a person would not want to use escaped mode "just in case". Even funnier, I think the first part of the 64-bit address (0x0013A200) will be the same for all ZigBee modules made by Digi International. So that puts the flaps down on a lot of AP=1 scenarios right there, LOL!

PaulS

Quote
I don't think that this is a legitimate combination.

I did not say that it wasn't. I'm happy to hear that it is, and that there is a useful reason to do so, AND what exactly the modes mean.
The art of getting good answers lies in asking good questions.

JChristensen


The 0x13 is not an allowed character, replace it with 0x7D, 0x33, recalculate the checksum and it should be good.


Opps, checksums are always calculated on the un-escaped data.  :smiley-red:

draythomp

#11
Oct 25, 2011, 02:54 am Last Edit: Oct 25, 2011, 02:59 am by draythomp Reason: 1
Let me try this:
0x7E, Start Sentinel
0x00, 0x10,  two bytes of length (looks right)
0x17,  frame type = Remote AT
0x05,  frame id (I usually use 1)
0x00, 0x13, 0xA2, 0x00, 0x40, 0x7E, 0x71, 0x53,  eight bytes of address
0xFF, 0xFE,   two bytes of network address (Broadcast or Unknown)
0x02,  remote command options (bitfield, this says 'save changes'
0x44, 0x32,   actual AT command (B space???)
0x05,  command parameter
0x32   checksum

er, uh, what were you sending again??

And, the API 1 restricted characters ONLY apply to the payload.  I use API 1 all the time because I hate having to escape the characters and can't read them when they come back.

Oh, and you can mix api and at modes, I do it all the time.  The over-the-air messages are all API, it gets translated for you before the serial output when you assign AT mode.  That also means there is an overhead over the air that most people don't realize, see what a simple AT command turns into?  So, one XBee can be in AT and the other in API.

JChristensen

#12
Oct 25, 2011, 03:57 am Last Edit: Oct 25, 2011, 03:59 am by Jack Christensen Reason: 1

0x44, 0x32,   actual AT command (B space???)

D2... he's just turning D2 on and off on a remote XBee.

Quote

And, the API 1 restricted characters ONLY apply to the payload.  I use API 1 all the time because I hate having to escape the characters and can't read them when they come back.

What part of the frame is the payload? According to the S2 product manual, p98, everything but the start delimiter, including the length and the checksum itself, is subject to be escaped.

shawshaw

I'm still following this thread and haven't gotten any iteration of these to be successful.

I was using AP=1. However x-ctu seemed to be able to send my packet over unescaped (according to the log), which is puzzling.
I'm trying A=2 and escaping without much luck, but I'm continuing to tinker.

To answer some other questions, yes I'm just trying to turn D2 on/off remotely. It's harder than it looks!



draythomp

Yes, that drawing drove me nuts also.  And I did a crap job of explaining it; let me try again.  Turns out, the data doesn't have to be escaped unless you're using API 2.  See, this is for parsers that look for a start sentinel of 7e to reset.  If you rely on the length and checksums, you can send anything you want to including a 7e inside the data packet.

The arduino XBee library uses the 7e to reset itself for the next packet.  I use the length and follow it to find the end of the packet.  That way I can send any thing I want to and not worry about it.  I do occasionally get a garbage packet that exceeds the length.  Then I reset and look for a 7e to start the next one, which may be messed up also because of the collision, but it will settle in a couple of packets and work just fine.  Similarly, the 7e based parsers can terminate early on a collision packet and have the same problem, just a different recovery technique.  

The real reason they included it was the XON, XOFF flow control characters for software based systems.  Which meant they could include the start sentinel to ease parsing sometimes, and of course, the escape character.

Now, I only have to learn how to look in the correct column for the ascii translation...... he's sending an ATD4 5 to turn on pin 4, got it.

So, what's wrong, it should work.  I get 32 as the checksum and 10 as the length also.  At this point, I would be looking at the lights and seeing if the device actually joined the network.

Go Up