Added Temperature Sensor Support

[hpmax]

Let's try this again from a fresh starting point.

This pull request adds support for the DS18B20 temperature sensor, which was already supported in hardware, but not software.

It adds two parameters in the sensord.conf: output_POV_T which turns on the sentences (just like the other output parameters) temp_config <9|10|11|12> This selects how many bits the user wants to use. 9 bits gives .5 degree C resolution, 12 bits gives .0625 degree C resolution. Conversion time is inversely proportional to resolution. TANSTAAFL.

The code assumes that only a single DS18B20 is attached to the one-wire interface. If more (or different devices) are plugged in, bad behavior may result. Code is included, but is unused and untested to support multiple devices.

[hpmax]

I'm still struggling to figure out how to fix the indent problem -- also, this has enough changes in it that I would consider it untested... Please do NOT approve this yet. I will test this weekend and confirm everything is working, but I believe I have addressed all the other issues. This version incorporates more and better error checking, return values are more consistent (fail is 0, or in the case of OWRead/OWrite is -1).

It now only operates the temperature sensor at all if you turn on the POV_T configuration, and does not report any value if a fault is encountered. The POV string was also changed to have \r\n instead of \n.

[kedder]

Ok, I think I can fix the indent problem in couple of minutes, so if you feel that's a lot of work for you, don't bother. I'll submit a PR with reformat next.

[hpmax]

Thanks for the offer. In the short term, I'd appreciate it. In the long term, I don't want to be dependent on you to fix my mess. I'll install Atom and try to figure out how to deal with this. As it stands, in emacs, I'm not even seeing the problem you're describing (although I'm sure its there).

However, please wait before making the changes. I'd like to try adding one additional feature (to check the status of the conversion) and also test it since it's now been significantly re-written since what I originally tested. I'll try to have everything done by the end of the weekend.

[kedder]

Sure, there's no hurry, take your time.

[hpmax]

The latest commit fixes all the bugs I'm aware of and it now works as designed.

However...

1) I do not think the timing is reliable... and it is equally as unreliable in the previous version. If this is really timing sensitive... It opens the question up whether its actually important that the samples are collected at regular intervals or if its adequate for it to be at close to regular intervals and the exact time between samples is known, since this is MUCH easier to guarantee.

Looking at the Kalman code, it appears that there is a delta time input on the update function. We could measure actual delta time and pass it in.

Immediately prior to executing the conversion for tep_sensor.p, we could execute the following:

clock_gettime(CLOCK_REALTIME,&timestruc);

Immediately after, you would execute:

deltatime=(timestruc.tv_nsec-oldtime)*1e-9; oldtime=timestruc.tv_nsec;

This should be about as accurate as we can get. That said, is there a reason why the Kalman filter only appears to be using ONE sensor, and not all of the available sensors?

2) The DS18B20 is acting weird. The documentation indicates a 12-bit conversion should take a max of 750 ms, but my conversions seem to take less than 10ms.

I'm going to try to contact Maxim and figure this out.