Removal of ASoM platform and addition of B5 SoM in 1.5.0-rc1

In the patch notes for Device OS 1.5.0-rc.1, the following changes stuck out to me and I felt that they warranted some discussion.

  • [B5 SoM] B5 SoM platform support
  • Removes xsom and asom platforms #2011

The addition of a B5 SoM i find quite interesting, as this is the first I’ve see of it and am curious what differentiates it from the “standard” BSoM (as they are indeed separate platforms).

The removal of the xsom is to be expected due to the discontinuation of Mesh, and the axing of normal Xenons. I find the removal of the ASoM to be somewhat disconcerting, as the entire point of the SoM form-factor (as I saw it) was allowing the creation of a universal “daughter-board” for your project, that could be slotted with a cellular or WiFi module depending on the deployment location.
During the Q/A with @zach and @will they had mentioned that they were in direct discussion with some enterprise customers regarding development of the ASoM, and that people should contact them directly for feedback/input on an M.2 Argon as they were still roadmappin the platform.

With this removal from the Device OS I’m curios as to the following:

  • Will the SoM form factor ever receive a WiFi device? (I don’t see the point in it if this isn’t the case)
  • While I’m painfully familiar with the difficulties of deploying a WiFi device to a customer’s site, it seems like Particle is leaning in heavily to Cellular, which has its own pros and cons. The biggest being the added cost of data, and the fact that WiFi is basically everywhere (difficulties of connecting aside). Why would I want to go with cellular, if WiFi is a valid (and cheaper) option?

I’m curious as to what others in the community think about this push towards cellular, and it’s broader ramifications on the Particle ecosystem.

2 Likes

The A Series SoM (Wi-Fi) has not been ruled out as a product, but will not be available in the near term. We turned off building Device OS binaries for it since it won’t be available soon, but could turn it back on at any time.

From this blog post from October 2019:

SUPPORTING LTE IN NORTH AMERICA NOW, EUROPE IN 2020

The B402 is our first module to support LTE Cat M1. At the time of this announcement, LTE CAT M1 connectivity is available in North America. For customers deploying in Europe, LTE CAT 1 will be available in Q2 2020.

The b5som is LTE Cat 1 for Europe. LTE Cat M1 is not widely deployed in Europe, and there are some difficulties with LTE Cat NB1 for features like OTA code flash. Roaming across LTE Cat M1/NB1 carriers is also difficult at this time. LTE Cat 1 solves these problems and is especially useful in Europe.

1 Like

This is pretty disappointing news. Seems like anyone basing a product on Wi-Fi needs to have a backup plan for another platform. Even with 4g my customers are unhappy with the lag and additional cost in a cellular system, so Wi-Fi is the standard for my product line.

As Rick mentioned we’re not ruling it out as a product but are calibrating priority based on customer demand…if you have an application that would benefit from the ASoM vs. the Argon, we’d love to learn more

Being able to run an application on a cellular device and a WiFi device is a big differentiator for Particle. Adding BLE/NFC to Gen3 over Gen2 is a clear step up as well.

You have to admit that even with LTE Cat 1 there will be locations inside buildings where it does not work. On top of that the cost of ongoing cellular data will kill a lot of IoT/Connected Products. That is certainly the situation with the products I design - they are all use WiFi and are in Schools and Universities. Those guys will pay once but aren’t keen on high on-going costs.

It is a big jump for someone wanting BLE+WiFi (i.e Argon) to pay without the certainty of a lower cost volume solution in the immediate future.

IMHO you should charge more for WiFi cloud service to make it commercially viable versus cellular if that is the problem but don’t cut off the volume hardware solution in Gen3 for WiFi connectivity.

This is one problem that I envision my team will have. We’re making devices that get deployed in hospitals, many of which will be in the basements of large buildings that are notorious for poor cell reception. But we want the option of building one daughter-board which can be either WiFi or Cell depending on deployment location (as some location might have poor WiFi but might be near a window)

Trying to convince senior management that we need to move from a one-time purchase cost to a subscription based model will be… difficult to say the least. And I have to agree with @armor that getting administrators to pay monthly will be equally as difficult.

Wait, does this mean 1.5.0-RC-1 and forward won’t support mesh at all, even if we have devices out there that aren’t ready to ditch their mesh setups? Any chance we could leave those available for a few months to support those of us that it would leave in deep water until we have time to create our own xenon alternatives?

Mesh will be completely gone in 1.6.0. As long as your devices stay at 1.5.0 or below, they will continue to work.

@Mjones, my understanding is my v1.6.0 will be the last version to support mesh.

2 Likes

I knew I should have double checked that before posting. Thanks for the clarification.

1 Like

whew, that works. Thank you, just got code on a test device and it was still fully functioning on RC1.