Thanks Brian,

Let me try to clarify ... 

> On Dec 1, 2016, at 3:02 PM, Brian Giori <briangi...@gmail.com 
> <mailto:briangi...@gmail.com>> wrote:
> 
> Hey, this sounds like a really cool project so just wanted to chime in. As
> a preface, I'm not sure if I completely understand what you're going for
> with this app so correct me if I'm wrong (I'm also a bit rusty).
> 
> Here are my suggestions:
> 
> Any MyNewt device that has "nimble" in its name will be seen as a valid
>> MyNewt device -- we can change this, but I based this off of the bleprph
>> tutorial code.
> 
> 
> If the new service will only ever run on mynewt then simply the existence
> of said service should be enough to 'validate' the device as being mynewt.

Rather than go through every Bluetooth device within range, connect to it, and 
see if it's offering the right service, I simply check the name of the device 
and, if it's not a mynewt device, move on. This is faster than connecting to 
each device. 


So in my office, I don't have to connect to -- or attempt to connect to -- each 
device. I can just look for the one named 'nimble-bleadc` and go there. 

> 
> 
>>   - Each sensor should publish 2 UUIDs as follows:
>> 
>> 
>>   - UUID 0x2Axx is considered a 'configuration UUID', should be
>>   readable, and should return a String containing the name of the sensor as
>>   you would like it to be displayed in the app
>> 
>> 
>>   - UUID 0x4Axx is considered a 'data UUID'  and should be subscribable
>>   and subsequently updated with the sensor readings associated with its
>>   0x2Axx config UUID
>> 
>> 
> In general, services should have fixed characteristics with fixed UUIDs. We
> should not be dynamically creating characteristics inside a service. This
> is because (at least in the case of Android) the mobile device caches the
> service and characteristic information, including the number of
> characteristics and all UUIDs so that it does not need to re-discover the
> service (noticeably slower than connecting to the cached service). For
> example, if my Android device first discovers the service with 1 sensor
> (i.e two characteristics), I will only ever see the service having two
> characteristics with the initial UUIDs even If I have added four more and
> changed the UUIDs for all characteristics.

The Characteristics are not dynamically created. In fact, they are immutable. 
/* Sensor Data */
/* e761d2af-1c15-4fa7-af80-b5729002b340 */
static const uint8_t gatt_svr_svc_sns_uuid[16] = {
    0x40, 0xb3, 0x20, 0x90, 0x72, 0xb5, 0x80, 0xaf,
    0xa7, 0x4f, 0x15, 0x1c, 0xaf, 0xd2, 0x61, 0xe7 };
#define ADC_SNS_TYPE          0xDEAD
#define ADC_SNS_STRING "eTape Water Level Sensor"
#define ADC_SNS_VAL               0xBEEF
#define SPI_SNS_TYPE          0xDE48
#define SPI_SNS_STRING "SPI Sensor"
#define SPI_SNS_VAL               0xBE48

The 0xDExx UUID will return the NAME of the sensor. 
The 0xBExx UUID will return values from the sensor.

This lets the app itself do the layout on-the-fly and have valid names.

See the attached image and movie showing the iOS app in action.

Note that the values returned are dummy values as I don't have ADC or SPI 
sensors actually working yet. 

> 
> Therefore, I suggest making a service with a single characteristic, either
> READ or NOTIFY, with a unique 128-bit UUID, that either stores (in the case
> of READ) or publishes (in the case of NOTIFY) a list of "sensor" structures
> which hold the sensor name and value. From there the mobile device can
> display the list accordingly.

I've made a single service, that holds multiple characteristics that are 
'paired' such that one is the name of the sensor, the other is the sensor 
values. The name is a READ characteristic, and the values are A NOTIFY 
characteristic.

I have a small screen-capture movie of what the above-defined 
service/characteristics look like in the iOS app, but I can't send it to the 
list. You can view it here: 
https://drive.google.com/open?id=0B9Hl75onlTTkMDR2UnZDZnhBU3M 
<https://drive.google.com/open?id=0B9Hl75onlTTkMDR2UnZDZnhBU3M> 

dg


