I2c NOOB QUESTION - Trying to get a MLX90614 IR Thermometer to talk to the Electric Imp

this is a non-contact infrared thermometer.

It is strongly affected by the emissivity of the surface being measured. Do you know what emissivity is set into the device? I am assuming it has that feature - hoping it has that feature.

Emissivity

One trick I have used is to put masking tape on the different things I wished to measure. after some time at steady state the tape will be at the same temperature of the object and different objects will have the same emissivity due to the fact the sensor is reading the surface of the masking tape. at least that is what I learned many years back. I’d guess things haven’t changed in this regard.

Why did you choose IR sensors? what are you hoping to accomplish?

Thanks mjkuwp94,
I’ll try to understand the spec sheet of the MLX90614 and see what I can come up with.

Being a motor mechanic, I want to measure the temperature of my front brake rotors (hence having 2 sensors on the one board is a bonus) and therefore I thought IR sensors would be the most appropriate to a high-rpm, high-temp situation.

Cheers,
duBe

I was just going to comment on the same thing, but @mjkuwp94 beat me to it. (Spot on with the emissivity comments). I played around with the 90614 when I was trying to use it to do a non-contact measurement of a reflow hot plate surface temperature.

The other thing I might add is that you could also be experiencing field-of-view effects. Not sure which variant of the device you’re using, but I believe the FOV can vary between 5 to 35 degrees or so. The measurement is essentially averaged over this window, so the geometry of what you’re trying to measure in relation to the FOV of the device matters. (I believe this might explain the differences you were seeing when you measured at different distances).

Anyway, there’s more than initially meets the eye with this device and it’s application that needs to be accounted for to make accurate measurements. (Not sure what precision you’re shooting for).

(For my project, I just ended switching back to using thermocouples).

Thanks LarryJ,
I’m really just using this project as a self-education idea as my learning style dictates that I must have a practical aspect to my learning or it just doesn’t sink in.

According to the Sparkfun website, this is a:
MLX90614ESF-BAA

which, according to the Melexis MLX90614 data sheet means:

Part No. : MLX90614
Temperature Code: E (-40°C to 85°C)
F (-40°C to 125°C)
Package Code: SF (TO-39)

  • Option Code: X(1) X(2) X(3)
    1: Supply Voltage / Accuracy
    A - 5V
    B - 3V
    C - Reserved
    D - 3V medical accuracy
    2: Number of thermopiles
    A - single zone
    B - dual zone
    C - gradient compensated
    3: Package options
    A - Standard package
    B - Reserved
    C - 35° FOV
    D - 10° FOV

So, all that taken into account, the ones I’ve got from Spark fun are:
-40°C to 85°C, TO-39, 3V, Single Zone, Standard package

And a bit of digging around reveals the “Standard package” to have a FOV of 90°.

Oh, that can’t be good, but I guess I could always try to buy a MLX90614KSF-BCC to increase the “spot temp” readings.

Thanks heaps for the “heads-up”, I really didn’t take any of that into account, just the fact that it was the only one on the Sparkfun website for sale.

And further to “emissivity” issue raised by @mjkuwp94 and yourself, the spec sheet says:

As a standard, the MLX90614 is calibrated for an object emissivity of 1. It can be easily customized by the customer for any other emissivity in the range 0.1...1.0 without the need of recalibration with a black body.

I wish I knew what that means, so I’ll keep plugging away to see if I can get a grip on that issue a bit better.

Thanks again,
duBe

Yes, I agree … no faster way to learn than to just dig in and start on a project. It’s a fun little device to play around with … just wanted to make sure you were aware of the measurement issues (beyond the i2c interfacing) which come into play when trying to increase the accuracy of your readings. Looks you’ve got a handle on the big ones now, so that should help you a lot. (BTW, I picked up a 10 deg FOV unit, MLX90614ESF-BCF, from Digikey, who had several different devices of the family).

I didn’t spend too much time playing with emissivity, but @mjkuwp94’s suggestion with the masking tape sounds like a good one. Once you understand the emissivity of the particular surface you’re trying to measure, I think it’s pretty much a one-time issue of including a cal factor as you mentioned earlier. I think you can do it in the device (EEPROM addr 0x04), but it might just be fine to include external cal factor(s) in your program.

