Today’s topic is measurements.
Abstract: We show why a well-defined binary datagram content is an advantage over a textual content for measurement data on a wire.
When you see
42
you see two Arabic numbers and probably guess it’s a number in the decimal system. So it’s 40 + 2. But if you are on the receiving end of a communication line what is 42 then? Does it mean anything to you?
Well it could be anything. If the sender sent this number 42, as a temperature you don’t know that it is a temperature on the receiving end without further information sent or it must be sent on a channel dedicated for just temperatures. Also you don’t know the unit without more information added. The temperature could be expressed in Kelvin, Fahrenheit or Celsius or even some of the other possible units that are used around the globe.
Still this is how most measurement values are sent. Sometime with adding information like
Temperature: 42 Kelvin
often all packed in XML or JSON envelopes and in text form. Alternatively you will find manifests by packed with the measurement data, big ones, with lots of information and options. Always in textual form.
All this is good and fine for higher end nodes. They have the memory to handle the conversions, the power to do the translations fast. No problem. But for sensor it gets a bit stupid. They are often cost sensitive devices and the processing power will therefore be lower and parsing and memory usage should be kept low. It’s just plain stupid to use high level structures on this level.
The VSCP solution
In VSCP, measurements, like everything else, is identified by a class and a type. There are a few different classes available that handle measurements, but let us look at the lowest end form here, made to make it easy for small devices to handle this kind of information in a resource efficient still safe way.
The measurement types in VSCP is fetched from the SI system. So all measurement type used in science and engineering is there and is so in a standardized form. Some examples
- Temperature: Class=10 Type=6
- Frequency: Class=10, Type=9
- Pressure: Class=10 Type = 12
you get the picture. You have them all specified here.
All measurements in the SI system have a default units. For temperature this unit is Kelvin. But people are used to use the more everyday common Fahrenheit and Celsius. This is true for all other measurements to, so in addition to the class and type to define which measurement is sent VSCP also send which unit this measurement is in. For the low-end devices, four well-defined unit types is available for each measurement type. For temperature unit = 0 is Kelvin (zero is always the SI unit), unit=1 is Celsius, unit=2 is Fahrenheit.
Last the format of the data is specified and some other information is also available which we will not go into here (full info is here).
The end result is a very compact measurement record that contain all relevant information. In this case 42 degrees Celsius is packed in seven bytes. Perfect for slow communication lines like RF.
The advantages of this format is
- Small packets with all needed information specified.
- Easy to handle by a low en device.
- Unit and type is always well specified.
- Value coding is always well specified.
- A unified format means uniform handling.
The uniform handling is interesting. This means that one solution can be used to, for example, draw diagrams for all types of measurements, same for statistical analysis or other analysis or just handling data. Well you get it. A big time and resource saver and no more stupid mistakes (making us miss Mars).
Sync
VSCP is not specially designed to be used in real-time systems. Still if we talk about milliseconds and 10th of microseconds it is usable.
For Level II events in VSCP, which have a timestamp in the package, this is no problem. Here we have microsecond resolution. But for low-end links the over head of a Level II event may be too much.
Level I events does not have a timestamp in the package. They are time stamped when they are received instead. This may not be enough in some situations.
Solution 1
The sync event (class=30, Type=26) is perfect if you want to synchronize measurements from several remote modules. Send the sync event on timed occasions and the nodes will respond in a synchronized fashion. You can timestamp them from the time you sent out the sync, optionally taking in to account the round trip time.
Solution 2
Instead of sync a node that send measurements can send a time event (Class=10, Type=4), using unit= 0 the timestamp can use millisecond resolution
OK that was all for today.