OK, fine, I didn't fix it. It failed again and this time I watched it for around 30 minutes. I used an XBee hooked into the USB port of my laptop and watched the data coming in. Each line from the Power Monitor was broken off at the 40 character point, then a couple of seconds later, the rest of the line came in. About half the time some message from some other sensor came in between the first 40 characters and the rest of the data. Changing baud rates didn't seem to help.
I went through the Digi documentation and prowled around their site looking for something related to this kind of problem and all I came up with was various warnings about waiting three character periods for the packet to be transmitted and transmit packets being sent when the serial Tx buffer was full. Neither of these seemed to be the problem. The data was cutting off in the middle of a line. I wanted to try the Serial.write() method, but since it takes days to fail I wasn't too hopeful of getting anything concrete short term.
However, at least according to the Digi documentation, using the API mode would guarantee the entire message would be sent as one unit. So, I stole code from the Acid Timer and switched the XBee programming to API mode 1. Yes, API mode 1. For those of you just starting out with XBee, there is a misconception about the API modes. In API mode 1, you don't have to escape any character at all. In API mode 2, you have to escape the flow control characters XON, XOFF, ESC as well as the actual 0x7E that is used to start a packet. This is to allow for software flow control, but I haven't looked into doing that at all. So, in API mode 1, you can do anything that you can do in API mode 2, except easier. Trust me on this, I've seen many, many people get confused by this; including the authors of the various how-to guides.
At any rate, the device is back in service using API mode 1 and sending data just fine. It's been a few hours and no problems have come up. I'll check on it reasonably often over the next couple of weeks to see if I have to do something else.
One other thing that isn't made clear in the documentation or any of the how-to guides I've looked at. You can mix and match API mode and transparent mode on these devices. For example the XBee I use to monitor what is going on is configured for transparent mode and it can see the broadcast sentences from every device broadcasting just fine. The packet headers and such are stripped off and the data is delivered out the serial line. This is a nice way to see what is going on over your network.
The other parts of this problem are described here and here.
Hi from far away,
ReplyDeletereading your article today I took one XBee off the box and I tried to monitor communication between another two ones. The only result I got was very well bricked XBee ...
Now after one hour work that XBee is back alive - huhh.
My question is: I have two XBees (Co-ordinator and End device) in API2 mode exchanging the data. How to set third one connected to PC in order to monitor the traffic ??
Cheers
Vladimir
What I think is happening to you is that you have the two XBees addressed to talk to each other and no one else. XBee 1 has a destination address of XBee 2 and vice versa. So, the third XBee won't decode the data since it's not part of the conversation. This is why I use broadcast mode. In broadcast all XBees will decode the data and send it out the serial port. So, set all three of the XBees to use destination address 0x000000000000FFFF (broadcast) and you should be able to monitor the traffic.
ReplyDeleteThis is how I can see all the traffic from all of my XBees. If I had a hundred or so XBees, I would have to rethink this since the broadcast traffic would clog up the network, but for a small number of them it will work just fine. It's like each XBee is shouting into a room so that all the others can hear it.
A trick I use when I'm changing a XBee is to save the profile in XCTU to a file on my laptop. That way, I can put it back pretty easily when I mess it up. The save button is on the same screen where you choose the software to load on the device. I spent two days getting one back when I was first starting to experiment with the devices and bricked one of the only two I had.
Yes, that's true. SW controlling End XBee sends the data packets to another (Co-ord) using its address. So no broadcast trasmission. This is in order to get back status data if the packets were received.
DeleteI'll be thinking a little bit more about it. Thank you for your answer and good night to Arizona. We have already morning here so let's go to work :-)).
Cheers
Vladimir