802.15.4 interoperability (XBee V1 to ???)

Wireless & IoT
1

Anyone have experience with 802.15.4 interoperability between devices? I currently use XBee Series 1 for some custom home automation applications (feeding the cats, watering the garden, etc) and am generally pleased with the performance. However, am concerned about being tied to a single vendor / module as the basic wireless solution is something I would like to use for some number of years.

While the basic XBee series 1 uses 802.15.4 at its core, its unclear to me whether it would actually interoperate with any other manufactures modules (say the Jennic or Microchip). Not sure if the Digi transport layer on top of 802.15.4 essentially makes the modules proprietary or not. I am particularly interested in the Microchip MRF24J40 modules as cost-effective alternatives to the XBee where the range limitations of the chip-antenna are acceptable.

Thanks in advance!

2

With series 1 (or maybe series 2), in 802.15.4 firmware config, with the Digi MAC mode disabled, it should interoperate with any other 802.15.4 compliant module that is likewise config’d in full '15.4 mode compliance. of course, 2.4GHz version of 802.15.4.

You’ll need to disable the Digi MAC mode where two or so bytes are placed in the beginning of each payload. Once off, the full payload per '15.4 is available. You will probably need to use the Digi API over the serial port to address packets to a given destination MAC address, and vice versa.

Series 2 with ZigBee will be another story.

3

You’ll need to disable the Digi MAC mode where two or so bytes are placed in the beginning of each payload. Once off, the full payload per '15.4 is available.

So I assume this means ATMM1 or 2? I guess then the question is whether I can still use TX16 (with broadcast address $ffff) or if TX64 is required. The Digi docs seem pretty light on details in this area.
4

Vraz:

You’ll need to disable the Digi MAC mode where two or so bytes are placed in the beginning of each payload. Once off, the full payload per '15.4 is available.

So I assume this means ATMM1 or 2? I guess then the question is whether I can still use TX16 (with broadcast address $ffff) or if TX64 is required. The Digi docs seem pretty light on details in this area.
yes, MM=1 with ACKs is prudent.

Addresses would be 64 bit (MAC) since there’s no network layer (ZigBee or Digi’s mesh).

I use peer-to-peer most often, where I set in all nodes

MM=1

A1 bit 2 = 0 (auto-associate disable)

CE=0 (end node true)

set channel and PAN ID all the same.

then to send a message, set DH:DL to the MAC address of the addressee and send packets. Or set DH:DL to FFFF to do a broadcast to all in range. For some reason, the broadcast address FFFF in 16 bits is used and the other bytes in the 64 bit address are don’t care, for broadcast.

Need to use the API mode to read incoming packets to get data and MAC address of source node. And get RSSI for that packet. Around the Internet, there are various implementations of the Digi API code, with packets wrapped in a simple UART data stream with 7E as the leading byte. I use API=1 so I can send binary data without having to do the messy “escape” sequences.

5

I currently use API mode 2 as my payload is pure binary and I didn’t think it was worth encoding myself to avoid reserved characters. I assume you must be escaping 0x11, 0x13, etc in some way if you are using API 1. Looks like A1 auto-assoc, CE=0 and identical channel/PAN-ids are all default on the series 1. However, it certainly makes sense to force those values in case later firmware changes the defaults. I currently send all packets broadcast and let my own protocol figure out who they are intended for.

Really appreciate the detailed reply. Am going to get one of the Microchip modules and see if I can get it talking to the XBee. That would put me in good shape for the long term.

6

Would you please report back on how you do with that? I’m following this thread with interest (and appreciate the detailed replies as well).

7

Vraz:
I currently use API mode 2

Am going to get one of the Microchip modules and see if I can get it talking to the XBee. That would put me in good shape for the long term.

Trying Microchip ↔ XBee just for the heck of it? Why not just use one or the other? Digi/XBee is unlikely to be discontinued any time soon.

I use the API mode that doesn’t use byte stuffing/escape- can’t recall if that is mode 1 or 2.

Re Microchip… Quote from their web page. It’s very true, no matter the vendor.

Alternative Protocols

