search

SUPScientist / smart-coasts-bathy-mapping

Low-cost, open-source bathymetric mapping (depth, GPS, angle, datalogging)
MIT License
0 stars 2 forks source link

Depth sensor returning 0.00 most of the time #7

Open SUPScientist opened 9 months ago

SUPScientist commented 9 months ago

Recent data showed a couple reasonable distance readings but ~ 95% depth = 0.00. Unclear if issue is hardware or firmware.

SUPScientist commented 9 months ago

HARDWARE IMPROVEMENTS: I think the next step will be for me to move from the breadboarded version to something soldered together. The current setup uses a Feather Tripler for the Boron, Adalogger featherwing, and GPS featherwing, and proto wires going to a breadboard for the power boost and step-down converter chips. Wiring is messy and needs to be cleaned up. Could be a poor wire connection (or a few) leading to bad readings.

FIRMWARE IMPROVEMENTS: I'm not sure we're calling result properly. This chunk,

https://github.com/SUPScientist/smart-coasts-bathy-mapping/blob/8444a9442982f13ee27aaa55ad683e8651b22c5b/Firmware/depth-sensing-JSN-SR04_Gen3_RK-Integration-Indu/src/depth-sensing-JSN-SR04_Gen3_RK-Integration-Indu.ino#L51-L59

puts depth_cm in a global variable which we then try to access in datalogging code below. Unclear if this is the proper way to work with the distanceCallback() function and distanceSensor.loop();. Ask Particle community for help understanding this code structure.

SUPScientist commented 9 months ago

Requesting support from the Particle community. Here is a request I posted: https://community.particle.io/t/jsn-sr04-callback-confusion/65888. Particle community is usually very responsive and helpful, so let's see what they recommend. CC @InduGadi in case you want to read up on that.

InduGadi commented 9 months ago

Awesome, thanks Dr. B! I will keep myself updated with the responses!

SUPScientist commented 9 months ago

Minor update: seems somewhat better after making two changes:

  1. Following suggestions here (minus changing all Serial.prints to Log.infos due to abundance of the former)
  2. Swapping the distance sensor for a different one in the lab. Initial one seemed to be returning more frequent bad values and not changing values as expected.

Still seeing frequent zeros, however, so may need to either save all values and filter out zeros later or request another value if it returns zero. Here is some example data:

3 Responses in Serial Monitor: Time: 23:33:09.000 Date: 11/30/2023 Fix: 1 quality: 1 736 0.59 volts 9.30 degrees C Location: 3408.4885N, 7752.0127W 23113003.csv 0000050673 [app] INFO: cm=0.000000 inch=0.000000 0000051173 [app] INFO: cm=82.297000 inch=32.400411

Time: 23:33:10.000 Date: 11/30/2023 Fix: 1 quality: 1 739 0.60 volts 9.54 degrees C Location: 3408.4885N, 7752.0127W 23113003.csv 0000051673 [app] INFO: cm=0.000000 inch=0.000000 0000052173 [app] INFO: cm=60.809000 inch=23.940564

Time: 23:33:11.000 Date: 11/30/2023 Fix: 1 quality: 1 748 0.60 volts 10.26 degrees C Location: 3408.4885N, 7752.0127W 23113003.csv 0000052673 [app] INFO: cm=52.955000 inch=20.848436 0000053173 [app] INFO: cm=48.297000 inch=19.014577

SUPScientist commented 9 months ago

Next steps:

  1. Check SD card to see which of the two depth values per loop is saved. It appears that zeros result more frequently on first of two samples per loop.
  2. If one of two samples per loop is consistently better, try to save that one!
  3. Replace serial print statements with Log.info. Timing is critical for this sensor, so anything that messes with system timing (e.g., Serial.print) could mess with results.
InduGadi commented 9 months ago

Hi Dr. B! Hope you are doing well! Those next steps sound great! Were you able to check the SD card? If the zeros appear more frequently on the first of the two samples, do you think we should either discard the first value or change the frequency of obtaining sensor readings? I was reading a few sources and found a couple of things we could try. In the forum (linked here), someone said that the Trigger HIGH before the reading should be 15 microseconds. Another person said that they take five consecutive readings 100 ms apart and calculate the median value of the readings that fall within allowed limits. So, we could filter out the readings outside the 23-600 range and use the median value as our data point. We could also potentially do this using this library called MedianFilter. Also, would you like me to update the code with Log.info instead of Serial.print? Thank you so much and have a great week!

carolinaj6 commented 8 months ago

How long is the trigger pulse for the sensor?

InduGadi commented 8 months ago

It looks like a 10 ms pulse is needed for the trig pin. So we could try to add the following line of code in the loop after getting each distance measurement.

delayMicroseconds(10); // keep the trigger "ON" for 10 ms to generate pulse for 10 ms.

But, using a longer trigger pulse of 20 ms is supposed to help with incorrect readings, so that could be a possibility. I know we had delayMicroseconds(20) in an older version of our firmware (in line 146 of this version using ping mode).

carolinaj6 commented 8 months ago

Yes - I have looked at a bunch of different forums and it seems like this should help. I looked into our library and I think it has the trig pin on high for only around 10 microseconds so I would like to try increasing it to 20.