XB9B 900MHz XBee on series 3B hardware, HP firmware

Tracy Allen

I'm starting a project with the XBee 900 HP, wondering if others here are using it. I'm branching off here from RForbes thread, Help-with-buffer-building-please.

One thing I've always found difficult with Digi products is the mental confusion of sorting out what's what. The manual for the product is a case in point. (manual = XBee-PRO® 900HP/XBee-PRO® XSC RF Modules, Sept 6th 2013). The first battle is the RTFM, to X out the irrelevant material. It is a mash-up of info on two distinct hardware platforms, the S3 and S3B, and three main firmware options, "HP", "XSC", and the bootloader for the optional Freescale application processor. The HP firmware is the most recent, most capable, and should be run on the S3B hardware platform. The XSC firmware is on the way out. The Freescale add-on is interesting, but hey, this is about the Parallax brains.

The S3B/HP is a step up from the old 900MHz XBee. When you go to purchase it from the usual sources, it is called the XBP9B, as opposed to the old XBP09. The description may include mention of XBee Pro 900 HP, and the S3B hardware platform. It should not mention XSC, because that is the older (obsolete?) firmware. It may mention digimesh, but the digimesh protocol is only one of the networking options contained in the HP firmware running on the S3B hardware. There are quite a few options for network topology that can be configured, including flavors of peer-to-peer, multipoint, coordinator centered, as well as flavors of digimesh. That is another dimension to sort out when reading the manual. The digimesh options allow the entire distributed network to run at low power, all in a cyclic sleep mode. With the old XBP09 modules, the multipoint and digimesh were two distinct firmware options that had to be loaded in via XCTU. The XB9B/S3B/HP setup is all inclusive.

Rforbes

I'll be using it soon I hope.

I have a BUNCH of the Xbee Pro XSC 900 (s3b) modules installed in the field and they are awesome, but difficult at times. The new 900 HP should be a nice almost-drop-in replacement for new stuff.

Some of the features on the 900 HP are beyond me, but I'm determined to figure it out

The biggest problem I have with the XSC is the packet id buffer being only 8 deep. That caused a lot of confusion for me in a system with lots of nodes as well as lots of repeaters and repeater/end nodes. I'm hoping the 900 HP can be used a little more effectively for relaying messages to get up and around mountains and such.

Tracy Allen

My understanding is that if you already have the S3B hardware, then XCTU is able to load HP firmware to replace the XSC firmware.

(XSC= XStream Compatible. HP=????).

I'm coming at it from having used standard 2.4GHz 802.15.4XBees. Also looking for sleeping routers and longer range around the hills.

I don't get what you mean by, "The biggest problem I have with the XSC is the packet id buffer being only 8 deep." What is that?

Rforbes

My understanding is that if you already have the S3B hardware, then XCTU is able to load HP firmware to replace the XSC firmware.

Yeah, I think I read that too. That's nice, because I have several XSC's not in use. At least they won't lie around waiting on their half-life to arrive. I wonder what they'd decay into at that point? hot dogs perhaps?

I think the HP is definitely not Xstream compatible, but don't really know. I don't have a lot of experience with xbees in general. In fact, I've only ever used the XSC.

I don't get what you mean by, "The biggest problem I have with the XSC is the packet id buffer being only 8 deep." What is that?

When the XSC transmits, it creates an rf initializer (when required) and the rf data packet. Part of that rf data packet includes a packet id (see page 101 of 90002173_G.pdg which I think is the latest HP manual and includes all the XSC junk in an appendix)

Any XSC module that is set up to be an end-node or a repeater/end node (acting as both) looks incoming data and packet id according to the following (page 130 of same pdf)

Algorithm details
• Packet ID (PID) is composed of transmitting module MY address and packet serial number.
• Incoming packets with a PID already found in the PID buffer will be ignored.
• Each module maintains a PID buffer 8 deep of previously received packets (managed as
FIFO).

After several hours on the phone with digi tech support, I was told that since it's only 8 deep, it can/will forward "repeated" messages out the uart that have already been sent out it if too many messages are being repeated.

I guess it makes sense, and I know there is a mathematical model that could define the conditions, but I don't understand it well enough to create that model.

Suffice to say that if you have a large number of repeaters or repeater/end-nodes, it creates a lot of repeated packets. I can't avoid setting them up like that because of the woods, mountains, buildings and occasional mutated squirrel affecting the rf waves.

