• Need help with PI PICO...

    From The Natural Philosopher@3:770/3 to All on Sat Mar 23 17:45:04 2024
    Ok, this is the one destined to be an oil level sensor and I have been
    working on getting a stable TCP/IP and Wi-Fi stack, which seems to have
    been achieved, as its talking reliably, albeit with delay, to my most
    remote Wi-Fi AP at a signal level generally around -87dbM.
    That is not, however the problem (although I thought it was). The
    problem seems to be that very very occasionally and as far as I can tell *completely randomly*, it fails to return from the function listed
    below. Cargo culted from the module manufacturers application notes

    This is for the ultrasonic transducer module.
    When it fails, all GPIO pins to and from the transducer module measure LOW.

    static float get_distance()
    {
    int i;
    absolute_time_t start;
    absolute_time_t end;
    static int64_t us_delay;
    gpio_put(ULTRASONIC_OUT,0);
    sleep_us(2);
    //set output pin high
    gpio_put(ULTRASONIC_OUT,1);
    sleep_us(10);
    gpio_put(ULTRASONIC_OUT,0); //reset the input
    // wait for echo pulse start
    while(!gpio_get(ULTRASONIC_IN))
    ;
    //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);
    }

    It would seem from the pin states that it gets permanently stuck in

    while(!gpio_get(ULTRASONIC_IN))
    ;

    Which as understand it is waiting for the module (HCSR04) to *start* to
    send a pulse.

    Now obviously infinite loops with no termination condition under fault conditions are poor code, but I am leaving it there until I understand
    why the code is in fact hanging.
    Someone online suggested that asynchronous interrupts may be the issue,
    but I cant see why or what interrupts to disable.

    Can anyone cast any light on this one?

    Or suggest a bug hunting methodology?

    --
    “The fundamental cause of the trouble in the modern world today is that
    the stupid are cocksure while the intelligent are full of doubt."

    - Bertrand Russell

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Sat Mar 23 18:37:22 2024
    On Sat, 23 Mar 2024 17:45:05 +0000
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    It would seem from the pin states that it gets permanently stuck in


    while(!gpio_get(ULTRASONIC_IN))
    ;

    Can anyone cast any light on this one?

    Or suggest a bug hunting methodology?

    Assuming you have access to the source of gpio_get() instrument the inside of it with tracers (I'd use printf if there's anything listening to stdout - otherwise find somewhere to put breadcrumbs that you can see in
    real time (in ancient times I'd just watch the blinkenlights). Wait for it
    to lock up and see what it's doing.

    Alternatively run it under strace or similar and wait for it to
    lock up or wait for it to lock up and attach gdb (you'll want to compile
    with -g for that).

    There's three - hopefully one of them will shed some light.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sat Mar 23 22:20:34 2024
    On 23/03/2024 18:37, Ahem A Rivet's Shot wrote:
    On Sat, 23 Mar 2024 17:45:05 +0000
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    It would seem from the pin states that it gets permanently stuck in


    while(!gpio_get(ULTRASONIC_IN))
    ;

    Can anyone cast any light on this one?

    Or suggest a bug hunting methodology?

    Assuming you have access to the source of gpio_get() instrument the inside of it with tracers (I'd use printf if there's anything listening to stdout - otherwise find somewhere to put breadcrumbs that you can see in
    real time (in ancient times I'd just watch the blinkenlights). Wait for it
    to lock up and see what it's doing.

    Well I did. That's how I got this far.
    I know it enters the routine, but never leaves, and the lack of GPIO
    voltage suggest it is being stuck where it is.

    My choice tree is between the GPIO out signal never being received by
    the ultrasonic module, or the GPIO in signal is being missed by the Pi
    PICO on account of possibly some interrupt masking its appearance until
    it is too late and its gone low again.


    Alternatively run it under strace or similar and wait for it to
    lock up or wait for it to lock up and attach gdb (you'll want to compile
    with -g for that).

    AIUI those are linux tools.

    We are running bare metal-ish here.
    Back in the day I would have used a chip emulator with hardware break
    points.
    And a cost of hundreds of thousands.

    There's three - hopefully one of them will shed some light.


    It's odd, it may be something to do with short ultrasonic distances. I
    have the PCB just lolling around on the desk, and facing a wall a few
    inches away seemed to make it crash moire predictably

    --
    “Puritanism: The haunting fear that someone, somewhere, may be happy.”

    H.L. Mencken, A Mencken Chrestomathy

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Sun Mar 24 07:23:46 2024
    On Sat, 23 Mar 2024 22:20:34 +0000
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 23/03/2024 18:37, Ahem A Rivet's Shot wrote:

    Assuming you have access to the source of gpio_get() instrument
    the inside of it with tracers (I'd use printf if there's anything
    listening to stdout - otherwise find somewhere to put breadcrumbs that
    you can see in real time (in ancient times I'd just watch the blinkenlights). Wait for it to lock up and see what it's doing.

    Well I did. That's how I got this far.

    Instrument /Inside/ gpio_get().

    I know it enters the routine, but never leaves, and the lack of GPIO
    voltage suggest it is being stuck where it is.

    Right so the next step is the inside of the routine.

    Alternatively run it under strace or similar and wait for it to
    lock up or wait for it to lock up and attach gdb (you'll want to compile with -g for that).

    AIUI those are linux tools.

    Unix tools but yes.

    We are running bare metal-ish here.

    Ah - no way to attach a debugger via the SDK ?

    Back in the day I would have used a chip emulator with hardware break
    points.

    An ICE is always nice if someone else is paying :)

    It's odd, it may be something to do with short ultrasonic distances. I
    have the PCB just lolling around on the desk, and facing a wall a few
    inches away seemed to make it crash moire predictably

    Hmm is there a minimum range spec ?

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to The Natural Philosopher on Sun Mar 24 09:39:30 2024
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    It would seem from the pin states that it gets permanently stuck in

    while(!gpio_get(ULTRASONIC_IN))
    ;

    Which as understand it is waiting for the module (HCSR04) to *start* to
    send a pulse.

    Can you scope it to see if the module is actually sending a pulse?

    Is the pulse perhaps too short for the Pico to detect? eg if the loop or gpio_get() function took some time, it could be the signal goes 0-1-0 in the middle of a loop iteration and so the gpio_get() never sees it go 1.

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sun Mar 24 11:13:24 2024
    On 24/03/2024 07:23, Ahem A Rivet's Shot wrote:
    On Sat, 23 Mar 2024 22:20:34 +0000
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 23/03/2024 18:37, Ahem A Rivet's Shot wrote:

    Assuming you have access to the source of gpio_get() instrument
    the inside of it with tracers (I'd use printf if there's anything
    listening to stdout - otherwise find somewhere to put breadcrumbs that
    you can see in real time (in ancient times I'd just watch the
    blinkenlights). Wait for it to lock up and see what it's doing.

    Well I did. That's how I got this far.

    Instrument /Inside/ gpio_get().
    gpio_get (X) for presumably memory mapped IO is going to be little more
    than
    return (iobase & (1<<X ) ? 1:0);

    However I found something i had forgotten...

    I know it enters the routine, but never leaves, and the lack of GPIO
    voltage suggest it is being stuck where it is.

    Right so the next step is the inside of the routine.

    Alternatively run it under strace or similar and wait for it to
    lock up or wait for it to lock up and attach gdb (you'll want to compile >>> with -g for that).

    AIUI those are linux tools.

    Unix tools but yes.

    We are running bare metal-ish here.

    Ah - no way to attach a debugger via the SDK ?

    There may be but it would be more complex.

    Back in the day I would have used a chip emulator with hardware break
    points.

    An ICE is always nice if someone else is paying :)

    Precisely!

    It's odd, it may be something to do with short ultrasonic distances. I
    have the PCB just lolling around on the desk, and facing a wall a few
    inches away seemed to make it crash moire predictably

    Hmm is there a minimum range spec ?

    Not really in practical terms.

    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'.

    I haven't thought it through, but it could be that too long a delay in
    some sense might miss a complete set of send and return pulses, leaving
    the thing stuck. Especially on a very short range echo.

    So last night instead of leaving it facing a wall, I left it facing the opposite wall, and it's still blinken away...

    There is an alternative to sleep_us, that simply involves a tight
    processor loop watching the clock, that might work better for these very
    small delays.

    I am going to do a statistical test on both methods at long and short
    ranges.

    (Fortunately, I managed to remove the existing radio sensor from the oil
    tank and on shaking, could hear water sloshing around inside. After
    emptying out and drying n the oven, it started working again. I don't
    think +60°C made it very accurate as it then showed a full tank, but it
    seems to have settled down to a figure consistent with what a dipstick
    shows. So there is no urgency to get the replacement PI sensor working:-)

    I am getting to really love these little PICOS, but there are a lot of
    quirks and bugs in the hardware and software.

    Thank's for your input.


    --
    “A leader is best When people barely know he exists. Of a good leader,
    who talks little,When his work is done, his aim fulfilled,They will say,
    “We did this ourselves.”

    ― Lao Tzu, Tao Te Ching

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Theo on Sun Mar 24 11:43:26 2024
    On 24/03/2024 09:39, Theo wrote:
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    It would seem from the pin states that it gets permanently stuck in

    while(!gpio_get(ULTRASONIC_IN))
    ;

    Which as understand it is waiting for the module (HCSR04) to *start* to
    send a pulse.

    Can you scope it to see if the module is actually sending a pulse?

    I could, but in fact it was easier to simply look at it in 'stuck' mode
    with a DVM.

    Is the pulse perhaps too short for the Pico to detect? eg if the loop or gpio_get() function took some time, it could be the signal goes 0-1-0 in the middle of a loop iteration and so the gpio_get() never sees it go 1.

    As you can see from my last reply that is roughly where I am headed. Or similar. Lacking full ICE., its all a bit 'poke the black box with
    different sized sticks, and try and infer from what it does, what is
    happening inside it'

    I think this must be where it sticks, because this is the only infinite
    loop with both input and output to the module in a low state, which is
    what I measured:

    gpio_put(ULTRASONIC_OUT,1);
    sleep_us(10);
    gpio_put(ULTRASONIC_OUT,0); //reset the input
    // wait for echo pulse start
    while(!gpio_get(ULTRASONIC_IN))
    ;

    I.e that it (allegedly) sends a 10µs wide high pulse, and then waits for
    that to trigger a response from the unit, but that response never happens.

    However that should not vary with the echo *delay*, and a longer target distance seems to improve things..

    ...unless, thinking a bit more, the pulse is so short it comes *and*
    goes inside that loop, as you suggested.. it certainly should *not* be,
    as even on a few cm of target distance, its hundreds of microseconds (i
    make it 58µs per cm roughly)

    Theo

    --
    “It is dangerous to be right in matters on which the established
    authorities are wrong.”

    ― Voltaire, The Age of Louis XIV

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Michael Schwingen@3:770/3 to The Natural Philosopher on Sun Mar 24 13:31:48 2024
    On 2024-03-23, The Natural Philosopher <tnp@invalid.invalid> wrote:
    My choice tree is between the GPIO out signal never being received by
    the ultrasonic module, or the GPIO in signal is being missed by the Pi
    PICO on account of possibly some interrupt masking its appearance until
    it is too late and its gone low again.

    Or there never is a signal on the module output. You should write your code
    to cope with such problems - sample code/libraries often skips the error handling, but that does not mean *you* can if you want reliable operation.

    Hook up an oscilloscope or logic analyzer to check what is the case. A
    cheap 8-channel USB logic analyzer is a great tool to have around when
    working bare metal:

    https://www.aliexpress.com/item/1005005993277484.html

    Using the Saleae software on these is *not* allowed by the license, but sigrok/pulseview work great:

    https://sigrok.org/

    We are running bare metal-ish here.
    Back in the day I would have used a chip emulator with hardware break
    points.
    And a cost of hundreds of thousands.

    Nowadays, you would use a SWD debugger, since the debug/emulation logic is already integrated in the RP2040!

    Something like the JTAG Hat on a Raspberry PI:

    https://www.schwingen.org/jtag-hat/

    or any SWD probe supported by OpenOCD (FTDI, CMSIS-DAP work fine), like the Raspberry Pi Debug Probe (which works for the RP2040, but lacks reset
    signals and support for voltages other than 3.3V):

    https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html

    That sets you back about 20€, and gives you instant breakpoint/single step operation with full view of registers and memory contents.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Michael Schwingen@3:770/3 to The Natural Philosopher on Sun Mar 24 13:36:38 2024
    On 2024-03-24, The Natural Philosopher <tnp@invalid.invalid> wrote:

    ...unless, thinking a bit more, the pulse is so short it comes *and*
    goes inside that loop, as you suggested.. it certainly should *not* be,
    as even on a few cm of target distance, its hundreds of microseconds (i
    make it 58µs per cm roughly)

    Start a hardware timer when sending the pulse, and set up an interrupt on
    the input with the return pulse. In the interrupt handler, read the timer
    value and set a flag for the main routine that the measurement is complete.

    If you add a timer interrupt to periodically send the start pulse, the whole measurement operation runs in parallel to whatever the main program is
    doing, without blocking anything.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to The Natural Philosopher on Sun Mar 24 14:45:58 2024
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    As you can see from my last reply that is roughly where I am headed. Or similar. Lacking full ICE., its all a bit 'poke the black box with
    different sized sticks, and try and infer from what it does, what is happening inside it'

    One of the challenges with embedded debugging is that printf can be a very
    slow thing, because it's spitting out characters on a slow UART. Adding
    printfs can thus screw up timing.

    Other techniques include writing things to memory you pick up later (don't forget that string handling and especially sprintf formatting can be slow)
    and wiggling GPIOs (eg output a different number in each stage of the
    program).

    sigrok is logic analyser software that works with cheap (<$10) capture
    hardware - seems it can now use a Pi Pico for that as well.

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to The Natural Philosopher on Mon Mar 25 11:31:16 2024
    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.

    But looking at PICO code samples, they commonly use sleep, so I'd be
    surprised if it was that bad.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Pancho on Mon Mar 25 15:57:24 2024
    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

    But looking at PICO code samples, they commonly use sleep, so I'd be surprised if it was that bad.

    I am veering away from that explanation, as with the test board located
    at some distance from any target, the problem has not reappeared.

    I am beginning to think that it may be possible for the echo pulse to
    'come *and* go' before the high level PICO code has got round to
    actually looking for it in the first place.

    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.

    It is also not clear from the documentation whether it is the low to
    high, or the high to low sequence, that triggers the ultrasonic board.

    If it is low to high, then there is an opportunity for an occasional
    very long delay in the

    sleep_us(10);

    to delay resetting the pulse until Elvis has left the building,. so to
    speak...

    So I have tow things to do. Understand how the ES module works in terms
    of timings, and replace that sleep_us with a different delay mechanism.
    It's now been 24 hours with no lockup with a distant target...

    OIL-SENSOR
    OIL-TANK
    -85dBm
    57.60cm
    23.7°C
    4.6V

    I have noticed that with absoluteley no change in sensor location I get
    up to ± 0.5cm variation in delay.

    --
    If I had all the money I've spent on drink...
    ..I'd spend it on drink.

    Sir Henry (at Rawlinson's End)

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim H@3:770/3 to The Natural Philosopher on Tue Mar 26 17:33:50 2024
    On Mon, 25 Mar 2024 15:57:25 +0000, in <uts6t5$163q2$1@dont-email.me>,
    The Natural Philosopher <tnp@invalid.invalid> 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

    But looking at PICO code samples, they commonly use sleep, so I'd be
    surprised if it was that bad.

    I am veering away from that explanation, as with the test board located
    at some distance from any target, the problem has not reappeared.

    I am beginning to think that it may be possible for the echo pulse to
    'come *and* go' before the high level PICO code has got round to
    actually looking for it in the first place.

    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.

    It is also not clear from the documentation whether it is the low to
    high, or the high to low sequence, that triggers the ultrasonic board.

    If it is low to high, then there is an opportunity for an occasional
    very long delay in the

    sleep_us(10);

    to delay resetting the pulse until Elvis has left the building,. so to >speak...

    So I have tow things to do. Understand how the ES module works in terms
    of timings, and replace that sleep_us with a different delay mechanism.
    It's now been 24 hours with no lockup with a distant target...

    OIL-SENSOR
    OIL-TANK
    -85dBm
    57.60cm
    23.7C
    4.6V

    I have noticed that with absoluteley no change in sensor location I get
    up to 0.5cm variation in delay.

    Assuming the "oil" you're talking about is kerosene/heating fuel, the
    speed of sound is 1330 m/sec so 0.5cm takes 3.76 micro-sec. I don't
    know the specs for the PICO, but perhaps comparing that to the time it
    takes to execute your code will give you an answer. I'd guess
    (emphasis on guess) that +/- 0.5 cm is doing fairly well.

    --
    Jim H

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Jim H on Tue Mar 26 18:00:16 2024
    On 26/03/2024 17:33, Jim H wrote:
    On Mon, 25 Mar 2024 15:57:25 +0000, in <uts6t5$163q2$1@dont-email.me>,
    The Natural Philosopher <tnp@invalid.invalid> 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

    But looking at PICO code samples, they commonly use sleep, so I'd be
    surprised if it was that bad.

    I am veering away from that explanation, as with the test board located
    at some distance from any target, the problem has not reappeared.

    I am beginning to think that it may be possible for the echo pulse to
    'come *and* go' before the high level PICO code has got round to
    actually looking for it in the first place.

    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.

    It is also not clear from the documentation whether it is the low to
    high, or the high to low sequence, that triggers the ultrasonic board.

    If it is low to high, then there is an opportunity for an occasional
    very long delay in the

    sleep_us(10);

    to delay resetting the pulse until Elvis has left the building,. so to
    speak...

    So I have tow things to do. Understand how the ES module works in terms
    of timings, and replace that sleep_us with a different delay mechanism.
    It's now been 24 hours with no lockup with a distant target...

    OIL-SENSOR
    OIL-TANK
    -85dBm
    57.60cm
    23.7°C
    4.6V

    I have noticed that with absoluteley no change in sensor location I get
    up to ± 0.5cm variation in delay.

    Assuming the "oil" you're talking about is kerosene/heating fuel, the
    speed of sound is 1330 m/sec so 0.5cm takes 3.76 micro-sec. I don't
    know the specs for the PICO, but perhaps comparing that to the time it
    takes to execute your code will give you an answer. I'd guess
    (emphasis on guess) that +/- 0.5 cm is doing fairly well.


    Oh the sensor is above the oil. Its just an electronic dipstick -
    measures distance to the oil surface.

    It did over a full 30 hours on long delays. Ive modded the code
    *slightly* and put it back on uber short delays.
    So far so good...


    --
    "What do you think about Gay Marriage?"
    "I don't."
    "Don't what?"
    "Think about Gay Marriage."

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Jim H on Tue Mar 26 18:16:22 2024
    On Tue, 26 Mar 2024 17:33:50 +0000
    Jim H <invalid@invalid.invalid> wrote:

    Assuming the "oil" you're talking about is kerosene/heating fuel, the
    speed of sound is 1330 m/sec so 0.5cm takes 3.76 micro-sec.

    I would have thought it's measuring the distance to the surface of
    the oil from above the oil so it would be the speed of sound in air that matters 300m/s.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Tue Mar 26 18:50:46 2024
    On 26/03/2024 18:16, Ahem A Rivet's Shot wrote:
    On Tue, 26 Mar 2024 17:33:50 +0000
    Jim H <invalid@invalid.invalid> wrote:

    Assuming the "oil" you're talking about is kerosene/heating fuel, the
    speed of sound is 1330 m/sec so 0.5cm takes 3.76 micro-sec.

    I would have thought it's measuring the distance to the surface of
    the oil from above the oil so it would be the speed of sound in air that matters 300m/s.

    Correct, Mrs Shot.
    Anyway it's died within 30 minutes of going back on 'short echo'...
    So its definitely sensitive to that in some way.

    I'll add more debug code tomorrow

    --
    When plunder becomes a way of life for a group of men in a society, over
    the course of time they create for themselves a legal system that
    authorizes it and a moral code that glorifies it.

    Frédéric Bastiat

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Higton@3:770/3 to The Natural Philosopher on Tue Mar 26 19:16:36 2024
    In message <utv5e7$29onh$2@dont-email.me>
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 26/03/2024 18:16, Ahem A Rivet's Shot wrote:
    On Tue, 26 Mar 2024 17:33:50 +0000 Jim H <invalid@invalid.invalid> wrote:

    Assuming the "oil" you're talking about is kerosene/heating fuel, the speed of sound is 1330 m/sec so 0.5cm takes 3.76 micro-sec.

    I would have thought it's measuring the distance to the surface of
    the oil from above the oil so it would be the speed of sound in air that matters 300m/s.

    Correct, Mrs Shot. Anyway it's died within 30 minutes of going back on
    'short echo'... So its definitely sensitive to that in some way.

    I'll add more debug code tomorrow

    Are you sure the sensor isn't malfunctioning as a result of being in
    oil vapour?

    David

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to The Natural Philosopher on Tue Mar 26 21:58:08 2024
    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.

    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.

    In many ways the resilience code will be simple, because it is just
    normal code, rather than cargo culting a novel ultrasonic device.

    You can investigate further, by recording fail stats, as well as
    distance stats.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Pancho on Wed Mar 27 10:13:56 2024
    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.

    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.

    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.

    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...:-)

    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..

    --
    Civilization exists by geological consent, subject to change without notice.
    – Will Durant

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to David Higton on Wed Mar 27 09:56:42 2024
    On 26/03/2024 19:16, David Higton wrote:
    In message <utv5e7$29onh$2@dont-email.me>
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 26/03/2024 18:16, Ahem A Rivet's Shot wrote:
    On Tue, 26 Mar 2024 17:33:50 +0000 Jim H <invalid@invalid.invalid> wrote: >>>
    Assuming the "oil" you're talking about is kerosene/heating fuel, the
    speed of sound is 1330 m/sec so 0.5cm takes 3.76 micro-sec.

    I would have thought it's measuring the distance to the surface of
    the oil from above the oil so it would be the speed of sound in air that >>> matters 300m/s.

    Correct, Mrs Shot. Anyway it's died within 30 minutes of going back on
    'short echo'... So its definitely sensitive to that in some way.

    I'll add more debug code tomorrow

    Are you sure the sensor isn't malfunctioning as a result of being in
    oil vapour?

    Since it is operating on the desk in front of me, fairly sure :-)

    I haven't let it anywhere near the oil tank yet. The plan is to have it installed by the fall. ready for next winter.
    So it is being hammered to check for problems *before* it gets to a cold
    wet inaccessible oil tank.

    David

    --
    In todays liberal progressive conflict-free education system, everyone
    gets full Marx.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Higton@3:770/3 to The Natural Philosopher on Wed Mar 27 11:59:00 2024
    In message <uu0rh5$2pcls$1@dont-email.me>
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    I am slightly curious as to how the PICO could miss what is a several hundred microsecond wide pulse.

    AFAICS there are many pitfalls:

    1) An interrupt can be being serviced, so the pulse is over before you
    get to see it.

    2) If you're looking for a pulse, you should be looking edge triggered
    rather than level triggered, but even then you may not get to react to
    the edge immediately because of an interrupt being serviced, so you'd
    get an anomalous result.

    3) You can look level triggered, but you need to turn off all interrupts
    to ensure you really are loking at it in real time.

    4) I had a play with an ultrasonic ranger a couple of years or so ago.
    I couldn't understand why I wasn't getting any return pulses at all.
    I eventually realised that I was sending another start pulse before
    the current cycle had finished.

    Regardless, you need an escape from any and every potential infinite
    loop. Whatever you're doing.

    If you can use a hardware timer in the chip, that's a much more reliable solution.

    David

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to David Higton on Wed Mar 27 12:18:28 2024
    On 27/03/2024 11:59, David Higton wrote:
    In message <uu0rh5$2pcls$1@dont-email.me>
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    I am slightly curious as to how the PICO could miss what is a several
    hundred microsecond wide pulse.

    AFAICS there are many pitfalls:

    1) An interrupt can be being serviced, so the pulse is over before you
    get to see it.

    2) If you're looking for a pulse, you should be looking edge triggered
    rather than level triggered, but even then you may not get to react to
    the edge immediately because of an interrupt being serviced, so you'd
    get an anomalous result.

    3) You can look level triggered, but you need to turn off all interrupts
    to ensure you really are loking at it in real time.

    4) I had a play with an ultrasonic ranger a couple of years or so ago.
    I couldn't understand why I wasn't getting any return pulses at all.
    I eventually realised that I was sending another start pulse before
    the current cycle had finished.

    Regardless, you need an escape from any and every potential infinite
    loop. Whatever you're doing.

    If you can use a hardware timer in the chip, that's a much more reliable solution.

    David

    Thanks David

    All make sense.

    I think the next stage is to provide an escape from the infinite loops,
    that documents itself and see where its hanging.

    If interrupts are buggering it up, I am not sure how using an interrupt
    would not also be buffered up by an interrupt.

    The LWIP stack is all interrupt driven and I am loath to mess around for
    fear of breaking comms.

    In the end the pragmatic answer may be to simply abort a failed reading
    and try again.


    --
    In todays liberal progressive conflict-free education system, everyone
    gets full Marx.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Robert Riches@3:770/3 to The Natural Philosopher on Thu Mar 28 03:44:08 2024
    On 2024-03-27, The Natural Philosopher <tnp@invalid.invalid> wrote:
    On 26/03/2024 19:16, David Higton wrote:
    In message <utv5e7$29onh$2@dont-email.me>
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 26/03/2024 18:16, Ahem A Rivet's Shot wrote:
    On Tue, 26 Mar 2024 17:33:50 +0000 Jim H <invalid@invalid.invalid> wrote: >>>>
    Assuming the "oil" you're talking about is kerosene/heating fuel, the >>>>> speed of sound is 1330 m/sec so 0.5cm takes 3.76 micro-sec.

    I would have thought it's measuring the distance to the surface of
    the oil from above the oil so it would be the speed of sound in air that >>>> matters 300m/s.

    Correct, Mrs Shot. Anyway it's died within 30 minutes of going back on
    'short echo'... So its definitely sensitive to that in some way.

    I'll add more debug code tomorrow

    Are you sure the sensor isn't malfunctioning as a result of being in
    oil vapour?

    Since it is operating on the desk in front of me, fairly sure :-)

    I haven't let it anywhere near the oil tank yet. The plan is to have it installed by the fall. ready for next winter.
    So it is being hammered to check for problems *before* it gets to a cold
    wet inaccessible oil tank.

    On the off chance an alternative sensing architecture might be of
    some use: Instead of using sound to measure distance, have you
    considered possibly using fluid pressure to measure the height of
    the stack of liquid above a pressure sensor? If you put a
    pressure sensor near the bottom of the tank, and if the air space
    above the liquid is at atmospheric pressure, the gauge pressure
    reading will be directly proportional to the height of liquid
    above the sensor.

    For water, the pressure reading will be ~0.43 psi per foot of
    height. Oil is almost certainly less dense, so you might need a
    very sensitive pressure sensor--unless the tank is very large.

    Anyway, just in case you hadn't considered that idea...

    --
    Robert Riches
    spamtrap42@jacob21819.net
    (Yes, that is one of my email addresses.)

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Robert Riches on Thu Mar 28 07:07:52 2024
    On 28/03/2024 03:44, Robert Riches wrote:
    On 2024-03-27, The Natural Philosopher <tnp@invalid.invalid> wrote:
    On 26/03/2024 19:16, David Higton wrote:
    In message <utv5e7$29onh$2@dont-email.me>
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 26/03/2024 18:16, Ahem A Rivet's Shot wrote:
    On Tue, 26 Mar 2024 17:33:50 +0000 Jim H <invalid@invalid.invalid> wrote: >>>>>
    Assuming the "oil" you're talking about is kerosene/heating fuel, the >>>>>> speed of sound is 1330 m/sec so 0.5cm takes 3.76 micro-sec.

    I would have thought it's measuring the distance to the surface of >>>>> the oil from above the oil so it would be the speed of sound in air that >>>>> matters 300m/s.

    Correct, Mrs Shot. Anyway it's died within 30 minutes of going back on >>>> 'short echo'... So its definitely sensitive to that in some way.

    I'll add more debug code tomorrow

    Are you sure the sensor isn't malfunctioning as a result of being in
    oil vapour?

    Since it is operating on the desk in front of me, fairly sure :-)

    I haven't let it anywhere near the oil tank yet. The plan is to have it
    installed by the fall. ready for next winter.
    So it is being hammered to check for problems *before* it gets to a cold
    wet inaccessible oil tank.

    On the off chance an alternative sensing architecture might be of
    some use: Instead of using sound to measure distance, have you
    considered possibly using fluid pressure to measure the height of
    the stack of liquid above a pressure sensor? If you put a
    pressure sensor near the bottom of the tank, and if the air space
    above the liquid is at atmospheric pressure, the gauge pressure
    reading will be directly proportional to the height of liquid
    above the sensor.

    Never thought of that. Cute.

    For water, the pressure reading will be ~0.43 psi per foot of
    height. Oil is almost certainly less dense, so you might need a
    very sensitive pressure sensor--unless the tank is very large.

    Anyway, just in case you hadn't considered that idea...

    I hadn't.
    Actually it looks like this idea is going to work fine, I just need to
    zero in on what the problem actually is, and get some form or
    reliability at short range. The sensor appears to work at far greater
    distances than its rated for, so against an orthogonal flat oil surface
    it should be just fine

    I won't be able to get much done in the next few days so will attack the
    code again next week.

    --
    "It is an established fact to 97% confidence limits that left wing
    conspirators see right wing conspiracies everywhere"

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=C3=B6rn_Lundin?=@3:770/3 to The Natural Philosopher on Thu Mar 28 09:35:38 2024
    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?

    :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;
    }


    }

    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to The Natural Philosopher on Fri Mar 29 00:52:20 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Pancho on Fri Mar 29 10:49:12 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to The Natural Philosopher on Fri Mar 29 13:14:08 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Pancho on Fri Mar 29 13:37:08 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Michael Schwingen@3:770/3 to The Natural Philosopher on Fri Mar 29 15:02:34 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Michael Schwingen on Fri Mar 29 16:36:20 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Pancho on Fri Mar 29 18:16:08 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim H@3:770/3 to The Natural Philosopher on Sat Mar 30 02:04:48 2024
    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=10s
    ____| |________

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


    Assuming my bleary-eyed math is correct, 10s 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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Jim H on Sat Mar 30 09:17:46 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to The Natural Philosopher on Sat Mar 30 16:26:38 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Pancho on Sat Mar 30 18:17:14 2024
    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"

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)