New version of packet-check program

Here is an updated version of my packet-check program. It’s a fairly simple program that lets you type or paste an API packet. The program then analyses the packet and prints the result of the analysis. Handy if you’re experimenting with API and you want to know whether the packets you’re generating are valid.

The update is minor: the main change is that a TX request packet will now show the ASCII characters in the transmitted data. The update was prompted when I was replying to a recent post from archendekta. I was looking up the ASCII codes by hand, and decided that it would be better if the program would do that for me.

I’ve also reviewed the new product manual for firmware version 1xe6, and made a few cosmetic changes to improve the output where the manual has clarified things. I didn’t find any new packet types or other major differences.

The program is a Tcl script, designed to be run from the command line (command prompt in Windows). It should run on any platform that has Tcl installed. If you want to use it but don’t have Tcl, you can get Tcl for your platform from (eg) www.activestate.com. Tcl is free software, and packet-check is of course also free.

Runs on pretty much any platform, including Linux, MacOS and Windows.

Here’s an example of running the new version under Linux.

[john@eccles ~]$ ./packet-check.tcl
API Packet analyzer for Series 1 XBee (version 0.3)
Enter packet: 7E 00 13 00 55 00 13 A2 00 40 30 EF 90 00 01 00 48 65 6C 6C 6F 21 F0

Packet: 7E 00 13 00 55 00 13 A2 00 40 30 EF 90 00 01 00 48 65 6C 6C 6F 21 F0
7E // Correct packet header byte
00 13 // payload length (decimal 19)
00 // Packet type: TX request with 64-bit address
55 // frame id
00 13 A2 00 40 30 EF 90 // 64-bit destination address
00 // TX options
01 // transmitted data SOH
00 // transmitted data NUL
48 // transmitted data ‘H’
65 // transmitted data ‘e’
6C // transmitted data ‘l’
6C // transmitted data ‘l’
6F // transmitted data ‘o’
21 // transmitted data ‘!’
F0 // checksum - correct

[john@eccles ~]$

Enjoy!

Thanks for posting that johnf!

great learning tool, i.e. for me. appreciate the effort john.

Hey john,

probably an obvious answer but i want to be sure; we need the SOH and NUL byte to indicate the start of the data portion of the packet? regardless if using TX req for 64 or 16-byte address?

not quite clear on this,
thx

Your program sounds very useful. However, when I run it on WindowsXP an empty window opens without any prompts. I am running it under ActiveState Tcl v. 8.5 from the command prompt. Any thoughts?

No, you don’t need those bytes unless they really are part of the data you mean to send.

For instance, this packet would omit them leaving you with just the text:

7E 00 11 00 55 00 13 A2 00 40 30 EF 90 00 48 65 6C 6C 6F 21 F1

Decoded, that’s

Packet: 7E 00 11 00 55 00 13 A2 00 40 30 EF 90 00 48 65 6C 6C 6F 21 F1
7E // Correct packet header byte
00 11 // payload length (decimal 17)
00 // Packet type: TX request with 64-bit address
55 // frame id
00 13 A2 00 40 30 EF 90 // 64-bit destination address
00 // TX options
48 // transmitted data ‘H’
65 // transmitted data ‘e’
6C // transmitted data ‘l’
6C // transmitted data ‘l’
6F // transmitted data ‘o’
21 // transmitted data ‘!’
F1 // checksum - correct

Hope that helps, and thanks for the nice comments!

Hmm. Unfortunately I don’t have a Windows machine handy to try this. The only thought that occurs immediately is to ask whether you ran the program like this:
wish packet-check.tcl
? If so, that might account for it, though when I do that under linux I do see the prompts. Try
tclsh packet-check.tcl
instead. (wish is for GUI programs, but packet-check is pure command line).

If that’s not the answer, let us know and perhaps someone who’s made it work will be able to give more suggestions. And anyway, if it doesn’t do the trick I’ll find a Windows machine and try it myself. This is one of those “there must be a simple answer” questions…

I got it. When the package installs, it updates the path extension, but not the path itself. And for the version I have, the shell is tclsh85, not tclsh

“tclsh85 packet-check.tcl” working on windows7

Thanks for the helpful feedback - for the next update I’ve added a comment to mention the tclsh85 bit.

I wonder whether anyone’s tried the program under MacOS? If so, it’d be nice to hear what the invocation procedure is there. I assume it’d be the same as Linux, but I don’t know.