[wiregate] Rounding errors in reported temperatures?

[martenss]

Since a few months I am a happy WG owner with about 20 sensors installed. 1-Wire bus is fully stable after having equipped an USB hub with 3 bus masters (all eqpt bought from the WG shop) - I can only advise to use the externally powered USB hub as this solved the initial flapping of my bus.

There is however still one particular issue that I would like to get solved.
Reported temperatures are quite often *.24 and *.74, where I would prefer *.25 and *.75; similar to what is shown in the WG Sensor page. The problem is not always there, the same GA is sometimes sent with *.25 / *.75 - as expected.

Some example (from the WG busmonitor) :
2011-01-27 23:56:59.305,A_GroupValue_Write,0.0.0,5/3/201,0C 26,21.24,DPT_Value_Temp,9.001,0,low,7,T_DATA_XXX_R EQ,0
2011-01-27 23:56:59.614,A_GroupValue_Write,0.0.0,5/3/204,0C 0D,20.74,DPT_Value_Temp,9.001,0,low,7,T_DATA_XXX_R EQ,0

In my EibPC I often see these telegrams coming in as follows:
2011-01-28 00:13:21 | Sender: 1.1.1 | GA: '5/3/200'f16 | Value: 21.740000000000002 | Typ: 16-Bit-Fliesskommazahl | Schreiben
Note sure where the additional *.**0000000000002 is coming from.

Any advise on where the problem could be?
Note that I used the default 10 bit "Auflösung".

Thanks for your help, martenss

[makki]

Hmm, these are indeed rounding issues, Chris recently wrote a nice post about what floating-point precision is good for (and why it's not always that "good" )

I'll try to reproduce tomorrow but I fear it's rather the decode of this strange thing called DPT9 in the EibPC adding the .000000000000002 degrees;
the remainder (.75 vs .74) is probably simply due to the way IEEE-754 encoding works: it just looses some precision squelching a long number into 2 bytes..

But I'll double-check tomorrow, it wouldn't be the first bug in encoding simple things to constrained busses to save a byte or two on the wire

Makki