On 28/03/2024 08:35, Björn Lundin wrote:
> On 2024-03-25 16:57, The Natural Philosopher wrote:
>> That is, some asynchrounous event in this sequence
>>
>>      gpio_put(ULTRASONIC_OUT,1);
>>      sleep_us(10);
>>      gpio_put(ULTRASONIC_OUT,0); //reset the input
>> //if asynch event lasting more than 100uS occurs here...
>>      // wait for echo pulse start
>>      while(!gpio_get(ULTRASONIC_IN))
>>          ;
>> //then the low-high-low echo pulse will never be detected.
>
>
> if you change the wait body to include a counter then you could realize
> that when the counter had reached a high number - you missed the pulse.
> Just try again then. Getting a reading is not that time sensitive - or?
>
That will be the next strategy.

I need to isolate exactly which bit is failing, and can remove all the
other debug code.
If it turns out to be a one in a thousand issue it probably isn't worth
trying to avoid it, as you say, simply take another sample

> :START
>       int cnt = 0;
>       gpio_put(ULTRASONIC_OUT,1);
>       sleep_us(10);
>       gpio_put(ULTRASONIC_OUT,0); //reset the input
>  //if asynch event lasting more than 100uS occurs here...
>       // wait for echo pulse start
>       while(TRUE) {
>
>         if (! gpio_get(ULTRASONIC_IN)) {
>            cnt++
>         } else {
>           break;
>         }
>
>         if (cnt >= TOO_HIGH_VALUE) {
>            goto START;
>         }
>
>
>       }
>

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

On 27/03/2024 10:13, The Natural Philosopher wrote:
> On 26/03/2024 21:58, Pancho wrote:
>> On 25/03/2024 15:57, The Natural Philosopher wrote:
>>> On 25/03/2024 11:31, Pancho wrote:
>>>> On 24/03/2024 11:13, The Natural Philosopher wrote:
>>>>
>>>>> However on trawling the internet I discovered a conversation  with
>>>>> someone else *on here* (c.s.r-pi) last year, who was finding that
>>>>> *sleep_us(x)* was highly inconsistent for certain (small) values of
>>>>> x. Sometimes taking a day to end.
>>>>>
>>>>> Further investigation reveals that in fact it really is a 'sleep'
>>>>> with the processor being put in low power mode and requiring an
>>>>> interrupt to 'wake it up'.
>>>>>
>>>>
>>>> Why not use threads/timers, wait on a lock/semaphore rather than sleep.
>>>>
>>> Good point Pancho, but I was really looking for the simplest code
>>> possible.  Interrupts can be tricky things on a platform whose
>>> architecture you do not understand completely. In any case it was a
>>> learnning curve I preferred not to negotiate if i didnt need to
>>>
>>
>> A timer isn't complicated, just a call back routine, and a semaphore.
>> Interrupts are something an OS does, not me :o). I hate multithread
>> code, but async handling of an external resource is one of the two
>> main places I would use another thread.
>>
>> I had a look at your code, it looks extraordinarily like a python
>> example on Tom's hardware.
>>
> Oh. The manufacturers sample code is the source of ALL the 'examples'
> that other people publish as their own., I am just being honest :-)
>
>> I'm not clear how many times it is succeeding vs failing, but I
>> suspect you really need to bite the bullet and introduce
>> timeouts/error handling, if it fails try again, average out multiple
>> results. i.e. accept it as flawed and that results are statistical,
>> like GPS.
>>
> Well the averaging out will happen anyway at the server side. I make the
> clients as simple as possible for resilience. In practice oil levels
> only change quickly if you have had the oil stolen overnight or if a
> supplier has filled the tank up, so gross deviations can have code
> exceptions, the rest would be the running average of maybe 20 samples.
> BUT it isn't inaccuracy that worries me per se, it's that it may be an
> indication of underlying timing issues.
>
>> In many ways the resilience code will be simple, because it is just
>> normal code, rather than cargo culting a novel ultrasonic device.
>>
> In fact the code in either case is simple.
>

I understood the idea of a ping delay time. It is just my experience
that things rarely work exactly as I expect them to.

