XBee Coordinator in API Mode - It's Not Cooperating...

Chemikal · 2009-04-26 05:33

Evening all,

I have been playing with some XBee Series2 units, and while I was easily able to get them working in AT mode as far as linking two of them up and sending data from one to the other... API mode is giving me problems...

Right now, I just want to query the coordinator's configuration with the Prop it is currently plugged into. See, I want to query the information from the XBee in a boot-up sequence and store it all to variables, but I cannot seem to get the "XBee_Object.spin" object to work properly... Really, while poorly documented etc, the object cannot be that poorly written, so I must be running a sequence of commands improperly... Here is my setup and the code I am trying to run:

XBee (XB24-B, v1120) - I am familiar with X-CTU and used it to load the "Zigbee Coordinator API" function set - set [noparse][[/noparse]NI] Node Identifier to "111"
The XBee is confirmed in Coordinator mode due to the pulsing LED (1 pulse each second)
Using "XBee Transciever AT-API Object" from the ObjectExchange, Version 1.1, written by Martin Hebel

The code ("LCD" is a 20x4 LCD I use for debugging):

PUB BootUp | XB_NI  

<!-- LCD initialization, etc up here -->

  LCD.MOVE(3,1)
  LCD.STR(STRING("=== XBee Startup ==="))

  dira[noparse][[/noparse]XBee_RX_Pin] := %0                               ' Set XBee_RX_Pin to input
  dira[noparse][[/noparse]XBee_TX_Pin] := %1                               ' Set XBee_TX_Pin to output
  
  XB.start(XBee_RX_Pin,XBee_TX_Pin,0,9600)              ' XBee Communication Init - RX,TX, Mode, Baud
  XB.AT_Init

  XB.AT_Config(string("ATAP 1"))

  XB.RXflush  
  XB.API_Query(string("NI"))
  XB.API_RX

  XB_NI := XB.RxData

  LCD.MOVE(4,1)
  LCD.DEC(XB_NI)

The result? It outputs "4868" as the variable result for "XB_NI"... it is set as "111", so it is not outputting correctly... output to my PC terminal with the same number.

I have tried for many, many hours with this now... your help is greatly appreciated.

- Josh

Post Edited (Chemikal) : 4/26/2009 4:02:19 PM GMT

Chemikal · 2009-04-26 18:27

I guess my major question here is how, in API mode, can I grab configuration data from the XBee?

Am I setting the "XB_NI" variable correctly?
Is that how I should code to receive the response from an API command?

(Seems like the XBee sends the response really fast when I use my PC with it... is the Prop switching to the RX mode fast enough to get the whole response?)

pgbpsu · 2009-04-26 18:30

Josh-

Why are you doing this?
XB.AT_Init

XB.AT_Config(string("ATAP 1"))

I thought you were running in API mode? Aren't these AT commands?

I've got a number of XBee units running in API mode. I haven't done exactly what you are trying to do, but something similar.

I have the coordinator connected to a mac and I read that serial data with a custom frontend. Each of my XBee end-devices/routers is connected to a prop. When each end device boots, I ask that prop to get the 64-bit address of the XBee radio to which it is wired. I never figured out how to use Martin's receive-from-Xbee stuff, so I just send the request to the XBee, then give it a little bit of time to generate a response, then read that serial port to which it is connected and parse that byte-wide buffer myself. You need to know what the AT Request response frame looks like. You should be able to find it in the XBee manual. Here's how I go about getting the serial number from an XBee wired to a prop.


'  uarts.str(DEBUG,string(13,"Sending API AT request (SL) to radio... "))
  API_Query(string("SL"))
'  uarts.str(DEBUG,string(13,"Looking for incoming packets...",13))
  bytefill(@API_Buffer,0,200)   ' zero out API buffer so we can use it to collect XB response

  waitcnt(clkfreq*4+cnt)   ' give the buffer some time to fill in response to our question
  index:=0
  repeat while (API_Buffer[noparse][[/noparse]index++] := uarts.rxcheck(XBEE)) <> -1 
