A02YYUW help needed

[stain7766]

I have installed ESP_Easy_mega_20230822_collection_A_ESP32_4M316k on a AZ-Delivery ESP32-WROOM-32

An A02YYUW is attached and I have been testing the plugin. A strange thing is happening.

The initial distance measurement is correct. However, regardless of changing the distances, all subsequent readings are exactly the same... no change.

The logs are below:

Code: Select all

209: ^^^INIT : Booting version: ESP_Easy_mega_20230822_collection_A_ESP32_4M316k, (GitHub Actions) mega-20230822 (ESP32 SDK 4.4.5.23
209: INIT : Free RAM:244296
211: INIT : Soft Reboot #2 Last Action before Reboot: Intended Reboot: CommandReboot Last systime: 146 - Restart Reason: CPU0: Softw
212: FS   : Mounting...
239: FS   : Mount successful, used 141815 bytes of 290156
256: CRC  : Settings CRC           ...OK
292: ESPEasy console using ESPEasySerial
307: CRC  : SecuritySettings CRC   ...OK 
333: INIT : Check for Priority tasks
334: INIT : SPI not enabled
335: Set Network mode: WiFi
437: WIFI : Set WiFi to STA
539: WiFi : Event STA Started
640: WiFi : Start network scan channel 1
7055: WiFi : Scan finished, found: 13
7057: WiFi : Best AP candidate: BT-AAAAAA 99:99:99:99:99:99 Ch:1 (-55dBm) WPA2/PSK bgn
7058: WiFi : Added known candidate, try to connect
7059: WiFi : Best AP candidate: BT-AAAAAA 99:99:99:99:99:99 Ch:1 (-55dBm) WPA2/PSK bgn
7061: INIT : Free RAM:196972
7119: A02YYUW: Initialization OK
7123: INFO : Plugins: 83 [Normal][Collection_A ESP32] (ESP32 SDK 4.4.5.230614)
7125: WiFi : Best AP candidate: BT-AAAAAA 99:99:99:99:99:99 Ch:1 (-55dBm) WPA2/PSK bgn
7126: WIFI : Connecting BT-AAAAAA 99:99:99:99:99:99 Ch:1 (-55dBm) WPA2/PSK bgn attempt #0
7135: WIFI : Arduino wifi status: WL_DISCONNECTED 6 ESPeasy internal wifi status: DISCONNECTED
8187: Webserver: start
8254: A02YYUW: Distance value = 72
8270: WIFI : Connected! AP: BT-AAAAAA (99:99:99:99:99:99) Ch: 1 Duration: 1137 ms
8271: WIFI : Arduino wifi status: WL_IDLE_STATUS 0 ESPeasy internal wifi status: Conn. 
8515: WIFI : DHCP IP: 192.168.9.99 (Collection-A-ESP32) GW: 192.168.9.999 SN: 255.255.255.0 DNS: 192.168.1.254 / 0.0.0.0   duration: 
8523: UDP : Start listening on port 8266
8523: firstLoopConnectionsEstablished
8532: mDNS : Starting mDNS...
8536: mDNS : Started, with name: Collection-A-ESP32.local
8560: MQTT : Intentional reconnect
8586: MQTT : Connected to broker with client ID: Collection_A_ESP32_0
8592: Subscribed to: Collection_A ESP32/#
9672: static_file: /esp.css
9802: WD   : Uptime 0 ConnectFailures 0 FreeMem 167708 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
17229: static_file: /esp.css
17230: Serve 304: 246899765 /esp.css
20232: static_file: /esp.css
20233: Serve 304: 246899765 /esp.css
39522: WD   : Uptime 1 ConnectFailures 0 FreeMem 169980 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
67189: A02YYUW: Distance value = 72
69522: WD   : Uptime 1 ConnectFailures 0 FreeMem 174872 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
99522: WD   : Uptime 2 ConnectFailures 0 FreeMem 174896 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
127189: A02YYUW: Distance value = 72
129522: WD   : Uptime 2 ConnectFailures 0 FreeMem 174896 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
159522: WD   : Uptime 3 ConnectFailures 0 FreeMem 174896 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
187189: A02YYUW: Distance value = 72

I have proven that the initial reading is correct by rebooting with a different distance. It is simply that no new readings are taken after this initial one and the same value is always returned. It is also in mm regardless of whether I divide by 10 (I want cm).

2023-09-12.png (54.08 KiB) Viewed 2035 times

Any help appreciated

[Ath]

Did you disable the Tools/Advanced setting "Enable Serial Port Console:"? (you are showing logs, so the answer must be No ) As that, by default, uses HWSerial0 on those GPIO pins, making it impossible for the plugin to also use that serial port.

A better solution would be to select HWSerial1 and another pair of GPIO pins for your sensor.

[Rob73]

I am just now starting to tinker with the serial communication, with the latest build also. I have the serial port console disabled under the tools:advanced tab and I still get the logging data under tools:log output. It really doesnt seem to matter if i have it disabled or not. It wont let me connect from the computer with a terminal program over serial if i have a serial server device enabled on the devices tab. I get logging scrolling regardless and the logging tab is the only place I see my serial data come through, from the logs. It shows all of my MQTT publishes and events happening. I am using an es8266 D1 Mini & it may be different on the ESP32. On mine, I am using HW Serial0 as the serial server port and it has the same setup for the serial console settings, HW Serial0. For mine it doesnt seem to care whether Enable serial port console is checked or not. I get the logging on a few other modules when the serial console is disabled also, may be specific to these d1 minis or something else I have in a setting.

Is this the first time you have used one of those A02YYUW sensors? Do you have another one to test or another module to test it with? What if you just set it up as a normal serial device, will it just spit raw data to the serial port that way? That would maybe give you some things to look at. If you look up that sensor, the arduino code just gets the serial data and then pieces together the data.

Rob

[stain7766]

BEGINNING to think I'm out of my depth here.

I disabled "Enable Serial Port Console:". Still getting logs. I changed the port and tx/rx pins. Making sure that pins were attached correctly, I got no readings so went back to the original settings I showed above and reconnected those pins. That is the only setting so far that I am getting any readings, with the led rapid flashing suggesting it is receiving data.

The readings now are completely inaccurate. If I place an object at a fixed position before the sensors, I get several different reading and none of them seem to reflect the mm distance. Not I have removed the distance formula just to work with raw data values for the time being. About 10mm away retuned values in the 600s, 1100s etc.

I do have 2 A02YYUWs so have tried both.

I will try another esp32 next but not really holding out much hope. Don't think I understand enough about pins/ports/serial to debug this myself

[TD-er]

The ESP32 is quite flexible regarding serial ports.
It simply boils down to 3 parameters:
- RX pin
- TX pin
- Port nr.

That last one doesn't seem important, but it is what makes the ESP32 do flexible.
So if you don't want to cause any conflict with the ESPEasy console and logging, you simply assign a different port nr to it and as long as there is no conflict in pins, it is a completely different port.

for picking the right pins, please have a look at this table:
https://espeasy.readthedocs.io/en/lates ... e-on-esp32

Some pins are absolutely a bad idea, like GPIO-0 and -12 and some have either a pull-up or pull-down resistor present.
Some others may output strange signals during boot, which makes them a less than optimal choice as TX pin.

[stain7766]

Thanks. Things have improved even if I am not sure exactly why.

I selected port SW Serial and pins GP21 (TX) and GP22 (RX). These do appear to be working but I did also select the lower voltage 3v3. Not sure if that was correct but I was trying a few things. Can change that back if the sensor struggles at lower voltage.

Is it possible in ESPEasy to manipulate more values that can be held locally and use these in exports? For example, I am using this for a water tank level and if I held the actual depth/radius of the tank plus the max water level and litres when full, I could do calculations to get the actual number of litres or % full. I am exporting via mqtt so could do this elsewhere but i do also have an available web page already written that takes an actual water level (not just the sensor ultrasonic reading) so doing this up front could be useful. If not, I can do this at the other end of the process but just trying to understand what EspEasy can do.

[TD-er]

Better not use SW serial, but rather use any of the HW serial ports if you have any HW serial ports left.
Software Serial (SW serial) is causing a lot of timing errors and thus errors in the transmission.

[stain7766]

You say not to use SW Serial. However, all the HW Serials failed to recognise any distance changes, exactly as before. So what do I do?

[TD-er]

Well I merely want to state that SW serial should be used as a last resort.

Could you try setting it to HWserial with a number you don't use anywhere else using those 2 pins, save it and then reboot the unit?
Or maybe even power cycle if that doesn't work.

I just remember seeing a reported issue a while ago in the ESP32 SDK about pins not being released when switching serial ports.
So if this is the case, I will have to find a way to work around this issue (or patch it myself).

[Yov]

I to am struggeling with this hardware. I have readings beoing them being very sensitive for materials closeby) but the promised 4,5meter is far from the distance readings i can get to. Max out at 2,3m.

[TD-er]

I have not played with this sensor myself.
But what I know from other sensors is that reflections are quite annoying.
Other ultrasonic sensors I have tested just try to match incoming signals as being an echo of what was just sent out.
So the first reflected sound will then trigger a pulse on the output and that's seen as the distance.

Internally this A02YYUW will probably just do the same.

For this to be somewhat useful, the sensitivity of the signal detection should not be set too low or else it may even trigger on other noise.
However this also means that the reflected ultrasonic signal should be strong enough.
So the attenuation of the reflected sound should not be too high and also enough should be reflected in the first place.

Sound dampening material like clothes will simply reflect a lot less sound.
And some other flat surfaces around your detection area may reflect more sound with a relatively shorter path and thus appear closer than what you want to detect.