Due to the fact that the ZigBee protocol has grown too large and complex for many applications, a large percentage of the market for IEEE 802.15.4 wireless Personal Area Networking is likely to use alternative, proprietary protocols, such as the MiWi protocol. Additionally, ZigBee protocol certification is costly and cumbersome for small- and medium-size companies. Microchip’s MiWi protocol provides a simpler, lower-cost solution for customers who do not need interoperability but still want to use robust IEEE 802.15.4 radios.

IEEE 802.15.4 is public, open. ZigBee is proprietary to, licensed by that alliance. Other popular network layer protocols for 802.15.4 include ISA 100.11a and 6LoWPAN, however these are complex and specialized. Also, 802.15.5 (new) is an open standard for meshing with 802.15.4.

Microchip is a chip vendor, not an OEM module vendor as is Digi who uses Freescale (series 1) and Ember (Series 2). The OEM modules (Digi, Jennic, others, are type certified (legal) for use in various countries), meaning the OEM need not bear this cost and delay. The chip vendors all have eval/dev boards, but these aren’t viable as OEM modules.

Looks like Microchip’s MiWi P2P is the same as XBee when configured for P2P using AT setup commands (one time).

My understanding is that 80% or more of all vendor’s 802.15.4 modules sold are without ZigBee. The ZigBee gang was too late to capture the beginning of the smart-grid movement and they were too late for Home Automation (Z-Wave got that). But finally, Utility industry companies are trying to force their meter vendors to comply with standards instead of being proprietary as they have been to date, in wireless, mostly 900MHz.

Beware though, the dependencies; example: Digi XBee series 1 is not ZigBee by intent whereas Series 2, being based on Ember’s chip, must load up with ZigBee, as I understand, by contract agreement.

Anyone know of a type certified OEM module based on Microchip’s 1mW or 100mW chips? These are relatively new.

8

Microchip is a chip vendor, not an OEM module vendor as is Digi who uses Freescale (series 1) and Ember (Series 2). The OEM modules (Digi, Jennic, others, are type certified (legal) for use in various countries), meaning the OEM need not bear this cost and delay. The chip vendors all have eval/dev boards, but these aren’t viable as OEM modules.

While its true Microchip is a chip vendor, they also provide the MRF24J40 in certified OEM-style module format. Here is the link to the two versions (low power and high power). According to the docs, they are certified for US, CA and EU. They are significantly cheaper than XBee (~$10 for low-power, ~$20 for high-power) though are only available with a PCB antenna which likely limits range. (And in addition, they make some development boards with these modules.)

http://ww1.microchip.com/downloads/en/D … 70329b.pdf

http://ww1.microchip.com/downloads/en/D … 70599B.pdf

Trying Microchip ↔ XBee just for the heck of it? Why not just use one or the other? Digi/XBee is unlikely to be discontinued any time soon.

Define soon. ;-) At this point I have a well tested and extremely reliable design that allows me to handle custom low-voltage home automation applications with relative ease. Thanks to XBee, the modules can be located where I want and they just work and two-way communication provides feedback back to my automation server. I simply want to avoid being unable to get parts to continue the system in the future.

One thing about the Microchip module solution-- its purely the radio chip, analog components, etc. You communicate via a tortured looking 12-bit SPI format. There is no host processor like the XBee. Since my designs have their own processor (ATMEGA88), its not an issue (and I think this is fairly common), but it does increase implementation complexity (though Microchip provides code for those using PIC). Also, the errata is somewhat ugly. The SPI interface cannot be shared (oops), the security module can corrupt data, etc.

9

stevech:
… whereas Series 2, being based on Ember’s chip, must load up with ZigBee …

or ZNET 2.5

10

Vraz:
…

One thing about the Microchip module solution-- its purely the radio chip, analog components, etc. You communicate via a tortured looking 12-bit SPI format. There is no host processor like the XBee. Since my designs have their own processor (ATMEGA88), its not an issue (and I think this is fairly common), but it does increase implementation complexity (though Microchip provides code for those using PIC). Also, the errata is somewhat ugly. The SPI interface cannot be shared (oops), the security module can corrupt data, etc.

Interesting... I didn't know about the Microchip OEM modules. Will read. Lack of co-processor with API as in XBee should mean the Microchip modules are much, much less expensive - but you are thus burdened with developing all the layer 2.5 code (that's in the XBee S1).

