Communicating with XBee
#1
Posted 25 November 2010 - 01:28 PM
tony
#2
Posted 25 November 2010 - 04:57 PM
#3
Posted 25 November 2010 - 11:49 PM
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.
#4
Posted 28 November 2010 - 05:19 AM
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.
tony
#5
Posted 29 November 2010 - 04:25 PM
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,
#6
Posted 29 November 2010 - 04:44 PM
#7
Posted 02 December 2010 - 02:58 PM
#8
Posted 02 December 2010 - 11:24 PM
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.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.
#9
Posted 02 December 2010 - 11:50 PM
#10
Posted 03 December 2010 - 07:29 AM
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
#11
Posted 03 December 2010 - 04:29 PM
Sorry for the confusion - I knew, I really meant the library you referenced.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.
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.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" ?
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.
#12
Posted 03 December 2010 - 06:37 PM
#13
Posted 04 December 2010 - 04:18 AM
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!
#14
Posted 04 December 2010 - 06:31 AM
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).
#15
Posted 04 December 2010 - 01:13 PM
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.
#16
Posted 08 December 2010 - 12:51 AM
#17
Posted 08 December 2010 - 03:58 PM
tony
#18
Posted 31 May 2011 - 08:19 AM
#19
Posted 06 February 2013 - 11:43 AM
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.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users