I did a project a couple of years ago using XBEE modules. The project was an theatre audience voting system using small handheld devices with PIC18LF1330 an accelerometer and XBEE modules communicating back to a linux server. I used the API mode for comms.
The modules I used 2 years ago, were… Hardware version 1707 and 1083 firmware.
Now I need to make some more, (bigger audience), the modules that I have are Hardware version 1947 and firmware 2264.
I’m finding a lot of commands that used to work fine don’t work anymore…
I apologise if this is a dumb question, but, what does the ZS (stack profile) parameter actually do?
What happened to CE, AP, A1… and other commands, (I send a few initial commands in AT mode then complete the initialization using API mode…
If your old XBees are running version 1803 and the new ones are running 2264, then the old ones are series 1 and the new ones are series 2.
Series 1 and series 2 XBees aren’t compatible with each other. The series 2 models have a very different command set, and under no circumstances can models from different series communicate between each other.
So if you want to extend the existing system, you need to purchase more series 1 modules.
The big difference between series 1 and series 2 is the provision for routers, to allow for a network in which nodes may be too far apart to communicate directly with each other. (That said, you can load the Digimesh firmware on a series 1 and get some routing capabilities.)
In your application it sounds as though series 1 will do fine. I see from your video that you record RSSI values - if those are well within reasonable numbers then you shouldn’t need the extra complication of routing.
As to whether to stay with firmware version 1083, well, that’s going to be your call. There have been many good changes since then, although as far as I know you can still downgrade a new series 1 XBee to that version. Personally, I’d want to take the opportunity to upgrade the existing system to the latest firmware - if you’re being asked to extend the system, my bet would be that the customer might want new features as well. That carries the risk of exposing a problem with an older firmware version. You can check out the firmware upgrade notes on the Digi site for (brief) details on what’s changed.
Disclaimer: IAND (I Am Not Digi). Before you spend any money based on anything I’ve said, you’d be wise to check with the excellent folks at Digi Support.
Thanks for the reply, I’m now trying to get up to speed with the differences between series 1 and series2, I will stick with the series 2, (having just bought 160 of them), and see if I can run in parallel with the existing series 1 modules, with separate coordinators for each network.
I don’t need digimesh. But I can think of other applications where that would be handy.
I have trawled the digi knowledgebase site looking for some sort of migration documentation. I can’t find it?
Well, I feel like I fell for the three card trick, series 2 is a giant leap backwards…
After trying different firmware and trawling through digi’s documentation, I’ve come to the conclusion than the series 2 modules just won’t work in my application.
Simply put, I have 150 battery powered devices, that I need to communicate with.
If I read the Zigbee and ZNET 2.5 documentation correctly I can only join a maximum of 8 devices per co-ordinator, since I don’t have any routers (as they can’t be battery powered) That limits the maximum number of devices to 8… surely that’s not correct?
Also, I need to trigger a voting sequence on all devices at the same time. So broadcast is essential.
So here is the question, how is this possible with series 2? If they can only run the mesh software.
Is there any 802.15.4 point to multipoint firmware for series 2 modules.
That’s a lot of XBees to dump - if you haven’t already, my suggestion would be to contact the clever folks at Digi support and see whether they can suggest a solution. You certainly can’t run the 802.15.4 firmware on the series 2 but if anyone can come up with an answer it’s the support folks.
Here is a shot of a school class during a performance of peligro island
The RGB led’s are driven by the pwm outputs on the PIC18LF1330, so I can display any colour I like, and the accelerometer detects the orientation, changing the colours and sending voting information to the linux server, where I put it into a mysql databse, which then controls the video sequences. Worked well, after I scrapped those series 2 modules…
Regards
Ray