I am trying to use a Melexis MLX90614 with Atmega8. I have failed in all my attempts till now. I tried sending this sequence

slave address(as 0x00 and 0x5A) --> opcode to read SMBus address 
     --> data byte high --> data byte low

I get a slave address NACK for both SMBus addresses. Is it because I am using an I2C library? I understand we have to give a PEC also, but as the Slave address is NACK'd I don't think the sensor is responding to my commands. I tried using the write opcode and got ACK's for that. So the communication is ok. Can anyone tell me what kind of problem may be here?

Also how would one generate a PEC for SMBus protocol?

I looked at this code and it just sends 0x00 and 0x07 over i2c to fetch two bytes of temperature. How can that be possible? In the datasheet it is specifically mentioned how to read one word and how to write one word. How can this be bypassed?

  • \$\begingroup\$ in response to "how can that be possible" - it's a "feature" :). \$\endgroup\$
    – vicatcu
    Commented Dec 29, 2010 at 17:42

1 Answer 1



I2C and SMBUS are essentially compatible as long as you are operating at 100kHz bus speed. The datasheet on page 15 ( suggests to read a register you (as a master) have to do:

SLA+W               (slave acks)
Command             (slave acks)
Repeated Start
SLA+R               (slave acks)
READ data byte low  (you ack)
READ data byte high (you ack)
READ PEC            (you ack)

The appropriate SLA is 0x5A. Just like with I2C, you will need pullup resistors on the SCK and SDA lines (3.3kOhm should be fine). Command value will depend on what you are trying to do as described on page 16 (7.4.6).

Reality (?)

However, there is a paragraph (7.4.1) on page 13 that says:

In order to provide access to any device or to assign an address to a SD before it is connected to the bus system, the communication must start with zero SA followed by low RWB bit. When this command is sent from the MD, the MLX90614 will always respond and will ignore the internal chip code information.

... now that is a vague description of a specialization of the protocol at best, but it appears to be what the github code is exploiting.

If one is to believe the github code, it is actually illustrating an undocumented protocol behavior. Namely:

SLA(0)+W   (slave acks)
Command(7) (slave acks) (writes to the RAM read-address register the value 7 = TOBJ1?)

SLA(0)+R        (slave acks)
READ low byte   (master acks)
READ high byte  (master acks)
READ pec        (master nacks)

I've seen this "flavor" of I2C interaction before, but I'm with you that it's not described that way in the datasheet.

Sidenote on PEC

As for "how you generate the PEC" it's described on page 14 at the bottom of the page:

The PEC calculation includes all bits except the START, REPEATED START, STOP, ACK, and NACK bits. The PEC is a CRC-8 with polynomial X8+X2+X1+1. The Most Significant Bit of every byte is transferred first.

Basically it's CRC-8-CCITT (see wikipedia) - implementations exist, just google for it, or post a separate question about CRC...

  • \$\begingroup\$ I have tried all that, I also have a 4.7K at the SCK and SDA lines. But I get a NACK for 0x5A even for transmit. \$\endgroup\$
    – Rick_2047
    Commented Dec 29, 2010 at 16:06
  • \$\begingroup\$ @Rick, please see additions I've made \$\endgroup\$
    – vicatcu
    Commented Dec 29, 2010 at 16:39

Your Answer

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

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