Datanab MAX31850 reading

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Datanab MAX31850 reading

CReese
Hello all,

I have a Datanab TC to 1Wire that uses a MAX31850:

http://www.datanab.com/sensors/1wire-%20thermocouple-sensor-thrmcpl_k.php

The device reads fine using a DS9490R on Windows using a package I have
written to read the device as in the datasheet (OneWire Viewer does not
read temperature on the 31850).

Using a DS2483 on owfs, I get some weird stuff. According to the man
page here (http://owfs.org/uploads/DS1825.html), the temperature should
give CJC, and thermocouple should give CJC-compensated temperature.
These values are as follows (owfs is mounted in Celsius):

Temp (CJT): -1.75
TC:  417

Clearly something is amiss. Moving the 1Wire connection without touching
the TC gives:

CJC: 22C
TC: 55C

Ideas?

Thanks,
Colin



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

Jan Kandziora
Am 29.06.2016 um 21:03 schrieb Colin Reese:

> Hello all,
>
> I have a Datanab TC to 1Wire that uses a MAX31850:
>
> http://www.datanab.com/sensors/1wire-%20thermocouple-sensor-thrmcpl_k.php
>
> The device reads fine using a DS9490R on Windows using a package I have
> written to read the device as in the datasheet (OneWire Viewer does not
> read temperature on the 31850).
>
> Using a DS2483 on owfs, I get some weird stuff. According to the man
> page here (http://owfs.org/uploads/DS1825.html), the temperature should
> give CJC, and thermocouple should give CJC-compensated temperature.
> These values are as follows (owfs is mounted in Celsius):
>
> Temp (CJT): -1.75
> TC:  417
>
> Clearly something is amiss. Moving the 1Wire connection without touching
> the TC gives:
>
> CJC: 22C
> TC: 55C
>
> Ideas?
>
We could also ask Paul Panish (CCed), who made the latest contributions
to module/owlib/src/c/ow_ds1820.c to support the MAX31850 properly.


Kind regards

        Jan


------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

CReese
In reply to this post by CReese
I just pulled off the hex and noted short VDD and also ground short
faults. These also showed up in owfs. I'm waiting on a scratchpad dump
from onewireviewer, but how is this even possible? The device is both
prebuilt commercially and also reads fine into a DS9490R. Is the data
being read incorrectly into owfs?

Thanks,
Colin


On 6/29/2016 12:03 PM, Colin Reese wrote:

> Hello all,
>
> I have a Datanab TC to 1Wire that uses a MAX31850:
>
> http://www.datanab.com/sensors/1wire-%20thermocouple-sensor-thrmcpl_k.php
>
> The device reads fine using a DS9490R on Windows using a package I have
> written to read the device as in the datasheet (OneWire Viewer does not
> read temperature on the 31850).
>
> Using a DS2483 on owfs, I get some weird stuff. According to the man
> page here (http://owfs.org/uploads/DS1825.html), the temperature should
> give CJC, and thermocouple should give CJC-compensated temperature.
> These values are as follows (owfs is mounted in Celsius):
>
> Temp (CJT): -1.75
> TC:  417
>
> Clearly something is amiss. Moving the 1Wire connection without touching
> the TC gives:
>
> CJC: 22C
> TC: 55C
>
> Ideas?
>
> Thanks,
> Colin
>
>

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

Jan Kandziora
Am 29.06.2016 um 21:56 schrieb Colin Reese:
> I just pulled off the hex and noted short VDD and also ground short
> faults. These also showed up in owfs. I'm waiting on a scratchpad
> dump from onewireviewer, but how is this even possible? The device is
> both prebuilt commercially and also reads fine into a DS9490R. Is the
> data being read incorrectly into owfs?
>
My next check would be with the DS9490R and owfs.

Kind regards

        Jan

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

ppanish
In reply to this post by Jan Kandziora
Jan,

I'm afraid I retired shortly after I made those code changes, and I
have't had a working development environment in about a year now. I've
gone back through the code and an email exchange with Paul Alfille to
try and figure out what's going on, and what I had done (see attached
email to Paul).

At the time I did the modifications I was having shared library problems
so that I couldn't use owfs through the linux command line. owlib was
only working through owcapi, and I didn't have easy access to owdir to
see what entries were valid. I wasn't aware that the temperature of the
thermocouple wasn't accessed through the "temperature" entry. As you can
see from my email this was a point of confusion, I assumed the desired
mode of operation was to consistently be able to access temperature in
the same manner across device families. The cold-junction temperature
would not typically be the parameter of interest in using a thermocouple.

I actually still think this is a better model for operation since device
dependent code would otherwise be required to read the hot-junction
temperature for the MAX31850/851. This would be made worse by the fact
that the family code for the MAX31850 is the same as that for the DS1825
thermometer, and the MAX31826 temperature sensor, both of which use
"temperature" as the access string, and for neither of which the
"thermocouple" string would have any meaning.

However, I do agree I mucked up the code and a cleaner fix is necessary.
I may get back to some of this in the winter, but I don't expect to be
doing any coding until then, so perhaps the best option would be to
revert my changes and see if the "thermocouple" access works properly.

Sorry for the confusion.

Paul Panish

Jan Kandziora wrote:

> Am 29.06.2016 um 21:03 schrieb Colin Reese:
>> Hello all,
>>
>> I have a Datanab TC to 1Wire that uses a MAX31850:
>>
>> http://www.datanab.com/sensors/1wire-%20thermocouple-sensor-thrmcpl_k.php
>>
>> The device reads fine using a DS9490R on Windows using a package I have
>> written to read the device as in the datasheet (OneWire Viewer does not
>> read temperature on the 31850).
>>
>> Using a DS2483 on owfs, I get some weird stuff. According to the man
>> page here (http://owfs.org/uploads/DS1825.html), the temperature should
>> give CJC, and thermocouple should give CJC-compensated temperature.
>> These values are as follows (owfs is mounted in Celsius):
>>
>> Temp (CJT): -1.75
>> TC:  417
>>
>> Clearly something is amiss. Moving the 1Wire connection without touching
>> the TC gives:
>>
>> CJC: 22C
>> TC: 55C
>>
>> Ideas?
>>
> We could also ask Paul Panish (CCed), who made the latest contributions
> to module/owlib/src/c/ow_ds1820.c to support the MAX31850 properly.
>
>
> Kind regards
>
> Jan
>

Hi Paul,

I just got around to updating and rebuilding my repository to check out the MAX31850 (sorry it took me so long to get to this)
functionality and I've run into some problems. I use the owcapi, and when I ran my application the temperature values for the
thermocouple devices were wrong.

Issue 1)

I first tried to debug the problem using owfs, but with the new build, from the command line I got the error message:
/opt/owfs/bin/owfs: error while loading shared libraries: libow-2.9.so.5: cannot open shared object file: No such file or directory.

I tried to resolve this using: export $LD_LIBRARY_PATH=/opt/owfs/lib, but that had no effect. I verified that the libraries are
present (they had to be for my application to work) with the proper links in place. I don't know what's happened here, but I
also verified that when I re-install version 2.9 the libraries are found properly.

Issue 2)

I don't know the owlib code, and I don't have a development environment set up to work on it, but I did some poking around to
see if I could resolve the temperature reading problem. Keep in mind that I was using the access string "temperature" for all
temperature devices.

After following code around a bit I found that the problem lies with the Resolution setting. In OW_set_resolution() you're using
the cold junction settings (ResolutionCLD) instead of the compensated junction values (ResolutionTCP). I was able to get correct
readings if I made this substitution.

A point of confusion for me is that this fix requires that the FS_22temp() function be used to access the read callback
functions. This only occurs when the "temperature" type access string is used. Since a thermocouple can be considered to be a
generic temperature reading device (object) this is how I expected the code to function and it allows my code to work with
arbitrary temperature device selection.

The only place ResolutionTCP is used in the original code is in the call sequence through FS_thermocouple(). If I understand the
code this would be accessed with the "thermocouple" access string. Since I have been unable to use owfs to see the directory
structure I hadn't realized this might be a possibility. When I modified my application to use that string it comes back with
around 512 as written with ResolutionTCP, and about 32 degrees C with ResolutionCLD, which would make sense since I have the
MAX31850 sitting on an warm device. Perhaps these two values were simply reversed in the code.

I'm not sure what usage you had in mind. I hope the intent is for "temperature" to return the compensated junction temperature
reading, not the cold junction temperature. From an application perspective that would make more sense, though I don't know what
effect this would have on the different resolution readings (temperature9, 10...) and how difficult this would be to make
workable in the code.

Any insight you could provide would be great.

Regards,

Paul Panish


------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

signature.asc (567 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

ppanish
All,

I just realized the attachment from my email to Paul Alfille wouldn't be
readable for anyone not using Postbox on a Mac. Here's a copy of the
text, sorry about the bad formatting:



Hi Paul,

I just got around to updating and rebuilding my repository to check out
the MAX31850 (sorry it took me so long to get to this)
functionality and I've run into some problems. I use the owcapi, and
when I ran my application the temperature values for the
thermocouple devices were wrong.

Issue 1)

I first tried to debug the problem using owfs, but with the new build,
from the command line I got the error message:
/opt/owfs/bin/owfs: error while loading shared libraries:
libow-2.9.so.5: cannot open shared object file: No such file or directory.

I tried to resolve this using: export $LD_LIBRARY_PATH=/opt/owfs/lib,
but that had no effect. I verified that the libraries are
present (they had to be for my application to work) with the proper
links in place. I don't know what's happened here, but I
also verified that when I re-install version 2.9 the libraries are found
properly.

Issue 2)

