XBee problems

Rsadeika · 2017-01-19 21:43

Not sure how to resolve this issue with using multiple XBee Pro modules.

Below is a sample program that I am using on two different Activity boards. I also have a special terminal program on my PC which uses the third XBee module. When I have just one Activity Board turned on, then the program works as expected. When I have both Activity boards turned on, then I have some problems like there is a blue LED by XBee socket on the boards that start to flash, along with the red LED next to it. The one board is #1 and the other board is #2. Not sure why this is occurring with the XBee boards, when I send it a command from the XBee on the PC using my special terminal program, that is addressing only one of the boards.

Thanks
Ray

/*
  testxbee.c
  January 19, 2017
*/
#include "simpletools.h" 
#include "simpletext.h"
#include "fdserial.h"

serial *xbee;

int main()
{
  // Add startup code here.
/*                     Rx  Tx     BAUD  */
  xbee = fdserial_open(11, 10, 0, 9600);

  char inIDno[5];
  char inDec[5];
  char inBuff[40];
  long inSec = 0;
 
  while(1)
  {
    // Add main loop code here.
    readStr(xbee,inIDno,5);
    if(!strcmp(inIDno,"#2"))
    {
      readStr(xbee,inBuff,40);
      if(!strcmp(inBuff,"0001")) high(26);
      else if(!strcmp(inBuff,"0002")) low(26);
    }//if loop        
  }//while(1) loop  
}//main

JonnyMac · 2017-01-19 22:11

How are your XBees setup? I think you'll need to go into XCTU and set the destination address for all modules to $FFFF (global address) -- this will let all modules "hear" every transmission (that said, I've never used this in non-APi mode) What this means, of course, is that you'll need to put a specific device address into your own messages for each device to consult before responding.

I'm working on the a laser tag project that makes extensive use of XBees. We're using API1 coms so that the Propeller doesn't have to filter every message (the target address is in the message).

Most packets use a simple packet that is formatted like this:

dat

  ' v1.x format
  '
  RefCommand    byte    $7E     ' header
                byte    $00     ' length.byte1
                byte    $08     ' length.byte0    
                byte    $01     ' tx id
                byte    $00     ' response
                byte    $FF     ' destination.byte1
                byte    $FF     ' destination.byte0
                byte    $01     ' disable ack
                byte    $40     ' $40 = message, $20 = kill, $10 = hit   
                byte    $03     ' $03 = referee
                byte    $00     ' command
                byte    $00     ' checksum

Referee commands go to every XBee. When one tagger is hit by another, it can send feedback using a similar packet -- this is the code that does that.

pub shot_feedback(victim, shooter, state)

  bytefill(@txbuf, 0, BUF_SIZE << 1)                            ' clear buffers
  serial.rxflush

  txbuf[00] := $7E             
  txbuf[01] := $00             
  txbuf[02] := $08                                              ' packet size
  txbuf[03] := $01                                              ' tx             
  txbuf[04] := $00                                              ' no response           
  txbuf[05] := $00                                               
  txbuf[06] := shooter                                           
  txbuf[07] := $01                                               
  txbuf[08] := state                                            ' hit = 16, kill = 32 
  txbuf[09] := victim                                            
  txbuf[10] := shooter                                           
  txbuf[11] := calc_checksum(@txbuf, 3, 10) 

  tx_frame(12)

Depending on your project, using API1 (or 2) messages may be cleaner.

Rsadeika · 2017-01-19 23:27

Thanks Jon. Now I am in trouble, I went to the OBEX to see what is there, and all the examples are in Spin. PropGCC does not do inline Spin, so I have to really think about this one. I will have to check out the procedure for giving each module its own XBee ID, although I thought it would be as easy as just using #1 and #2.

Ray

JonnyMac · 2017-01-20 01:08

although I thought it would be as easy as just using #1 and #2.

