Hello,
I have two pressure sensors (Bar02 and Bar30).
I have used both sensors and they were working fine but after a while (two weeks on average) when I open the serial monitor I get “starting” and then no readings at all as if it’s stuck or something.
The I2C bus is working fine, another sensors was on the bus and was functioning. I checked the wiring and I everything.
What causes the sensor to malfunction?
Hi @ASmarine,
This isn’t an issue I’ve heard of before.
A couple of questions here:
- Is this two weeks of continuous measuring, or are you saying they were working each time you turned them on within a two week period, and then stopped working afterwards? If it’s continuous measurement note that both the Bar30 and Bar02 are not intended for extended submersion, and should be dried fully once per day (as specified on the relevant product pages and on the sensor datasheets).
- Given you’ve mentioned a serial monitor I assume you’re using an Arduino or similar. If your board runs on and communicates with 5V, are you using an I2C level converter to drop the communications to 3.3V for the sensors? This is mentioned in the Bar02 Arduino Guide, and covered in depth in the Bar30 Arduino Guide.
If neither of those is the issue then I’d suggest adding some extra Serial.println calls in the script that you’re running, to help determine where it’s getting up to.
No continuous operation.
Just a period of 2-3 hours every three days on average. The vehicle is normally placed in a very sunny place so it dries out very quickly.
I guess it’s the I2C voltage level that caused the sensors to malfunction. I’ve been using an I2C converter for a while but it was lost. I had to act quickly so I wired the Arduino directly to the sensor (I often do that with raspberry pi (also I2C 3.3 v level) without issues). It worked fine for a relatively long time which led me to believe it was okay.
Good thing I posted this so that buyers get to know what issues could arise from such acts.
I will try to use another voltage level converter and see if the damage is permanent. Just to keep thread followers updated.
Ahh yeah, that can definitely cause premature failures (as with any case of operating something outside its specification). Unfortunately it’s not always an immediate bang/smoke, which can give a false sense of security until the relevant component fails much sooner than expected.
Raspberry Pi and Bar30/Bar02 both use 3.3V I2C, so they should be directly compatible, whereas most Arduino boards use 5V, which is where a level converter becomes necessary.
If it stopped working when it previously was working I would guess that the damage is likely to be permanent, but it at least doesn’t hurt to try 
Hello,
I bought a new one (a third one, actually) with I2C converter integrated into the system. I managed to dry it up after each run (15 minutes approximately underwater). But the same exact problem happened again. This has to do with the sensor quality itself because I followed the rules this time. I checked all other sensors connected to the I2C bus and all is fine except for the pressure sensor. No sparks, no short circuits, just the sensor malfunctioning out of nowhere.
Definitely odd.
What code are you using to run it? If you’re using our example then it must be getting stuck at either Wire.begin() or sensor.init().
I expect it’s not Wire.begin() given that’s a library built into the Arduino, and you mentioned another sensor on the same bus was working (so it’s presumably not one of the lines being held low/high from a short circuit or something).
The sensor initialisation code basically just sets a few variables and gets some calibration data from the sensor. The only part of that I could see potentially blocking indefinitely would be the read calls (specifically if the sensor isn’t working/stops responding, or a byte gets missed/corrupted), which wouldn’t be detected because unlike the Arduino Wire.read example, our code doesn’t check for available data after the requestFrom calls.
From a look at the Wire source, read (and indeed the whole library) is implemented with buffers that get filled via interrupts, so it shouldn’t be possible for it to block (it should just return -1 if a byte is read when there isn’t one available). If one of the calibration bytes is set to -1 then the calibration should fail the CRC (cyclic redundancy check), in which case sensor.init() should return false, which should trigger the additional Serial.println calls which identify that an error has occurred, before it attempts to initialise again after a 5 second delay.
If it manages to get past the initialisation then at least communication with the sensor should be working correctly, but even if readings aren’t the example should still be printing regularly, just without meaningful measurement values.
Things to try
If you’re using different code to our example script, are you able to share it and/or can you see what results you get with our script? The behaviour you’ve described doesn’t seem to be possible with our example script, unless my reasoning above is incorrect, or you’re on different library versions to the ones I was referring/linking to.
In case it’s relevant/helpful, I’ve just checked the device datasheets (available from our product pages), and they both have a section on resetting:
Our example does include a reset during initialisation, but it may be worth trying to power-cycle and reset the sensor a few times repeatedly to see if it starts responding again
If reseting doesn’t help, and our example script is repeatedly failing to initialise your sensor, and/or is giving consistently meaningless readings in the loop, then I’d suggest you contact support@bluerobotics.com and let them know what’s going on (e.g. link them to this thread). Since you don’t seem to have used it outside its rated electrical range, and assuming you haven’t been using them outside their rated pressure ranges, then most likely they can send you a replacement. If you do send a support email, it would be helpful if you can include the order number or order date if possible