2019 priorities for 3rd Gen hardware stability

@dougal, this functionality is exactly what is being planned for the High Availability (higher cost tier) mesh networks.

So you’ll be able to specify “primary” and “secondary” gateways? I had the impression that the mesh would just always use the “best available” gateway, based on nearest path. If you can somehow configure (or if it’s just automatic) that WiFi should always be primary and only use Cellular when no WiFi gateways are available, that will be better than what I was expecting.

@dougal, how Particle implements HA is still not defined. The “best available” may be based on “cost of route” or pre-defined fallback order. In a true HA mesh, you may have primary and secondary gateways in different segments of a large mesh (eg. “at both ends”). There are many possibilities which Particle needs to explore.

3 Likes

I like @peekay123’s list + HA capability as already discussed.

If I pick up one item, it’s stability – the mesh stability of course, and the cloud connection stability also. I think the cloud integration is a major differentiator of Particle Mesh, but I am disappointed and frustrated when the device seems disconnected from the cloud so often (i.e. Particle.publish/Ping/Diagnostic/OTA etc. do not go through) although I am sure the device is sending the events over the local mesh network (by Mesh.publish) perfectly fine.

  • General reliability
  • Mesh networks
  • WiFi connectivity
  • cloud monitoring of devices
  • NFC API

Thanks for asking.

Thanks all for taking the time to share this feedback. It all aligns pretty well with our expectations. For those counting at home, here's the feedback tally (below).

We've already begun preliminary work on the first two (BLE APIs and Sleep modes) and will begin discussion of the features below internally.

BLE API ++++++++++++
Sleep modes +++++++++
Device recovery (HW watchdog) +++++
NFC API ++++
Topology mapper ++++
User access to external flash +++
HW debugging in workbench +++
High availability networks +++
Mesh management API +
One free HA network +
Stable threading
Sleepy end devices
"Efficient" mesh OTA (download once, distribute locally)
Boron Cellular API completeness
Cellular data metering in dashboard
Update CLI to support Mesh
Gateway can join mesh as an end device
Easier switching of Wi-Fi / mesh networks
XIP for external flash

9 Likes

I definitely agree with that! It would be really nice to be able to have both an Argon and a Boron gateway on a single network (without the steep price tag).

1 Like

Great stuff.

I think folk know I’m keen on BLE, specifically:

Bluetooth characteristics

  • Private UUID characteristics r/w/notify

Transparent UART

  • Straight write mode like serial print so folk can roll their own if they so desire
  • Particle publish via BLE
  • Particle function via BLE

The latter two need some careful consideration as to how its handled, a command string, string delimiter etc etc. Folk should be able to follow the spec with some examples in nodejs and arduino to implement on their end. I say nodejs because a lot of hybrid apps are running angular and running a simple command line nodejs script is pretty straight forward and easily ported to their mobile framework of choice (ie Ionic).

Thinking aloud, it could even be possible that BLE function calls are made via a write to a characteristic and BLE publishes are via another characteristic with notify on. That would make life pretty easy.

As an aside, what mongoose os do with their RPC approach is pretty cool.

2 Likes

Just got my particle. +1 more for NFC!

+1 to the XIP - more program space would be great

Sleep modes +1

  • Bluetooth mesh (High priority)
  • BLE API (High priority)
  • Sleep modes (very important)
  • Sleepy end devices (very important)
  • Device recovery (HW watchdog)
  • 2MB flash memory access
  • NFC API
  • Topology mapper

Is there any plan for Bluetooth mesh ?

@developer_bt, Particle is implementing mesh using Thread on 802.15.4 and not on Bluetooth. I don’t believe there is any plan to support BLE mesh.

2 Likes

Hi @peekay123 Thank you for the information. I know that, Particle mesh is implemented with using Thread but is there any plan for Bluetooth mesh? Or new Bluetooth support will be only for BLE?

@developer_bt, I am not aware of any plans to implement BLE mesh on particle devices.

I'm not sure what you mean by this. BLE is the technology upon which a mesh could be implemented (as Nordic does in their SoftDevice stack along with Thread). Particle will be implementing a "conventional" BLE API for mesh devices.

Confirming there is no plan for Bluetooth mesh.

2 Likes

Stable Threading +1
BLE API +1
3rd-Party Boron LTE SIM actually working +1

Until those things work AND have a reasonable track record, I will stick to the Electron and Photon. My use case requires threading for viable operation. I use way more data per month than Particle is going to be cost-competitive on. I need to be able to have the end user reconfigure WiFi credentials without physical access. The Photon does not have enough RAM to use MQTT with TLS.

If these things didn’t materialize I would eventually be forced to move to a different embedded platform (likely Amazon’s FreeRTOS port) within a year or so.

1 Like

Sorry 3rd party sim is out of the Boron SOM. It means LTE outside of US is a no go, and it was needed as fallback for single locations without coverage, in a multi location delivery to keep the contract. Hope to see at least an interface to one in the coming products.

THIS

  • Mesh Network being able to use alternative gateways. For example, if I have 3 Xenons, 1 Argon and 1 Boron – if the WiFi goes down, the devices connect to the cloud via the Boron, and switch back if the WiFi becomes stable again.
1 Like

Are we still limited to a single gateway per network at the moment?