That's easy when you have two modules, because you can use XCTU to preset MY (local) and DL (destination, low word) address so they connect to each other. If you want three three or more modules to hear each other, then you have to set DL to $FFFF. After that, you have to insert addressing into your messages and let the Propeller handle it. In the laser tag system, shot reports are peer-to-peer (victim reports to shooter), but referee commands are broadcast to $FFFF so that all elements (taggers and game pieces) in the system can deal with the message.

Just so you understand, XBees always use API mode -- it's just hidden from you when you select non-API. I prefer API mode so that I can craft messages as I choose, including those that go point-to-point.

My object (which I cannot share because it does include customer code) is Spin as a wrapper over FDS. I have posted the source for other generic routines in my wrapper, and you shouldn't have any trouble porting them to C.

And... there's lots C code for XBees written by Arduino users -- that should be even easier to fold into your project.

pub tx_frame(len) : idx

  repeat len
    serial.tx(txbuf[idx++])


pub get_rx_frame(ms) : len | c

  bytefill(@txbuf, 0, BUF_SIZE << 1)                            ' clear buffers

  if (ms =< 0)
    c := serial.rxcheck
  else
    c := serial.rxtime(ms)

  if (c == $7E)                                                 ' look for frame header    
    rxbuf[len++] := c
    repeat
      c := serial.rxtime(1)
      if (c < 0)  
        return len  
      else
        rxbuf[len++] := c


pub validate_rx_frame | last

  last := rxbuf[2] + 2

  if (calc_checksum(@rxbuf, 3, last) == rxbuf[last+1])
    return true
  else
    return false


pub calc_checksum(p_buf, first, last) | cs, idx

  cs := $FF                        
  repeat idx from first to last        
    cs -= byte[p_buf][idx]             

  return cs.byte[0]

Rsadeika · 2017-01-20 11:45

I am going to start at the bottom, read the documentation for the XBee modules, and go from there. Your mention of the API mode sounds like an interesting approach, you have complete control over the XBee module, to have it do want you need it to do from within your code. At the moment my Propeller programs still have plenty of memory available, and I am trying very hard to keep it that way.

When I get a workable solution I will post the PropGCC program here, I am not confined by proprietary code.

Ray

Rsadeika · 2017-01-20 13:01

I just went to the Digi site, and I see that the XBee-PRO S1 802.15.4, the modules that I have, are now legacy. No wonder that I am finding it difficult to find docs and information for the product. Not sure if I should consider moving up to the latest XBee module, whatever that might be.

Anybody have any idea as to what you get that is better than what I have right now, in the new module? What does the new module have to offer that the legacy module does not have, besides up to date docs and info? I will have to look at the Parallax store and see if they have some kind of user information besides just a product info page.

Ray

Publison · 2017-01-20 13:55

Ray,

Have you seen this?

https://www.parallax.com/news/2016-09-16/upcoming-changes-xbee-product-line

Rsadeika · 2017-01-20 14:56

Thanks

Point number two looks kind of interesting, I wonder if that means that the modules have a default address? That would make life easier, that way you would not have to use XCTU program to accomplish this. Hopefully they are staying away from the paring stuff. Since the price is the same, maybe I will have to upgrade.

Ray

•Simple, out-of-the-box RF communications, no configuration needed
•Point to multipoint network topology

RS_Jim · 2017-01-20 15:34

Have you tried this? Search Parallax site for this: 122-32450-XBeeTutorial-v1.0.1.pdf
I find this to be a comprehensive Document. I also see information relating to Xbee on the Learn.Parallax.com site regarding programing the xBee in "C"
Jim

Publison · 2017-01-20 15:44

https://www.parallax.com/downloads/getting-started-xbee-rf-modules-text

http://learn.parallax.com/tutorials/projects/xbee-802154-pc-demo

JonnyMac · 2017-01-20 16:30

This is the module I'm using:

https://www.parallax.com/product/32407

There are links to lots of useful documentation on the Digikey page.

http://www.digikey.com/product-detail/en/digi-international/XBP24-AWI-001/XBP24-AWI-001-ND

XBee problems

Comments