Sounds like you’re well on your way now. Keep us updated on your progress and the results of your testing.

Thanks LarryJ,
the info on DigiKey was very handy indeed; it appears they carry nearly every incarnation of this device & more importantly, their data sheets are much more up to date.

I was able to see that I can get a 3V gradient compensated 5° FOV model which will be much more a direct reading (although it’s very expensive $50).

Cheers,
duBe

The emissivity calibration might be a bit complicated. I have similar interests so perhaps I’ll dig into that a bit more. One way to calibrate or check the brake rotor would be to get it warmed up (oven?) and instrument the surface with a thermocouple. point the IR sensor at a spot near the thermocouple but insulate every other part of the brake rotor. The idea is to get the temperature to drop really slowly over time so that the temperature through the rotor is relatively uniform.

How hot do you think they get? I’d guess very.

The regular thermocouple and IR sensor will of course show different readings but the regular thermocouple is the correct one.

Were you thinking of measuring on the shiny surface right where the pad is running?

I do all my own car repair and maintenance. Brakes are the most annoying thing to me because even when I do the most meticulous work they can get a slight ‘warped’ feel after a while.

Hey thanks heaps @mjkuwp94,
that’s a great idea; I can easily heat a rotor in a mate’s kiln & that should give me a 3rd calibration point as the kiln’s thermometer should be pretty spot on for the “ambient” temp inside it.

Being an old-school VW mechanic (I don’t even work on my wife’s new car = I do a contra-deal with a mate who races vintage mx; I tune his bikes [not very well mind you] and he services my wife’s car) my biggest problem is when my brakes are too cold and they don’t want to stop at all as the “transfer layer” isn’t “sticky” yet.

Yes; I was thinking of pointing them at the shiny part of the rotor face, right where the rotor exits the calliper so as to get a good idea of the brake temps. I could even face a second sensor at the rotor face at the entrance to the calliper, that way I can see the difference between Pre & Post brake application! Not sure what that would do for me, but an interesting diversion none the less.

Yeah; when I was younger I used to LOVE doing maintenance on my mates cars, bike & boats as it made me feel very useful. But as time goes on & technology gets further & further advanced, I’m feeling like I know less & less (which is correct). These days I stick to pre-80’s carburettor’d VW’s and my son’s mx bikes with the very rare emergency fix of a mate’s boat if we encounter problems while skiing. Even ski boats are becoming way too tech advanced for old-timers like me now, very few have carbs now & all the fancy auto-settings like “perfect-pass” & auto-ballast, auto-trim, etc have made it all too risky for me to pop my passion-fingers in there!

I agree, brakes can be a nightmare; even for a mechanic who clearly explains themselves to the customer before taking on the work & clearly explains the “bed-in” procedures, it can come back to bight you on the backside!

Short of rebuilding the callipers, mic’ing (& re-machining if necessary) the hubs, then “on-car” re-machining of the rotors & meticulously following the “bed-in” procedure for the particular pads each time you change pads, you’re always going to have a very different brake pedal “feel” each time you change pads. And even then, sometimes you just pull your hair out in frustration when it all goes south despite doing all those things. ABS has put a whole other world of hurt into the equation if the driver actively engages the system on a regular basis (some will tell you this is good practice, me thinks it stuffs brake pads & rotors very quickly).

If you’re interested to know more about the “Truth” about brakes, here’s a couple of GREAT websites:

http://www.myturbodiesel.com/1000q/brake_FAQ.htm

http://www.tirerack.com/FAQ/results.jsp?category=Brakes

Cheers,
duBe

Thanks for the links @dube68 those are good ones.

My cars are VWs, a 2003 TDI and a 2001 B5 Passat. Both are incredibly good cars imho. The TDI has 235k miles and feels like new except for slightly wonky brakes. The Passat has 175k miles and same story.

Measuring fluctuations of temperature might also be interesting. Rotors that do not have a uniform surface or are warped or worn thin/thick will probably have a temperature signature that is not consistent. This would be a pretty involved experiment though. wifi is not active in the car after all…

The emissivity of polished steel is very low. one reference I found showed this is .07