I don't know the owlib code, and I don't have a development environment
set up to work on it, but I did some poking around to
see if I could resolve the temperature reading problem. Keep in mind
that I was using the access string "temperature" for all
temperature devices.

After following code around a bit I found that the problem lies with the
Resolution setting. In OW_set_resolution() you're using
the cold junction settings (ResolutionCLD) instead of the compensated
junction values (ResolutionTCP). I was able to get correct
readings if I made this substitution.

A point of confusion for me is that this fix requires that the
FS_22temp() function be used to access the read callback
functions. This only occurs when the "temperature" type access string is
used. Since a thermocouple can be considered to be a
generic temperature reading device (object) this is how I expected the
code to function and it allows my code to work with
arbitrary temperature device selection.

The only place ResolutionTCP is used in the original code is in the call
sequence through FS_thermocouple(). If I understand the
code this would be accessed with the "thermocouple" access string. Since
I have been unable to use owfs to see the directory
structure I hadn't realized this might be a possibility. When I modified
my application to use that string it comes back with
around 512 as written with ResolutionTCP, and about 32 degrees C with
ResolutionCLD, which would make sense since I have the
MAX31850 sitting on an warm device. Perhaps these two values were simply
reversed in the code.

I'm not sure what usage you had in mind. I hope the intent is for
"temperature" to return the compensated junction temperature
reading, not the cold junction temperature. From an application
perspective that would make more sense, though I don't know what
effect this would have on the different resolution readings
(temperature9, 10...) and how difficult this would be to make
workable in the code.

