From: tnp@invalid.invalid   
      
   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: you cannot sedate... all the things you hate (1:229/2)