'    uarts.hex(DEBUG,API_Buffer[noparse][[/noparse]index-1],2)
'    uarts.str(DEBUG,string(" "))
'  uarts.str(DEBUG,string(13,"Done.",13))

' pull out the parts of the buffer we are interested in.  See XBEE manual for AT response frame.
  repeat index from 8 to 11
    SL := ( SL << 8 ) | API_Buffer[noparse][[/noparse]index] 
'  uarts.str(DEBUG,string(13,"Lower 32-bits of Radio Serial Number: 0x"))
'  uarts.hex(DEBUG,SL,8)

  waitcnt(clkfreq+cnt)   ' wait 1 seconds

'  uarts.str(DEBUG,string(13,13,"Sending API AT request (SH) to radio... "))
  API_Query(string("SH"))
'  uarts.str(DEBUG,string(13,"Looking for incoming packets...",13))
  bytefill(@API_Buffer,0,200)   ' zero out API buffer so we can use it to collect XB response

  waitcnt(clkfreq*4+cnt)   ' give the buffer some time to fill in response to our question
  index:=0
  repeat while (API_Buffer[noparse][[/noparse]index++] := uarts.rxcheck(XBEE)) <> -1 
'    uarts.hex(DEBUG,API_Buffer[noparse][[/noparse]index-1],2)
'    uarts.str(DEBUG,string(" "))
'  uarts.str(DEBUG,string(13,"Done.",13))

' pull out the parts of the buffer we are interested in.  See XBEE manual for AT response frame.
  repeat index from 8 to 11
    SH := ( SH << 8 ) | API_Buffer[noparse][[/noparse]index] 
'  uarts.str(DEBUG,string(13,"Upper 32-bits of Radio Serial Number: 0x"))
'  uarts.hex(DEBUG,SH,8)

  uarts.str(DEBUG,string(13,"64-bit Address of this radio: 0x"))
  uarts.hex(DEBUG,SH,8)
  uarts.hex(DEBUG,SL,8)

It seems to me that if you are in API mode, all you need to do is use the API_Query method to get a response from the Coordinator if that's what your prop is wired to.

Here's the API_Query method from Martin's post in the OBEX which is what I'm using.


Pub API_Query (stringptr)| len, chars, csum
{{
  Sends AT command in API mode to query a parameter value.
  Should also be used to set network identifier.
  Data is returned as an AT response as a string.
  XB.API_Query("DL")                                 ' Query
  XB.API_Rx                                          ' accept response
  MyDest := byte[noparse][[/noparse]XB.RxData]                          ' 8 bit value
  XB.API_Query("DL")
  XB.API_RX
  MyPanID := byte[noparse][[/noparse]XB.RxData]<<8 + byte[noparse][[/noparse]XB.RxData+1]  ' 16 bit value
}}
  API_Buffer[noparse][[/noparse]0] := $7E
  len           := strsize(stringptr) + 2    ' API Ident + FrameID + AT cmd
  API_Buffer := len >> 8           ' MSB
  API_Buffer := len                ' LSB
  API_Buffer := $08                   ' API Ident for AT Command (non queue)
  API_Buffer := FRAME_ID              ' Frame ID
  Repeat chars from 0 to len-2        ' Add string to packet
     API_Buffer[noparse][[/noparse]chars + 5] := byte[noparse][[/noparse]stringptr++]
  csum := $FF                            ' Calculate checksum
  Repeat chars from 0 to len
    csum := csum - API_Buffer[noparse][[/noparse]chars + 3]
  API_Buffer[noparse][[/noparse]len+3] := csum

'  uarts.str(DEBUG,string(13,"Length: "))
'  uarts.dec(DEBUG,len)
'  uarts.str(DEBUG,string(13))

  Repeat chars from 0 to len + 3
    uarts.tx(XBEE,API_Buffer[noparse][[/noparse]chars])
    uarts.hex(DEBUG,API_Buffer[noparse][[/noparse]chars],2)
    uarts.str(DEBUG,string(" "))
  uarts.str(DEBUG,string(13))

  return

Chemikal · 2009-04-26 20:42

Wow, thanks for the response pgbpsu -

