Group Actions
Engagement
  • Author Author: koudelad
  • Date Created: Date Created
  • Views 1184 views
  • Likes 4 likes
  • Comments 6 comments
Related
Recommended

IR thermometer complications

koudelad

Hello,

 

For the last week, I've been trying to get working a prototype of an IR thermometer, based on MLX90614. I ordered a DCC version, which means a 3 V power supply, medical accuracy (0,5 centigrade in 0 to 50 centigrade area), gradient compensated (compensates package temperature difference), 35 degrees field of view. My idea was to use it as a quick body thermometer, but also have to possibility to measure some interesting places from time to time - walls, windows, heating elements, ...

 

I try to work incrementally, one step at a time, here is my procedure:

 

1) Connecting the HW and verifying that it works.

MLX90614 communicates over SMBus, which means I couldn't use my favorite analysis technique - Digilent Analog Discovery 2 | Farnell element14 . I always connect new sensors to the analyzer, power them up (love the feature of integrated power supplies) and apply knowledge from studying the datasheet, how to start measuring or whether only read some output registers.

 

Maxim (but also other manufacturers) created easy to read comparison of I2C vs SMBus: https://www.maximintegrated.com/en/app-notes/index.mvp/id/476

One important feature of SMBus makes it impossible to "manually" communicate with the sensor - timeout between commands. A write and a following read operation need to be performed within 35 ms. This requires some program code, so I started writing the code for a microcontroller.

However, using an I2C interface in a microcontroller and speed between 10 a 100 kHz work OK.

 

I can read the temperature registers storing ambient and object temperature and interpret the values. The sensor responsiveness is great.

 

2) Cyclic Redundancy Check (CRC)

Another difference between I2C and SMBus is, that SMBus uses Packet Error Code (PEC) during communication. So I started studying CRC on Wikipedia.

 

The sensor supports only "read word" and "write word" commands, the data is always 2 bytes of data and 1 byte of PEC. PEC for is CRC8 with X8+X2+X1+1 polynomial.

I have no idea why, but I can't figure that PEC number.

 

There are online calculators on the internet that reveal there are many variants for computing CRC: different polynomial length, different polynomial, reflection of input and/or output CRC and finally XORing the output CRC. Wow.

 

Here is an example of my temperature readings from the sensor:

[LSB][MSB][PEC]:

0x7E 0x39 0xCB

or

0x7F 0x39 0xDE

 

Comparing this to the online calculators (polynomial is 0x107 or 0x07 if stored in an 8 bit number, no reflection, no XORing):

Online CRC-8 CRC-16 CRC-32 Calculator says 0xDB for 0x7E39 and 0xCE for 0x7F39

Sunshine's Homepage - Online CRC Calculator Javascript has the same results.

 

It is probably not a coincidence that I get calculated 0xDB instead of sensor's 0xCB and calculated 0xCE instead of sensor's 0xDE.

I just don't know why.

 

During searching the internet for some code related to MLX90614, I found out that majority of developers just ignore the PEC. It is not necessary for them to check the data validity.

However, PEC is needed by SMBus for writing data to the sensor. There is one good reason for writing data to the sensor: when you want to change emissivity and in my case, internal gradient compensation factor (or SMBus address, which I don't want to change).

 

I also found a great introduction with examples on Dr. Ross Williams' webpage. I got the idea of modulo n arithmetic, I can perform the division manually using a pen an a piece of paper, but I can't figure out, how to put this algorithm into C code.

 

I would appreciate any ideas. Should I be able to write my own (easy to read, but inefficient) algorithm or take some advanced and optimized code from the internet and test it? Should I trust the online calculators for manual verification?

I am stuck image

 

Thank you,

David

  • I would just like to post an update in case anyone stumbles upon this post.

     

    I didn't get an additional answer from Melexis nor their distributor, but I found an application note that is not available on the official Melexis site (no idea why). It describes the details of the communication in more depth than the datasheet: https://www.pololu.com/product/1061/resources

     

    It confirms what has been written above, the PEC is computed always from all the bits on the data bus (excluding the start, repeated start and stop bits).

     

    What also helped me a lot: there is an application report from TI, SLAA249 Implementing SMBus Using MSP430 Hardware I2C, which also contains firmware examples for MSP430. I used a PSoC 4 and the adjustments made to the SW implementation of the CRC8 calculation is really cosmetic.

     

    I implemented the functions in the Visual Studio, tested and debugged and then ported to the PSoC in order to save time spend debugging.

     

    David

  • in reply to gecoz

    Thank you very much, I will have a look at the example and try to implement the CRC8 function.

     

    This changes the logic of what I thought before.

  • in reply to koudelad

    Hi David,

    Indeed, as said, in the CRC calculation you need to consider the complete stream of bytes belonging to the SMBus  communication in order to get to correct PEC. For instance, if you look at the communication example on the datasheet (pag. 17 -  8.4.6 SMBus communication examples) and use the calculator you mentioned (Online CRC-8 CRC-16 CRC-32 Calculator ),  with reference to Fig.8, and write the following hex string as calculator input: B407B5D23A, you get 0x30 as PEC, as expected. (You can repeat the same with Fig. 9, and again get the correct PEC).

    Looking on the internet for an easy implementation of the CRC8 algorithm, I came across this arduino sample code, which contains quite a lot of comments on how the CRC8 is calculated. I haven't tried it, and I only had a quick look at it, but you might find it useful.

    Fabio.

  • in reply to koudelad

    BTW the datasheet only says: The PEC calculation includes all bits except the START, REPEATED START, STOP, ACK, and NACK bits.

     

    No information whether it includes an address of a device and a command (register address).

  • in reply to shabaz

    Thank you for your reply, . Good idea, I will try to ask Melexis.

     

    I actually contacted them before buying the sensor to get an advice on a device variant (especially FOV) selection. They do not provide support directly, but I got an answer (definitely from them) by forwarding the email through a component distributor.

     

    I will paste here any new information I find out. I guess it will take a few day to process.

     

    David