FWIW, I'd also massively underestimated the difficulty of coding the
PICO, I'd assumed it was running a multitasking OS, like busybox, but I
see it isn't. I guess there are a whole bunch of gotchas there too.

> It is:  send a 10µs pulse to the unit, wait for the echo pulse start ,
> get the time, wait for the echo pulse end, get the time, subtract the
> difference.
>

I'm unclear on terms, but that sounds like the length of the pulse,
10µs. Not the distance travelled by the pulse. Surely, you should be
measuring the time between sending the pulse and receiving the pulse.
I've probably misunderstood something, if the code is giving a sensible
distance.

> What appears to be happening is that at short range the echo pulse never
> starts, or ends before the code is aware of it.
>
>> You can investigate further, by recording fail stats, as well as
>> distance stats.
>>
> Failure is very very rare. I am sampling for test purposes once a
> second, and its usually an hour or more before it locks up.
>
> I could simply  turn the while loop into a for loop with a counter so
> that even if I got a null result it wouldn't lock up. Missing one sample
> is no big deal: just take another!
>
> I am slightly curious as to how  the PICO could miss what is a several
> hundred microsecond wide pulse.
>

Maybe ultrasound is everywhere. Maybe a bird sings, or a walwart noise
interferes. The device may just move in mysterious ways.

> So far I have managed to get stuff reliable without having to unpick the
> ARM interrupt pandora's box. I am keen to leave it closed. The LWIP
> stack was bad enough...:-)
>

Yeah, I went off the idea of getting a PICO the moment I realised it
didn't have a proper OS. I have spare rPi3s I could use, and I'm willing
to accept high power usage of a couple of watts.

> Obviously interrupt on GPIO pin state would be the thing, but it would
> take some research to find out what the ISR was allowed to do in terms
> of library code that was re-entrant..
>

To be fair, the ISR wouldn't need to do much. But the problem might be
inherent in the ultrasonic device. The device interrupt/event may suffer
the same problem you are seeing.

On 29/03/2024 00:52, Pancho wrote:
> On 27/03/2024 10:13, The Natural Philosopher wrote:
>> On 26/03/2024 21:58, Pancho wrote:
>>> On 25/03/2024 15:57, The Natural Philosopher wrote:
>>>> On 25/03/2024 11:31, Pancho wrote:
>>>>> On 24/03/2024 11:13, The Natural Philosopher wrote:
>>>>>
>>>>>> However on trawling the internet I discovered a conversation  with
>>>>>> someone else *on here* (c.s.r-pi) last year, who was finding that
>>>>>> *sleep_us(x)* was highly inconsistent for certain (small) values
>>>>>> of x. Sometimes taking a day to end.
>>>>>>
>>>>>> Further investigation reveals that in fact it really is a 'sleep'
>>>>>> with the processor being put in low power mode and requiring an
>>>>>> interrupt to 'wake it up'.
>>>>>>
>>>>>
>>>>> Why not use threads/timers, wait on a lock/semaphore rather than
>>>>> sleep.
>>>>>
>>>> Good point Pancho, but I was really looking for the simplest code
>>>> possible.  Interrupts can be tricky things on a platform whose
>>>> architecture you do not understand completely. In any case it was a
>>>> learnning curve I preferred not to negotiate if i didnt need to
>>>>
>>>
>>> A timer isn't complicated, just a call back routine, and a semaphore.
>>> Interrupts are something an OS does, not me :o). I hate multithread
>>> code, but async handling of an external resource is one of the two
>>> main places I would use another thread.
>>>
>>> I had a look at your code, it looks extraordinarily like a python
>>> example on Tom's hardware.
>>>
>> Oh. The manufacturers sample code is the source of ALL the 'examples'
>> that other people publish as their own., I am just being honest :-)
>>
>>> I'm not clear how many times it is succeeding vs failing, but I
>>> suspect you really need to bite the bullet and introduce
>>> timeouts/error handling, if it fails try again, average out multiple
>>> results. i.e. accept it as flawed and that results are statistical,
>>> like GPS.
>>>
>> Well the averaging out will happen anyway at the server side. I make
>> the clients as simple as possible for resilience. In practice oil
>> levels only change quickly if you have had the oil stolen overnight or
>> if a supplier has filled the tank up, so gross deviations can have
>> code exceptions, the rest would be the running average of maybe 20
>> samples.
>> BUT it isn't inaccuracy that worries me per se, it's that it may be an
>> indication of underlying timing issues.
>>
>>> In many ways the resilience code will be simple, because it is just
>>> normal code, rather than cargo culting a novel ultrasonic device.
>>>
>> In fact the code in either case is simple.
>>
>
>
> I understood the idea of a ping delay time. It is just my experience
> that things rarely work exactly as I expect them to.
>
> FWIW, I'd also massively underestimated the difficulty of coding the
> PICO, I'd assumed it was running a multitasking OS, like busybox, but I
> see it isn't. I guess there are a whole bunch of gotchas there too.
>
>> It is:  send a 10µs pulse to the unit, wait for the echo pulse start ,
>> get the time, wait for the echo pulse end, get the time, subtract the
>> difference.
>>
>
> I'm unclear on terms, but that sounds like the length of the pulse,
> 10µs. Not the distance travelled by the pulse. Surely, you should be
> measuring the time between sending the pulse and receiving the pulse.
> I've probably misunderstood something, if the code is giving a sensible
> distance.
>
No.
Maybe ascii art will help

