INTL 3:770/1 3:770/3
REPLYADDR tnp@invalid.invalid
REPLYTO 3:770/3.0 UUCP
MSGID: fd965774
REPLY: 8e086bd7
PID: SoupGate-Win32 v1.05
On 26/03/2024 17:33, Jim H wrote:
> On Mon, 25 Mar 2024 15:57:25 +0000, in ,
> 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
>>
>>> 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)
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
|