> 
> Again take everything I just said with a grain of salt, I haven't used
> MyNewt in a number of months.
> 
> Finally, great idea for a project. This would be very useful for new
> developers as a tool and a reference point for other applications.
> 
> Brian Giori
> 
> 
> 
> On Thu, Dec 1, 2016 at 7:03 AM, David G. Simmons <santa...@mac.com 
> <mailto:santa...@mac.com>> wrote:
> 
>> Doh!!
>> 
>> Ok, so since actually complying with BLE standards is sort of important
>> :-) the UUID to use is E761D2AF-1C15-4FA7-AF80-B5729020B340 which is
>> unique, and is 128-bits.
>> 
>> That being said, it is also noted that defined characteristics are all
>> (save one) in the 0x2Axx range. So my choice there was bad too.
>> org.bluetooth.characteristic.fitness_machine_control_point defined as
>> 0xEE1D is the outlier there.
>> 
>> 128-bit UUIDs are a pain in the *** if you ask me. They are easy to
>> generate via the website Chris so generously provided. They are annoying to
>> translate into 16-byte arrays, but generating 128-bit UUIDs with a common
>> prefix/suffix is, as best I can tell, not possible. This all makes the iOS
>> app more complicated if not impossible without requiring users to generate
>> their own UUIDs, then go edit the iOS source files, build and deploy the
>> app to a device.
>> 
>> I see 2 possible solutions here:
>> 
>> 1) we flaunt standards, a bit, and use 16-bit characteristic IDs that are
>> NOT within the pre-defined characteristic ranges, say 0xDExx and 0xADxx as
>> our Config and data prefixes -- keep in mind that this is *only* for a demo
>> app and would not be used for any production application.
>> 2) We generate 2 128-bit UUIDs, say  559557e5-2ae2-4d4b-bda2-d432e8577be3
>> and d5e9608f-6e41-490f-88e2-4281c8ebe2c6, then clip off the start,
>> 559557e5- and d5e9608f- for config and data prefixes, and folks can
>> generate their own 128-bit UUIDs, then replace the prefixes.
>> 
>> 1 seems a lot more straight-forward and easier to explain to people who
>> are trying to work through the tutorials. 2 would have a lower chance of a
>> UUID collision, though even with 1, the collision chances are nearly
>> non-existent.
>> 
>> Happy to take suggestions here.
>> 
>> dg
>> 
>>> On Nov 30, 2016, at 1:03 PM, Christopher Collins <ccoll...@apache.org 
>>> <mailto:ccoll...@apache.org>>
>> wrote:
>>> 
>>> That sounds great!  My only comment is that the app probably shouldn't
>>> use those 16-bit UUIDs.  There is a registry of standardized bluetooth
>>> service UUIDs (https://www.bluetooth.com/specifications/gatt/services 
>>> <https://www.bluetooth.com/specifications/gatt/services> <
>> https://www.bluetooth.com/specifications/gatt/services 
>> <https://www.bluetooth.com/specifications/gatt/services>>),
>>> and 0x1811 is reserved for the Alert Notification Service.
>>> 
>>> For non-standard services and characteristics, you will need to use
>>> 128-bit UUIDs.  You can generate unique 128-bit UUIDs using a site like
>>> this one: https://www.uuidgenerator.net/ <https://www.uuidgenerator.net/> 
>>> <https://www.uuidgenerator.net/ <https://www.uuidgenerator.net/>
>>> .
>> 
>> --
>> David G. Simmons
>> (919) 534-5099
>> Web <https://davidgs.com/ <https://davidgs.com/>> • Blog 
>> <https://davidgs.com/davidgs_blog <https://davidgs.com/davidgs_blog>> •
>> Linkedin <http://linkedin.com/in/davidgsimmons 
>> <http://linkedin.com/in/davidgsimmons>> • Twitter <
>> http://twitter.com/TechEvangelist1 <http://twitter.com/TechEvangelist1>> • 
>> GitHub <http://github.com/davidgs <http://github.com/davidgs>>
>> /** Message digitally signed for security and authenticity.
>> * If you cannot read the PGP.sig attachment, please go to
>> * http://www.gnupg.com/ <http://www.gnupg.com/> <http://www.gnupg.com/ 
>> <http://www.gnupg.com/>> Secure your email!!!
>> * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/> 
>> <http://keyserver.pgp.com/ <http://keyserver.pgp.com/>>
>> **/
>> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
>> 
>> There are only 2 hard things in computer science: Cache invalidation,
>> naming things, and off-by-one errors.
>> 
>> 
>> 

--
David G. Simmons
(919) 534-5099
Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> • Linkedin 
<http://linkedin.com/in/davidgsimmons> • Twitter 
<http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs>
/** Message digitally signed for security and authenticity.  
* If you cannot read the PGP.sig attachment, please go to 
 * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!!
 * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/>
**/
♺ This email uses 100% recycled electrons. Don't blow it by printing!

There are only 2 hard things in computer science: Cache invalidation, naming 
things, and off-by-one errors.

> On Dec 1, 2016, at 3:02 PM, Brian Giori <briangi...@gmail.com> wrote:
> 
> Hey, this sounds like a really cool project so just wanted to chime in. As
> a preface, I'm not sure if I completely understand what you're going for
> with this app so correct me if I'm wrong (I'm also a bit rusty).
> 
> Here are my suggestions:
> 
> Any MyNewt device that has "nimble" in its name will be seen as a valid
>> MyNewt device -- we can change this, but I based this off of the bleprph
>> tutorial code.
> 
> 
> If the new service will only ever run on mynewt then simply the existence
> of said service should be enough to 'validate' the device as being mynewt.
> 
> 
>>   - Each sensor should publish 2 UUIDs as follows:
>> 
>> 
>>   - UUID 0x2Axx is considered a 'configuration UUID', should be
>>   readable, and should return a String containing the name of the sensor as
>>   you would like it to be displayed in the app
>> 
>> 
>>   - UUID 0x4Axx is considered a 'data UUID'  and should be subscribable
>>   and subsequently updated with the sensor readings associated with its
>>   0x2Axx config UUID
>> 
>> 
> In general, services should have fixed characteristics with fixed UUIDs. We
> should not be dynamically creating characteristics inside a service. This
> is because (at least in the case of Android) the mobile device caches the
> service and characteristic information, including the number of
> characteristics and all UUIDs so that it does not need to re-discover the
> service (noticeably slower than connecting to the cached service). For
> example, if my Android device first discovers the service with 1 sensor
> (i.e two characteristics), I will only ever see the service having two
> characteristics with the initial UUIDs even If I have added four more and
> changed the UUIDs for all characteristics.
> 
> Therefore, I suggest making a service with a single characteristic, either
> READ or NOTIFY, with a unique 128-bit UUID, that either stores (in the case
> of READ) or publishes (in the case of NOTIFY) a list of "sensor" structures
> which hold the sensor name and value. From there the mobile device can
> display the list accordingly.
> 
> Again take everything I just said with a grain of salt, I haven't used
> MyNewt in a number of months.
> 
> Finally, great idea for a project. This would be very useful for new
> developers as a tool and a reference point for other applications.
> 
> Brian Giori
> 
> 
> 
> On Thu, Dec 1, 2016 at 7:03 AM, David G. Simmons <santa...@mac.com> wrote:
> 
>> Doh!!
>> 
>> Ok, so since actually complying with BLE standards is sort of important
>> :-) the UUID to use is E761D2AF-1C15-4FA7-AF80-B5729020B340 which is
>> unique, and is 128-bits.
>> 
>> That being said, it is also noted that defined characteristics are all
>> (save one) in the 0x2Axx range. So my choice there was bad too.
>> org.bluetooth.characteristic.fitness_machine_control_point defined as
>> 0xEE1D is the outlier there.
>> 
>> 128-bit UUIDs are a pain in the *** if you ask me. They are easy to
>> generate via the website Chris so generously provided. They are annoying to
>> translate into 16-byte arrays, but generating 128-bit UUIDs with a common
>> prefix/suffix is, as best I can tell, not possible. This all makes the iOS
>> app more complicated if not impossible without requiring users to generate
>> their own UUIDs, then go edit the iOS source files, build and deploy the
>> app to a device.
>> 
>> I see 2 possible solutions here:
>> 
>> 1) we flaunt standards, a bit, and use 16-bit characteristic IDs that are
>> NOT within the pre-defined characteristic ranges, say 0xDExx and 0xADxx as
>> our Config and data prefixes -- keep in mind that this is *only* for a demo
>> app and would not be used for any production application.
>> 2) We generate 2 128-bit UUIDs, say  559557e5-2ae2-4d4b-bda2-d432e8577be3
>> and d5e9608f-6e41-490f-88e2-4281c8ebe2c6, then clip off the start,
>> 559557e5- and d5e9608f- for config and data prefixes, and folks can
>> generate their own 128-bit UUIDs, then replace the prefixes.
>> 
>> 1 seems a lot more straight-forward and easier to explain to people who
>> are trying to work through the tutorials. 2 would have a lower chance of a
>> UUID collision, though even with 1, the collision chances are nearly
>> non-existent.
>> 
>> Happy to take suggestions here.
>> 
>> dg
>> 
>>> On Nov 30, 2016, at 1:03 PM, Christopher Collins <ccoll...@apache.org>
>> wrote:
>>> 
>>> That sounds great!  My only comment is that the app probably shouldn't
>>> use those 16-bit UUIDs.  There is a registry of standardized bluetooth
>>> service UUIDs (https://www.bluetooth.com/specifications/gatt/services <
>> https://www.bluetooth.com/specifications/gatt/services>),
>>> and 0x1811 is reserved for the Alert Notification Service.
>>> 
>>> For non-standard services and characteristics, you will need to use
>>> 128-bit UUIDs.  You can generate unique 128-bit UUIDs using a site like
>>> this one: https://www.uuidgenerator.net/ <https://www.uuidgenerator.net/
>>> .
>> 
>> --
>> David G. Simmons
>> (919) 534-5099
>> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> •
>> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <
>> http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs>
>> /** Message digitally signed for security and authenticity.
>> * If you cannot read the PGP.sig attachment, please go to
>> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!!
>> * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/>
>> **/
>> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
>> 
>> There are only 2 hard things in computer science: Cache invalidation,
>> naming things, and off-by-one errors.
>> 
>> 
>> 

--
David G. Simmons
(919) 534-5099
Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> • Linkedin 
<http://linkedin.com/in/davidgsimmons> • Twitter 
<http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs>
/** Message digitally signed for security and authenticity.  
* If you cannot read the PGP.sig attachment, please go to 
 * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!!
 * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/>
**/
♺ This email uses 100% recycled electrons. Don't blow it by printing!

There are only 2 hard things in computer science: Cache invalidation, naming 
things, and off-by-one errors.


Reply via email to