Recently we had similar message ($CHECK_BARO1_PRESEN) and the problem was in 20 pin connector: barometer CS pin was detached due to mechanical impact. We soldered that pin and the problem had gone.
So it was completely hardware problem since we disassembled device several times and it turns out that connector DF40C(2.0)-20DS is not robust enough to withstand many cycles of unplugging.
As mentioned in above comment Bunch of orange cubes start to fail - #12 by sidbh it is highly discouraged to open the Cube, do repairs like this.
@sidbh
Hello,
Who is the managing partner for CUBE products in India . Heard that the manufacturing of CUBE products will be from Taiwan and USA . Also that they do have an Indian partner.
@sidbh @phill @Franco @Hannes_Verschore - Was there any resolution to this issue? I just experienced this for the second time… first cube I RMAed after reading these posts… but for the second cube, I wanted to dive deeper and see if I could find the root cause.
I shared more details here: $CHECK_BARO0_PRESEN Error on Cube Orange+
But in short, if I bypass the sensor check at boot, it appears that the BARO is functioning just fine… yet when I enable the sensor check, it fails.
The issue here was caused by it being dismantled, and breaking the connector.
Do not disassemble your cube! It has gone through extensive testing after finally being assembled and any disassembly will risk permanent damage.
@philip - Yea, that’s what I understood from this post too. I haven’t opened any of the cubes I have and see the same issue on at 2/3 of the cubes I have.
As I wrote above if I bypass the board/sensor check at startup, everything works fine, the baro reads real and correct data, etc. Is there any new data on this topic that could explain the root cause for this error without having opened the cube?
Loading a firmware from a different device can cause this..
Hello,
How did you bypass the board/sensor check. Was it a initial firmware precompilation trick or something else ! Curious to know…thank you