ThunderNerd
More dregs from a badly-wired brain.

Return to Home
 
 
Degrees Milsius

Milcius
A proposed temperature scale where the range 0 to 100° C is divided into 1000 units.
This allows an integer resolution of 1/10 of a degree Celsius.

Etymology
A back formation from Mille (1000) and Celsius.

Usage
To convert Celsius to Milsius, multiply by 10. To convert Milsius to Celsius, divide by 10.


Front view
Click thumbnail for larger image.
Background
America is moving away from Fahrenheit and adopting Celsius as the preferred temperature unit. This is fine, and Celsius is a much more sensible scale, but the hidden penalty of the change is to throw away half the resolution.

The standard temperature for scientific observation is 68°F or 20° C.
Look what happens when we go up 1° to 69° F - the equivalent is now 20.5° C. (Rounded to half a degree C.)

In order to convey even the same level of accuracy in degrees Celsius we must use decimal places.

We now have many temperature sensors with sub-degree accuracy but are using a scale developed in the early part of 18th century. Back then high technology was a scratchmark on a handmade mercury glass thermometer, so 100 units between freezing and boiling was plenty.


That's right: As we stumble technologically-burdened into the 21st century we are swapping over to a temperature scale developed in 17-bonk that offers half the resolution of our previous scale. This is going in the wrong direction.

In itself, the use of decimal places to express a temperature value is not normally a problem.
There is one area of modern technology where decimal places are impractical, undesirable and in some cases impossible, and that is in tiny embedded micro computers. The use of decimal places on small microprocessors or microcontrollers requires either floating-point arithmetic or additional code.

The simple method of working in a ten times larger scale and then dividing by ten is obvious to any programmer and difficult for me to claim originality. As I've been doing this for years anyway, I'm going to skip the decimal place tweak code and start outputting using degrees Milsius.

In the example above, 69° F or 20.5° C becomes 205° M. This offers ten times the resolution without decimal places and moves the
effective range into more ergonomic and user-friendly territory.

The Downside
The increased resolution requires more digits for the same range. The good news is that most of the normal range is useless for everyday measurements. A temperature range of 0 to
255° M (0 to 25.5° C or 0 to 78° F) is suitable for many industrial processes and indoor environments requires only 8 bits to provide a resolution of a tenth of a degree. Compare this to the 0 to 255° C range using 8 bits in Celsius.

More bits (10 or 16) are typically used for sub-integer
Celsius so there is no penalty for the same accuracy.
A temperature range (freezing to boiling) of 0 to 1000° M (0 to 100° C; actual range 1024° M or 102.4° C) requires 10 bits.

Negative Values
There is no conventional way of expressing negative temperatures using positive integers without using
degrees Kelvin. Once again, great for low-temperature physics but large parts of the range are useless for everyday measurements. When was the last time you measured a temperature below 250° K?

One solution might be to move the offset just a tad - say, a nice round
100° C (so 0° C is now 1000° M).
The offset change can be indicated in the unit as a minus M. The minus sign could use the non-break character space.

In that case 0°-M is the same as -100° C, (just a lot easier to code.)
Moving the offset down by 100
° C results in useful ranges:
12 bits covers normal meteorological temperatures: 0 to 4096°-M (-100° C to 31° C).
In most cases over 8 bits it's common to use a 16 bit word.
The full 16 bits gives us: 0 to 65536°-M (-100° C to 555.4° C).

In the example above, 69° F or 20.5° C becomes 205° M or 1205°-M.
A negative example: -20.5° C (-4.9° F) becomes 795°-M

Comments, compliments, complements and hatemail to: milsius@thundernerd.com.


Ken Thornton-Smith, 7/1/2010