Electron power-on connectivity issues with 0.8.0-rcX

Troubleshooting
1

Upgrading to 0.8.0-rc7 has made it so our units no longer stay connected when booted off the power supply. We are using a 5V supply rated well in excess of 5A.

They boot and stay connected fine when a battery is plugged in, but without the battery on the first boot they do not stay connected. What’s weird is that they do complete the handshake and deliver an initial diagnostics message (we can see it in the console), but then they go silent and become unreachable. The cyan LED starts blinking rapidly.

It’s also weird that the battery can be removed and then the Electron rebooted without reproducing this problem. It really is only on initial power-on.

This problem was seen across several tested devices. Using particle device doctor to downgrade to 0.7.0 solves the problem. Have not tested other 0.8.0 RCs.

This occurs whether the firmware was compiled for 0.7.0 or 0.8.0-rc4 (-rc7 is not available right now as an option in Particle Dev).

This is using a 3rd party AT&T SIM, with KeepAlive set at 60 seconds.

This is an absolute blocker for us for 0.8.0.

1 Like
2

Thanks SO much for posting this!!! I spent all day trying to get my electrons online :cry:

I’m running OS 0.8.0-rc.3 on 5 Electrons. I can only get them online when I power them on with the LiPo. I loose connectivity as soon as I unplug the LiPo, even if the Electron is powered by an external power-management circuit or via USB. It looks like it NEEDS the LiPo to maintain cellular connectivity!!

I’m going to try to downgrade to 0.7.0 and hope that I can connect without the LiPo. Hope that switches things back to normal! :frowning: :frowning:

3

You should be able to compile for RC7 via CLI by means of the --target 0.8.0-rc.7 switch.

While this should not happen when 0.7.0 does not suffer the problem, but the amperage of the PSU isn't the only factor. It's also the capability to respond fast to changing power demands.

4

rc.7 not supported:

C:\Users\Foo\Documents\Particle\projects\firmware_sandbox [master ≡ +1 ~9 -0 !]> particle update-cli
Updating CLI... no plugins to update.

C:\Users\Foo\Documents\Particle\projects\firmware_sandbox [master ≡ +1 ~9 -0 !]> particle compile electron --ta
rget 0.8.0-rc.7

Compiling code for electron
Compile failed. Exiting.
Invalid build target version.
Valid targets:
0.8.0-rc.4
0.8.0-rc.3
0.8.0-rc.2
0.8.0-rc.1
0.7.0
0.7.0-rc.7
0.7.0-rc.6
0.7.0-rc.4
0.7.0-rc.3
0.7.0-rc.2
0.7.0-rc.1
0.6.4
0.6.2
0.6.2-rc.2
0.6.2-rc.1
0.6.1
0.6.1-rc.2
0.6.1-rc.1
0.6.0
0.6.0-rc.2
0.5.3
0.5.3-rc.3
0.5.3-rc.2
0.5.2
0.5.3-rc.1
0.5.2-rc.1
0.5.1
0.5.0
0.6.0-rc.1
0.5.5
0.5.4
0.4.8
0.6.0-libraries.1

Excellent point. In specific, it fails on our lab bench supply, our bespoke high-efficiency TI 12V-5V DCDC trafos, some super cheapie DCDCs bought from China, and USB. We have tried a lot, but simply can't find a combination which allows it to work correctly without the lipo.

@archr, sorry to hear you're having the same problem. In private emails with Particle, it sounds like they test stuff pretty extensively, so I'm wondering what edge case we're catching here. It's a great data point to know that this isn't exclusive to rc.7.

More info about our test case is that we run in MANUAL mode and don't turn on the radio immediately, so the system isn't seeing as large an inrush current as with typical firmware.

Are there others able to reproduce this? It's a scary problem, because it means that an OTA OS update (so cool that we can do this!) can wind up bricking remote units which intentionally have avoided using a battery. If that's the case, this is a huge blocker to roll-out.

5

This might be a point for @rickkas7 to look into with his lab equipment :wink:

6

I'm really not sure. The only program I serially uploaded to the Electron after the upgrade to rc3 was BLINK_LED to test if the upgrade was successful. I'm stumped :frowning:
Although, downgrading to 0.7.0 with particle update resolved my issue of connectivity, I'd love to understand what the issue with 0.8.0 rcX is!

7

I wasn’t able to reproduce this. I’m not saying there isn’t a problem, there very well may be, but the problem didn’t happen for me and I’m not sure what is different about my setup.

  • I used an Electron 3G Americas U260.
  • Installed 0.8.0.rc.7 and tinker by USB
  • Did not connect a battery

