SMT version of the Electron

Will there be an Electron (cellular) version of the P1?

While of course anything is possible, it’s not entirely clear how that would work. There are components on the bottom of the Electron, including the main processor, assorted chips, and the SIM card slot. That is why there is no “headerless” version of the Electron that can be soldered directly to another board using castellated holes; that can’t be done with components on the bottom.

As for a P1-like product, you’d have to move everything on the bottom to the top, which would make a significantly larger footprint than the existing Electron, even if you left off the buttons, LED, and USB like the P1.

Of course you can always use the existing open source design for the Electron and just implement it right on your board. You’ll have to go through certification, however.

3 Likes

@jdugat, I believe when the Electron was introduced there was talk of making a version with castellated edges like the new Photon (ie no components on bottom). This seems like a normal progression, much like that of the original Core to the Photon. This is speculation on my part and Particle has not announced any timeline to support this.

1 Like

@peekay123 is correct, a castellated version of the Electron would work (you’d need a cut-out in your PCB) and makes the most sense.

@rickkas7 is also correct in that a true “P1” version (with no components on the bottom) would require extensive rework of the Electron PCB.

Note, all three of us are just speculating and do not represent the official stance of Particle on this matter. Perhaps @mdma or @BDub an comment?

2 Likes

Hey folks! I’m the GM of Developer Tools at Particle, and would be happy to comment on this one.

The answer is that we’re currently investigating the idea of a SMT version of the Electron for scaling cellular customers. We have a bunch of design criteria that are driving our investigation, so we’d love to ask the community:

What design features would you like to see in a SMT module version of the Electron that is different from our existing development kit, here:

https://store.particle.io/collections/electron

3 Likes

Hi I have a few contributions:

  1. currently the VBat is tied to power via a resistor, I’d like to see this removed for the surface mount.
  2. remove all led’s and buttons
  3. remove on board USB connector and add pins for external USB connections
  4. remove default battery connector and just provide inputs
  5. add support to easily add external flash
  6. maybe change the pcb outline to fit everything on 1 side?
2 Likes

Thanks for the great feedback! This is super useful.

1 Like

I have one more thought is to reduce the pitch for the castella to be able to route as many pins as possible

1 Like

I think the following would keep us on the Particle band wagon for a while:

More modem options, including CDMA for Verizon and / or NB-IOT

After that, it woud be awesome to see:

  • The uBlox modem that has cellular locate implemented properly
  • Ruggedized antenna connector, or just have separated inputs so we can pick the connector
  • Pin out the BQ24195 so it can read the LiPo battery’s thermistor
    • OR Use a charge manager that can handle multi-cell batteries
    • OR do away with charge manager all together, and let us pick one that fits with our design
2 Likes

+1 for NB-IoT / RPMA / LoRa

I’ve been told by a Particle employee that NB-IoT is too far off to be concerned with, however I disagree. Many countries (even NZ and Aus) have roll-out planned for 2017. In my opinion, deploying on 2G/3G is not a viable option for a product that needs 5+ years lifespan.
I really like Particle, but if NB-IoT integration isn’t available at least at a software level (we’re building our own hardware) by the time it rolls out, we will have to move on :disappointed:

1 Like

+1 For NB-IoT / RPMA / LoRa
I think it is not too early to think about these technologies.
These technologies are ideal for the further development of Particle Electron.
Especially I think is best next electron to be based on NB-IoT :smile:

Hey all! Thanks again for another round of good feedback.

With respect to NB-IoT, it’s one of our favorite LPWAN technologies that we’ve researched, and would love to build an NB-IoT device as a successor to the current version of the Electron.

The long pole in the tent is not hardware availability (although the number of modules actually available today is extremely limited) but the global rollout plan for NB-IoT support on the carrier side. Most North American carriers are rolling out LTE CAT M1 well in advance of NB1 (NB-IoT), and most European and Asian carriers are leading with NB1 instead of CAT M1. The rollout is expected to happen throughout 2017, but it will likely be well into 2018 until we can talk about global coverage for either technology.

In other words, you shouldn’t assume that an investment into an industrialized 3G Electron represents an active choice to not build on new LPWAN technology, just that they’re being developed on alternate timelines. If you have more or new information that we don’t have on LTE timelines, I’d be very interested in chatting!

3 Likes

Hi @will,

What do you think about expanding the modem options to include support for Verizon? As noted in [this post][1], the design of the industrial electron could follow ublox’s nested design approach, and be able to support a number of modems.
[1]: Community interest in Verizon support for the Electron?

Hey @hwestbrook – it’s a good suggestion, and one that we’ve explored in the past. We’re currently working with AT&T and T-Mobile on their GSM network in the US, so it’s easier for us to build new hardware with our existing carriers than to build new hardware while also negotiating a separate carrier agreement with Verizon.

As you mentioned, though, the u-blox module design is pin compatible and nest-able, so developing an industrialized Electron with our existing carriers and increasing carrier coverage in the future is completely feasible.

Hi @will

Here are some of my tips for the next electron.

  • I think there was also a topic for SIM cards can not withstand the extreme temperatures so it would be good to let the soldering pads for MFF2 (embedded SIM). This is especially important for professional applications.

  • Also it would be good the next version to have a SPI Flash as Core.

  • Pads for external RGB LED.

  • Ublox version of the module that you use to be with the newer firmware that supports Embedded SSL. This is especially important for enabling SSL communication without spending the resources of the MCU.
    This version you are using does not allow it.

1 Like

Thanks for all the feedback! Many of these points (embedded SIM, external flash, industrial operating temps) are considerations that we’re investigating, so my hope is that you all are satisfied with the results.

3 Likes

@will, some while ago I already launched a topic for an “industrial grade electron”, you can find it here Industrial grade electron possible in the future?

Besides temperature and humidity, the connection to the battery seems pretty important as well, since it should be shock resistant for some applications on transportation devices). But it would be great if the battery would be exposed on pins and not a connector on the electron itself, so that the height of the electron is not too big. I have a project actually where this is a problem to fit it inside a very low housing.

Besides an industrial garde electron it would be nice to have 1 (more expensive I understand) device that could handle all sorts of communications like mobile (2G, 3G and 4G at once, as well as wifi and ethernet, I see a big opportunity for these kinds of devices acting as gateways to connect existing devices to the cloud with minimal impact (not having to redesign the whole product).

1 Like

Wouldn't you then be paying for a bunch of technologies you'll never use? I like the current model where you can pick according to your actual needs. Photon for wifi, electron for cellular, Bluz/Redbear Duo for Bluetooth. They should all be (mostly) code compatible, so it shouldn't be hard to replace them with a different module?

@Moors7 I agree, I like the current models as well. But for some applications it might come in handy to have a full system, for others only a part of it. So the current systems are OK, but there eis just a gap to fill some applications (if you have these kind of interfaces, to existing systems you need all communications and in the case of a 1 CPU system you have it all instead of interconnecting them).

But I agree the current set is good

1 Like

@will , has there been any developments on this lately?