Serial Comms via the ZigBee Port
Serial Comms via the ZigBee Port
by Pev
Thu Aug 24, 2006 8:39 am
Hi,
I have been investigating the ZigBee port with a view to hijacking the connections and putting a Bluetooth module in it's place. This is what I have found so far.
The Zigbee port appears to run at 57600 baud, 8 bit, 1 stopbit, No Parity and with no flow control as we would probably all expect. The connection has a 8 connections with connection 1 being ground, and 7 and 8 being TX and RX. (Can never remember which way round those 2 are lol). I believe that with teh ZigBee100 plugged in there is the opportunity to reset the port Baud rate but without it it looks like its just 57600.
Firstly, I hooked up a TTL level shifter to the port by tacking the wires in place with a tiny bit of solder and just powered up the CM-5. I got the familiar banner you get in the BCP program play mode out of the Zigbee port. I think started sending data out of the port and all seemed well, although I couldn't quite get my head around the packet format.
Had a lot of trouble getting my incoming packets to trigger the CM-5 remcon RX Data incoming flag so I dropped a line to Robotis.
THey kindly supplied the Zigbee packet format which is
0xFF 0x55 DATA1 ~DATA1 DATA2 ~DATA2
where ~ represents the inverse or compliment of the original value. Thus to send an A (0x41) the packet would be:
0xFF 0x55 0x41 0xBE 0x00 0xFF
This definately triggers the RX Data Incoming flag. However at the present time if I read the data or attempt to use it in a simple If statement to turn on the AUX LED I get the LED turning on then the CM-5 drops out of play mode and I get an ERROR:000A reported by the CM-5.
So some progress that I wanted to share in the hope that there may be some other, clever people out there investigating this and who may have worked around the ERROR:000A issue. I have sent details to Robotis asking for advice. When I hear I'll update the thread.
Pev
I have been investigating the ZigBee port with a view to hijacking the connections and putting a Bluetooth module in it's place. This is what I have found so far.
The Zigbee port appears to run at 57600 baud, 8 bit, 1 stopbit, No Parity and with no flow control as we would probably all expect. The connection has a 8 connections with connection 1 being ground, and 7 and 8 being TX and RX. (Can never remember which way round those 2 are lol). I believe that with teh ZigBee100 plugged in there is the opportunity to reset the port Baud rate but without it it looks like its just 57600.
Firstly, I hooked up a TTL level shifter to the port by tacking the wires in place with a tiny bit of solder and just powered up the CM-5. I got the familiar banner you get in the BCP program play mode out of the Zigbee port. I think started sending data out of the port and all seemed well, although I couldn't quite get my head around the packet format.
Had a lot of trouble getting my incoming packets to trigger the CM-5 remcon RX Data incoming flag so I dropped a line to Robotis.
THey kindly supplied the Zigbee packet format which is
0xFF 0x55 DATA1 ~DATA1 DATA2 ~DATA2
where ~ represents the inverse or compliment of the original value. Thus to send an A (0x41) the packet would be:
0xFF 0x55 0x41 0xBE 0x00 0xFF
This definately triggers the RX Data Incoming flag. However at the present time if I read the data or attempt to use it in a simple If statement to turn on the AUX LED I get the LED turning on then the CM-5 drops out of play mode and I get an ERROR:000A reported by the CM-5.
So some progress that I wanted to share in the hope that there may be some other, clever people out there investigating this and who may have worked around the ERROR:000A issue. I have sent details to Robotis asking for advice. When I hear I'll update the thread.
Pev
by inaki
Thu Aug 24, 2006 12:36 pm
I would bet that that error has something to do with the packet format, perhaps because the packet is wrong or because the serial signals are wrong.
Perhaps the header is not 0xFF,0x55 or there is some byte missing.
For example, in the normal serial interface it seems to use 0xFF,0xFF as header, a byte with the length of the packet and a byte for checksum. However the wireless interface seems to use a much simpler package.
The serial communication may be wrong too, for example:
The bits you are sending to the Zigbee interface are in LSB or MSB format ? I think it should be LSB. Other than this, are you using reverse serial levels or normal levels (many interfaces require reversed levels but others do not) ?
Perhaps the header is not 0xFF,0x55 or there is some byte missing.
For example, in the normal serial interface it seems to use 0xFF,0xFF as header, a byte with the length of the packet and a byte for checksum. However the wireless interface seems to use a much simpler package.
The serial communication may be wrong too, for example:
The bits you are sending to the Zigbee interface are in LSB or MSB format ? I think it should be LSB. Other than this, are you using reverse serial levels or normal levels (many interfaces require reversed levels but others do not) ?
by Pev
Thu Aug 24, 2006 1:16 pm
Hi,
Attached is the powerpoint slide sent over by Robotis detailing the packet format:
http://robosavvy.com/Builders/Pev/ZIG-100%20Remocon%20Packet.ppt
As you say it is much simpler than the normal serial packet. I am going to work on this again tonight as I am wondering if its the way I am processing the data after I have recieved it. My reasoning for this is that If I print the incoming data it does appear correctly. i.e if I use their example I get decimal 4660 displayed before the error.
Pev
Attached is the powerpoint slide sent over by Robotis detailing the packet format:
http://robosavvy.com/Builders/Pev/ZIG-100%20Remocon%20Packet.ppt
As you say it is much simpler than the normal serial packet. I am going to work on this again tonight as I am wondering if its the way I am processing the data after I have recieved it. My reasoning for this is that If I print the incoming data it does appear correctly. i.e if I use their example I get decimal 4660 displayed before the error.
Pev
by Pev
Fri Aug 25, 2006 6:39 am
Time for me to be rather embarrassed. I have just had a look through my BCP program and the ERROR:000A was nothing to do with the wireless comms and remocon code. It was a really stupid mistake on my part. I jumped to a routine and then tried to return from it. Should have used CALL.
How embarassing. Inaki sorry for wasting your time.
A very very red faced Pev
by Pev
Mon Aug 28, 2006 6:56 pm
inaki wrote:Pev, please, dont worry. What you have found is great. Now please tell us what plans do you have to place a Bluetooth adapter in place of the zigbee thing. I am eager to hear about the results.
Inaki,
Try this
http://robosavvy.com/modules.php?name=Forums&file=viewtopic&t=551
should give you more details. Am working on a Pocket PC interface now
Pev