Measurement Additional Units for Weather Stations

As part of the process of interfacing a weather station into the C-Bus measurement application, I have come across a few unit types I would like to add.

These are;

For Speed

• Kph
• Mph
• Knots

For Distance

• mm
• Inches

I realise these are all readily convertible from the base units of "Metres/Second" and "Meters" however this requires the end display unit to know the intended final units.

Given the units information is carried as part of the message payload, it makes sense to be able to set them at the encoding end.

So, I have noticed that the protocol lists one units value $FF as user defined but as you can see I would like more.
Can I use any of the values between $28 and $FD that are currently unoccupied?
If so I would think working backwards from $FD would be better to avoid any factory additions coming the other way.

Cheers

Rohan

 

I've also recently noticed there are 2 additional units listed in the C-Bus diagnostics utility that are not in the protocol documents.
Namely;

$/Unit
$/Hour

Are these official units?

Regards

Rohan

 

Hmm..... that may have been the intent, but that's not how it has panned out.

If the sending format is supposed to be neutral, why does it include units at all?

This assumes the display end has the intelligence to calculate and the user controls to select the option. I'm not sure all C-Bus devices can do that (happy to be corrected).

Yep, that's what we have now. The Measurement specification does not only contain base units. There are several types with multiple units.
e.g.
For Flow Rate there is;

• Litres per Hour
• Litres per Minute
• Litres per Second

For Elapsed Time there is;

• Seconds
• Minutes
• Hours

For Speed there is;

• Metres per Second
• Metres per Minute

At some point someone has decided that calculating them at the display end is not possible (or too much effort) and encoded the units at the send end.

I think this is a case of could be either way. I would argue that the sender is the absolute authority on what is contained in the message and therefore should set the end units. It also means the display end can be reasonably dumb.

However I acknowledge that the reverse can be equally as true (especially with culture based metric/imperial units).

The problem here is it's not consistent either way, and there appears to be no official guidelines for third party encoding and display. I actually suspect that very few (if any) third parties have ever built a system for sending measurement information, and the current list of units is a mix of "ideas at the time" and a couple of requested extras ($/Unit, $/Hour).

I understand that just adding unit types as requested by the "great unwashed" potentially has no end to it, and could result in a bit of duplication and mess, but as it stands now there are 212 spare slots, so it really is not likely to become an issue any time soon.

BTW "Sieverts", surely that was added after a Friday long lunch....

So perhaps a compromise would be to open up the custom range to allow product specific units?

Anyway as usual, thanks for your help and comments Ashleigh, especially with the maths lesson the other day. I know it's not your domain any more to green light changes, but hopefully one of the official guys can comment as well.

Cheers

Rohan