So the end result is that any given module set up as a repeater or repeater/end-node receives "repeated" messages from other repeaters... and since the FIFO buffer is only 8 deep, it doesn't take long for the module to not see that it's already received that particular repeated message. Since teh record of it is gone from the FIFO once 8 more messages are received, it sends it out its serial port. (providing the packet is addressed to it, of course.)

The end result is that you get multiple copies of the exact same message coming out the serial port. So you have to code in a way to accept the first packet, but ignore subsequent copies of it.

It wasn't very difficult to create a method to handle it (just attach your own packet id as part of your rf data), but even the digi guy was stumped when I told him what I was seeing coming out the serial port. I guess not many people have had to use these things the way I've set them up.

One good thing about the XSC is that it can be extremely reliable with a setup like this. It provides multiple pathway and hops, retries and acknowledgements and all kinds of cool stuff to get the data through.

Tracy Allen

Hot dogs? Half life, decay into, say what? Field tools decay into nest sites for ants, barnacles or geckos, depending on location.

Okay, I see that text on p130 in the section on XSC. I'd X'd that out to avoid brain cell overload and confusion with the HP firmware operating modes. XSC does seem similar to the repeater/directed broadcast mode of the HP firmware. They recommend not using that due to the heavy load it places on the network, and maybe it has the same effect as the one you are describing about packet overflow. The Digimesh protocol on the other hand uses a routing table and acknowledgements and is designed to minimize the spurious network traffic. Can we read between the lines? There must be a lot left unsaid in the manual in terms of both features and pitfalls.

The HP firmware does not allow short 16 bit MY addresses (ATMY returns an error). All addressing is done with 64 bit MAC address. That is true of their 2.4GHz Digimesh firmware too, which runs on the series 1 hardware.

Chris Savage

Unfortunately the Digi Examples site has S1 and S2 examples, but nothing for the S3, though they do cover the S6 (Wi-Fi).

http://examples.digi.com/category/get-started/

Tracy Allen

Also, posts on Digi forums are sparse. Typically an ill-defined problem receives no reply, or a vague reply, or a request for clarification. Or someone else pipes up with the same issue, "did you get it working?", and that's the end of it. One could get pretty discouraged browsing there.

Digi does provide a lot of guidance on their web site, lots to sort thru. Here is a nice one, Quick_Guide_to_DigiMesh_Setup. That does not deal with series S3B either, but it does touch on differences between Zigbee and Digimesh, and the difference between Digimesh as implemented at different frequencies. A lot of the difference has to do with channel selection. At 2.4GHz you select a channel explicitly using the CH command. At 900 or at 868 MHz, there is instead a CM, channel mask, to confirm a set of allowable channels. In operation the XBee hops between channels as necessary. That is taken to another level in the XB900pro HP. HP I believe stands for hopping (not high power!). The hopping algorithm is implemented in a packet preamble, so that XBees that do not have matching HP parameters waste minimal energy listening to traffic on intersecting networks.

Tracy Allen

My understanding is that if you already have the S3B hardware, then XCTU is able to load HP firmware to replace the XSC firmware.

Yeah, I think I read that too. That's nice, because I have several XSC's not in use.

I have to qualify that. Today we tried to load the HP firmware into some S3B modules that had come with the XSC firmware. Wouldn't take it. Miserable error message. Well, there it was in black and white in a table on page 5 of the manual: In order to run either XSC or HP firmware, the S3B for the most part has to be above rev H. The older ones we had were rev A. The S3B is printed in bold type on top of the module, but you can find the revision number in fine print on the bottom.

Chris Savage

Tracy, were you able to recover them (restore the original firmware)?

bsnut

Chris Savage wrote: »

Unfortunately the Digi Examples site has S1 and S2 examples, but nothing for the S3, though they do cover the S6 (Wi-Fi).

http://examples.digi.com/category/get-started/

Thanks for posting this interesting link. There is some helpful information on this site that I can use.

Tracy Allen

Chris,
I'm not sure about the state of the firmware after the attempt to change from XSC to HP. Good question. I think we didn't check or try to restore it.

giejo

Hai everyone,
Did anybody knows any programs links for the module "digi xbee s3b" series in spi protocol. i am still researching on this but failed to get responses regarding the topic. Could anyone help me to figure the issue out.?