further, calling it anything else would be confusing. This IS the
technical term for this reference temperature.
C
On 9/9/2016 2:03 PM, Colin Law wrote:
> On 9 September 2016 at 15:20, Matthias Urlichs wrote:
>> On 09.09.2016 15:50, Uwe Bonnes wrote:
>>> So you mean that */temperature* should
On 9 September 2016 at 15:20, Matthias Urlichs wrote:
> On 09.09.2016 15:50, Uwe Bonnes wrote:
>> 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 tempe
Uwe,
Yes, that's what I was thinking. I hope the group will agree this is the
best approach.
Paul P
Uwe Bonnes wrote:
>> "Paul" == Paul W Panish 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 w
Am 09.09.2016 um 15:50 schrieb Uwe Bonnes:
>
> 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
On 09.09.2016 15:50, Uwe Bonnes wrote:
> 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 t
> "Paul" == Paul W Panish 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
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
inspect
Am 09.09.2016 um 14:00 schrieb Uwe Bonnes:
>> "Jan" == Jan Kandziora 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
> J
> "Jan" == Jan Kandziora 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
Am 09.09.2016 um 11:15 schrieb Uwe Bonnes:
>
> In article <5db40b85-90cb-333c-bf0e-ba66a5f26...@gmail.com> 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 u
In article <5db40b85-90cb-333c-bf0e-ba66a5f26...@gmail.com> 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
> writt
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 wrote:
>
> It looks like Paul submitted my changes in v2.9p6. Support for the
> MAX31850 was added in v2.9p2. Not s
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 f
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
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 wit
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 t
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 MAX31
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,
tcte
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 locatio
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 to
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
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
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 incor
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
24 matches
Mail list logo
