Electron: Hardware Discussion


#21

Battery management is a very important feature to me. I loved reading that you are working on battery management for the Electron. Many Electron boards will be used in small mobile systems, so the ability to charge a battery is very important. I chose not to back your campaign this time, because it seemed that battery charging would not be implemented. I will be happy to order an Electron or two, if you are able to implement an on-board battery charger.
Solar panel management would also be great to have, but I suspect that this is so complex that it has to be a separate board.


#22

The standard JST connector probably makes more sense, even with the risk of hooking up a battery backward. That's a risk with any connector if a cable is made incorrectly, not checked, and connected. I'm OK with requiring the battery in tandem with the USB connector. It will only be on the USB during development (long time) and production load (short time).

Goes without saying that the cell should be off except when in use. We are using this for outbound data only, and would rather have control over battery usage. Will need to be able to get battery life data from battery and then manage data transfer accordingly. More important to keep the system running if the battery gets low, than to transmit data.

The more flexible the power sourcing the better. Some applications may be battery, and others may have local power (automotive). The JST connector should be able to accept and manage a liPo or accept external +5.

Smaller CPU is better of course since it gives you some of that real estate for the liPo charger circuitry.

I like the suggestion to put the USB and battery connector side by side. I've also used uC boards with the USB on one side and the batter opposite on the other. Anything to get both connectors at one end of the board.

I have two product plans currently, and expect more. The antenna should be a flexible choice. Sometimes small and mobile matters more than large with great signal. I'd like to be able to select.


#23

The castellated edges work only when the bottom side does not have any components, like the Photon. In the current state, the Electron has components on both the sides. So, castellated edges are ruled out for now.

@ScruffR

Thanks!


#25

I've a bit to add to the discussion on the battery charge management circuit (although I don't really know how it entirely works).

I've been using the topology and components found here in a product:
Circuit:
http://ww1.microchip.com/downloads/en/AppNotes/01149c.pdf
Battery Charge Management Controller:
http://ww1.microchip.com/downloads/en/DeviceDoc/22071B.pdf

In my case, I've also used an isolation circuit that switches off the device when the battery's charging, which won't be suitable for Electron. This IC (isolation circuit in one integrated circuit smile ) occupies a good proportion of the space.

That said, I had layout made on EAGLE. All these (with 0805 diodes, resistors and caps) fit in an area equivalent to that between the Core's USB and CC3000 (roughly, for a comparison).

The JST connector and LED indicators are placed elsewhere. The other components are inside the highlighted yellow box (It is a pretty big area).

My pick would be the standard JST connector.


#26

I've used this chip on many projects for power path management, even on my own 3G cellular breakout board.

http://www.digikey.com/product-detail/en/0/296-23840-1-ND
BQ24075RGTT

This is small 3mmx3mm and does exactly what the electron needs although it is pricy. There are a few different variants within this family but work about the same.


#27

I work for a company that has done industrial IoT since 2001 open_mouth
If there were some things I would want to see in the electron it would be
- The ability to minimize power while allowing for I/O (particularly I). Similar to the TI CC2650, a very low power monitoring chip would go a long ways towards maximizing battery life. Quite simply, we don't need to communicate all the time but we want to sample environmental data frequently and send composite datasets.
- The ability to obfuscate and/or encrypt communication down to the device. In fact, generally hardening communication is necessary. Is there a way to set up the device so it only calls out and does not accept incoming connections? Is there a way to verify commands sent down to the electron?
- This one is a doozie and probably not possible but it would be amazing to have intrinsically safe rating or something similar so it can be used in a number of warehouse, silo, and enclosed environments that require IS or class1-div1.
- Minimizing the time spent to authenticate on the network. This chews up so much time, just getting connected.
More to come as I think about it


#28

Thanks for all the valuable input guys!

@wesner0019
TI offers some really good battery management units. I'm currently evaluating BQ24298 in particular. It offers a programmable input current limit via I2C and power-path management.

The other units under evaluation are:
MAX8606 from Maxim
LTC3567 from Linear Tech

The second stage of this setup is to choose a regulator to power the STM32 micrcontroller. A buck-boost or LDO are both viable options. One chip solution would be ideal here. LTC3567 comes very close to having everything except for the fact that its output voltage exceeds the Ublox module's input voltage and would need to be regulated.

Feedbacks always appreciated!


#29