CONTROL=10µs
____| |________

RETURN = wahatever
_____|^^^^^^^^^^^^|____________

>
>> What appears to be happening is that at short range the echo pulse
>> never starts, or ends before the code is aware of it.
>>
>>> You can investigate further, by recording fail stats, as well as
>>> distance stats.
>>>
>> Failure is very very rare. I am sampling for test purposes once a
>> second, and its usually an hour or more before it locks up.
>>
>> I could simply  turn the while loop into a for loop with a counter so
>> that even if I got a null result it wouldn't lock up. Missing one
>> sample is no big deal: just take another!
>>
>> I am slightly curious as to how  the PICO could miss what is a several
>> hundred microsecond wide pulse.
>>
>
>
> Maybe ultrasound is everywhere. Maybe a bird sings, or a walwart noise
> interferes. The device may just move in mysterious ways.
>

No, I'ts definitely all associated with a short return pulse

>> So far I have managed to get stuff reliable without having to unpick
>> the ARM interrupt pandora's box. I am keen to leave it closed. The
>> LWIP stack was bad enough...:-)
>>
>
> Yeah, I went off the idea of getting a PICO the moment I realised it
> didn't have a proper OS. I have spare rPi3s I could use, and I'm willing
> to accept high power usage of a couple of watts.
>
Well this has to be battery powered.

You can get some sort of Free BSD RTOS port to a Pico, but in fact
mostly what you tend to be doing is just one thing at a time and so
linear code with callbacks works pretty well

>
>> Obviously interrupt on GPIO pin state would be the thing, but it would
>> take some research to find out what the ISR was allowed to do in terms
>> of library code that was re-entrant..
>>
>
> To be fair, the ISR wouldn't need to do much. But the problem might be
> inherent in the ultrasonic device. The device interrupt/event may suffer
> the same problem you are seeing.

That of course is what we are here to establish.

--
No Apple devices were knowingly used in the preparation of this post.

