Shop OBEX P1 Docs P2 Docs Learn Events
XBEE Transmitter initializing Receiver by mistake — Parallax Forums

XBEE Transmitter initializing Receiver by mistake

ptig185ptig185 Posts: 6
edited 2011-09-14 03:08 in Accessories
Hi,
I'm programming some Xbees to transmit some solar panel values (Voltage and current). I have the two of the communicating at 9600 baud, no rts-cts yet.
My initial code is borrowed from the AppBee Document since I'm using PICs and PB-Pro language.

I have both tx and rx first initializing the XBEE set up using AT commands and the "+++" sequence with the time guard band.
It seems that as I initialize the TX module, that it is also transmitting that "+++" sequence out to my receiver and causing it to go into "COMMAND" mode and stopping it.
If I reset the RX pic after the TX has initialized then the RX takes off and starts receiving my test data which is a sequence of numbers 0-65535.
If I reset the TX PIC then the RX pic gets put into COMMAND mode and stops receiving.

The only way so far to get them both to work is to comment out the "CONFIGURING" code in the TX PIC so the RX pic receives the data.
Apparently the Apbee_Doc.pdf example has no issue?

The only difference in hardware that I can see is theat the Apbee RX side is using the RTS line from the XBEE, which I am not doing at this time.
I am using the hardware serial USART and the PICBASIC HSERIN2 command to receive the data.

has anyone had this issue out there?


Thanks,
Brian

Comments

  • sylvie369sylvie369 Posts: 1,622
    edited 2011-09-11 06:53
    ptig185 wrote: »
    Hi,
    I'm programming some Xbees to transmit some solar panel values (Voltage and current). I have the two of the communicating at 9600 baud, no rts-cts yet.
    My initial code is borrowed from the AppBee Document since I'm using PICs and PB-Pro language.

    I have both tx and rx first initializing the XBEE set up using AT commands and the "+++" sequence with the time guard band.
    It seems that as I initialize the TX module, that it is also transmitting that "+++" sequence out to my receiver and causing it to go into "COMMAND" mode and stopping it.

    [Respectfully, and take this with a grain of salt...]

    How do you know that the TX XBee is sending "+++"? How do you know that the RX XBee is entering command mode?
    I may be mistaken, but my hunch is that you're misdiagnosing the problem, and that the code on whatever is connected to your receiving module is causing the problem.

    Have you tried plugging the RX XBee through a USB board directly into your computer without any microprocessor (e.g., PIC) in-between? If the problem is in your code (as I suspect), you should see the data come in when you turn on the TX unit. If not, then sorry, but I'm wrong. <grin>

    Alternatively, do you really need to use the software to configure the XBee modules each time you power up? You could set them, and then save the settings, and remove the configuration code from your programs. Unless you're expecting to use different settings each time the system is on, this would seem to be a way to avoid your troubles.
  • ptig185ptig185 Posts: 6
    edited 2011-09-12 07:40
    Yes I did eventually plug into the X-CTU interface and found that the module was not getting altered and both tx-rx still had address 0 in NV memory.
    I then disabled the Config sequence and was sending data just fine.
    I also noticed that in the example codes I followed, there was no Write to NV (ATWR) command ever given.
    I'll add that tonight and test in X-CTU.
    I read the Guard time back as 1000mSecs in X-CTU so I'm fairly sure I was not executing that properly.
    I'm not sure what GT duration I should use in framing the "+++". Is it exactly the GT value set in NV or anything longer than the GT value that works?

    I'll experiment on that one.

    Thanks,
  • ptig185ptig185 Posts: 6
    edited 2011-09-12 07:43
    No, I'm not expecting to change the values every time but possibly adjust the tx power level.

    By the way, I used to fly sailplanes in the past . Are you a licensed glider pilot?


    Thanks,
    Brian
  • sylvie369sylvie369 Posts: 1,622
    edited 2011-09-12 08:05
    I'm not a licensed glider pilot, though I still would like to become one someday. I've got about 10 hours, if I remember correctly (I do have a Private Pilot license, though).
    That photo is just from a wonderful time I had in Hawaii flying the Grob 103 out of Dillingham Field. Absolutely spectacular.

    It sounds as though you're making good progress. I'll keep tabs on this thread - I'm curious about how this resolves.
  • johnfosjohnfos Posts: 59
    edited 2011-09-12 11:59
    @ptig185:

    You asked about guard times. The line needs to be quiet for at least as long as the guard time, so for safety you'd probably want to make your period slightly longer than the GT parameter says. 1.1 seconds sould be plenty.

    When you're doing your own configuration from a program, you do need the WR command if you want the results saved. When you program the XBee from X-CTU, X-CTU will do the WR quietly for you.
  • ptig185ptig185 Posts: 6
    edited 2011-09-12 16:55
    johnfos,
    Thanks, Yes I determined the guard time requirement by trial.
    I also now have the NV parameters programming by observing the actions in the X-CTU terminal mode.

    I have yet to "string": the commands but for now I'm using CR after each parameter change and waiting 100msecs after each one.

    HSEROUT2 ["X"] 'someone recommended and initial character first
    PAUSE 1100 ' Guard time must be > GT parameter
    HSEROUT2 ["+++"]
    PAUSE 1100
    HSEROUT2["ATDL",HEX4 $35C,CR]
    PAUSE 100 'mSECS
    HSEROUT2["ATMY",HEX4 $309,CR]
    PAUSE 100
    HSEROUT2 ["ATWR",CR]
    pause 100
    HSEROUT2 ["ATCN",CR]
    pause 100

    so this seems to work fine
    I noticed that when entering an "ATDL400" in the terminal that the following comma entered caused an execution of that command just as if I entered a <CR>
    I then see the "OK".

    I'm still not sure when to wait for the "OK"'s so I have the 100msecs after each one.
    I used :this just after the parameter change:
    HSERIN2 1000,reconfigure,[WAIT("OK")]
    but this just seems to always loop back to reconfigure as if it's not getting the OK in time.

    thanks,

    Brian
  • ptig185ptig185 Posts: 6
    edited 2011-09-14 03:08
    Well I got all the issues resolved. I'm programming and reading settings back from the xbee.
    I switched to rts cts handshaking mode and flushing the buffer and that helped.
    I also failed to correct for the incoming HEX values from the RSSI inquiry.
    Data is transferring perfectly and I can now start up and shut down the transmitter without glitching the receiver.
    Also at one time, my Font arrays for my NOKIA LCD cell phone display on the board was over running my constants in lower memory. That was a stopper for and hour. As I added more constants and variables, there was eventually a collision and overwrite of code space message.

    Thanks for the help out there and comments....

    Brian
Sign In or Register to comment.