https://toitlang.org/ logo
Join Discord
Powered by
Port.read blocking when using DYP-A01 package toge...
# help
a
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 
import serial.ports.uart show Port
, as serial.ports could not be found, to 
uart show Port
instead. If this was a mistake (and what lead to our problem), then any help to import serial.ports would be appreciated. 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: 
msg := "{\"range\": $(dyp.range)}"
which we've narrowed down to the blocking happening on line 40 in the package dyp_a01.toit file --> 
frame := port.read
. The read function (from the standard library 'uart') is blocking until data is available, according to the documentation. 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.
f
The 
import
change is correct. Let me see if I can find documentation about the DYP-A02
It looks like the A02 and the A01 share the same protocol. The package should thus work with your sensor (modulo the 
import
change).
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.
Could you show me the program you use?
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.
Could you try to run the following program, to see if you get data from the sensor?
Copy code
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"
a
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.
f
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.
It's the SX1262
If you have another chip, make sure to ask first, if the driver would be compatible with your chip.
oh. And if I remember correctly, there is no "LoRaWAN" package yet.
So you would only have the lower-level LoRa communication.
a
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.
f
Interesting. The V3 uses an older chip than the V2? (assuming higher number means newer chip).
Kasper had a look at the sx1276, but concluded that it was different enough, that it required basically a completel rewrite of the driver.
a
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.
f
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.
PreviousNext
Powered by