On 29/03/2024 10:49, The Natural Philosopher wrote:
> On 29/03/2024 00:52, Pancho wrote:
>> On 27/03/2024 10:13, The Natural Philosopher wrote:
>>> On 26/03/2024 21:58, Pancho wrote:
>>>> On 25/03/2024 15:57, The Natural Philosopher wrote:
>>>>> On 25/03/2024 11:31, Pancho wrote:
>>>>>> On 24/03/2024 11:13, The Natural Philosopher wrote:
>>>>>>
>>>>>>> However on trawling the internet I discovered a conversation
>>>>>>> with someone else *on here* (c.s.r-pi) last year, who was finding
>>>>>>> that *sleep_us(x)* was highly inconsistent for certain (small)
>>>>>>> values of x. Sometimes taking a day to end.
>>>>>>>
>>>>>>> Further investigation reveals that in fact it really is a 'sleep'
>>>>>>> with the processor being put in low power mode and requiring an
>>>>>>> interrupt to 'wake it up'.
>>>>>>>
>>>>>>
>>>>>> Why not use threads/timers, wait on a lock/semaphore rather than
>>>>>> sleep.
>>>>>>
>>>>> Good point Pancho, but I was really looking for the simplest code
>>>>> possible.  Interrupts can be tricky things on a platform whose
>>>>> architecture you do not understand completely. In any case it was a
>>>>> learnning curve I preferred not to negotiate if i didnt need to
>>>>>
>>>>
>>>> A timer isn't complicated, just a call back routine, and a
>>>> semaphore. Interrupts are something an OS does, not me :o). I hate
>>>> multithread code, but async handling of an external resource is one
>>>> of the two main places I would use another thread.
>>>>
>>>> I had a look at your code, it looks extraordinarily like a python
>>>> example on Tom's hardware.
>>>>
>>> Oh. The manufacturers sample code is the source of ALL the 'examples'
>>> that other people publish as their own., I am just being honest :-)
>>>
>>>> I'm not clear how many times it is succeeding vs failing, but I
>>>> suspect you really need to bite the bullet and introduce
>>>> timeouts/error handling, if it fails try again, average out multiple
>>>> results. i.e. accept it as flawed and that results are statistical,
>>>> like GPS.
>>>>
>>> Well the averaging out will happen anyway at the server side. I make
>>> the clients as simple as possible for resilience. In practice oil
>>> levels only change quickly if you have had the oil stolen overnight
>>> or if a supplier has filled the tank up, so gross deviations can have
>>> code exceptions, the rest would be the running average of maybe 20
>>> samples.
>>> BUT it isn't inaccuracy that worries me per se, it's that it may be
>>> an indication of underlying timing issues.
>>>
>>>> In many ways the resilience code will be simple, because it is just
>>>> normal code, rather than cargo culting a novel ultrasonic device.
>>>>
>>> In fact the code in either case is simple.
>>>
>>
>>
>> I understood the idea of a ping delay time. It is just my experience
>> that things rarely work exactly as I expect them to.
>>
>> FWIW, I'd also massively underestimated the difficulty of coding the
>> PICO, I'd assumed it was running a multitasking OS, like busybox, but
>> I see it isn't. I guess there are a whole bunch of gotchas there too.
>>
>>> It is:  send a 10µs pulse to the unit, wait for the echo pulse start
>>> , get the time, wait for the echo pulse end, get the time, subtract
>>> the difference.
>>>
>>
>> I'm unclear on terms, but that sounds like the length of the pulse,
>> 10µs. Not the distance travelled by the pulse. Surely, you should be
>> measuring the time between sending the pulse and receiving the pulse.
>> I've probably misunderstood something, if the code is giving a
>> sensible distance.
>>
> No.
> Maybe ascii art will help
>
> CONTROL=10µs
> ____| |________
>
> RETURN = wahatever
> _____|^^^^^^^^^^^^|____________
>

Yeah, I know what a ping is supposed to do. It is the time interval
between sending a ping and receiving the echo, simples. But... that
isn't what your code looks like.

You have:

while(!gpio_get(ULTRASONIC_IN));
//read clock and store
start=get_absolute_time ();

Which is presumably waiting for silence, no echo, it might work if that
is the default start state, i.e. if it does nothing, but it is
redundant. You should start the time interval when the ping is sent.

>>
>>> What appears to be happening is that at short range the echo pulse
>>> never starts, or ends before the code is aware of it.
>>>
>>>> You can investigate further, by recording fail stats, as well as
>>>> distance stats.
>>>>
>>> Failure is very very rare. I am sampling for test purposes once a
>>> second, and its usually an hour or more before it locks up.
>>>
>>> I could simply  turn the while loop into a for loop with a counter so
>>> that even if I got a null result it wouldn't lock up. Missing one
>>> sample is no big deal: just take another!
>>>
>>> I am slightly curious as to how  the PICO could miss what is a
>>> several hundred microsecond wide pulse.
>>>
>>
>>
>> Maybe ultrasound is everywhere. Maybe a bird sings, or a walwart noise
>> interferes. The device may just move in mysterious ways.
>>
>
> No, I'ts definitely all associated with a short return pulse
>

