Sensirion/python-sensorbridge-i2c-sfm

Compatibility to more SFM Sensors (SFM 3000)

dermahax opened this issue · 3 comments

I am trying to connect a SFM3000 Sensor using python.
Looking at the datasheets, the only differences that I found (between the SFM 3019 and the SFM 3000) was the default voltage (5V instead of 3.3V) as well as the sensor adress (0x40 instead of 0x2E). By cloning the class and just changing this parameter, I cannot communicate with a SFM 3000. The connection to the sensor bridge works fine.

see the following fork: sensirion_sensorbridge_i2c_sfm
When running quickstart_SFM3000.py the error code 41 raises: An I2C slave did not acknowledge the sent data.

What else needs to be modified to add new sensors?

psachs commented

Hi and thanks for reaching out.

The SFM3000 uses a different CRC function than the SFM3019. Even though they implement a very similar interface they use a different chip and therefore have some slight differences that may not be visible on a first glance.
E.g. the CRC is different, the start measurement command and read serial number is different as well. There is also no selection of measured gas for the SFM3000.

The CRC is defined in the command.py here: https://github.com/Sensirion/python-sensorbridge-i2c-sfm/blob/669b2296c5e0e9d39ad96d6238068ab1fc36d1b3/sensirion_sensorbridge_i2c_sfm/sfm3019/commands.py#L57C17-L57C45

you can find CrcCalculator(8, 0x31, 0xFF) however we need CrcCalculator(8, 0x31, 0x00) instead for the CRC calculation.
Replacing this line should fix the CRC issues.

The command 0x31AE (GetSerialNumberAndProductId) only returns 2 words with the serial number and not the product identifier.

Furthermore the way how measurements are initiated is different. I attach you the correct datasheet with the I2C communication for clarification:

Sensirion_Mass_Flow_Meters_SFM3000_I2C_Functional_Description_V1.1_D1.pdf

I will look at your fork later this week when I find some time for it.

Hi thanks for the fast response,
this helped a lot (especially the CRC). The fork now works to read out the SN correctly and the flow values.
There is one last thing I cannot figure out though: The flow values seem reasonable versus the "arrow direction" (that is printed on the sensor). However, in the other direction (flow going with the arrow), the flow values seem to have some kind of converting or overflow issue: They are reasonable for 0 to +5 slm, but then jump to -460 slm if the flow grows futher.
Based on the data sheet I use flow_scale_factor: 140 [1/slm] and flow_offset: 32000.
Any quick idea what the issue could be?

This looks like an overflow issue. I am however not sure why this happens. There might be something wrong in how you interpret the data.

I also noticed in your code that in read measurement you changed the number of read bytes from 6 to 4. This should be 3 (2 bytes flow + 1 byte CRC).