search

digidotcom / xbee_ansic_library

A collection of portable ANSI C code for communicating with Digi International's XBee wireless radio modules in API mode.
204 stars 116 forks source link

network_scan sample does not work due to CTS not being set by XBee #11

Closed zapatek closed 4 years ago

zapatek commented 6 years ago

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:

  1. Does not work: Plug in the XBee device to host and run network_scan
  2. Works: Plug in the XBee device, run XCTU to connect to it, quit XCTU, run network_scan
  3. Does not work: After step 2 above, reset XBee without unplugging and run network_scan again

Any solutions?

tomlogic commented 6 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.

tomlogic commented 6 years ago

@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.

datag commented 6 years ago

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?

tomlogic commented 6 years ago

@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).

datag commented 6 years ago

@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?

tomlogic commented 6 years ago

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).

datag commented 6 years ago

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!

tomlogic commented 4 years ago

@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.

datag commented 4 years ago

@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.