I did the XB.AT_Init ... XB.AT_Config(string("ATAP 1")) because of what I saw in Martin's XBee_Object_Example:

Pub Start | check
    XB.start(7,6,0,9600)           ' XBee Comms - RX,TX, Mode, Baud
    [b]XB.AT_Init                     ' Initialize for fast AT command use - 5 second delay to perform[/b]
    Comm.start(31,30,0,9600)       ' Initialize comms from Prop to PC
    num.init                       ' Initialize Numbers object

    XB.AT_Config(string("ATAP 0"))            ' Set for non-API mode (AT mode)

    XB.AT_Config(string("ATDL 1"))            ' Set destination address to 1
    XB.Str(string(13,"Hello number 1",13))    ' TX string
    XB.Dec(101)                               ' TX value
    XB.tx(13)                                 ' TX carraige return


    XB.AT_Config(string("ATDL 2"))            ' Change address to 2
    XB.Str(string("Hello number 2",13))       ' send string and then value
    XB.Dec(102)
    XB.Tx(13)
    


    [b]XB.AT_Config(string("ATAP 1"))                ' change to API mode[/b]
    XB.API_Str(1,string("Back to number 1!",13))  ' send string to address 1
    XB.API_Str(1,num.ToStr(103,num#dec))          ' send a string for value to address 1
    XB.API_Tx(1,13)                               ' send CR to address 1
    XB.API_Str(2,string("And number 2!",13))      ' repeat for address 2
    XB.API_Str(2,num.ToStr(104,num#dec))
    XB.Delay(250)                                 ' delay to allow responses from actions

   <!--- etc etc -->

It actually sounds like the system you have created is the same as what I am working on - I have XBee-Prop modules around the house, and the Coordinator XBee module wired into my server PC, with a frontend to show the status of the units around the house and to change them.

What is the "uarts" object you are using? I figured it was SimpleDebug, but that does not seem to be the case because of "uarts.rxcheck(XBEE)". What's the "XBEE" variable?

Also, thanks again, but yes I did see Martin's comment in the API_Query command, but in the code:

Pub API_Query (stringptr)| len, chars, csum
{{
  Sends AT command in API mode to query a parameter value.
  Should also be used to set network identifier.
  Data is returned as an AT response as a string.
  XB.API_Query("DL")                                 ' Query
  XB.API_Rx                                          ' accept response
  MyDest := byte[noparse][[/noparse]XB.RxData]                          ' 8 bit value
  XB.API_Query("DL")
  XB.API_RX
  MyPanID := byte[noparse][[/noparse]XB.RxData]<<8 + byte[noparse][[/noparse]XB.RxData+1]  ' 16 bit value
}}

He is setting "MyPanID" to the response from an API Query for Destination Low (DL)... is that a typo on his part, or is there something I am misunderstanding? Shouldn't it be XB.API_Query("ID") to trigger the response for the Pan ID?

Thanks again for the help - your response has been a major help so far.

Ole Man Earl · 2009-04-26 22:00

I have a problem also with the XBee. How the heck do you read the RSSI of the Tx AND the Rx module ? I'm at my wits end.

pgbpsu · 2009-04-27 01:34

Josh-

From your first post, it sounded to me like you had a prop connected to the coordinator. My coordinator is connected to my PC. Props are only connected to XBee routers. ( I have no end devices in my system because I want to be able to move them around and not worry about an unusable topology). But other than that, it does sound like we have similar systems.

Sorry about the uarts object. I grabbed this code from an existing application. That application has 4 serial ports. To squeeze them all into one cog, I used a 4-serial-ports-in-one-cog object. It's in the object exchange and it's great. I'm cogged strapped in that application. I use one uart for the XBees, one for debug messages sent out the programming port, and 2 for GPS stuff. The XBEE and DEBUG are constants referring to the port within that cog. I don't use Martin's start method. I'm using the start method that goes with 4-cog-serial port.

Martin's object might have a typo. It does say that the response from the AT_Query command is returned as a string. If that's true it could be that you're getting a string when you think you are getting a number. However, based on the comments, it looks like he's in fact getting a number back. Looking at the XBee manual, DL is the lower 32-bits of the destination address. It makes sense that he would store that as MyDest (My Destination?) My guess is that the second "DL" request should be, as you've suggested, EI(extended Pan ID), OE(Operating Extended Pan ID), or OP(Operating Pan ID). But it's anyone's guess what he's trying to do.

I've not used the String addressing method you are attempting. I do everything with the 64-bit DH,DL. Having said that, in my system, it's only the coordinator that talks to the end nodes. All the end nodes only talk to the coordinator. This makes the destination address easy. It's the same on all the nodes (to me a node is everything but the coordinator): 0x0000_0000. That is the coordinator's address. All my nodes come up in a mode where they begin transmitting no matter what. When the coordinator is turned on, it starts receiving packets and builds a table of the address from which it has received data. Using that table, it can then address individual nodes using the 64-bit address that arrives anytime a packet arrives. Is this what you are doing, or are you having nodes talk to one another in addition to the coordinator?

BTW, I don't think you can mix the AT and API commands has you have listed in the first chunk of code below. These are two different firmwares. You can issues some AT commands when running in API mode, but I'd be very surprised if, having setup the firmware on a device to be API mode, that a command such as:
[noparse][[/noparse]code]
XB.AT_Config(string("ATAP 0")) ' Set for non-API mode (AT mode)

XB.AT_Config(string("ATDL 1")) ' Set destination address to 1
XB.Str(string(13,"Hello number 1",13)) ' TX string
[noparse][[/noparse]\code]

would do anything. AFAIK, if the radio, in API mode, gets anything that doesn't start with 0x7E it rejects it- i.e. won't even send it.

If our systems are as similar as you think, I'll strip out the unnecessary code from my app and send it to you.

@Ole Man Earl
Are you using AT or API mode? You should be sending a "DB" request to the unit.

Ole Man Earl · 2009-04-27 02:30

I knew it was a "DB" but I am not sure I am in AT or API mode. To get RSSI via DB command does it matter which mode you are in ?

Chemikal · 2009-04-27 04:06

pgbpsu -

Yes, I have a Prop connected to the coordinator so that the link stays up between the units if I have to shutdown the server or do not require my server to be running (it's an actual server machine - my future plan is to make the status of the units linked to the coordinator viewable from the web/intranet, but I need to make the system rock-solid and self-repairing before I get there.)

Ah, I see the "uarts" code is the pcFullDuplexSerial4FC object... I should probably incorporate that now as well to save on cogs, rather than rewriting it in the future if/when I run out.

Yes, I just have the nodes talking to the coordinator, and vice-versa. I do not have the nodes communicating with one another.

Looking through the datasheet I just came across for the XBee, which has all of the commands you referred to (EI, OP, etc)... the datasheet I was using was apparently very basic, I think I might be able to get some usable data out of the XBees now... Though, it is now even more pressing that I should look into getting that USB logic analyzer I have been looking at (a USBee SX module: http://www.usbee.com/sx.html), which would make all of this much easier to diagnose/write.

I am also going to drop that bit of code that deals with the AT commands - I agree now that it isn't necessary (unit is looking for start delimeter 0x7E of API packet)

If you could send me your app, that would be great - plus, it is always good to see how another coder approached a problem and dealt with the protocols...

With the datasheet, your help thus far, and hopefully your app, I should be able to have a functioning system sometime soon - then I can jump into the really fun stuff (self-repairing routines, Python frontend, a nice small etched board utilizing all surface mount parts, etc)

Again, thanks for all the help -

@Ole Man Earl:
The mode of the unit depends on what Function Set you loaded onto the XBee unit with X-CTU (an application you can download from Digi) - each function set has a "AT" or "API" suffix. Also, from the XBee datasheet:

It is possible to measure the received signal strength on a device using the DB command. DB
returns the RSSI value (measured in &#8211;dBm) of the last received packet. However, this number
can be misleading. The DB value only indicates the received signal strength of the last hop. If a
transmission spans multiple hops, the DB value provides no indication of the overall transmission
path, or the quality of the worst link &#8211; it only indicates the quality of the last link and should be
used sparingly.

For the modes (AT or API), the datasheet states that both modes accept DB - I do not have my system in front of me, but it should be something like:
- AT mode: send "+++" (no CR), then send "ATDB" (with a CR after it).
- API mode: form a packet for the AT command 'DB' aka: 0x7E 0x00 0x04 0x08 0x52 0x44 0x42 0xCheckSum, where 0x52 is an arbitrary value and I am unfamiliar with calculating the necessary CheckSum with hex...

For TX status, I am unsure... other than collecting the status with API, but I am not sure if you're even using API mode, as AT mode is much simpler unless you really dive into the coding and hex values...

... back to writing the term paper I have been working on for the past 15hrs... not due until Wed thankfully

Post Edited (Chemikal) : 4/27/2009 4:52:29 AM GMT

pgbpsu · 2009-04-27 14:19

Josh-

I've attached 2 files. One is an archive of the spin files and the second is the output once that code is running. I think you should be able to adjust only things at the front/constant section of the program and get output similar to what is in the output.txt file. I stripped all/most of the unnecessary code out of this so it doesn't do anything useful. It simply sends the numbers 0-11 to the coordinator every 200ms. It does accept responses and i you look through the output.txt file you'll see where I sent a command from the PC via the coordinator to this unit. It recognizes the incoming packet and prints the proper message.

There are a LOT of debug messages in here, but it's the only way I could get it working. You can comment all those out and it should run just the same, only using Prop Serial Terminal, you won't see anything.

I'm kinda swamped the next couple of days. Leaving for vacation on Wednesday and trying to get a bunch of things done before I go. I think I'll have internet while away (but no prop) so have a crack at this and post back if you have questions/trouble. Just don't expect to rapid a response.

Good luck.

Peter

Chemikal · 2009-04-27 15:51

Peter -

The Archive .zip file is empty (0 KB) - If you could please re-upload

Thanks for all the help - I believe I can make it all work now once I see your code.

Have a good vacation,

- Josh

pgbpsu · 2009-04-27 16:46

Sorry about that.· I'm posting from a windwos machine this time.· Hope this works....

p

pgbpsu · 2009-04-28 14:09

Josh-

I hope that last upload gave you files you can use. Let me know how this goes.

I'm very interested in the rest of your system. The system I've/we've developed here has been pretty stable so I've become a big fan of the XBee radios. I'd like to do something very stripped down (from a hardware point of view) and similar to what you have. I'd like to automate some aspects of our garden and cold frames. I was thinking of a small prop/xbee system that could record temp, humidity, turn on pumps, fans, and open vents to try to stabilize the conditions in there. I'm interested to see what hardware you come up with. I have several free 40DIP props, but now that they are only $8 each, I could see getting the smaller packages to save board space. I was thinking of an socketed XBee, an efficient power supply that would accept either 12V or 6V input since these are easy to power with solar panels, a temp sensor, some space for some switches, etc. Anyway, keep me posted and let me know how you get on with the code.

p

Chemikal · 2009-04-29 05:50

Yep, I will be going through the files you gave me and see what kind of ground I can cover - I skimmed through it and it seems like it'll be no problem

I also have several free 40DIP props that I purchased recently, but my next focus is to get my equipment together to work with the smaller packages... rework station, PCB house accounts, etc. After working with a FPGA and some gyros recently, I never realized how simple surface mount parts really were... granted you have the right equipment (I currently work/intern at a semiconductor company and was hanging around with some work friends in one of the fabrication labs)

I finished that term paper I have been focusing on just now, have to present it tomorrow, and then I will have some time to jump back into the Prop again

I also like your idea of the solar powered system - solar and wind power are another interest of mine and have some plans for some large-scale systems (wireless transmission of the wind speed, power generation, demand, etc with an XBee would be cool)... couple that with hydrogen storage and the associated systems (electrolysis, etc), and then I finally get into my actual career choice and my almost completed major: chemical engineering. So yeah, I love lots of projects and ideas, so once I get wireless enabled I should be able to enter the realm of a whole new span of possibilites... I will keep you updated with how my system works out -

XBee Coordinator in API Mode - It's Not Cooperating...

Comments