Simple example of two way communication with the XBee and Propeller

Daniel Harris · 2011-05-11 14:18

Hey all,

I had a customer walk in with his project in hand. He was having some trouble getting bi-directional communication between two XBee connected Propeller boards. Once I double checked his wiring and XBee settings, I wrote this little example program to simply demonstrate the concept of client->server->client communication.

The basic run down of what these two programs do...

Host Server gets loaded with the server code.
Remote Client gets loaded with the client code.

Client transmits a prompt for validation to the server.
Server validates the received prompt. Server then transmits a validated reply to the Client.
Client waits for received response from server. If received response is valid, LED turns on. If recieved response is invalid, LED turns off.

attachment.php?attachmentid=81081&d=1305148600

attachment.php?attachmentid=81081&d=1305148600

--Real simple demonstration. I thought it might be useful for some of you who want to get started with the XBee modules.

Scout · 2011-05-11 23:26

SWEET! hey Daniel, thanks for all of your help so far! I am excited to keep going and developing this system. I am sure that the other propeller and stamp users out there will benefit as the results are posted!!

johnfos · 2011-05-12 10:15

@Daniel:

Neat. If this is to serve as general demo code, maybe add a comment on the BAUD_RATE setting, that if using Series 1 XBees and wanting high speed, to set BAUD_RATE to 111_111 and not the nominal 115_200?

Daniel Harris · 2011-05-12 17:08

@Johnfos,

Is there a known problem with the XBee where it needs to communicate at 111_111 baud? I haven't heard of that before.

As far as I have used them, you can totally communicate at 115_200 baud. The XBee just has to be configured to expect communication at that speed...

johnfos · 2011-05-12 23:00

@Daniel:

Bearing in mind that we're only talking about the series 1 XBees here, the issue is that the internal clock runs at 16MHz. That gets divided by a configurable integer value and then by 16 to drive the UART, so you can get any baud rate that's a factor of 1MHz. If you want 115,200 baud the nearest divisor is 9, which actually delivers 111,111 baud. The difference is enough to make communication unreliable in many cases. Series 2 XBees have a faster clock, and don't suffer from the problem.

For more detail, you might like to check out my XBee series 1 cookbook (and other resources - FAQ and API packet check program) at http://www.jsjf.demon.co.uk/xbee/xbee.html . The cookbook has an appendix on baud rates. It also has the stub of a second appendix on the issue, but that's a work in progress and currently on hold.

chris jones · 2011-05-13 01:58

Hello

i am trying to use the demo code on 2 demo boards with 2 xbees thansk for the exmaple ou have been the most help so far. but i am haveing some issues i have the dmeo boards so i changed the pin for the led to my demo boards led "20" but the code does not seem to work. also i changed the dout and din ping to 1,2

 
{{
  RFID Tag Side (remote client)
}}
CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000
  XBEE_DOUT_PIN = 1
  XBEE_DIN_PIN  = 2
  XBEE_MODE     = %0000
  XBEE_BAUD     = 9_600
  LED_PIN       = 19
  
obj
  xb    :       "FullDuplexSerial"  'comms to XBee.
var
  long  recv
  
pub go
  xb.start(XBEE_DOUT_PIN, XBEE_DIN_PIN, XBEE_MODE, XBEE_BAUD) 'start comms to XBee
  dira[LED_PIN] := 1            'sets to output
  'main loop
  repeat
    xb.tx("?")                  'prompt the host for validation
    recv := xb.rxtime(250)      'receive our response byte, wait 1/4 second max for response
    
    if recv == "!"              'if we receive a valid response, then execute the following...
      outa[16] := 1        '  turn LED on
      waitcnt(cnt + 2*clkfreq)  '  wait 2 seconds
      outa[16] := 0        '  turn LED off
      'waitcnt(cnt + clkfreq)   '  wait
      
    else                        'else, if something else was received
      outa[16] := 0        '  didnt get an ! (got something else), turn the LED off
    waitcnt(cnt + (3*clkfreq))  'wait 3 seconds

 
{{
  Computer Side (host)
}}
CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000
  XBEE_DOUT_PIN = 1
  XBEE_DIN_PIN  = 2
  XBEE_MODE     = %0000
  XBEE_BAUD     = 9_600
  LED_PIN       = 20
  
