We will have to wait for particle 
OK It seems to be the antenna or SIM/provisioning as the primary cause and timeout as potential secondary cause
Getting signal strength: RSSI: -79dBm, QUAL: 25dB, BARS: 3
Getting signal strength: RSSI: -79dBm, QUAL: 25dB, BARS: 3
Getting signal strength: RSSI: -77dBm, QUAL: 25dB, BARS: 3
Getting signal strength: RSSI: -77dBm, QUAL: 25dB, BARS: 3
Getting signal strength: RSSI: -77dBm, QUAL: 25dB, BARS: 3
Pinging Google DNS 8.8.8.8 (Consumes 240 bytes per ping): ERROR!
ERROR 17 : PSD or CSD connection not established
Getting signal strength: RSSI: -81dBm, QUAL: 25dB, BARS: 2
Getting signal strength: RSSI: -81dBm, QUAL: 25dB, BARS: 2
Getting signal strength: RSSI: -81dBm, QUAL: 25dB, BARS: 2
Getting signal strength: RSSI: -79dBm, QUAL: 25dB, BARS: 3
Pinging Google DNS 8.8.8.8 (Consumes 240 bytes per ping): ERROR!
ERROR 17 : PSD or CSD connection not established
Pinging www.bing.com (Consumes 64 bytes per ping): ERROR!
ERROR 17 : PSD or CSD connection not established
Getting signal strength: RSSI: -71dBm, QUAL: 25dB, BARS: 3
Pinging Google DNS 8.8.8.8 (Consumes 240 bytes per ping): ERROR!
ERROR 17 : PSD or CSD connection not established
Pinging www.bing.com (Consumes 64 bytes per ping): ERROR!
ERROR 17 : PSD or CSD connection not established
Getting signal strength: RSSI: -73dBm, QUAL: 25dB, BARS: 3
A friend and I have a total of four electrons. Two were activated more than a month ago. The newest two were activated at the same time about two weeks ago. The two newest both stopped working last weekend, at basically the same time, after working fine for about a week. The other oldest two continue to work fine.
The new two seem to exhibit almost the exact same flashing sequence as described in this thread:
- Power on (by plugging in the fully-charged LiPo)
- On white, breath white once
- Rapid green flashing for a couple of minutes
- Rapid cyan flashing for about one minute
- Two or three orange flashes
- Rapid cyan flashing for about one minute
- Repeat back to 2
Weāve already tried ākey doctorā. My friend opened a ticket and tried a few things that were suggested that didnāt helpā¦ then support has gone silent for the last week.
I was contemplating trying to tack some wires onto the modem rx/tx to capture the traffic, but I donāt see a ready place to do this in the layout; Reza ā how did you produce the logs in your last few posts?
For what itās worth, all four of our electrons are running 0.5.0
Thanks,
Jeff
@JeffInCO the first debug list is using the following
https://particle.faqt.co/share/h867h4
the ping test and timeouts is using the following
I wonder what are our options considering that the units are not usable at this stage ā¦ since support case is also silent ā¦
The 3 blinks of orange indicate a server key error. Be sure to update your CLI, and then run
particle keys server
I hope that helps. Let me know 
1 Like
I have the same problem. Here is the detailed error log:
What I did
- Upgarded particle cli
- Upgraded firmware to 0.5.1-rc1
- Flashed the usb debug tinker firmware
- Got the result. It seems like your 3c002a000b51343334363138.udp.particle.io has problems.
1 Like
Iāve had the same problem. For me it started a few weeks ago. I originally bought a single Electron. I got it all working on my project and wrote some custom code for it. Finally I updated to the latest firmware to 0.5.0. Everything was working great. Then I ordered two more electrons. I immediately upgraded them to 0.5.0 and flashed them with my custom code. They worked for about one day. Then within 30 minutes of one-another, the two new devices stopped working alltogether. They started going through the pattern sequence described earlier by JeffinCO (Hi Jeff). My original Electron device continues to work with no issue.
Iām not sure what to do at this point. Iāve had a couple of Particle team members respond to support requests that I posted. But they seem to go silent and I never hear from them again as if I have some sort of incurable disease. One of them indicated that there is some known issue with the particle cloud service that was currently being debugged by engineering and then he stopped responding to my emails after that. The other asked me for information about my devices and I never heard back from him after that. Again, no further responses to my emails that followed.
I think there is some issue with either the cellular service or the cloud service. I see someone posted that after deactivating their SIM card and re-activating it again, the problem remains. And by accident I unclaimed one of my failing devices and then re-claimed it again on my particle account, but the problem remains. I would really like to use this device in a product Iām developing, but I canāt make any forward progress until this issue is resolved. Iāve gone ahead and ordered two more devices (assuming someday this issue will be resolved) but it would be great if this would become more of a priority with the Particle team, since the Electron device is completely broken and unusable once it gets in this state.
1 Like
This has become a long thread 
@jimmies & @jobsight, have you tried this?
Also particle keys doctor <insertYourDeviceID> might be worth a try.
BTW: Particle has recently stocked up its human resources in the support corner (and will be searching for more).
2 Likes
Yes, this is the message I receiveā¦
>particle keys server
running dfu-util -l
Found DFU device 2b04:d00a
checking file C:\Users\jmead\AppData\Roaming\npm\node_modules\particle-cli\keys\
ec.pub.der
spawning dfu-util -d 2b04:d00a -a 1 -i 0 -s 3298 -D C:\Users\jmead\AppData\Roami
ng\npm\node_modules\particle-cli\keys\ec.pub.der
dfu-util 0.8
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
Opening DFU capable USB device...
ID 2b04:d00a
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "DCT Flash "
Downloading to address = 0x00000ce2, size = 320
Download [=========================] 100% 320 bytes
Download done.
File downloaded successfully
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Okay! New keys in place, your device will not restart.
1 Like
Yes, @jobsight and I have both tried āparticle keys serverā. This doesnāt help a bit.
The problem is almost certainly with the cellular connectivity. I finally got around to installing dfu-util on my Mac, and then installing the debug tinker firmwareā¦ so I can see all of the modem commands.
(For anyone who doesnāt already know, UBlox has an ATCommands reference manual here)
First, Iāll state again that we are using the batteries, and they are fully charged (the red LED cycles on and off every few minutes while plugged into USB, so I assume that weāre just keeping the LIPOās topped off.)
I ran the debug firmware on one of @jobsightās two broken electrons, and on my own electron that works. I compared the resulting logs side-by-side. A few things that I noticed:
-
Both electrons are connecting to AT&T (weāre in the US)ā¦ The AT+COPS? command returns a string containing the hex string 0041005400260054 (0x41 is A, 0x54 is T, 0x26 is &).
-
The signal strength on the broken electron is a bit weaker ā AT+CSQ returns 5,2 on the broken electron vs 10,6 on the good electron. They are sitting next to each other on my desk. (The broken electron has failed to work at three different locations in about a 15 mile radius, but I donāt have signal strength data for the other two locations.) My iPhone is on AT&T also, and I know that I usually see 2-3 bars both at home (where I am now) and at work (one of the other locations where weāve tried the bad electron).
-
The response to the AT+UPSND=0,0 command returns the same thing on both electronsā¦ except that this command returns the dynamically assigned IP address on the Internet for the session, and the addresses are obviously different for the twoā¦ But, the fact that the bad electron is getting an IP address says that itās at least communicating something with the cellular network.
-
Pretty much immediately after the IP address is reported in the log, both electrons try to do a DNS lookup (as others have said above in the thread). The bad electron fails to complete the lookup; the good electron completes successfully.
-
After the DNS lookup succeeds on the good electron, the good electron uses the returned IP address (54.174.165.65 in the log Iām looking at now) to start talking to your cloud. There is a bunch of additional AT commands for the good electron that use that IP address to send and receive actual payload data via UDP. The bad electron never gets to the point of sending or receiving UDP data.
So the takeaway (Particle, are you listening?) The bad electron has not even yet started trying to talk to your cloud! The DNS lookup talks to the cell providerās DNS server to resolve the IP address of your cloud server, and this fails. Itās no surprise that updating the server keys fails to fix the problem!
BTW, The exact same DNS lookup that failed on the bad device succeeds if I run it from my OS X command line. (I.e., dig .udp.particle.io returns four IP addresses, one of which matches the IP address that the good electron gets as the result of its DNS lookup.)
My conclusion is that this is a fundamental cellular connectivity issueā¦ could be HW (why is the signal so weak?), or it could be some kind of cellular provisioning/sim issue.
Jeff
1 Like
Thanks JeffInCOā¦ Adding to what you said, itās interesting that both of the bad Electrons worked right out of the box for 24 hours or so, then both just stopped working within minutes of each other. Also, as you mentioned, they donāt work at three different locations that good Electrons work in. Iāll need to figure out how you installed the debug software so I can do the signal strength test on the second bad electron. I might also try swapping the antenna with the one on my good Electron.
1 Like
OK, Iāve ruled out the antenna as being the issue. I swapped the antennas between a good Electron and a bad Electron and the results remained the same. The good electron still connects and the bad electron still fails as it did before. My gut tells me that it is a SIM provisioning issue. Besides the antenna being ruled out, another reason for saying this is that when I review āBilling and usageā on my Particle account, the good Electron shows a continued slow uptrend in ācellular usageā from day 1 until now. But for the bad electrons, it shows zero usage even though I used data on the first 24 hours of service when they were working.
1 Like
BTW, Thanks ScruffR for chiming in 
I didnāt intend to direct my previous reply to you; I know youāre not a particle employee.
2 Likes
I did ask Particle to check the SIM and provisioning, nothing but silence so far ā¦
Higher up in the thread, I have documented all the cell com, and its failure ā¦
Thank you very much
A few more comments on signal qualityā¦
The first digit is the RSSI; higher numbers are better.
The second digit is āqualā. One would think that higher numbers are better (higher quality?), but the AT commands reference doc in section 7.2.4 seems to imply that, at least for 2G GPRS, lower numbers are better (lower number is lower bit error rate). The electrons that Iām looking at are U260ās, so theyāre 3G, although Iām not sure if theyāre in 2G or 3G mode. For both 2G and 3G, qual seems to be indicative of the signal to noise ratio, whereas rssi is just the signal strengthā¦
My āgoodā electron returned:
CSQ: 10,6
This would be RSSI of -93 dBm
@jobsightās ābadā electron returned
CSQ: 5,2
This would be RSSI of -103 dBm
@reza Rezaās log showed -71dBm to -81dBm for RSSI, so better signal strength than either of the two electrons (both good and bad) that Iām looking at.
@jimmies error log shows CSQ of 28, 1, so RSSI of -57 dBm
While you are waiting for Particle to reply (as @peekay123 mentioned they are discussing options already) and at the risk I missed a previous try of that in the long thread above:
How do the stubborn Electrons behave when swapping the SIMs for ones with good Electrons?
Does the issue travel with the SIM or stick with the Electron?
1 Like