Toit
#Port.read blocking when using DYP-A01 package together with the A02YYUW ultrasonic sensor
Thread channel in help
ApEf 02/07/2024 08:26 PMWiki: This is an easy-to-use ultrasonic distance sensor module of high performance and reliability, waterproof and dustproof. Compared with other similar sensors, it features much smaller blind zone, wider sensing angle and a certain penetration power (smog, dust). Wiki: This A01NYUB Waterproof Ultrasonic Sensor features farther monitoring distance, wider detection range and a certain penetration power(smog, dust). Use the sensor with Arduino controller to build up your projects, such as backing car annunciator, obstacle avoidance robot, object approaching detection etc.
Hello!
I am working on a project where me and a friend are going to be measuring water levels using the A02YYUW sensor. This sensor does not seem to have a package and we opted to try to use the DYP-A01 package instead. We based this decision on the info we were given on DFROBOT, which according to their wiki they both use the same UART Output (the form, data bit, band/baud rate). A02YYUW: https://wiki.dfrobot.com/_A02YYUW_Waterproof_Ultrasonic_Sensor_SKU_SEN0311 DYP-A02 V2 (A01NYUB): https://wiki.dfrobot.com/A01NYUB%20Waterproof%20Ultrasonic%20Sensor%20SKU:%20SEN0313
We first had to edit line 5 in the DYP-A01 package from
When running the example file that is provided with the package (to simply read and output the distance values from the sensor in the terminal), the code seems to stop on this line:
The sensor is connected to an ESP-WROOM-32, to pins: VIN(5v), RX2 (pin17), TX2 (pin16), GND. The sensor works, it has been verified to be functioning correctly when tested in C with ESP-IDF.
I am working on a project where me and a friend are going to be measuring water levels using the A02YYUW sensor. This sensor does not seem to have a package and we opted to try to use the DYP-A01 package instead. We based this decision on the info we were given on DFROBOT, which according to their wiki they both use the same UART Output (the form, data bit, band/baud rate). A02YYUW: https://wiki.dfrobot.com/_A02YYUW_Waterproof_Ultrasonic_Sensor_SKU_SEN0311 DYP-A02 V2 (A01NYUB): https://wiki.dfrobot.com/A01NYUB%20Waterproof%20Ultrasonic%20Sensor%20SKU:%20SEN0313
We first had to edit line 5 in the DYP-A01 package from
import serial.ports.uart show Portuart show PortWhen running the example file that is provided with the package (to simply read and output the distance values from the sensor in the terminal), the code seems to stop on this line:
msg := "{\"range\": $(dyp.range)}"frame := port.readThe sensor is connected to an ESP-WROOM-32, to pins: VIN(5v), RX2 (pin17), TX2 (pin16), GND. The sensor works, it has been verified to be functioning correctly when tested in C with ESP-IDF.
floitsch 02/08/2024 08:17 AM
The
Let me see if I can find documentation about the DYP-A02
importLet me see if I can find documentation about the DYP-A02
floitsch 02/08/2024 08:27 AM
It looks like the A02 and the A01 share the same protocol. The package should thus work with your sensor (modulo the
importfloitsch 02/08/2024 08:28 AM
From the dfrobot page it looks like the sensor can work with 3.3V, so I would use that instead.
There are conflicting reports about whether the ESP32 can support 5V, but in this case it looks like it's not necessary, so I would use the 3.3V instead to avoid damaging the ESP32.
There are conflicting reports about whether the ESP32 can support 5V, but in this case it looks like it's not necessary, so I would use the 3.3V instead to avoid damaging the ESP32.
floitsch 02/08/2024 08:28 AM
Could you show me the program you use?
floitsch 02/08/2024 08:32 AM
You probably don't need to connect the RX pin (pin 3 on the sensor) to anything, unless you want to be able to change the output-speed of the sensor.
floitsch 02/08/2024 08:33 AM
1
Could you try to run the following program, to see if you get data from the sensor?
import gpio
import uart
main:
rx := gpio.Pin 16 // Labeled as TX on the sensor.
port := uart.Port --rx=rx --baud-rate=9600 --tx=null
while true:
data := port.read
print "received: $data"1ApEf 02/08/2024 12:52 PM
Thanks for your help! It seems to work with the code you provided and we are now able to receive data from the sensor.
I'm sorry to bother with another question, however on another sidenote. We're going to be using LoRaWAN in this project and we're wondering if using an ESP with LoRa (like Heltec Lora32) or an ESP with an external LoRa module would be more difficult? As in, if we find the internal pins for the LoRa module in, for example, the Heltec Lora32, would it be similar to working with an external module (in the code).
We've found a project that uses LoRa with external modules but not any with an ESP that has LoRa integrated.
I'm sorry to bother with another question, however on another sidenote. We're going to be using LoRaWAN in this project and we're wondering if using an ESP with LoRa (like Heltec Lora32) or an ESP with an external LoRa module would be more difficult? As in, if we find the internal pins for the LoRa module in, for example, the Heltec Lora32, would it be similar to working with an external module (in the code).
We've found a project that uses LoRa with external modules but not any with an ESP that has LoRa integrated.
floitsch 02/08/2024 12:55 PM
First: don't hesitate to ask when you have questions. Sometimes our documentation isn't up to date, and often we can respond quite quickly.
For LoRa: there is no difference between a board with an integrated module and an external one. The boards that have LoRa integrated still talk to the chip the exact same way as if the module was outside.
Note that there is only one driver (I know of) for LoRa. Let me have a look which chips it supports.
For LoRa: there is no difference between a board with an integrated module and an external one. The boards that have LoRa integrated still talk to the chip the exact same way as if the module was outside.
Note that there is only one driver (I know of) for LoRa. Let me have a look which chips it supports.
floitsch 02/08/2024 12:56 PM
It's the SX1262
floitsch 02/08/2024 12:56 PM
If you have another chip, make sure to ask first, if the driver would be compatible with your chip.
floitsch 02/08/2024 12:58 PM
oh. And if I remember correctly, there is no "LoRaWAN" package yet.
floitsch 02/08/2024 12:58 PM
So you would only have the lower-level LoRa communication.
ApEf 02/08/2024 01:02 PM
Thanks for your answer, the microcontroller we plan to use in this project (for testing) is a Wireless stick lite V2 from heltec, which according to their documentation seems to use the SX1276 chip. However, the V3 does use SX1262 and we're planning on buying another unit so might as well implement LoRa connectivity with using the SX1262 chip instead.(edited)
floitsch 02/08/2024 06:18 PM
Interesting. The V3 uses an older chip than the V2? (assuming higher number means newer chip).
floitsch 02/08/2024 06:19 PM
Kasper had a look at the sx1276, but concluded that it was different enough, that it required basically a completel rewrite of the driver.
ApEf 02/08/2024 06:45 PMThe HTIT-WSL is composed up of an MCU (ESP32-S3FN8) and Semtech LoRa Transceivers (SX1262), perfectly support Arduino®. Users can easily carry out secondary development and application. 
We thought so too, that a higher number would mean a newer chip, which makes one wonder why they chose to go with an older chip (if that truly is the case). At least that is what we could gather from their site: https://heltec.org/project/wireless-stick-lite-v2/. Could it be that they went with the older chip due to more support for it or to make the microcontroller cheaper?
If the V3 uses sx1262 I think it would be better for us to use it, not only since its the chip that is supported by the driver but also because if we're buying a new microcontroller it'll be the V3 instead.
If the V3 uses sx1262 I think it would be better for us to use it, not only since its the chip that is supported by the driver but also because if we're buying a new microcontroller it'll be the V3 instead.
floitsch 02/09/2024 06:28 AM
Looks like a nice device.
From what I could find the sx1262 and sx1276 both have their respective advantages, so just because one has a higher part-number doesn't seem to indicate that it is in fact better.
From what I could find the sx1262 and sx1276 both have their respective advantages, so just because one has a higher part-number doesn't seem to indicate that it is in fact better.
18 messages in total