Electron power-on connectivity issues with 0.8.0-rcX

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.

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.

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.

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

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.

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?

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

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?

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

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.

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.

Reproduced with rc8.

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

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

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

Bumping this, as the issue is a blocker in testing/using 0.8.0. I noticed that all the updates to 0.8.0-rcX have focused primarily on small modem tweaks, so I can’t quite tell if there’s traction on resolving this. It’s been three months since the original bug report, so it would be nice to get an update Particle’s current thinking.

@rickkas7, do you know if this is intended for resolution in 0.8.0?

1 Like

@kubark42 could you try this app and let me know what you find? I’m getting good results after disabling charging.

If you don’t get good results, I’d like to see what your logs look like. Start particle serial monitor --follow and then plug in your device after that. You can send them to my email if you don’t want to post here: 08%20PM

#include "Particle.h"

SYSTEM_MODE(SEMI_AUTOMATIC);

SerialLogHandler logHandler(115200, LOG_LEVEL_ALL);

void setup()
{
    PMIC().disableCharging();
    Particle.keepAlive(30); // would recommend 30 seconds with any 3rd party SIM as a default
    Particle.connect();
}
1 Like

Initial tests are good here as well. I simply added PMIC().disableCharging(); at the beginning of my program. Boots and stays online for several minutes.

Interesting! I wonder, have charging parameters changed in 0.8.0? And how would this interact with the system not having a battery at all?

Thanks for figuring this out. I’m pumped about finally being able to access all the coolness of 0.8.0-rcX!

We reworked the PMIC Power Management in 0.8.0 to work better for Device Diagnostics. So it looks like something is causing an issue when the system detects the battery as missing. It seems to be causing AT commands to fail completely, but that’s as much time as I had this weekend to look into it. Disabling Charging is something you could have done and probably should have done before if not using the battery.

I’ll have to make sure it’s in multiple places in the Docs. I’m sure it’s in there in at least one place though. That said, not disabling charging shouldn’t cause the modem to stop responding to AT commands.

I’m thinking the Power Manager might be switching power to the BAT pin forcefully and causing power loss to the modem, in an effort to detect when the battery is disconnected and connected.

2 Likes

I think the only part of the documentation I’ve ever consulted was where it discussed the required powersupply for non-battery operation. I’m fairly confident I didn’t see anything to the effect that I should disable the battery charging. But now I know!

I think this unit is doing fine now. For sure, we see it transmitting data continuously, and the health metrics show up in the Particle cloud. Maybe we can consider this bug has a workaround, and then the scope can be reduced to why the battery charger has an interaction with the AT commands?