Do you know what temperature you can heat the rotors to without tempering them? I should know but I don’t. Maybe researching brakes would tell you.

Ahhh, good point about the low emissivity @mjkuwp94,
You did try to educate me about that previously, maybe I could point them at the outer horizontal edge of the rotor instead?

As for the wifi issue; I’ve got a cunning plan!
I’m going to try to hook the imp to my iPhone’s “Personal Hotspot”!

I haven’t tried that yet, so perhaps I should before I go too much further.
The alternative is, I’ve got a little 12vdc 4G mobile modem that puts out a wifi network. So if worse comes to worst, I can wire that modem into my car & hook the imp to it.

Hmmm, “tempering” you say!
Well; again, it never occurred to me (see a recurring theme here???)
I would hazard a guess it would be well beyond the range of the MLX90614’s reading range of 380°C but that’s just a guess.

Which brings me to another conundrum; what will happen to the sensor if the rotor gets beyond that max reading? Will it be destroyed or will it simply stop working until the temp lowers again?

I don’t expect to have this problem, but as I’ve never measured brake temps before, I can’t be sure until I’ve done it.

I’m actually using this project as a “learning” tool, not particularly for the application, although (for my learning style) if there’s no intended practical application, I tend to switch-off and stop learning. So I just made-up an intended practical application to keep me interested and see the learning through.

It is a great way to learn. Actually if you ask me this is the new and correct way to learn. old-fashioned schooling has shown many flaws.

check out this link.

datalogging

I suspect the sensor will do fine but that you should leave some space between the sensor and the rotor.

I wish I had more time. This is a really good project that I would also be interested to do.

This is where this project is at now:

I have 2 x Electric Imps, each with 2 x MLX90614 IR Temp Sensors (one on i2c12 and the other on i2c89) reporting temps in every 5 seconds to 2 x Xively Channels (one channel for each i2c line). I’ve set an “IF” statement in the AGENT code that looks for an “OVER-TEMP” condition and if so, sends a WARNING via Twitter.

Here’s the links to my Xively & Twitter feeds:

Imp_1 Xively:
duBe’s Imp_1 Xively Feed

  • EDIT - Imp_1 is down at the moment until I find another mini USB cable to power it, my son repossessed his cable; kids do the darndest things.

Imp_2 Xively:
duBe’s Imp_2 Xively Feed

Twitter:
duBe’s Imp_1 & Imp_2 Twitter Feed

As it’s cold here in Melbourne, AU I set the OVER-TEMP condition to be 18°C so I could get some Tweets coming through by placing my finger above the sensors.

As an interesting bonus consequence of having 2 x MLX90614’s hooked up, it’s turned out to be SUPER RARE that the EXACT SAME message will be sent out to Twitter, as both sensor readings have slight variations and one will read differently to the other, sending a different Tweet either ahead or behind the other. So, in practice, the Twitter feed in the AGENT code can be left active without worrying about SPAMMING Twitter.

Next step is to work out some real-world mounting application for the sensors themselves, so that I can point them at the brakes.

After that, I think I might look at trying to work out how to use the MASTER & SLAVE functionality of the MLX90614’s, as the data sheet tells me I can hook-up 127 sensors per i2c line.

Wow, image that!
2 x i2c lines available on the Electric Imp,
That’s 2 x 127,
That’s, umm, A LOT!

That would be cool!
I could measure EVERY conceivable part on my car regardless of how silly it would be to measure it!
AWESOME!

Hi again,
I’ve just hit a bit of a problem with my project:

I was in a hurry to wire-up my other Imp and “fried” the MLX90614 on Imp_2 i2c12.
Not so much of a problem I thought but as it turns out, this causes the code to simply stop executing the first time it is asked to check the value of i2c12.

I guess I was supposed to put in some better kind of error handling, would anyone mind helping to educate me around this kind of thing?

Here’s the code that calls i2c12:

