Main Site Documentation

Xbee module software


#1

Got my Xbee modules today and am looking for some driver code. Change set 14263 (dated 12/20) on codeplex has the Xbee module hardware files, but no software. Saw a note about GHIElectronics.NETMF.NET.dll version 4.1.8.0 in the comments, so I’m guessing there will be a SDK release soon. When will it be available? I can hack together something in the meantime, but would rather drag and drop this one into the designer! Same goes for the music module.

Also, I noticed the new Wifi driver is up! Do I hear whispers of a streaming internet radio project?

Chompin’ at the bit,

The Wireless Wizard


#2

New SDK will be up in few days to add all new module drivers. For now, this a serial port do just use the USB-serial module drivers.


#3

I ordered the XBee module this morning. I hadn’t really thought much about the driver assuming it would just be accessed using SerialPort. Is there going to be more to it? Will there actually be a “real” XBee driver that exposes everything through properties, etc. w/o the need for one of the other open libs out there? That would be sweet!


#4

Speaking of that, wr are still waiting to see how will the community contribute to “open source”. You all asked for it and now it is all open. I yet to see a contribution from the community :slight_smile:


#5

I think XBee module bringsup a lot of question marks of what to support in the driver. What if a user used the wifi or the bluetooth that has the XBee form factor?


#6

I think it’s still way too early to be expecting much. Personally, most of my contributions so far have been in making sure Hydra gets stable first and just getting comfortable with Gadgeteer. Then I’ll move onto helping extend where I can. I also have some ideas for modules I want to create after the contest is over. I’ll start another thread about questions I have there…

I agree and was just thinking about this very thing… XBee module by itself is a very basic thing and maybe should be just a very basic “base” module that has a Module class that itself is just a base class that handles the basic communications to the pins. Then you could have GHI or user created classes that use that base class, ie.

XBeeBasic : XBeeModule
XBeeApi : XBeeModule
Zigbee : XBeeModule
BTXbee : XBeeModule
WifiXbee : XBeeModule

I think it’s unreasonable to expect GHI to provide all this functionality for the price XBee modules sell for and this is a perfect place for the community to step in and take over. There’s already plenty of open source code out there for XBee we would just need to make it Gadgeteer friendly. Most of my projects are using XBee so definitely count me in.


#7

Definitely count me in on some driver development. I agree that it would be perfect opportunity for a development project. I think we should start by agreeing on an interface definition. Some of the xbee form factor modules (roving networks wifi, for example) have a completely different command structure, so using an interface gives us more flexibility implementing the abstract and concrete classes. In some cases, like for the basic Xbee stuff, the code is already written (and on codeplex), so just needs to be tweaked and wrapped. For most everything else we’ll be starting from scratch, unless somebody has a secret library they haven’t made available yet. I’ll have some time over the holiday weekend to start on some design docs :think:


#8

ransom, I think maybe you’re over thinking this thing… For maximum flexibility, I think the (base class) interface is nothing more than the pins available through the Gadgeteer socket and maybe the SerialPort properties. I assume that only the usual UART pins were exposed. With that then all of the other XBee implementations can be defined totally customized to it’s purpose.


#9

Not yet! I think we are essentially saying the same thing.

There are also several analog pins for hooking stuff directly to the Xbee.


#10

I see those on the edge but I assume they aren’t available directly through the socket and therefore are really irrelevant as far as the driver goes. They would be controlled through XBee API commands. Correct?


#11

Correct


#12

[quote]They would be controlled through XBee API commands. Correct?
[/quote]

Correct, but you can execute these commands using fez. Basically they are serial commands as well :slight_smile:


#13

@ ianlee74 - I took another look at the gadgeteer core code and think I know where our confusion about interfaces comes from. That project contains a folder called Interfaces, which are hardware related classes. I was referring to using a software interface to define our basic properties and functions for any hardware that is Xbee pinout compatible.

Stay tuned…


#14

I think we were talking the same thing but I’m interested to see what you come up with. I’ve only ever dealt with the “normal” Xbees and aren’t really familiar with what the other versions offer. Regardless, I’m struggling to find time to finish up my piezo project so I’m not going to spend any time on any other projects until that one is done in a couple weeks.


#15

BLUETOOTH AND XBEE MODULES (CALLING FOR COMMUNITY CONTRIBUTORS)
http://www.tinyclr.com/forum/21/5547/


#16

Nice! More “official” motivation to get this ball rollin’.