I have used this sensor in many projects and I think I always had it wrong. How long does it actually take to make a conversion for a single device. I always thought it was on order of 750 ms. I just did the following and it seems that the conversion time is not what I thought it would be. The text isn't complete by any stretch of the imagination, but if I am doing something wrong it would be good to know about it now. I want to control the conversion so I can do things while the conversion is taking place.
In setup I basically get the device address and tell the library to not wait for conversion
void setup(void)
{
// start serial port
Serial.begin(9600);
while (!Serial.dtr());
Serial.println("Dallas Temperature: ");
// Start up the library
sensors.begin();
deviceCount = sensors.getDeviceCount();
Serial.print("Device Count: " );
Serial.println (deviceCount);
sensors.getAddress(device, (uint8_t)0);
for (int i = 0; i < 8; i++)
{
Serial.print(device[i], HEX);
Serial.print(":");
}
Serial.println();
bool wfcf = sensors.getWaitForConversion();
Serial.print("WaitForConversion: ");
Serial.println(wfcf); // Reports 1 or true
sensors.setWaitForConversion(false);
wfcf = sensors.getWaitForConversion();
Serial.print("WaitForConversion 2: ");
Serial.println(wfcf); // Reports 0 or false
}
isConversionAvailable always returns true immediately, the temperature looks good but it could easily be the last valid temperature. Is there something else I need to do to use this technique?
If I remove the setting of the wait for conversion and use the default as true, it does take 752ms for the conversion to take place.
nefArduino:
I want to control the conversion so I can do things while the conversion is taking place.
Glad to hear you got the problem fixed but I rather suspect it was because of something else. I think the whole point of these things is that you can "do things while the conversion is taking place", which goes quite some way to explain why you can get readings from several with 12 bit resolution at one second intervals. If the library really was the problem, people would have been complaining for years, and not waiting for version 3.7.9.
I understand that there are mysterious commands available to control the conversion time wait, but I'm not sure that is what you are looking for, they are probably not relevant to your problem, and I don't see the point of them anyway.
The documentation in the header says that this call "Only applies to the first sensor on the wire."
Is this a technology issue, it just can't be done, or an implementation problem.
if I call requestTemperaturesByAddress for a few sensors on the wire, I can only see that the first one is done? Does this imply I should call this on the first sensor after all of the others so when it is done, I know I ca check the others?
I obviously don't understand how the oneWire protocol works.
nefArduino:
The documentation in the header says that this call "Only applies to the first sensor on the wire." .........I obviously don't understand how the oneWire protocol works.
Evidently, but I wonder what documentation, and what header. There's the real mystery.
This is not a cross post. The other question was asked and answered. I was using an old library where IsConversionComplete didn't seem to work and I needed figure out how. I moved to a new library version and changed the name of the method and it now works.
I was under the impression that I was not to keep adding new questions to an old post? Aren't those the rules?
In the 3.7.3 version of the library the method was called:
bool isConversionAvailable(const uint8_t*); // and it seemed to work for any device on the wire but didnt
for 3.7.9 version of the library the method was called:
bool isConversionComplete(void); // and only works for the first device on the wire.
The documentation I was referring to is the header comment just above the method declaration
// Is a conversion complete on the wire? Only applies to the first sensor on the wire.
bool isConversionComplete(void);
Probaly right, but your new question, which started with what is now reply #6, was a totally incomprehensible waste of time, so it might pay to sit back and try to think about what the real problem is, how you might coherently explain it, and start over again - with a proper heading.
I'm not sure that the statement is correct. You can issue a SKIP ROM command and then a Convert T command to make all sensors on the bus start a conversion (this is non-parasite mode) - this is what the requestTemperatures function does. If you then call isConversionComplete it issues a read slot on the bus and if a sensor has not finished converting it grounds the bus. The datasheet isn't clear what happens in this situation but it seems to me that if you do this, getting a zero from isConversionComplete would mean that at least one sensor is still doing a conversion but you won't know which one (or more). In theory, you can keep calling isConversionComplete until it returns true and then all of them will have completed a conversion.
If I find some time, I may play with this to try to sort out what really happens.
In the 3.7.3 version of the library the method was called:
bool isConversionAvailable(const uint8_t*);
And this form implies you can ask about any device on the wire.
The newer version seemed to go backwards
for 3.7.9 version of the library the method was called:
bool isConversionComplete(void); // and only works for the first device on the wire.
So something about the 3.7.3 didn't work, why else would they reduce functionality?
After seeing this, and switching from 3.7.3 to 3.7.9 and having it work one asks the question:
Is the change because the 3.7.3 version will not work or was the functionality pulled back because it was hard and needed more time.
Why would someone want to know this? Because if you are building a device with multiple independent temperature sensors and the project needs to know if each sensor is done converting then it might be best to implement each sensor on its own wire.
Knowing this gives someone implementing a project with multiple sensors a set of constraints to work with.
el_supremo:
I'm not sure that the statement is correct.
Do you mean the comment in the header file, that it only works on the first sensor?
I don't need this for my current project, I do need it for my next project and thought I would ask while I was thinking of it. I will do a setup like I need for the next project and request temperature on the second or third device and then check for conversion. It is strange that the functionality would go backwards, so i suspect you are correct.
And the resulting temperature seemed correct. I heated up the sensor that corresponds to the first device and the temperature.
It does seem the comment in the header file is incorrect. It does have the problem that one has to check all of the thermometers to see which one was different unless one keeps track of the one asked for. This is a little more work on the part of the application but still useful.
I can post the complete code if anyone is interested.