I’m using two XBee Pro ZB modules (XBP24BZ7SIT-004) with the latest firmware.
At the moment, I am using them simply for bi-directional data transfer between the two modules - There is a possibility of adding a third and maybe fourth module in future.
The data transfer at the moment is mainly one way - sending from one module back to the ‘base’ module attached to the computer but I do need to send characters from the computer to make the MCU on the other end do stuff
Anyway, I have a bit of an issue. I appear to be able to send and receive fine from one module, but the other module appears to not be sending data correctly (I think it’s the sending module from how the tx light responds on that end) - it sends the first few characters fine (sometimes) and then stops sending them, appears to buffer a load and then send a load in one go. It also drops a load of characters when it does this.
I have tried changing the configuration around (swapping the coordinator firmware over to the other module) but that seems to make no difference whatsoever. I have also tried changing baud rates, resetting the modules - re-configuring etc.
This setup all works fine with my other XBee modules so it is definitely a module issue.
Like I say, one of the modules appears to work fine so I’m a bit worried that there will be no solution to this apart from buying a new module. I’ve only just got these two and literally took them off the anti-static foam after a few weeks, tested them and found this issue.
If anyone has any bright ideas of what to try, or just a better idea of how I should be configuring these modules then I’d love to hear it. I’m pretty new to them (got some chip ant. series 1 modules) so I’m learning all the time.
Here you have mentioned “I have tried changing the configuration around (swapping the coordinator firmware over to the other module) but that seems to make no difference whatsoever. I have also tried changing baud rates, resetting the modules - re-configuring etc.”
So, What is Your question? You are not able to configure your modules again? Or you are Facing difficulty in transmitting only between this two modules?
Anyway, I have a bit of an issue. I appear to be able to send and receive fine from one module, but the other module appears to not be sending data correctly (I think it’s the sending module from how the tx light responds on that end) - it sends the first few characters fine (sometimes) and then stops sending them, appears to buffer a load and then send a load in one go. It also drops a load of characters when it does this.
Or you are Facing difficulty in transmitting only between this two modules?
That is the issue I am facing - one of the modules appears to be buffering data and losing lots of data also.
For example, if I have both modules connected to two instances of X-CTU then I can send data from one module to the other perfectly, the data is transferred quickly and appears on the second serial monitor almost instantly.
However, if I send data the other way then the first few characters normally send fine (about 8 or so but isn’t the same number each time) but then after that, a load will not reach the second serial monitor, if I keep sending characters then some of those will get to the second serial monitor and will arrive in ‘chunks’ (also of a random length it appears).
Are there any other resets I can try apart from the factory reset?
Do you think it might be a hardware issue?
Unfortunately, a ‘mesh’ is not a good solution for a simple tossing around of characters types in hyperterm. What happens is the mesh can add delays of up to 5 seconds, plus will throw away packets when it gets busy. Assuming you are trying to type characters by hand, then they are moving by 1 or a few characters per packet.
A mesh prefers a more ‘managed’ approach, so using the API firmware and using software to bundle the data complete with a length field. The mesh is really designed for small, discrete transactions such a sensor waking and sending in a new reading.
You will find the Series 1 (802.15.4) much better at the raw byte forwarding as they can sustain throughput with perhaps 50msec or less latency, but they do not work as a mesh.
In your case, playing with the RO setting to try and reduce packet count by packing more data into fewer packets might help. Might help, or might not.
Unfortunately, a ‘mesh’ is not a good solution for a simple tossing around of characters types in hyperterm. What happens is the mesh can add delays of up to 5 seconds, plus will throw away packets when it gets busy. Assuming you are trying to type characters by hand, then they are moving by 1 or a few characters per packet.
Ok I can understand that - I am wondering why it works one way though and not the other - one of the modules is definitely working better than the other.
So the API firmware is better for what I want to be doing?
I will be sending packets of data once a second from one of the modules and then sending simple commands back the other way (single characters mainly)
I have these modules now, what’s the best way forward?
In your case, playing with the RO setting to try and reduce packet count by packing more data into fewer packets might help. Might help, or might not.
Well like I say, I will be doing that but I do have to send single characters to one of the modules every so often and they really need to get there.
