search

adafruit / Adafruit_CircuitPython_ESP_ATcontrol

Use the ESP AT command sent to communicate with the Interwebs
MIT License
20 stars 17 forks source link

in Adafruit_CircuitPython_ESP_ATcontrol AT+CWLAP Does not return OK #48

Closed mperino closed 2 years ago

mperino commented 2 years ago

It looks like Adafruit_CircuitPython_ESP_ATcontrol expects that AT+CWLAP (aka esp.scan_APs() ) to return OK.

On Challenger 2040 (and I expect other ESP) it returns the string of AP's, but no OK. Because there is no "Special Case" for AT+CWLAP, it raises (raise OKError("No OK response to " + at_cmd)).

Here's the AT Debug (MAC and AP obscured with XX: ---> AT <--- b'\r\nOK\r\n' ---> AT+GMR <--- b'AT version:2.1.0.0-rc1(32ea726 - Jul 16 2020 02:34:17)\r\nSDK version:v3.3-2-gb6e861a7\r\ncompile time(0993e9e):Jul 16 2020 09:03:46\r\nBin versn.0kn\nO' ---> AT+GMR <--- b'AT version:2.1.0.0-rc1(32ea726 - Jul 16 2020 02:34:17)\r\nSDK version:v3.3-2-gb6e861a7\r\ncompile time(0993e9e):Jul 16 2020 09:03:46\r\nBin versn.(kw\nK' ---> AT+GMR <--- b'AT version:2.1.0.0-rc1(32ea726 - Jul 16 2020 02:34:17)\r\nSDK version:v3.3-2-gb6e861a7\r\ncompile time(0993e9e):Jul 16 2020 09:03:46\r\nBin verso.0kw\nO' ---> AT+CWMODE? <--- b'+CWMODE:1\r\n\r\nOK\r\n' ---> AT+CWLAP <--- b'+CWLAP:(3,"NSXX",-35,"XX:f4:c6:10:XX:XX",5)\r\n+CWLAP:(3,"DTV",-65,"02:6b:XX:ae:XX:XX",11)\r\n+CWLAP:(3,"uXX",-70,8a0::,)CP3"0ea::e,\r\n\n' ---> AT+CWLAP <--- b'+CWLAP:(3,"NSXX",-34,"XX:f4:c6:10:XX:XX",5)\r\n+CWLAP:(3,"DTV",-64,"02:6b:XX:ae:XX:XX",11)\r\n+CWLAP:(3,"uXX",-70,"82cb"1+A("7780c:,)\n\r' ---> AT+CWLAP <--- b'+CWLAP:(3,"NSXX",-34,"XX:f4:c6:10:XX:XX",5)\r\n+CWLAP:(3,"DTV",-64,"02:6b:XX:ae:XX:XX",11)\r\n+CWa1\rWP3,,ea:::")\r\r' Failed to get data, retrying No OK response to AT+CWLAP

mperino commented 2 years ago

Worked with Pontus and they found:

The default receive buffer (64 bytes) is not big enough to hold all the data coming from the onboard ESP. When large amounts of data are being sent, especially at high baud rates such as 115200 or higher, the circuitpython interpreter simply can't keep up with the data channel, and data gets overwritten/lost causing the python at-library to lose sync with the device. The short term fix for this is to increase the default buffer receive buffer size to something that can hold a complete data packet in the buffer before your program can interpret the data. This is done by revising the UART creation statement to include this. For instance: uart = busio.UART(TX, RX, baudrate=115200, receiver_buffer_size=2048) will increase the buffer size to 2048 bytes allowing receiving up to 2048 bytes of data before the buffer becoming overwritten.

I will add fixes to the examples with the workaround.