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
--- Begin Message ---
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
signature.asc
Description: OpenPGP digital signature
--- End Message ---
------------------------------------------------------------------------------
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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
