You are correct. The pinout is labeled 5V but the datasheet does say 3-5.5V 
JSN-SR04T-rev2 mode 2 and 3 look like similar in description. Iām not sure to be able to tell the difference. As for the current consumption, Iām going to power it with an digital pin 3v3 if ok(some ppl have trouble to make it works on 3v3 but there are some tutorial where it wxplain how). and I could change to input pin before sleeping to stop some leakage. Otherwise using a Fet but donāt know which one to use. On my prototype I used a relay because I wasnāt able to use a fet correctly, or wrong specs for the use. So if I understand well, the mode2&3 return a hex format of the measurement? How many measurements does it take?(there still be some high and low value avalable. I prefer doing the math myself and recognize false reading rather than make an average from (1200, 1400, 1200, 1200) you see?
What about the adafruit TPL5110 board to use as simple watchdog, reducing stall to about 1hours(the goal is to sleep 1 hour or more(low water) betweenpublishes).
Solar for the moment is just adding a more complex system where couple of cell resolve the problem. I think Iām not going to use that in the first test. using 10 cells 18650 1500mah is not a problem.
Tell me a good logic Fet to use for acting like a relay for low load drive and lower than 20v, Iāll buy it at the same time.
I had issues when powering the JSN V.2 with a digital pin.
As a temporary band-aid, using (2) digital pins seems to work fine.
Mode 2 performs (10) measurements per second, continuously.
Mode 3 only performs (1) measurement, each time you request it (I haven't used Mode 3).
See Below for sample code for Mode 2 that will print the distance to your Serial Monitor.
But your existing code with the Default Mode should work fine also, and you wouldn't need to solder the R27 resistor.
Click ME for MODE 2 Code
void readDistance() {
dataReady = false;
// Turn Sensor ON
while (dataReady == false) {
if (lastReceiveChar + receiveTimeout < millis ()) {
dataTimeout = true;
}
if (Serial1.available() > 0 ) {
if (dataTimeout == true) {
ndx = 0;
dataTimeout = false;
}
buforek[ndx] = (byte) Serial1.read();
lastReceiveChar = millis();
ndx++;
if (ndx == 4) {
ndx = 0;
if (buforek[0] == 0xff && ((buforek[0] + buforek[1] + buforek[2]) & 0x00ff) == buforek[3]){
distance = buforek[1] * 256 + buforek[2];
dataReady = true;
// if (distance <= 189) distance = 0; // 189mm seems to be the minimum detection distance
if (dataReady) {
Serial.print("MM: ");
Serial.print(distance);
Serial.print(" , Inches: ");
Serial.print(distance / 25.4);
Serial.print(" , Feet: ");
Serial.println(distance / 304.8);
}
}
}
}
}
// Turn Sensor OFF
}
I hope to build my long range MaxBotix Version w/ Solar and Sleep for Boron LTE this week.
I'll share it here in case it helps with your project.
Iām really missing spare time theses days.
Thanks, Rftop, this make a lot sense and itās clearer now.
but the code is really beyond me. could you explain a bit how it is working.
buforek[ndx]? //It look like youāre sampling 4 time?
if (buforek[0] == 0xff && ((buforek[0] + buforek[1] + buforek[2]) & 0x00ff) == buforek[3]){
distance = buforek[1] * 256 + buforek[2]; //thoses 2 hexs is translated to 255 with google //could you explain the purpose of theses lines?
Do you recommend buying tpl5110 and 5111?
do someone could tell me a nice logic fet to use with 3.3v?
The JSN Modes 2 & 3 output serial data in Millimeters.
The frame format is: 0XFF + H_DATA + L_DATA + SUM.
After you see a 0XFF, the next (2) 8-bit values are the distance measurement, which are used to create the 16-bit measurement. The fourth value is the CheckSum (only the lower 8-bit of the Sum).
Update:
I have a Maxbotix and a JSN-SR04T V.2 unit built.
Both use Boron Sleep Mode and Solar.
I'm not happy with either just yet.
MaxBotix Version
The Maxbotix MB7051 is very accurate and fits beautifully in a 3" PVC pipe as it's enclosure. My thought is a short piece of PVC pipe wont draw as much attention for vandalism on the side of a bridge as a "typical" panel would.
The MB7051 is so accurate that I'm seeing the measured distance vary with Air Temperature on the hourly logs.
This can be up to a 3" swing just from the Air Density Change w/ Temperature over night.
The temperature compensation is easy, but adding an external temp sensor adds a little bit of complexity to a weatherproof enclosure (PVC pipe). It also needs a temperature sensor inside the enclosure to determine when to disable Li-Po charging (I normally use a TMP36 or 37).
I'm using a cheap 1-watt flexible solar panel that wraps around the 3" PVC Pipe enclosure
JSN Version
The JSN-SR04T V.2 performs better in Mode 2 verses the Default Mode 1 (for me anyway).
There are far less "bogus" values reported when using the Serial Output of the JSN.
But Serial Output requires soldering a resister to R27 which isn't a lot of fun.
I'm powering the JSN from the 5V output of this Battery Shield, but this isn't absolutely necessary.
I'm still not confident in the accuracy or precision of the JSN sensor, but it's slowly gaining on me.
Both Sensors:
I'm leaning towards having the Boron remain awake in both Sensor Versions when the SOC is > 90%.
The benefit of using a variable Sleep (verses a TPL5110/1) is the Boron can be available for OTA flashes after it's deployed in the wild.
Both Versions send distance, Li-Po Voltage, and SOC to ThingSpeak using a Webhook.
I'll continue to tweak the Code and run the trials.
I'll let ya know when I have something worth sharing for improvement ideas.
@Rftop, great update!
In your āBoth Sensorsā section you mention the benefit of variable Sleep vs. TPL5110/1 being OTA updates. I totally agree with this statement, but I still have wondered about using a set time each day (or even once a week) to allow for a set OTA update window (say 10 or even 30 mins). Due to the fact that when a cloud connect is called the date/time is synced I would expect the window to be tight enough that you could āshoot the gapā and send an OTA update during the window. Although, it is not instant OTA, it would provide a hybrid allowing for OTA and maximum battery life optimization.
Since the TPL5110/1 used the ādoneā pin I believe it is possible.
Based on your experience with your project so far, do you think this proposed hybrid OTA protocol has potential?
@Backpacker87, Yes indeedā¦ thatās a great idea.
So if you wanted 1 hour updates, you could do as you say and Not trigger the Done Pin once a day (or more).
That would allow you up to a 1 hour window (or maybe 2 hours, Iām not sure) to stay awake for OTA flash.
Adding to your idea, you could have the Boron check a flag from a 3ārd party to see if it needs to stay awake during that 1 hour to wait for an update. Something as simple as reading a field from ThingSpeak, then resetting that field after a successful OTA.
I put the JSN-SR04T on hold for now.
Iām focusing on the MaxBotix. Everything has been going smooth until today when a Code Update introduced some problems. Nothing major and entirely my fault.
Would it be a good idea if the 3rd party element here is a photon?
It wouldn't be doing anything useful perhaps, but the waking up electron could read a variable from it and learn that there is an OTA waiting for it.
Perhaps publish/subscribe here is simpler than a webhook to ThingSpeak, and parsing the response, but I'm only wondering here...
@Rftop and @gusgonnet I really like the flag idea. I have been thinking about it and it could be considered like a catch and release strategy.
You could trigger the flag at any point before the boron wakes to check so as to set the trap (this would be in the condition you need to do an OTA). When the Boron wakes and connects to the cloud, if there is a flag āit is caughtā and it stays awake until the flag is removed by the user (updates completed successfully no need to stay away longer āit is releasedā) , or when the pre-assigned wake period (say 1 hr) has elapsed.
If the boron wakes, connects, and there is no flag then it will discontinue the cloud session saving the battery and data associated with staying awake for 1 hr for no need.
For the flag, personally I would use a click-button on a Ubidots dashboard as most of my borons push their data to a Ubidots dashboard already.
Bottom line: I believe we have collectively fleshed out the theoretical best hybrid scenario for optimized battery and data for the Boron utilizing a scheduled wake combined with a flag catch and release.
I have had other obligations I have had to dedicate my time to, but I will have more free time soon. I will work on building this out by the end of April.
Joseph
2 Likes
hey there,
I saw this today and thought of your project. They mention a mosfet there so maybe you can take that as inspiration?
Bonne journee,
Gustavo