no response to 'SH'

[GoogleCodeExporter]

What steps will reproduce the problem?
1. xbee.send('at', chr(9), command="SH") 
2. response = xbee.wait_read_frame()
3.

What is the expected output? What do you see instead?

the wait command doesn't respond.

When I use serial.write() followed by serial.read(), I do get a response for 
"ATSH"
I tried a variety of commands and a variety of frame ids, but "sh" will only 
hang.

What version of the product are you using? On what operating system?
The latest, running on OSX

Please provide any additional information below.

Original issue reported on code.google.com by r...@haystack.mit.edu on 8 Sep 2014 at 3:48

[GoogleCodeExporter]

Hello all,

I figured out why the SH command times out. There's an escaped delimiter in the 
address (for my particular XBee) that the wait_read_frame as is doesn't know 
how to handle.

How do I know that?

Since I can't use the code from this site as is, and I have to get a series 2 
XBee Pro/digimesh working, I created a utility to send/receive binary mode 
packets. There are a number of weirdnesses to binary mode that I've yet to 
fully work out (such as the device expects an ascii command after a binary 
command, so the serial port has to be closed then reopened, and you can't send 
a binary command after a "+++" because it then expects ascii to follow not 
binary) but when I get the utility completed,  I will copy it here.

Anyway, writing my own driver is how I discovered that sending an ATSH after 
setting ATAP mode 2, I discovered the escaped delimiter in the response.

Have fun.

Original comment by r...@haystack.mit.edu on 16 Sep 2014 at 8:24

[GoogleCodeExporter]

More information:

1.  The user's manual documentation is not as up to date as the tool that be 
access at this URL:
  http://ftp1.digi.com/support/utilities/digi_apiframes2.htm
  My first attempts to send remote AT commands returns status = 4, which isn't in the user's manual but
  from the info at that URL means I sent a bad remote command. 
  Also the upper 6 bits of the status byte should be ignored.

2. Not all remote AT commands are valid with the broadcast address (which is 
why I got the 4 error).
    The next step is to try several (or all) AT commands to see which are not supported.
     digimesh support seems to not understand that my question "which remote AT commands are supported?"
     was a general question -> their response was to point out that the one I tried wasn't supported. 

Original comment by r...@haystack.mit.edu on 24 Sep 2014 at 6:43

[GoogleCodeExporter]

More info with today's debugging session.
The send remote command ATND to the broadcast address returns a bad checksum 
but a
send remote command ATNH to the remote address returns a good checksum. Go 
figure (it might be my checksum calculator so I'll ignore it for now).
I created a list of all AT commands to send remotely to see what happens.
Detected errors on the first few responses, an extra byte is returned for 
certain commands between the 0x7E and the packet type, so the returned address 
is off by one. More coding to do to see what happens if I toss the extra byte. 
I retried sending those remote commands local (still as binary frame) and the 
read back was without errors, so not sure if the problem is real or a coding 
error on my part.

Original comment by r...@haystack.mit.edu on 26 Sep 2014 at 4:09

[GoogleCodeExporter]

Not noise but coding error -> escape detected in the LSB count field.
Which implies escapes can occur in the file id field, too.

Original comment by r...@haystack.mit.edu on 26 Sep 2014 at 6:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Finally have consistently working code but have now detected that frame type 
0x10 has a very small payload, on the order of 63 bytes. A protocol stack in 
python would be useful. I may do this or get the Xtend module and live with a 
2048 byte max packet size.
I've also created background threaded listener for frames based on gevent so 
you don't have to lock up on "wait" calls. Anybody interested in my source 
code? Its still a work in progress.

Original comment by r...@haystack.mit.edu on 29 Jan 2015 at 7:31