Shop OBEX P1 Docs P2 Docs Learn Events
confused about xbee flow control — Parallax Forums

confused about xbee flow control

AnnoyingAnnoying Posts: 50
edited 2010-05-05 05:23 in BASIC Stamp
·I am communicating between two xbees each on a Basic Stamp 2 using the adafruit xbee adapters (http://www.ladyada.net/make/xbee/), and I have been trying forever to get the timing right so they can effectively send data and receive data back and forth, but nothing has worked consistently. All the documentation I'm reading (basic stamp stuff) says that RTS is the flow control pin, and I'm confused about how the adapter has more pins that involve flow control, DTR-flow control into Xbee and CTS-flow control from Xbee. I just connected the RTS adapter pin and used that in the serout command·in the format SEROUT TX\RTS, 84, [noparse][[/noparse]sData] for both microcontrollers and they still are not communicating well.

Comments

  • WildatheartWildatheart Posts: 195
    edited 2010-05-03 20:42
    Try these simple TX and RX programs.
    [noparse][[/noparse]change pin assignments according to your setups]


    ' {$STAMP BS2}
    ' {$PBASIC 2.5}
    '***********************
    ' Simple_tx.bs2
    ' Example to transmit decimal
    ' Word values
    ' ***********************
    Baud CON 84
    myAddr CON $0 ' Node address
    DestAddr CON $1 ' Destination address

    RX PIN 0 ' Receive Pin
    TX PIN 1 ' Transmit Pin
    RTS PIN 2 'Connect to RTS flow control pin

    X VAR Word

    HIGH TX ' Idle transmit pin

    '
    [noparse][[/noparse] Xbee Inlitalization ]
    DEBUG CLS, "Configuring XBee for flow control", CR
    PAUSE 2000 ' 2 second guard time
    SEROUT TX, Baud,[noparse][[/noparse]"+++"] ' Enter command mode
    PAUSE 2000 ' 2 second guard time
    SEROUT TX, baud,[noparse][[/noparse]"ATNI BS2 Test Node",CR, ' Set description
    "ATMY ", HEX myAddr,CR, ' Set Node address
    "ATDL ", HEX DestAddr,CR, ' Set Destination Node address
    "ATD6 1",CR, ' Enable flow control
    "ATCN",CR] ' Exit command mode


    DO
    X = X + 1
    SEROUT TX,Baud, [noparse][[/noparse]DEC X,CR,CR] ' Send value of X as decimal

    PAUSE 500
    LOOP










    ' {$STAMP BS2}
    ' {$PBASIC 2.5}
    '******************************************
    ' rx_flow_control.bs2
    ' Simple data with flow control
    ' Example to receive decimal value and
    ' display in DEBUG Window using flow control

    '******************************************
    ' Example to receive decimal value and display in DEBUG Window using flow control
    Baud CON 84
    myAddr CON $1 ' Node address
    DestAddr CON $0 ' Destination address


    RX PIN 0 ' Receive Pin
    TX PIN 1 ' Transmit Pin
    RTS PIN 2 ' Connect to RTS flow control pin

    X VAR Word

    HIGH TX ' Idle transmit pin

    '
    [noparse][[/noparse] Xbee Inlitalization ]
    DEBUG CLS, "Configuring XBee for flow control", CR
    PAUSE 2000 ' 2 second guard time
    SEROUT TX, Baud,[noparse][[/noparse]"+++"] ' Enter command mode
    PAUSE 2000 ' 2 second guard time
    SEROUT TX, baud,[noparse][[/noparse]"ATNI BS2 Test Node",CR, ' Set description
    "ATMY ", HEX myAddr,CR, ' Set Node address
    "ATDL ", HEX DestAddr,CR, ' Set Destination Node address
    "ATD6 1",CR, ' Enable flow control
    "ATCN",CR] ' Exit command mode

    [noparse][[/noparse] Main ]
    DO
    DEBUG CR,"Press a key to retrieve data in buffer", CR
    DEBUGIN X ' Wait for key press

    GetData:
    SERIN RX\RTS, Baud,100,Timeout,[noparse][[/noparse]DEC x] ' Receive data with 100mS timeout/flow control
    DEBUG CR,DEC X ' Display data
    GOTO GetData ' Loop back for more data

    Timeout: ' No data, repeat
    LOOP
  • Tracy AllenTracy Allen Posts: 6,662
    edited 2010-05-03 21:15
    DTR is a control input to the XBee, used for updating the firmware of the XBee when it is connected to the X-CTU software from DIGI. CTS is a flow control output from the XBee that tells the external processor to stop sending it data, which is not normally a problem with the BASIC Stamp applications unless the radio link goes down. So the only one you need to connect is RTS, which, as you know, is an input to the XBee that the Stamp asserts when it is ready to receive data. Note that the RTS flow control needs to be enabled, done by the line,
    "ATD6 1",CR, ' Enable flow control
    in Wildatheart's program above.

    Another parameter you might want to experiment with is the "packetization timeout" RO.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • AnnoyingAnnoying Posts: 50
    edited 2010-05-03 22:25
    I tried those two programs and it didn't work--but this might have to do with the fact that my rechargeable 9 V batteries keep on losing charge so quickly. I don't understand why, because I now have a separate power supply for the big servo and the 9 V battery is just for the BS2/xbee. As I was debugging, I measured the resistance between the ground and +5 pins on the xbee adapter, and it was 8 kohm, is that normal?
    while I'm waiting for the batteries to charge: do those two programs only have to be run one time to configure the xbee for flow control? does the actual program have to include "ATD6 1"?
    would my code look like this:
    GOSUB GetOwnValue
    GOSUB SendValue
    GOSUB GetOtherValue

    GetOwnValue:
    PULSIN Yin, HiPulse, pulse2
    RETURN

    SendValue:
    SEROUT TX, 84, [noparse][[/noparse]"ATNI BS2 Test Node", CR, ' Set description
    "ATMY ", HEX myAddr, CR, ' Set node address
    "ATDL ", HEX DestAddr, CR, ' Set destination address
    "ATD6 1", CR, ' Use RTS for flow control
    "ATCN", CR]
    SEROUT TX\RTS,84,[noparse][[/noparse]"*",pulse2.HIGHBYTE, pulse2.LOWBYTE,CR,CR]
    RETURN

    GetOtherValue:
    SERIN RX, 84,[noparse][[/noparse]WAIT ("*"),pulse1.HIGHBYTE,pulse1.LOWBYTE]
    RETURN
  • WildatheartWildatheart Posts: 195
    edited 2010-05-03 23:43
    Both, the RX and the TX examples work perfectly with the BS2, the Xbee, and the Parallax supported adapter boards. I just copied, pasted and tested each of them as I listed them on this page.

    Why are you changing the code and concerning yourself with having to rerun the Xbee configuration each time you test run your setup? No, it isn't necessary to do a full reconfig each time, but for now your sole concern should be to establish some form of reliable communication between the two units. I'd advise you to stay with the basics until you get this to run.

    Also, I'd forget about testing servos at this time - and until you reach a comfort level with your ability to transmit/receive data without errors.

    Other Xbee posting here discuss battery life when used with the Xbee. I'd also suggest you read through some of them, if you haven't already.

    If you continue to have difficulty, please attach a wiring diagram of your two setups.

    Hope this helps.


    Post Edited (Wildatheart) : 5/4/2010 12:06:34 AM GMT
  • AnnoyingAnnoying Posts: 50
    edited 2010-05-04 02:26
    the communication works when one xbee is only receiving and the other is only sending, but my program in which the xbees send and receive data back and forth still didn't work after I ran the configuration program. So it must still be a timing problem right? I thought that the RTS addition to the serout command would solve all my problems...
  • WildatheartWildatheart Posts: 195
    edited 2010-05-04 03:44
    If I understand you correctly, you’re expecting the Xbee’s to compensate for your lack of program control.

    Program control and flow control are not the same. Flow control allows the Xbee buffer to continue receiving a limited amount of transmitted data while the BS2 is away performing tasks other than those related to xbee stuff. As for that buffer… think of a bucket hanging from a rubber snubber. There is an acceptable point at which the bucket hangs given a certain load. However if the bucket isn’t full, additional load added to the bucket simply stretches the rubber snubber a bit more. Up until the point when the bucket overflows, you’re able to save the unprocessed material subsequently added to the bucket for future processing.

    After you understand this concept, your programming skills must coordinate orderly bidirectional transmissions through program control. The Xbee's are good, but they're not good enough to replace the programmer
  • AnnoyingAnnoying Posts: 50
    edited 2010-05-04 05:09
    ouch. burnnnn. well I'm "new to this" and I would really appreciate tips for writing a simple program that transmits and receives data back and forth. is it so much more complicated than DO serout serin LOOP? i got these xbees because the parallax transmitter/receiver things (now obsolete) didn't work consistently. this stings like a bee.
  • WildatheartWildatheart Posts: 195
    edited 2010-05-04 05:20
    A little bee sting only hurts for a minute. Don't panic. If you got the two units to transfer data reliably, you're 70% there. You're doing fine.

    Now, think about the program - think about the process - think about what happens when your left hand transfers something to your right hand.

    Your left hand has the hotdog and makes a gesture to your right hand to take it. Your right hand has to be ready and looking for the handoff. ...and back and forth if you want to transfer information bidirectionally.

    If your right hand isn't waiting in a loop for the handoff, it's just la de da de da. You have to program the exchange, and be anticipating the handoff.

    Make sense?


    Post Edited (Wildatheart) : 5/4/2010 5:30:20 AM GMT
  • AnnoyingAnnoying Posts: 50
    edited 2010-05-04 05:35
    thank you but the hot dog analogy was a bit too abstract for me to apply to my program--I have WAIT in the serin command, and I thought the RTS in the serout command ensures that the serout instruction will only end once receiver allows it to send the entire output data. why is the solution such a mystery??? ahhhhh
  • WildatheartWildatheart Posts: 195
    edited 2010-05-04 05:50
    RTS is a buffer thing, it is not a program control thing. Use RTS, but forget about it for single data transfers.

    The transmitter must send... the receiver must be expecting the delivery, the receiver may or may not acknowledge receipt by sending acknowledgement back to the transmitter, and then the receiver acts on that offering, and visa versa.

    Stop thinking about RTS and flow control for now if you're just transferring single data at a time - think program control.
  • WildatheartWildatheart Posts: 195
    edited 2010-05-04 06:22
    Here's a simple exchange you asked for: (But you have to think it through to understand it) Try exchanging numerical data befor you connect a bunch of other stuff to your BS2's.

    But, you'll do better if you think about exchanging hotdogs from hand to hand - one gives, one is ready to accept - back and forth.

    The transmitter waits until the receiver sends DEC 22 before it begins its transmission to the receiver

    FROM THE PERSPECTIVE OF THE RECEIVER:
    Main:
    x = 0
    DEBUG "Ready to receive",CR
    DO
    PAUSE 5
    BUTTON Btn, 1, 200, 20, btnWrk, 0, No_Press ' a button press at the receiver signals the transmitter
    IF x = 0 THEN GOSUB Init_TXer
    GOSUB GetData

    No_Press:
    LOOP

    Init_TXer: '
    SEROUT TX,Baud, [noparse][[/noparse]DEC StartTX,CR,CR] ' now send transmitter the code/okay to begin transmission
    PAUSE 50
    RETURN


    FROM THE PERSPECTIVE OF THE TRANSMITTER:
    Main: 'wait till the okay to begin gets here
    PAUSE 2500
    DEBUG " Waiting to begin",CR
    DO UNTIL x = 22
    SERIN RX\RTS, Baud,100,Timeout1,[noparse][[/noparse]DEC x]

    Timeout1:
    LOOP


    FOR x = 1 TO 1000 ' got the okay to begin, now transmit data to receiver
    SEROUT TX,Baud, [noparse][[/noparse]DEC X,CR,CR]
    GOSUB Receive ' No data, repeat

    Receive:
    SERIN RX\RTS, Baud,100,Timeout,[noparse][[/noparse]DEC y] ' yet another bidirectional exchange
    IF y = 35 THEN GOTO Main
    Timeout:
    RETURN
  • AnnoyingAnnoying Posts: 50
    edited 2010-05-04 07:09
    thanks but I find it generally confusing... is a button really necessary?
  • WildatheartWildatheart Posts: 195
    edited 2010-05-04 15:27
    If not a button, then what?

    My simple RX example above uses a "keypress", not for bidirectional communication, but to unload data from its' Xbee. So, a keypress would work. An accelerameter's data would also work. The end of a PAUSE in a program would work. Something has to happen before something else happens.

    Now it is your turn. You have too much misunderstood information and its confusing you. So, back to square one! Please convince us that your two units are electrically and functionally working by explaining in your words what's happening in the simple RX and TX program above.
  • AnnoyingAnnoying Posts: 50
    edited 2010-05-05 00:53
    so the program you wrote is still a bit muddled to me, but I applied some stuff from it to my own program and it worked! I still have a few questions about it: 1. Why is the RTS only used in SERIN? 2. The addition to my code that made it work was this:
    pulse2 = 0
    DO UNTIL pulse2 > 0
    SERIN RX\RTS,84,[noparse][[/noparse]WAIT ("*"),pulse2.HIGHBYTE,pulse2.LOWBYTE]
    LOOP

    I'm confused about why this did the trick because I thought the WAIT ("*") would essentially create a loop.
    3. How do you know that this scenario won't happen: The serout command is executed on xbee #1, xbee #2 receives the data and then executes its serout command and then goes back to the serin command before xbee #1 has a chance to receive the data, so they are both stuck in the serin command?

    Also, I'm still having battery trouble. I have a 9 V battery separate from the servo power supply for the BS2 and xbee. It lost voltage very rapidly. any suggestions for a better lightweight power supply? I am already using a somewhat heavy supply for the servo, consisting of 5 AA batteries.
    THANK YOU!
  • WildatheartWildatheart Posts: 195
    edited 2010-05-05 02:27
    First of all, 5 AA batteries hooked together is not considered a ‘heavy power supply’ for your servo operation.

    Second, had you have gone back and read some of the other Xbee posts (as I recommended) you’d have learned that Xbee’s are power hogs (comparatively speaking). 9 volt batteries won’t last all that long.

    Third, you seem to have a mind of your own, and it is becoming clear that your failure to understand is largely due to a deliberate disregard of my suggestions.

    Fourth, I will not consider, nor will I comment on the code or other programming remarks you included in your latest comments. You are trying to suck me into something that is nothing close to the known to work code I listed for you to try.

    Fifth, if your primary focus in rotating servos, I do not have the time to help you. On the other hand, if you want learn something about the Xbee such that YOU can troubleshoot your own situations, I’ll hang in there with you.

    Now, if you’re going to hang in here under my terms, you will need to run, rerun, run again, study the code, and continue running the simple TX and RX programs until you’re no longer “muddled” about their operation. You will cut your servo stuff off of your BS2 (as I previously asked), and you will explain the operation of the TX and RX programs.

    Let’s try again.
  • AnnoyingAnnoying Posts: 50
    edited 2010-05-05 04:59
    First of all, "heavy" is a relative term and weight is a major factor in my project.

    Second, I have been looking up xbee posts and do not see any helpful information about what battery to use.

    Third, I do have a mind. The code you provided makes no sense to that mind.

    Fourth, I tried something similar to a few lines of that code that was comprehensible, and it WORKED.

    Fifth, my primary focus is not in rotating servos. All my questions have been directed at getting the xbees to communicate. I merely mentioned that I am already using a separate supply for my servo, because my sole problem is finding a lightweight battery that is sufficient for the bs2/xbee, due to project constraints.
  • WildatheartWildatheart Posts: 195
    edited 2010-05-05 05:23
    Regarding your need for a “heavy” power supply… you’ll need to balance price, weight, and runtime. Only you can decide the parameters that you’re willing to live with.

    Regarding your inability to find information in the forums on the Xbee power requirements, see Joshua Donaldson’s post at http://forums.parallax.com/showthread.php?p=903678

    If your “sole problem is finding a lightweight battery that is sufficient for the bs2/xbee, due to project constraints.”, I can’t help you anymore.

    If you were able to glean a few lines of code that WORKED for you, then case closed. I’m happy to have helped you.

    But if you ever want to know more about RTS/flow control stuff (where this all started) we can always revisit the concept if you choose.


    Post Edited (Wildatheart) : 5/5/2010 5:28:56 AM GMT
Sign In or Register to comment.