Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: The Natural Philosopher <tnp@invalid.invalid>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: Need help with PI PICO...
Date: Tue, 26 Mar 2024 18:00:17 +0000
Organization: A little, after lunch
Lines: 92
Message-ID: <utv2fh$291q6$1@dont-email.me>
References: <utn4f2$3p985$1@dont-email.me>
 <20240323183723.b2902fb94d75422b924c1bc7@eircom.net>
 <utnkjj$3t5m0$1@dont-email.me>
 <20240324072346.81064ff46570e669982a1f4e@eircom.net>
 <utp1sm$acjh$1@dont-email.me> <utrna6$113rn$3@dont-email.me>
 <uts6t5$163q2$1@dont-email.me> <ro060jlodkfoh36bjhed4m1ld8h6deuq1l@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 26 Mar 2024 18:00:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="17bc5b97482e918e14621b6ddccfdfc0";
	logging-data="2393926"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/bfv3eQs9Bd5mWN7BROeOl1Kx4CfdFKCA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:52TqymQ3T35GtYWOSdi0luSWXRk=
In-Reply-To: <ro060jlodkfoh36bjhed4m1ld8h6deuq1l@4ax.com>
Content-Language: en-GB
Bytes: 4736

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