obj
  xb    :       "FullDuplexSerial"  'comms to XBee.
var
  long  recv
  
pub go
  xb.start(XBEE_DOUT_PIN, XBEE_DIN_PIN, XBEE_MODE, XBEE_BAUD) 'start comms to XBee
  'main loop
  repeat
    recv := xb.rxcheck          'see if a byte is available, save result into 'recv'
    if recv == "?"              'if we received the correct prompt (= "?")
      TurnOnLED                 '  turn on the LED for a time
      xb.tx("!")                '  send back our response

pub TurnOnLED
  dira[16..23]~~               'sets to output
  outa[LED_PIN] := 1            'sets pin high
  waitcnt(cnt + clkfreq)        'wait one second
  outa[LED_PIN] := 0            'turn it back off
  'all done here, return now

johnfos · 2011-05-13 04:11

@Chris:

In your client code you have LED_PIN set to 19 (not 20 as you said) and when you try to toggle the LED you're driving pin 16. Would that account for it?

chris jones · 2011-05-13 08:21

johnfos wrote: »

@Chris:

In your client code you have LED_PIN set to 19 (not 20 as you said) and when you try to toggle the LED you're driving pin 16. Would that account for it?

i made the chages to use the LED_PIN varable but still nothing lights up on the demo board.

johnfos · 2011-05-13 13:18

Did you change the definition of LED_PIN to 20?

chris jones · 2011-05-13 15:05

yes i have set the LED_PIN to 20

Daniel Harris · 2011-05-14 12:46

Hey Chris,

Have you verified that your XBees are configured to communicate with each other? That was one of the biggest stumbling blocks I ran into when learning how to use XBees.

Some of the settings to verify are the PAN ID, the Channel, and if Destination High and Destination Low are set. If you got XBee 802.14.5 adapters from Parallax, they come from Digi International preprogrammed with defaults to set the XBees to just broadcast messages - meaning that any XBee with the default values will receive a message sent by any other XBee with the default values. If you picked up the ZB (Series 2) modules, then you will have to do some pre-configuration to get them talking nicely with each other.

chris jones · 2011-05-14 13:09

Can you post your defaults so I can verify mine?

johnfos · 2011-05-14 13:09

@Chris:

If you're still stuck, would you like to post again with a few extra details?

1. You can use X-CTU to save a .PRO file containing (most of) the XBee settings. Do that for each of the XBees and attach the files to the post (eg host.pro, client.pro). I have a nifty little program that can analyse these things if you're using the Series 1 model.

On the other hand, if you're using series 2, I may have to bow out at this point.

2. Attach also your current SPIN code for client and host.

Daniel Harris · 2011-05-14 14:37

If you can use Digi's X-CTU tool with your XBees, under the modem configuration tab, click the "Restore" button to restore the XBee back to defaults.

My default settings are:

PAN ID: 3332
Channel: C
Destination High and Destination Low: leave those blank or clear them.

Also, disable AES Encryption if its on, but you would have had to set that up.

Any luck with it?

chris jones · 2011-05-15 17:57

ok i have the defaults loaded i get the same outcome

Dgswaner · 2011-05-15 22:36

I tried your code, and it works for me, just had to make sure I had my Pin assignments correct.

chris jones · 2011-05-16 15:40

ok, i have it working. is there a way to send text to the other node ?

rook128 · 2012-02-01 00:05

@Daniel Harrris

Can these codes be modified in any way to interface the parallax propeller with MICAz motes...?

Simple example of two way communication with the XBee and Propeller

Comments