HC-SR04 and FreeBSD

[Luiz Otavio O Souza]

On 25 August 2014 16:57, Patrick Tracanelli wrote:
> On 24/08/2014, at 19:29, Evandro Nunes wrote:
>>> On Sat, Aug 23, 2014 at 5:51 PM, Patrick Tracanelli wrote:
>> Hello,
>>
>> As far as I know, for this specific ultrasonic sensor, you are missing
>> to set the echo GPIO pin to high. This sonar sensor will bring it back
>> to 0 when the triggered sound get back to the sensor (round-trip).
>>
>> So the correct sequence should be, in a loop:
>>
>> 1 - Set echo pin to HIGH
>> 2 - Trigger the sensor for 10us (it means your 100ms is more than you
>> need, but no, it won’t cause a problem)
>> 3 - Wait until echo in is LOW
>>
>> When the sound come back to sensor, the device will LOW the GPIO pin again.

No, this is not correct, setting a value to an input is a noop and
when you need this kind of cooperation from both sides, you usually
will be using a pull-up and open colector outputs (they never drive
the output to 'high' to avoid short-circuits).

[...]

>
> What you wanna do is to measure how long HIGH takes.
>
> I just made a better test so you can actually "see" the sensor working. Run this more simple loop:
>
> gpioctl -c 2 IN
> gpioctl -c 3 OUT
> gpioctl 3 0
>
> while true ; do
>  gpioctl 3 1 ; sleep .10; gpioctl 3 0
>    while [ $(gpioctl 2 | tail -1) -gt 0 ] ; do
>     echo "..." #nada
>    done
>  sleep 1
> done
>
> On a second shell, run this horrible cpu consuming loop:
>
> sh -c "while true ; do /root/date-precisao && gpioctl 2 ; done"

This one is okay,

>
> And check for the date when PIN 2 becomes high and later when it becomes low again.
>
> Speed of sound is 340 meters per second. Since this sensor measures round-trip, you shall divide by two, so here is a simple measurement by hand:
>
> An object added 1 meter from sensor:
>
> (eksffa at localhost):~% echo "((999013225427212-999013225364525)/340)/2" | bc
> 92
>
> An object added 2 meters from sensor:
>
> (eksffa at localhost):~% echo "((999013003943898-999013003811223)/340)/2" | bc
> 195
>
> So, now you have a better precision, but insanely high CPU usage due to the second loop.
>
> Yes, you are right, I personally agree some library with basic electronic functions would be very valuable to FreeBSD.
>
> Good to read you will try to write something, I believe Rui Paulo's library is a good start to hack, reading GPIO device, detecting when a PIN is HIGH and measuring the time until it becomes LOW is probably a good starter challenge ;-)

What we need is interrupt support so you don't need to keep reading
the GPIO pin in a busy loop and just get notified when the pin change
its state.

I hope i can get this sorted out soon (it is being worked on).

>
> One sensor I am trying to make work is DHT11 temperature and humidity, according to datasheet[1] on section 7, this "single-wire bi-directional" sensor seems to return a 32bit value which shall be calculated in 4 octets.

I can help you with the DHT11. I have some DHT11 working with an AVR
bridge which gives me the DHT11 data through I2C, this make the
readings reliable. I hope GPIO eventually grow up so i can get rid of
the AVR bridge. There are 5 octets with the Parity.

> This is a kind of sensor that deserves a library for sure (and FreeBSD deserves to have such a library) but hopefully not the kind of Arduino library which is device specific. A more generic library that reads a selectable 8/16/32bit value and returns it in different formats (decimal, hex, ...) would do the job for this sensor as well as other single-wire pin sensors.

A generic library isn't always possible because each device encodes
the data in its own format, the DHT11(/DHT22) is different than
onewire and so on, but a good driver (if possible) for DHT11 would be
useful.

>
> [1]http://akizukidenshi.com/download/ds/aosong/DHT11.pdf

Luiz