2

I am designing a custom GATT profile for a mobile robot base to connect to a tablet. Among other things, the base is reporting its position in x and y coordinates. The question is, how should I organize these two values in the GATT profile? Should they be contained in two individual characteristics or should I lump them together in one characteristic. E.g. (I left out UUID's for brevity):

<Service name="Odometry Service">
    <Characteristic name="Base Position" >
        <Value>
            <Field name="Position on the X axis">
                <Format>sint32</Format>
                <Unit>org.bluetooth.unit.length.metre</Unit>
                <Exponent>-3</Exponent>
            </Field>
            <Field name="Position on the Y axis">
                <Format>sint32</Format>
                <Unit>org.bluetooth.unit.length.metre</Unit>
                <Exponent>-3</Exponent>
            </Field>
        </Value>
    </Characteristic>
</Service>

or

<Service name="Odometry Service">
    <Characteristic name="Position on the X axis" >
        <Value>
            <Format>sint32</Format>
            <Unit>org.bluetooth.unit.length.metre</Unit>
            <Exponent>-3</Exponent>
        </Value>
    </Characteristic>
    <Characteristic name="Position on the Y axis" >
        <Value>
            <Format>sint32</Format>
            <Unit>org.bluetooth.unit.length.metre</Unit>
            <Exponent>-3</Exponent>
        </Value>
    </Characteristic>
</Service>

Obviously, technically, I can do both, and looking at the official Bluetooth adopted characteristics some characteristics lump the information together e.g. the Location and Speed characteristic used in the Location and Navigation service. Where the Indoor Positioning Service reports latitude and longitude in individual characteristics.

On one hand it makes sense to lump them together as the a change in position would likely change both values, and result in only one indication on the client side. On the other hand the client needs to do bit fiddling to get the values, which would be easily handled if they were individual characteristics.

I cannot seem to find a recommendation in the specification, and the adoption of both types seem to indicate that it is up to me? However, I may have missed a point somewhere.

Karl Hansen
  • 23
  • 1
  • 5

1 Answers1

1

TL/DR: Pack the values together

I've used sensors that report accelerometer in a single attribute and also ones that separated the axis into separate attributes. Neither is right or wrong, it all depends on your application.

However, when the values are separated you end up with some problems if you wish to use the axis values together. If you get a notification/indication that an axis has changed, you'll only get that value reported and have to assume the value of the other. If both axis have changed values, you'll get the two indications separately and it's a bit of a race condition.

Think about it like this:

You're currently X, Y value is (1,1) and then the value changes to (2,2). If you have the values packed together in a single attribute you'll get this:

  • current state: (1,1)
  • indication of change to (2,2)
  • updated state: (2,2)

If you have them separate you'll get this (as on possible situation):

  • current state: (1,1)
  • indication of change on X to 2
  • current state: (2,1)
  • indication of change on Y to 2
  • current state: (2,2)

The major question is, are you okay with having that intermediate state of (2,1) that probably isn't an actual state of the device? It's also just as likely to get a (1,2) state depending on which axis registered the change first.

Reading over your question again, I'm not really sure if either of your choices reflect what I'm saying in my case #1... What you want to do is have a single value reported that contains both X and Y values in a single binary and the listening end then has to unpack. I'm not familiar with the notation you're using so I'm not sure if that's what your first choice is doing or not.

Tim Tisdall
  • 9,914
  • 3
  • 52
  • 82
  • You illustrate the problem with separating them well. I would be putting the two together. Things that you typically use together and change together put together. Things that are independent separate. – Ifor Oct 06 '16 at 17:00
  • I struggled with a device that returned x,y,z values as separate values and couldn't alter that. I had a hack in place to wait half a second to try to wait for all indications to come in. It was VERY annoying and it's not obvious how bad a problem it is until you've painted yourself into that corner. – Tim Tisdall Oct 06 '16 at 18:03
  • Thank you @TimTisdall. Indeed, I am thinking of packing the values into a single binary. In this case two 16-bit integers into a 32-bit binary. – Karl Hansen Oct 13 '16 at 12:03
  • The XML notation used is the one used on Bluetooth.org to describe characteristics and services on GATT. – Karl Hansen Oct 13 '16 at 12:04