XBees in API Mode... Help

Chemikal · 2009-10-25 07:25

Evening,

OK, I have had these XBees for 6months now, and everytime I try to get them working, they don't and I get upset with them (repeat weekly). SO, I need some help apparently.

I have a end-node, which I am simply trying to send some data to the coordinator.

I am a pro now with X-CTU, and I can get them working fine in AT mode. The key is that I want to get them working in API mode... which I can't seem to do.

Both units are on the same PAN (the PAN LED is steady, the end-node is blinking twice as fast as the coordinator, and the end-node receives the DL address, etc from the coordinator)

I have a logic analyzer and a whole slew of analysis tools, and I can't figure out why they're not working because everything seems fine, so maybe I am missing something simple...

For example:

I have built the same exact packet as on page 89 of the XBee manual (http://ftp1.digi.com/support/documentation/90000976_C.pdf), and I have confirmed this with my logic analyzer (see attachment). The baud rates are the same between what is sent to the XBee and the XBee's config (9600).

Here's the PUB of my .spin file which sends the packet:

note: destAddress[noparse][[/noparse]n] is all $00 bytes, as I am trying to send to the coordinator

PUB SendtoXBee | j, k, a_byte, csum

  j := 0
  TXpacket[noparse][[/noparse]j++] := $7E                                  'Start delimiter
  TXpacket[noparse][[/noparse]j++] := $00                                  'Length byte 1
  TXpacket[noparse][[/noparse]j++] := $16                                  'Length byte 2

  TXpacket[noparse][[/noparse]j++] := $10                                  'API identifier
  TXpacket[noparse][[/noparse]j++] := $01                                  'API frame ID
  TXpacket[noparse][[/noparse]j++] := destAddress[noparse][[/noparse]0]
  TXpacket[noparse][[/noparse]j++] := destAddress
  TXpacket[noparse][[/noparse]j++] := destAddress
  TXpacket[noparse][[/noparse]j++] := destAddress
  TXpacket[noparse][[/noparse]j++] := destAddress
  TXpacket[noparse][[/noparse]j++] := destAddress
  TXpacket[noparse][[/noparse]j++] := destAddress[noparse][[/noparse]6]
  TXpacket[noparse][[/noparse]j++] := destAddress[noparse][[/noparse]7]
  TXpacket[noparse][[/noparse]j++] := $FF                                  '16-bit address of the destination device
  TXpacket[noparse][[/noparse]j++] := $FE                                  '--> 0xFFFE is the address in unknown
  TXpacket[noparse][[/noparse]j++] := $00                                  'Broadcast hops - 0:use maximum
  TXpacket[noparse][[/noparse]j++] := $00                                  'Options
  TXpacket[noparse][[/noparse]j++] := $54
  TXpacket[noparse][[/noparse]j++] := $78
  TXpacket[noparse][[/noparse]j++] := $44
  TXpacket[noparse][[/noparse]j++] := $61
  TXpacket[noparse][[/noparse]j++] := $74
  TXpacket[noparse][[/noparse]j++] := $61
  TXpacket[noparse][[/noparse]j++] := $30
  TXpacket[noparse][[/noparse]j++] := $41

  TXpacket[noparse][[/noparse]j++] := $13                                  'Checksum
  

  repeat a_byte from 0 to 25
    SER.dec(CONSOLE,a_byte)
    SER.tx(XBEE,TXpacket[noparse][[/noparse]a_byte])

  SER.txflush(XBEE)

I have noticed that the XBee that is transmitting (the end-node) does not output anything to show and error, nor confirmation that the data was sent (I thought it was supposed to when AP=1?)...

SO, can anyone share their thoughts, or perhaps some code that works and explain your setup?

Thanks,
- Josh

Stephen Moraco · 2009-10-25 09:46

Josh,

I've gotten the XBees working in both the YBox2 (propeller) and my PropSense boards (propeller).

I'm a Logic Analyzer user as well. (I work on one of the largescale logic analyzer teams)
Love the analyzer screen shot. I may have to get one of these smaller ones...

Turns out that life is really bad when the XBee devices are allowed to sleep.
You don't seem to mention it so I thought I would... they going to sleep on you?

I monitor XBee pins 13 and 15 to determine state. 13 is off when sleeping...
I was chasing problems (my tail?) for weeks until I figured this sleep thing out.

Regards,
Stephen

Related Threads: http://forums.parallax.com/showthread.php?p=825391
(links to pics of my new boards, too)

Chemikal · 2009-10-25 15:33

Oooo, that is surely a possibility and I have done my fair share of tail chasing... - I will check it out and report back.

Chemikal · 2009-10-25 16:10

Ok, I have put pin 9 (sleep_req) on each unit to 'low', which the manual states will keep them out of sleep. But, the power status LED (pin 13) has always been on, so I don't think it was a sleep issue.

Any other ideas?

On the same topic, does the XBee need any other connections other than power and the serial lines to the Prop for API mode?

Or, when in API mode, does the XBee need to be configured by the Prop somehow before it is ready to send? Or can you simply start sending transmission packets to it, like I have been?

Mike Huselton · 2009-10-25 19:46

XBEE 1 or XBEE 2(different parts, different modes and protocols). XBEE PRO? XBEE 1 does not support coordinator or end nodes - only XBEE 2 does that.

API mode was given up on for XBEE 1 (Motorola part). API and simple passthru okay for the Cypress parts (XBEE 2).

I struggled for five years until an engineer gave the straight info.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

Post Edited (James Michael Huselton) : 10/25/2009 7:53:26 PM GMT

Chemikal · 2009-10-25 20:53

Oh yeah, both units are XBee, Series 2, non-pro, and are made by Digi. (XB-24B).

I believe their power output is 2mW, and they have the wire antennas.

Erik Friesen · 2009-10-26 01:12

Well, for starters your checksum doesn't total FF.

There are a few sticklers with using api mode, at least when using the xtends, which are similar.

There can be limitations that are not clarified. You cannot send an api packet larger than 256 bytes with the xtend in repeater mode, and also you cannot send two large api packets back to back , as the second one will not go through unless you give it time to process the first one. This is not stated in the manual, I had to find it out the hard way.

Api mode is a little more work, but it is so superior that it is worth the effort, at least if you are doing addressing on the fly, and wish to know the rssi easily.

Chemikal · 2009-10-26 02:06

touche.

I forgot that when I changed the destAddress from the example to the coordinator, that the csum will change. I have a pretty good idea how to calculate the csum, but the documentation says to only keep the lower 8-bits of the addition... and I don't know how to do that.

Something like: csum := $FF - [noparse][[/noparse]Summation of (4th byte) to (packet length, not including csum byte)] , right? But what do I do about only keeping the "lower 8-bits"?

I am only sending a small 25 byte packet, and I know the benefits of API, which is why I want to use it... but it just doesn't work, so I would like some code or some details from someone who got theirs working.

I haven't found much for information anywhere, and the whole key to the abilities of the XBee units is the API mode... so if anyone has any information, please share - this could finally be the location on this forum for how to get API mode working with the XBees.

Erik Friesen · 2009-10-26 02:24

Here is some C code. All you have to do is and it with FF to clear the rest of the bits, or just use a byte sized variable. This is for an xtend so it could be a little different.

This is not that difficult to find if you are doing it right. Remember that over the air the packets are identical. API mode only changes the way to send and receive packets from the UART. You can use one on regular mode to debug your sending and receiving. A serial port spy is invaluable to debug this also. http://www.serial-port-monitor.com/

checksum is figured from 3rd byte to last before checksum.

I had to change from brackets to ( ) so it is not true c code. Otherwise the forum wouldn't print it right. I think you can get the gist though.

char sendAPI(char *TP,short qt, char ID,unsigned int DT,char option)//Adds checksum
{
    Disable_control_ir();
    int a,QT;
    QT=qt+5;
    unsigned char checksum=0;
    while(!U1STAbits.TRMT);//make sure tx buffer is clear
    txpointer=&localtx[noparse][[/noparse]0];//set pointers
    while(DigiX.tx);//wait for last transmission to clear
    mU1TXClearIntFlag();//clear interrrupt
    localtx(0)=0x7E;//start delimiter
    localtx(1)=QT>>8;//high byte length
    localtx(2)=QT&0xFF;//low byte length
    localtx(3)=0x01;//API identifier
    localtx(4)=ID;//Frame ID
    localtx(5)=DT>>8;//DT high byte
    localtx(6)=DT&0xFF;//DT low byte
    localtx(7)=option;//Option
    for (a=0;a<qt;a++)
        {
        localtx(a+8)=TP(a);//copy buffer
        checksum+=(unsigned char)TP[noparse][[/noparse]a];//figure checksum
        } //   
    checksum=checksum+localtx([noparse][[/noparse]7)+localtx(6) +localtx(5) +localtx(4) +localtx(3);
    checksum=0xFF-checksum;
    localtx(QT+3)=checksum;
    txcnt=QT+4;
    txpcnt=0;//set pointer to next byte in series
    for(a=0;a<4;a++){//repeat four times to fill buffer
        if(txcnt>0){//only if count is not reached
            U1TXREG=*(txpointer+txpcnt);
            txpcnt++;
            txcnt--;
        }
    }
    txintenable = 1;//enable interrupt
    G_rxtx=1;//led
    R_rxtx=1;//led
    DigiX.tx = 1;//flag send
    Enable_control_ir();
}

Chemikal · 2009-10-27 01:30

After 6months of banging my head into my desk, IT WAS THE CHECKSUM BYTE.

  chksum := $00
  repeat k from 3 to (j-1)
    chksum := chksum + TXpacket[noparse][[/noparse]k]

  chksum := $FF - chksum
    
  TXpacket[noparse][[/noparse]j++] := chksum                                  'Checksum

That's how I did it - the 'chksum' is a VAR as 'byte chksum '

I am now sending data reliably, and a whole range of possibilities just opened up.

Thanks all for your help.

- Josh

XBees in API Mode... Help

Comments