I'm using the IR Temperature Sensor from Adafruit (MLX90614) :
https://learn.adafruit.com/using-melexis-mlx90614-non-contact-sensors/wiring-and-test Wiring and Test | Using Melexis MLX90614 Non-Contact Sensors | Adafruit Learning System
Which I connected to the i2c breakout from sparkfun:
https://learn.sparkfun.com/tutorials/sparkfun-blocks-for-intel-edison---i2c-breakout-block SparkFun Blocks for Intel® Edison - I2C Breakout Block - learn.sparkfun.com
However, when running: i2cdetect -y -r 1 I see no devices. I tried with another i2c device. This address is shown. I attached the temperature sensor using the same hardware setup to an Arduino and there the device is also recognized. Any ideas on how to use the sensor on the edison? In my belief, if one i2c device works all should work, I wonder if it can possibly be some kind of compatibility issue? Any ideas on how to get this sensor to work?
About the link that you shared, are you following all the instructions from there? Are you using the same library that is being used in that configuration? About the "repeated start I2C" support, I will investigate this so I can give you a proper response.
I tried with the Arduino MLX library on the edison but only wrong values were read (same as when sensor was disconnected). On Arduino Uno all works fine. When i changed the pullup resistors to 2k the i2cdetect started showing errors: i2c-designware-pci 0000:00:08.0: i2c_dw_handle_tx_abort: lost arbitration.I am quite sure the problem is with the repeated start for now. Would be great if you could help on that!
According to the Wire.h library, which can be found under /AppData/Roaming/Arduino15/packages/Intel/hardware/i686/1.6.2+1.0/libraries/Wire/src, a repeated start can be enabled.
// Originally, 'endTransmission' was an f(void) function.
// It has been modified to take one parameter indicating
// whether or not a STOP should be performed on the bus.
// Calling endTransmission(false) allows a sketch to
// perform a repeated start.
The implementation of uint8_t TwoWire::endTransmission(uint8_t sendStop) for false condition states:
/* sendStop = false
* pretend we have held the bus while
* actually waiting for the next operation
If we go by the description, adding a Wire.endTransmission(false) should enable a repeated start. I would suggest you to try this, and let us know the results.
This did not work. I had the same result. Besides, It would not solve my problem as I'm trying to read it from Node.js. Thank you anyway.
Maybe any other ideas?
Take a look at this thread: , Diego posted a code you can use to check if there is a device connected.
Are you using a voltage level converter to use the MLX90614?
Could you check the signals between the sensor and the board?
Thank you for the reply!
1. The python link in the example no longer works, unfortunately. Does anyone have a copy of this? I also have the ADC block connected, an accelero to the i2c and another temperature sensor to the i2c. These all work well.
2. I'm using the 3.3V version of the MLX90614. On arduino UNO I connect it to 3.3V gnd, sda and scl and works well. It also works fine on my 3.3V arduino fio. Do I need something for the Edison? I'm using the i2c sparkfun block https://learn.sparkfun.com/tutorials/sparkfun-blocks-for-intel-edison---i2c-breakout-block?_ga=1.243... SparkFun Blocks for Intel® Edison - I2C Breakout Block - learn.sparkfun.com from which i conclude the level shifter is already on board?
3. The sensor is not showing up. I can not send anything to the sensor in order to start. I see the search (i2cdetect) showing up on the bus but see no response.
2. It looks like it already has a level shifter. Has you tested the SparkFun Block? Just to know that the problem is not the block.
3. Have you tried to attach the sensor to a level shifter and then to the Edison Module? With this we could check point-2. Also, are you testing the signals? With a logig analyzer or oscilloscope you could test the content of the signals in SCL and SDA.
1. Thank you ill try this but give it little chance as even the i2cdetect doesnt find it.
2. As mentioned, I use the i2c block with a couple other i2c sensors. These all work well.
3. I cannot send a start command to the sensor, so I see no response from the sensor. There is then nothing to measure right?
Have you checked this link https://m2aglabs.com/2015/02/24/intel-edison-and-i2c-sensors-with-xdk/ https://m2aglabs.com/2015/02/24/intel-edison-and-i2c-sensors-with-xdk/. In that post, he's using a similar sensor, MCP9808, which is an I2C temperature sensor and he's using the XDK IoT Edition. I would suggest you to check the connection that he's implementing in there and see if there's something that you haven't done with your configuration.
Thank you for the reply. The case is however different. The mlx is using a slightly altered version of i2c (repeated start). I could easily get other devices, including this one to work. I do however need an IR temp sensor and this is by far the best one. Although I would like to stay with a digital solution, my current plan is to change the sensor to pwm mode. All i2c (actually smbus) advice is welcome.
As you put it in your first post, a compatibility issue is also possible. But we'll investigate this to see if we can find an answer.
Thanks for the help so far. When I scope the signal on the I2c i still see a clock rate of 300 khz. The sensor is not compatible with 300khz, only 100. I tried changing the mode from fast to standard as recommended in this thread. .
When I open the mode file in VI it reads std. However the speed is still 300khz. Any ideas? Hopefully this can solve the issue.
Have you followed the previous steps that Zahid posted? I was looking at that thread and you already posted your question, but apparently this flag was already enabled in your kernel. Am I right?
In the end i struggled so long with this sensor. I could change the mode but after startup it would return to fast and would always should fast on my scope. Quite sure the problem is there. The sensor had a pwm mode. I switched to that and can now read the sensor using gpio. Thanks for the efforts. Still would like to hear about a solution using i2cc
There's also a possibility that the device ID is greater than 76. Did you check this? The device ID might be out of the Edison's range and cannot be detected by it. This might not be the issue but it is always good to check.