INTL 3:770/1 3:770/3   
   REPLYADDR tnp@invalid.invalid   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  f2e1da15   
   REPLY:  472bb062   
   PID: SoupGate-Win32 v1.05   
   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.   
      
   --   
   If I had all the money I've spent on drink...   
   ..I'd spend it on drink.   
      
   Sir Henry (at Rawlinson's End)   
      
   --- 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