As to Microchip’s errata - XBee Series 1 uses Freescale’s radio and Digi’s co-processor that have matured for several years. I don’t encounter module design bugs in my use of XBees.

Microchip is missing certification in Asia - Japan is really difficult, as is France, and neither of these conform to the EU specs. Japan/France limit power to 10mW and Japan’s emissions mask is so strict that truly, most modules cannot make spec with more than a couple of mW. Japan’s is anally over-spec’d.

Also need OEM modules to have U.FL or SMA connector for OEM to choose proper type of antenna.

Yes, the nice thing about 802.15.4 is the standard for low power RF data comms. Nordic remains proprietary.

11

Vraz:
One thing about the Microchip module solution-- its purely the radio chip, analog components, etc. You communicate via a tortured looking 12-bit SPI format. There is no host processor like the XBee. Since my designs have their own processor (ATMEGA88), its not an issue (and I think this is fairly common), but it does increase implementation complexity (though Microchip provides code for those using PIC). Also, the errata is somewhat ugly. The SPI interface cannot be shared (oops), the security module can corrupt data, etc.

The datasheet is ugly as sin yes, you need to have a copy of the 802.15.4 spec with you as well, (2003 or 2006, you only need to use the mac header definitions) The SPI interface is actually 16bit, or 24 bit, but some clever person at microchip thought it was better to describe it as a 12 bit or a 15 bit with some don’t care bits. Much like the rest of the datasheet, it’s much more obtuse than it should be. When you get your head around it, it’s really pretty straightforward.

The spi interface can absolutely be shared, it has a chip select pin.

Yes, it’s a radio, you need a host processor, but I find that vastly preferable. with xbee’s, I’m limited to what they thought would be useful, and while that might sometimes be enough, and you can leave out the host processor altogether, I just don’t feel it’s worth it. I find SPI to be vastly preferable to UART anyway. More chips have SPI modules, SPI is much much much faster, SPI doesn’t have baud rate timing issues.

Yes, it doesn’t ship as a wireless serial cable out of the box. If that’s what you want, xbee’s on the end of ftdi cables are a turn key solution.

The mrf24j40’s are more compact, cheaper, and are on standard breadboard pitch, rather than 2mm, like xbee’s. In plain 802.15.4 mode, they both send/receive to each other happily.

12

I’ve used XBee series 1 to interoperate in '15.4 mode (no ZigBee) with TI’s '15.4. And Daintree’s sniffer.

Probably will work with any '15.4 module.

Microchip’s '15.4 stuff is like Limburger cheese.

13

hello !!

this discussion was verry interesting with a lot of new information !!!

But i want to know… two Miwi and Zigbee devices can they be interoperable and communicate with each other ? since they are two 802.15.4 protocols.

else, can a MRF24J40 module switch from miwi to zigbee protocol during the communication to receive data from an xbee ???

thank you for your reply…

14

ZigBee not a synonym for 802.15.4; nor is Ethernet a synonym for 802.3.

ZigBee is one of several network protocols used with 802.15.4.

15

Yes since there is the protocol upper layer.

So, please tell me: interoperability between different 802.15.4 protocols (zigbee and miwi in this case) is impossible ?

and a second question please: i read that there is a profile ID that must be attributed by Zigbee alliance so that the Zigbee module is interoperable with other zigbee devices. is it the same case for XBee ? or desabling the maxstream mode is enough?

i’m looking forward your answers

thanks !!!

16

if you don’t use ZigBee, and use XBee series 1, and disable Digi’s MAC mode, then you have a plain IEEE 802.15.4 modem. You set the channel, PAN ID, encryption off (or on), and pan coordinator mode off, must associate off. Now via Digi’s binary API, you send/receive 802.15.4 data payloads, up to about 100 bytes. Address by the 64 bit address of the destination radio, or FFFF for the short-address broadcast.

That’s simplicity. No PAN coordinator and all that rot.

Any node can transmit to any other node given its 64 bit address. YOU can have nodes do a periodic broadcast to advertise they exist, for the pleasure of others in range. YOU can define message content. YOU can have node # 5 relay to node #9, fixed routing.

And so on.