Home/Support/Support Forum/Hex Data
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Hex Data

0 votes
I'm trying to send commands from a host application to the ConnectPort which receives the command via TCP/IP and then sends it to the appropriate xBee node.

I seem to be able to receive the command fine on the ConnectPort but socket.recv seems to always convert the received message into a string. The string seems to be forwarded to the xBee node and it doesn't respond like it should. Here is what I'm using for testing;

message = tcpSocket.recv(256)
tcpAddress = tcpSocket.getpeername()

print "Received data from ", tcpAddress, " forwarding to Zigbee socket"
print message

zigbeeSocket.sendto(message, 0, zigbeeAddress)


Is there a way I can first view on the console that I'm receiving the right commands and then make sure it is still in Hex when forwarded over zigbee?
asked Aug 9, 2009 in Python by jim3342 New to the Community (1 point)

Please log in or register to answer this question.

4 Answers

0 votes
Yes, the socket module will represent the data that it receives as a string. However, the string still should contain the binary data however you sent it initially. Perhaps you could give a sample of what you expect your data to look like, as well as what you seem to be seeing.

If it is binary data, it won't print well and you may need to process it somewhat to better interpret what is being passed around. One fairly quick and easy way is to call repr() on the string, which will escape most characters for better interpretation.

Also, I see that you're receiving in maximum sizes of 256 on the tcp side, and then forwarding on what you receive. TCP is stream based and will happily give you 256 bytes. The mesh is datagram based, with a significantly smaller max payload, something around 70 bytes I believe. If you pass data beyond that into the 'sendto' call, that is an error. It will give a short return and will not transmit all that was passed. Your application will probably need to segment the data to pass it on in full. This could be part of the reason your remote device does not behave as you desire.
answered Aug 9, 2009 by DigiGuy42 Community Contributor (102 points)
0 votes
I'm looking to send short commands to the remote device such as a payload like;

FC FE 01 10

I have been more focusing on the print at this time to make sure I have the right byte sequence at the ConnectPort before sending it to the zigbee device. I will also need to shorten the 256 size.
answered Aug 10, 2009 by jim3342 New to the Community (1 point)
0 votes
All of the characters you list in this example are "unprintable" ASCII characters. The result of "print message" in such a case is likely to print junk to the display.

Can you divide this up to isolate the problem?

For instance, can you describe the byte sequence you expect to be transmitting over TCP, and then the result of both

print len(message)
print repr(message)

... after the successful call to recv?

In turn, can you build a local string with the payload you hope will be transmitted to the zigbee radio, i.e.

outstr = '\xfc\xfe\x01\x10'

... and send that to the radio via sendto?

It will be very useful to differentiate a problem in the TCP half of things, or the zigbee half.
answered Aug 10, 2009 by 52637p Community Contributor (59 points)
0 votes
You can also create the "binary string" as:
outst = chr(0xFC) + chr(0xFE) + chr(0x01) + chr(0x10)

Unlike C/C++, Python maintains a string length so nulls (\x00) can be placed into the string fine.

To print or dump binary strings I often toss this routine into my code (the forum strips the indentation):

def print_bytes( szMsg, data):
print "%s[%d]" % (szMsg,len(data)),
for by in data:
print "%02X" % ord(by),
print
return

So "print_bytes('output', outst)" would show:
output[4] FC FE 01 10
answered Aug 10, 2009 by lynnl Veteran of the Digi Community (1,047 points)
...