JSN SR04T - Temperature Influencing Readings

[zboblamont]

@timbergetter Gotcha, but it is still information rather than control, YOU are the control..
Were it a closed system (float valve/ballcock) a standard pressure switch on the pump would handle the auto-cut-off as the pressure ramps up against the closing valve.
Perhaps a further refinement might be a float switch or other high level contact to warn of imminent overflow? That way at least you have a backup indicator should the US go walkabout.
If you are certain the overnight level is correct, thermal insulation on your case might tame the temperature shift and solve your issue without figuring out which part or connection is going wrong. A little puzzled why the reported level barely appears to shift though.
My raw water tank seems fairly reliable on the ultrasonic at 3.3v, reporting every x.55 on RTC. I only monitor it to verify the borehole pump topped up the raw tank overnight after twice running dry due to a faulty pump control timer.

Coincidentally it's a WhisperNode from Oz, staggeringly good performer on 2xAA alkalines... I also built in an X attempts routine to get a reading to limit battery drain after the condensation drip incident.
Hopefully the sewage node issue is resolved in another month, it's more an annoyance than essential info..

[slt1]

@Timbergetter I also tried the JSN SR04T sensor and had problems with it. Ended up using the cheap HC-SR04 sensors on my tanks. Have 3 different tank sensors - borehole water tank up the hill, rainwater tank at house and another reverse osmosis filtered water tank. All three going for just over a year now.

Condensation issues / waterproof I resolved by quickly spraying some clear laq spray paint over the sensors. On one tank I also added little standoffs so the sensor is not sealed onto the lid of the tank but rather 5 to 10mm above the lid to let the ambient air pass over and prevent high humidity inside the tank condensing on the sensor.

And then for the code ... I added LM35 temperature sensor and added temp compsensation. Also I do a few readings and average them out.

All-in-all I now get only one or two weird readings on rare occasions - could be a spider !

Here is the last day data of the tank I have up the hill. Its showing pump cycles as well to keep tank topped up - its a weak borehole so i can only pump a little at a time. I have a separate node with relay to turn on/off pump as well as float switch down the hole to detect low water levels in the borehole.

Here is a one week graph of the same tank : temp and distance only shown

Here is one month data

We are just coming out of winter here (in South Africa!) - so temp swings of the air inside the tanks are quite radical between day and night (except the last 2 days its been getting rather warm here !)

Basically - just wanted to let you know/see that the cheap HC-SR04 sensors can do the job - and no more hiking up hills to check tank levels - and also the pumping can be automated too by the controller

[zboblamont]

@slt1 Out of curiosity was the JSN you trialled the 2.0 version or the original SR04T, ie the purported 3v version or the original 5v ?
Nice that you got a solution with the HC version but your type of winter is a tad different to here :joy:

[slt1]

@zboblamont I bought this one https://www.hobbytronics.co.za/p/1119/waterproof-ultrasonic-distance-transducer

Looks like its supposed to be the 5V version from those specs.

[slt1]

@zboblamont Oh - and its not really winter anymore here - only goes to last month in the screenshots previously shown. Not sure where you're from - but temp inside tanks here range from 0.69 C to 42.7 C - min / max for last year

Here is the last years graph for interest sake !

Here is my first prototype version installed on the rain tank :

[Timbergetter]

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:

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.

[zboblamont]

@timbergetter said in JSN SR04T - Temperature Influencing Readings:

You may be wondering why the water level is stuck at 1.1 metres

The level variation makes sense now.
No clue what is going on with temp electronically, but couple of anomalies on the 1st fall outwith the perceived problem range briefly. Stumped what could be going awry with the board/head short of a dodgy connection.
I run max 10 readings looking for 2 consecutives within a defined range, but in your case you are reporting a value you know is incorrect?
Perhaps you could reference previous reading in the sketch to assess whether to send in the bogus signal? As your decay over time should be predictable (during irrigation season) perhaps not reporting the anomaly might be an option?

[zboblamont]

@slt1 I'm Scottish but currently live in Romania, very different weather altogether, -20 to +45....
Air temp inside is largely influenced by solar gain on an above ground tank, but the high thermal mass of the water means the fluid temp drift is much slower than those wild swings in air temp, topping up levels having the greater effect.
Good that you found a solution you can have confidence in, if @Timbergetter can't solve his problem, this might be an alternative solution as the climate should be similar.
The high humidity of my underground tanks dictated the button sensor approach, and insertion in a 3/4" collar gave a solid fixing for the head. Only one install is giving me grief, which I note this morning is finally passed the ghost level, another 3 weeks and I can investigate further.

[Timbergetter]

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.

[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?

[slt1]

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

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

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.

[Timbergetter]

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

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

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

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

[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

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

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

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

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