Closed zapatek closed 4 years ago
Try setting ATD7
to 1, and then ATWR
to save that change. The library was written for a serial connection with flow control.
@zapatek I'm closing this issue out since I didn't hear back. Feel free to re-open it with additional information that might help with finding a solution.
I'm also experiencing this problem (XBee S2C connected via XBee USB adapter on POSIX):
If I connected to XBee with XCTU or terminal program like miniterm/minicom right before, the atinter command works like expected. Otherwise atinter shows this (w/ XBEE_SERIAL_VERBOSE XBEE_ATCMD_VERBOSE):
xbee_ansic_library/samples/posix$ ./atinter /dev/ttyUSB0 9600
_xbee_cmd_issue_list: next command ATHV
atcmd header is:
08 01 48 56 ..HV
xbee_ser_write: wrote 3 of 3 bytes
7e 00 04 ~..
xbee_ser_write: wrote 4 of 4 bytes
08 01 48 56 ..HV
xbee_ser_write: wrote 1 of 1 bytes
58 X
Waiting for driver to query the XBee device...
xbee_cmd_tick: request 0x0000 timed out
xbee_cmd_tick: dispatch to handler @0x563a58bcfd66 w/context 0x563a58dd61e0
_xbee_cmd_list_callback: timed out
_xbee_cmd_list_callback: found final callback
_xbee_cmd_query_handle_end: ATHV timed out!
_xbee_cmd_query_handle_end: HV=0x0 VR=0x0 IEEE=00-00-00-00-00-00 net=0x0000
xbee_cmd_tick: releasing expired request 0x0000
Error -110 waiting for query to complete.
XBee on /dev/ttyUSB0: HV=0x0 VR=0x0 IEEE=00-00-00-00-00-00 net=0x0000
Can't display menu for this hardware/firmware combination.
Valid command formats (AT prefix is optional, CC is command):
[AT]CC 0xXXXXXX (where XXXXXX is an even number of hexadecimal characters)
[AT]CC YYYY (where YYYY is an integer, up to 32 bits)
[AT]NI "Node ID String" (where quotes contain string data)
It seems the program does not receive any data. In some cases some bytes are received, but:
_xbee_cmd_issue_list: next command ATHV
atcmd header is:
08 01 48 56 ..HV
xbee_ser_write: wrote 3 of 3 bytes
7e 00 04 ~..
xbee_ser_write: wrote 4 of 4 bytes
08 01 48 56 ..HV
xbee_ser_write: wrote 1 of 1 bytes
58 X
Waiting for driver to query the XBee device...
xbee_ser_read: read 1 bytes
0e .
xbee_ser_read: read 1 bytes
02 .
xbee_ser_read: read 1 bytes
8a .
xbee_ser_read: read 1 bytes
00 .
xbee_ser_read: read 1 bytes
75 u
xbee_ser_read: read 1 bytes
4f O
xbee_ser_read: read 1 bytes
4b K
xbee_ser_read: read 1 bytes
0a .
xbee_cmd_tick: request 0x0000 timed out
xbee_cmd_tick: dispatch to handler @0x55b7c32cad66 w/context 0x55b7c34d11e0
_xbee_cmd_list_callback: timed out
_xbee_cmd_list_callback: found final callback
_xbee_cmd_query_handle_end: ATHV timed out!
_xbee_cmd_query_handle_end: HV=0x0 VR=0x0 IEEE=00-00-00-00-00-00 net=0x0000
xbee_cmd_tick: releasing expired request 0x0000
Error -110 waiting for query to complete.
XBee on /dev/ttyUSB0: HV=0x0 VR=0x0 IEEE=00-00-00-00-00-00 net=0x0000
And in rare cases the command succeeds.
When I connect w/ miniterm I'm able to communicate with the device:
$ miniterm --rtscts /dev/ttyUSB0 9600
...
+++
OK
ATMY
0
After that, the communication w/ atinter almost always works, but some times I get noise like this
xbee_ser_read: read 0 bytes
xbee_ser_read: read 0 bytes
xbee_ser_read: read 0 bytes
When I connect w/ XCTU right before atinter, the communication always works like expected:
xbee_ansic_library/samples/posix$ ./atinter /dev/ttyUSB0 9600
_xbee_cmd_issue_list: next command ATHV
atcmd header is:
08 01 48 56 ..HV
xbee_ser_write: wrote 3 of 3 bytes
7e 00 04 ~..
xbee_ser_write: wrote 4 of 4 bytes
08 01 48 56 ..HV
xbee_ser_write: wrote 1 of 1 bytes
58 X
Waiting for driver to query the XBee device...
xbee_ser_read: read 1 bytes
7e ~
xbee_ser_read: read 1 bytes
00 .
xbee_ser_read: read 1 bytes
07 .
xbee_ser_read: read 1 bytes
88 .
xbee_ser_read: read 1 bytes
01 .
xbee_ser_read: read 1 bytes
48 H
xbee_ser_read: read 1 bytes
56 V
xbee_ser_read: read 1 bytes
00 .
xbee_ser_read: read 1 bytes
2e .
xbee_ser_read: read 1 bytes
45 E
xbee_ser_read: read 1 bytes
65 e
_xbee_cmd_handle_response: response matched request 0
_xbee_cmd_handle_response: dispatch to handler @0x55a1b9168d66 w/context 0x55a1b936f1e0
_xbee_cmd_list_callback: matched command result ATHV
_xbee_cmd_issue_list: next command ATVR
... [CUT] ...
_xbee_cmd_query_handle_end: HV=0x2e45 VR=0x4060 IEEE=00-13-a2-00-41-52-10-19 net=0x0000
XBee on /dev/ttyUSB0: HV=0x2e45 VR=0x4060 IEEE=00-13-a2-00-41-52-10-19 net=0x0000
Is this some kind of flow control issue? What can I do to further investigate the issue?
@datag, which XBee USB adapter are you using, and how is the DIN line wired up?
It looks like the XBee is coming up in a recovery/configuration mode. At startup or on reset, if DIN is pulled low I believe the XBee boots into command mode and 9600 baud.
I'm interpreting one of your startup sequences as follows:
0e 02 8a 00 75
-> an Modem Status API frame (type 0x8a) with the frame start (0x7e) corrupted as 0x0e.
4f 4b 0a
-> the string "OK\n", sent to indicate that the XBee entered command mode.
If we review the schematic of the USB adapter, it might have a pulldown on DIN. Replacing that with a pullup might resolve the issue. If reset is connected to one of the other modem control lines (DTR?), maybe you could add some code to your startup procedure to open the serial port and toggle reset so it's booting with the port open (which should be holding DIN high).
@tomlogic, thanks for digging into this!
It's a Waveshare XBee-USB-Adapter https://www.waveshare.com/wiki/XBee_USB_Adapter and this is the schematic: https://www.waveshare.com/w/upload/4/47/XBee-USB-Adapter-Schematic.pdf
The DIN and DOUT seem to have 1K pull-ups.
You notice that CTS, RTS and DTS are NC in the schematic. I soldered a connection for CTS and RTS, DTR is still not connected. Could it be that I need to connect DTR as well?
And yes, it seems that the XBee does not perform in regular mode as I noticed the associate LED is not blinking as well. When connecting with XCTU or terminal program, the LED starts blinking. Another thing I noticed is that the XBee comes up when in transparent mode (ATAP=0) - the associate LED blinks as usual. Why the different behavior?
If reset is connected to one of the other modem control lines (DTR?), maybe you could add some code to your startup procedure to open the serial port and toggle reset so it's booting with the port open (which should be holding DIN high).
Is that the case? I cannot find something about that in the schematic. And is this XBee adapter really compatible, if that's the issue?
I did not see pull ups on the DIN and DOUT pins of the schematic. You'd want to check voltages of those pins without an XBee installed, when you have the serial port closed, and then again after opening the port.
I found this regarding forcing the module into command mode using serial break (holding the DIN pin low):
Can you open a terminal in XCTU at 9600 baud and send a serial break for 6+ seconds. This procedure will force the module to enter command mode using standard UART settings (9600 baud, 8/N/1). I would expect the module to emit an "OK" message, indicating command mode has been entered.
If you hook up DTR, you can use it for /SLEEP_RQ
but would need to configure it as such and control it from your terminal program. I don't recall whether the host library does anything specific with it.
I'm not sure why the module would come up with ATAP=0
but not with ATAP=1
(assuming that's the only configuration difference).
I did not see pull ups on the DIN and DOUT pins of the schematic.
Sorry, I've mistaken the RXD/TXD LEDs schematic as pull-ups :see_no_evil:
You'd want to check voltages of those pins without an XBee installed, when you have the serial port closed, and then again after opening the port.
The DIN/DOUT always reads high (regardless of port opened or closed) - so this should be OK and not the cause for the module to not come up?
I guess it's some problem with the adapter. As I'm using the XBee via adapter only for evaluation/development I'm fine with using a workaround. For now as a quick&dirty workaround I just run a modified version of miniterm in order to send some dummy data to the XBee and after that I'm able to use the library (w/ first frame start byte being correct).
I'm not sure why the module would come up with ATAP=0 but not with ATAP=1 (assuming that's the only configuration difference).
Yes, that is strange. I'm using firmware version 0x4060, haven't tried other versions.
Thank you for your effort so far, I appreciate it!
@datag I just pushed up some changes/improvements to the POSIX serial driver that might address the problem of samples only working after running XCTU first. I realize this issue is over a year old now, but if you're still working on this project can you please give the updated code a try? If you're still having problems, please re-open this issue.
@tomlogic Thanks for addressing this issue. Unfortunately I'm currently not working on this project and therefore cannot test the chance any time soon. But when I do so, I'll definitely post an update here.
I have tried network_scan sample both in posix (using macos) and win32 (using win7). In both cases, the nework_scan sample does not work due to the root cause that the XBee module does not set CTS as expected to start communication (even RTS is is set by host).
However in both OS platforms, the sample would work (CTS is set by XBee) if first XCTU is run and quit.
It seems that XCTU has some sort of device initialization process that is different than the samples and is able to put the XBee device in proper state. However the source code for XCTU is not available.
To summarize:
Any solutions?