I didn't want to self promote here, but I am anyways :)
We developed a Plug and Play modular sensor Architecture. you can check out
the kickstarter for it here
https://www.kickstarter.com/projects/pureengineering/puremodules-for-dreamers-tinkerers-hackers-and-des
also more info here: https://hackaday.io/project/12808-pure-modules  and
http://www.puremodules.com/

I think you might be interested in the super sensor module as it has 7
sensor chips on it.
I'm planning on working with the mynewt sensor API when I get some more
free time after the kickstarter is over and when I get some more time to
add the nrf52 core support mynewt bsp, although it doesn't seem that
critical as the code compiled for the nrf52dk bsp works fine on it. If
anyone wants a pre-release nrf52 core module to add bsp support send me an
email directly.

Also if you check out the BLE GATT characteristics, they almost have every
sensor type covered.
https://www.bluetooth.com/specifications/gatt/characteristics it would be
worth checking out if your sensor is already covered.



On Thu, Dec 1, 2016 at 4:49 PM, Brian Giori <briangi...@gmail.com> wrote:

> Ah ok, I thought you were going for some kind of self contained 'Mynewt
> Sensor Service' which would be pretty cool in its own right but for demo
> purposes what you have is all you need.
>
> Brian
>
> On Thu, Dec 1, 2016 at 2:12 PM, David G. Simmons <santa...@mac.com> wrote:
>
> >
> > > On Dec 1, 2016, at 4:00 PM, Kevin Townsend <ke...@adafruit.com> wrote:
> > >
> > > On 01/12/16 21:35, David G. Simmons wrote:
> > >
> > >>
> > >> 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.
> > >>
> > > Normally you would include a specific service UUID in the advertising
> > packet to solve this problem, and when you collect the advertising data
> you
> > can determine if the service you care about is present, which might be
> less
> > arbitrary than relying on a device name? 128-bit UUIDs do cause a
> problem,
> > but you can still fit one in the main adv. packet, or you can optionally
> > use the scan response for a second payload.
> > >
> > > Just a suggestion about a fairly standard way to solve this problem
> > without having to connect to every device in range. :)
> >
> > True, that is the 'normal' way, but it turns out that almost no one
> > actually does it in practice. At least, looking through the devices in my
> > environment, not a single one advertises any services as part of its
> > advertisement data.
> >
> > I think that, this being a demo app, and not being a real production app,
> > I'm inclined to leave it as is and just check the name for now. Unless
> > there are strenuous objections.
> >
> > I'm much more interested in spending time getting sensors attached to
> > MyNewt than working on the iOS app. So, if anyone has any words of wisdom
> > on *that* front, I'm all ears!
> >
> > dg
> > --
> > 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.
> >
> >
> >
>



-- 
Sashi Ono
Principal Embedded Systems Engineer
(805) 699-6690
www.pureengineering.com

Reply via email to