XBee Series 2

Anyone have experience with the XBee series 2? I like the higher output power (2mw vs 1mw) and lower power consumption vs the original, but am puzzled by the seemingly primitive ZigBee wireless architecture. Needing a dedicated coordinator and end-points (not to mention routers) requires much more infrastructure planning than I am interested in. The original XBee seems to support a non-nonsense adhoc configuration missing from the series 2 (which requires different firmware depending on the usage).

I have need for a solid RF telemetry solution which is usable within my house (fairly large) and adjoining property. The basic XBee looks good with its adhoc support, but I would really like the power/efficiency of the series 2. Appreciate any first-hand feedback. Thanks,

Vraz

I’m not sure if I understand your question/problem. If you would like the v1 functionality on the v2 modules, I think it is fairly simple to use a non-Zigbee firmware on the v2.

I like the XBee modules. They’re easy to use and Maxstream’s support is great. I have developed a simple mast/multi-slave protocol (w/ TDMA).

Let me know if you have any questions, or you can clarify your intentions/problems.

John

Sorry-- should have been more clear.

Is there a way to operate the Series 2 with the transparent router/end-device firmware (what DigiKey stocks) in an adhoc mode similar to the original so that a group of these devices can communicate as peers?

Put differently, I want to deploy a number of remote sensors and simple controls which communicate with a central computer. While the central computer could act as a ZigBee coordinator, because of range issues, I might actually need two nodes connected at opposite ends of the house (hard wired back to the computer) to provide solid coverage. It sounds like the ZigBee firmware only supports a single coordinator and thus this topology would not work (I would need to add dedicated router nodes).

It seems odd to require different firmware for the different ZigBee roles. Since DigiKey only sells the -004 devices, it means I need to flash at least one to coordinator myself. While I am sure that is not a huge issue, its time I would prefer not to invest in that particular area of the project (was hoping for a module I could just plug and go).

I was planning to use a simple polling protocol to collect data or send commands on a schedule driven by my central computer.

Interesting reference to using a non-ZigBee firmware on the V2. That is not a possibility I was aware of. I will dig through the Maxstream site and see if I can find any references to that.

I might be better off using V1 which looks perfect for my needs, though the lower current / higher transmit power of the V2 is what I found appealing about it.

Thanks,

Vraz

I have not used Zigbee and I’m not familiar with its ins and outs.

If you download the Maxstream XCTU software and update it, it will have all of the different firmware loads available for uploading to the modules.

If you don’t currently have any v1 modules deployed, start with the v2s.

I just looked again at the Maxstream documentation. I may be wrong. Call their tech support and they can answer all your questions. They are always a big help.

Good luck,

John

The solution was entirely the fact the PIC does a lousy job at input buffering. I created my own buffer in the PICs RAM and it has significantly increased the rate at which I can receive data. I’m well over 16 kilobits per second atm. I think the rest of the data can be obtained easily now with some tweaking. Thanks guys

to be fair, the PIC UART has no buffering. I doesn’t try so it really can’t do a “lousy” job. I’d say the blame lies elsewhere…

Beware: XBee series 2 is intended for ZigBee only. I don’t think you can run them in the simple 802.15.4 mode like the series 1 have.

Series 1 is based on Freescale’s chip; Series 2 uses Ember. The latter may have some onerous licensing issues about ZigBee. Many applications don’t need/want the ZigBee stack, just the 802.15.4 MAC API (per IEEE), or the XBee’s wireless UART configuration.