Problems with xbee.send using ZBTxRequest and XBeeAddress64 (ArduinoXbee-2001)

531 views
Skip to first unread message

Eric Searle

unread,
Mar 4, 2011, 12:57:40 PM3/4/11
to xbee-api
I am using an Arduino hooked to a coordinator Xbee and a remote Xbee
with two pushbuttons and LED's on DO 0 and DO 3. Xbees are Series 2
Arduino software is 2001.

I have used the short form of ZBxRequest (3 params) and the long form
(6 params). In both cases when I monitor the output from Arduino sent
to the Coordinator Xbee, the output is corrupted. Two consecutive
bytes (0x7D and 0x33) are appearing in the output, usually overwriting
the high order bytes of the 64-bit Destination address at position 7
and 8 of the output. The position of the two bytes varies with the
payload size and sometimes is appears twice at positions 3 and 4 and
pos. 8 and 9. With a payload size of 1, the whole of the output stream
is overwritten.

Instead of creating an object for the 64-bit address in the
ZBTxRequest call itried using a local variable of type uint64_t but
the compiler did not allow this. The values of unint_32
DestinationDevAddrMS, uint_32 DestinationDevAddrLS and uint_16
NetworkAddress were obtained from a previous ZBRxIoSampleResponse call
and subsequent xbee.readPacket(); and
xbee.getResponse().getZBRxIoSampleResponse(ioSample); This wors fine.

I have tried moving both the ZBTxRequest and XBeeAddress64
instantiations positions around in my code. Same results.

I have included my code for review if you need it. all the nss.println
displays show the correct values. Please note, I have commented out a
lo of alternatives that I have tried to solve the problem

#define OutputPayloadLength 12
#define MaxOutputPayloadLength 32
uint32_t Work32;
// uint64_t Work64; // Alternate storage for 64-bit DeviceAddress.
Cannot be used in ZBTxRequest even though needs uint64_t
// 64-bit Address for ZBTxRequest to use (cannot use a uint64_t
directly)
// XBeeAddress64 XBee_Addr64 = XBeeAddress64(DestinationDevAddrMS,
DestinationDevAddrLS);



void SendXbee()
{
nss.println("Addresses Prior to Send");
// Work32 = XBee_Addr64.getMsb();
// nss.print("Work:");
// nss.println(Work32,HEX);
// Work64 = Work32;
// Work64 = Work64 << 32;
// Work32 = XBee_Addr64.getLsb();
// Work64 = Work64 + Work32;
// nss.print("Work32 My 32-bit Address:");
// nss.println(Work32,HEX);
nss.print("DestAddr MS (32-bits) ");
nss.println(DestinationDevAddrMS,HEX);
nss.print("DestAddr LS (32-bits) ");
nss.println(DestinationDevAddrLS,HEX);
nss.print("NetworkAddr: ");
nss.println(NetworkAddress,HEX);
// Data Frame to be sent to Xbee
// uint8_t XBee_Data[OutputPayloadLength]; // Was char type but
uint8_t works fine
uint8_t XBee_Data[MaxOutputPayloadLength];
int OutputLength = OutputPayloadLength; // need a variable for
ZBTxRequest
// FrameID is incremented from 1 each time
int MyFrameID = xbee.getNextFrameId(); // For ZBTxRequest. Did this
to see if it affects the overwrite of packet (bug)
nss.print("FrameID:");
nss.println(MyFrameID,HEX);

// Not sure whether byte [0] is needed
// I believe the FrameType defines the following as an AT Command.
// XBee_Data[0] = 0x08; // API Frame Type AT_COMMAND_REQUEST 0x08
// XBee_Data[1] = 0x4D; // Frame ID, any non-zero Value

XBee_Data[0] = 0x44; // First Byte "D" AT Command (D0) Digital
Output Zero?
XBee_Data[1] = 0x30; // Second Byte "0" AT Command (D0)
XBee_Data[2] = 0x05; // Pin High Output
XBee_Data[3] = 0x44; // First Byte "D" AT Command (D1) Digital
Output 2?
XBee_Data[4] = 0x31; // Second Byte "0" AT Command (D1)
XBee_Data[5] = 0x00; // Pin High Output
XBee_Data[6] = 0x44; // First Byte "D" AT Command (D2) Digital
Output 2?
XBee_Data[7] = 0x32; // Second Byte "0" AT Command (D2)
XBee_Data[8] = 0x00; // Pin High Output
XBee_Data[9] = 0x44; // First Byte "D" AT Command (D3) Digital
Output 2?
XBee_Data[10] = 0x33; // Second Byte "0" AT Command (D3)
XBee_Data[11] = 0x00; // Pin High Output

// 64-bit Address for ZBTxRequest to use (cannot use a uint64_t
directly)
XBeeAddress64 XBee_Addr64 = XBeeAddress64(DestinationDevAddrMS,
DestinationDevAddrLS);
nss.print("XBee_Addr64: from Object:");
nss.print("MS: ");
nss.println(XBee_Addr64.getMsb(),HEX);
nss.print("MS: ");
nss.println(XBee_Addr64.getLsb(),HEX);
nss.print

// MS is getting corrupted on output to the Coordinator
// Ensure that MS is correct prior ro
XBee_Addr64.setMsb(DestinationDevAddrMS);
XBee_Addr64.setMsb(DestinationDevAddrMS);
nss.print("XBee_Addr64: from Object Again:");
nss.print("MS: ");
nss.println(XBee_Addr64.getMsb(),HEX);
nss.print("MS: ");
nss.println(XBee_Addr64.getLsb(),HEX);
// XBee_Addr64.setMsb() = DestinationDevAddrMS; //Does not
Compile

