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 Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
