Members willing to contribute, to test or to suggest for XBee module driver can discuss that over here
A previous discussion about XBee module that you might make use of:
[url]http://www.tinyclr.com/forum/21/5288/#/1/[/url]
My first question is: what should we understand by the term XBee. Should the module allow to use any Digi XBee product or just the ones that use ZigBee protocol?
Here is a complete list of XBee products:
[url]http://www.digi.com/pdf/chart_xbee_rf_features.pdf[/url]
I have highlited ones that I’m familiar with and I possess.
I think it’s up to us to build drivers for anything that will plug into the XBee module 
So, the challenge is to come up with a design that can handle all the possibilities. The advice from Microsoft regarding the design of the Bluetooth modules probably applies equally to the design of this module.
I have some of the 802.15.4 Series 1 modules and I plan to get a couple of the XBee ZB Pro modules in the next few months.
The gadgeteer core already has a serial interface (the code kind of interface) we can use. That’s the only common thing I can think of for “anything that fits in an Xbee socket”. From there we can layer on base classes as needed for each group of component command sets (AT, API, etc).
A good example of this already exists in the mftoolkit at codeplex. If you haven’t already, I suggest getting your head around his design. It’s quite involved. I contacted Michael Schwarz (toolkit author) via email, and he’s game for helping out, if we do decide to use some or all of his stuff. I think he may be a member here, but am not sure what his username is.
@ ransomhall: I have used the xbee part of mftoolkit a when i started playing with xbee and it does work indeed. Also it uses API so it’s a good starting point. If Michael Schwarz would like to pitch in that would be great.
I have one concern regarding XBee modules and Gadgeteer. Using XBee ZB modules (ZigBee) requires to have a little knowledge about ZigBee protocol and the modules architecture. You need to understand the difference between end device, router, coordinator, how to flash the module with the correct firmware and how to differe one XBee from another. This is acceptable by expirienced programmer but i think might be problematic for beginner gadgeteer developer. If however this module is targeted to developers that have expirience with XBee and know anything about ZigBee then this doesn’t matter and we just have to give them a good API do deal with.
It definitely would be great to have Michael help out with this. I used his toolkit on a project several years ago before there was SerialPort and it worked great. He is certainly an expert on the topic. However, I tried to revive that project several months ago and his whole toolkit has apparently been re-written and my project would not work and I could no longer figure out how his library works… It is not at all intuitive about how to use it. I think the public API around his code could probably be greatly improved to be more intuitive and less cryptic. Also, lots of in-line XML documentation is a must.
@ Gralin - Sounds like you just volunteered to write up some “Before You Start” documentation aimed at a new Xbee/Gadgeteer user
Kidding aside, it IS difficult to make any code like this dead simple to use, even with decent documentation. I don’t think we would be too pretentious coming up with a list of skill prerequisites, as long as we provide some pointers on how to get those skills.
BTW - Adafruit is now selling an iron on Xbee skill badge, with stickers and online versions soon to follow. Would be fun to award these to new users who successfully tackle those prerequisites.
@ ransomhall: nice try 
What i hate the most about programming is that sometimes you have to write a peace of documentation I love to read well written documents and suck in writting my own
I like ZigBee, don’t get me wrong, but i somehow don’t see it in any simple project (as many net mf are). If you want to truly use the power of this technology you need have a project that uses at least a few modules and none is able to send data directly to all other. But when you have a project like that it is possible that you will write your own solution. All others that will only want to send data from sensors in a star topology will only waste their money on expensive XBee modules and only use 5% of their power. XBee even come in a SOC version so you can write your application inside the module which makes FEZ + XBee very expensive solution.
Ok enough complaining. Count me in if you realy want to make the driver. My question is where can we store the code. Maybe we could copy the existing code into a new Codeplex project and then GHI will copy it back to Gadgeteer repo?
Codeplex uses either TFS or Mercurial. I would vote for Mercurial, as it is OSS. [url]http://mercurial.selenic.com/about/[/url]
Mercurial or Git. Since there is no Git on Codeplex i also vote for Mercurial.
What do you guys think about Michael Schwarz approach to use compilation symbols so that the code can be compiled for both net mf and standard .net. He has two projects, one standard console app and other a net mf project that only references files from the first project and compiles them for net mf. In my opinion:
Advantages:
[ulist]Unit tests
One library, multiple platforms
Debugging possible using only PC with multiple XBee connected[/ulist]
Disadvantages:
[ulist]Takes more time than only writting code for net mf (but maybe the fact that the code can be debuged on pc makes up for it)
The code gets messy with all that conditional markup that fits more to ANSI C than C#[/ulist]
From a design perspective, it’s a really nice piece of work. I’m with Ian on thinking we may not need this level of complexity. It may be why we don’t see this code more in use - less experienced developers have trouble getting their heads around it and quickly move on.
On your pros/cons - I’m not sure if a multi platform single library is a good thing. Otherwise, I really like the idea of being able to write unit tests and debug without deploying to a device. These advantages make it much easier to quickly find and fix bugs. I"m not sure if taking more time is a bad thing. Since we’re all volunteers, they’re won’t be any hard deadlines. Taking time to really “do it right” is great, but has lead to some other OSS projects I’ve followed never making it out of alpha.
Shall I create a CodePlex project? Name suggestions? Besides @ ianlee74 and @ gralin, anybody else want in at this point? @ architect? There were a few that said “in a couple weeks”, so I might as well set you up now. I’ll need your codeplex user names.
Also, I have a SharePoint (Office365) site that we can use to keep track of the non-code aspects of the project. Who’s working on what, private discussion threads, milestones, etc… They recently added the ability to authenticate with a Windows Live ID, and I’ve been looking for a reason to try that out.
[quote]My question is where can we store the code. Maybe we could copy the existing code into a new Codeplex project and then GHI will copy it back to Gadgeteer repo?
[/quote]
This is a good question. But I am not sure what is the optimal solution. But your idea of using codeplex sounds good to me.
I think the possibility of debugging the library without deploying to device may speed things up a bit. GHI could think about creating a simple adapter for XBee to allow users to connect them to PC (only add FTDI or Prolific chip to the existing gadgeteer module board for UART to RS232 conversion). Users will have to flash their XBee an the easiest way to do this is by connecting to PC (wireless update is possible but requires some expirience).
@ ransomhall: My codeplex login is gralinPL. Count me in.
This library won’t be too hard. Others had also unified the library for different XBee modules so we have no other choice but to follow this road. Here is a list of projects (besids mftoolkit) that we can take inspiration from:
Java: [url]GitHub - andrewrapp/xbee-api: Java library for communicating with XBee radios
C: [url]GitHub - andrewrapp/xbee-arduino: Arduino library for communicating with XBee radios in API mode
Python: [url]GitHub - niolabs/python-xbee: Python tools for working with XBee radios
@ Joe - Codeplex is without a doubt THE place for .NET related OSS projects. The only thing I’m a little hesitant about is the lack of fine grained control (aka admin stuff) for source control and the fact that the project is very public from the start.
@ Gralin - on the USB Xbee adapter for direct to PC use - there are plenty of these on the market already. I personally prefer the breakout Adafruit has [url]http://www.adafruit.com/products/126[/url], used with a FTDI cable or friend. It’s a fun little kit to make, and is breadboard friendly.
For my own work, I use Codesion.com (remote SVN repo). It’s got a place for non-code related documents and has Bugzilla tied directly into the source repository for assigning features and bugs to project developers. I could beef up my account to 5 users while we get this off the ground, and then once we’re happy with a beta version, move it to codeplex. It would be about $20/month, which I’m happy to subsidize for a few (<6) months. This gives us a private place to work through the first round of development and more flexibility with source control details.
Last time I added a Codeplex project I believe it said you have 30 or 45 days before you have to make it public.
As far as using code compile to make this a do-all XBee library, I don’t think we should. MFToolkit already serves that purpose. I think all we should build is a Gadgeteer driver. If we come up with something better than all the other libs out there in the process then we should at that time create a new project and base the Gadgeteer module driver on it. But, I don’t think that should be our goal.
@ ianlee74 - 30 days private. I’m with you on starting by doing a Gadgeteer driver. The big question - is it just a wrapper over an existing library like the mftoolkit, or is it from scratch with liberal borrowing from the same? My vote would be for the latter option.