Electron power-on connectivity issues with 0.8.0-rcX

Troubleshooting
#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.

Automatic over-the-air for cellular devices not working for 3G electron
#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.

#23

Update: this issue has been reproduced by Particle engineers and has been filed as a bug. Thanks, David!

#24

What exactly did you guys figure out was the cause of the problem?

#25

I don’t know that it’s been root caused yet. It was only yesterday that they were able to reproduce the bug. Maybe https://github.com/particle-iot/firmware/issues/1548 will wind up as a 0.8.0 milestone and then we could track it there.

1 Like
Particle's plans for getting firmware to 1.0