// Create a TX Request
// ZBTxRequest zbTx = ZBTxRequest(XBee_Addr64, XBee_Data,
sizeof(XBee_Data));
// ZBTxRequest zbTx = ZBTxRequest(XBee_Addr64, XBee_Data, 0);
// ZBTxRequest zbTx = ZBTxRequest(XBee_Addr64, NetworkAddress,
ZB_BROADCAST_RADIUS_MAX_HOPS, ZB_TX_UNICAST, (uint8_t*) XBee_Data,
OutputLength, xbee.getNextFrameId());
ZBTxRequest zbTx = ZBTxRequest(XBee_Addr64, NetworkAddress,
ZB_BROADCAST_RADIUS_MAX_HOPS, ZB_TX_UNICAST, (uint8_t*) XBee_Data,
OutputLength,MyFrameID);
// ZBTxRequest zbTx = ZBTxRequest(DestinationDevAddr,
NetworkAddress, ZB_BROADCAST_RADIUS_MAX_HOPS, ZB_TX_UNICAST,
(uint8_t*) XBee_Data, OutputLength,MyFrameID);
// ZBTxRequest zbTx = ZBTxRequest(DestinationDevAddr,
NetworkAddress, ZB_BROADCAST_RADIUS_MAX_HOPS, ZB_TX_UNICAST,
(uint8_t*) XBee_Data, OutputLength,MyFrameID);

//Send the packet
nss.print("PacketToSend: ");
for(int i=0; i<= OutputPayloadLength-1; i++)
{
nss.print(XBee_Data[i],HEX);
// nss.print(0xFF,HEX); // Separator
}
nss.println();
xbee.send(zbTx);
GetResponse();
}

Andrew Rapp

unread,
Mar 5, 2011, 2:04:55 PM3/5/11
to xbee...@googlegroups.com
Those are escape bytes  Take a look at the FAQ http://code.google.com/p/xbee-api/wiki/FAQ and read the XBee documentation to learn more


--
You received this message because you are subscribed to the Google Groups "xbee-api" group.
To post to this group, send email to xbee...@googlegroups.com.
To unsubscribe from this group, send email to xbee-api+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xbee-api?hl=en.


Eric Searle

unread,
Mar 9, 2011, 9:18:08 PM3/9/11
to xbee...@googlegroups.com, dlwi...@aeis.tv
Dear Mr. Rapp,
 
I noticed the entry below in the "FAQ" listings referring to the same problem I am having:
My XBee address is 0x13 0xa2... but when I send a packet, I see 0x7d 0x33 0xa2... in the log. What's going on here?
I think the question was about the packet sent was apparantly overwritten by the XON and XOFF commands.
 
I am sending a packet using xbee.send(zbTx); on the instance below of ZBTxRequest.
 
ZBTxRequest zbTx = ZBTxRequest(XBee_Addr64, XBee_Data, OutputLength);
 
OutputLength is 5 (The payload contains at AT command to det D0 High on the Endpoint)
 
XBee_Addr64 contains 00 13 A2 00 (MS) and 40 69 29 E1 (LS)
 
X-CTU is displaying as output from the Coordinator:
 
7E 00 7D 33 10 01 00 7D 31 A2 00 40 69 29 E1 FF FE 00 00 08 4D 44 30 04 BC
 
It appears that:
1 -- The XOFF sequence (7D 33) is overwriting the LSB of the length field
2 -- The XON   sequence (7D 31) is overwriting the Hi order 2 bytes of the MS word of the 64-bit Endpoint address.
 
I have not yet been able to check whether the CRC (BC) was generated before or after the XON and XOFF were laid down.
 
This seems to be the same problem as described in the FAQ (above);
 
Are there any protocol calls that I need to do before calling xbee.send
 
Thank you very much for your timely respose to my post,     Eric G Searle

On Sat, Mar 5, 2011 at 2:04 PM, Andrew Rapp <andre...@gmail.com> wrote:
Those are escape bytes  Take a look at the FAQ http://code.google.com/p/xbee-api/wiki/FAQ and read the XBee documentation to learn more

On Fri, Mar 4, 2011 at 10:57 AM, Eric Searle <eric.g...@gmail.com> wrote:
I am using an Arduino hooked to a coordinator Xbee and a remote Xbee
with two pushbuttons and LED's on DO 0 and DO 3. Xbees are Series 2
Arduino software is 2001.

I have used the short form of ZBxRequest (3 params) and the long form
(6 params). In both cases when I monitor the output from Arduino sent
to the Coordinator Xbee, the output is corrupted. Two consecutive
bytes (0x7D and 0x33) are appearing in the output, usually overwriting
the high order bytes of the 64-bit Destination address at position 7
and 8 of the output.  The position of the two bytes varies with the
payload size and sometimes is appears twice at positions 3 and 4 and
pos. 8 and 9. With a payload size of 1, the whole of the output stream
is overwritten.

Instead of creating an object for the 64-bit address in the
ZBTxRequest call itried using a local variable of type uint64_t but
the compiler did not allow this.  The values of  unint_32
DestinationDevAddrMS, uint_32 DestinationDevAddrLS and uint_16
NetworkAddress were obtained from a previous ZBRxIoSampleResponse call
and subsequent xbee.readPacket(); and
xbee.getResponse().getZBRxIoSampleResponse(ioSample); This wors fine.

I have tried moving both the ZBTxRequest and  XBeeAddress64
instantiations positions around in my code. Same results.

--
You received this message because you are subscribed to the Google Groups "xbee-api" group.
To post to this group, send email to xbee...@googlegroups.com.
To unsubscribe from this group, send email to xbee-api+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xbee-api?hl=en.

Reply all
Reply to author
Forward
0 new messages