XBEE on RCFAST

VG · 2012-01-01 17:57

Hi All,
I am trying to use RCFAST (internal clock) with XBEE Series 1. The code works perfectly on the Protoboard (XTAL) with XBee board soldered to it. The propeller on breadboard (no XTAL) seem to have hard time understanding the XBEE message. The message is coming to Prop (it blinks on an LED). But it seems DOUT (XBEE) byte is not interpreted properly. Do you have any idea or expereince with this setup.
VG.

localroger · 2012-01-01 18:04

RCFAST is very variable. A better option is the 5 MHz resonator with PLLx1 or PLLx2 instead of PLLx16. That gives you the low power operation but also the timing accuracy for serial comms.

pedward · 2012-01-01 23:13

I just hooked my MFJ SWR analyzer up as a frequency counter to the prop in RCFAST mode and it put out 6.5884Mhz NCO with a FRQA of $8000_0000. That makes it 13.1764Mhz. In RCSLOW, the frequency was rather unstable, .024Mhz, or 24Khz. This means RCSLOW was actually running at 48Khz. I had a dickens of a time getting it into RCSLOW, as BST output a _clkmode of 2 when asked for RCSLOW, which should be 1. Also, the Prop wouldn't switch to RCSLOW.

I suspect that the Propeller won't startup in RCSLOW because it's already in RCFAST on boot, and it won't fall back when the CLK register is loaded from a SPIN program. I did try explicitly giving the binary value to _clkmode and that didn't work. In the end I used CLKSET to get the Prop into RCSLOW.

Here's a test program to find your clock frequencies:

CON

  _clkmode = RCSLOW
'  _clkmode = RCFAST

PUB Main
  CLKSET(%0_0_0_00_001,20_000)
  DIRA[0]~~
  CTRA:=%00100 << 26 + 0
  FRQA:=$8000_0000

  repeat

kuroneko · 2012-01-02 01:22

pedward wrote: »

I had a dickens of a time getting it into RCSLOW, as BST output a _clkmode of 2 when asked for RCSLOW, which should be 1. Also, the Prop wouldn't switch to RCSLOW.

Works perfectly fine here (11kHz) with PropTool or BST. Note that the _clkmode constant is not the byte value sent to the clock register (see datasheet, 6.3.1. Constants).

@VG: Can you post your code which sets up the connection? Have you tried a slower baud rate?

pedward · 2012-01-02 03:15

Sure nuff' the constant is 2, but even when I did that I still had the Prop running at RCFAST. I stuck a frequency counter on the output and it still read fast, not slow. I'll do some digging once the counter is charged, maybe stick it on the 'scope too.

kuroneko · 2012-01-02 04:00

pedward wrote: »

Sure nuff' the constant is 2, but even when I did that I still had the Prop running at RCFAST.

Can you check the binary file at offset 4? I know that there is an issue with XINPUT (BST) but I haven't heard of an RCSLOW one.

VG · 2012-01-02 16:55

Some of you already talk to XBEE connected to Standalone Prop.

I am able to see messages (after using an external 20Mhz oscillator) from XBEE to Prop. If the message is more than 16bytes I don't have any LED Blinks from getMsg module. This happens only with the standalone prop with eeprom and 20MHz crystal not with a protoboard.

Is there a restriction from FullDuplexSerial??? I see the tx and rx bufffers are set to 16bytes. I changed those buffers to larger size. That did not work. Worse even those messages that are less than 16 bytes ended up "0" byte filled. Do you have any clues/suggestions about how to handle this? My messages are upto 30 bytes.

All my communication is at 9600 (very slow, but that's OK).

I have a proto board connected to the prop chip on BB on pins p30 and 31.

con
  _clkmode = xtal2                         
  _xinfreq = 20_000_000                                 

  ' Set pins and Baud rate for XBee comms  
  XB_Rx     = 22    '1 for proto or 22   ' XBee DOUT
  XB_Tx     = 23  '5 for proto or 23    ' XBee DIN                  
  XB_Baud   = 9600
  
  LED_PIN   = 20   '16 for proto or '20

  ' Set pins and baud rate for PC comms 
  PC_Rx     = 31  
  PC_Tx     = 30
  PC_Baud   = 9600   

var
  byte  Message[250]
  byte  MsgSz
  
OBJ
  dbgMsg  :     "FullDuplexSerial"             
  XB      :     "FullDuplexSerial"
  Str     :     "Strings3"          'From Strings2
  
PUB start|val, Val2, i,j, valp1,valp2               
  
  'start term
  dira[LED_PIN]   :=1
  LEDon(1)   '1
  dbgMsg.start(PC_Rx, PC_Tx, 0, PC_Baud) ' Initialize comms for PC   
  LEDon(0)
  LEDON(1)    '2
  XB.start(XB_Rx, XB_Tx, 0, XB_Baud) ' Initialize comms for XBee
  LEDon(0)
  LEDON(1)    '3
  LEDon(0)
  DbgMsg.tx(13)                                                       
  DbgMsg.str(string("Hello!! I'M Alive!!",13))
  
  i := 0
  val := 0
  repeat
     val := XB.rxcheck
     if val <> -1
       'LEDon(1)               
        getMsg(val)
     LEDon(0)
     Delay(10)

pub getMsg(ValA)|Valp1,Valp2,Val2,val,i
  'Check if the first character matches with the first letter of head
  i:=0
  if ValA == "A"
    Message[i++] := ValA
  else
    return
  DbgMsg.str(string("Rx:"))

  repeat  45            'Wait no more than a total of 45 seconds. Need to break this if there is infinit loop and waiting for message
     val := XB.rxcheck   'Original: XB.rx
     Val2 := val
     if (Val2 > -1)
        Message[i++] := Val2
     if Valp2 == 88 and Valp1 == 89 and Val2 == 90        'sequence XYZ received
        Message[i] := 0    'Zero terminate the string to be safe. But zero could be in payload. Maintain size
        repeat j from 0 to i
           LEDon(1)
           LEDon(0)
           XB.Tx(Message[j])
        return
     Valp2 := Valp1
     Valp1 :=  Val2

pub LEDon(Val)
    outa[LED_PIN] := Val
    delay(500)


{{ Clock Functions }}
Pub Delay(mS)
'' Delay ring
'' Delay(1000)     ' pause 1 second
  waitcnt(clkfreq/1000 * mS + cnt)

VG · 2012-01-04 19:51

This problem is fixed AFTER using FullDuplexSerial_rr004 from Obex instead of FullDuplexSerial. Thanks cruso99.
After a lot of trials I noticed 16characters is limit on regular FullDuplexSerial. Cruso99 made a simple fix in FullDuplexSerial_rr004 to be adjustable upto 256 (in 2 powered numbers.) Thanks to all those who helped me or directed into the right thing.

VG

XBEE on RCFAST

Comments