`/*
I blew a sensor up, so gotta comment this out until I get a new one
really need to get some error handling in here to stop
the Imp locking up if a peripheral device doesn’t report in
*/

/*
local bytes_12=hardware.i2c12.read(0xb4, “\x07”, 3);
if (typeof(bytes_12)!= “string”) {
server.log("i2c12 read error: "+bytes_12);
return;
}
local data_low_12 = bytes_12[0];
local data_high_12 = bytes_12[1];

server.log("data_low_12 is: "+data_low_12);
server.log("data_high_12 is: "+data_high_12);

// The conversions below are taken straight from a bildr Arduio project
// http://bildr.org/2011/02/mlx90614-arduino/

//This converts high and low bytes together and processes temperature, MSB is a error bit and is ignored for temps
local tempFactor_12 = 0.02; // 0.02 degrees per LSB (measurement resolution of the MLX90614)
local tempData_12 = 0x0000; // zero out the data
//frac; // data past the decimal point

// This masks off the error bit of the high byte, then moves it left 8 bits and adds the low byte.
tempData_12 = (((data_high_12 & 0x007F) << 8) + data_low_12);
tempData_12 = (tempData_12 * tempFactor_12)-0.01;

celcius_12 = tempData_12 - 280.15;

*/
// wakeup every 5 seconds and read temperature
imp.wakeup(5, read_c);

server.log("The temperature on i2c89 sensor is " +celcius_89 +"C");

/*
I blew a sensor up, so gotta comment it out until I get a new one
really need to get some error handling in here to stop
the Imp locking up if a peripheral device doesn’t report in
*/
// server.log("The temperature on i2c12 sensor is " +celcius_12 +“C”);

/* 
   To send both i2c89 and i2c12 readings to Xively on different channels:
   create a table called "thermotemps" 
   which hold the variables "thermo1temp" and "thermo2temp"
   assign the value of variable "celcius_89" to "thermo1temp"
   assign the value of variable "celcius_12" to "thermo2temp"
*/
local thermotemps = {"thermo1temp" : celcius_89, "thermo2temp" : celcius_12};

// pass the above created table "thermotemps" to the "Xively" AGENT
agent.send("Xively", thermotemps);`

I just hard-coded the value of i2c12 to be “0” so that the pass to the agent would still have something to pass along.

Many thanks in advance,
duBe

generally you would use the

try{ } catch (error){ }

construction

you could try this function for experimenting…

`
function testnew(){

local _bytes = -1023;
try{

 _bytes = hardware.i2c12.read(0xb4, "\\x07", 2);

server.log("my type is " + typeof(_bytes));

}
catch (error){

//some code can be placed here
server.log(" an error occurred and was caught " + error);

}

return _bytes;
}
`

but I am not 100% sure about it. What I am trying to do there is set a value of minus 1023 to be returned if there is an error. The calling code could check to see if the returned value is minus 1023 and then it would take appropriate action - such as using your hard-coded value.

Hopefully the _bytes would be correctly typed if the i2c read function actually completes correctly but I cannot test that part of it. I ran this code in the agent to try it out.

one thing I am not great at is figuring out how squirrel does the various datatypes. That is why I have the typeof function in place.

Thanks @mjkuwp94,
sorry for the delay in replying; had a bit on my plate over the last week.

Anyhoo, I’ve decided that I’m completely stu-PID; I can’t work this out.
I’ve tried a heap of different ways to get that to work but no luck.

I reckon I “kind-of” understand your code snippets but I can’t seem to mould it to suit my actual application.

I’ll keep trying & let you know when I understand it a bit more.

Thanks again,
duBe

getting back to basics, did you purchase a bare sensor or is the part on a breakout board or module?

I have one of these sensors - just remembered - but it was packaged on a board with a microcontroller. It was from parallax. I think they said they did that so that the end user would not have to deal with the complicated protocol of the sensor.

…but that is from memory.

I just purchased the bare sensors from SparkFun https://www.sparkfun.com/products/9570
.
I didn’t know anything about it before purchasing it; I just bought it based on Hugo’s recommendation that it would work with an Electric Imp.
.
I had previously purchased an Arduino Board & coupled it with an FreeTronics IR Temp Sensor board:
http://www.freetronics.com/products/irtemp-ir-temperature-sensor-module#.UqBgFZGyhFc
.
This worked well but I found it beyond me to get it to talk with the real world. That’s what brought me to Electric Imp. I emailed Electric Imp, outlined my desired outcome and shortly after, @Matt Haines & @Hugo Finnes both replied with a few suggestions & here I am now; annoying people like your good self.