I am building a “system” which will have 5 radios on the same Channel/Pan ID all communicating with each other. I am going to allow the user to change the Channel or Pan ID as they may have multiple systems and want to interchange parts. It is also possible that multiple users will be near each other and they will be “separated” by using AES encryption (plus initially we will assign each system a different Pan ID).
I am thinking about using API commands and broadcast mode so that one unit can change the Channel/Pan ID for the other 4 units in the system. I am concerned that if another system is nearby, that it would get changed as well. I don’t know whether AES is used in API mode. The plan is to put one unit in API mode and transmit Remote AT commands to the other 4 to change their Channel/Pan ID.
Firstly, have you checked that the remote API command to change channels works as you’d expect? If you page back in the topics of this forum for the topic title “set the transmission channel”, you’ll find a reply from me in which I report trying to do exactly that, but with only a corrupted response packet to show for it. I had tried the experiment only to try to help the original poster, and I didn’t take the matter any further. My firmware version was and is 10C8. This may provoke corrections from the fine folks at Digi if the problem was somehow of my making - any such corrections will be humbly accepted
Following on from that, though, can you clarify what exactly you’re trying to do? In your first paragraph, I see that users may want to interchange parts. In that case, one part needs to have its settings changed. But in the second paragraph you talk about changing the channel and/or PAN for a whole set of parts. Those seem to be different requirements.
I am at the latest firmware version and can’t remember what that is. I have not tried it yet - was trying to gather information first if I could.
You are correct that there are two requirements. That to change one remote unit and that to change them all. I would tell the user to handle this by only having those ON that they wanted to change. But I don’t want one user affecting another if they happen to be near each other. This system is used in a competitive racing environment and they would love to be able to mess each other’s stuff up :). That is why I am using AES and not allowing them to change the AES key.
Ok, so if your firmware allows you send the necessary commands in remote API mode, then I can see how the users can change channel and PAN on their units.
What I don’t see is how one user can reprogram a module for another user to operate. They would surely need to change the encryption key as well - and my understanding is that you won’t allow them to do that.
I guess it all depends on the controlling computer - maybe you could allow user A to remove their encryption from a module, and then allow user B to set their encryption on that module, all without giving them the general ability to change encryption at will. This would mean storing the encryption keys in the controlling computer(s), which might or might not be a security problem depending on the setup.
It also depends, I suppose, on the module interface. If users might deliberately want to mess each other up, and if they can plug modules into their own laptops with X-CTU running, they could do what they liked. And if they can open the box and remove the XBee, they can do exactly that. I guess part of this design is going to have to be an assessment of just how devious and knowledgable the users might be.
