Subject: [core] Draft: Data representation

From: Markus Becker <[email-masked]>
Date: Wed, 16 Feb 2011 12:22:33 +0100

Hello,

while working on transmitting real sensor data with CoAP, we are dealing with 
a data representation issue. We have to options:

1) Calculate the real room temperature from the buffer value. This involves 
multiplication and division, e.g. for SHT11 sensor Tc = -39.6 + 0.01 * BUF = 
(BUF - 3960)/100. For humidity this might be more complex and involving 
floating point calculations, which increases code size considerably (~3kB). On 
the good side, we would have device independent data representation.

2) Transmit the ADC buffer value from the temperature sensor as is. For 
different types of sensor hardware we would transmit different values for the 
same room temperature. Therefore a description of the data representation 
needs to be known for the device. Are there data representation descriptions 
formats available? Would those be referenced by 'd=...' in the link-format?

What option are others currently pursueing?

Best regards,
Markus

------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| Mobile Research Center
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: [email-masked]
| building: NW1 room: N2260
------------------------------------------------

---

From: "Stok, Peter van der" <[email-masked]>
Date: Wed, 16 Feb 2011 14:07:25 +0100

Hi Markus,

If I understand you correctly, you want to represent your data according to a format that exists already.
There are several standards which look at data representation, that you might use;
BACnet, ZigBee, IEEE 1451, ACN, oBIX, etc., etc.
IEEE 1451 is the most elaborate one. The others are more application oriented.

Greetings,

peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Markus Becker
Sent: Wednesday 16 February 2011 12:23
To: [email-masked]
Subject: [core] Draft: Data representation

Hello,

Best regards,
Markus

------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| Mobile Research Center
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: [email-masked]
| building: NW1 room: N2260
------------------------------------------------
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Markus Becker <[email-masked]>
Date: Wed, 16 Feb 2011 15:19:40 +0100

> a format that exists already.

Preferably yes. Additionally the question is _where_ to get the data into that 
format. On the constrained node or somewhere in the non-constrained network.

> There are several standards which look at
> data representation, that you might use; BACnet, ZigBee, IEEE 1451, ACN,
> oBIX, etc., etc.

Assuming the IEEE1541 ConRes datatype would be chosen as the datatype of CoAP 
data for a temperature resource. How can the ADC value of an SHT11 be 
efficiently (without floating point operations) be translated into that 
representation? And how would this representation be referenced in the link-
format?

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Markus Becker Sent: Wednesday 16 February 2011 12:23
> To: [email-masked]
> while working on transmitting real sensor data with CoAP, we are dealing
> with a data representation issue. We have to options:
> 
> multiplication and division, e.g. for SHT11 sensor Tc = -39.6 + 0.01 * BUF
> = (BUF - 3960)/100. For humidity this might be more complex and involving
> floating point calculations, which increases code size considerably
> (~3kB). On the good side, we would have device independent data
> representation.
> 
> different types of sensor hardware we would transmit different values for
> the same room temperature. Therefore a description of the data
> representation needs to be known for the device. Are there data
> representation descriptions formats available? Would those be referenced
> by 'd=...' in the link-format?
> 
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby
> notified that any use, forwarding, dissemination, or reproduction of this
> message is strictly prohibited and may be unlawful. If you are not the
> intended recipient, please contact the sender by return e-mail and destroy
> all copies of the original message.
| telephone: +49 421 218 62379

---

From: "Stok, Peter van der" <[email-masked]>
Date: Wed, 16 Feb 2011 16:42:19 +0100

Markus,

A possibly unsatisfactory reply:
Choosing the location to put the data in a given format is a design decision which depends on application and hardware budget.
Clearly when you do a lot of statistics first and send the result over sporadically, conversions need to be done at the source (the constrained device).
When you have completely homogeneous hardware at many different sources with a low production rate, then the raw 16 bit ADC value may be the best option to transport, because the hardware is cheap and you have lots of them.

So I am sorry, the _where_ cannot be recommended in a general fashion.

Concerning integer calculations:
There is quite some literature for integer calculation with floating point results in assembler languages or C. Usually this gets solved, may be some one can refer you to an existing library. For example we did this in an ad-hoc fashion for our clock synchronization when implementing a kalman filter.

The representation of the format in the link-format is much more interesting. In principle I do not think that representation formats are the responsibility of Core. However, the coap protocol should help you to indicate which standard you use. This is the subject of the building control draft.

Hope this helps,

peter