BLE Central Mode


#6

Hm. Given that, I’d like to ask two questions. I’ll do two replies to hopefully keep things clean.

Second: Given my existing BLE-skewed mindset and absorbing that y’all are seeing Bluetooth as primarily (only?) a setup and diagnostic tool can you point me at a use case of how you see the new parts being used to gather and flow data? As in, data comes in via the pins (uart, AtD, digital, etc) on the Xenon, flows through the mesh, Boron / Argon uplinks? Or something else.
Y’all are super sharp so I know you’ve designed around some use-case ideas. It’d be useful to me at least to have more insight to those.

Thanks!


#7

In the fullness of time, we’d like to add API support for Bluetooth. However, we will be focusing our efforts for the initial release on the primary use case of device setup and diagnostics over Bluetooth. We have other ideas on how we can leverage Bluetooth that will also not be included at launch.

When I think of use cases that I’d like us to support in time, advertising/COTS sensors is something I’d include on the ever-growing list. Would it be possible for us to study these sensors? Any documentation you can share will help us evaluate if/when we can support them.


#8

How [do we] see the new parts being used to gather and flow data? As in, data comes in via the pins (uart, AtD, digital, etc) on the Xenon, flows through the mesh, Boron / Argon uplinks?

Yup, that’s the main way. Note that Argons and Boron share the same peripherals, so they can also connect the same sensors and gather data.


#9

My day job is software engineering support at JSC. Several of the sensors we use are readily available:

Ruuvi tags are wonderful devices and the team producing them is extremely helpful to the user base. I have mine broadcasting temp, pressure, humidity, xyz acceleration, and battery voltage at 1/2 Hz. To be clear, all data is carried in the manufacturer data of the advertising packet. The range is phenomenal for BT and at the rate they’re running we’ll need to change a battery about once every three years. I’m monitoring about a dozen now that have been running for months. In the next two weeks we’ll deploy 25 more, using a RPi3 as the gateway. We’re using them in two places. One is to protect expensive projectors in the SES from extreme temps and humidity that’s out of range. The others will be in some of the curation labs as a pressure monitoring trial.

JSC’s WEAR lab has adopted Bluetooth as a transmission mechanism of choice. Here, Bluetooth HRM’s (your pick from what’s out there) are a sensor we monitor; tested already underwater at NEEMO. In addition, kits have been supplied to universities to enable Bluetooth data return. Their choice whether it’s in advertising packets or characteristics. One key is we don’t require pairing; the goal is to save on crew time. If data’s exposed via a characteristic we connect, read, and disconnect without the pairing step. Access control is handled via a list of valid MAC addresses.

Trivally, we’ve used Estimote stickers and beacons to track the location of equipment. This is simply listening for advertising packets to see which gateway can hear a particular beacon.

Personally I’ve got an application for using beaconing sensors to be sure livestock doesn’t get too hot. Think Ruuvi tags as the sensor here.

In the ground-based implementation of the environmental sensors the cellular back-haul is preferable; keeps us off networks that have onerous security restrictions. Should we fly a gateway to the ISS, wifi or more likely wired would be the back-haul of choice.

Hope this helps - I’d be happy to answer any follow-ons.


#10

Y’know - In order:

  1. by far - allow scanning for the data in advertising packets
  2. allow reading of data from characteristics

Just in case that’s helpful.


#11

It is, thank you!


#12

I’m sorry if this has been asked previously.

Can I just flash these as nRF52840 Preview DK units?

Thanks


BLE services for Argon/Xenon class devices
#13

Jonathan, sounds like the new devices will be able to communicate with a Particle BluzDK.
Will the Argon be not able to act as a gateway for the BluzDK… eventually?
I currently use BluzDKs as I may use Xenons in the future; as sensor nodes. The Bluz Gateway works great for now (up to 5 BluzDKs), but I was hoping to evolve my implementations by replacing it with Argons.
I read the FAQ that says “Nothing!” is happening with the Photon/Electron (BTW: I am crushed you did not mention the BluzDK), but I am starting to think “nothing” is a red flag (ok, maybe yellow).
I am trying to figure out if I am stuck holding a bag of fading Photons and Bluz modules or there are plans to breath new life into the previous generation.

I am enthusiastic about the new products and Particle’s efforts to integrate offerings from Adafruit. Great team work!

Thanks,
Pescatore

