18 replies to this topic

[mrxer]

Want to interface the netduino to a Xbee module(using the xbee shield). I know i have to use serial ommunications, how do i do this? I assume i can't use the builtin UART as the USB interface uses it. Any help would be great!

[davidlt]

Maybe this can help:
http://www.ladyada.n...ee/arduino.html
http://www.arduino.c.../Shields/Xbee01

[GDSever]

Want to interface the netduino to a Xbee module(using the xbee shield). I know i have to use serial ommunications, how do i do this? I assume i can't use the builtin UART as the USB interface uses it. Any help would be great!

Depending on which shield you are using - I've had success with the SparkFun Xbee shield and the Grommet (codeplex) library for sending / receiving messages with the Xbee API.

[mrxer]

Depending on which shield you are using - I've had success with the SparkFun Xbee shield and the Grommet (codeplex) library for sending / receiving messages with the Xbee API.

ok...i can now send data from an XBee(with XBee Explorer Shield connect to USB on PC) to an XBEE connected to netduino.

Now how do i send data to the PC from the netduino....this is my code so far..when the code is runnig...(i can see that the DIN light flashes but he Xbee connected the PC recives nothing....

static SerialPort xbee = new SerialPort(SerialPorts.COM1, 9600, Parity.None, 8, StopBits.One);

                //Rec:(15:59:59)7E 00 11 90 00 13 B2 00 40 3C 88 3B 00 00 01 48 65 6C 6C 6F 86 7E 00 07 8B 01 00 
                //Data Parsed: 7E 00 11 90 00 13 B2 00 40 3C 88 3B 00 00 01 48 65 6C 6C 6F 86 
                //ZigBee Receive Packet
                //64 Bits Address: 0013:B200-403C:883B
                //16 Bits Network Address: 0000
                //Options: 0x01
                //Packet Acknowledged
                //Data:48 65 6C 6C 6F  Hello
                PrintBytes(new byte[] { 0x7E, 0x00, 0x11, 0x90, 0x00, 0x13, 0xA2, 0x00, 0x40, 0x3C, 0x88, 0x3B, 0x00, 0x00, 0x01, 0x48, 0x65, 0x6C, 0x6C, 0x6F, 0x86, 0x7E, 0x00, 0x07, 0x8B, 0x01, 0x00 });



        static void PrintBytes(byte[] line)
        {
            byte[] bytesToSend = line;
            xbee.Write(bytesToSend, 0, bytesToSend.Length);
        }

Ps- I will document my project so other people can learn from my mistakes.

[GDSever]

Now how do i send data to the PC from the netduino....this is my code so far..when the code is runnig...(i can see that the DIN light flashes but he Xbee connected the PC recives nothing....

I'm actually using a modified version of the Grommet Xbee classes. It's much easier to deal with the API messages when you've got a class that manages the byte translations and checksum calculations. My changes to the source will be incorporated on Codeplex as soon as I get a chance to do some more testing and send it back to the author / upload it myself. You might try looking at his implementation for some ideas.

Also, I noticed you have some bytes that are considered control characters in your byte stream, like 0x13. Are you using the "Escaped" API? Some values (0x11, 0x13, 0x7E and 0x7D) must be XORed with the value 0x20 and preceeded by the bit 0x7D in order to transmit properly. I had a similar issue as you (no communication) and found that using the Escaped version worked without problems. When calculating your checksum byte, make sure you use the un-XORed value (and omit the 0x7D byte as well).

Last, I didn't check to make sure your Checksum byte was calculated properly... I might do that if I get a little time later.

In the meantime, go check out Grommet (specifically the XBee classes and Grommet.Ext).

Best regards,

[GDSever]

After running your byte array thru my translator, I noticed that you are trying to transmit a "ZigbeeReceivePacket", which is used for receiving messages, not sending them to another Xbee. You probably want to take a look at the API documentation for "Zigbee Transmit Request" (0x10).

[Szymon]

GDSever, I've seen the Grommet project, but decided to use the XBee classes from MFToolkit (http://mftoolkit.codeplex.com/) because I also want to use the HTTP server implementation. Did you see it as well? I'm curious if you have compared them and it there is any reason to choose one over another. If there is anything missing I guess it would be better to pull the resources together and maintain single library rather than split into two. I will give Gromet another look too. Thanks, -Szymon

[GDSever]

Did you see it as well? I'm curious if you have compared them and it there is any reason to choose one over another. If there is anything missing I guess it would be better to pull the resources together and maintain single library rather than split into two. I will give Gromet another look too.

No, I am not familiar with that library, but now that you've clued me in, I will take a look. Will report back once I get a chance to compare them.

[GDSever]

I like the library - its alot more thorough (albeit more heavy) implementation of the XBee API. The method the Grommet library uses for reading in frames (use of a FrameBuilder class) does feel more elegant and is a little easier to follow for me than the code in the XBee.cs "ReceiveData" class, but your implementation seems like it should work really great. I might have to give it a try (and perhaps make a switch). It's actually very similar to the classes I wrote in VB a year or so ago...

[Szymon]

I like the library - its alot more thorough (albeit more heavy) implementation of the XBee API. The method the Grommet library uses for reading in frames (use of a FrameBuilder class) does feel more elegant and is a little easier to follow for me than the code in the XBee.cs "ReceiveData" class, but your implementation seems like it should work really great. I might have to give it a try (and perhaps make a switch). It's actually very similar to the classes I wrote in VB a year or so ago...

Just to make it clear: I'm not the author of MFToolkit - it was written a while ago by Michael Schwarz, and he recently updated it to MF 4.1. Michael is active on this forum so I hope he can join our conversation.

What I was suggesting is to take a look at both XBee libraries and maybe try to decide which one is more complete, and see if we can merge them and move forward as single code base. I will be happy to help with this effort. For now I will look at the FrameBuilder class in Grommet and see if this can be migrated to MFToolkit. What do you mean by seaing that MFToolkit implementation is "more heavy" ?

Thanks,
-Szymon

[GDSever]

Just to make it clear: I'm not the author of MFToolkit - it was written a while ago by Michael Schwarz, and he recently updated it to MF 4.1. Michael is active on this forum so I hope he can join our conversation.

Sorry for the confusion - I knew, I really meant the library you referenced.

What I was suggesting is to take a look at both XBee libraries and maybe try to decide which one is more complete, and see if we can merge them and move forward as single code base. I will be happy to help with this effort. For now I will look at the FrameBuilder class in Grommet and see if this can be migrated to MFToolkit. What do you mean by seaing that MFToolkit implementation is "more heavy" ?

Michael's is definitely complete - Grommet has significant missing areas (Like IO sampling frames, Escaped API support, and a few others), but for many people it could do a fair job if they were just sending string transmissions. What I meant by heavy was Michael's has alot more classes, alot more code, which I suspect means larger compiled programs. I haven't actually done a side-by-side comparison to see what the difference is so I am mostly guessing. I plan on taking Michael's classes for a spin this weekend. This dialog has conviced me to consider switching.

The FrameBuilder concept is a good one, but the Grommet library is missing a rather important aspect - Escaped API (It didn't take much for me to add it in). I suspect Michael's approach to read in all bytes in the receiving buffer is more efficient than the byte-by-byte read in Grommet, but it does mean alot more logic and whatnot to break the stream into packets.

[Szymon]

Yes, you are right that MF Toolkit implementation is more comprehensive. However as you pointed most people would only use the common functions most of the time. I think at minimum this includes: - initialize xbee module - read module configuration - discover other nodes in network (in order to map node id's to short address) - send and received binary data For this I think Grommet does a good job. I especially like that the API is focused on executing these higher level operations rather than exposing the entire XBee API. When I started exploring MF Toolkit it was hard to guess how I'm supposed to use it to execute these functions. IMO if we want the library simple to use it should hide the technical details of XBee protocol and instead expose easy to use functions. Another reason is the size. I plan to use Netduino Plus as a gateway passing web requests to other nodes connected via XBee. Because Netduino Plus has limited memory it is important to make the libraries as small as possible. I did a quick comparision of the PE files (not the dlls) and Grommet is about 4 times smaller then Grommet. Unfortunatelly MF doesn't trim the code that is not used by application during deploymnet so we should minimize the code ourselves. I have managed to trim the Grommet library to about 9K (the PE file again). Right now I'm reviewing the code in Grommet. One think that I liked in particular in MF toolkit was the usage of ByteReader\ByteWriter classes. This greatly streamlines the code for parsing and serializing the API Frames. Right now I'm trying to bring them to Grommet replacing calls like Utility.InsertValueIntoArray or Utility.CombineArrays. This also replaces calls to BigEndianConverter.

[GDSever]

Well, I created a new project and added in the MicroXbee and MicroIO projects - Success! Was very easy, once I figured that each project had to be switched to deploy to the USB Netduino_Netduino (not just the one containing Program.cs).

I unfortunately haven't been able to test out the IO Sample stuff because my Router API Xbee crapped out on me... Got a thread started at on the Digi support forum, but I don't know how long it will take (if at all) for someone to help me out. I can't even reload firmware at this point and may be forced to purchase some new Xbees :-\ Not good.

But thanks again for making me aware of the MF Toolkit - works great as far as I can tell!

[Szymon]

I unfortunately haven't been able to test out the IO Sample stuff because my Router API Xbee crapped out on me... Got a thread started at on the Digi support forum, but I don't know how long it will take (if at all) for someone to help me out. I can't even reload firmware at this point and may be forced to purchase some new Xbees :-\ Not good.

This happened to me as well during one of the firmware updates. Fortunatelly I found that there is a way to do factory reset on XBee.
First you need to get X-CTU to prompt you for additional action, and then short couple of pins on XBee. Read here for instructions:
http://forum.sparkfu...ad0f7115f82a106
(find replies from artcar12 and heathkit).

[GDSever]

This happened to me as well during one of the firmware updates. Fortunatelly I found that there is a way to do factory reset on XBee.
First you need to get X-CTU to prompt you for additional action, and then short couple of pins on XBee. Read here for instructions:
http://forum.sparkfu...ad0f7115f82a106
(find replies from artcar12 and heathkit).

I've executed those steps more than 50 times at this point, and with the same results. The modem will not write the new firmware - it always gives me the "lost communication with modem" message. The only change that has occured is that the sequence of numbers for ID has now changed... but that is it.

I have pretty much resigned myself to the fact that I'll be buying more Xbee modems soon. I had to pull the one I had in my embedded application so I at least had 2 to do some testing with... Hopefully one of these remaining 2 won't die on me also.

[GDSever]

OK... after much much trial and error, I finally realized the key - RESET must be wired to ground prior to the dialog box coming up, and then you break the connection to start writing the firmware. I finally have a functional Xbee again - and I've learned a valuable lesson regarding XBees and the SparkFun Xbee Explorer.

[mrxer]

I now have my xbee(connected to PC with USB,Coordinator)..WHen i send an Explicit ZIgBee command... i can read it on the RX pin on the EndDevice using a logic probe BUT my netduino detect the data. I am using the xbee shield with the netduino(EndDevice). Do i have to mofiy anything on it? Maybe the diode(i saw comments regardingthis).

[hus]

Any example how to use Grommet library for XBee API communication (send and receive data)?

[Sharktear]

Hi,

I'm searching for a library that work correctly in api mode for sending remote AT commands to a remote xbee end device. I need to set up the sleep mode of the xbee dinamically, with a sleeping period different for morning and night. Until now I used the Grommet's library already mentioned in this topic, but for this job it doesn't work... It contains a method to send remote command to an end device (SendAtRemoteCommand or similar name) but the value parameter of this methos is single byte value. I need to set up the end device with a sleeping period of 5 seconds, so I need to set SP=0x1F4 where 1F4 is equivalent to 500 (this value is multiplied by 10 from the device so I obtain 5000 ms)... the problem is that 1F4 not fit in a single byte and I need to split in a byte array... Googling I've found a method for splitting an hex value in a byte array but I'm not sure it works correctly. Then I've modified the method of the Grommet's xbee library to accept a byte array for the value parameter, but when I've tryed to send all remote at commands for a sleep period of 5 sec and 1 sec awake it doesn't work and the xbee module remain awake all the time. I've searched for code snippet similar to mine needs but without success.

Anybody has solved this problem or can help me to improve in the correct way? Is there a working way to convert an hex value like 0x1F4 directly with the micro framework?

Many thanks.