A short pulse always fails? I wasn't clear if it just made it more
vulnerable to failure. Failure caused by something else? Maybe
wavelength? Interference. I really don't know. I don't know how you can
rule stuff out. Apart from empirically, test reliability, in which case
you need to record failure stats as well as success.

>>> So far I have managed to get stuff reliable without having to unpick
>>> the ARM interrupt pandora's box. I am keen to leave it closed. The
>>> LWIP stack was bad enough...:-)
>>>
>>
>> Yeah, I went off the idea of getting a PICO the moment I realised it
>> didn't have a proper OS. I have spare rPi3s I could use, and I'm
>> willing to accept high power usage of a couple of watts.
>>
> Well this has to be battery powered.
>
> You can get some sort of Free BSD RTOS port to a Pico, but in fact
> mostly what you tend to be doing is just  one thing at a time and so
> linear code with callbacks works pretty well
>

Yeah, you say that, but virtually all my experience is based upon a
multitasking OS: VMS, Unix, Windows NT, Linux. I can't remember stuff I
did in the early 1980s. I have a huge store of experience, intuition, in
the multitasking Posix like world, none in single process.

I'm a little paranoid, pessimistic, I think the world is out to mess me
up. If things can go wrong, they will go wrong, which is why I'm
unwilling to step into such a different paradigm.

On 29/03/2024 13:14, Pancho wrote:
> On 29/03/2024 10:49, The Natural Philosopher wrote:
>> On 29/03/2024 00:52, Pancho wrote:
>>> On 27/03/2024 10:13, The Natural Philosopher wrote:
>>>> On 26/03/2024 21:58, Pancho wrote:
>>>>> On 25/03/2024 15:57, The Natural Philosopher wrote:
>>>>>> On 25/03/2024 11:31, Pancho wrote:
>>>>>>> On 24/03/2024 11:13, The Natural Philosopher wrote:
>>>>>>>
>>>>>>>> However on trawling the internet I discovered a conversation
>>>>>>>> with someone else *on here* (c.s.r-pi) last year, who was
>>>>>>>> finding that *sleep_us(x)* was highly inconsistent for certain
>>>>>>>> (small) values of x. Sometimes taking a day to end.
>>>>>>>>
>>>>>>>> Further investigation reveals that in fact it really is a
>>>>>>>> 'sleep' with the processor being put in low power mode and
>>>>>>>> requiring an interrupt to 'wake it up'.
>>>>>>>>
>>>>>>>
>>>>>>> Why not use threads/timers, wait on a lock/semaphore rather than
>>>>>>> sleep.
>>>>>>>
>>>>>> Good point Pancho, but I was really looking for the simplest code
>>>>>> possible.  Interrupts can be tricky things on a platform whose
>>>>>> architecture you do not understand completely. In any case it was
>>>>>> a learnning curve I preferred not to negotiate if i didnt need to
>>>>>>
>>>>>
>>>>> A timer isn't complicated, just a call back routine, and a
>>>>> semaphore. Interrupts are something an OS does, not me :o). I hate
>>>>> multithread code, but async handling of an external resource is one
>>>>> of the two main places I would use another thread.
>>>>>
>>>>> I had a look at your code, it looks extraordinarily like a python
>>>>> example on Tom's hardware.
>>>>>
>>>> Oh. The manufacturers sample code is the source of ALL the
>>>> 'examples' that other people publish as their own., I am just being
>>>> honest :-)
>>>>
>>>>> I'm not clear how many times it is succeeding vs failing, but I
>>>>> suspect you really need to bite the bullet and introduce
>>>>> timeouts/error handling, if it fails try again, average out
>>>>> multiple results. i.e. accept it as flawed and that results are
>>>>> statistical, like GPS.
>>>>>
>>>> Well the averaging out will happen anyway at the server side. I make
>>>> the clients as simple as possible for resilience. In practice oil
>>>> levels only change quickly if you have had the oil stolen overnight
>>>> or if a supplier has filled the tank up, so gross deviations can
>>>> have code exceptions, the rest would be the running average of maybe
>>>> 20 samples.
>>>> BUT it isn't inaccuracy that worries me per se, it's that it may be
>>>> an indication of underlying timing issues.
>>>>
>>>>> In many ways the resilience code will be simple, because it is just
>>>>> normal code, rather than cargo culting a novel ultrasonic device.
>>>>>
>>>> In fact the code in either case is simple.
>>>>
>>>
>>>
>>> I understood the idea of a ping delay time. It is just my experience
>>> that things rarely work exactly as I expect them to.
>>>
>>> FWIW, I'd also massively underestimated the difficulty of coding the
>>> PICO, I'd assumed it was running a multitasking OS, like busybox, but
>>> I see it isn't. I guess there are a whole bunch of gotchas there too.
>>>
>>>> It is:  send a 10µs pulse to the unit, wait for the echo pulse start
>>>> , get the time, wait for the echo pulse end, get the time, subtract
>>>> the difference.
>>>>
>>>
>>> I'm unclear on terms, but that sounds like the length of the pulse,
>>> 10µs. Not the distance travelled by the pulse. Surely, you should be
>>> measuring the time between sending the pulse and receiving the pulse.
>>> I've probably misunderstood something, if the code is giving a
>>> sensible distance.
>>>
>> No.
>> Maybe ascii art will help
>>
>> CONTROL=10µs
>> ____| |________
>>
>> RETURN = wahatever
>> _____|^^^^^^^^^^^^|____________
>>
>
> Yeah, I know what a ping is supposed to do. It is the time interval
> between sending a ping and receiving the echo, simples. But... that
> isn't what your code looks like.
>
> You have:
>
>  while(!gpio_get(ULTRASONIC_IN));
>     //read clock and store
>     start=get_absolute_time ();
>
> Which is presumably waiting for silence, no echo, it might work if that
> is the default start state, i.e. if it does nothing, but it is
> redundant. You should start the time interval when the ping is sent.
>
That is what the code does. You send a trigger pulse,. The board farts
around, waits, sets its output high to mark the pulse start, and then
low when it ends