EDIT: …sounds like the new devices will NOT be able to communicate…


#14

As the creator of bluz, I can provide some answers here.

We are also evaluating the new hardware and what it means to bluz. The primary focus of these boards at their launch will not necessarily include generalized BLE support, which would mean they could not operate as a gateway solution for bluz until that is available. However, they do run the Nordic chipset (same as bluz) and can act as a gateway from a hardware perspective, so we would expect to be able to use them as gateways for bluz at some point. As we have expertise in supporting the Nordic stack and BLE in general, it is possible we could even accelerate the BLE features on this new hardware. These are all things we are currently looking into.

I can say that we absolutely do not plan to leave our customers without a plan forward. Our hardware and firmware are still fully functional today, and you can expect they will still be functional years from now, so the hardware will continue to be supported. While this new hardware is certainly exciting (I placed my pre-order within the first hour!), it also won’t be available for months, so things will continue to operate normally for bluz. As we figure out how this new hardware fits our story over the coming months, we will be sure to keep everyone in the loop.


#15

Thanks, Bluz Team, that sounds like good news for us guys who would really like to see the full potential of the BLE 5.0 tech available for use on the new boards when they eventually are ready.

From what I have read so far the BLE 5 or BLE, in general, has a much lower power requirement compared to the 802.11 Mesh protocol. It would be nice to pass data between the new devices using the Low Power BLE 5 with it’s new lower bitrate longer range functions if you guys tackle that :slight_smile:

Please do keep us in the loop if you start working on this.


#16

Like MikeWhitten, we see central mode as critical. We’re using redbear duo’s to do this today in the healthcare space, where we use COTs beacons (Ruuvi and Estimote) as wearable devices. I see lot of applications for this model in healthcare, manufacturing, building automation, and beyond.

If you assume the end device is another particle mesh device, that could be a big limiter. These beacons have made big jumps in battery life (years) and range (100’s of meters), which makes them really useful and an awesome extension to particle connectivity.

Also, I think you acquired RedBear since your mesh announcement? It would be nice to see RedBear (or its functionality) included in the new release. Out of curiosity, has this changed anything?

We love what you are doing! Keep up the awesome work.


#17

+1 on the BLE central mode

We have a wide deployment of custom BLE sensors deployed in the field. We’ve looked at using Particle in the past to connect these to the cloud, but the lack of BLE support has been a deal-killer.

With this new mesh generation we really hope that Particle will implement the ability to collect advertised data and connections to BLE peripherals as noted in this thread. That would be hugely attractive!

-AD


#18

I stopped using Particle (Redbear duo) because (lack) of this. I am part of the second mfg run because of this. Please, please ! Give us BLE central !

/Claudio


#19

Hello @jberi , in light of what was announced last night on the Bluz forum, is there more you can tell us about the plans for BLE for the new generation?


#20

+2 On including common BLE functionality.


#21

+3 and I am sure many more on standard BLE functionality.


#22

Like the others I am keen to use BLE on Xenon’s in particular. Indeed I ordered a number before I became aware that BLE would not be available on the initial firmware.

On the other hand I appreciate that Particle focussed on getting the initial firmware solid.

Is there any planned schedule available for the introduction of BLE in the firmware? (I need to decide whether to add an additional board with BLE or possibly move to an alternative processor family entirely).


Particle Mesh - Bluetooth
Boron + 5-Xenon Setup Questions
#23

Hey folks – Bluetooth APIs for Mesh are on our radar and will be one of the first new features added to the Device OS beyond stability improvements to the existing Particle Mesh functionality. Learning from the preorder process, it’s too early in the design and execution process for us to commit to a timeline.

Specifically for RedBear, we have committed to the following:

  • Sales of RedBear hardware through the end of Q1 2019 (with a last buy on 3/29/19)
  • Support of RedBear hardware through the end of Q3 2019

Our intention is to create a transition path for RedBear customers, which relies on the Argon and the Xenon to provide equivalent functionality to the Duo and Nano. Obviously, that is not possible without support for Bluetooth APIs, which hopefully gives you a sense of our intended timeline for shipping these features to the community.


Required to always have a Boron or Argon?
#24

I concur with the desire for full bluetooth support with Mesh. You might consider a phased approach starting with the ability to rx advertisements and customize tx advertisements followed by support for characteristics.


#25

Beauty of open source is for you to tinker without waiting.

There’s a WIP branch: