Will the BLE modules in the new generation of hardware support central mode? I’m particularly interested in scanning and logging data received from nearly BLE peripherals.
4 Likes
We generally try to be thoughtful about which features we add to our Device OS because more features means more flash and RAM used by the system and less resources available to your application. Since the primary role of Bluetooth in Particle Mesh is for device setup and diagnostics, we don’t plan to support generalized and broad Bluetooth functionality when we ship. Do you have a specific use case you can share? We’re always listening and take input to heart. It may be possible that what we’re planning to have at ship overlaps with your logging use case, while not requiring the full peripheral implementation.
1 Like
I’m trying to track the movement of BLE devices along a path lined with mesh endpoints. Ideally, at regular intervals, I’d scan for nearby peripherals and record their device ids.
Would these devices be Argons or some other device (maybe that you designed?) If they’re argons and not knowing the level of accuracy your application needs, you should be able to use the 802.15.4 radio’s RSSI for rudimentary trilateration. Anything different and can’t really guarantee that it will be possible at launch.
Hm. Given that, I'd like to ask two questions. I'll do two replies to hopefully keep things clean.
First: My top-of-mind use case for the Argon and Boron is to gather, process, and send on data from existing BLE sensors that are sending said data in their advertising packets. These sensors already exist in the world. They measure parameters of interest (temperature, pressure, humidity, VoC's, airborne particle counts, presence, acceleration for vibration detection) and advertise the data to all listeners. Some sensors are COTS, some are custom. The gateway needs to be quick at gathering, filtering, and transmitting these packets and data.
In this case Bluetooth is the primary data transmission and collection mechanism. Edit: Bluetooth is primary from sensors to gateway; cellular or wifi is then used to rest of world. Just for clarity.
Do you foresee Argon and Boron being able to support this use case?
4 Likes
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!
2 Likes
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.
3 Likes
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.
1 Like
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.
4 Likes
Y’know - In order:
- by far - allow scanning for the data in advertising packets
- allow reading of data from characteristics
Just in case that’s helpful.
4 Likes
It is, thank you!
1 Like
I’m sorry if this has been asked previously.
Can I just flash these as nRF52840 Preview DK units?
Thanks
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…
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.
8 Likes
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 
Please do keep us in the loop if you start working on this.
3 Likes
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.
4 Likes
+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
6 Likes
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
2 Likes
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?
+2 On including common BLE functionality.