INTL 3:770/1 3:770/3
REPLYADDR tnp@invalid.invalid
REPLYTO 3:770/3.0 UUCP
MSGID: cfe99e42
REPLY: a6ce2c63
PID: SoupGate-Win32 v1.05
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)
SEEN-BY: 10/0 1 15/0 90/1 103/705 105/81 106/201 128/260 129/305 135/225
SEEN-BY: 153/757 7715 218/0 1 601 700 840 870 930 220/70 221/1 6 226/17
SEEN-BY: 226/30 100 227/114 229/110 111 112 113 200 206 307 317 400
SEEN-BY: 229/426 428 470 550 616 664 700 240/1120 266/512 267/800
SEEN-BY: 282/1038 291/111 292/854 301/1 113 812 310/31 320/219 322/757
SEEN-BY: 335/364 341/66 342/200 396/45 460/58 633/280 712/848 770/1
SEEN-BY: 770/3 100 330 340 772/210 220 230 5020/400 1042 5058/104
SEEN-BY: 5075/35
PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426
|
