@Vitesze, I noticed that your Serial.print(“failed to connect -…”) hints at 5 minutes but your sleep command is only for 5 seconds. Your FSM may not be right. Here:
case CONNECT: {
if (millis() - lastConnectSample >= 8000) {
lastConnectSample = millis();
Serial.println("connecting...");
Particle.connect();
}
The code will keep calling Particle connect every 8 seconds it seems. You may want to separate your code into more states.
It’s supposed to be 5 minutes, but for testing purposes I reduced it to 5 seconds…
Is calling Particle.connect() repeatedly not the way it is supposed to be? I saw several examples in the past where people kept calling it. Is it really sufficient to only call it once? I don’t know if its something related to older firmware or whatever, I just did it this way to maximize the odds of establishing that connection
I installed 6 devices in a different part of town 2 days ago…They’re set to connect every 6 hours, and today combined they missed about 30% of their expected connections. It’s a part of town that should have decent connectivity; near a very large shopping centre and the airport. The only thing I can think of is that these waste containers actually had metal lids on them.
The max. connect time was set at 60 seconds, with no re-attempts…whatever the issue may be, I was hoping increasing it to 90 seconds with 2 re-attempts and possibly a stronger antenna would solve the issues
It just won’t be feasible for me to drive around with all the Electrons all the time to make sure they can connect. I want to activate them in any part of town and at the very least get a 95% reliability with their connections. Right now I’m at 80% for yesterday and 68% for today.
Whenever I catch such a repeated calling of Paricle.connect() I usually comment on it that this is not good practice.
Especially for the Photon but probably also for the Electron a new call to Paricle.connect() during an ongoing connection attempt will mess up things and knock back the current attempt.
But recently there were some changes to Particle.connect() logic - especially in connection with SYSTEM_THREAD(ENABLED) - which might render this obsolete if you are targeting 0.6.3+, but good practice would still be to not trigger a new attempt while another is still running.
On the Electron one single cold connect can take up to five minutes and calling Particle.connect() before that periode is over might cause troubles. You can always use waitFor(Particle.connected, someTimeout).
Version is 0.6.2, and using SYSTEM_THREAD(ENABLED). I will remove the repeated calls to Particle.connect(), even if it doesn’t solve this issue at least it should reduce other potential issues then… 
EDIT: Only one call per attempt now, but it can’t connect still on 2nd/3rd attempt.
My best guess right now (also judging by other topics; and eliminating potential causes by trying out stuff with code) is that while the Electron is still busy carrying out Particle.connect(), once anchorTime = 60000, it goes to sleep right away…Possibly doing this will cause several issues with the modem at that point?
I’ll try to fully disable the Cellular modem before it goes to sleep as maybe Cellular.on() isn’t even sufficient to put it in the correct state again afterwards
Give 0.7.0-rc.3 (rc.4 may have some issues) a try. There should be some improvements revolving around properly winding down the connection and cellular modem before sleep.
Also, give the same code you were originally trying today minus the extra Particle.connects a try tomorrow and see if it starts connecting normally again.
For me, the long connection times would come and go with no real cause that I could find. I chalked it up to just cellular service provider issues. I was not using the Particle could either, just connecting to the cellular network to send data to Ubidots via MQTT directly.
I did run it with only calling Particle.connect () once. Didnt help the issue, but I can see it being an useful change regardless.
I will test 0.7.0 firmware next week.
Im using third-party Simcard…it couls be an issue, although tbg theyre from a pretty big cellular provider that has good coverage in this city, so I’d be surprised.
I should add in some code to test how long exactly they take to connect right now. My guess it’s the conditions (semi-thick metal all around it), some subpar firmware design on my part, and antenna gain which could be a bit higher I think.
Publish that RSSI data on each unit also, that’s an important part of the equation for the deployed units that are not working.
CellularSignal sig = Cellular.RSSI(); // Prototype for Cellular Signal Montoring
int rssi = sig.rssi;
int strength = map(rssi, -131, -51, 0, 5);
That maps stregenth from 0 Low - 5 Max.
@Vitesze Any luck with your Electron today?
I just plugged in my Electron with a low battery and it went breathing white. Plugged in USB and it connected right up.
Not yet, usually on the weekends I dont spend too much time on it…
My next step will be to download 0.7.0 on an Electron and see what happens. For sure its no voltage issue as it happens with different 2A LiPo batteries. My guess right now is that after Particle.connect () is called, eventually i put it to sleep to wait for 5 minutes, and this must confuse the Electron. The LED feedback i rexeive on the 2ns attempt makes it seem like it does find the signal, but cant establish the connection properly
My alternative step is to seperate this state into two states, and see if it fixes that way.
You have a Particle SIM card you could test also?
Yeah, will try it too!
(1) Tested this with separate it into different states - didn't work
(2) Tested with 0.7.0-rc.3 - didn't work
(2) Tested with a Particle Simcard -didn't work
With all 3 methods during the 2nd connection attempt I still get the blue+white led shown several times (with 10-15 second intervals)
Like here:
The issue I have is that Cellular.ready() never returns as True. However, this even happens with 0.7.0-rc.3 for me, not just 0.6.2 as stated before.
A suggested fix is to put the device in Deep Sleep instead, but I can't do this as this would lead to the loss of my stored variables (the device first collects data, and then connects)
I looked at my sensor data from the weekend, and out of 51 expected connections to the Cloud only 41 were made (approx. 80%). It seems to be very variable which ones don't connect; so far, all 6 have been showing some connection issues, but none of them has been totally unable to connect. The conditions are a mix of closed container w/ metal lid, closed container w/ plastic lid and open container
Send the RSSI signal data when you can.
Also you can use retained variables via eeprom so your data is saved even during power down.
I will soon, when I got some time 
Using EEPROM in order to bypass an important issue with my Electrons doesn’t seem good practice to me and makes things unneccesarily complicated. Surely there must be a way to put an Electron in sleep mode if it cannot connect, and then re-attempt it again later?
Added the RSSI in my code, now let’s wait and see tomorrow what the data shows for them…
I used the code with one of my sensors at my desk and the RRSI fluctuated between 3 and 5, eventhough there wasn’t really any difference in the time it took to establish the connection…I suppose 3 is still more than satisfactory?
Cool, should at least give us a clear picture of what’s going on with all of them and how the all metal bins affect signal strength.