The Electron connected normally and proceeded to breathing cyan powered three different ways for me:

  • Supplied 5.5V at up to 2.5A to VIN using a bench supply
  • Supplied 5.0V at up to 2.5A to VIN using a bench supply
  • Supplied by a 2A USB power supply
2 Likes
8

@rickkas7 Thanks for giving this a try.

One difference I can instantly think of is are you using a 3rd party SIM, and if so, what is your KeepAlive time?

Another difference is that you tested with the tinker app, which was presumably compiled for 0.8.-rc.7. the latest version for which we can compile custom code is 0.8.0-rc4. Can you confirm that this works when you use an rc4 binary?

10

Tinker is built for 0.4.6 or something like that. But I can try using an 0.8.0-rc4 binary and a 3rd-party SIM tomorrow. I used the Particle SIM.

11

I don’t have a Particle SIM, so can’t test Tinker. I could compile a simple example against 0.4.6 and test that, though.

12

You can test Tinker with a 3rd Party SIM just the same, you just need to use the demo application provided in Web IDE and add your APN settings with it.

Electrons are always sold with SIM, so you should have one, but might not have activated it.

13

This is how you build tinker with APN settings:

https://docs.particle.io/faq/particle-devices/electron-3rdparty-sims/electron/#making-tinker-with-apn-setting

1 Like
14

Fair. By that metric, I have 41 of them! (Speaking of which, is there any kind of market for these things? I hate to throw them away, but they're not really useful to us).

I'll test with the tinker app.

15

I’ll test with the tinker app.

The same behavior. It successfully connects, breaths cyan for several seconds, and then goes back to rapid flashing cyan. The below message appeared in the console:

{"data":"{\"service\":{\"device\":{\"status\":\"unreachable\"},\"coap\":{\"round_trip\":null},\"cloud\":{\"uptime\":112,\"publish\":{\"sent\":1}}}}","ttl":60,"published_at":"2018-06-14T14:28:18.828Z","coreid":"32002d001947373333353132","name":"spark/device/diagnostics/update"}

and this message appeared another time:

{"data":"{\"device\":{\"power\":{\"battery\":{\"charge\":71.46,\"state\":\"unknown\"},\"source\":\"USB host\"},\"system\":{\"uptime\":34,\"memory\":{\"total\":111616,\"used\":28200}},\"network\":{\"connection\":{\"status\":4,\"error\":0,\"disconnects\":0,\"attempts\":1,\"disconnect\":0},\"signal\":{\"rssi\":-73,\"strength\":50,\"quality\":75.51,\"qualityv\":-6,\"at\":4,\"strengthv\":-73}},\"cloud\":{\"connection\":{\"status\":1,\"error\":0,\"attempts\":1,\"disconnect\":0},\"disconnects\":0,\"publish\":{\"rate_limited\":0},\"coap\":{\"unack\":0}}},\"service\":{\"device\":{\"status\":\"ok\"},\"coap\":{\"round_trip\":1368},\"cloud\":{\"uptime\":1,\"publish\":{\"sent\":1}}}}","ttl":60,"published_at":"2018-06-14T14:30:47.740Z","coreid":"32002d001947373333353132","name":"spark/device/diagnostics/update"}

It's unclear to me whether that message is written by the Particle cloud server or if it is a received message from the Electron.

@archr, what SIM card are you using?

16

Particle's default SIM. What version of the firmware are you trying to run now?

17

I am only able to use 0.7.0. Everything else has this bug.

@rickkas7, what could we do to help further the understanding of this issue? I can hook an o-scope up to see if voltages are stable. What pin(s) should I be looking at? 3.3V and 5 are obvious contenders, is there anything else as well?

18

In the datasheet there is a recommendation that Electrons not using the LiPo should have a 470uF elec to handle the surges in current requirement. They are pretty hefty spikes which seem to be beyond the ability of many otherwise overspecified switching regulators to keep up.

2 Likes
19

You may also want some smaller (non electrolytic) caps to increase response time which isn’t that great with big electrolytic caps due to their inherent inductance and resistance.

20

We have bulk caps and low ESR ceramic caps. The power supply is spec'ed to fill a 1mF cap without sagging. Perhaps the original suggestion for 470uF is too small.

However, rather than work around this in hardware, it would be much better to understand what the software change was. It's possible that it's the result of a useful change to the modem configuration. But it's also possible that this is a change which benefits a few people at the cost of large fleets of installed hardware. It might even be a bug, causing the Electron to use more power than minimally necessary.

It would be great to isolate the change, so we can decide on a case-by-case basis if we'd like to activate/deactivate the feature.

22

Reproduced with rc8.