Q:
Can somebody tell me what materials are used to avoid the problem of formation of condensate(tool is seen to work in temperatures about 0 degrees) on window of MLX90614?
And what obstacles I will meet in my investigation of this problem(maybe it will be necessary to write some module, which will change emissivity in relation of ambient temperature) if I will not use any coverage?
|
A:
Any condensation on the window will make the IR measurement invalid. It is not possible to compensate for this just by changeing emissivity.
To avoid condensation on can heat the senor slightly (as evenly as possible) so the sensor temperature is slightly higher then the surrounding. Condensation will then form on colder objects and not on the window.
An other option might be to use a very thin coating of a hydrophobic compound.
People also use an airflow to keep the optical window free of condensation and dirt.
|
Q:
we want to use MLX90614DAA to measure the body temperature of a baby. The distance from the device to baby's abdomen may be about 30cm to 50cm. Is it possible to obtain an accurate reading? Any suggestion?
Is it possible to get an evaluation board EVB90614 with medical high accuracy sensor MLX90614DAA on the board?
|
A:
With a distance of 30-50cm, the area observed by the MLX90614DAA is also about 30-50cm in diameter. That is probably too big for babies.
Your first option is to reduce the distance.
The other option would be to use the MLX90614|BCC which has a smaller FOV (35 degrees). However, at this moment we do not yet provide this sensor with medical accuracy calibration. This is still under evaluation.
You can order the EVB90614 with our local representative. If you specify that you want some MLX90614DAA or MLX90614BAC with it, we'll include these at no extra cost.
|
Q:
I've just bought an EVB 90614, but i can't connect it with the PC using your software downloaded from your site.
When I plug in the usb cable the functional led on the evb90614 turn blue; after that when i start the pc software the led become green and then red.
The error that pops up is 'connection time out error';
On the message log i found a 'boot not present' error.
What can i do?
Can i have the .hex file of the firmware of the evb90614 (i suspect that the evb90614 is not be programmed)?
|
A:
we need you to give us more comprehensive information about the problem,....for example when you start software is there MLX90614 module on the board,and which version it is(3V or 5V),...and the exact order of your actions and error messages which appears.
Please would you tell us where you bought the EVB from?In case we can't help you,we will replace the EVB with another one.
|
Q:
I try to explain my problem better.
I've bought an EVB90614 from DIMAC red S.r.l. BIASSONIO Milan ITALY.
I've bought three MLX90614 AAA 5V window inside non automotive too.
ORDER OF ACTION:
1 - I connect the EVB90614 with the MLX90614 plugged in to the USB socket on my pc (i've windows xp home). The led on the EVB90614 turn on blue.The evaluation board is correctly recognized fron the PC as a generic HID device and the standard windows driver is associated to the device.
2- I start your sw MLX90614 configurator version 1.05.01; the sw tries to find the evb90614. For a while the led on the pcb turn green then becomes red definitely.
3- a pop up window comes out with the message "Communication error - time out"
on the console board i find the following messages:
"
[17:44:50] PSF initialized
[17:44:50] Bootloader is not active
[17:44:58] Communication error - time out
"
OBSERVATION:
i try to change the sensor, the usb port, i try the version 1.00.1a of the sw, but nothing seems to make a change.
|
A:
Dear Sear i will send a new hex file which you can load
in the EVB(In User guide of the EVB is described how can this be done),...please use SW from the web www.melexis.com (it version is 1.05.10).
|
Q:
for your help to solve my problem.I appreciate very much it.
I'm sorry to tell you the I'm not able to work with EVB90614 yet.
I succeded in upload the new firmware that you send to me, but after that, the SW (i'm using the correct version 1.05.10) tell to me that the device name is not EVB90614.
If I try to communicate it says that maybe i've uploaded a wrong .hex
Maybe a corrupted .hex file?
|
A:
We will replace the board. Can you please contact your sales person at Dimac Red to organize the replacement.
Please also return the EVB so we can investigate the problem.
|
Q:
I want to thank you for the speed and quality of your service.
My EVB90614 is been replaced, and the new is perfectly working.
Thank you very much to DIMAC Red too.
|
Q:
I am looking for an Infrared sensor for measuring TIG welding temperature at every pass (interpass temperature). Should I go for a fixed or variable emissivity instrument?
What is the difference between the two really?
|
A:
A thermometer with variable emissivity will take into account the emissivity of the object being observed. For objects with low emissivity (like metals) this is required to get a correct reading. However, if the aim is only to observe repeatability of the process, and not the exact temperature, emissivity compensation is not needed.
|
Q:
I have 2 questions:
What is the IR wavelength range that the sensor works at? I want to use a fresnel lense to narrow down the field of view.
Also. Do you have any recomendation on the type of fresnel lense i could use?
by the way the sensor is MLX90601kza-Bka.
|
A:
The wavelength range is from 6 to 15um.
We have never used fresnel lenses with good result. Be careful about stability and heating/cooling of the lens. You will have to recalibrate the sensor of course.
If you need a smaller FOV, I suggest you check our MLX90601KZA-CLA with a FOV of 40degrees. It has a PWM output instead of an analog though.
|
Q:
I am interested in using the MLX90247 thermopile to measure temperatures of 1500 - 2000 C. Basically I would like to measure temperature of molten steel. Is this possible?
|
A:
The standard MLX90247 would not work in the high temp region1500 - 2000 °C because of the wavelength which is used.
|
Q:
I'm interested in knowing more about the Field Of View (FOV) of the MLX90247:
-What are the measuring conditions?: For example, the distance from the radiation source, the temperature of this one,...
- Are the degrees related with the rotation in one plane of the thermopile? (with respect to the direct sight to the radiation source).
-With an angle of 100 degrees the thermopile still receives the 90% of the energy (the energy received at 0 degrees, I supose), how is this posible? I supposed that with 90 degrees, the thermopile will not receive any energy.
|
Q:
How far can the source be from the sensor to accurately detect radiation.
|
Q:
How far can the source be from the sensor to accurately detect radiation.
I also would like to know the sensing distance. It does not specify in the data sheet anywhere.
|
Q:
I was also curious if you had any lens' which would narrow the sensors FOV? of another technique to narrow the FOV?
|
A:
Hello,
the FOV is measured using a stable point source at high temperature(you could compare it to the tip of a soldering iron). The source is placed at about 20 cm from the sensor. The sensor is rotated in the horizontal plane.
The field of view is a complete field of view. So, a field of view of 100 degrees means that the sensor receives energy up to 50 degrees to the left and up to 50 degrees to the right.
|
A:
The absorption of infrared energy by air is very low.
So, there is in most practical applications no limitation on the distance between the object and the sensor.
However, you have to take into account that the sensor measures the average temperature of all objects inside its field of view. If you increase the distance, the sensor might see not only the obeject you want to measure, but also its surroundings. In that case, the sensor measures the average temperature of the object and its surroundings.
|
A:
Use of MLX90247 for ear thermometers regarding safety for the users:
The MLX90247 is a low-tension low-power device.
A certificate of suitability of use for medical purposes should however be obtained at the level of the ear-thermometer, by the manufacturer of the ear-thermometer.
|
A:
Lenses to narrow sensor's FOV:
Melexis does not supply thermopiles with lenses as a standard product.
The development of a sensor with a lens requires a quite important engineering effort, and can only be envisaged in the framework of a high-volume project.
Other techniques to narrow FOV: use of parabolic mirror.
Again, the development of a device with custom parabolic mirror can only be envisaged in the framework of a high-volume project.
|
A:
Digikey:
I reviewed the information on the Digikey site, and I am taking action to bring it up to date.
In fact, the MLX90247 B on the Digikey site corresponds to the MLX90247ESF-DSA in the datasheet.
The MLX90247 C on the Digikey site is no longer supported. It does not correspond to any of the 4 component types mentioned in the current datasheet.
Thank you for letting me know that the information on the Digikey site is confusing, and sorry for the inconvenience.
|
A:
the MLX90247 has a cut-on wavelength of 5.5 micrometer.
Above a few 100 degree Celsius, most of the energy radiated by the object has shorter wavelength than 5.5 micrometer and does not reach the thermopile sensor. So, the standard MLX90247 is unfortunately not useable for temperatures in the order of 1500 to 2000 °C.
|
A:
We can make a custom sensor for high temperatures using a window + filter supplied by the customer. However, we are currently not equipped for characterisation of the resulting component up to temperatures in the order of 1500 to 2000°C. A quote can be made on request to your local sales representative.
|
Q:
Could the MLX 90247 sensor be used for ambient temperature measurements? Are its readings affected by moisture or wind?
|
Q:
Yes, MLX90247 consists of IR thermopile sensor and a PTC RTD element. The TO39 package has high thermal conductivity, so heat transfer through the pins might result in sensor die temperature different from the ambient, and therefore some care should be taken to ensure the heat transfer is to ambient and not PCB or wires, for example. As a typical PTC, the sensor transfer function is R(t) = R0.{ 1 + (t-t0).TC1 + [(t-t0)^2].TC2 }, and the TC1 and 2 are defined for t0=25deg.C. Sensor itself is not provided calibrated, so the 3 values R0, TC1 and TC2 will vary from sensor to sensor and calibration will be needed.
As the sensor package is hermetically sealed neither moisture nor wind will affect the sensor itself. However, external leakages (between the pins/wires/solder pads/PCB traces...) are not covered by that sealing and therefore moisture (especially condensing) would require their prevention. Leakage that results in 10 MOhm shunt to the PTC RTD connections may result in up to 1deg.C error in some cases.
As a matter of fact, wind is most likely to improve measurements accuracy as far as it improves the thermal contact (convection) between the sensor and the ambient (assuming the air temperature is of interest).
|
Q:
What is the 90247's Detection Wavelength. I find it no where in the PDF.
I'm looking for 5-8um to 14um range.
|
A:
The 90247's detection wavelength is mentioned on page 3 of the MLX90247 datasheet, in the specifications table, under the title "spectral sensitivity". The spectral sensitivity is higher than 70% in the wavelength range 7.5 to 13.5 micrometer. The long-wavelength pass filter of the component blocks all radiation having a wavelength below 5 micrometer (spectral sensitivity below 1%). The datasheet can be downloaded on www.melexis.com.
|
Q:
The MLX 90247 field of view is 100 degrees for the DSA type. How does this angle translate to linear distance. In other words, how far can the sensor read. Also, is it possible
to increase its field of view by using lenses?
|
A:
A FOV of 100 degrees means that the diameter of the object viewed is 2.4 X distance. The further the sensor, the more area is observed.
Theoretically it is possible to increase the fov with an expensive lens. I have never heard of actually doing that however. The trend is more that people want to reduce the FOV.
|
Q:
I have a MLX90247 thermopile and I am having some trouble getting a usable reading from it. When the output is connected to an oscilloscope, all I see is noise centered on ground, with a magnitude of about 5mV. The data sheet states that the output should be approximately 40uV/K. That should translate to about 11.8mV for room temperature. When I hook this thermopile up to a non-inverting amplifier, I see the thermopile output change to 400mV. I cannot explain why that is happening. Can someone please describe a basic circuit that can amplify this signal to a usable range (0-3.3V).
|
A:
A thermopile sensor measures the temperature difference between its own temperature and the object it is looking at through the window. If the sensor has a temperature of 20C and the object a temperature of 40C, the output will be approximately 800uV.
A basic schematic to amplify the thermoplie signal can be found at the bottom of page 6 of the MLX90247 datasheet.
A digital solution which also makes it possible to measure the resistance of the integrated thermistor can be found at:
EDN issue 2003, April 3
http://www.edn.com/article/CA286247.html?spacedesc=designideas&industryid=44217
Please note: to have an accurate temperature measurement, both the thermopile output and thermistor must be calibrated, which is not a simple task.
|
Q:
The datasheet I got from the melexis website only has 4 pages. Can you point me to this more lengthy datasheet you mentioned?
I understand the need to calibrate to measure absolute temperature, but in my case I am using two thermopiles in opposition to measure a difference. So I'm not worried about any calibration. So far, I'm not even sure that my thermopile is working properly at all because I can't see any usable signal, it just looks like noise on the scope. Maybe the better datasheet will help.
|
A:
Nevermind on the datasheet, I just found the newer version.
|
A:
To measure a difference make sure both sensors are as much as possible at the same temperature.
Regards,
Luc Buydens
|
Q:
Hello,
I am pretty much having the same results as you do. Did you find out why?
When I look at EDN issue 2003, April 3
http://www.edn.com/article/CA286247.html?spacedesc=designideas&industryid=44217,
One thing I see is that VSS is connected in between OUT+ and OUT-. Does this prevent from using single ended amplification at the output of the thermopile? In signle ended amplification, it looks like only OUT+ would get amplified.
|
Q:
I am now using the MLX90247 to measure surface temperature. The readings seem to be accurate at low temperatures; but at higher temperatures, such 100+ degrees F, its readings are off by 20-30 degrees F. Does this mean that the sensor needs calibration? and does emissivity of the object being measured also affects the sensor readings? If so, how can I compensate for low emissivity values?
|
A:
The MLX90247 is a thermopile sensor giving a voltage output depending on the temperature of the object it sees. However, this is a purely analog device without any internal calibration. If you are making a thermometer, you will have to calibrate the setup (MLX90247 + electronics) you made yourself.
Our new MLX90614 on the other hand is a smart sensor with integrated electronics and comes factory calibrated.
Emissivity of the object does influence the sensor reading, but in general this is only an issue for metals which have a low emissivity. Compensation for low emissivity can be done through calculation if you know the emissivity of the surface you are measuring.
|
Q:
Now how can I reduce the MLX90247 FOV? and where can I purchase such part which adjust its FOV?
|
A:
To reduce the FOV you can either use a metal cap with a smaller aperture or a lens. The choice really depends on your application.
The lenses can be plastic or silicon. Plastic is only usefulif you do not want to do an accurate temperature measurement.
Most of the silicon lenses are custom designs.
Simple plastic lenses can be bought at www.fresneltech.com.
|
Q:
I plan to use this sensor to measure ambient temperature in an industrial environment. I need a +/-1 degree Celsius precision. Will this sensor be suitable for this application? If so, would you recommend a metal cap or a lens to reduce its FOV? and if you recommend to use a metal cap then what is the aperture size if I want to reduce the FOV to X-degrees?
|
A:
Making a thermometer with a +/-1 degree accuracy with the MLX90247 will be very difficult, certainly for small FOVs. I advise not to use this component. We do have calibrated IR thermometers. This is the better choice for your challenge.
|
Q:
Does anybody know if these products are RoHS compliant? The Lead Free statement from Melexis doesn't shed too much light on this particular part. Any help would be appreciated.
|
A:
Melexis confirms that the MLX90247thermopile devices, the MLX90614 and MLX90615 infrared thermometer sensor family and the EVB90614 and EVB90615 are RoHS compliant.
|
Q:
I would like to know the sensitivity of the thermopile please I red it was about 0.05 degree, do you are agree with this data.
thanks for any help,
john
|
A:
As indicated in the datasheet of the MLX90247 thermopile, the sensitivity is typically 34 microVolt/°C for the version with window of 2.5 mm diameter, and typically 46 microVolt/°C for the version with window of 3.5 mm diameter.
The thermopile has a resistance of 60kOhm. This resistance is the main noise-contributor (thermal noise): 32 nV/square root (Hz). The total noise depends of course on the bandwidth of the circuit used to read out the thermopile, and this total noise determines the resolution of the temperature reading.
|
Q:
Can you recommend a lense to use in front of my MLX90247B? The specs provided are fine, I just need something that will mechanically seal the device.
|
A:
For best performance we recommend Si-lenses. These can be obtained from several suppliers. However, these suppliers use to ship you the lens without a holder. If it concerns an experimental setup, it is best to make a tooled part to hold the lens. For more details you will need to contact an application engineer through your local Sales Representative.
|
Q:
Hello, I have read an interesting article about the MLX90611 Thermopile Array Module. When will the MLX90611 be available?
|
A:
At the moment the MLX90611 is not in production.
|
Q:
What is the range of distance from measurement point to sensor to garantee the temperature accuracy? Is lens changeable to accomodate longer or shorter distance?
|
A:
The distance does not influence the measurement accuracy as long as the object fills the complete field of view (FOV), so the sensor only sees the object that must be measured.
It is possible to put an IR lens in front of the sensor to change the FOV. In that case however the user must recalibrate and make adjustments using the build in emissivity coefficient. We cannot guarantee accuracy in that case of course.
|
Q:
I have problem to calculate the PEC.
I have tried the CRC-8 calculator from
smbus.org, but it will not fit.
Please give me short sample of code how to calculate the PEC. I am using a PIC16F648A from microchip.
|
A:
The PEC on the engineering parts you have works but with increased timing. (this should be solved in the production version of the sensor).
An app. note with software is currently being approved and should be on our website very shortly.
|
A:
an app. note with software for the PIC is now available:
http://www.melexis.com/Asset.aspx?nID=5229
|
Q:
Hello. I experience the same problems as mentioned above. I don´t get proper(/expected) PEC when reading from device (MLX90614ESF-BAA-N)...I checked my CRC8 computing function and it returns the same values as a CRC calculator from smbus.org (http://www.smbus.org/faq/crc8Applet.htm). I don´t fully understand the reply - "The PEC on the engineering parts you have works but with increased timing" - is there any possibility of getting right values of PEC from the sensor samples we have (i.e. by changing some settings) or you just claim that it would be OK in production version? (I tried different bus frequencies with no effect on result .. I use I2C interface of LPC2103 for communication)
example of data transfer (hexadecimal values):
b4 // address 0x5a, write
07 // command RAM access - Tobj
b5 // address 0x5a, read
89 // received low byte
3a // received high byte
3b // received PEC
.. but I would expect PEC to be "ab" (calculated from message b4 07 b5 89 3a)
When I evaluate CRC8 on the whole message (including the PEC from sensor) I would expect 0 as a result(in case of proper PEC). But I get "f9" .. suprisingly I get this exact result with every temperature reading(different temperature values) from this RAM address ... (I somehow feel that this wouldn´t be true in case of broken data packet) ... Please notice me, if I do something wrong (maybe I don´t calculate PEC from right message .. but I tried to computed it only from fractions of the message with no effect – i.e. from received data bytes only and so on)
Not only I experience problems with PEC computation, but also the device sometimes NACKs after the first byte sent (b4) –
|
Q:
The Errata sheet of the MLX90614 that describes these problems and suggested work arounds is available through an applications engineer, who you can contact through the local sales rep. They can coordinate the resources and deliver the desired material.
|
Q:
I'm trying to connect MLX90614 to PC Comm port using Delphi, but I can't recieve acknowledge bit from the device... It seems, MLX90614 is in sleep mode. I think that this causes by Windows, that interrupts procceding of sending Slave address and MLX90614 entering Sleep mode(because of some time threshold has exceeded).?
|
A:
MLX90614 enter in sleep mode if you put it in sleep mode with special command and can be awaken by special way(see MLX90614 datasheet). If you havn't sent sleep command to MLX90614 it will not be in sleep mode, so i think the problem is different.
Before try anything i advise you to read AN "SMBus comunication with MLX90614" on www.melexis.com.
Also i suggest you to use slave address 0x00 to comunicate with MLX90614 till you drive the communication.
Be shure that all electrical specification are keeped.
You can try to power on MLX90614 and check the pin SDA/PWM for PWM signal(pull up to this pin is also needed). If on this pin there is PWM signal this mean that the module is configured in PWM mode. To do SMBus communication in this case you must to switch the module in SMBus mode(See in MLX90614 dataseet or in AN"SMBus communication with MLX90614" how this can be done).
|
Q:
All this steps I have already done...I've connected this MLX90614 to PIC12F675 and it works! But it does not work with Comm port, also, current consumption is about 2uA, that fit to current consumption in Sleep mode...Maybe I do something wrong???
|
A:
Please contact an applications engineer via your local sales channel. Use www.melexis.com/contacts.aspx
|
A:
Voltage levels on standard PC COM port are often well outside the SMBus specification, so I would also like to have a look at your schematic before giving detailed advice.
I could recommend that you read and store the EEPROM content. If you can send me or give here this EEPROM it might also be helpful for us.
elexis
|
Q:
This project is not the first in my life and I actually know that standart levels on PC COM port are often not in SMBus specification, so I use LDO for providing voltage level about 3 V and stabilitrons to protect pins.
Now I'll try to create the same diagram on base of PIC12F675 and after that, I sure, I'll know what's the problem!!!
But I have some questions about errata, such as:Has emissivity compensation problem been solved?
I note that Errata sheet is dated by 18.10.2006 and Datasheet-14.02.2007(Rev2). I know that this problem can be solved by using programm metheds, but it will be more comfortable if this function will be realised in MLX90302.
|
A:
Emissivity compensation is OK with all devices except the ones with the first silicon.
I would again ask you for your schematic. It can save time. Zener diodes can have significant capacitance (for example, BZX79-C4V7 http://www.semiconductors.philips.com/acrobat/datasheets/BZX79_3.pdf has 300 pF capacitance) and the SMBus is sensitive to capacitive loadings.
You may try to also slow down the communication. While you are in the specified high state time (SCL line) you can increase other timings and thus decrease the sensitivity to capacitive loading. MLX90614 can be used with clock well below 10 kHz.
|
Q:
Hi! Thanks again for your help, but I just have successfully complete my "investigation". Now it works!
|
Q:
I have another one interest: where can I get full table of RAM memory for MLX90614? There are many links for intermediate results of computation, but table of RAM adresses is not realy full,unfortunately...
|
A:
MLX90614 is a thermometer... So I wonder what more than temperatures you need to read from the device? There is raw data also,
0x03 for ambient
0x04 for IR sensor 1
0x05 for IR sensor 2 (irrelevant with single zone devices).
The rest of the RAM is used by the MCU program and you can't get any useful readings from it...
|
Q:
I actually know, that MLX90614 is a thermometer, but I want to use it with smaller FOV and I need to know intermediate results to understand the calculating process...
So, I would be grateful to you for your help with RAM table...it can save a lot of my time...
Or can you give me some recommendations about using external optics?
|
A:
This will need to be answered by an applictions engineer offline. please contact your local sales rep via www.melexis.con/contacts.aspx
|
Q:
Hello Andrey,
we are using the MLX90614 in an application that reads the temperature values over the SMBus. Actually two sensors are connected to the bus, located on the addresses 2 and 3.
The reading procedure is the following:
- Read Sensor 1
Wait 25ms
- Read Sensor 2
Wait 50ms
Redo from start
After some time (between 10sec and 5 min) of reading values without any problems suddenly one of the sensors (not always the same one) fails to be accessed over the SMBus. We observe that the values taken right before the fail are totally nonsense. An example below (the values have been recalculated to reflect units of 0.01°C):
2932 (Meaning 29.32 °C)
2932
2932
10260
32096
24662
19290
SMBus Error now.
Do you have any explanation/ideas to that?
Thanks a lot and regards,
Thomas
|
Q:
here's another example of logged readings (we always log 8 readings before filtering them):
24664
19290
SMBusError now
0
0
1316
2148
2148
As you can see it is the same sequence of events and numbers as in the last post starting at the value 24662.
Where do these 'magic numbers' come from?
I will now try to log longer sequences to see when the sensor stabilizes to the correct value again.
Note: When the sensor does a NAK on the SMBus we always generate a stop condition on the bus since we saw that the sensor is not accessible again after a NAK if it doesn't get s stop sequence. Is this a known issue?
Could you please provide me with the erata sheet for the sensor, I can not find it on the web.
|
A:
May I ask you to read the last 4 EEPROM addresses and send them to your applictions engineer, please?
Behavior you describe is strange to me, too. Could you try to increase all timings of the SMBus twice and see if the problem persists?
|
Q:
here are the requested values for the last 4 EEPROM addresses for every sensor (addresses 0x1C, 0x1D, 0x1E and 0x1F)
Sensor1:
0xA1EA
0x2AFF
0x3290
0xC880
Sensor2:
0xA1D3
0x2AFF
0x3290
0xC880
Haven't made experiments with the SMBus timing up to now.
|
Q:
I've now increased the number of captured samples (same timing, still) to 16 and have got the following sequence for example. From my point of view this looks like if the sensor after the strange events recovers within appr. 10 or 11 readings to the target temperature which, in our application, would correspond to appr. 750ms:
10338
32108
24670
19298
SMBus Error now
0
0
1336
2172
2562
2562
2752
2842
2890
2912 This seems to be quite OK again
2930
|
Q:
I just realized that it isn't an SMBus access error that occurred but instead it was a check against a returned value from the sensor of > 0x7FFF that we had in the software what made the corresponding function to return with an error.
So, with this new information I realized that in the situations where I mentioned that the SMBus fails the SMBus worked correctly (including PEC check) but the original value returned from the sensor was > 0x7FFF what equals to 655.34 K = 382.34 °C!
One value I just obtained for example was 696.10 K = 423,10 °C!
Does that change your failure analysis result, i.e. is that something you already know?
|
Q:
one more thing I have to correct:
The '0' values in my readings report are probably not zeroes but negative temperatures (i.e. below 0°C). This is because my driver software clips negative values to 0 after conversion to °C.
To summaries it seems like if the sensor sometimes suddenly shows several totally strange values and then slowly settles to the correct target temperature again. It really seems to be a swing over effect with slow decay.
|
Q:
I have come into collision with new trouble...
If I try to change emissivity(EEPROM 0x04) it looks like some of filters are damage and do not works properly until I shut down power and switch it on again...
|
A:
I am sorry this is not clarified in the MLX90614 data sheet.
Some EEPROM settings take effect immediately others only after Reset. For simplicity I would recommend that you assume all changes take effect after Off/On. Make all changes in EEPROM, power MLX90614 down, power it up and then use it to measure.
In case power management of that kind is not convenient in your case you can use the exit from sleep mode instead. Change the EEPROM as you need, send via SMBus the command “Enter Sleep Mode” (Opcode 0xFF), [here in the data sheet the clock goes low but I think you do not need that in your case, just send command 0xFF as a normal SMBus command and exit with both SCL and SDA high], then force “0” on SDA line (keeping SCL high) for at least 130 ms, (if filters are used add some more time for the to also settle) and then read.
|
Q:
I have some problems to understand the meaning of the RAM register. For example in the User manual there isn't any informationa about location from 0x03 to 0x05 but i found this informations in the SMSbus communication . Also there isn't any information about conversuion in the user manual. I hed tried to communicate with the sensor, i can read and convert the RAM location from 0x06 to 0x08 but i i try to measure the temperature of OBJ1 this increase up to 32/33 degree and after remain in this position even if the object reach the temperature of 250 degree !!!. I che the location 0x04 and this change increasing the value but i don't know how to use it andhow to convert to a temperature. have you some othe application note or for example a pseudocode of the PC software used for the EVA board?
|
A:
There is a straightforward dependence between the numbers read from RAM and the temperature. One LSB is 0.02 deg. Kelvin. 0 deg. K would be 0x0000, 0.02 deg.K would be 0x0001 ... 0 deg. C = 273.15 deg.K would be 0x355A, +25 deg. C - 0x3A3C, +37 deg. C - 0x3C94 etc.
This is valid for all 3 RAM locations with temperature results,
0x06 - Ta
0x07 - Tobj1
0x08 - Tobj2 - note that this address would read irrelevant data with a single zone device (MLX90614xAx)
All other RAM locations are used for intermediate computations and are of no interest for the customer.
Unfortunately we do not cover PC SW in Application Notes. However, we have Application Notes for the SMBus and it's implementation in PIC MCUs.
|
Q:
Thank you for the fast reply.
I understand that we must use only this three location.
In your site there is some different document that can create confusion infact in the user manual there are only the three register from 0x06 to 0x08 but in the SMBus descriptions document you can find the other.
However now it's OK.
|
Q:
I have a problem with the MLX90614BAA. I want to measure the temperature of a humans head. Even though the object is completely in FOV, the measured temperature strong depends on distance.
I already changed gain and emissivity but it didn't work properly.
Which parameters have to be changed, or is there any possibility to ease the distance effect?
|
A:
gain and emissivity will not help in this case. How did you change gain? Normally that should not be altered by the user.
Your problem may have 2 causes: either the head is not covering the whole FOV (in the figures you can see the sensor has a tail outside the 50% FOV) or the temperature of the head is not uniform (the hair will have a different temperature from the rest).
For a possible solution, I would advise you to use one of our new sensors with an FOV of 35 degrees (MLX90614BAC). You can ask a sample with our distributor. The datasheet will be published on the website shortly.
|
Q:
My 90614 has an SMbus address of 0xb6 = 0b10110110, if I interrogated the EEPROM correctly. Do all devices have this address by default, or do units vary?
|
A:
By default all MLX90614 should have slave address 0x5A=0b01011010 written in the low byte of EEPROM address 0x0E (the high byte of this address has no meaning, it may contains any value). The maximum slave address must be 0x7F=127decimal because maximum 127 modules can be connected to SMBus.
Check if you do access to EEPROM and not to RAM. If everything is OK probably your module contains this value by mistake. If this is the case only the first 7 bits will be recognised from module, i.e. 0x36 will be the address.
Also you can send me all EEPROM content you read.
NOTE: After your communication is OK before to change EEPROM read all EEPROM and save it for reference.
|
Q:
I was actually reading the hi byte of EEPROM address 0X0E by mistake, but I think the table on page 11 of the datasheet (03-11-07) suggests the hi byte? Was I reading that table wrongly? I will read the low byte tomorrow and I expect it will be 0x5A as anticipated.
|
Q:
I am designing a handheld box. I need to have an ambient temperature sensor on this bix. My current solution using a thermistor is picking up heat generated from within the box, like battery charger, LCD etc.
Can the MLX90614 be used in this application to pickup only the amibent temp. Around 3cm from the sensor
|
A:
MLX90614 has internal calibrated ambient temperature sensor in the range -40 till 125 degrees Celcius. So if this temperature range fit of your application i think that you can use it.
|
Q:
I am designning an ambient temperature sensor on a handheld box.
I am currently using a thermistor. As the box is generating heat from the LCD, Battery charging and other circuitry. The thermistor is picking out the heat measurement of the internal heat.
I am only interested in the ambient temperature and not the internal heat. Can MLX90614 help in this app?
|
A:
MLx90614 has an internal calibrated ambient sensor in the range -40 to 125 degrees Celsius. If this range fits in your application you can use it.
|
A:
The MLX90614 will measure the temperature of the objects in its FOV. So if your "ambient temperature" is the temperature of what the sensor can look at the MLX90614 will do the job. The heat generated in the box would not influence the measured temperature if the heat generation is not too big and the heat generating parts are not too close to the sensor. Depending on your application you should chose a BAA or BCC sensor.
|
Q:
Can anyone tell me what kind of distance from the object this sensor works best at? Should I be sensing 10mm from the object or can it go up to 100mm???
|
A:
The answer will depend on the size of the object being sensed. The FOV, field of view, of the sensor is a conical projection from the lens of the device. At 10mm the IR energy being measured is averaged over a small area. At 100mm it is proportianally larger. If the object emitting the IR energy is large then at 10 or 100 you might have the same result. If it is small then at 10 you might have a good reading but at 100 you might be averaging over the object + surrounding objects or background emissions. Can you share more specifics about the object you are trying to measure and the application you are trying to do?
|
Q:
I am using the sensor to measure the temperature of a liquid inside of a cuvette. We have been getting less than par results from the sensor. It seems that the FOV of this version of the sensor is too wide, we will be looking into one with a narrower FOV. Also I have noticed during testing that when I am constantly monitoring the temperature as it rises and falls from room temperature to body temperature, there seems to be a cyclic effect from the output of the IR sensor. What I mean by this is that as the temperature is rising it will constantly rise from say 23 C to about 28.88C, once it hits this value, it returns to 23C and the entire process starts over again. The same thing happens during cool down, it will go from 29C down to 23C and jump back up to 29C over and over again. Do you know of any reasons for this?
|
A:
We have never encountered such behavoir before. Is it possible to send me a trace of the measurements you did? Preferrably the raw IR data and the calculated temperature.
|
Q:
I am using an I2C driver that comes with my Arm7 to connect to the MLX90614BAA. It seems to work fine for me as long as there is no other device in the line.
But i want to use an I2C temperature sensor as well (TCN75A) and every time I read the TCN75A the MLX90614 gets into a state where it does not respond to read / write messages any more. (No Ack)
I did some try and error and found out that when i pull SCL and SDA low for 10µs the MLX90614 becomes operable again.
I wanted to ask why this works and if it is a reliable method.
I am also not sure why the TCN75A somehow influences the MLX90614. I checked the addressing and all is fine.
can you help?
regards,
Franz
|
A:
This is quite puzzling situation.
I've checked the address of TCN75A and it is 1001XXX (where XXX id hard wired on the device it self) so normally there should not be a problem of addressing, however MLX90614 responds on two addresses
1. The one stored into EEPROM (factory default 05A)
2. and address 0x00 - all MLX90614 will respond to this one
So please check you protocols and communication for addressing 0x00 which may lead to conflicts
Concerning the way you "restore" MLX90614 into operation is rather strange and at the moment I can't say if this is OK as I don't understand the mechanism - I guess you simply do "STOP" condition (rising SDA while SCL is high) that is way the operation is restored and if this is the case yes it is OK.
I would suggest to try to hold both lines SDA and SCL high for about 100us (this will cause "time out on SCL line" and first thing after that try to address MLX90614 -> you should have normal operation.
|
Q:
how i can find erratta for this sensor?
|
A:
You don't need errata -> please check you other topic for the answers you're looking for.
If there still is a problem we will be more that happy to assist you to get it right.
|
Q:
I'm curious about the effect of direct sunlight on the sensor. I have the sensor mounted in the open air (through a hole in a plastic box plugged with silicone sealant), pointing directly at the sky to measure the temperature of incoming IR radiation. I notice that in direct sunlight my system records oscillations of about 4C in cycles over about 30 mins each, despite constant external conditions. When the unit is in shadow these oscillations go away. Any ideas what is causing these oscillations or a way to reduce them?
|
A:
We do have evaluation of the performance of the device and depending of the readings when a sun light hit directly to the sensor window and the max deviation that we observed was in a range of 1DegC max and I must say that the impact was instantaneous while you have oscillations with very long period ~30min.
Did you check the behavior of the ambient channel during that experiment?
Ambient temperature should show what ever your conditions are stable.
I can explain the deviation but no idea what so ever about that the deviations are periodical - is the period stable or can be correlated with something else.
You mentioned that the sensor is plugged with silicone sealant -did you must make sure that no part of that sealant are within the FOV of the device as every change of the silicone temp will be "seen" by our device.
Would it be possible that you log and send to me (aga@melexis.com) following information so we can analyze it and eventually see what is happening:
1. EEPROM dump
2. Log of following RAM addresses while the phenomenon is present (I assume that the device you use is MLX90614) 0x04, 0x05 and 0x06
|
Q:
I have a MLX90614 which I have connected to an Arduino board for testing. I am getting strange results back after any commands sent. I have a timing image I've captured an annotated with a primitive logic analyser. The general flow of the data is this:
-start
-send slave+rw
-get ACK
-send command
-get ACK
-send stop bit
-send start bit
-send slave+rw
-get ACK
-get 3 bytes of 255,255,255.
-send stop
I am not sure if that stop bit should be in the middle. The programming library I'm using seems to send it and I am not sure what is happening. I can email someone the timing diagram if they are willing to help. I've tried 3 seperate sensors for this and its the same problem.
|
Q:
The link below is the timing diagram I am producing:
diagram
|
Q:
Instead STOP-START bit after the command byte you must send REPEATED START which is different.MLX90614See fig.4/page 5 from http://www.melexis.com/Assets/SMBus_communication_with_MLX90614_5207.aspx
|
Q:
I have read page 5 of Melexis_0005207_390119061402P004.pdf more than 20 times before but I did not see your advise "REPEATED START" after sending the command byte. I also read your code for PIC uC (my code for PSoC) but it does not help to solve the problem. I can get the third acknowledge (total three) from slave address 0x5A (0xB4 , 0x07, 0xB5) but Slave respond data bytes (low byte, high byte, PEC) are always 0xFF ,0xFF, 0xFF. Any more ideas?
|
A:
I've check the communication and I see that he is doing STOP the START again.
This is wrong - once you send STOP MLX90614 cancel the whole communication and release the lines, then you send again 0xB5 but for MLX90614 this is beginning of new communication.
The correct way is that at the place where STOP/START is to make just START condition.
Possible reasons for canceling the communication are:
1. Time out of SCL line - occur if you hold SCL line "high" for more than app 50us and "low" for more than 32ms.
2. A "STOP condition" occur - rise SDA line while SCL is high (doesn't matter that after that you send START condition again)
3. It is possible that you don't send "Repeated Start" (RS) after 0x07 at all.
|
Q:
Thank you for help. After I take care the accident "STOP CONDITION" - rise SDA line while SCL is high, I only got slave ACK after send Slave 0xB4, but NACK after send command 0x07 and ACK after sending 0xB5 . Now the problem is the slave does not acknowledge the sending command 0x07 and not relate to repeated start.
My calculation of SCL frequency is arround 50 kHz. I will make sure this timing on oscilloscope or sound recorder in PC ( Hope it can record the FEQ arround 20kHz)
I am worry it was damaged because the PSoC port sourced power upto 50mA while the Melexis SDA is only sink 2 mA in one mistake configuration. Could this made something wrong with the MLX90614?
|
A:
Since the device responds I don't think that you kill it with this 50mA.
So you have ACK after 0xB4 - that is OK - this mean that the device recognize the command and the address and confirms it, then you send 0x07 (Read RAM address 0x07 - Tobj1) and you don't have ACK, then you send 0xB5 and again have ACK.
During send 0x07 command you have done something wrong and the device doesn't respond and when you attempt to send 0xB5 our device recognize it as beginning of new command that is why it respond with ACK thus we have to focus on 0x07 command.
Could you please check and verify that:
1. There are no change of SDA and SDL line at the same time
2. There is no high level of SCL line for more that 50us - this will lead to time out
|
Q:
I connected the SDA and SCL signals to PC via Line-in sound recorder . I found the mistake timing due to serial communication RS232 with 9600 bps taking to much time and effect the timing of SCL. I fixed it.
Now , It works !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Thank you very much for all your help.
|
Q:
I checked again Melexis 's sample code and I believe there are nothing wrong with it. But I found serious Cypress PSoc C complier 4.4 problems: the returned function returns nothing !!!
unsigned char TX_byte(unsigned char Tx_buffer) {
// ..............
}
return Ack_bit; // Don't work with PSoC complier
The above "return Ack_bit;" does not work!!! That is the reason I had to be crazy because Melexis 's code use a lot of returned functions.
|
Q:
I try to use the MLX90614 for the measurement of the downwelling longwave radiation of clouds to detect clear sky. Can you send me a graph of the wavelength sensitivity between 5.5 and 14µm?
|
A:
the transmission passband of the filter used in the MLX90614 is 5.5 to 14 um.
|
Q:
thanks for quick reply. Is the transmission curve of the filter flat or has it some wavelengths with lower transmission?
|
A:
It's basically flat with only small variations.
|
Q:
I am looking to info with regards the spot diameter as I move away from the object I am measuring.
is there a table D:S
Distance : Spot size
the 10 degrees only helps if I know the sensor size.
Thanks Arie
|
A:
The topic with the FOV of the devices is very tricky one as most of manufactures give FOV at 50% of the signal (which is the meaning of 10Deg in DS)while for most application it is interesting at what distance the device will measure with in the specification.
Well for ACF and BCF versions of MLX90614 the real D/S is 1bout 1/1.
|
Q:
I'm trying to use the MLX90614 in analog voltage output mode (PWM-to-voltage conversion). Can anyone suggest a few suitable ADC converters for such configuration?? The App. Note shows different circuits for different ADC's, but did not suggest any ADC names/models.
Also, if anyone has tried using the MLX90614 in such mode, I would appreciate if you can share your experience on it.
|
A:
In the app. note, the OpAmp AD8603 from Analog Devices is used, which works quite well. Your other option is to use a microcontrooler with SMBus protocol and an ADC for the analog output.
|
Q:
I'm trying to find out some ADC converters name/model so I can use the MLX90614 for analog output.
Not sure if I expressed my question clearly from looking at your comment.
|
Q:
The AD8603 is an operatinal amplifier that goes before the ADC converter, what I need is the name/model of the ADC converter that is suitable for operating the MLX90614 in analog output mode.
|
Q:
I want to use the MLX90614 in the analog mode (with the PWM output) for our measuring device. The sensors are standard configured to SMBus. Is it possible to set the PWM output mode without using µC?
or may i get them in pwm mode??
I want to use this sensor, cause i believe we change the software i a few years to use digital sensors and so i don´t have to change the type of sensor.
|
A:
the MLX90614 is configured by changing the content of the EEPROM. This is only possible with a uC (or our EVB).
For evaluation purposes we can provide you samples wiht PWM preprogrammed. Please contact our sales rep. to request such samples. You will have to indicate the temperature range and P/P or O/D configuration.
|
Q:
Hello, if I want to constantly measure te temperature of objects with different emissivities (liquids of different colours) is there any other way to do it rather than measuring the real object's temperature at a certain point and use the emissivity calculation routine in the software? Emissivity is different at different temperatures. I am trying to make the accuracy of the sensor better because I am getting errors of about 3 degrees, I don't know why...so what I am trying to do is find a relationship for the error at different temperatures, but the sensor doesn't seem to have a very regular behaviour. Once the measuring conditions change a little bit, the results change completely.
|
A:
emissivity is temperature dependent, but not so much.
I expect that the problems you have have more to do with what and how you measure.
With the information you give it is hard to comment on what is the issue really.
|
A:
I suspect that part of your variability of results relates to reflected images, which might include surfaces at a wide range of temperatures?
Check carefully the field of view, is it well inside the area that you want to measure the temperature?
To obtain accurate IR measurements, I believe that you need to generally control the temperatures of surfaces that will/may be visible to the measuring transducer, as reflected images.
The temperature of these surfaces will form part of the measurement, to the extent of approximately (1 - emmisivity). If these surfaces are at significantly different temperatures to the object that you desire to measure, then the resulting measurement may be significantly in error.
In many lab situations, these other surfaces will be at a controlled temperature, due to lab airconditioning, so that this problem will be small.
Liquids may have quite highly reflective surfaces.
If the temperature of these objects cannot be managed, then interpose a shield, that you can easily manage it's temperature, either high emissivity if you can control it's temperature to close to the expected object temperature, or
low emissivity if it might vary in temperature. (High emissivity reduces the problem of further reflections.......)
Pay particular attention to items of significantly different temperature to object being measured, or that may change in temperature to a large degree.
You might also need to consider that your sensor may be able to see objects through the liquid. What is on the other side of the liquid?
If you are using IR lenses, then the temperature of the lense will also have a small effect on the measurement (especially if there is any condensation on the lense). Alternatively, maybe you could measure the temperature of the side of the beaker that contains the liquid. This gives less exposure to condensation and also allows you to modify the beaker surface, for increased emissivity - eg paint with black laquer (nail polish can be used for a quick check. Colour doesn't seem to matter in my experience. Increased emissivity gives less sensitivity to reflections.)
For example, measuring inside a human ear, the reflections will also be from a surface at body temperature, thus negligible loss of measuring accuracy and the surface emissivity doesn't affect the measurement anyway, as the reflected surface is at the same temperature as the surface being measured.
This sounds a bit complex, but with some deliberate experimentation, you will quickly gain experience and control. You can deliberately include a test black surface, at different locations, to see how much effect it has on your measuring accuracy. (IR emissivity may be different to visible light emissivity, so judge by checking the accuracy of your measurement, not by your human eye!) If you "object under test" is at equilibrium with lab environment, then you don't need to be concerned with it slowly cooling down, while you test for unwanted sensitivities...
A test surface could be a brass weight, heated to say 80oC in an oven (I assume that this is significantly different to the liquid that you are measuring), or for a quick easy test, just use a glass bulb incandescant lamp (roughly 100oC until it cools down). An alternative safer source, but not calibrated, might be an IR emitter LED, just for quick detection of possible problems, or soldering iron.
I assume that the liquid surface is close enough to the internal liquid body, that this difference is not a source of measuring error?
For all of the above reasons, IR measurements are useful, when moderate resolution/accuracy is all that is required. Otherwise, you might be forced to go to contact measurement, say thermocouple dipped into the liquid.
|
Q:
Hello,
I don't see this one in the online store. Do you expect it to be available soon?
|
A:
The MLX90614 is available from DigiKey
|
Q:
Could someone please point me at some low cost optics that could narrow the beam to say 10-20 degrees?
|
A:
Reducing the beam (FOV) with cheap external optics without losing the calibration is not possible. We are working on new versions of the MLX90614 with smaller FOV due to come out this year.
|
Q:
Do you know if new part will be available by July 07.
Is the accuracy or calibration being lost by external optics? Can it be (easily) recalibrated or compensated externally? We could probably tolerate 1C error in 20-40C range.
|
A:
Samples and a limited volume of a sensor with a "medium" FOV will be available by July. (Samples even by April. A sensor with a really narrow FOV will take till end of this year.
If you change the FOV yourself with external optics, the calibration is completely lost.
|
Q:
you state that if I build an optic tunnel (in an anti-reflective metal material) with an infrared silicon lens on the top, and setup the MLX90614 to be in the focus of the lens,I lose the calibration? How can improve the FOV perfromance? can I tweak the eeprom to improve the calibration?
|
Q:
MLX90614 calibration is valid for black body within the field of view. Providing the same energy (also assumes unaltered spectra in the range 5...15 um) to the sensor die is a must for the calibration to be valid. This is pretty hard to ensure. There are also parasitic effects in that case that are hard to compensate for at a glance. In two words, the useful input signal is reduced 4 times for every 2 times decrease of FOV (using simple solutions like tubes), and parasitic effects increase in magnitude. This yields in significant degradation of accuracy even if the loss of signal is compensated with gain (with SNR also affected).
Simple solution like tweaking the EEPROM is not an option. MLX90614 supports emissivity compensation that might be tested for applicability. However, I believe that getting it nice working would not be a very simple task.
Melexis develops calibrated MLX90614 with narrow FOV. We will certainly announce these versions whenever we have them.
|
Q:
I have meet one more trouble with using MLX90614...
If I measuring temperature in range (20..90) the results are all right, but...if I trying to measure higher temperatures, MLX gives me strange results.
For example, on 150 degrees the output is about 140, and on 320 degrees output is 285.
What I should do to have accurate result?
Should I change Ke(RAM 0x04) and gain of amplifier(bits<11..13> of RAM 0x05) according to temperature level?
|
A:
There are a number of potential reasons:
A) All MLX90914s are set for an emissivity of 1.
The object you are looking at almost certainly has a lower emissivity.
You have to change the Ke to introduce an emissivity correction. From your data I calculate an emissivity of about 0.8-0.85.
The gain of the amplifier should not be changed.
B)Is your object filling up the whole FOV of the sensor? If you look at a hot object with a cold background, the measurement will give an average temperature reading.
|
Q:
I have a couple of problems with the MLX90614. When reading the temperature from the device (Ta or Tobj), sometimes the device NACKs the first byte sent (Cmd = 0x00 for Device address zero and zero in bit zero for write). There is only one device on the bus. We read the device every second and this problem occurs only every now and then. What could make the device NACK a SMbus transfer (could it be busy performing some calculation?).
Also, sometimes the device gets into a state where it transfers a temperature far beyond what it should (e.g. 674 Deg C) What could cause this to happen?
Thanks in advance for you help.
|
Q:
We will send you new sensors.
About the old ones would you give us more details for example:
1. What is the value of pull up resistors?
2. What SMBus frequency do you use?
Did you examine AN "SMBus communication with MLX90614" on our web site?This AN describes the SMBus comunication with MLX90614 in details.
Do you have the errata sheet of MLX90614?
|
Q:
We have modified our circuit to reset the power to the MLX90614 before initialising it. Now the temperature readings are consistent (previously we had power to the MLX90614 continuously and attempted to reset the device by clearing the SCLK pin for > 25ms (actual= 150ms)). However, a read does still fail periodically.
We started using 22k resistors, but have fitted 4k7 pull-ups in case there was a rise time issue/noise.
In addition to this, I have made a dump of the registers from EEPROM and RAM on power-up:
EE Reg 0 = 0x9993
EE Reg 1 = 0x62E3
EE Reg 2 = 0x0201
EE Reg 3 = 0xF71C
EE Reg 4 = 0xFFFF
EE Reg 5 = 0x1FB4
EE Reg 6 = 0x7093
EE Reg 7 = 0x7093
EE Reg 8 = 0x73F4
EE Reg 9 = 0x7B20
EE Reg 10 = 0x8BA0
EE Reg 11 = 0x0000
EE Reg 12 = 0xA8A8
EE Reg 13 = 0x00A8
EE Reg 14 = 0xBC01
EE Reg 15 = 0x0000
EE Reg 16 = 0x0000
EE Reg 17 = 0x7E00
EE Reg 18 = 0x0000
EE Reg 19 = 0x800E
EE Reg 20 = 0x0000
EE Reg 21 = 0x1EB2
EE Reg 22 = 0x0000
EE Reg 23 = 0x3767
EE Reg 24 = 0x0000
EE Reg 25 = 0x0000
EE Reg 26 = 0x655F
EE Reg 27 = 0x2154
EE Reg 28 = 0x00AC
EE Reg 29 = 0x0AAA
EE Reg 30 = 0x0008
EE Reg 31 = 0x0000
RAM Reg 0 = 0x8002
RAM Reg 1 = 0x0001
RAM Reg 2 = 0x458C
RAM Reg 3 = 0x1BA2
RAM Reg 4 = 0x0003
RAM Reg 5 = 0x???? [NACK from MLX90614]
RAM Reg 6 = 0x3A7B
RAM Reg 7 = 0x3A85
RAM Reg 8 = 0xE550
RAM Reg 9 = 0x040E
Of note is EEPROM register 14 (SMBus address register). The factory default should be 0x5A, but I've tried two samples now with the same result. Am I correct in assuming that the SMBus address should be read from the LS byte of the 16-bit value?
I've also tried writing to EEPROM register 5 (Config Register1) to clear the LS 3 bits to set the IIR filter for a1 to 0.5, but this seems to be rejected as the Config Register1 value is always the same after power up.
The message I send (verified on scope trace) is:
0x00 (Slave address, WR bit0 = 0)
0x25 (EEPROM register 5 - Config Register1)
0xB0 (Register Low Byte)
0x1F (Register High Byte)
0x91 (PEC value)
All byte transfers are ACKed by the MLX90614, but after power up the register value is always 0x1FB4.
I have looked for an Errata sheet for the device, but cannot find one. Can you please forward a link to the Errata.
Thankyou in advance for your help again.
|
Q:
I have more information after further testing. As well as the read from the Ta or Tobj1 temperature registers periodically being NACKed (after the 1st byte i.e. Command SMBus address 0x00), the temperature is sometimes (not often) reported as approx 20 Deg C above the average temperature within a valid data packet. For example, when we read the temperature (Ta & Tobj every second), we usually read a value of approx 27 Deg C. However, sometimes (could be after 30 seconds, sometimes after a couple of minutes) the reading is approx 48 Deg C, then the next sample is back to normal. This has also been noticed when using the evaluation kit.
I have looked through the App Note "SMBus communication with MLX90614", but the data transfer (via a scope) seems to be valid.
|
Q:
How long does it take for the POR sequence to complete? i.e. How long after power-up do we have to wait before:
1) We can access data from the device.
2) The temperature stabilises on the device.
Is this the same for standard and medical grade devices? We would like to use both types, but for different applications.
We would like to power-up the device every now and then to read a stable temperature (low-power applications) and therefore the quicker the temperature stabilises the better for our low-power consumption.
Thankyou again for your support.
|
Q:
1. When you clear the SCL line for certain time Treq you don't reset the device,you just switch over the device to SMBus mode.This must be done if the module is configured in PWM mode(See EEPROM register PWMCTRL<bit1>) before trying any SMBus comunication.
Turn off and turn on device power supply to reset the device.
2. About EEPROM register 14 you are right the default address should be 0x5A in LS byte of the word. I see the current address is 0x01.
3. Before do writing in EEPROM you must to erease the cell. The erease is just writing 0x0000 in the cell. After erease/write command wait about 5ms before try another command.
For Example to erease EEPROM 0x05 send the message:
0x00(Device Address)
0x25(EEPROM access command+EEPROM address)
0x00(Data Low byte)
0x00(Data High byte)
0x83(Pec)
Wait 5ms after this.
|
Q:
The POR sequence completes for 3ms.
About 200ms after that the data output is valid.
This is the same for the standard modules and modules with medical accuracy.
|
Q:
Thanks for your support again, I have only two remaining problems, please see my note "Posted 9 March at 2:45AM", i.e. the reporting of temperature of approx 48 Deg C every now and then (also noticed on dev kit) and also the NACK of transfers every now and then (usually the first byte). These do not happen very often, but I would like to resolve them if possible. Thanks again for your continued support.
|
Q:
The Errata sheet of the MLX90614 that describes these problems and suggested work arounds. You can obtain this from your local sales representative.
|
Q:
Thanks for your help - from the errata sheet, we can explain all issues.
Thanks again for your support.
|
Q:
I'm using SMBus to program MLX90614. i think i'm doing all correctly.but still it gave me wrong responses.
i use 0x00 as slave address.here is my steps:
1. send start+address
2. send command
3. send start+address
till this step the sensor give the ack(no problem)
4. datalow=readAck
5. datahi=readAck
6. pec=readNak
7. stop
till step #4,everything is okay.but for the rest,sensor gave the wrong response. can anyone help me what to do?thank you
ps.i'm using AVR
|
A:
I see that you manage till step 4 and then the sensor returns some data (steps 5 and 6). Is this result reasonable?
What do you really read? Ta or To? I guess you reading RAM 0x06 (Ta) or RAM 0x07 (To) please specify.
At point 7. you point out that you stop at step four - how long do you wait there?
Please note that there is a real chance that you end up with "TIME OUT" condition which can occur under following conditions:
1. SCL line is high for more that 50us
2. SCL line is low for more that 32ms
What do you mean under wrong response -> the results is not correct or the communication fails?
|
Q:
i'm reading temperature object which is in RAM 0x07h. here is my code: unsigned char readMemori(unsigned char slave_address,unsigned char command)
{
if(i2c_start(slave_address)==1) //start+write slave address
{
goto error;
}
if(i2c_write(command)==1)
{
goto error;
}
if(i2c_start(slave_address)==1)
{
goto error;
}
MLX_datalo=i2c_readAck();
MLX_datahi=i2c_readAck();
MLX_pec=i2c_readNak();
i2c_stop();
return 0;
error:
i2c_stop();
return 1;
}
int main()
{
unsigned char x,arr[6];
DDRB=0xff;
DDRD=0xff;
_delay_us(10);
i2c_init();
while(1)
{
x=readMemori(mlx90614_address<<1,temperature_object);
if(x==0)
{
arr[5]=mlx90614_address; //
arr[4]=temperature_object; //
arr[3]=mlx90614_address; //Load array arr
arr[2]=MLX_datalo; //
arr[1]=MLX_datahi; //
arr[0]=0;
if(MLX_pec!=pecCalculation(arr))
{
PORTB=MLX_datalo;
PORTD=MLX_datahi;
_delay_ms(200);
}
else
{
PORTB=0x31;
}
}
if(x==1)
{
PORTB=0x40;
}
}
}the result always gave me 0x40 in PORT B which means the readMemori function always return 1. i dont know what's wrong with it, it seems i'm doing all correctly.by the way i'm using two wire interface (TWI)..thank you
|
A:
Did you ever try to see on the scope what you really send and receive?
Here is an example:
> send START condition : Falling edge of SDA while SCL is high
> send Slave Address : 0xB4 (0x5A << 1 | Wr[0])
< receive Ack
> send Command : 0x07 (RAM_ACCESS[0x0] | ADDRESS_7h[0x7])
< receive Ack
> send Slave Address : 0xB5 (0x5A << 1 | Rd[1])
< receive Ack
> send Repeated START : Falling edge of SDA while SCL is high
< receive Data byte low : 0xB9 (LSB byte)
> send Ack
< receive Data byte high : 0x8B (MSB byte)
> send Ack
< receive PEC : 0x4C
> send Ack
So please check what ever you have the sequence described above and also please check on the scope if you really send the what you think you're sending and compare it with the picture posted previously.
|
A:
based on your code, I would suggest your first change your #3 step into:
"repeat start + read slave address" instead of "write" then to see what happens.
|
Q:
When writing to the config register (address 0x05) It says that you shall not alter the some factory preset bits, at the same time it says that you shall erase the address by writing 0 to the address.
Is it OK to erase the address and then restore the factory preset bits together with my FIR and IIR settings?
|
A:
Yes it is perfectly OK to erase those bits and then restore them during writing process.
Actually there is no other way to write data into EERPOM.
|
Q:
Right now I have my sensor Ke still at 1.0 and I'm getting an error in measurement. Below are the actual and observed temps. Can you tell me if this error could be due to Ke being incorrect. Whats the equation to determine Ke?
Actual Observed
37C 35C
41C 37.5C
47C 41C
Also is there a way to set the Ke value withou going through the PEC calculation?
|
A:
The values you give,if I interprete them right??? (Actual Observed 37C 35C 41C 37.5C 47C 41C is rather cryptic), may be due to an incorrect Ke. To calculate the correction one also has to know the Ta temperature.
Correction is only possible if the sensor has the same temperature as the surroundings of the object.
Regards,
Luc Buydens
|
Q:
I assume the sensor provides a calibrated output if the Ta (Ambient temperature) is changing. Is the requirement to have a constant Ta just so you can calculate the Ke of our object? Whats the equation to calculate the Ke?
|
A:
yes, the sensor compensates for Ta changes, but you have to know the Ta to calculate the K factor.
The formula is: Ke = (To,meas^4 - Ta^4)/(To,act^4 - Ta^4)
You have not explained what you observe or what you are measuring, so I cannot comment if the reason of the error you see is due to the Ke.
|
Q:
The actual and observed temps are in pairs as follows
Actual Observed
37C 35C
41C 37.5C
47C 41C
|
Q:
The Ambient temp in the readings above was ~27C.
|
A:
The numbers you give cammot completely be explained by emissivity. I get values between 0.8 and 0.7 for the emissivity at the different temperatures. That is a bit too much variation for that small temperature range. You could try programming an emissivity of 0.75 in the MLX90614 and check out the result.
|
Q:
Thanks for the info. We have a heater not to far fro mthe sensor itself. Is it possible that there are thermal gradients in the sensor and thus its not calibrating properly for ambient temperature changes.
|
A:
if the heater is behind the sensor, the readings should be too low indeed.
|
Q:
I want to adjust the emissivity of the MLX90614 sensor via SMBus but in the datasheet I can't find how to do this. Can you advise me, please?
|
Q:
You can easily change the emissivity with the EVB90614 without going into details. EEPROM value can be found as follows:
Factory default 0xFFFF (emissivity 1.000) ; Ke=DEC2HEX{ ROUND[ E*(-1+2^16) ] }
where "ROUND" represents round-off without truncation. For example, if you have an object with emissivity of 0.612 the value to be written in EEPROM address 0x04 will be 0x9CAB.
|
Q:
That's exactly what I was looking for.
I had two problems:
1.) In the datasheet Ke is not identified as being the Emissivity.
2.) There is no calculation given from Emissivity to Ke.
I would strongly recommend to add this to the next revision of the datasheet. However, may be I just have overlooked it. In this case could you please point me to it?
|
Q:
Thank you for the advice! As a matter of fact we are just preparing a new release of the data sheet so we will have the chance to add that information soon. As the EVB90614 is provided as a standard tool that supports customization of the MLX90614 we have implemented emissivity compensation configuration in that tool. It is simple and straight-forward and the customer needs to go in no details about the device specifics.
|
Q:
I want to enter my MLX90614 in sleep mode, but I'm not sure about the SMBus sequence, is it a write word SA+COMMAND+PEC?.
|
Q:
To put a MLX90614 in Sleep mode you must send Slave Address + Command + Pec. Please see application note SMBus communication with MLX90614 (page 13 - 16) http://www.melexis.com/Asset.aspx?nID=5207
|
Q:
The problem is that I'm receiving ACK from Melexis when I send Slave Address (0xB4 --> 0x5A+WR), and when I send Sleep Command (0xFF) too, but when I send the PEC constant (0xF3) I receive NACK, I don't know why.
|
Q:
So when SMBus device address is 0xB4 the PEC constant is 0xE8, use this link when calculate PEC byte http://www.smbus.org/faq/faq.htm.
PEC constant=0xF3 is used when Slave Address is 0x00
|
Q:
we use the MLX90614 in SMBus mode and need to store/read back some user defined values in the sensor's EEPROM.
My question is how many/which bits could be used for this without influencing the sensor functionality.
Here is a list of my current understanding. Could you please comment on this?
TOmax --> Seems to have influence on PWM only--> 16 Bit
TOmin --> Seems to have influence on PWM only--> 16 Bit
TA range --> Seems to have influence on PWM only--> 16 Bit
PWMCTRL --> Bit 1 : Must be left to 0 (SMBus Mode)
--> Bit 2 : Electrical configuration of PWM/SDA Pin. Must be set to 0?
--> All other Bits: Don't care if Bit 1 = 0?!
--> 14 Bit?
000Fh: Melexis reserved, but accessible? Can this be used by customer?--> 16 Bit?
0019h: Melexis reserved, but accessible? Can this be used by customer?--> 16 Bit?
|
Q:
------------------------------------------------------------------------------------
WARNINNG!!!!!!!!!!
BEFORE CHANGE THE EEPROM READ ALL EEPROM AND SAVE IT FOR REFERENCE.
------------------------------------------------------------------------------------
If you use only SMBUS mode the next EEPROM cells and bits are free for use.
1. Tomax(0x00)
2. Tomin(0x01)
3. PWMCTRL(0x02)
Bit 1 - MUST BE 0 (Enable SMBus Mode)
Bit0, Bits[2:15] are free for use.
4. Tarange(0x03)
5. SMBus address(0x0E) - only the high byte is free for use
6. Melexis Reserved (0x19)
Only Bits[7:4] and Bits[15:11] are free for use
-----------------------------------------------------------------------------------
WARNINNG!!!!!!!!!!
BEFORE CHANGE THE EEPROM READ ALL EEPROM AND SAVE IT FOR REFERENCE.
-----------------------------------------------------------------------------------
|
Q:
Thanks a lot for the detailed information, this helps a lot!
|
Q:
I have bought MLX90614, I want to use it to develop an smart equipment / used to heat the flowing liquid.
I use PIC16F877A to control it.
But I can not found any sample code about PIC connect MLX90614.
And I found EVB90614(Evaluation Board for the MLX90614). It use PIC18F4550. It is very well. but it not give the microcontroller firmware(ASM).
Could you give me the microcontroller firmware of PIC18F4550 in EVB90614. Or other sample code use 16F877A connect PIC with MLX90614.
Email:yacoyacoyaco@163.com
|
Q:
We will release an Application Note, describing implementation of SMBus communication with MLX90614 on PIC18 MCUs soon. It will also provide free to use assembly language code.
|
Q:
I am using the 90614 in SMBUS mode, and I am not seeing the dynamic range of the device that i need to see.The Tobj values look correct for objects such as when i put my hand in front of the window it will register 85F and the Ta looks correct at around 78F. But when i put a soldering iron(approx 500F) within 2 inches of the window, the Tobj value is only reading around 135F. I have tried varying the Emissivity value in the register from .1 to 1.0 to see if it changes, but it only varies slightly around 5-10F. Is there any other register value i can change to increase the dynamic range?
|
A:
From your measurements I calculate an emissivity of only 4-5%.
Metals have low emissivity. so a soldering iron is not really a good test object, but is too low.
I expect you are using a wide angle sensor -AAA or -BAA and that the soldering iron fills only a small part of the field of view of the sensor. So it mainly still measures the room temperature.
|
Q:
I seem to be experiencing some issues interfacing the MLX90614-BAA with a dsPIC33F.
At first I didn't seem to be able to get the onboard I2C peripheral to work, so I 'bit-banged' an SMBUS/I2C interface over two I/O pins. There are two devices on the bus: an MLX90614-BAA, and an MCP9800 (Microchip ambient temperature sensor). The SDA and SCK lines are pulled up via two 4.7K resistors.
My bit-banged I2C routines appear to work for the MCP9800, but not the MLX90614. I've been monitoring the SDA/SCK lines on a dual-trace oscilloscope through development. The MLX90614 doesn't appear to be acknowledging the address byte, regardless of whether I use address 0x00 or 0x5A/0xB4 ('factory default programming' from the PIC example on the Melexis website -- I wasn't sure if the address it quotes was including the R/W bit or not, so I tried both the original and shifted versions). I tried using very slow and very fast time constants for the clock and data signals, both of which worked for the MCP9800, but unfortunately the MLX90614 didn't respond.
I then tried putting a spare MLX90614 on a breadboard and looking for the factory-default PWM on the SDA pin. I tried many different combinations of signals, and even (when getting despirate) voltages (5v) and swapping the pinouts to check and see if the 'front view' listed in the datasheet was really from behind. In all cases, the MLX90614 didn't respond with the PWM output.
|
Q:
About the pinouts, the picture in the datasheet is view from the top(from the side of the glass filter).The first pin then is on the left of the marker.
1.SCL/Vz
2.SDA/PWM
3.VDD
4.VSS
Because i am not completely sure from your letter let try the next:
1. Put on the bus only a MLX90614,put away MCP9800 for now
2. Pull up SDA with 4.7k(need for PWM Open Drain mode ) and connect SCL to Vdd
3. Turn on Vdd
If the module is in PWM mode a PWM signal will appear on SDA.
|
A:
The standard factory setting for the MLX90614 output is SMBus. It will only give a PWM signal when this is set in EEPROM using the SMBus.
|
Q:
Thanks for your quick reply. Sorry if my initial post was confusing, I hope I can help clarify things. I would like to use the MLX90614 in SMBUS mode, and have been working to get this interface to work for about a week. In this respect I notice that the MLX90614 hasn't been sending ACK bits (pulling SDA low on the 9th clock cycle) when sending address 0x00 on the I2C bus. Similarly, I've tried addresses 0x5A and 0xB4 without luck.
I then used a fresh MLX90614 on a breadboard to see if I could find the PWM signal, just for testing purposes. I must have been using an older datasheet as it said the default was for both SMBUS and PWM mode to be enabled. I'm not interested in using the PWM mode, but only tried this as a test to ensure I was powering the MLX90614 correctly, and had the pinouts correct. When I didn't see the PWM output I tried alternate pinouts and voltages, just to see if I had accidentally been sent a 5v version instead of 3v, or if the datasheet pinouts were reversed for whatever reason.
I have the MLX90614 inserted on a custom PCB with the MCP9800 on the bus. Unfortunately it would be difficult to remove the MCP9800 (it's surface mount), but as there don't appear to be any bus-contention issues on the scope -- SDA and SCK are free and don't appear to be pulled low by the MCP9800 inappropriately -- it doesn't look like it's a conflict between the devices.
|
Q:
I understand that you want to use SMBus,...i just wanted to check if the module is not in PWM mode.
You have checked this and probably the module is not in PWM mode.
Please check if all electrical specifications of MLX90614 are kept(see this AppNote http://www.melexis.com/Asset.aspx?nID=5207). For example Clock high period(thigh) must not be above 50us.
For simplicity just send on the bus START+SlaveAddress+STOP. All MLX90614 must acknowledge their slave address.
A slave address occupy the 7 MSbits. So if device has address 0x5A you should shift it one bit on the left which result in 0xB4. LSbit as you know is bit R\-W but this bit no meaning for MLX90614 you may keep it zero. As i understand from MCP9800 datasheet address 0x00 is not supported from MCP9800,...so for this experiment is the best to use 0x00 as slave address.All MLX90614 must respond to this address.
If you have opportunity send me some oscillograms on dpv@melexis.com. That can help us to resolve the problem .
Would you tell us where have you bought the modules from?
|
Q:
We have been seeing a similar issue with the MLX90614ESF-DAA part. We interfaced the part to an 8051-based microcontroller with no problems, but have now interfaced it to an ARM-based micro and are seeing a lot of failures. When it fails, the device does not ACKnowledge any addressing bytes and does not appear to be in PWM mode.
We know the link over SMBus is secured with a CRC and so it should not be possible to 'accidentally' overwrite configuration/EEPROM data, but is there any way we could be corrupting the device to make it stop responding over SMBus?
For example, the POR time (0v to 2.1v) should take no longer than 1ms, otherwise this could result in “unspecified operation” due to the internal circuitry triggering on “inappropriate levels” (from datasheet). If we were outside of the 1ms POR time for some of our units, is it possible this could stop the MLX90614 from working/corrupt internal configuration?
|
Q:
If a device is not in PWM mode it has to respond over SMBus. To change the EEPROM you must erase it before to write it. After this 5ms are need. So i don't think the EEPROM can be reconfigured accidentally. A device will not respond also if it is in sleep mode.
MLX90614ESF-DAA is 3V device. Minimum power supply is 2.4V. What power supply do you
apply?
|
Q:
We don't think it's in Sleep mode or PWM mode as some tests have been performed to check this. We're using a supply voltage of 3.3v. We have now noticed that if we reduce the POR, we have less failures. The POR time is now approx 100us. Previously the rise time was marginal (approx 1ms, possibly slightly more in some cases).
If we were < 1ms on the POR time, would this result in unspecified behaviour (possibly no comms?, possibly the address of the device corrupted so we get a NAK over SMBus?) We currently use a device address of 0x00 which I think means the device should respond.
|
Q:
I am also noticing an SMBus comm problem. I am running a PIC16F88 directly into the MLX90614 with 4.7k pull-ups on SDA and SCL. The bus is running at 100kHz. Address for the part is confirmed via the eval board with SMBus set as default and PWM disabled. Looking at a first stab at object temperature transfer I noticed intermittent ACK's on the address write of 0x00. I might get an ACK every 2 to 16 address transmissions. I trimmed the procedure down to just Start, write address, write command 0x06, Stop. I noticed that every time the address was ACK'ed the command was also ACK'ed. However, every time the address was NACK'ed the command was also NACK'ed. I set up the code to specifically look for the ACK on address and, if it was not received, send a Stop, wait 100us, then resend a Start and send the address again. Once the address is ACK'ed I go ahead and send the command to see if it also ACK's. I see anywhere from 0 to 10 or so retries. As before, when the address is ACK'ed the command is also ACK'ed and vice versa. I have tried tossing in 100us of wait time after the Start bit to see if I need to slow things down for the part but see no difference. As with the rest of you, does anyone have any ideas?
|
Q:
Ignore the last post. I found my problem. The SMBus/I2C procedure supplied with the CCS Microchip PIC compiler is very good at setting up the SCL for data transfer but not so good at clocking SCL for the ACK/NACK bit! While the SCL runs a true 100kHz when passing a byte the internal procedure (i.e., one embedded in CCS's library and not accessible) does not appear to take the system clock speed into consideration when outputting the last SCL for ACK/NACK and rushes it. I slowed the system clock speed down and, while the SCL still runs at the very same 100kHz, it provides the 90614 a little more reaction time before hitting it with the ACK/NACK SCL clock pulse. The MLX90614 is now running as stable as can be. And maybe this is why we should all use ANSI compilers and write our own procedures, eh?
|
Q:
I had the same problems as Peter.
My part is MLX90614ESF-AAA.
Melexis sent 2 pcs as samples but I could never make it run.
Recently I purchase 10 pcs directly from Melexis and I have the same problem.
I feel the same with connections and pin out. Top view does not shows the window so I was confuse.
Now I am sending start, address, data_low, data_hi and checking each time the Ack bit.
All OK until here.
The problem is the PEC calculation. Soft in the web shows PEC for reading and not PEC for writing.
I think that I have to put :
SLAVE=> PEC4
COMMAND=>PEC3
DATAL=>PEC2
DATAH=>PEC1
With this information I have to call PEC_calculation but PEC0 ?
Finally I have to send PEC as the last byte. Then?
I am simply trying to use the sensor getting PWM. I think that PWM was standard from Melexis, but now I can see thar SMbus is standard.
0x5A slave does not work but with 0x00 is OK.
I an using a PIC16fF627A
|
Q:
1. When you make a writing you must do next to calculate PEC:
0x00 => PEC4
SLAVE => PEC3
COMMAND => PEC2
DATAL => PEC1
DATAH => PEC0
0x00 => PEC (This register is always zero)
call PEC_calculation
2. When you use slave address 0x5a you must shift it one bit to the left because
the slave address occupy 7 MSbits of the address byte and must to add bit Rd\-Wr.
Bit Rd\-Wr have no meaning for MLX90614 so you can keep it zero. This results in
0xB4 for the address byte.
|
Q:
Thank you for your answer.
Now I can pass the PEC calculation and end setup with success.
But I am trying to put the sensor for a PWM output and I am sending:
Slave address
Command B'00100010' ; eeprom , 02h
DataL B'00000011'
DataH B'00000000'
PEC ……
And nothing happens. What do I have to do in this point with data and clock lines?
PIC lines must be inputs?
I can not see PWM output.
|
Q:
Before writing an erasing operation must be done. An erasing operation is just a writing of zeros in an EEPROM cell. After a/an writing/erasing 5ms are need the new value to be written/erased.
After writing it is strongly recommended that the device is restarted by turning off/on the power supply.
===============================================================
PWMCTRL register configuration
===============================================================
Bit [0] - Select the type of PWM mode
1- Single PWM
Bit [1] - Enable/Disable PWM mode
1- Enable PWM
Bit [2]- Configuration of the pin PWM
0- Open Drain (external pull up is need)
Bit [3] Mode selection
0- PWM
Bits [8:4] PWM Period Repetition
000 - no repetition
Bits [15:9] PWM clock selection
0000001 Period 1.024ms
Pseudo code example:
An Erasing of the EEPROM address 0x02 (PWMCTRL)
1. Send START bit
2. Send Slave Address (0x00* for example) + Rd\-Wr bit**
3. Send Command (0b001x_xxxx + 0b0000_0010 -> 0b0010_0010)
4. Send Low data 0x00
5. Send High data 0x00
6. Send PEC 0x95
7. Send STOP bit
8. Wait 5ms (this time is need the cell to be erased)
A writing of 0x0203 in EEPROM address 0x02 (PWMCTRL )
1. Send START bit
2. Send Slave Address (0x00* for example) + Rd\-Wr bit**
3. Send Command (0b001x_xxxx + 0b0000_0010 -> 0b0010_0010)
4. Send Low Byte 0x03
5. Send High Byte 0x02
6. Send PEC 0xA4
7. Send STOP bit
8. Wait 5ms (this time is need the cell to be written)
9. Turn off/Turn on module power supply to reset MLX90614 ***
===============================================================
Tomax configuration ( 120 degrees Celsius)
===============================================================
An Erasing of the EEPROM address 0x00 (Tomax)
1. Send START bit
2. Send Slave Address (0x00* for example) + Rd\-Wr bit**
3. Send Command (0b001x_xxxx + 0b0000_0000 -> 0b0010_0000)
4. Send Low data 0x00
5. Send High data 0x00
6. Send PEC 0x43
7. Send STOP bit
8. Wait 5ms (this time is need the cell to be erased)
A writing of 0x9993 in EEPROM address 0x00 (Tomax )
1. Send START bit
2. Send Slave Address (0x00* for example) + Rd\-Wr bit**
3. Send Command (0b001x_xxxx + 0b0000_0000 -> 0b0010_0000)
4. Send Low Byte 0x93
5. Send High Byte 0x99
6. Send PEC 0x5B
7. Send STOP bit
8. Wait 5ms (this time is need the cell to be written)
9. Turn off/Turn on module power supply to reset MLX90614 ***
===============================================================
Tomin configuration ( -20 degrees Celsius)
===============================================================
An Erasing of the EEPROM address 0x01 (Tomin)
1. Send START bit
2. Send Slave Address (0x00* for example) + Rd\-Wr bit**
3. Send Command (0b001x_xxxx + 0b0000_0001 -> 0b0010_0001)
4. Send Low data 0x00
5. Send High data 0x00
6. Send PEC 0x28
7. Send STOP bit
8. Wait 5ms (this time is need the cell to be erased)
A writing of 0x62E3 in EEPROM address 0x01 (Tomin )
1. Send START bit
2. Send Slave Address (0x00* for example) + Rd\-Wr bit**
3. Send Command (0b001x_xxxx + 0b0000_0001 -> 0b0010_0001)
4. Send Low Byte 0xE3
5. Send High Byte 0x62
6. Send PEC 0x7D
7. Send STOP bit
8. Wait 5ms (this time is need the cell to be written)
9. Turn off/Turn on module power supply to reset MLX90614 ***
Note* : Any MLX90614 will respond to address 0x00
Note**: Bit Rd\-Wr has no meaning for MLX90614
Note***: Put in/Put out a MLX90614 in/from Sleep Mode also resets MLX90614
After these settings the module should be configured as:
1. PWM single mode
2. Reading To ( object temperature)
3. PWM period 1.024ms
4. PWM pin is open drain, which demands external pull up connected to
|
Q:
Thank you.
Yes, now it is working. I think the PWM will react more until a body temperature but I will see if I can change the amplifier gain or modify any other parameter.
What I need is to detect a body from 2 meters like a people sensor from the ceiling roof. I just need to detect a difference between “no people” and “people”.
So I think to test the floor temperature and compare with body temperature and that’s all.
It is no important the temperature in degree C, just the abrupt difference.
|
A:
Normally the SMBus or PWM should not make much difference for what you want to do. For the speed the settings of the internal digital filters wil have more effect.
However, even more an issue for your applicatio is the FOV of the sensor. You are now using a sensor with a wide FOV. I doubt that the senosr will pick up any temperature difference from 2 meters distance. I think you have a better change using as sensor with a smaller FOV like the MLX90614ESF-AAC.
|
Q:
Thank you for your post.
Yes, I can see no difference with AAA sensor from 2 mts. My old data sheet did not mention the AAC part. Just only AAA and AAB. I can see that it is new.
I ask for samples. In fact I have to read a difference from 1 to 1.5 meters. Is there a lens or something I can do for improving my sensing? Perhaps gain, filters or lenses.
|
A:
You could try plastic single or multi facet lenses depneding on your specific application.
|
Q:
Great product! My application involves looking at a concrete surface from 6-10 feet above. The FOV will make the viewed area much too large. Can you suggest any manufacturers for a lens system for the MLX90614? Is it realistic to believe that a properly focused system will be able to read a "patch" of the material from this kind of distance?
|
A:
How big is the area you want to observe? We are just releasing a new version of the MLX90614 with a FOV of 35degrees. That would mean an object of 6.5 feet across can be measured from 10 feet.
If that is still too big, we are developing another version with an even smaller FOV, but that one is ont available yet.
|
Q:
This is great news. The 35 deg should work well for one scenario and, if the newer unit has an FOV of maybe 15 deg or less (fingers crossed) it would handle the other scenario. I received two EV boards from Future a couple days ago and have proved out the initial concept. Any idea when a few of the 35 FOV units may be available and how can I get my hands on them?
|
A:
the 35 degree version is available right now. Just ask future to order some samples of the MLX90614AAC or MLX90614BAC (depending on 5 or 3V).
The next version will have an FOV < 15degrees.
Luc Buydens
|
Q:
This is very good news!!!
Is it possible to find some more information on this theme(maybe datasheet on MLX90614BAC or something else)?
|
A:
the official version of the specification will be released any day now.
|
Q:
I just received the 35 FOV parts a few minutes ago and am performing some side-by-side testing with the standard part. Do you know when the 15 FOV may become available and what the part number will be? I want to keep my Future guy on his toes.
|
A:
It will be called the MLX90614BAD. It will have a FOV <10degrees. At the moment we are still testing lenses but I hope to have engineering samples Q1 2008.
|
Q:
Just want to check how's the development of MLX90614BAD? Has the engineering sample available yet? I will need a FOV < 10degrees for my new product in coming month. Where can I have the most update info. about the eng. sample when they are available? Thanks,
|
Q:
What options, or recommendations, for Melexis MLX90614 top lenses exist?
|
A:
At this moment we do not have a lensed product in our portfolio. We are deceloping one, but we still have some lens issues.
If you want to integrate a lens yourself I should caution you that the sensor works in the FIR. Most standard lenses are opaque in that region. There are suppliers of lenses for these wavelengths. Typically one uses silicon or germanium lenses (high end) or PolyEthylene lenses (cheaper).
|
Q:
Do you know suppliers of such PolyEthylene lenses, and may you post it here?
|
A:
I know suppliers like Kube Electronics in Switzerland
http://www.kube.ch/optics/index.php
and Fresneltech in the US
http://www.fresneltech.com/materials.html
|
Q:
I have question about memory of the MLX90614...
In my project I need to storage some parameters of my device in power-off mode, so, can I use some slots of MLX's EEPROM memory, or they are unavalibe to write?
|
A:
Please contact an application engineer via your local sales representative.
|
Q:
I'm invesigating at the possibility to use MLX90614ESF-DAA in our product for skin temperature measurement.
I installed the sensor into our instruments plastic (ABS) enclosure and ported your C example interface code to our
processor (thaks for the easy approach!). The sensor works great.
The problem is that when the sensor is mounted into the enclosure (~2...3 mm deep, 6 mm hole) the FOV will be limited by the hole
edges. This in turn will of course affect the result.
So what im asking is that is it safe to mount the TO-can directly to the enclosure?
This would remove this whole FOV blocking problem but it also would expose the
sensor surface for a touch of dirty fingers, possible cleaning chemicals, static discharge and so on...
Can this sensor handle such things? Other options might be to drill a larger hole and use a protective glass/plastic lens but it's more expensive to do.
BTW. I'm aware that there is a sensor with a more narrow FOV coming up,
but it will simply be too large to fit this product.
|
A:
This sensor is being used in car interiors and withstands most -non agressive- cleaning agents, cola, etc....
Dirty fingers can of course be a problme (fingerprints should not cause much problem). But the window can be cleaned with cleaning alcohol and a lint free cloth.
The sensor has been tested for ESD up to 2KV. static discharge should not pose big problems.
So I do not see major problems in mounting the senor directly to the enclosure.
|
Q:
First, thanks for getting the narrow FOV parts to me. Testing is going well. My app is going to be outdoors. The device will be pointed down and will not receive direct rain or snow hitting it but it will be rather exposed. I would like to mount it in an enclosure with a window allowing the sensor to look out but still be protected. However, my initial testing shows that what may appear transparent to visible light is anything but to IR. Any recommendations on what kind of material can be used for a viewport?
|
A:
Indeed, what is transparent for the eye is not transparent at the wavelengths where the sensor operates (5-14um).
There are transmissive materials like Si, Ge and ZnSe used in laboratory and very expensive equipment. But they will need adjustment of the emissivity setting in the MLX90614.
Windows made of (high density) polyethylene will transmit very efficiently at all temperatures if they are thin enough. "Thin" means generally less than about 0.005 in. (0.1 mm).
A more commonly usedmaterial is (high density) polyethylene. An example is Glad Cling Wrap , which can easily be wrapped around the IRt/c for cleanliness, or formed into a window. If the polyethylene is dirty or damaged, it can easily be replaced.
More specialised material can be found at www.kube.ch or www.fresneltech.com
The transmission coefficient of such thin polyethylene is in the neighborhood of 90%, and therefore a small adjustment of the emissivity compensation may be required depending on the required accuracy, the temperature difference of what you are measuring and the sensor temperature.
|
Q:
I am having trouble with initial communication with the MLX90614 sensor. I have followed all of the specifications in the manual, as well as read all the forums and it seems that I am doing everything correctly, but device doesn't reply with an ACK. Steps that were attempted: 1) Connected sensor to 5V power same as the uC that is doing all of the communication to the sensor. Pulled up SCL and SDA lines with a 4.7K. Wrote my own communication functions based on the "SMBus communication with MLX90614" manual as shown at the end of the document (Did that because on one of the forums found that CCS compiler has issues with I2C). 2) Tried the communication for reading temperature as mentioned in above manual. 3) Tried sending start+shifted by one bit slave address of+stop bit command. 4) Tried reseting to SMbus mode by holding SCL pin low for 1.2ms and then sending address. 5) Checked communication on the logic analyzer everything seems exactly as should be, but not a single time I received an ACK. What can be done? any tips cause I don't know what else to try, and I am quite certain there were no any electrical issues cause everything was hooked up correctly from the beginning. BTW sensor was purchased from Digikey.
|
A:
You seem to be doing things as they should be.
Please try if the sensor responds to SMBus address 00 and send us a trace of the communication if you can.
|
A:
It is little hard to judge whatever you do the think in the right way so I'll make a short list of the common problems that our customers have and known remedy for these problems:
1. Make sure that SMBus speed (the frequency of SCL)is between 10kHz...100kHz
2. Make sure that there is no change of SCL and SDA at the same time - this will avoid ambiguous command such as STOP condition.
3. Make sure that SCL signal does not stay in HIGH for more that 50us and LOW for more than 30ms - if you fail on that condition you'll end up with time out condition
4. Make sure that you release the SDA line during ACK (three state)
5. Be sure that when calculate PEC you take into a count all bits to be send
6. In order to communicate with MLX90614 device the device should be in SMBus mode so if you are not sure in what mode the device is configured send RQ (request) command (HOLD down the SCL line for more than 20ms) before beginning of SMBus communication. Just one request is necessary to switch to SMBus mode.
7. MLX90614 responds to two SMB slave addresses 0X00h (always) and the one written into EEPROM (customer can change that address)
|
Q:
I got same problem to. I try with address 0x00 but MLX90614 never send ACK. I used correct timing signal SCL like datasheet describe (like above). I still can't use MLX90614 with SMBUS. I ever tried change frequency SCL to 10k-100kHz, but the problem still occured. any suggestion? I got MLX90614 from sample distributor. any errata to solve this problem?
Thank you
|
Q:
for information, I got 2 sample ic MLX90614 and both never reply with ACK. I use my code to read+write 24C256 (EEPROM with I2C protocol)and I got no problem.
|
A:
Did you start your communication with "START" condition (transition from "1" to "0" of SDA line while SCL line is high?
If so you simply should send eight clocks after start (while SDA is low) and on the night clock you should see ACK.
Please see attached picture of two examples of communication with MLX90614 that should help you to compare you communication with a working one.
BTW you didn't specify the supply voltage of the device you are using.
Could it be just that you have 5V device while you try to supply it and communicate with it at 3V?
|
Q:
After a long delay I have continued work on the project and your diagram was very helpful. After carefully examining the SDA I noticed that at the point of ACK the SDA signal dips by 1V until 4V not lower. I suspected that it could be the sensor. I ordered new exactly the same sensor and today after replacement everything worked.
Again, thank you very much for the diagrams, I still thought don't know what could have happened. Have you encountered such case before?
|
A:
I never had such a problem till now and it is very strange.
I wondering did you manage to get to the point where MLX90614 returns data (LSB byte and MSB byte?
If so is the level of "0" again that bad?
If yes then maybe the output driver is bad but if the level goes down to 0V then it is hard for me to explain what is going on.
What is the value of the PU resistors that you use?
Is it possible that during getting a live of your set up accidentally had Push-Pull driver connected to the SDA line?
|
Q:
I'm trying to get an MLX90614ESF-AAA working over SMBus. So far, I don't get any reply on address 0x00 or 0x5A.
At the moment, I am only sending a Start, send slave address and Stop. Is the clock timing critcal between the Start and sending of the address? At the moment, my Start and Stop conditions have a clock high pulse width greater than 50uS. However, the clock during the sending of the slave address is less than 50uS. Will this cause a problem?
|
Q:
Use clock high pulse during Start condition for example 10us, 15us,20us instead 50us.
|
Q:
I am using a BASIC Stamp BS2px with the MLX90614 and using its I2C commands to try communicate with the MLX90614.
I have done this successfully with a Nat Semi LM92 Temperature Sensor IC that uses an I2C bus.
At the moment, I am sending a Slave Address (of 0x00) and command (of 0x07).
When I then attempt to read the 2-bytes of the RAM and then the PEC byte, I always get 0xFF for all bytes. However, the MLX90614 seems to ACK all bytes.
My clock high pulse width is approx. 2uS which I know is outside specification, but the device ACKs as expected. Why does it not output the data bytes?
Can I send you a scope trace to show you signal levels and timing.
|
Q:
Please send the oscillograms to an applications engineer via your local sales representative.
Also increase clock high period above 4us.
|
Q:
I've now used the MLX90614 with a Silicon Labs micro that has an on-chip SMBus controller and the MLX90614 appears to be working. I think my problem with the BASIC Stamp is that the clock cannot be controlled to stay within the min. 10kHz specification.
|
Q:
I am using the MLX90614 as a slave device, my master is a PSoC. Everytime I power the sensor on I seem to get junk data for the object temperature for about 2-3mins. After that it seems to work when an object is in front of it, but when open space is in front of it I get a very high temperature reading. Any thoughts on why this occurs? Am I overlooking something obvious?
|
Q:
Well, a new sensor solved that issue. Works perfectly fine now. I do have another question though. I read about a sensor with a FOV of 10deg or less I was wondering when that might be coming out. Thanks.
|
A:
Q3 of 2008
|
Q:
I want to use MLX90614DAA to measure the temperature of a human's forehead. The distance from the device to human's forehead is about 30cm. Is it possible to obtain an accurate reading without using additional optics? I also tried to use a lens in front of the device's window, however the temperature reading became very insensitive. Any suggestion on how to tackle this problem?
|
Q:
This will require consulting with a Melexis application engineer. Please contact your local sales representative to arrange this.
|
Q:
I have been trying to use the MLX90614ESF-BAA to replace an analog temperature sensor and would like to use the pwm output. I have connected it per figure 25 in the data sheet. According to page 18, PWM should be the factory default but I don't get any pulses on pin2. I have tried a pullup with no help. What else do I need to do?
|
A:
I'm sorry, but the SMBus is the factory default. This is an error in the datasheet on page 18 we need to correct.
We can send you a sensor with PWM enabled for testing.
I will send you a mail to ask you for details.
|
Q:
I am having difficulties with my sensor when it comes to reading values from the RAM address.
I am following all of the guidelines as laid out in the data sheet but when i go to read the data bytes, i get a steady "high" state on the input pin.
Can anyone let me know if there is some sort of trick that I am missing? I get both acknowledges for the SA and the command but when i open up the data line for the sensor to drive it, i get 0xff every time.
|
Q:
There are two Application Notes that cover MLX90614 SMBus communication in details,
http://www.melexis.com/prodfiles/0005207_390119061402P004.pdf
http://www.melexis.com/Assets/MLX90614_SMBus_implementation_in_PIC_MCU_5229.aspx
Have you already looked what's in them? Can you compare what you have on the SMBus with the page 14 of the first document ("SMBus communication with MLX90614")?
|
Q:
Thanks for the quick reply. The layout that is on page 14 of that document is exactly what I am following. I discontinue the communication after the first data byte packet is supposed to come through because I was originally just testing each byte of communication. So basically what I have setup right now is the start, SA, write, ack, command, ack, restart, SA, read, and then I open the data line and thats when I get my 8 bits high, followed by a stop. I have this setup in a while(1) loop so I can see the output on a scope. I have tried various pull-up resistors and have even put in an open collector on the data line because I wasnt sure if it was able to drive the data line or not. Also I have tried everything from 10kHz-100Khz delay before, and/or during the response time. I am out of ideas!
|
Q:
How long is this parameter in your system Thd:sta?(See page 5 in AppNote" SMBus communication with MLX90614".
By specification it must be minimum 4us. If this parameter is more than 30us this can result in situation like yours. Try to use for example Thd:sta values between 5 and 20 us.
|
Q:
I have checked my setup timings and they are currently set to a 30us delay. I will try changing this value. But also, does the MLX90614 A family come factory default to PWM or SMBus? The data sheet is a little confusing in this regard. And if it comes default to PWM I assume I must write to the EEPROM to change the control register value.
Thanks,
Tom
|
Q:
MLX90614 comes with SMBus factory default.
|
Q:
I am using the 90614 with an atmel mega88 processor using 4.7K pullups trace distance less than 2". I get one good commnication out of every 6 to 12 attemps at room temp and it gets worse below 0 C. The timing of my clock is high 11usec low 13 usec. the time between the last clock bit of write command and clock rising edge of start is 1.6 usec.
Also my clock signal is not at 5 VDC it is aprox 4 VDC with an exponitial rise. I have lowered that pullup to 2K without any change. I am using Codevision AVR C compiler and the lib for the TWI communications and ideas on what is happening?
|
A:
I hope you use 5V device (the first letter after 90614 is A).
4,7K PU if perfectly OK (although 2K also works) to have good communication in such a short distance thus we have to check the communication it self.
From your description of the clock I can rule out the timeout of SCL signal.
I suggest to check all rising edges of you communication. There should not be any overlapping rising edges of SDA and SCL at any time. This may result in STOP command (rising edge of SDA while SCL is HIGH) thus canceling the communication.
Please see an attached example of how should look like the communication with MLX90614 (click on the picture to enlarge) and verify that your looks like this.
|
Q:
We have an implementation of the MLX90614 device that reads the IR temperature via the SMBus. We have noticed that when pointed at a surface, the temperature is initially quick to react, but then takes several minutes to rise the last few degrees C.
For example, when pointed at a surface at 34 degrees C, the device immediately jumps from room temperature to approx 30 degrees, takes about another minute to reach 32 degrees, then takes a further 20 minutes to reach 34 degrees.
The same effect is seen on different surfaces at different temperatures (always takes a long time to reach the actual surface temperature). The surface temperature is also measured by an independant device for comparison.
Can you please let us know if this has been noticed before (it happens on all of our 90614 sensors). E.g. is it an effect of the internal DSP filtering, or perhaps some other internal calibration?
Can you please respond with any ideas as soon as you can as we require an urgent understanding of the effect we are seeing.
|
Q:
I think You should shut down IIR and FIR filters...because, all of my MLX90614 sensors are work quickly and punctually.
Or, may be You use your own averaging filters that works with your previous measerments? so You should to minimize lenght of them...
|
Q:
Indeed, there is no electronic on the MLX90614 that would take so long to react. On-chip digital filters settle within a second with their maximum settings (refer to Application Note "Understanding MLX90614 on-chip digital signal filters" for details). It is really possible, though, that external filtering (such as the moving average) might take much longer. Mister Watson, is there any filtering added to temperatures, read from MLX90614 in your application??
There are, however, thermal effects, that might also take that long. Please note that all accuracy specifications of MLX90614 are valid under isothermal conditions. I would need details about your application before I could try to tell if there is something resulting in thermal gradient over the MLX90614. I sent you a mail about that. I will also need to know the version of the device you have, and I would also appreciate if you could send me the device EEPROM. I would also like to know if you use the EVB90614 or you read the MLX90614 with another SMBus Master?
|
Q:
We checked our internal filtering and found no issue there. We then checked the Application note "Understanding MLX90614 on-chip digital signal filters" and using this information, we decided to concentrated on the hardware around our sensor.
We now believe that the issue is related to the Field of View (FOV) angle. We have the MLX90614 housed in a plastic unit, but believe that the FOV is picking up an edge of the plastic unit and adding that temperature to the IR temperature of the surface we intended to measure. The plastic unit housing the MLX90614 is taking time to rise in temperature, not the surface we try to measure.
Thankyou for your invaluable help in this matter, it has allowed us to solve the problem quickly.
|
Q:
I am really happy you found the problem!! Every unintended object that enters the Field Of View of IR thermometer will affect measurements' accuracy. We have this note in the MLX90614 data sheet, FAQ section, too.
|
Q:
I have the problem that I can’t change the SMBus address from my MLX90614BAC. The other Communication with the Sensor work very well. I can reed the two temperatures, enter the sensor in sleep mode etc.
But when I try to change the default SMBus address, I receive after the pec always a NACK. I don’t understand why?
Example of data transfer (hexadecimal values):
b4 // address 0x5a, write
2E // EEPROM Adress 0Eh
2B // new SMBus Adress low byte
00 // new SMBus Adress high byte
96 // PEC (calculated with http://www.smbus.org/faq/crc8Applet.htm)
I have made some Oscillograms but I can’t insert these pictures in this forum…
|
Q:
Have you tried to write 0x00 in this EEPROM cell before writing new adress?
It was the same with me then I tried to change any values in EEPROM.
|
Q:
Thank you for replying. I have tried now to change the adress with a erasing operation before (how is it explained in the App. Note: " SMBus communication with MLX90614"). The Ack. of the write operation is now okey, but now I receive a Nack after the pec from the erase Transmission.
data transfer:
Start bit
0x00 // address
0x2E // EEpron Address
0x00 // erase
0x00 // erase
0x6F // pec
wait 5 ms
0x00 // address
0x2E // EEPROM Address 0Eh
0x2B // new SMBus Address low byte
0x00 // new SMBus Address high byte
0x56 // PEC (calculated with http://www.smbus.org/faq/crc8Applet.htm)
wait 5 ms
Stop bit
Enter Sleep Mode
I have upload some Oscillogram pictures here:
http://img503.imageshack.us/img503/7340/eraseoperationhu7.png
http://img503.imageshack.us/img503/2210/byte1and2tf9.png
http://img503.imageshack.us/img503/6379/byte3and4ph6.png
http://img503.imageshack.us/img503/1240/byte5tj9.png
|
Q:
I explored your oscillograms and i didn't find any problem.
Even if you make a writing without erasing the module should send ACK after any byte but the EEPROM cell will be unchanged.
I see that the first time when you have tried to change Slave address without erasing you also have received NACK after the PEC byte.
I don't understand this:
"The Ack. of the write operation is now okey, but now receeive a Nack after the pec from the erase Transmission".
What do you mean that the write operation is okey?
Thanks a lot for the oscillograms. This really make easy our job when we try to resolve customer problems.
|
Q:
Probably, in this example you have forgot to transmit the adress of MLX90614?(as you did in your first post)?
|
Q:
Great, it works now!
The Problem was that I enter the sensor after the erase and write operation in the sleep Mode to reset the mlx90614 (How it is explained in the App. Note: " SMBus communication with MLX90614" on page 19, Error in the App. Note ??). That way the sensor doesn't save the new address.
When I make after the erase and write operation a power supply turn off/on, it works perfect.
Comment: I receive after the pec of the erase transmission still a Nack. But it works even so ;-)
Thanks to Oleg and Dimo for yours great support!!
Best regards
Sven :-)
|
Q:
MLx90614 resets itself when is put in Sleep and after that is put out from Sleep or by turn off/on the module power supply. The Nack after PEC byte is not normal behavior of the module.
Before erasing/writing operation do you make some other communication?
I'm trying to find what cause the module to send NACK after PEC byte.
|
Q:
Before the erasing/writing operation I make only an Exit from Sleep Mode operation. That's all.
Code section:
I2C_Init();
I2C_ExitFromSleepMode();
I2C_WriteNewAddress(0x00, 0x00,0x6f);
delay_500us(10);
I2C_WriteNewAddress(0x00, 0x1C,0xc4);
delay_500us(10);
|
Q:
If you want try to do only erasing and writing to check the result. And after that try to put some delay after Exit From Sleep before to do erasing/writing.
|
Q:
I try to communicate with MLX90614 via LPC2368 I2C bus. After sending Start condition with SA 00 I get a direct Nack (0x20)?
|
Q:
Is it possible to send oscillograms at dpv@melexis.com ?
What is the meaning of 0x20?
|
Q:
I have bought MLX90614ESF-AAA module and parallax MLX90614 Infrared Thermometer Module (#28040). The module works fine. But I need to measure temperature at the point, that means I need very small Field of View, just the point. I do not need other temperatures, such as environment between sensor and object. The point's radius is 5 sm. Also I need place the module 2-3 meter away from the measuring object. Is it possible? I understood about MLX90614-XCC and MLX90614-XCF module after the test, but I think this is not best solution for my needs. What is best way to solve this problem?
|
A:
The 10degree FOV part with the black tube is made by Melexis. The datasheet is on the webpage of the MLX90614.
http://www.melexis.com/Asset.aspx?nID=5152
It is more exspensive then the standard version because there's an IR lens inside.
|
Q:
When I have read a the temperature word from the ram to my computer.
What format has the word. is it signed - unsigned scaled?
|
A:
The result you get is unsigned but MSB is used for error flag (if it is high there is an error), the rest 15 bit represents the temperature in Kelvins (that is why there is no sign i.e. negative values).
Please note that 1LSB corresponds to 0,02Deg.
For instance:
1. 0000 => -273,15'C (no error) - min possible value returned by MLX90614
2. 0001 => -273.13'C (no error)
3. 0002 => -273,11'C (no error) and so on
4. 3AF7 => 28,75'C (no error)
5. 7FFF => 382,19'C (no error) - max possible value returned by MLX90614
The result is calculated by following expressions:
1. Convert it to decimal value i.e 3AF7h = 15095d
2. Divide by 50 i.e. 15095/50=301,9K (result in Kelvins)
3. Convert K -> 'C i.e. 301,9-273,15=28,75'C
|
Q:
Thanks,
I didn't find it in the datasheet
|
Q:
We have an application that records body temperature over time and have noted that Tobj takes a long time to reach its peak. Initially we thought that an object may have been in the FOV, but have discounted this by completely removing anything near the FOV window of the MLX90614.
The device is a constant distance away from the body (approx 1cm) and over a period of about 30mins, Tobj rises quickly to approx 32 Deg C, then takes at least 20mins to rise another degree. We have measured the ambient temperature at the same time to see if there is a connection.
Tamb rises very slowly due to thermal conductivity - could there be a connection between the slow rising Tamb and the rise in Tobj?
We do not change any EEPROM settings in the MLX90614 and therefore use the factory default settings (only reading Tobj and Tamb).
Can you think of any reason why this may happen? We have data here I can send you if it helps.
|
A:
You will need to contact an application engineer via your local sales representative.
|
Q:
I was wondering how often the MLX90614 writes new data the RAM registers for TA, TOBJ1 and TOBJ2? Is it based on the settling time for FIR and IIR filters? I want to make sure that our software doesn't sample too often in order to save processing time.
|
Q:
Yes, the refresh rate depends on FIR and IIR settings.
See this AppNote http://www.melexis.com/Assets/Understanding_MLX90614_on-chip_digital_signal_filters_5272.aspx
|
Q:
We are developing a new product with the 90614 which will be used in an environment that will require frequent cleaning of the view window. We have tried various glass, plastic and acrylic covers to prevent contaminants from getting into the 90614 sensor, but most have prevented accurate measurements, even though the material is stated to be transparent to IR. Is there a material that will allow us to read object temp through a protective window constructed of the material (with corrections applied)?
|
A:
the only viable material that can be used is PolyEthylene, and preferrrably a thin sheet like used for ear thermometers.
Compensation can be made using the emissivity coefficient.
|
Q:
I need to measure the temperature of an object accurately to within 0.3C from 0C to 40C. The 90614 can not quite do that. My question is then is it possible to obtain that accuracy by performing a two point calibration of the MLX90247 as part of a system. The difference between ambient and object temperature will be between 0C-25C.
|
A:
I expect that will be extremely difficult and I would not advise it.
|
Q:
I currently obtain approx. 1C accuracy with a single point calibration at room temp. What factors cause this to be extremely difficult? If I can accurately maintain a blackbody at a specific temperature? or can the technology in general not obtain that?
|
A:
1C over the whole range is already qutie good. Obtaining that under all circumstances is not trivial.
One normally has to calibrate also the internal thermistor with measurements at a few points.
|
Q:
Hello. Can you, please, tell me what is the 90614's wavelength? Thanks
|
A:
5.5 to 14 um.
|
Q:
How weatherproof is the top face of the MLX90614? I want to make a permenant outside mounting but putting it through a drilled hole. Is it waterproof on the top face?
|
A:
the MLX90614 is hermetic and closed to humidity. However, if there is water on the window it will only measure the temperature of the water.
|
Q:
I'm using MLX90614DAA with PIC10F206 to set up a simple SMbus application as you described in the "Simple IR temperature reader with MLX90614 and PIC10 MCU", "the typical Typical Circuit on page 2 of 390119061404P002.pdf".
I also compiled the asm file "main.asm" using your IDE, and input to the pic10f206.
however, i'v got no correct output. the output voltage to pin 2 of DB9 remains 0.86V.
are your Typical Circuit and HEX file right?
or do you have any suggetions for me to debug?
|
Q:
The circuit is right. How do you check the output? With oscilloscope?
Do you use these settings in your Terminal Program?
"8 bit data, one stop bit, no parity bit, 57 600 baud".
If you see on the oscilloscope oscillograms as is shown on page 45 in AppNote "MLX90614 SMBus implementation in PIC MCU" and that through pin GP2 the data is sending but you don't get data in your terminal program the only reason should be that 3V levels are not recognized from your PC serial port. Then you have two options:
- Just replace MLX90614DAA with MLX90614Axx(5V module) and use power supply 5 Volts
- Use MLX90614DAA but the data must be send using MAX232 driver to meet the RS232 serial protocol specification which will make the circuit a little bit complicated
|
Q:
I see that the MLX90614 can be set to different communication modes. If I order the parts will they be defaulted to the correct mode to work with the PIC10F206 example code? Or maybe that code includes the mode setting commands?
|
A:
The MLX90614 is as a standard shipped with the SMBus communication mode active. This works with the mentioned code.
|
Q:
Next question. Does the sensor withstand being pointed at the sun? I understand it's not going to be a useful measurement, but will it be fried?
P.S. I discovered the sensor + interface board sold by parallax, that's a very nice solution for evaluating this device.
|
A:
It will survive, if you're not too close to the sun. But the maximum temperature reading of the MlX90614 is 380C.
|
Q:
Thanks, sounds good, I hope 150 million kilometres is far enough ;-)
|
Q:
I have a problem to get the register value from 90614 ram. I am using pic16f877a and I2C communication protocol. my project has two devices (TX-card and RX-card). The MLX is on RX-card. TX-card sends a string to RX-card to tell RX-card to read the temperature.
Actually, my first program is working. I was using 4Mkz crystals in both tx and rx card (baud rate is 9600). I can get a read from MLX.
But what I really need is 115200 baud rate. So, I placed 14.7456Mkz crystals in both tx and rx card. Tx-card sends string under 115200 baud rate. Rx-card program has been modified a bit:
MOVLW B'00101000' ; I2C MASTER MODE
MOVWF SSPCON
; clock = FOSC/(4 * (SSPADD + 1))
; 100K = 14.7456M/(4 * (SSPADD + 1))
MOVLW 0x24 ; SETUP BIT RATE ABOUT 100KHZ
MOVWF SSPADD
But I cannot get correct value, because the result I got were either ffff or 0000.
|
A:
In the specification of the MLX90614 (p. 15 , 8.4.4.1 Timing)it is noted that the SMBus frequency is 100KHz max. The product does not support the high baud rate.
|
Q:
thanks for your reply. the baud rate only relative to the rs232 communication speed. the i2c speed is set up by SSPCON and SSPADD registers.
speed = FOSC/(4 * (SSPADD + 1))
where speed = 100Khz; FOSC = 14.7456 MHz;
if i assign 36 to SSPADD, the i2c speed will be less than 100Khz.
is that right?
by the way, i am using i2c protocol, not SMbus.
|
A:
I have no idea what is meant by SSPCON an SSPADD, but your calcuations seems right.
|
Q:
i solved my problem!!! :)
my privious program was using i2c protocol, and let the hardware (microchip) to deal with the sending and receiving process. it works fine in low baud rate, ie. 9600. but never worked in high baud rate, ie. 115200
now, i am using smbus protocol and manully clocking the data out and in. it works in both high and low baud rate.
thanks:)
|
Q:
When/where can we get details on the MLX90614 XCF narrow FOV? I am also looking for XXC and XXF information. Thank you!
|
A:
please download the datasheet at:
http://www.melexis.com/Asset.aspx?nID=5152
|
Q:
I'm interested in purchasing MLX90614-ACF sensor. I'm going to use it to detect temperatures in the range of 35-40 C.
I'm wondering what is the max. distance of the measured object. I 'd like to use the sensor to measure the temperature of a surface that is 3-4 meters away from the sensor. Is that possible?
Let's say that the whole surface has the same temperature, 39 degrees C. Is the measurement changing with the distance from the sensor? For example, if I measure 39 degrees from 20cm (pointing to a small part of the surface), will I measure 39 (or something like +-2 degrees) from 3 meters away, or not?
|
A:
The sensors measures energy in the wavelegnth band of 5-14um. In that range, the atmosphere has little influence on the reading. Certainly for distnaces of 3-4m there should not be an issue, provided the object you measure fills the FOV completely. For a distance of 3-4m your object should be >80cm to be on the safe side.
|
Q:
Thank you Mr. Buydens.
|
Q:
I decided to make a chamber with a peltier cell in order to get low
temperatures and measure it by MLX90614ESF-AAA. Also for sensor soft development.
I can not read the real temperature from the object placed 7 cm far.
I can read my own body temperature and other objects temperature correctly but distance is a hard topic.
I am thinking about the object material. It is an aluminium heat sink.
Perhaps factory filters or material Emissivity must be considered.
Do you have experience with this? do you have an idea about?
How I can get better result with object place not too close from the sensor?
I check with fresnell lenses, 1 zone 2 cm diameter but I can not get better and real values.
I am using factory default single zone SMBus.
|
A:
Did you consider the field-of-view specification? The sensor has a 90 degree field of view, so the measurement area has a diameter of 14cm at a distance of 7cm. The sensor will average the temperature of everything it can see.
Depending on the surface treatment, there's a wide variation in emissivity. You can google "aluminum emissivity" for more details.
|
A:
Metals are very difficult to measure because of the low emissivity. Aluminnium is no exception. The emissivity depends a lot on the surface state of the aluminium (oxidation). Getting emissivities from the web will not give much help.
You also have to consider that due to the low emissivity, the aluminium will reflect the energy of its surroundings like a mirror, and you will measure the temperature of what is around the aluminium instead of the aluminium itself.
If possible, a much better option is to paint the amluminium with a high temperature paint like the ones used for barbeques.
|
Q:
I interfaced MLX90614BAA with microcontroller and i received some data as 255186... I sure about my program, but the pull-up current is only 6 micro Amps. I used 1.1K as pull-up resistor. Kindly help me to increase the pull-up
|
Q:
MLX90614 gives 16bits data,..how you get this value 255186 = 0x3E4B6.
Would give us more information for your system,...if is possible send oscillograms.
|
A:
Could it be that all three bytes (including crc byte) are being combined together ?
|
Q:
I'm try to calculate the lens for my device, based on MLX90614BCF. But I can't find the meaning of distance from upper end of its body to absorber area.
|
A:
In the MLX90614BCF there is already a lens inside.
If you want to add a lens to a MLX90614 to change the FOV it is better to use the standard BAA as othwerwise you have to deal with a 2 lens system where you have only control over 1 of the lenses.
If you can use only small lenses it may be interesting to use the MLX90614BCC. In this device there is no lens, only an additional aperture.
|
Q:
Thanks for quick reply!
|
Q:
Does the conical field of view of the MLX90614-xCF actually taper to a point at the lens of the sensor, or is there a minimum spot size that has to be taken into account when calculating the spot size at a given distance?
|
A:
The lens is an optical component like any other lens. So of course the FOV does not taper to a point.
You best take the inner diameter of the tube at the front of the sensor as the minimum spot size at that position.
|
Q:
I am trying to read the content of the eeprom of a MLX90614DAA. However, from the address of the 0x0E, i got 0x01BC which is supposed to be 0x005A (default slave address). Is it possible for such kind of device? The sensor is brand new and according to the datasheet, i think it is not possible for me to corrupt the default setting during operation.
For the test, i put 0x00, 0x01, 0x02 as slave address and got response correctly for the value of Tobj1. Remaining addresses (0x03...0x5a) have no luck.
BTW I have considered the bit left shiftting, for example, address 0x5a->0xb4.
Therefore, i think probably my device has 0x01 as the default slave address. But i can not ensure it.
|
A:
Yes you're right that the default address should be 0X005A.
Yes it is possible for you to corrupt the data in that part of EEPROM as this area is fully accessible thus you can write in it what ever you want (although I don't think that this is the case).
I'm a bit confused that you're able to program 0x00, 0x01 and 0x02 as slave addresses but for the rest.
I see one potential problem namely you claim that you read 0x0E which actually correspond to reading RAM (you can easily can check this by reading this address several times in a row and if the returned value is changing most probably you read RAM instead of EEPROM). In order to read EEPROM you should send 0x2E.
MLX90614 has one default address that no matter what you program into EEPROM it will respond and this address is 0x00h. or whit ather word our defice will respond to 0x00h and the one programed into EEPROM address 0x2E. Please try to read 0X2E and then try to look for MLX90614 at this address.
|
Q:
Thanks for reply. I have checked that the command i use is 0x2e.
If i use command 0x20, i got response as 0x9399. Is this a factory setting for reading eeprom whose address is 00h?
|
Q:
Just one more thing. I want to programm the eeprom to change the content of 0x0e to be 0x5a. If the device can generate response if i use slave address 0xb4, it can be proved that the content has been corrupted.
Following the instruction from the forum, i tried to erse the address 0x0e first. I can get ACK for the first two byte writing (each followed by a period of 4ms), i can not get ack for the last byte (PEC). Does that means the value of PEC i am writing is wrong, then the sensor refuse to execute erasing action?
|
A:
If you use command 0x20 and you get 0x9399 is perfectly normal - this mean that you really can read the EEPROM although the actual result from that reading is 0x9993 (you have to switch MSB and LSB). Maybe this explain why you get respond to address 0x01 as you mentioned that you read 0x01BC from 0x0E thus the result is 0xBC01 corresponding to address 0x01 (however I can't explain respond to address 0X02).
Erasing the address first is the right way when you want to write to EEPROM.
It is not necessary to wait 4ms after each byte but wait 4ms after the whole command write to EEPROM is send.
Another thing is that the whole command write to EEPROM should contain 5 bytes (as far as I understand from your description you are sending only three bytes)
Normally write command consist:
1. Slave address byte followed by ACK
2. byte for determining what we will do (0x22h in our case - EEPROM access) + ACK
3. LSB byte to be written + ACK
4. MSB byte to be written + ACK
5. PEC + ACK
then wait 4ms.
Please find two examples of communication with our device at your mail.
|
Q:
Sorry for delay. Many thanks for your reply and sample code. I have managed to re-write the eeprom on the address 0x0e. And now the slave address is 0x5a which can be recognized by the slave device itself.
I think the prevoious 0x02 can be explained that the 0x01 (from 0xbc01) is converted to be 0x02 after 1 bit left-shifting. But i can not explain why 0x01 has response. Because 0x01 can not be obtained by any address after left shifting withou special setting.
And i have found out why i can not execute the writing operation of eeprom. That is because of the wrong calculation of PEC. I ignored the value Rd which is 1 (The value of Wr is 0 which has no effect on the 7-bit slave address). Following the on-line calculator, (http://smbus.org/faq/faq_main.htm), i got the right value.
At the bottom of this link
http://forums.parallax.com/forums/default.aspx?f=25&m=295491
someone has a very similar problem. I guess maybe some batch of MLX90614 do have this problem. Since it can be controlled by rewriting , it won't be a big issue.
|
Q:
Can you explain me the difference between the MLX90614xAC (FOV 35°, Vdd=3V) described in the datasheet on Page 29 and the MLX90614ESF-DAA Temperature sensor that I can buy on de Melexis homepage? Are this the same Products?
|
A:
No, the MLX90614ESF-DAA is a thermometer with "medical accuracy" +/-0.1C accuracy, 3V, but an FOV of 90 degrees.
|
Q:
i've apparently killed a MLX90601B and C - love some help on getting them back to working.
I plugged them into my mlx90601 evaluation board and they worked fine. I uploaded the demo thermometor Ir_Handheld_rev22.eep from melexis.com and ever since when i run the eval board it says "module is not present or is not properly configured" of course i tried this with the MLX90601C and got the same result.
i'm a bit new to these devices. Am i missing something or is there a way to undo what i did and get the mlx's back to their factory defaults?
Thanks!
ps - i'm using v 3.5 of the configurator software.
|
A:
As described in the accompanying our tools documentation, care needs to be taken not to destroy the original EEPROM content as it contains unique calibration data as well as configuration settings. In case you have not saved the original EEPROM I am afraid the module performance is permanently lost. There is a chance that, if you copy the EEPROM from another module (working one) you could have operational module with unpredictable performance. If you have followed the precautions in the documentation provided by Melexis and have stored the original EEPROM, all you have to do is restore it and you will have the module resurrected.
|
Q:
1.) Is it necessary to include the packet error code whenever you read or write to EEPROM or Ram locations in the MLX90614?
2.) What is Melexis's prescribed method of interfacing a microcontroller that operates at +5Volts to a MLX90614 that operates at +3Volts(ie. do they have a recommended voltage translator circuit to perform this voltage translation)?
|
A:
1.1. In case of reading from MLX90614 it is up to the reader side to check the PEC or not but since you want to interface 3V device with 5V reader it is recommended to check PEC as this will ensure you that the data you receive is correct.
1.2 In case of writing data to MLX90614 the PEC is mandatory as MLX90614 will cancel the command (no writing process will be processed) if the PEC is not correct.
Concerning question two there are two approaches that can be implemented depending on your system.
2.1. Simplest way is to connect your PU resistors to 5V supply.
In that case SCL line is perfectly OK as it is only input and will definitely see the clock (NOTE: this is true just in case your CPU is communicate with Open drain/collector not with push-pull. Push pull may destroy the device)
For SDA line however there is a internal ESD protective diode connected between SDA pin and VDD (3V) of the device thus the voltage will be limited (again PU + open drain/collector not push -pull) to 3,6V. This level is OK with MLX90614 but you should see if this would not cause a problems from reader side. Normally there is no problems but PEC check is advisable.
2.1. In case you can spare three port of your CPU that is dedicated to communicate with MLX90614 then you can have following configuration:
SCL line - PU connected to 5V + open drain/collector (the same as before)
SDA line - One pin of CPU to transmit the data to MLX90614 -> PU connected to 5V + open drain/collector.
Second pin dedicated to receive data from MLX90614. The data to this pin is supplied via LS (level shifter 3V->5V)from SDA pin.
Please see attached picture.
|
Q:
Need some sample assembly code for the PEC for a simple read of the TA and Tobj. I got this code from the web and several other samples but they don't work. I am communicating on the bus successfully. I am using an MSP430F2132. Here is the code:
melexiscrc mov.b #0,&tstbuffer
mov.b #7,&tstbuffer+1
mov.b #0,&tstbuffer+2
mov.b &i2crecvbuf,&tstbuffer+3
mov.b &i2crecvbuf+1,&tstbuffer+4
mov.b &i2crecvbuf+2,&tstbuffer+5
mov #tstbuffer,R4
mov #5,R5
clr.b &melxcrc ;CRC starts with 0
melexcrc01 mov.b 0(R4),R8 ;get the byte
xor.b &melxcrc,R8
mov.b melcrctbl(R8),&melxcrc
inc R4
dec.b R5
jnz melexcrc01 ;do all bytes
ret
melcrctbl DB 0,94,188,226,97,63,221,131,194,156,126,32,163,253,31,65
DB 157,195,33,127,252,162,64,30,95,1,227,189,62,96,130,220
DB 35,125,159,193,66,28,154,160,225,191,93,3,128,222,60,98
DB 190,224,2,92,223,129,99,61,124,34,192,158,29,67,161,255
DB 70,24,250,164,39,121,155,197,132,218,56,102,229,187,89,7
DB 219,133,103,57,186,228,6,88,25,71,165,251,120,38,196,154
DB 101,59,217,135,4,90,184,230,167,249,29,69,198,152,122,36
DB 248,166,68,26,153,199,37,123,58,100,134,216,91,5,231,185
DB 140,210,48,110,237,179,81,15,78,16,242,172,47,113,147,205
DB 17,79,173,243,112,46,204,146,211,141,111,49,178,236,14,80
DB 175,241,19,77,206,144,114,44,109,51,209,143,12,82,176,238
DB 50,108,142,208,83,13,239,177,140,174,76,18,145,207,45,115
DB 202,148,118,40,171,245,23,73,8,86,180,234,105,55,213,139
DB 87,9,235,181,54,104,138,212,149,203,41,119,244,170,72,22
DB 233,183,85,11,136,214,52,106,43,117,151,201,74,20,246,168
DB 116,42,200,150,21,75,169,247,182,232,10,84,215,137,107,53
|
A:
It is quite difficult for me to read and understand that code.
As you mentioned the communication with our device is OK so it is only matter of correct calculation of the PEC.
Normally for well working on-line PEC calculator we use the one provided by SMBus home page -> please follow the link:
http://smbus.org/faq/faq.htm
on the bottom of the page you'll see a link to CRC-8 Calculator.
Here is a simple example how it works (to help you to see what data should be supplied to the calculator in order to get correct result. Let's say that you device responds to SA=0x5A and the command that is executed is Read RAM address 0x07(Tobj).
So the command you need to send consist following:
> send Slave address : 0xB4 (0x5A << 1 | Wr[0])
> send Command : 0x07 (RAM access [0x07] | address_07 [0x03])
> send address : 0xB5 (0xB5 << 1 | Rd[1])
< receive Data byte low : 0xFB
< receive Data byte high : 0x39
< receive PEC : 0x2A
Or the respond of the device is 0x39FB.
So in order to get that PEC = 0x2A you should enter B407B5FB39 into calculator and this is the bit stream on which you should calculate your PEC.
|
Q:
I’m presently programming my circuit to use the MLX90614. The sensor responds to the address 0x00, but will not respond when interrogated with its default address.
With the 0x00 address the responses are ok. It gives the right object temperature, the address at which it is located and so on.
For now I will use only one sensor per unit and if I don’t find any solution, I will use address 0x00. But for the next project the same two lines will be used with up to 25 sensors on the same bus.
So being unable to communicate with the sensors at a specific address is very problematic.
|
Q:
Check your mail. If you still have problems with the communication send me if is possible oscillograms.
|
A:
Try to read EEPROM cell 0x0E. The LSByte of this cell contains the slave address of the module.
By default it should be 0x5A. Don't forget that when this address is send by SMBus it occupy the 7 MSbits of the byte.
So on the bus it should be send as 0xB4 ( 10110100) where the 7 MSbits are address and the LSbit is bit R/-W. For MLX90614 this bit has no meaning , i keep it zero usualy.
If you still have problems with the communication send me if is possible oscillograms.
|
Q:
I have a problem writing to the allowed for writing EEPROM registers of the MLX90614. I have read the application data, I am reading all the EEPROM registers correctly, but I am not able to write. I use for writing 0xB4 as slave address.
|
A:
You should use 0xA5 for slave address. first write 0000 to the EEPROm address you want to change, then the new values. Then power down the device for the values to take effect.
|
Q:
thanks for the immediate response. I actually tried this already... but I think that the writing address must have 0 for LSB. Anyway, I am almost sure that my problem lies in the PAC byte. Do you have examples for C code for calculation of the PAC byte?
And one more question: If I write 0000 to the EEPROM address without writing anything else afterwards, will the cell value be then read as 0000?
|
A:
Here is basic rules that will assure that your writing into EEPROM will be successful:
1. Before write down new value first you should write 0000h (you can check if this writing is successful by reading the same address -> you should read 0000)
2. Make sure that you wait at least 4ms after each EERPROM write command.
3. Not to confuse to which address the device respond you can use 0x00h - to this address all devices should respond no matter what address is programmed into EEPROM (this is for debug purposes of course - if you have more devices on the bus you'll have problems).
4. Concerning the PEC calculation you can use following on line PEC calculator:
http://smbus.org/faq/faq.htm
If you still have problems I would like to see some scope pictures of your communication to our device in order to find out what is wrong -> you may contact me at aga@melexis.com.
|
Q:
I'm having the same problem of some people here: I can't write the slave address on the sensor. The read went fine, I could read the Ta and To. But I can't write. You guys said that I could read the slave address that is in the address 0x0E, but how can I change if I'm reading RAM or EEPROM?
Also, maybe the problem I'm having is due to the PEC value. I used the library you guys have here on the PEC calculation and I didn't understood two things. Here is the code:
arr[5]=SlaveAddress; //
arr[4]=command; //
arr[3]=SlaveAddress; //Load array arr
arr[2]=DataL; //
arr[1]=DataH; //
arr[0]=0; //
PecReg=PEC_calculation(arr);//Calculate CRC
Why you don't send the mode of operation(read or write) and what is that arr[0] = 0? On the datasheet there is no information of that last 0. And maybe thats the problem I'm having, I don't know if i should it or not on the write proccess.
|
Q:
I can get three MLX90614 's acknowledge (low bit) with default slave address 0x5A by sending serial bytes: 0x84 , 0x07, 0x85 ( read RAM T object) but I only read three bytes 0xFF ( low Byte, Hi Byte, PEC) . The reading data bit code from slave is the same code with reading previous slave acknowledge, but I always read unchanged High bit. I changed timing from 10kHz to 100kHz, to add some more delay time between slave acknowdge bit and slave respond byte, but without success.
When I changed the slave address which is different with 0x5A, I will not get acknowledge from slave. It means MLX90614 does not damaged but I cannot get its proper respond. I want to get crazy with it. Please help!
PS: my code is based on C language for PSoC. Data sent to PC via RS232
|
A:
If you manage to get three ACK and then suddenly the SDA line become FFFF this means that for some reason MLX90614 cancel the communication and release the line and since there are PU resistors you get "1".
Possible reasons for canceling the communications are:
1. Time out of SCL line - occur if you hold SCL line "high" for more than app 50us and "low" for more than 32ms.
2. A "STOP condition" occur - rise SDA line while SCL is high
3. It is possible that you don't send "Repeated Start" (RS) after 0x07
I guess you meant 0xB4 and 0XB5?
Please see picture with two communications (please note that the SA = 00h)
|
Q:
What is the spectral sensitivity / spectral range of the melexis MLX90614.
|
Q:
MLX90614 uses 5.5 ... 15 um range.
|
Q:
We would like to use MELEXIS IR temp sensor for measuring of the human skin temperature. The sensor will be relatively clouse to skin (c 2mm] in our applicatin. It means, we have to protect the sensor against peases of skin and mayby massage oil. The ideal solutin is some plastic window. The problem is, all plastics I know are the barier against 10,6 microns wawe lenght. Do you know some solution for me? Do you know some plastic (or other material)usable for this application?
|
A:
You can use a very thin (<0.1mm) foil of PolyEthylene. That material is also used as protection for ear thermometers. You may need to make a small adjustment in the emissivity compensation setting of the sensor to compensate for the small absorption of the polyethylene. It is also important to have the foil at the same temperature as the sensor.
Another option might be not to use a protection and clean the sensor regularly with alcohol and a lint free cloth.
When the sensor comes this close to the body, it is possible that the metal housing of the sensor is heated by the body. This can lead to erroneous measurements. I would advise to protect the metal housing of the sensor as much as possible with a standard plastic, taking care the plastic does not get in the viewing angle of the sensor of course.
|
Q:
The MLX90614 is EXCELLENT!
Our problem is that the TO-39 case is EXTREEMLY magnetic. Inside an MRI scanner it destroys the images. Is there any other casing planned in the future?
|
A:
I am really very happy that you like our product so much!!
On the other hand, I am really very sorry to say that the only package materials likely to be in production are all ferromagnetic.
Sorry for the stupid question, but is it the permeability of the can package that causes the problem or the coercivity?
|
Q:
Thanks for the prompt reply!
The actual problem is this: MR-Imaging requires the highest possible DC-field homogeneity (a few parts per million). Anything which alters this flux density is disturbing. A few ppm does only geometrical image distortions, but few dozen ppm of inhomogeneity causes a ‘black hole’ in the image. This is true for paramagnetic and diamagnetic materials equally, but as their susceptibility to magnetic fields is less, it would be acceptable. The TO-39 causes a large ‘black hole’.
Our bill of material for the project is carefully chosen not to be ferromagnetic (even the battery is eliminated by stealing the power from the KW strong radio pulses inside the magnet) and this TO-39 case is the only problem which should be solved.
|
Q:
I am trying to talk to the device using an I2C bus. I have 2 other devices on this bus (non MLX) and I am able to talk to them using LPC23xx. With a Logic Analyzer, we can see SDA, SCL, VDD & GND are all correct. However, the device won't send an ACK. I have tried slave address 0 & 5a<<1=b4. I have also read all previous posts.
|
A:
This issue has been resolved. I am now able to communicate with the device. Not sure exactly why but I cleaned up the interrupt handler I was using for ARM7 and the code started working. The cleanup was to remove code clearing the start flag where not needed. Thanks.
|
Q:
I'm using a MLX90614 and I'm having problem with writing on EEPROM and with PEC calculation.(I'm using SMBus)
1. PEC Calculation: When I'm using the slave address 0x00 I don't have problem with the PEC calculation, that way I can read the temperature without any problem. This is what I'm using for the PEC calculation:
PEC[5] = SlaveAddress << 1 | 0x00(Read)
PEC[4] = Command | RAM Command(0b00000000)
PEC[3] = SlaveAddress << 0 | 0x01(Write)
PEC[2] = DataLow
PEC[1] = DataHigh
PEC[0] = 0
At first, the SlaveAddress is with value 0x00 and it works, but with 0x5A it don't work. I get error during the PEC validation of the sensor. I used Melexis example with C to get a basis for the read process, so I'm using your function for my calculation.
2. Writing EEPROM: For writing on EEPROM to change the slave address, I'm using this proccess:
First, I erase the EEPROM at the address 0x0E. Then I do the follow:(I'm already sending the PEC values so you can see if the problem might be that, I got the "order" of PEC values on the forum)
PEC[4] = 0
send the 0x00 Address -> PEC[3] = 0x00 | 0x01(Write)
send the command(0b00100000 | 0x0E) -> PEC[2] = 0b00100000 | 0x0E
send the Data Low -> PEC[1] = 0x00
send the Data High(the new address I'm sending 0x5A) -> PEC[0] = 0x5A << 1
I don't know how to solve these problems, I read almost all MLX90614 on the forum and could find a lot of useful information but I'm still having these problems. And for that, I would like to give a suggestion too: That you could put an example for the writing proccess. The read example is awesome and it really helped me to be able to read the temperature, but just the datasheet is not enough information for most of the people that use the sensor.
|
A:
1. READ is "1", WRITE is "0"
2. You should calculate the PEC of {PEC[5],PEC[4],PEC[3],PEC[2],PEC[1]} without PEC[0. I assume that PEC[x]is just a name of variable?
3. As far as I understood you send PEC after each byte which should not be the case. You should have only one PEC after the whole pack.
4. After you erase the address (0x0E) did you verify the the address is actually erased?
5. From which exactly document did you get the example of PEC calculator?
6. Is it possible to give us some specific example so we can check for our selfs the calculation of the PEC?
|
A:
Here I put two examples of SMBus communication with MLX90614: read RAM address 0x07 (please note the repeated start) and write 0xC807 to EEPROM address 0x02.
|
Q:
See Fig.2 on page 4 of "SMBus communication with MLX90614". You will see that after all bytes on which PEC must be calculated an zero byte is added. This zero byte always is loaded in PEC[0] when PEC is calculated.
####################################################################################
####################################################################################
Pseudo code example:
An Erasing of the EEPROM address 0x0E (SMBus Address)
1. Send START bit
2. Send Slave Address 0x00*
3. Send Command 0x2E
4. Send Low data 0x00
5. Send High data 0x00
6. Send PEC 0x6F
7. Send STOP bit
8. Wait 5ms (this time is need the cell to be erased)
To calculate PEC load PEC array as follow:
PEC[5] = 0x00 (in case of writing this byte is not used and must be 0x00)
PEC[4] = 0x00 (Slave Address)
PEC[3] = 0x2E (Command + EEPROMaddress)
PEC[2] = 0x00 (low data byte)
PEC[1] = 0x00 (high data byte)
PEC[0] = 0x00 (augmented byte, PEC[0] always is 0x00)
PEC[5] PEC[4] PEC[3] PEC[2] PEC[1] PEC[0]
==========================================
0x00 | 0x00 | 0x2E | 0x00 | 0x00 | 0x00 |
==========================================
|_________ ________________|__ __|
\/ \/
message sent on the bus zero byte
####################################################################################
####################################################################################
A writing of 0x5A in EEPROM address 0x0E (SMBus Address )
1. Send START bit
2. Send Slave Address 0x00*
3. Send Command 0x2E
4. Send Low Byte 0x5A
5. Send High Byte 0x00 (the high byte of the EEPROM address 0x0E has no meaning)
6. Send PEC 0xE1
7. Send STOP bit
8. Wait 5ms (this time is need the cell to be written)
9. Turn off/Turn on module power supply to reset MLX90614 (After this MLX90614 will
respond to the new slave address 0x5A)***
To calculate PEC load PEC array as follow:
PEC[5] = 0x00 (in case of writing this byte is not used and must be 0x00)
PEC[4] = 0x00 (Slave Address)
PEC[3] = 0x2E (Command + EEPROMaddress)
PEC[2] = 0x5A (low data byte)
PEC[1] = 0x00 (high data byte)
PEC[0] = 0x00 (augmented byte, PEC[0] always is 0x00)
PEC[5] PEC[4] PEC[3] PEC[2] PEC[1] PEC[0]
==========================================
0x00 | 0x00 | 0x2E | 0x5A | 0x00 | 0x00 |
==========================================
|_________ ________________|__ __|
\/ \/
message sent on the bus zero byte
####################################################################################
####################################################################################
After above procedures you can use slave address 0x5A to communicate with MLX90614
Note* : Any MLX90614 will respond to address 0x00
Note**: Bit Rd\-Wr has no meaning for MLX90614
Note***: Put in/Put out a MLX90614 in/from Sleep Mode also resets MLX90614
|
Q:
I could finally erase/write on EEPROM and use the correct PEC calculation. Thanks for the answers.
I was using the PEC calculation code found in this example http://melexis-rf-ics.com/Assets/MLX90614_SMBus_implementation_in_PIC_MCU_5229.aspx.
|