That code is waiting for the pulse to *start*

> A short pulse always fails? I wasn't clear if it just made it more
> vulnerable to failure. Failure caused by something else? Maybe
> wavelength? Interference. I really don't know. I don't know how you can
> rule stuff out. Apart from empirically, test reliability, in which case
> you need to record failure stats as well as success.
>
The shorter pulses failed *sometimes*, the longer ones never did.

New code is in and it hasn't failed yet...

static float get_distance()
{
int i;
absolute_time_t start;
absolute_time_t end;
static int64_t us_delay;
//set output pin high
gpio_put(ULTRASONIC_OUT,1);
busy_wait_us(10); //sleep_us() possibly unreliable here
gpio_put(ULTRASONIC_OUT,0); //reset the input
// wait for echo pulse start
for (i=0;i<100000;i++)
{
if(gpio_get(ULTRASONIC_IN)) //pulse start
{
//read clock and store
start=get_absolute_time ();
//wait for echo pin to go low;
while(gpio_get(ULTRASONIC_IN))
;
end=get_absolute_time ();
//get clock difference
us_delay=absolute_time_diff_us(start,end);
//convert to float and return it as cm
return (((float)(us_delay))*0.034/2);
}
}
//we ran out of time here.
return(0.0);
}

>> You can get some sort of Free BSD RTOS port to a Pico, but in fact
>> mostly what you tend to be doing is just  one thing at a time and so
>> linear code with callbacks works pretty well
>>
>
> Yeah, you say that, but virtually all my experience is based upon a
> multitasking OS: VMS, Unix, Windows NT, Linux. I can't remember stuff I
> did in the early 1980s. I have a huge store of experience, intuition, in
> the multitasking Posix like world, none in single process.
>
Well I cut my teeth on assembler on Z80s and 8080s and bare metal
programming LONG before Unix was part of my knowledge