Any insight you could provide would be great.

Regards,

Paul Panish


Paul W Panish wrote:

> Jan,
>
> I'm afraid I retired shortly after I made those code changes, and I
> have't had a working development environment in about a year now. I've
> gone back through the code and an email exchange with Paul Alfille to
> try and figure out what's going on, and what I had done (see attached
> email to Paul).
>
> At the time I did the modifications I was having shared library problems
> so that I couldn't use owfs through the linux command line. owlib was
> only working through owcapi, and I didn't have easy access to owdir to
> see what entries were valid. I wasn't aware that the temperature of the
> thermocouple wasn't accessed through the "temperature" entry. As you can
> see from my email this was a point of confusion, I assumed the desired
> mode of operation was to consistently be able to access temperature in
> the same manner across device families. The cold-junction temperature
> would not typically be the parameter of interest in using a thermocouple.
>
> I actually still think this is a better model for operation since device
> dependent code would otherwise be required to read the hot-junction
> temperature for the MAX31850/851. This would be made worse by the fact
> that the family code for the MAX31850 is the same as that for the DS1825
> thermometer, and the MAX31826 temperature sensor, both of which use
> "temperature" as the access string, and for neither of which the
> "thermocouple" string would have any meaning.
>
> However, I do agree I mucked up the code and a cleaner fix is necessary.
> I may get back to some of this in the winter, but I don't expect to be
> doing any coding until then, so perhaps the best option would be to
> revert my changes and see if the "thermocouple" access works properly.
>
> Sorry for the confusion.
>
> Paul Panish
>
> Jan Kandziora wrote:
>> Am 29.06.2016 um 21:03 schrieb Colin Reese:
>>> Hello all,
>>>
>>> I have a Datanab TC to 1Wire that uses a MAX31850:
>>>
>>> http://www.datanab.com/sensors/1wire-%20thermocouple-sensor-thrmcpl_k.php
>>>
>>>
>>> The device reads fine using a DS9490R on Windows using a package I have
>>> written to read the device as in the datasheet (OneWire Viewer does not
>>> read temperature on the 31850).
>>>
>>> Using a DS2483 on owfs, I get some weird stuff. According to the man
>>> page here (http://owfs.org/uploads/DS1825.html), the temperature should
>>> give CJC, and thermocouple should give CJC-compensated temperature.
>>> These values are as follows (owfs is mounted in Celsius):
>>>
>>> Temp (CJT): -1.75
>>> TC: 417
>>>
>>> Clearly something is amiss. Moving the 1Wire connection without touching
>>> the TC gives:
>>>
>>> CJC: 22C
>>> TC: 55C
>>>
>>> Ideas?
>>>
>> We could also ask Paul Panish (CCed), who made the latest contributions
>> to module/owlib/src/c/ow_ds1820.c to support the MAX31850 properly.
>>
>>
>> Kind regards
>>
>> Jan
>>

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

CReese
In reply to this post by Jan Kandziora
Indeed. Unfortunately onewireviewer won't even give me raw scratchpad data.

It seems to me that since the temperature (ds1825) and CJC compensated temperature (31850) are in the same place (bytes 0-1) they should both be delivered to 'temperature' and CJC (1-2) should be in an auxiliary location.

C

> On Jun 29, 2016, at 1:49 PM, Jan Kandziora <[hidden email]> wrote:
>
>> Am 29.06.2016 um 21:56 schrieb Colin Reese:
>> I just pulled off the hex and noted short VDD and also ground short
>> faults. These also showed up in owfs. I'm waiting on a scratchpad
>> dump from onewireviewer, but how is this even possible? The device is
>> both prebuilt commercially and also reads fine into a DS9490R. Is the
>> data being read incorrectly into owfs?
> My next check would be with the DS9490R and owfs.
>
> Kind regards
>
>    Jan
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

CReese
In reply to this post by Jan Kandziora
DS9490R yields similar results. This time only a ground short is
observed. Again, this seemed to read fine into a DS9490R using the TMEX
API through LabVIEW.

Looking at the two datasheets, there is no way to avoid device-dependent
code. There need to be three distinct values: temperature,
tctemperature, and tcjctemperature.

The reason for this is that the temperature in bytes 0-1 is formatted
differently in the MSB. See below for summary for temp (DS1825) and
CJC-compensated temp:

Bit / DS1825 / MAX31850
0 - 2^-4 - Fault
1 - 2^-3 - Reserved
2 - 2^-2 - 2^-2
3 - 2^-1 - 2^-1
4 - 2^0 - 2^0
5 - 2^1 - 2^1
6 - 2^2 - 2^2
7 - 2^3 - 2^3

8 - 2^4 - 2^4
9 - 2^5 - 2^5
10 - 2^6 - 2^6
11 - S - 2^7
12 - S - 2^8
13 - S -2^9
14 - S - 2^10
15 - S - S

Thus, you need to know whether you are looking for a value interpreted
as a DS1825 or as a MAX31850. Because they are indistinguishable from
software, you'd just know which one to read. This is the way that I
wrote the routine on the LabVIEW program I wrote using TMEX API. You
just have to know which value to read.

Still, even with this, I cannot match up the value being read with owfs
with either interpretation. A hex dump of the scratchpad, for example,
gives me:

e9 00 f2 0e ff ff ff ff 29

Big endian, LSB MSB
e9 00 = 11101001 11110010

This gives me -14.5625 for a DS1825 and 14.5 for a 31850.

For bytes 2-3:
f2 0e 11110010 00001110

This gives me 14.9375 for a 31850, with a ground short fault.

Values read by owfs are 0.875 for temp and 236 for thermocouple.

So ... should I just read the scratchpad and do my own conversion, or
can someone rewrite this?

Colin








On 6/29/2016 1:49 PM, Jan Kandziora wrote:

> Am 29.06.2016 um 21:56 schrieb Colin Reese:
>> I just pulled off the hex and noted short VDD and also ground short
>> faults. These also showed up in owfs. I'm waiting on a scratchpad
>> dump from onewireviewer, but how is this even possible? The device is
>> both prebuilt commercially and also reads fine into a DS9490R. Is the
>> data being read incorrectly into owfs?
>>
> My next check would be with the DS9490R and owfs.
>
> Kind regards
>
> Jan
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

Jan Kandziora
Am 30.06.2016 um 08:30 schrieb Colin Reese:
>
> Thus, you need to know whether you are looking for a value interpreted
> as a DS1825 or as a MAX31850. Because they are indistinguishable from
> software,
>
They are distinguishable. The DS1825 configuration register bit 7 reads
always 0. The MAX31850 (and MAX31826) configuration register bit 7 reads
always 1. See the datasheets (pp. 8/13/9 resp.).


>
> So ... should I just read the scratchpad and do my own conversion, or
> can someone rewrite this?
>
We can and should. Unfortunately I have none of these devices at hand.


Kind regards

        Jan

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

Jan Kandziora
In reply to this post by ppanish
Am 29.06.2016 um 23:51 schrieb Paul W Panish:
> All,
>
> I just realized the attachment from my email to Paul Alfille wouldn't
> be readable for anyone not using Postbox on a Mac. Here's a copy of
> the text, sorry about the bad formatting:
>
Thanks for the reply, Paul.

I try to understand all this first.

Kind regards

        Jan

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

ppanish
Sure, sorry I can't be of more help at the moment.

To be clear, with the changes I made, which were done empirically, I was able to read the hot junction thermocouple temperature using the  "temperature" access string on the MAX31850 development board I had purchased. It also read properly with the different resolution access strings, "temperature9", "temperature10"...

As I recall, without the two code changes I made, the value returned by "temperature" made no sense for either the cold or hot junction. I don't think I checked what "thermocouple" returned, but it's not clear to me from my email exactly what experiments I performed.

Paul W Panish
Mobile: (603) 343-8901

> On Jun 30, 2016, at 04:56, Jan Kandziora <[hidden email]> wrote:
>
>> Am 29.06.2016 um 23:51 schrieb Paul W Panish:
>> All,
>>
>> I just realized the attachment from my email to Paul Alfille wouldn't
>> be readable for anyone not using Postbox on a Mac. Here's a copy of
>> the text, sorry about the bad formatting:
> Thanks for the reply, Paul.
>
> I try to understand all this first.
>
> Kind regards
>
>    Jan

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

CReese
In what rev were these made? I'm on 2.9 I believe and neither make sense.

What is the possibility that scratchpad gets read wrong? I have no visibility into the code but the faults I am observing are suspect, considering everything reads fine using tmex.


> On Jun 30, 2016, at 3:58 AM, Paul W Panish <[hidden email]> wrote:
>
> Sure, sorry I can't be of more help at the moment.
>
> To be clear, with the changes I made, which were done empirically, I was able to read the hot junction thermocouple temperature using the  "temperature" access string on the MAX31850 development board I had purchased. It also read properly with the different resolution access strings, "temperature9", "temperature10"...
>
> As I recall, without the two code changes I made, the value returned by "temperature" made no sense for either the cold or hot junction. I don't think I checked what "thermocouple" returned, but it's not clear to me from my email exactly what experiments I performed.
>
> Paul W Panish
> Mobile: (603) 343-8901
>
>>> On Jun 30, 2016, at 04:56, Jan Kandziora <[hidden email]> wrote:
>>>
>>> Am 29.06.2016 um 23:51 schrieb Paul W Panish:
>>> All,
>>>
>>> I just realized the attachment from my email to Paul Alfille wouldn't
>>> be readable for anyone not using Postbox on a Mac. Here's a copy of
>>> the text, sorry about the bad formatting:
>> Thanks for the reply, Paul.
>>
>> I try to understand all this first.
>>
>> Kind regards
>>
>>   Jan
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

ppanish
It looks like Paul submitted my changes in v2.9p6. Support for the
MAX31850 was added in v2.9p2. Not sure what you're saying beyond this,
and I haven't worked with the scratchpad registers.

When I modified this code I basically performed a dump of the data
available in the ow_1820.c module to find which data structure held the
correct information for the hot junction temperature. I then modified
the code to present this data on a "temperature" query. Two years later
I don't really remember the specifics.

If you're running a version prior to 2.9p6 I'd suggest you update at
least that far and give it a try.

Colin Reese wrote:

> In what rev were these made? I'm on 2.9 I believe and neither make sense.
>
> What is the possibility that scratchpad gets read wrong? I have no visibility into the code but the faults I am observing are suspect, considering everything reads fine using tmex.
>
>
>> On Jun 30, 2016, at 3:58 AM, Paul W Panish<[hidden email]>  wrote:
>>
>> Sure, sorry I can't be of more help at the moment.
>>
>> To be clear, with the changes I made, which were done empirically, I was able to read the hot junction thermocouple temperature using the  "temperature" access string on the MAX31850 development board I had purchased. It also read properly with the different resolution access strings, "temperature9", "temperature10"...
>>
>> As I recall, without the two code changes I made, the value returned by "temperature" made no sense for either the cold or hot junction. I don't think I checked what "thermocouple" returned, but it's not clear to me from my email exactly what experiments I performed.
>>
>> Paul W Panish
>> Mobile: (603) 343-8901
>>
>>>> On Jun 30, 2016, at 04:56, Jan Kandziora<[hidden email]>  wrote:
>>>>
>>>> Am 29.06.2016 um 23:51 schrieb Paul W Panish:
>>>> All,
>>>>
>>>> I just realized the attachment from my email to Paul Alfille wouldn't
>>>> be readable for anyone not using Postbox on a Mac. Here's a copy of
>>>> the text, sorry about the bad formatting:
>>> Thanks for the reply, Paul.
>>>
>>> I try to understand all this first.
>>>
>>> Kind regards
>>>
>>>    Jan
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> Owfs-developers mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

CReese
Ok I'm on 2.9.5. I'll update. I figured that the module you wrote was low level stuff but apparently I don't know what does what.

C

> On Jun 30, 2016, at 7:34 PM, Paul W Panish <[hidden email]> wrote:
>
> It looks like Paul submitted my changes in v2.9p6. Support for the
> MAX31850 was added in v2.9p2. Not sure what you're saying beyond this,
> and I haven't worked with the scratchpad registers.
>
> When I modified this code I basically performed a dump of the data
> available in the ow_1820.c module to find which data structure held the
> correct information for the hot junction temperature. I then modified
> the code to present this data on a "temperature" query. Two years later
> I don't really remember the specifics.
>
> If you're running a version prior to 2.9p6 I'd suggest you update at
> least that far and give it a try.
>
> Colin Reese wrote:
>> In what rev were these made? I'm on 2.9 I believe and neither make sense.
>>
>> What is the possibility that scratchpad gets read wrong? I have no visibility into the code but the faults I am observing are suspect, considering everything reads fine using tmex.
>>
>>
>>> On Jun 30, 2016, at 3:58 AM, Paul W Panish<[hidden email]>  wrote:
>>>
>>> Sure, sorry I can't be of more help at the moment.
>>>
>>> To be clear, with the changes I made, which were done empirically, I was able to read the hot junction thermocouple temperature using the  "temperature" access string on the MAX31850 development board I had purchased. It also read properly with the different resolution access strings, "temperature9", "temperature10"...
>>>
>>> As I recall, without the two code changes I made, the value returned by "temperature" made no sense for either the cold or hot junction. I don't think I checked what "thermocouple" returned, but it's not clear to me from my email exactly what experiments I performed.
>>>
>>> Paul W Panish
>>> Mobile: (603) 343-8901
>>>
>>>>> On Jun 30, 2016, at 04:56, Jan Kandziora<[hidden email]>  wrote:
>>>>>
>>>>> Am 29.06.2016 um 23:51 schrieb Paul W Panish:
>>>>> All,
>>>>>
>>>>> I just realized the attachment from my email to Paul Alfille wouldn't
>>>>> be readable for anyone not using Postbox on a Mac. Here's a copy of
>>>>> the text, sorry about the bad formatting:
>>>> Thanks for the reply, Paul.
>>>>
>>>> I try to understand all this first.
>>>>
>>>> Kind regards
>>>>
>>>>   Jan
>>> ------------------------------------------------------------------------------
>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> Owfs-developers mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

Uwe Bonnes
In reply to this post by CReese

In article <[hidden email]> you wrote:
> Hello all,

> I have a Datanab TC to 1Wire that uses a MAX31850:

> http://www.datanab.com/sensors/1wire-%20thermocouple-sensor-thrmcpl_k.php

> The device reads fine using a DS9490R on Windows using a package I have
> written to read the device as in the datasheet (OneWire Viewer does not
> read temperature on the 31850).

> Using a DS2483 on owfs, I get some weird stuff. According to the man
> page here (http://owfs.org/uploads/DS1825.html), the temperature should
> give CJC, and thermocouple should give CJC-compensated temperature.
> These values are as follows (owfs is mounted in Celsius):

Hello,

this is the third attempt for a reponse:
- First direct to the asker and Jan
- Reply via gmane after successfull subscription.
- and now via my normal mailer

The manual page tells that the internal chip temperature is the content of
the */temperatur* files and the cold junction compensated thermocouple
temperature is the content of */thermocouple.

The Chip has the thermocouple temperature at data[0] and the internal
temperature at data[2]. However all other similar chips have the temperature
at data[0].

Current code only mixes up data and interpretation. Appended patch fixes the
readings.

Please apply!

Cheers
--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
>From 28b19bf33327bab73d843e1331eaab681e8ff5ba Mon Sep 17 00:00:00 2001
From: Uwe Bonnes <[hidden email]>
Date: Tue, 6 Sep 2016 13:13:00 +0200
Subject: MAX32850: Fix values for thermocouple and temperature data.

---
 module/owlib/src/c/ow_1820.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/module/owlib/src/c/ow_1820.c b/module/owlib/src/c/ow_1820.c
index 874746d..47346f8 100644
--- a/module/owlib/src/c/ow_1820.c
+++ b/module/owlib/src/c/ow_1820.c
@@ -932,9 +932,12 @@ static GOOD_OR_BAD OW_22latesttemp(_FLOAT * temp, enum temperature_problem_flag
  Resolution = &Resolution12 ;
  break ;
  }
-
- temp[0] = OW_masked_temperature( data, Resolution ) ;
-
+        if ((pn->sn[0] == 0x3B) && (data[4] & 0x80)) {
+            /* MAX31850 shows internal temperature at data[2] as "temperatureXXX"! */
+            temp[0] = ((_FLOAT) ((int16_t) ((data[3] << 8) | (data[2] & 0xf0)))) / 256.0;
+        } else {
+            temp[0] = OW_masked_temperature( data, Resolution ) ;
+        }
  if ( accept_85C==allow_85C || data[0] != 0x50 || data[1] != 0x05 ) {
  return gbGOOD;
  }
@@ -964,13 +967,12 @@ static GOOD_OR_BAD OW_thermocouple(_FLOAT * temp, enum temperature_problem_flag
 
  RETURN_BAD_IF_BAD(OW_r_scratchpad(data, pn)) ;
 
- temp[0] = OW_masked_temperature( &data[2], Resolution ) ;
-
  if ( (data[0] & 0x01)  || (data[2] & 0x07)) {
  // Fault flag
  LEVEL_DEBUG("Error flag on thermocouple read of %s",pn->path) ;
  return gbBAD ;
  }
+ temp[0] = OW_masked_temperature( &data[0], Resolution ) ;
 
  return gbGOOD ;
 }
--
2.6.6


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

Jan Kandziora
Am 09.09.2016 um 11:15 schrieb Uwe Bonnes:

>
> In article <[hidden email]> you wrote:
>> Hello all,
>
>> I have a Datanab TC to 1Wire that uses a MAX31850:
>
>> http://www.datanab.com/sensors/1wire-%20thermocouple-sensor-thrmcpl_k.php
>
>> The device reads fine using a DS9490R on Windows using a package I have
>> written to read the device as in the datasheet (OneWire Viewer does not
>> read temperature on the 31850).
>
>> Using a DS2483 on owfs, I get some weird stuff. According to the man
>> page here (http://owfs.org/uploads/DS1825.html), the temperature should
>> give CJC, and thermocouple should give CJC-compensated temperature.
>> These values are as follows (owfs is mounted in Celsius):
>
> Hello,
>
> this is the third attempt for a reponse:
> - First direct to the asker and Jan
> - Reply via gmane after successfull subscription.
> - and now via my normal mailer
>
> The manual page tells that the internal chip temperature is the content of
> the */temperatur* files and the cold junction compensated thermocouple
> temperature is the content of */thermocouple.
>
> The Chip has the thermocouple temperature at data[0] and the internal
> temperature at data[2]. However all other similar chips have the temperature
> at data[0].
>
> Current code only mixes up data and interpretation. Appended patch fixes the
> readings.
>
Uwe, I am not sure how we should handle this. IIRC, in the past, the
temperature values had been the way you suggest. But for some reason I
not aware anymore, this had been switched.

We have to find the reason why it's bogus as it is now.

Kind regards

        Jan


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

Uwe Bonnes
>>>>> "Jan" == Jan Kandziora <[hidden email]> writes:

    Jan> Am 09.09.2016 um 11:15 schrieb Uwe Bonnes:
    Jan> Uwe, I am not sure how we should handle this. IIRC, in the past,
    Jan> the temperature values had been the way you suggest. But for some
    Jan> reason I not aware anymore, this had been switched.

My patch handles it at it is describes in ./src/man/man3/DS1825.man for the
MAX31850.

    Jan> We have to find the reason why it's bogus as it is now.

The reason why it is bogus is, that the present code does not return values
according to the secription in the man page.

If it has switched, the man-page should be updated...

Bye
--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

Jan Kandziora
Am 09.09.2016 um 14:00 schrieb Uwe Bonnes:

>>>>>> "Jan" == Jan Kandziora <[hidden email]> writes:
>
>     Jan> Am 09.09.2016 um 11:15 schrieb Uwe Bonnes:
>     Jan> Uwe, I am not sure how we should handle this. IIRC, in the past,
>     Jan> the temperature values had been the way you suggest. But for some
>     Jan> reason I not aware anymore, this had been switched.
>
> My patch handles it at it is describes in ./src/man/man3/DS1825.man for the
> MAX31850.
>
>     Jan> We have to find the reason why it's bogus as it is now.
>
> The reason why it is bogus is, that the present code does not return values
> according to the secription in the man page.
>
> If it has switched, the man-page should be updated...
>
I just applied your patch to head. Let's see who's crying out loud after
next update.

Kind regards

        Jan


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

ppanish
In reply to this post by Uwe Bonnes
Jan, Uwe:

The values were switched as a result of the change I submitted to Paul a
couple of years ago. I was experimenting with the MAX31850 and getting
what I thought were garbage results. I was not familiar with the code
and submitted a simple change that I worked out empirically by
inspecting the data structure for the device. I was unaware of the man
page for this device and assumed the thermocouple temperature (hot
junction) should be returned by a "temperature" query.

For my changes I assumed the OWFS implementation should follow a
consistent object model where the measured temperature is returned with
a standard query (one of the "temperature" values), and explained to
Paul what I had done. I assume he was too busy at the time to pay much
attention to what I was saying and he committed my changes without review.

I see Jan just applied the patch to bring the code back in line with the
documentation. I don't think many people are using this, and if they are
they're not paying attention to the documentation, so I doubt there will
be much response to the change.

While use is still limited I'd encourage you to consider following the
object model for other temperature devices, and change the documentation
to concur. I'm sure this would still require some code cleanup. I'm not
invested in this approach in any way, I just think it's a cleaner
implementation from a device abstraction perspective.

Regards,

Paul Panish


Uwe Bonnes wrote:

>>>>>> "Jan" == Jan Kandziora<[hidden email]>  writes:
>
>      Jan>  Am 09.09.2016 um 11:15 schrieb Uwe Bonnes:
>      Jan>  Uwe, I am not sure how we should handle this. IIRC, in the past,
>      Jan>  the temperature values had been the way you suggest. But for some
>      Jan>  reason I not aware anymore, this had been switched.
>
> My patch handles it at it is describes in ./src/man/man3/DS1825.man for the
> MAX31850.
>
>      Jan>  We have to find the reason why it's bogus as it is now.
>
> The reason why it is bogus is, that the present code does not return values
> according to the secription in the man page.
>
> If it has switched, the man-page should be updated...
>
> Bye

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Datanab MAX31850 reading

Uwe Bonnes
>>>>> "Paul" == Paul W Panish <[hidden email]> writes:

    Paul> Jan, Uwe: The values were switched as a result of the change I
    Paul> submitted to Paul a couple of years ago. I was experimenting with
    Paul> the MAX31850 and getting what I thought were garbage results. I
    Paul> was not familiar with the code and submitted a simple change that
    Paul> I worked out empirically by inspecting the data structure for the
    Paul> device. I was unaware of the man page for this device and assumed
    Paul> the thermocouple temperature (hot junction) should be returned by
    Paul> a "temperature" query.

    Paul> For my changes I assumed the OWFS implementation should follow a
    Paul> consistent object model where the measured temperature is returned
    Paul> with a standard query (one of the "temperature" values), and
    Paul> explained to Paul what I had done. I assume he was too busy at the
    Paul> time to pay much attention to what I was saying and he committed
    Paul> my changes without review.

    Paul> I see Jan just applied the patch to bring the code back in line
    Paul> with the documentation. I don't think many people are using this,
    Paul> and if they are they're not paying attention to the documentation,
    Paul> so I doubt there will be much response to the change.

    Paul> While use is still limited I'd encourage you to consider following
    Paul> the object model for other temperature devices, and change the
    Paul> documentation to concur. I'm sure this would still require some
    Paul> code cleanup. I'm not invested in this approach in any way, I just
    Paul> think it's a cleaner implementation from a device abstraction
    Paul> perspective.

 So you mean that */temperature* should return the thermocouple temperature
 and */thermocouple should vanish and */coldjunction (or a similar name)
 should appear and  return the internal temperature?

This sounds also much clearer to me and I will try to make a patch to the
docs and the code, if I get confirmation that this approch is right.

Any other ideas for a sensible filename to return internal temperature?

Bye
--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
12