=====TRANSMITOR_TEST=====
Tdest address 0x201
0x1 0x2 0x1 0x4 0x52
0x7E Len 0 6
cmd 1
checksum is 1
0x1 checksum is 2
0x2 checksum is 4
0x1 checksum is 5
0x4 checksum is 9
0x52 checksum is 5b
a4
sent RFcmd
wait for delimit
start of char is 7e
rx length 0 74 = 74
[It hangs here on the TXresponse]
=====RECEIVER_TEST=====
SRX16 cmd
get for delimit
start of char is 7e
rx length 0 6
cmd id = 0
allocate 5 at 8e1
[hangs here]
I noticed I get the right length on RX but the wrong command ID and the wrong length on the TX response length. I was initially advised to use broadcast addressing (0xFFFF) but I have the same results and my application need to send individual packets to different devices on the network.
What you’ve posted looks like the output from a program you’ve written, so I have to guess at what each line really means. Under that assumption [1], I’m struck by the line
revision = 1083
. If that’s a report of the firmware version [2], then it’s well out of date and you probably need to update the firmware before you can expect reasonable behaviour.
If assumptions [1] and [2] are right, then here’s my experience. I bought a development kit a few weeks ago, and found that the firmware version as delivered was 1084. There have been two major updates since that version was current: the 10Ax firmware, and the 10Cx firmware. If you want to use the features that are currently advertized for the XBee, you do need the latest firmware. It’s not a big problem: you just need to use the X-CTU program to update your chips. There’s no cost involved. When I updated the firmware on my own chips, things suddenly started working.
There is another problem though: the 10Cx firmware has useful features that the 10Ax firmware lacks, yet the documentation has yet to be updated. To catch up on that, see other threads in this forum.
These lines seem to suggest that you received 7 bytes (rx length 0 6) and allocated a 5-byte buffer for them. On the face of it, that has to be a software disaster.
On the other hand, maybe your program was interpreting those lines differently. Unless you give us more details, you probably won’t get much more help.
Thanks for the response. It was definitely something I considered, but was hoping to avoid as my setup would have to change drastically (I’d have to breadboard up something).
I figured I could get away with the limited functionality.
I’ll try it when I get back in the lab.
After updating all the modules to 10A5 and blowing a power supply, I got back to were I was and tried the same thing.
The only difference from the log on both sides was the new fw revision. Similiar results still occur when I send a broadcast packet with the same data.