> I'm a little paranoid, pessimistic, I think the world is out to mess me
> up. If things can go wrong, they will go wrong, which is why I'm
> unwilling to step into such a different paradigm.
>
It's like going back to the days spent messing around in BASIC on 6800
kits my friend had built.

Its just another way of doing stuff. Like a coder friend once said 'it's
all just bits, in silicon'

:-)
>
>

--
In theory, there is no difference between theory and practice.
In practice, there is.
-- Yogi Berra

On 2024-03-25, The Natural Philosopher <tnp@invalid.invalid> wrote:
>
> I have noticed that with absoluteley no change in sensor location I get
> up to ± 0.5cm variation in delay.

Sounds reasonable (or even quite good) for such a cheap sensor. Does yours
come with a datasheet that specifies accuracy limits?

The datasheet on the Sparkfun website claims "the ranging accuracy can reach
to 3mm", but does not give any guaranteed limits - and I believe there are
lots of clone parts thay may be even worse.

cu
Michael
--
Some people have no respect of age unless it is bottled.

On 29/03/2024 15:02, Michael Schwingen wrote:
> On 2024-03-25, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>
>> I have noticed that with absoluteley no change in sensor location I get
>> up to ± 0.5cm variation in delay.
>
> Sounds reasonable (or even quite good) for such a cheap sensor. Does yours
> come with a datasheet that specifies accuracy limits?
>
It *is* the Sparkfun module.

> The datasheet on the Sparkfun website claims "the ranging accuracy can reach
> to 3mm", but does not give any guaranteed limits - and I believe there are
> lots of clone parts that may be even worse.

In general I am getting *repeatibility* now to a lot less than that, and
it has been known, (pointed out of the window) to detect large objects
at many many metres.

It is certainly more than good enough for measuring from 0-1.5 metres or
so. to a sorta 10% accuracy.

--
"And if the blind lead the blind, both shall fall into the ditch".

Gospel of St. Mathew 15:14

On 29/03/2024 00:52, Pancho wrote:
> FWIW, I'd also massively underestimated the difficulty of coding the
> PICO, I'd assumed it was running a multitasking OS, like busybox, but I
> see it isn't. I guess there are a whole bunch of gotchas there too.

With a single core things might get tricky, but the PICO has dual cores.
So you can run code on one core that just sits in a tight loop taking
measurements if you need to, and the other core can take care of
everything else, such as comms with the outside world.

---druck

On Fri, 29 Mar 2024 10:49:13 +0000, in <uu66b9$83pi$3@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> wrote:

>Maybe ascii art will help
>
>CONTROL=10µs
>____| |________
>
>RETURN = wahatever
>_____|^^^^^^^^^^^^|____________
>

Assuming my bleary-eyed math is correct, 10µs is the length of one
cycle of ultrasound at 100,000 Hz.

So what frequency is your ultrasound? Maybe some ASCII art - to scale
- of the waveform going down and back will reveal something.

I admit total ignorance to whether your devices can send sound and
receive at the same time, etc, etc, so this is my last potentially
annoying input. Good luck.

Spent many an evening with Z-80 assembler back in the late 70s. Good
times.

--
Jim H

On 30/03/2024 02:04, Jim H wrote:
> On Fri, 29 Mar 2024 10:49:13 +0000, in <uu66b9$83pi$3@dont-email.me>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> Maybe ascii art will help
>>
>> CONTROL=10µs
>> ____| |________
>>
>> RETURN = wahatever
>> _____|^^^^^^^^^^^^|____________
>>
>
> Assuming my bleary-eyed math is correct, 10µs is the length of one
> cycle of ultrasound at 100,000 Hz.
>
The width of that pulse is pretty much immaterial - its only a digital
trigger, It doesn't send anything directly.

The unit does that, and senses a high to the output. Then it transmits a
squawk., When it receives an echo it switches that to low.

Its a smart device .

https://cdn.sparkfun.com/datasheets/Sensors/Proximity/HCSR04.pdf

