I configured the xbee’s to a baud rate of 38400,57600 and 62500 with the same results
XBEE 1
atmy: 30
atni: DIY
atvr: 10E6
XBEE 2
atmy: 10
atni: BOT1
atvr: 10E6
Do i need to pair the XBee’s with the one on the DIY transmitter? I’m a bit confused. I’m not sure what to enter for Current MY: 00 NEW: .
I tried entering the 10 for the B0T1. all i get *_unknown_10. when select scan I get. I think i’ve gone off the beaten path. could you push
me back on track? 
I don’t think it would mater any, but on my remote I have set the MY to 0. You might want to try that and see if that helps.
The My is it’s own address that it will send out to everyone to tell them to communicate with you.
If you go into the manual way of entering the address like: 10 It will report the _unknown_10 as it does not know it’s name. There is code to try to query it…
Obviously make sure that the baud rate the you leave the XBEE configured for probably 62500 matches the baud rate used by the programs, or they won’t be able to communicate with the xbee.
If it were me, I would start off trying to debug things, by seeing if the XBees are working at all with the program. To do that I have several different debug options that are under #ifdef settings. If you go into xbee_taserial_support.bas near the top of the file you will see some lines like:
'DEBUG_OUT con 1
'DEBUG_VERBOSE con 1
'DEBUG_ENTERLEAVE con 1
'DEBUG_DUMP con 1
'DEBUG_WITH_LEDS con 1
I would probably start off uncommenting the DEBUG_OUT and DEBUG_VERBOSE and see what types of messages show up on the debug terminal.
Likewise for the transmitter I would also uncomment the define for DEBUG. Note on the Bap28 some of the debug messages will be garbled as the the serout to s_out at 9600 baud can be screwed up by the code processing interrupts…
In the Arc32 phoenix code in the file phoenix_control_diy-xbee.bas file There are also debug defines. Make sure DEBUG_XBEE and DEBUG_VERBOSE are uncommented. Also make sure you are actually building with XBEE support. That is in the …CFG_bas file make sure USE_XBEE is defined. In this code you can also have USE_PS2 defined as I have it working with both controllers at the same time… Sortof - that is if it gets a connect from DIY it will stay with that until released…
Kurt
I checked all my connections and ran the config program
All the XBee are now set to the same baud rate
On the transmitter:
Now i select A to scan for xbees i get XXXXBOT3. XXXXbeing random characters 
Now you may understand what I was talking about the RTS line back several posts back: viewtopic.php?f=21&t=5447&start=303
Receiving or transmitting data over the hserial (XBEE) causes interrupts to happen. These interrupts can cause the LCD to garble up. I normally fixed this by enabling the RTS line, which I have a hack in place that tells the XBEES to not send data back to me, which helps in the LCD display…
It sounds like it found it so if you select it does the transmitter and receiver talk?
Kurt
Yes I do recall you mentioning this. This may be a silly question. Can you use the transmitter with the RTS wire and not use the wire on the other end?
I’m not sure i was a bit confused at what i was seeing
Good morning again,
Not a silly question. I will try to do a quick and dirty stick figure here, as anyone can tell you my hand drawn ones don’t look any better 
[p1]=[Xbee1] --- [Xbee2]=[p2]In this Processor 1(p1) is connected to XBee1 through 2 or 3 wires, likewise Processor 2 is connected to Xbee2 by 2 or 3 wires (plus ground…).
For things to work Processor 1 has to talk to xbee 1 at the baud rate that XBee1 is configured for. Likewise Processor 2 has to talk to Xbee2 at whatever speed XBee 2 is configured for. Often they are both configured to the same baud rates, but this is not necessary. Changing the XBees baud rate does not change the speed that the xbees talk to each other over the air it is simply the speed that the xbee talks to what ever hardware that is connected to it’s DIN and DOUT pins. Likewise the RTS line is simply a hardware handshake between the XBee and processor that allows the processor to say it is ready to receive data or not. Actually that is a slight lie, it actually is setup to say that my input buffer is almost full so please don’t send any more. In reality when you signal this, you can still receive 1 or 2 characters after that point (if there are any characters pending on the XBee).
The XBees have their own input and output buffers, so even though you tell it not to send anything it should not lose anything, unless of course it receives more data than the size of its buffer. As I mentioned above XBEE1 and XBEE2 can be communicating with their hosts at different speeds. One obvious issue would be if the higher speed one was trying to send more continuous data than the receiving side can download at it’s lower speed, than data could be lost. Not much of an issue for us here as I am sending small packets and doing handshaking, so I have done things like run one at 62500 and anther at 38400 and sometimes at 57600…
Sorry for the long winded answer.
Kurt
Kurt
Kurt,
Now those were some nice stick figures 
The lights started coming on all over the place. That also explains some of the other things I was seeing. I had set 2 xbee’s (with antenas) @ 62500 and left my the other 2 xbees(with chip antenas) @ 38400. So I was seeing them also.
Thank you.
I let you know if i can select any of them
This is what i get from the terminal for the DIY transmitter
Init Timer
Enter: Init Controller
Entår: WaitHseroutComplete
Exit: WaitHseroutComplete
Exit: Init Controller
£ŒP:7E00080q03000000 01 : 0010 - EA
£ŒP:7E00080q04000000 01 : 0010 - E9
£ŒP:7E00080q05000000 01 : 0010 - E8
£ŒP:7E00080q06000000 01 : 0010 - E7
£ŒP:7E00080q07000000 01 : 0010 - E6
£ŒP:7E00080q08000000 01 : 0010 - E5
£ŒP:7E00080q09000000 01 : 0010 - E4
£ŒP:7E00080q0A000000 01 : 0010 - E3
£ŒP:7E00080q0B000000 01 : 0010 - E2
£DP:7E00060a0C000000 02 : - F0
£DP:7E00060a0D000000 02 : - EF
£DP:7E00060a0E000000 02 : - EE
And this is from the ARC32
Phoenix-Arc32 keyboard monitor
D <start addr>]<cnt>] - Dump EEPROM memory
O - Enter Servo Offset mode
S - Download sequence(s) - VB call only
T <n>] - Set or show debug Trace level
V <n> - View Sequence
: Exit: ReceiveXbeePacket
Enter: Init Controller
I’m programing my spare BB2 bap28
when i try to use the TestXBee program i get a complie error
Error: FILE D:\DIY XBEE - PACKET MODE\XBEE PROJECTS\XBEE_TASERIAL_SUPPORT.BAS(LINE 740) : [TOKEN [] : Unexpected argument typeserout s_out, i9600 "RCV XBEE Packet: ", hex _bAPIPacket(0), " From:", hex _bAPIPacket(1), hex _bAPIPacket(2), |and when i try to use the XBeeTest program i also get a complie error
Error: FILE D:\DIY XBEE - PACKET MODE\XBEE PROJECTS\XBEETEST.BAS(LINE 40) : [TOKEN GETXBEENDLIST] : Expected Labelgosub GetXBeeNDList], cNodesI will look in the morning, but check to make sure you have a recent compiler and what BAP is the compiler configured for?
Kurt
I’m using the BasicMicro Studio 1.0.0.35 and configured it for BasicATOMPro 28.
Whats the line of code before the serout command. Also please post the entire serout command. It’s continued on the next line based on the “|” at the end.
For the second error find the function, “GetXBeeNDList”. If you can’t find the label in the code, neither can the compiler.
Sorry, it was a semi-simple probably out of date program I used to try to debug how the Node discovery worked, before I mucked up the actual transmitter code. The label probably got accidentally deleted when I merged the code into the transmitter code.
The place the label belongs and the comment above should be updated, to look like:
;==============================================================================
; GetXBeeNDLISt
;==============================================================================
GetXBeeNDList:
_cNDListIn = cNDList ; remember how many we had from EEPROM (no need to check dups of items beyond this)
; now lets do the XBEE query and see if anything changes
gosub ClearInputBuffer ; make sure we toss everything out of our buffer and init the RTS pin
pause 20 ; have to have a guard time to get into Command sequence
#ifdef XBEEONHSERIAL
hserout "+++"] ; try to get it's attention
gosub WaitHSeroutComplete
pause 20 ; have to wait a bit again
hserout "ATND", 13, | ; output the request for Node discovery.
"ATCN",13] ; Exit command mode
...Not sure of the state of the actual program if it acutely matches the code in the transmitter now or not. But note this code was not changed to XBEE packet mode…
Kurt
#ifdef DEBUG_VERBOSE
serout s_out, i9600 "RCV XBEE Packet: ", hex _bAPIPacket(0), " From:", hex _bAPIPacket(1), hex _bAPIPacket(2), |
": ", hex _bAPIPacket(bDataOffset)," ", hex _bAPIPacket(bDataOffset+1)," ",hex _bAPIPacket(bDataOffset+2)," ",hex _bAPIPacket(bDataOffset+3)," ",|
hex _bAPIPacket(bDataOffset+4)," ",hex _bAPIPacket(bDataOffset+5)," ",hex _bAPIPacket(bDataOffset+6)," ",hex _bAPIPacket(bDataOffset+7),13]
#endif
Kurt,
I added the label and now it complies. I It only returns FFFF and 0’s when I run the program.
When i try to use DEBUG_VERBOSE on the XBEETEST it get the complie error listed above. Is that because
?
I went back and reprogramed my DIY transmitter to ensure i was using the correct board.
I reprogramed my XBEE modules using the XBEE COnfig app.
-When using the VB APP and selecting discover DL’s It finds all three XBEE’s.
-The transmitter see’s the XBee as they all light up when selecting “A” scan for xbee’s. It finding one and displays it
on the LCD. It lets me select it.
I need to program my ARC32 and spare BBII BAP28 to see if one of them will reply.
Hi Phil,
Two issues: does not compile when debug verbose. I don’t know why it compiled before and not now, maybe compiler got stricter or somehow a comma got deleted. Go to the line that did not compile, you will see something like:
serout s_out, i9600 …
It needs to be:
serout s_out, i9600, …
Now for APi versus transparent mode, yes that could be an issue here!
That is, the call to InitXbee, does tell the XBee to go into API mode. So not sure how it will respond with the +++ like commands here.
If I get a chance I may try to hack up a version with the API mode, that can be extracted from the transmitter program.
Background information: when you are not in API mode you use the +++ got get into command mode. In command mode you issue the command: ATND
This does a node discovery. Which it will do a broadcast to all other nodes asking them to send back information. The information is sent back as text with something like:
<The logical 16 bit address set locally by ATMY command>
Serial number high
serial number low
A strength indicator
Node Indicator Text for the node set by the ATNI command
Each line is terminated by a CR. If you get a zero length MY, this says that the command has completed and no more nodes will be reported.
When in API mode, you build a packet, which has the command in it “ND” and broadcast it. Again it uses the same time outs, but of getting text messages returned it receives a packet back with the information and it is terminated when you get a certain type packet returned.
I hope that helps.
Kurt
Kurt
Phil, the good (or bad) news is I am looking into it.
I have the xbeetest program updated with the packet mode of the ATDL command and found it was having problems. That is the bad new. The good news is that I have a version of the test program working now on both a Bap28 as well as a Bap40 which should be the same as on Arc32, which I may test out later. I now need to merge it back into the transmitter program and upload all of this. Note: on Bap40 and Arc32, I have partial changes in place to use HSERIAL instead of serout s_out, i9600, but not yet in the support functions… But if you wish to try the probable changes out in your transmitter to see if it finds your bots, before I get the chance to finish and test it out:
Change the code in the DIY Transmitter.bas file for the function UpdateNDListFromXBEE: to
[code]UpdateNDListFromXBEE:
_cNDListIn = cNDList ; remember how many we had from EEPROM (no need to check dups of items beyond this)
#ifdef DEBUG
serout s_out, i9600, “C: UNDL”, 13]
#endif
; use same helper function to send command as our get functions
gosub APISendXBeeGetCmd"N","D"]
; I think I can loop calling the APIRecvPacket - but as the data it returns is in a different
; file, I may have to have helper function over there.
repeat
;gosub APIProcessGetXBeeVal@_bAPIPacket,32,3000000], _cbRet
gosub APIRecvPacket[3000000], _cbRet
if _cbret > 11 then ; MY(2), SH(4), SL(4), DB(1), NI???
; ok lets extract the information for this item
awNDMY(cNDList) = _bAPIPacket(0) << 8 + _bAPIPacket(1)
alNDSNH(cNDList) = _bAPIPacket(2) << 24 + _bAPIPacket(3) << 16 + _bAPIPacket(4) << 8 + _bAPIPacket(5)
alNDSNL(cNDList) = _bAPIPacket(6) << 24 + _bAPIPacket(7) << 16 + _bAPIPacket(8) << 8 + _bAPIPacket(9)
; The Node identifier starts in bTemp(11)
; We want to blank this field out to our default size we use
_i = _cbRet - 12 ; number of actual characters transfered.
while _i < CBNIMAX
_bAPIPacket(_i+11) = " "
_i = _i + 1
wend
_fItemDup = 0
if _cNDListIn then
for _i = 0 to _cNDListIn-1
if (alNDSNH(_i) = alNDSNH(cNDList)) and (alNDSNL(_i) = alNDSNL(cNDList)) then
; We have seen this one before...
_fItemDup = 1; ; signal that this item is a duplicate...
; but we will also make sure the MY or the NI has not changed.
if (awNDMY(_i) <> awNDMY(cNDList)) then
_fListChanged = 1; we know that we need to write the stuff back out...
awNDMY(_i) = awNDMY(cNDList)
endif
for _j = 0 to CBNIMAX-1
if abNDNIS(_i*CBNIMAX + _j) <> _bAPIPacket(_j+11) then
abNDNIS(_i*CBNIMAX + _j) = _bAPIPacket(_j+11)
_fListChanged = 1; we know that we need to write the stuff back out...
endif
next
endif
next
endif
; only save away the data if this is not a duplicate and we have room
if (_fItemDup = 0) and (cNDList < CMAXNDLIST) then
for _j = 0 to CBNIMAX-1 ; copy the NI string in.
abNDNIS(cNDList*CBNIMAX + _j) = _bAPIPacket(_j+11)
next
cNDList = cNDList + 1
_fListChanged = 1 ; yes the list changed - have new node
endif
endif
until _cbret <= 11 ; MY(2), SH(4), SL(4), DB(1), NI???
return
[/code]
The issues was: Code changed for what the receive a packet returned. It used to only return the user data, now it returns the whole packet after the size, so there are something like 5 extra bytes of data that we need to skip over.
Second issue: for some reason before code that looked like: My = a(5) << 8 + a(6)
was returning the correct data, now it appears to be returning 0. But: My= (a(5) << 8) + a(6)
Works.
Kurt
Quick update: I think I have the changes merged into the transmitter program. Also did some more of the Pro40/Arc32 #ifdefef stuff for debug. I sure wish there as a better way than:
#ifdef DEBUG
#ifdef BASICATOMPRO28
serout s_out, i9600, "Debug stuff"]
#else
hserout "Debug Stuff"]
#endif
#endifI think all of the changed files are now in the zip file…
DIY XBEE - Packet mode.zip (270 KB)
Kurt,
GREAT 
I was about to ask about some thing on the first code you posted. But you already posted an update to that which cleared what i was seeing.
It found all my XBee’s. One connected to the PC, one connected to the ARC32 and the other connected to the BAP28. Displayed them by the correct
NI and it matched the DL and MY.
Question:
In the “diy transmitter.bas” code, only if I uncomment DEBUG con 1 i get a linking error
C:\Program Files\BasicMicro\Basic Micro Studio\bin\ld.exe : region text is full (d:\diy xbee - packet mode100902\xbee projects\diy transmitter.bin section .text)Should i only be using the one in the “xbee_taserial_support.bas” file ?
I’ll load the xbee projects on my bap28 and Arc32 board so i can try and play.
Thank you
Phil