1

Problem:

I bought two MS5803-14BA sensors and I soldered them myself to a SOIC-8 PCB to be able to use them. Only one sensor is used in my circuit. To access it, I use an Arduino Pro Mini 8MHz/3.3V with a library that has a CRC check for the sensor. When assembled to the circuit, one of the sensors pass the test, however the other fails. I'm using I2C to access the sensor.

I would like both sensors to pass the test so I could compare readings from two assembled circuits, but I really don't know how to do it. I have a three questions:

  • Where this problem can be originating from?
  • What kind of limitations I have for not passing the CRC test? Does it mean that the collected data can not be trusted?
  • If I use the raw readings D1 and D2 from a sensor that have failed the CRC test and pos-compensate them in the computer, will I have trustful results?
  • How to solve it?

Schematic:

schematic

simulate this circuit – Schematic created using CircuitLab

  • The resistors R1 and R2 are pull-up resistors.
  • The capacitor C1 is recommended by the sensor's datasheet.
  • Sensor's PS pin is connected to Vcc in order to select I2C mode for communication. The other option was SDI.
  • Sensor's CLS pin is connected to ground to select the address 0x77 to the sensor. Case it is connected to Vcc, the address is set to 0x76.

Documentation

7
  • Are both devices on the same address and you manually swap them, or are they on different addresses and both connected to the same bus all the time?
    – Majenko
    Apr 10, 2017 at 18:18
  • They are on the same address and I manually swap them. I was doing this to see how close their readings are and after I saw bigger differences than expected, I started to research and end up finding the CRC test.
    – rvbarreto
    Apr 10, 2017 at 18:36
  • It sounds to me like either one is dead (damaged during soldering maybe?) or there is a problem with the carrier board for that one, or it's not soldered quite right (did you reflow it or hand solder it?)
    – Majenko
    Apr 10, 2017 at 18:38
  • I thought about this also. It is a STM soldering and I hand solder it. I used a multimeter to check continuity between the solder and the pins and didn't notice anything unusual. I'm using a breadboard, can this interfere? My SOIC board are from adafruit, they are quite good quality.
    – rvbarreto
    Apr 10, 2017 at 18:43
  • Breadboard can sometimes cause issues with its parasitic capacitance and poor connections, yes. However I'd expect spurious results from both modules if that were the case.
    – Majenko
    Apr 10, 2017 at 18:46

1 Answer 1

0

Where this problem can be originating from?

As per page 7 and page 14 of the data sheet, there are 16 bytes of PROM in the unit which contain calibration information determined and written at the factory. This calibration information includes coefficients that must be used by whatever's reading the sensor to adjust for manufacturing variations. The data also include a CRC check code to let you confirm you've read the PROM correctly.

So there are three possibilities here:

  1. The CRC as written to PROM is wrong.
  2. There was an error while transferring the data from PROM to your MCU.
  3. The software is doing the CRC calculation incorrectly.

The source code suggests that the most likely reason for this sort of failure is faulty wiring between the MCU and the sensor.

What kind of limitations I have for not passing the CRC test? Does it mean that the collected data can not be trusted?

Potentially, yes. To determine how bad things really are and what might be going wrong you need to do a bit more experimentation.

When you call the initializeMS_5803() function you pass it a boolean parameter determining whether it's running in verbose mode. Set this to true so it prints out the coefficients 0 through 7 to the serial port during initialization. Restart your Arduino several times, ideally under different conditions of temperature, power, physical wire configuration (if any), etc., and see if the values ever change. If they are ever different from a previous run, you have either cabling corrupting the data transfer or a defective sensor. You may be able to look at which bits change, if any change consistently, to get some insight into how "random" the problem really is. (Could it be that only a certain bit pattern is being transmitted unreliably?)

If all values always read the same, compare them to the values read from your good sensor. If they're quite similar, and you're generally getting similar readings under similar conditions from both sensors, I would suspect possibility 1 or 3 above, and reckon that you're likely to be getting reasonably reliable data from the sensor. If the values are vastly different this doesn't necessarily mean that the sensor will be unreliable; I have no idea how much these coefficients vary from unit to unit.

If I use the raw readings D1 and D2 from a sensor that have failed the CRC test and pos-compensate them in the computer, will I have trustful results?

Again, that depends on whether or not it looks as if you're getting corruption on the data link. As above, if you ever read different PROM data from run to run on startup, the sensor is much less likely to be producing trustworthy data.

You could also try comparing the raw readings from both sensors under conditions as close to identical as you can make them. I don't know how close in calibration the two sensors are, but if they are close, the raw data should look similar and that would be a sign of reliability.

How to solve it?

First, determine if you are getting the same or different PROM values across multiple startups. If they're always the same, send your good and bad values to the author of the driver and ask him if he thinks his CRC algorithm might have an error in it. (Or check it yourself against the application note mentioned in the data sheet, if you feel up to it.)

If the CRC algorithm in the software you're using is correct, given that you appear to reading successfully from another sensor, I'd send the sensor giving the CRC error back to the manufacturer, along with the coefficients you had read, with a query as to whether they have got the CRC wrong or you're reading the data wrong.

If you're getting different PROM values, that's either a faulty sensor or a wiring problem. You may be able to help isolate this with the usual tricks: slow down the transfer speed (with Wire.setClock()) to see if that reduces data corruption, re-wire the circuit with different (and preferably shorter) wires and other parts, make sure you've got caps in the appropriate places to filter noise, put a scope or a logic analyzer on the SCK and SDA lines to see if you can see any dodgy-looking waveforms, and so on. If anything looks strange, you can always use your working unit for comparison. If all that still looks good, it may well be a faulty sensor.

1
  • Thank you for this very elaborated answer. You got all the points I had doubts.
    – rvbarreto
    Apr 23, 2017 at 21:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.