> So what frequency is your ultrasound? Maybe some ASCII art - to scale
> - of the waveform going down and back will reveal something.
>
40Khz allegedly. see datasheet

> I admit total ignorance to whether your devices can send sound and
> receive at the same time, etc, etc, so this is my last potentially
> annoying input. Good luck.
>
Ive no idea either, Its got two things that might be transducers,

> Spent many an evening with Z-80 assembler back in the late 70s. Good
> times.
>
Yes. I finally connected the dots between hardware and higher level
languages

Anyway the unit now appears to be stable, i've watched it fail to
connect, and recover, I've watched it detect it had lost wifi and
reconnect after that, and it hasn't crashed or locked up yet, so I think
that's as far as the code needs to go right now.

Next step is to concert to battery and check if the battery saver works,
and see how long it lasts on batterries

--
"An intellectual is a person knowledgeable in one field who speaks out
only in others...”

Tom Wolfe

On 30/03/2024 09:17, The Natural Philosopher wrote:
> On 30/03/2024 02:04, Jim H wrote:
>> On Fri, 29 Mar 2024 10:49:13 +0000, in <uu66b9$83pi$3@dont-email.me>,
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>
>>> Maybe ascii art will help
>>>
>>> CONTROL=10µs
>>> ____| |________
>>>
>>> RETURN = wahatever
>>> _____|^^^^^^^^^^^^|____________
>>>
>>
>> Assuming my bleary-eyed math is correct, 10µs is the length of one
>> cycle of ultrasound at 100,000 Hz.
>>
> The width of that pulse is pretty much immaterial - its only a digital
> trigger, It doesn't send anything directly.
>
> The unit does that, and senses a high to the output. Then it transmits a
> squawk., When it receives an echo it switches that to low.
>
> Its a smart device .
>

I think that is the part I was missing. I assumed it was like an analog
device, out pin was for send and the in pin signalled it was receiving.

On reflection, the code makes sense if it is a smart device. The in pin
just goes high (or low) for the period between sending and receiving a
few micro seconds of the echo.

> https://cdn.sparkfun.com/datasheets/Sensors/Proximity/HCSR04.pdf
>

Not the most precise wording.

Having taken the trouble to understand. I might buy one to tell me if my
garage door is open. Buy an echo device that is, not a PICO.

On 30/03/2024 16:26, Pancho wrote:
> On 30/03/2024 09:17, The Natural Philosopher wrote:
>> On 30/03/2024 02:04, Jim H wrote:
>>> On Fri, 29 Mar 2024 10:49:13 +0000, in <uu66b9$83pi$3@dont-email.me>,
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>
>>>> Maybe ascii art will help
>>>>
>>>> CONTROL=10µs
>>>> ____| |________
>>>>
>>>> RETURN = wahatever
>>>> _____|^^^^^^^^^^^^|____________
>>>>
>>>
>>> Assuming my bleary-eyed math is correct, 10µs is the length of one
>>> cycle of ultrasound at 100,000 Hz.
>>>
>> The width of that pulse is pretty much immaterial - its only a digital
>> trigger, It doesn't send anything directly.
>>
>> The unit does that, and senses a high to the output. Then it transmits
>> a squawk., When it receives an echo it switches that to low.
>>
>> Its a smart device .
>>
>
> I think that is the part I was missing. I assumed it was like an analog
> device, out pin was for send  and the in pin signalled it was receiving.
>
> On reflection, the code makes sense if it is a smart device. The in pin
> just goes high (or low) for the period between sending and receiving a
> few micro seconds of the echo.
>
>
>> https://cdn.sparkfun.com/datasheets/Sensors/Proximity/HCSR04.pdf
>>
>
> Not the most precise wording.
>
> Having taken the trouble to understand. I might buy one to tell me if my
> garage door is open. Buy an echo device that is, not a PICO.
>
>
Well hook it to a pico and tell a server via wifi that the door
is/isn't open!

It seems reiable so far.

Now running of 3 dry cells to see at what point the voltage gets too low
for reliable pinging.

--
Canada is all right really, though not for the whole weekend.

"Saki"