element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Members
    Members
    • Benefits of Membership
    • Achievement Levels
    • Members Area
    • Personal Blogs
    • Feedback and Support
    • What's New on element14
  • Learn
    Learn
    • Learning Center
    • eBooks
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Dev Tools
    • Manufacturers
    • Raspberry Pi
    • RoadTests & Reviews
    • Avnet Boards Community
    • Product Groups
  • Store
    Store
    • Visit Your Store
    • Choose Another Store
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
Personal Blogs
  • Members
  • More
Personal Blogs
Legacy Personal Blogs IR thermometer complications
  • Blog
  • Documents
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Blog Post Actions
  • Subscribe by email
  • More
  • Cancel
  • Share
  • Subscribe by email
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: koudelad
  • Date Created: 22 Jan 2018 8:46 AM Date Created
  • Views 691 views
  • Likes 3 likes
  • Comments 6 comments
  • crc
  • mlx90614
  • ir sensor
  • smbus
Related
Recommended

IR thermometer complications

koudelad
koudelad
22 Jan 2018

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

  • Sign in to reply

Top Comments

  • gecoz
    gecoz over 5 years ago in reply to koudelad +4
    Hi David, Indeed, as shabaz 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…
  • koudelad
    koudelad over 5 years ago in reply to gecoz +4
    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.
  • shabaz
    shabaz over 5 years ago +3
    Hi David, I think it's worth asking Melexis for example code. They take into account the address and the command bytes too, as far as I can tell. So, the PEC should include those bytes too (I could be…
  • koudelad
    koudelad over 5 years ago

    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

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • koudelad
    koudelad over 5 years ago 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.

    • Cancel
    • Vote Up +4 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • gecoz
    gecoz over 5 years ago in reply to koudelad

    Hi David,

    Indeed, as shabaz 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.

    • Cancel
    • Vote Up +4 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • koudelad
    koudelad over 5 years ago 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).

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • koudelad
    koudelad over 5 years ago in reply to shabaz

    Thank you for your reply, shabaz . 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

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2023 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • Facebook
  • Twitter
  • linkedin
  • YouTube