Xbee Adoption

Archive
#1

Why does it seem Xbee is not that popular, at least not for netmf/gadgeteer? I mean, xbee.codeplex.com looks like a solid library, but not tracking many downloads or activity. Other libs are out there too, similar status. Flat.

Is Xbee worth betting the farm on?

Is it better to use Series 1 or Series 2? (Multi-point vs Mesh I guess?)

Is there a driver for CerbuinoBee to use Xbee without a GT socket? (it looks that way from the Gbee code sample)

The thing is, IoT is all about connectivity, and it seems Xbee is ideal. low cost, low power, and capable of mesh or basic client/server. Anyway, I’m thinking about using CerbuinoBee + Xbee for my next project. But dang, I’m not super confident in the community activity. Not sure why this isn’t huge… ?

#2

Dear andre.m

Could you show us a case or example for using synapse module with NETMF?
For example, how to config the synapse, how connect to NETMF board…
Thanks.

#3

I can give some history on XBee as it relates to netmf/gadgeteer in this forum. Initially, everybody wrote their own wrapper for the XBee serial commands. There was some good work out there to prevent reinventing the proverbial wheel (I helped on the xbee.codeplex.com project, which was itself refactored from an existing OS library), but some found it too “complicated” and opted for re-rolling their own code. No one solution has emerged as “the one” to use.

Generally, most people here seem to just dabble with XBee by setting up a simple point to point with two nodes. The number of folks here who really dive in and set up larger mesh networks or use the more advanced features of the platform is pretty small. From a hobbyist perspective it is expensive to do so, and other cheaper options do exist.

#4

I have heard that the XBee firmware until recently has been ugly, inconsistent and overly complex.

BUT it should be great now!

Actually I think the time is just right to work on the driver for the XBee module.

Crappy driver means no adoption.

#5

Please explain. I haven’t kept up on recent XBee developments.

#6

I hope this is viewed as a good/natural thing. The curve always works out this way. mostly dabblers, fewer experts. Still not sure why Xbee isn’t “huge” even for the dabbling point to point folks. I mean, even simple solutions benefit from one device talking to another at the very least. WIFI (RS21) is waaaaay too expensive and overkill for simple messaging. That is why I thought Xbee would be dominating by now. In my architecture (being planned), I’m using wifi for a bridge between TCP/IP and Xbee. If an Xbee-only client needs something from the internet, it will call to a wifi + xbee enabled node. A bunch of minions that talk to the mother ship.

So when you say “expensive”, it is expensive to do what? Write an SDK to simplify advanced features?

And when you say there are “cheaper options” out there, what do you refer to? Nordic? I’m not seeing where its much cheaper, and even so, it’s even worse in regards to .NET library/developer support and libraries, facades, adoption, etc, no?

It sounds like the buzz around Xbee (no pun intended) has kinda subsided. Or any low power low cost RF for that matter. I’m up for participating on the project where I can. Just trying to get an idea of whether this is going to be widely adopted or flop to a halt long term.

Questions for the community about why adoption is slow might be:

[ol]Because Xbee firmware is too hard/messy (to njbuch’s point)
Because Xbee libraries are too hard? (Drivers/SDK not easy enough? Samples not easy or cover enough scenarios?)
Because the .NET libraries are not heavily supported/backed (went stagnant)?
Because you just need point to point (Mesh is a paradigm shift?)
Because Xbee is too expensive for simple point to point? (what is cheaper?)
Because you’re still building silo’d non-IoT connected projects?
Because there is no clear, easy, or standardized way to SECURE the messaging in RF projects?[/ol]

My hunch is that the top issues are #'s 2 and 6. And I bet fixing 2 would improve 6, just based on the fact that the easier something is to adopt, the more likely it is to in fact be adopted. But I dunno. I’d love to hear from the community.

#7

BTW, I’m just now discovering the conversations about Nordic
https://www.ghielectronics.com/community/forum/topic?id=6285&page=1

And the fact that there is a netmf/Gadgeteer library here:

All of this appears to have been developed about the same time as Gbee, and by the same author! (Gralin). So, which one beats out in favor? :slight_smile:

And I do see the chip itself is cheap (like $3-4 range) however, to make it USEFUL on the Gadgeter or even Netduino requires more than just the chip, so you’re back up to near Xbee cost anyway (for a module, etc)

That said, the downloads are WAY higher (in comparison to .NET Xbee libraries combined).

So, not to fork my own thread, but WTF? Big talk of a Nordic Gadgeteer module also seems to have died. Nordic adoption is also a valid question and topic.

Bottom Line:
I am looking for the best low-cost, easy to use RF (without massive software plumbing or hardware rocket science) to plug in and get going. And by best, it includes long term community interest. I’m trying to get an idea of where the trends are or might head.

#8

Depending on what your definition of “low-cost” is - https://www.ghielectronics.com/community/creations/entry/12

This is about as “easy to use RF to plug in and get going” as you are going to get.

#9

Let me just say that I appreciate your systematic effort, and encourage you to go ahead and grab the horns of some of the cool 900HP modules.

Justins RFPipe is great, but if you need 45 km line of sight range, you are forced to dive into http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/point-multipoint-rfmodules/xbee-pro-900hp

You observations are spot on, and you are on the beginning of a wave of cool wireless communication. Gadgeteer deserves this.

But it is a very complex field. Cool guys promised a mesh enabled driver for Justins RFPipe, but it is just not as simple as that, and requires a careful design and lots of programming.

I am crossing my fingers that the cellular drivers, and the wireless drivers will mature significantly in the next period - without that… I think we will loose some sponsors…?

#10

I know this wont be everyone’s case, but I’m ok soldering up my own module and connectors using something like this
http://www.mdfly.com/index.php?main_page=product_info&cPath=8_52&products_id=81

As seen here:
https://www.ghielectronics.com/community/forum/topic?id=5460&page=10#msg67851

Just not quite this raw :slight_smile: (too much work)

It’s the netmf/gadgeteer wiring / pinout, and the drivers (GT module) that become the stumbling block for those that just don’t do that low level of work.

#11

I’ve been testing Xbee out here with a home automation system and once I get it stable I will use this in a commercial system for an oil well monitoring solution.

I have 2 nodes that are running on Atmel AVR devices and there is a Cobra 2 board receiving their data. I am also looking to add 2 Cerbuino modules to it once they arrive.

I am using the MFTOOLS XBEE driver and it is stable for quite a while and then there is the dreaded BUFFER OVRFLW message on the screen. I though it was my application code but that is fine and I traced it to the receive loop in the XBEE driver.

It seems to get stuck in a loop and the serial buffer overflows. When checking the byte count returned, it shows 16384 in the buffer and the processing loop keeps receiving the same data over and over. I am working on this now to try and fix it as otherwise it works well and I can either receive telemetry data from the AVR or I can configure a XBEE module to be standalone and send me analog and digital data periodically.

What I really like is the mesh capability. I live in an apartment with solid reinforced concrete walls and radio is very poor in here. WiFi can just about reach my bedroom. With the XBEE modules, I get a similar range but if I put in a repeated in the middle, bingo, the other node appears! :slight_smile: