| View previous topic :: View next topic |
| Author |
Message |
hevermarc
Joined: 20 Mar 2019
Posts: 2
|
| Problem with MLX90614 temperature sensor |
 Posted: Wed Mar 20, 2019 10:41 am |
 |
|
Re Gabriel's MLX90614 driver:
http://www.ccsinfo.com/forum/viewtopic.php?t=55507
I am using your code, but data is not being read correctly.
I could see some variation in temperature. But not correct.
| Code: |
Object Temp:-272.01
Ambient Temp:-270.98
Object Temp:-272.79
Ambient Temp:-270.02
|
|
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Wed Mar 20, 2019 4:07 pm |
|
|
On the library post, there is another user with the same problem and a possible solution.
I would follow PCM's advice first, then try the solution on the library comments.
I developed the driver using MikroE's Clicker 2 boards and the corresponding Click board, so I'm guessing there might be some hardware issue on your side.
Or something I did not foresee on my code due to My specific hardware.
G.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9133
Location: Greensville,Ontario
|
|
| Posted: Wed Mar 20, 2019 4:38 pm |
|
|
While I don't have that temp sensor, I have to ask what are you using as a reference temperature sensor ? Both groups of reading are within '1' (-272.01 and -272.79).
Where is the sensor located ? What is the power supply ? Have you the recommended filtering and EMI protection ? Have you 'waited' long enough between the samples (per the datasheet) ? There are dozens of hardware possibilities for 2 readings to not be identical IF they're supposed to be.
From a software aspect, print out all the data from raw to final answer, including all intermediate calculations. Do all the math by hand, decode the data from the sensor and confirm/deny where the problem may be.
You, of course, should never ever rely upon one reading from one sensor. As to why, well..read up on the 737 MAX8 stall control system.
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Mar 20, 2019 6:29 pm |
|
|
Those numbers come from these equations:
| Code: | void Read_Object()
{
fprintf(lcd_putc,"Object Temp:%3.2f\r\n",((MLX_Read_Transaction(OT_Address)*0.02)-273));
delay_ms(500);
}
void Read_Ambient()
{
fprintf(lcd_putc,"Ambient Temp:%3.2f\r\n",((MLX_Read_Transaction(AT_Address)*0.02)-273));
delay_ms(500);
} |
Take a small reading from the MLX90614, divide it by 50, then add -273
to it. That will give the results he is seeing. |
|
|
hevermarc
Joined: 20 Mar 2019
Posts: 2
|
|
| Posted: Wed Mar 20, 2019 9:06 pm |
|
|
Hi guys, I don't know why, but my circuit is working now after change my settings to i2c by software. While I was using i2c by hardware I couldn't to communicate with the mlx60914 module.
| Code: |
#Include <16F877.H>
#Fuses HS,NOWDT,PROTECT,PUT,BROWNOUT
#Use delay(clock=4000000)
#Use RS232(baud=9600,xmit=pin_c6,rcv=pin_c7,errors,restart_wdt)
//#Use I2C(master, sda=PIN_C4, scl=PIN_C3)
#Use I2C(master, sda=PIN_D0, scl=PIN_D1) |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19255
|
|
| Posted: Thu Mar 21, 2019 12:08 am |
|
|
Speed.
You are not specifying a clock rate for the I2C.
The default is always 'as fast as possible'. Using the hardware port
you will be exceeding the speed rating of the chip. Software I2C is
much slower, so you are getting away with it. However in both cases
you really should be specifying the clock rate. Just use the keyword
'SLOW' or specify a rate so 'SLOW=100000'.
When a rate is specified, this becomes the maximum that can be used.
Slow defaults to 100000 max, which is the maximum the chip supports.
In the hardware mode, you are probably trying to use 400000, which
is 'fast' I2C. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9133
Location: Greensville,Ontario
|
|
| Posted: Thu Mar 21, 2019 4:50 am |
|
|
Curious, so I downloaded the sensor's datasheet. It says it is an SMBus device not I2C. That got me wondering if the OP should be using the SMBus option for the #USE I2C(......).
It may 'tweak' the I/O pins for better (proper) communications ? I've never looked 'into the die' to see what actually does get changed as I can't recall ever having used an SMBus device in 25 years of Playing with PICs.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19255
|
|
| Posted: Thu Mar 21, 2019 6:44 am |
|
|
For the master, it shouldn't matter.
Main differences:
SMBUS inputs have lower ViH
Since the 'high' is dependant on the pull up and not the device, shouldn't
matter.
SMBUS supports 100KHz maximum. I2C supports 400K on fast mode,
and even more with active pull-ups.
SMBUS adds the requirement for a check byte, but the driver being used
here generates this.
However the speed difference allowed is critical here.... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
