Skip to content
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Troubleshooting
  3. JSN SR04T - Temperature Influencing Readings
  • Getting Started
  • Controller
  • Build
  • Hardware
  • Download/API
  • Forum
  • Store

JSN SR04T - Temperature Influencing Readings

Scheduled Pinned Locked Moved Troubleshooting
ultrasonic water level tank
34 Posts 6 Posters 1.4k Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • zboblamontZ zboblamont

    @timbergetter Not labouring the point at all, but what have you changed which might help narrow the problem?
    1 - Did you review the sketch to verify the reading is double or triple verified and not reported if false compared to expected range or previous reading? Clearly not as you are still reporting incorrect readings.
    2 - If the connections are Dupont, have you checked continuity for a dodgy wire, or even better soldering terminations to eliminate thermal expansion of contacts from possibilities?
    3 - Have you tried changing the materials used for casing and conduit from thermal conducting metal to insulated material or see if insulating the case made any difference?
    As @slt1 kindly chipped in with a climate not unlike your own he couldn't get the 5vJSN to reliably work and elected to go with a modified twin transducer which he found reliable.
    Your false readings are uncannily close to the deadband of 20cm on all your failures for what it's worth.
    I have one strangely behaving board, and one operating perfectly in stable temperatures but high humidity. I will experiment when the problem arises after the tank is emptied in 3 weeks, but curious what you've tried in the last 4 days?

    T Offline
    T Offline
    Timbergetter
    wrote on last edited by
    #21

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

    zboblamontZ 1 Reply Last reply
    0
    • S slt1

      @Timbergetter Can you can post the sketch you are using?

      T Offline
      T Offline
      Timbergetter
      wrote on last edited by
      #22

      @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
      }
      
      1 Reply Last reply
      0
      • T Timbergetter

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

        zboblamontZ Offline
        zboblamontZ Offline
        zboblamont
        wrote on last edited by
        #23

        @timbergetter said in JSN SR04T - Temperature Influencing Readings:

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

        Correct, high humidity makes this button US head ideal. @slt1 had failures with it which is why he resorted to the twin version with a lacquer coat and plenty of ventilation, a viable option in his installation. Your assumption the twin head is more sensitive is incorrect, but they are more widely stocked by suppliers.
        Ok on the connections, that knocks thermal disconnect off possible causes.
        Ok on the casing choice, I'm only wondering if there is an inadvertent effect of high heat absorption or rf reflection internally. On the heat correlation to failure, it could perhaps be the rise/fall rate rather than actual temp, but baffled what is being influenced.
        Your suggested substitution might be worth a try. As said previously, I have two near enough identical installs with only one giving ghost level problems, so I am suspicious it is a QC issue. Unfortunately only have a spare US head from a DYP trial previously, and loath to order another JSN in the hope I get a reliable one.
        Will have a look at the sketch later, but your explanation sounds logical, if a lot more complicated than my own. Sketch I use runs a max of 10 attempts for two consecutive readings within the expected range, if it fails it does not report the value. As I'm using Domoticz as Controller it flags red if it doesn't get a reading over 3 hours, prompting me to investigate. Only the condensation drip at very low temps has caused this to date.

        S 1 Reply Last reply
        0
        • zboblamontZ zboblamont

          @timbergetter said in JSN SR04T - Temperature Influencing Readings:

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

          Correct, high humidity makes this button US head ideal. @slt1 had failures with it which is why he resorted to the twin version with a lacquer coat and plenty of ventilation, a viable option in his installation. Your assumption the twin head is more sensitive is incorrect, but they are more widely stocked by suppliers.
          Ok on the connections, that knocks thermal disconnect off possible causes.
          Ok on the casing choice, I'm only wondering if there is an inadvertent effect of high heat absorption or rf reflection internally. On the heat correlation to failure, it could perhaps be the rise/fall rate rather than actual temp, but baffled what is being influenced.
          Your suggested substitution might be worth a try. As said previously, I have two near enough identical installs with only one giving ghost level problems, so I am suspicious it is a QC issue. Unfortunately only have a spare US head from a DYP trial previously, and loath to order another JSN in the hope I get a reliable one.
          Will have a look at the sketch later, but your explanation sounds logical, if a lot more complicated than my own. Sketch I use runs a max of 10 attempts for two consecutive readings within the expected range, if it fails it does not report the value. As I'm using Domoticz as Controller it flags red if it doesn't get a reading over 3 hours, prompting me to investigate. Only the condensation drip at very low temps has caused this to date.

          S Offline
          S Offline
          slt1
          wrote on last edited by
          #24

          @Timbergetter Isee you are still on 10us delay. I've read somewhere that 10us delay specified for the JSN is too short and causes failed readings in the JSN and I if I recall 15 or 20 us makes it more reliable. @zboblamont already mentioned this, so perhaps you already tried to increase the delay ???

          Also, something else someone mentioned elsewhere was that metal casing caused some erratic readings on the JSN and grounding the case to the circuit's gnd helped.

          zboblamontZ 1 Reply Last reply
          0
          • S slt1

            @Timbergetter Isee you are still on 10us delay. I've read somewhere that 10us delay specified for the JSN is too short and causes failed readings in the JSN and I if I recall 15 or 20 us makes it more reliable. @zboblamont already mentioned this, so perhaps you already tried to increase the delay ???

            Also, something else someone mentioned elsewhere was that metal casing caused some erratic readings on the JSN and grounding the case to the circuit's gnd helped.

            zboblamontZ Offline
            zboblamontZ Offline
            zboblamont
            wrote on last edited by
            #25

            @slt1 I can't recall where I read the 15 microsecond suggestion, but the spec sheet I found only states "a minimum of 10us".
            The spec sheet I found was at https://www.jahankitshop.com/market/d/8946 .

            S T 2 Replies Last reply
            0
            • zboblamontZ zboblamont

              @slt1 I can't recall where I read the 15 microsecond suggestion, but the spec sheet I found only states "a minimum of 10us".
              The spec sheet I found was at https://www.jahankitshop.com/market/d/8946 .

              S Offline
              S Offline
              slt1
              wrote on last edited by
              #26

              @zboblamont Yes - that spec sheet does say "1,10uS above the TTL pulse". That is not a great english translation !

              Chinglish translations sometimes might miss some important words - here is the spec translated by google from Chinese stating "above" 10us
              0_1568194916445_bf46382c-4d29-4aa4-8f76-8a8d54997c4a-image.png

              Also, there are various people reporting issues at using 10 though. Here is something mentioned in the NewPing lib issues queue : https://bitbucket.org/teckel12/arduino-new-ping/issues/41/jsn-sr04t-20-needs-to-have-longer-high

              zboblamontZ 1 Reply Last reply
              0
              • zboblamontZ zboblamont

                @slt1 I can't recall where I read the 15 microsecond suggestion, but the spec sheet I found only states "a minimum of 10us".
                The spec sheet I found was at https://www.jahankitshop.com/market/d/8946 .

                T Offline
                T Offline
                Timbergetter
                wrote on last edited by
                #27

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

                zboblamontZ 1 Reply Last reply
                0
                • S slt1

                  @zboblamont Yes - that spec sheet does say "1,10uS above the TTL pulse". That is not a great english translation !

                  Chinglish translations sometimes might miss some important words - here is the spec translated by google from Chinese stating "above" 10us
                  0_1568194916445_bf46382c-4d29-4aa4-8f76-8a8d54997c4a-image.png

                  Also, there are various people reporting issues at using 10 though. Here is something mentioned in the NewPing lib issues queue : https://bitbucket.org/teckel12/arduino-new-ping/issues/41/jsn-sr04t-20-needs-to-have-longer-high

                  zboblamontZ Offline
                  zboblamontZ Offline
                  zboblamont
                  wrote on last edited by
                  #28

                  @slt1 It's a bit bass-ackward chinglish right enough, but what I took "above" to mean was greater than.
                  I tried using old and new ping to begin with, but couldn't get it to work, hence reversion to the manual method where I could try altering things (mostly blindly) in the absence of a spec. Some guy did a video on it saying don't buy this rubbish version 2.0, I'm sure the longer pulse was mentioned in the comments.
                  For some reason the problem JSN worked reliably on the sewage tank with a 5v setup, but when I extended the Trigger after reading about it, it found it started working on 3.3v. Unfortunately when the tank was emptied it began seeing ghost levels, so when next emptied I'll investigate further. If it isn't a head problem (have spare) then something is wrong with the board on QC.

                  S 1 Reply Last reply
                  0
                  • T Timbergetter

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

                    zboblamontZ Offline
                    zboblamontZ Offline
                    zboblamont
                    wrote on last edited by
                    #29

                    @timbergetter Fair enough, it's a puzzle but do report back with the fix, somebody will be along with a similar problem at some point.
                    The 10µs does seem to be an issue, perhaps that might be your first mod when the problem recurs.
                    As I'm resolving depths to the nearest mm within the permissible range rather than examining flight time, possibly I've a greater chance of getting consecutive readings due to arithmetic rounding down.
                    For a direct earth you would need to drill the box or lid and use a bolt I suspect, unless there are tapped collars inside.

                    K 1 Reply Last reply
                    0
                    • zboblamontZ zboblamont

                      @timbergetter Fair enough, it's a puzzle but do report back with the fix, somebody will be along with a similar problem at some point.
                      The 10µs does seem to be an issue, perhaps that might be your first mod when the problem recurs.
                      As I'm resolving depths to the nearest mm within the permissible range rather than examining flight time, possibly I've a greater chance of getting consecutive readings due to arithmetic rounding down.
                      For a direct earth you would need to drill the box or lid and use a bolt I suspect, unless there are tapped collars inside.

                      K Offline
                      K Offline
                      kted
                      wrote on last edited by
                      #30

                      Have you guys considered using a US-100 ultrasonic sensor instead?
                      It can be used in the usual "ping" method, or in serial mode, in which case you can also get a reading from the built-in temperature sensor, and the distance measurement is automatically temperature compensated.
                      And it also works reliably at 3V.
                      I was using it for a year without problems in an diesel tank, and made the mistake to replace it with a TOF sensor. Now I'm back to the old reliable US-100.

                      zboblamontZ 1 Reply Last reply
                      0
                      • zboblamontZ zboblamont

                        @slt1 It's a bit bass-ackward chinglish right enough, but what I took "above" to mean was greater than.
                        I tried using old and new ping to begin with, but couldn't get it to work, hence reversion to the manual method where I could try altering things (mostly blindly) in the absence of a spec. Some guy did a video on it saying don't buy this rubbish version 2.0, I'm sure the longer pulse was mentioned in the comments.
                        For some reason the problem JSN worked reliably on the sewage tank with a 5v setup, but when I extended the Trigger after reading about it, it found it started working on 3.3v. Unfortunately when the tank was emptied it began seeing ghost levels, so when next emptied I'll investigate further. If it isn't a head problem (have spare) then something is wrong with the board on QC.

                        S Offline
                        S Offline
                        slt1
                        wrote on last edited by
                        #31

                        @zboblamont Are you "ghost levels" not perhaps echoes bouncing around the tank and nothing in the tank to absorb the sound quickly. If so perhaps increasing time between pings might help to let the previous ping dissipate.

                        zboblamontZ 1 Reply Last reply
                        0
                        • S slt1

                          @zboblamont Are you "ghost levels" not perhaps echoes bouncing around the tank and nothing in the tank to absorb the sound quickly. If so perhaps increasing time between pings might help to let the previous ping dissipate.

                          zboblamontZ Offline
                          zboblamontZ Offline
                          zboblamont
                          wrote on last edited by
                          #32

                          @slt1 Nope. It is not a physical intrusion or an echo off the clean vertical sides, had to re-read notes until the penny dropped as there is a lot of nonsense in circulation.
                          A US pulse will decay quickly even in an echo chamber, but a first pulse in silence can only return by the shortest route, any echoes thereafter have no effect. You can calculate the decay for the frequency but it is miniscule. This is a board/head problem not an environmental one, but to summarise the iterations:
                          1 - 5v promini and separate battery pack passing info to Node over I2C. Perfect aside battery decay.
                          2 - Run JSN on a booster off Node battery with the Node using Trig and Echo via level converter, worked perfectly until I emptied the tank..
                          3 - Extended the Trig pulse and run on 3v3 direct, again no problem, until I emptied the tank.
                          Iterations 2 and 3 are hitting the same ghosts only when the tank is <50%, but crucially only on one board of two identical installs. The second in the Raw Water tank has worked perfectly on 3v3 down to empty and the tank has ribbed sides with ledges which might give reflections.
                          Have a spare head and 5v and 3v3 arduinos to trial when tank is emptied ca 3 weeks. Might buy another JSN and take pot luck, but not exactly confidently.

                          1 Reply Last reply
                          0
                          • K kted

                            Have you guys considered using a US-100 ultrasonic sensor instead?
                            It can be used in the usual "ping" method, or in serial mode, in which case you can also get a reading from the built-in temperature sensor, and the distance measurement is automatically temperature compensated.
                            And it also works reliably at 3V.
                            I was using it for a year without problems in an diesel tank, and made the mistake to replace it with a TOF sensor. Now I'm back to the old reliable US-100.

                            zboblamontZ Offline
                            zboblamontZ Offline
                            zboblamont
                            wrote on last edited by
                            #33

                            @kted This is a standard type two diaphragm as @slt1 used, but as my tanks are sealed and underground the 100% humidity would kill them fairly quickly. There is no advantage over the button head in terms of accuracy, the button type allows the Node to be distant from the measuring point and are waterproof.
                            Most of these US can be operated in various modes by changing the value of one of the resistors, but not all can be operated down to 3v...

                            1 Reply Last reply
                            0
                            • N Offline
                              N Offline
                              nestwiderhaken
                              wrote on last edited by
                              #34

                              I'm having the same / a simular issue of temperature related readings, but at a different temperature level (for me it must be > 14 degree). I massure the dew point as well (temperature = orange, dew point = yellow). It looks to be more related to water in the air than only to temperature.
                              @zboblamont have you been finally been able to find a solution?

                              6760565c-914c-4608-be1a-6d10d0640e08-{AC609C25-78E7-49DE-8302-0166A041BFF2}.png

                              1 Reply Last reply
                              0
                              Reply
                              • Reply as topic
                              Log in to reply
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes


                              18

                              Online

                              11.7k

                              Users

                              11.2k

                              Topics

                              113.0k

                              Posts


                              Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                              • Login

                              • Don't have an account? Register

                              • Login or register to search.
                              • First post
                                Last post
                              0
                              • OpenHardware.io
                              • Categories
                              • Recent
                              • Tags
                              • Popular