INTL 3:770/1 3:770/3
REPLYADDR Pancho.Jones@proton.me
REPLYTO 3:770/3.0 UUCP
MSGID: a6ce2c63
REPLY: bd771217
PID: SoupGate-Win32 v1.05
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)
SEEN-BY: 15/0 19/38 90/1 105/81 106/201 128/260 129/305 135/225 153/757
SEEN-BY: 153/7715 218/700 840 220/70 226/17 30 100 227/114 229/110
SEEN-BY: 229/111 112 113 200 206 307 317 400 426 428 470 550 616 664
SEEN-BY: 229/700 266/512 267/800 282/1038 291/111 292/854 310/31 320/219
SEEN-BY: 322/757 342/200 396/45 460/58 633/280 281 412 418 420 509
SEEN-BY: 633/2744 712/848 770/1 3 100 330 340 772/210 220 230 5020/400
SEEN-BY: 5075/35
PATH: 770/3 1 633/280 229/426
|
