Navigation

    • Register
    • Login
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. Timbergetter
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    Timbergetter

    @Timbergetter

    1
    Reputation
    10
    Posts
    94
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online
    Location Australia

    Timbergetter Follow

    Best posts made by Timbergetter

    • JSN SR04T - Temperature Influencing Readings

      I built a water level sensor for my 80,000 litre water tank based on the JSN-SR04T-2.0 ultrasonic sensor about six months ago. It is powered by 3 AA alkalines and therefore relies on being in sleep mode for most of the time.

      ![alt text](0_1567755826897_AJH_4070.JPG image url)

      I have experienced similar problems to many on this forum with the apparent unreliability of this sensor. In general the device spends most of the time reporting the correct water level but then has episodes of spurious reading which normally present as a depth to water level of around 220 mm. I had been thinking that I was plagued with condensation effects and I have been attending to reducing condensation with some limited success. In the last few days I have been seeing a pattern where temperature change might be influencing rogue behaviour.

      I have included a thermistor in my water level sensing package so that I can do some temperature compensation of readings. This has the spin-off that I can monitor the air temperature in the tank. I have noticed over the last 5 or so days a distinct pattern where the 220 mm anomalous reading occurs when the temperature is in the range of say 13 degrees to 20 degrees celsius. Looking at the attached chart which superimposes temperature and depth to water readings it can be seen that the correct water level is being reported over night but as the morning warms up it goes bad when the temperature hits 12 to 15 degrees and stays bad until the temperature warms up to about 20 degrees. The reading then stays good during the middle of the day but as the temperature falls below 20 degrees the reading goes bad again and stays bad until the temperature has fallen to below 12 degrees or so.

      0_1567756141934_TempVsDepth.jpg

      I would be very interested to learn of anyone else who has observed a similar temperature influence on water level readings.

      posted in Troubleshooting
      Timbergetter
      Timbergetter

    Latest posts made by Timbergetter

    • RE: JSN SR04T - Temperature Influencing Readings

      @zboblamont @slt1 It is my code that sets a sounding that is below 1300 µS to 1300 µS. The minimum depth that I end up reporting varies a little due to my temperature compensation but is nominally 0.22 m. I don’t know what the Newping library returns for these low and / or spurious soundings.

      I have not tried pulse widths other than 10 µS yet because until recently the weather has been too cold for the spurious reading to occur (less than 13 ºC). It’s warmed up over the last day so the time is right now to try lengthening that pulse.

      The only ground path to the metal box is via the ground side of the antenna fixed to the box. I’m not sure what alternate arrangement to try there.

      I’ve got a few things to try now. I’m going to try being systematic, trying one thing at a time and observing the effect for a day or so. It could take a while especially if the weather doesn’t cooperate.

      posted in Troubleshooting
      Timbergetter
      Timbergetter
    • RE: JSN SR04T - Temperature Influencing Readings

      @slt1 Sure can.

      /* Sender-10.ino ************************************  WATER LEVEL MONITOR
        Consolidate the dual sleep model
        Refine DoSoundings to handle wild exceptions
        Start bringing back in sleep function
        Debug nested do loop
        Bring in HC-12 radio
        Rationalise Lo/Hi Flow Detection
        Tidy Up
        Remove twice declare of sumsoundnew bug
        Move loop operations to functions
        Assemble output into single char packet
        Introduce THERM
        Switch off ADC when sleeping
      *****************************************************/
      
      const byte LOW_POWER_PIN = 5;
      const byte TRIGGER = 7;
      const byte ECHO = 8;
      const byte THERM = 1;
      
      #include <SoftwareSerial.h>
      const int RxH = 3, TxH = 4;
      SoftwareSerial HC12(RxH, TxH);
      
      const int numsoundings = 10;
      const int min_time = 1300, max_time = 15000;
      int countPings = 0;
      unsigned int cycleNum = 0;
      const byte Td = 5;
      long int duration[numsoundings] = {};
      int Vo = 0;
      
      // Set up for extended sleep when not much change in sounding
      bool HiFlowDetected = true;
      long int sumsoundold = 0, sumsoundnew = 0;
      int sleepcycles = 0; //number of cycles to sleep
      const float sumsoundTholdS = 100;
      const float sumsoundTholdL = 509;
      //*******************************************************************************S
      // Debug
      //int sleepcyclesS = 3;
      //int sleepcyclesL = 3;  //83 Secs for 10 cycles
      //*******************************************************************************M
      // Operational
      int sleepcyclesS = 14;
      int sleepcyclesL = 140;  //83 Secs for 10 cycles
      //int sleepSecsS = 148;    //Used only in Receiver
      //int sleepSecsL = 1480;   //Used only in Receiver
      //*******************************************************************************M
      
      void setup() {  
        Serial.begin(9600); 
        HC12.begin(1200);
        pinMode(LOW_POWER_PIN, OUTPUT);
        pinMode(TRIGGER, OUTPUT);  
        pinMode(ECHO, INPUT);  
        Serial.println("< CycleNo, SumSound, HiFlowDet, countPings > Vo, dSum ***");
        
        // Setup Watchdog Timer
        WDTCSR = (24);
        WDTCSR = (33); // 8 Seconds sleep
        WDTCSR |= (1<<6);
        // Disable ADC
        //  ADCSRA &= ~(1 << 7);  // Comment out if analog port needed
        // Enable SLEEP
        SMCR |= (1 << 2);  // power down mode
        SMCR |= 1;  // enable 
      }  
      
      //======================================
      void loop() {                         //
        digitalWrite(LOW_POWER_PIN, HIGH);  //
        delay(Td);                          //
        countPings = 0;                     //
        sumsoundnew = DoSoundings();        // 
        sleepMode();                        //
        ADCSRA |= (1 << 7);                 //
        Vo = analogRead(THERM);             //
        ADCSRA &= ~(1 << 7);                //
        sendResults();                      //
        sumsoundold = sumsoundnew;          // 
        cycleNum++;                         //
        putToSleep();                       //
      }                                     //
      //======================================
      
      long int DoSoundings(){
        // Get required number of consistent soundings
        // Read first sounding hoping its a candidate
        const int durationERR  = 300;
        int TdSnd = 20;
        
        bool skip = false;
        long int sumsound = 0;
        do{
          int count = 0;
          sumsound = 0;
          skip = false;
      
          duration[count] = aping(); // Sometimes needed to clear cobwebs?
          delay(TdSnd);
          byte j = 0;
          byte m = 0;
          duration[count] = aping();
          delay(TdSnd);
          sumsound += duration[count];
          count++;
          do{
            duration[count] = aping();
            delay(TdSnd);
            if(abs(duration[count] - duration[count-1]) < durationERR){
              // Sounding should be within 51.5 mm of previous
              sumsound += duration[count];
              count++;
            }else{
              m++;
              if(m > 10){ // Should trap wildest exceptions
                // Need to start again
                m = 0;
                skip = true;        
              }
            }
          }
          while(count < numsoundings & !skip);
        }
        while(skip == true);
        return sumsound;
      }
      
      //============
      long int aping(){
        countPings++;  
        digitalWrite(TRIGGER, LOW);  
        delayMicroseconds(2);  // 2
        digitalWrite(TRIGGER, HIGH);  
        delayMicroseconds(10);  //10
        digitalWrite(TRIGGER, LOW);  
        long int xx = pulseIn(ECHO, HIGH);  
        if(xx < min_time){
          return min_time;
        }else{
          if(xx > max_time){
            return max_time;
          }else{
            return xx;
          }
        }
      }
      
      //============
      void sleepMode(){
        // HiFlowDectected currently reveals status entering last sleep
        if(HiFlowDetected){
          if(abs(sumsoundnew - sumsoundold) < sumsoundTholdS){
            Serial.print("A");
            sleepcycles = sleepcyclesL;
            HiFlowDetected = false;
          }else{
            Serial.print("B");
            sleepcycles = sleepcyclesS;
          }
        }else{ // Previous cycle was long
          if(abs(sumsoundnew - sumsoundold) < sumsoundTholdL){  
            Serial.print("C");
            sleepcycles = sleepcyclesL;
          }else{
            Serial.print("D");
            sleepcycles = sleepcyclesS;
            HiFlowDetected = true;  
          }
        }
      }
      
      //============
      void sendResults(){ 
        const int TdHome = 100; // Any less than 50 ms is unstable
        // Even 60 might not be long enough - try 100 as test
        char outstr[30] = {};
        char buff[6];
        //************* Package to cloud *******************S
        itoa(cycleNum, buff, 10);
        strcpy(outstr, buff);
        strcat(outstr, ",");
        ltoa(sumsoundnew, buff, 10);
        strcat(outstr, buff);
        strcat(outstr, ",");
        itoa(HiFlowDetected, buff, 10);
        strcat(outstr, buff);
        strcat(outstr, ",");
        itoa(countPings, buff, 10);
        strcat(outstr, buff);
        strcat(outstr, ",");
        itoa(Vo, buff, 10);
        strcat(outstr, buff);
        Serial.print(outstr);
      
        HC12.print("XY"); // Clear the cobwebs
        delay(TdHome);
        HC12.print("YZ"); // Clear the cobwebs
        delay(TdHome);
        HC12.print("<");
        delay(TdHome);
        HC12.print(outstr);
        delay(TdHome);
        HC12.print(">");
        delay(TdHome);
        //**************************************************F
        Serial.print("<");
        Serial.print(outstr);
        Serial.print("> ");
        Serial.print(Vo);
        Serial.print(", ");    
        delay(Td);
        Serial.println(sumsoundnew - sumsoundold);
      }
      
      //============
      void putToSleep(){  
        digitalWrite(LOW_POWER_PIN, LOW); // Power Down MOSFET
        delay(500); // May need to increase if no sleep
        // Stop current leakage from floating pins in to HC12 (ryanm)
        digitalWrite(RxH, LOW);
        digitalWrite(TxH, LOW);
        //delay(150); // May need to increase if sleep truncated
        delay(500); // Debug - See if HC12 printing is dependent
        // Put 328P to sleep - T=8 gives cycle time = 74 secs
        sleepLoop(sleepcycles);
      }
      
      //============
      void sleepLoop(int loopNum){  // as per Keith Darrah
        // Sleep duration = 8 * loopNum seconds
        for(int i=0; i<loopNum; i++){
          // BOD Disable
          MCUCR |= (3 << 5);
          MCUCR = (MCUCR & ~(1 << 5)) | (1 << 6);
          __asm__ __volatile__("sleep"); // go to sleep
        }
      }
      
      //============
      ISR(WDT_vect){  // support watchdog timer
      }
      
      posted in Troubleshooting
      Timbergetter
      Timbergetter
    • RE: JSN SR04T - Temperature Influencing Readings

      @zboblamont The sketch is attempting to do the following:
      Compare new reading with previous acceptable reading and if they agree within 300 µs then accept the reading, otherwise discard it and try another reading. If there are 10 discards in a row then restart the whole process. Keep doing this until we get 10 acceptable readings and transmit the sum to the base-station. So if the sensor is continuously returning 0.22 m or thereabouts this will be passed on as an acceptable value.

      My Dupont-like connections are all soldered. I am using 3 daughterboard type connections so I guess these could be suspect in a thermal expansion scenario.
      0_1568173775738_AJH_4068.JPG
      I haven’t tried a plastic box. I got such a great deal on the die-cast box. Insulation might increase or alternatively might decrease the time that the electronic components and connections spend in the range of 13 to 20 degrees C, I really don’t know which. Either way I can see it pushing the underlying problem deeper into the shadows making it even harder to troubleshoot.

      The weather for the last week has been mostly cold, not even getting to 13 degrees so no chance to try things. It’s warming up right now so this might be my chance.

      I can well believe the twin transducer would be more sensitive and accurate but my concern here was the continuously high humidity.

      I do have a spare JSN sensor and controller so it might be time to try a substitution exercise.

      posted in Troubleshooting
      Timbergetter
      Timbergetter
    • RE: JSN SR04T - Temperature Influencing Readings

      At the risk of appearing to be labouring the point I’ve just looked a the last few days and once again the JSN is giving good results, but only if (13 > Temperature >20). Strange indeed.

      0_1568110982382_update-2.jpg

      posted in Troubleshooting
      Timbergetter
      Timbergetter
    • RE: JSN SR04T - Temperature Influencing Readings

      There is a lot of very interesting observations and suggestions coming to light here and I thank everyone for their input. No-one seems to have experienced the exact observation that I have made, however I may not have defined this exact issue very well, so I’ll add a bit of clarification with this figure:

      0_1567986221440_TempVsDepth2.jpg

      You may be wondering why the water level is stuck at 1.1 metres (depth to water) for days on end. This is a relatively large tank at 80,000 litres and outside irrigation season not much water is used. It’s just supplying water to my house at present.

      The last few days have been cold with maximum temperatures below 10 º C so no spurious readings and no troubleshooting possible.

      posted in Troubleshooting
      Timbergetter
      Timbergetter
    • RE: JSN SR04T - Temperature Influencing Readings

      @zboblamont It’s always a human at the pump switch (or at the very least me). He must decide whether to believe the reading broadcast by the JSN or alternatively pack a ladder onto the ute, drive to top of hill, climb onto tank and pop the heavy manhole lid and take a look.

      posted in Troubleshooting
      Timbergetter
      Timbergetter
    • RE: JSN SR04T - Temperature Influencing Readings

      @yveaux One of the objectives here was to detect near-full conditions while filling the tank so I can stop the pumps. I need to be able to rely on readings rather than wondering if it is a software artefact or not.

      posted in Troubleshooting
      Timbergetter
      Timbergetter
    • RE: JSN SR04T - Temperature Influencing Readings

      @zboblamont it is comforting to know that I am not the only person to have issues with this sensor, and I was thinking that was the case until I came across this amazing forum a few days ago. Things started well about 8 months ago during the peak of summer season here in Australia. For 2 to 3 months I saw none of these phantom 220 mm readings. Then as the weather cooled the phantom readings started, but I seemed to resolve the problem then for a few days at a time by drying out the sensor. So condensation seemed to play a role then. The current problem does not seem to be related to condensation, but rather operation in the modest temperature range of 13 to 20 degrees C. Anything higher than 20 degrees and it works fine, (as we head in to the Australian spring). Maybe the “oven-like” temperatures of last summer did some damage to some silicon that has only begun to show up now. I’ll keep chipping away and see what I find around the next corner.

      posted in Troubleshooting
      Timbergetter
      Timbergetter
    • RE: JSN SR04T - Temperature Influencing Readings

      Curious is the word. If it were an overheating issue then I wouldn’t have expected a return to stable operation while ever the temperature is above 20 degrees celsius, but I’m not ruling anything out at this stage. I noticed in one of your past sketches that you used 150 microsecond pulse-width ahead of the pulseIn() command. I am using 10 microseconds there and I cannot remember how I settled on that. I think 10 microseconds is the absolute minimum to trigger the jsn. I might play with that next. I am still running with the original set of batteries so the supply may have fallen to low volts by now so I’ll check that too. I thank you for your input.

      posted in Troubleshooting
      Timbergetter
      Timbergetter
    • JSN SR04T - Temperature Influencing Readings

      I built a water level sensor for my 80,000 litre water tank based on the JSN-SR04T-2.0 ultrasonic sensor about six months ago. It is powered by 3 AA alkalines and therefore relies on being in sleep mode for most of the time.

      ![alt text](0_1567755826897_AJH_4070.JPG image url)

      I have experienced similar problems to many on this forum with the apparent unreliability of this sensor. In general the device spends most of the time reporting the correct water level but then has episodes of spurious reading which normally present as a depth to water level of around 220 mm. I had been thinking that I was plagued with condensation effects and I have been attending to reducing condensation with some limited success. In the last few days I have been seeing a pattern where temperature change might be influencing rogue behaviour.

      I have included a thermistor in my water level sensing package so that I can do some temperature compensation of readings. This has the spin-off that I can monitor the air temperature in the tank. I have noticed over the last 5 or so days a distinct pattern where the 220 mm anomalous reading occurs when the temperature is in the range of say 13 degrees to 20 degrees celsius. Looking at the attached chart which superimposes temperature and depth to water readings it can be seen that the correct water level is being reported over night but as the morning warms up it goes bad when the temperature hits 12 to 15 degrees and stays bad until the temperature warms up to about 20 degrees. The reading then stays good during the middle of the day but as the temperature falls below 20 degrees the reading goes bad again and stays bad until the temperature has fallen to below 12 degrees or so.

      0_1567756141934_TempVsDepth.jpg

      I would be very interested to learn of anyone else who has observed a similar temperature influence on water level readings.

      posted in Troubleshooting
      Timbergetter
      Timbergetter