More thoughts
1) I want to be able to pot the entire device to prevent moisture intrusion.
2) I want to be able to monitor battery voltage in quasi real-time. We have found that the resting voltage can look good byut the moment you turn on that cellular radio, there is such a rush of current that you can get a brownout. It is good to be able to monitor the voltage to look for this but you'd need a circuit to smooth the reading to at least many mS (well, maybe not THAT long).
3) I would second the ability to use our own antenna. BUT if you are thinking about antenna's I'd love to see a flat and squat or circular type, that is, one that isn't really long in any direction. Something that can fit into small spaces and radiate out in a dome-like field.

More thoughts to come


#30

Will the Electron be providing a way to gather cellular tower data for telemetry purposes? All this discussion on power makes me think I'd love to eliminate needing a GPS all together and save boat loads of cost and power. I don't really need GPS-level location accuracy. The cell-only location accuracy on my old iphone was more than sufficient for my application.


#31

@graves14
We definitely want to make the telemetry possible without solely relying on a GPS module. We'll have access to base station information and rssi values at all time, but we haven't really explored the possibility of exposing it to the user in an easy to use API form. This is something we will look into when we get to it.

Thanks!


#32

In the spirit of keeping all of the development work transparent and open, I have decided to create a publicly accessible repository for the Electron hardware dev. I'm also experimenting with keeping a well updated project journal available within the repo. I'd love everyone's inputs in every way possible!

Here is a link to the github repository: https://github.com/spark/electron-powersupply


#33

Whether GPRS / 3G modules have an opportunity for SSL?
The new model of the Quectel M95 (Quectel M95 FA) has enabled support for SSL.
http://www.electronics-lab.com/blog/?p=32897
Good option for microcontrollers with weaker performance. SSL layer is provided by the module.

Whether you have enabled SSL encryption with the possibility of using a TCP library.
Mbed have mbeTLS whether it will be possible to adapt used with Electron.
https://tls.mbed.org/


#34

Now I saw that CyaSSL is supported directly by FreeRTOS, perhaps it is best to implement in the TCP client/server library.
http://www.freertos.org/FreeRTOS-Plus/CyaSSL/CyaSSL.shtml


#35

We have in fact already implemented TropicSSL in our firmware libraries (which is a BSD-licensed fork of PolarSSL), although we're planning on evaluating mbed TLS when it becomes available.


#36

It's great smile ,
Whether there will be the possibility of accession by client library?
For example:
client.SSLConnect ("www.particle.io", 443));
Whether this will be a possible for Photon and Electron?


SSL/TLS library
#37

JST connector for sure, regarding the LiPo power (and a pin header for powering with an external LiPo for embedded purposes).

There was a question regarding GPS in this thread...
Does the cellular module itself have aGPS capablility? (and if so, will an extra uFL connector be exposed for a GPS antenna). I would find it very valuable to have this functionality incorporated if the cellular module has it natively -- I imagine a large number of remote applications will want GPS data (or aGPS data). Having it query-able through your platform would be ideal; or even something as basic as accessing it with AT commands...


2G/3G cell tower location tracking?
#38

Power consumption is indeed critical. I've used some other modems that I had to switch off via a transistor since their standby power usage was way too large. LEDs are great for debugging, but just suck power. (One board I used was drawing 80 mA without even having the modem on!) So whatever happens, having a low power sleep mode is critical for me. (With the transistor and a custom Arduino, I'm now down to 3.5 mA in sleep, which is decent.) So what I'm saying is make sure the modem is really off when not needed, not some half-powered standby. If you want LEDs, put in a jumper so I can turn them off.

As for powering it, LiPo is what I'd use. However, the USB battery booster packs are rather convenient for users, since they are easy to connect and only go in one way. Makes testing easy, too, since I can just plug in +5V or into the computer. You obviously need a connector, so whatever you pick, it should be relatively common and easy to get. Including the other gender in the box would be great, so I can just make a cable, or at least include a USB to whatever you select.

Package wise, all I really care about is durability. If you use the WLCSP, it must be encapsulated very well. The LQFP just seems easier, though, IMHO.

Antenna: you'll likely never get consensus on this, so maybe let people pick from 2 or 3? I want something that takes up as little space as possible, but is omnidirectional.


#39

Hi @NMASSON
The cellular module does not have a built in GPS receiver, but you can get telemetry data based on cell tower triangulation. We have a GPS shield (asset tracker) that will pair up nicely with the Electron to provide accurate position information.


#40

I would be interested in helping with this; my main purpose in backing the electron is to see what might be available to a dev on the radio side; hopefully able to dig in deeper than the Android APIs allow (and way deeper than Apple's...). We do a cell network monitoring platform today and would love to have deeper access into the radio data to better help our customers.


#41

Hey folks,

Snapped a couple of photos of Mohit working on the development boards for testing Electron power supply. Thought you'd like to see!


Power Management