Giving up and getting a life



Well I think over the last year Particle has gone from a great platform to a total waste of my time.

I’ve been developing several projects jumping to and froe as time permits and until recently had a great experiance. Now the whole thing is totally junked. I get no end of trouble flashing a core, it bricking up after flashing. Some times it will not flash at all and time outs, and other times it appears to flash but the code on the core hasn’t changed. Now the new libary system means I can not edit libarys so if I know there is an issue with a libary I can not change it and test it. I think so call improvements have basically screwed it all up.

I want to stop paying for a electron that I never get around to using becasue I can not develop the project on a core before transfering it to the electron. If I deactivate the sim will that mean I can never come back to it again later if change my mind?



Hi @VideoLiam ,
Sorry to hear you are having hard time. If I may suggest - DO categorise, and list your complaints. Not general, broad statements, but specifically. Particle community is very responsive, and developers always monitor and listen to our suggestions. ALWAYS try to suggest a possible solution or alternative - if YOU wont say what YOU want, others won’t read your mind.

Based on information I gathered from your post (had to speculate+assume a lot, so could be far off the truth, but hey…) - you using Web IDE, and trying to invoke some library(s), and apply a change to it, and flush the device.

You have two (~~easy) options:

  1. Download desktop IDE , get the library, apply changes and use it.
  2. If you want to use specifically web IDE - download library, apply changes, test it locally. When you are satisfied with the “new/updated” library, rename it to something like ‘mycustom_math’ and upload it.


Does it do the same thing when it’s running Tinker? Though it’s no fun, user apps do influence the operation and flashing of devices. If your app is blocking or interfering with the connections, then failures aren’t uncommon.

How’s that? You can still edit libraries (depending on what IDE you’re using in what way).

With the amount of changes with the Core vs. Photon, and the similarities with a Photon and Electron, you’re better off prototyping on a Photon than on a Core.

As far as I’m aware you can ‘pause’ a SIM until you’re ready to use them again.


I may have to put that in perspective. While it is true that you can still do it as used to be, it has become more difficult to get to the sources with legacy projects, since the “peek” feature for legacy libs got removed (which I already moaned about :sunglasses:)
But as said, it’s still possible


If you are serious (and you live in the US) list the devices you own and I’ll make you an offer for the lot; assuming all of the IOs are ok too…


I would say Dump the old Core’s and go with the more rock solid stable Photons for sure.

Quitters never win and winners never quit :smile:


Hi @VideoLiam

Just one more quick point: my old Cores seem to require a periodic refresh of the TI CC3000 WiFi chip firmware–sometimes they just lose their minds and that is the only fix.

Photon is much more stable and pleasant to work with, which is basically why it was created.


Thank you all for your replies, some with practical suggestions and some more supportive in general.

First let me appolgise and accept the gentle admonishment for my dismissive stance, and title to this thread. It is a bourne from fatigue and frustration. Please forgive me.

Second thank you to BulldogLowell for your offer. I am actually in the UK, and shoe boxing my stock of cores, photons and the odd electron will not be financial burden. If neccessary I am sure I can pass them on to a good home at the London Hackspace. But thank you for the offer, that was kind hearted.

In an attempt to deconstruct the situation I’ll try and be a bit more specific, but be warned I may be meandering.

The project at hand is a reasonalby straight forward GPS tracking project which initially involved an uBlox Neo-6M. This is quite straight forward, didn’t make much difference if it was developed on a core/photon or electron, but clearly was intended to be deployed on an electron. I used the TinyGPS libary. All was pretty much well, the code was designed to createda Particle.variable and by using a raspbery Pi running a simple phyton 3.4 script I could pole the electron to find its position rather than have the electron pump out data on a time interval wasteing bandwidth when nothing interesting was likely to be happening. The Pyton script would then store the data and it could be used to draw a GPS route or specific location on Goggle maps.

The project got put aside for a few months until around christmas I treated my self to a ‘Ublox NEO-M8N GPS & Compass with shell for PIX PX4 Pixhawk Flight Controller’ from ebay hoping it had a genuine Neo-M8N module as the Galileo Sat sytem had recently gone live and I thought that would be fun to play with. Anyway it wasn’t genuine module inside, but hey thats fea-bay for you and no big deal it was still a functioning Sat Nav Module which output a serial signal. Now the phrasing for the Neo-M8N module is slightly different for the phrasing most GPS units so although it should have been fine with the TinyGPS++ libary I discovered it was not. But I also discovered someone who had come accross this before and Modified the TinyGPS++ libary to fix the phrasing

Check out:-

I tested in on an Arduino UNO and it worked nicley with my fake Neo8 and it should be possible to port over to the Particle platform and ultimately the Electron. Although it was not a genuine Neo-8 it was packaged nicely.

So this is were it all started to fall apart. I noticed that the Particle Libarys included the TinyGPS++ libary and started there, on a core to get a working model before moving on the electron. No joy. I’d try flashing the core and sometimes it would flash, and others it would time out. Other times the Web IDE and the console would report it was online but it would be sat next to me quickly flashing green for a while, pausing blue, and then quickly flashing green. The only way I could get over this was to reset all the wifi credentials. Then I noticed that I could only do this using the CLI and Particle Setup over usb. The Spark android app was not working (But I’d had issues with that before). I managed to get the core back online, but I did notice that whilst in the claiming stage of resetting the Wifi credentials it never completed that task. But I have its credentials estabished and it started working again. This I discovered the at time it really would take and age to be able to flash, and some times I was not sure that it was. So I wrote as simple bit of test code:-

int count = 0;

void setup() {
    //Particle.variable("Counter", &count, INT);
Particle.variable("Count", count);

void loop() {
count = count+1;
Particle.publish("Count", String(count));
Serial.println("Count test New Firmware ");

Now I could monitor the flash functioning and by chageing the text in the Serial.println, know I was infact recodeing the core. On serveral occasions it did not update the core, although the web IDE reported that it had.

The the core would start forgetting Wifi credentials as I moved between work, the London Hackspace and home.

So having estabished that the core was not performing, the project got put aside again, as it was taking too much time just to get a stable platform before I could try to debug/modify the libary.

Then I returned back to my project, and found to my dismay whenever I flashed one bit of code to the core, I got the fast flashing green light treatment, but I was able to flash the same core with a blink test routine as often as I liked. I eventually figured out that flashing this code:-

#include <TinyGPS++/TinyGPS++.h>
//#include <SoftwareSerial.h>
//#include "application.h"
   This sample sketch demonstrates the normal use of a TinyGPS++ (TinyGPSPlus) object.
   It requires the use of SoftwareSerial, and assumes that you have a
   4800-baud serial GPS device hooked up on pins 4(rx) and 3(tx).
//static const int RXPin = 4, TXPin = 3;
//static const uint32_t GPSBaud = 9600;

// The TinyGPS++ object
TinyGPSPlus gps;

// The serial connection to the GPS device
//SoftwareSerial ss(RXPin, TXPin);

void setup()
 // delay(2000);
 // Serial1.begin(9600);

  Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
  Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
  Serial.println(F("by Mikal Hart"));

void loop()
  // This sketch displays information every time a new sentence is correctly encoded.
  while (Serial1.available() > 0)
    if (gps.encode(
     // Serial.println("loop");
  if (millis() > 5000 && gps.charsProcessed() < 10)
    Serial.println(F("No GPS detected: check wiring."));

void displayInfo()
  Serial.print(F("Location: ")); 
  if (gps.location.isValid())
    Serial.print(, 6);
    Serial.print(gps.location.lng(), 6);

  Serial.print(F("  Date/Time: "));
  if (

  Serial.print(F(" "));
  if (gps.time.isValid())
    if (gps.time.hour() < 10) Serial.print(F("0"));
    if (gps.time.minute() < 10) Serial.print(F("0"));
    if (gps.time.second() < 10) Serial.print(F("0"));
    if (gps.time.centisecond() < 10) Serial.print(F("0"));


ALWAYS resulted in the green light death if I used firmware 0.6.1 on a core, but 0.3.4 was safe-ish.

Then I discovered that I could no longer edit the libarty in the IDE. In the past I has used libarys, and if I used them the libary code would apear as tabs in my IDE, and I could edit them, but not now… for some reason. And thats when I got to the point I’m giving up…

Ok, If you have kept up this far, this is my conclusions.

I’m a mechanical engineer, so I’m not stupid, I can problem solve, if not spell.

The Partical is a fast evolving platform, so here is a tip to myself. Its a good idea to write which firmwear you initially wrote and tested your code in and on what device. I have discovered code I wrote a while back is broken becasue of firware updates.

Libarys (I know can be useful, and Code junkies are going to hate me for saying this) are unreliable, they often do not follow development as core-code might. As they are written by someone else, the flow can be difficult to follow, when you try to debug or deconstruct it. At least in the days for Fortran we include all our subrouines in the code, so it followed the programe development. I’ve lost count the number of times I’ve watched a Code-expect look thought someone elses libary with disdain, I think they have only been polite when they have looked at my kiddie-code. I’ve never been sure who the real experts have been. Mind you the look on their faces when they discovered that there is an M6 fine and and M6 course thread (for our American readers subsitute UNF and UNC)…

Of particualr point to make the existing TinyGPS++ libary in its examples uses softwear serial, which is not supported on the Partical platform as far as I can tell. So there must be a tonne of people banging their heads on that one. So why is it in the Libary in the first place… It’s been there a while…

Yes abandoning the Core and pulling out a photon would make sence. Even the suggestion of re setting the core as is apparently suffers Old-timers desiese. I take those points on board. But I like the fact the core has TX and RX written on the pins… Yes I can use which ever pins in the photon, but I have to keep looking it up…

Anyway thank you for your attention, your thoughts and letting me throw out my thoughts…

Kind regards



I can sypathise with you on most of your points and I’m sure we can figure out a way forward for you, but for that …

… I think you must remember wrong. That was never possible in Web IDE. What you may remember is that once you found a library that had issues you could “peek” the library in read-only mode and thus copy/paste the code back into your own project into their own file tabs and then edit that.


I’ve written a library to fill that gap (ParticleSoftSerial) but the TinyGPS++ lib was contributed before that and hasn’t been adapted for that since.


Ok, I am now finally giving up.

I decided to update my CLI on all three of my PC’s one of which was my workhouse machine even though it was still running XP, and try a new photon.

I checked my system by ensuring a photon I had previoulsy set up (it was headerless so no good for my project at hand, but first let just test things are working). It was working and I could flash to it. However I could no longer get it to use USB mode on my windows machine, becasue try as I might it will no longer see the USB driver for it.

Anyway, put that aside, pull out a NEW photon, and use a windows 7 machine to set it up on my wifi. No joy. It will not using the android app or the CLI on a windows 7 machine see the cloud after even though the prevoisly configured photon can see the network and cloud no problem.

I included the process below, but I think its time to give up on this whole particle platform. Its a mess. I suspect becasue it been broken by improvements.

Thanks for those how have offered help but bye.


C:\Users\Cyber>particle setup
 _ __             _   _      _
| '_ \  __ _ _ __| |_(_) ___| | ___
| |_) |/ _` | '__| __| |/ __| |/ _ \
|  __/| (_| | |  | |_| | (__| |  __/
|_|    \__,_|_|   \__|_|\___|_|\___|

> Setup is easy! Let's get started...
> It appears as though you are already logged in as
? Would you like to log in with a different account? No

! PROTIP: Hold the MODE/SETUP button on your device until it blinks blue!
! PROTIP: Please make sure you are connected to the internet.

> I have detected a Photon connected via USB.
? Would you like to continue with this one? Yes
! The Photon supports secure Wi-Fi setup. We'll try that first.

! PROTIP: Wireless setup of Photons works like a wizard!
! PROTIP: We will automagically change the Wi-Fi network to which your computer
is connected.
! PROTIP: You will lose your connection to the internet periodically.

! PROTIP: Some computers may require Administrator permissions for my automagica
l Wi-Fi scanning capabilities.

! OOPS: I was unable to scan for nearby Wi-Fi networks (-___-)

? We can still proceed in 'manual' mode. Would you like to continue? Yes

! PROTIP: Manual mode will prompt you to manage the Wi-Fi connection of your com
puter when it's necessary.
! PROTIP: To proceed, you will need to be able to manually change the Wi-Fi conn
ectivity of your computer.
! PROTIP: Your Photon will appear in your computer's list of Wi-Fi networks with
 a name like, Photon-XXXX
! PROTIP: Where XXXX is a string of random letters and/or numbers unique to that
 specific Photon.

! PROTIP: You will need to know the password for your Wi-Fi network (if any) to
! PROTIP: You can press ctrl + C to quit setup at any time.

> Obtained magical secure claim code.

? Please connect to the Photon's Wi-Fi network now. Press enter when ready.

> Now to configure our precious Photon

! PROTIP: If you want to skip scanning, or your network is configured as a
! PROTIP: non-broadcast network, please enter manual mode to proceed...

? Would you like to manually enter your Wi-Fi network configuration? Yes
? Please enter the SSID of your Wi-Fi network: Photon
? Please select the security used by your Wi-Fi network: WPA2
? Please enter your Wi-Fi network password: photon test
> Here's what we're going to send to the Photon:

> Wi-Fi Network: Photon
> Security: WPA2
> Password: photon test

? Would you like to continue with the information shown above? Yes

> Obtaining device information...
      throw er; // Unhandled 'error' event

Error: connect ETIMEDOUT
    at Object.exports._errnoException (util.js:874:11)
    at exports._exceptionWithHostPort (util.js:897:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1063:14)


Having never been too fond of particle setup (for the reasons you’ve encountered), would you be willing to give particle serial wifi a shot?


Hi Moors

But it always been the saving grace of any problems. If I ever encounted problems all I had to do was put it in to listening mode run spark or particle setup and hey presto manually enter my wi-fi and bobs your uncle back up and running.

Since I updated CLI today, it become alot more complicated. It seems to think its running on a computer with a wi-fi interface, which desktops only do if your being too cheep to use a bit of ethernet cable. Wi-fi adaptors are really flackey. So I use a proper network cable and this is the first time in 25 years thats a disadvangate…

Although the particle setup has tried to do a manual set-up, after failing to do a wifi to wifi set up, I suspect it is badly writen, and not tested.

Like I keep saying why have they broken what worked?

I’ll have a gander at serial wifi but I have this dread in my soul.



Hi Moors7

Well I gave ‘particle serial wifi’ a shot, but it is now just sitting there frozen:-

C:\Users\Cyber>particle serial wifi
? Should I scan for nearby Wi-Fi networks? No
Attempting to configure Wi-Fi on COM3

Solid blue light.

Thanks thoughts…



Hi Moors,

I gave it a second go:-

C:\Users\Cyber>particle serial wifi
? Should I scan for nearby Wi-Fi networks? No
Attempting to configure Wi-Fi on COM3
Serial -> SSID:
? SSID ****
Serial <- ****
Serial -> ****
Serial -> Security 0=unsecured, 1=WEP, 2=WPA, 3=WPA2:
? Security Type WPA2
Serial <- 3
Serial -> 3
Serial -> Password:
? Wi-Fi Password &&&&&
Serial <- &&&&&
Serial -> &&&&&
Serial -> Thanks! Wait while I save those credentials…
! Something went wrong: Serial timed out

Oh well.



Hi @VideoLiam sorry for your troubles here. You might have some old code or user code on your Photon that’s interrupting things. I would suggest checking the CLI version to make sure it’s updated to 1.20.1. Check with command particle --version Then proceed to put the latest firmware on your Photon before running the setup steps.

Use DFU mode on your Photon and run
particle update

DFU mode again and
particle flash --usb tinker.

Then erase all credentials (press RESET and hold SETUP for > 10 seconds until it blinks blue fast)… and try again with:
particle serial wifi


I have to agree with you. I developed an app with the photon about a year ago, the experience was great. Having just worked on a project with the electron, it was a much less pleasant experience.

  1. CLI is now a necessity. Which raises it’s own issues, as there are issues getting it installed. Documentation on what to do and installing is not in one place, and you have to dig to find it if you want a complete working installation.

  2. Firmware updates. Found an installer to update the firmware, but not to latest. To get to latest, needed to use CLI and locate the firmware update instructions, or you end up using the installer and then cli. Not sure why we can’t just have a working installer for the latest.

  3. Documentation is scant, incomplete and split up over various locations.

  4. Referenced documentation is often absent.

  5. Basic information to get started with the device requires digging into forums.

It’s great that the community helps, and products evolve over time but ultimately, these devices aren’t cheap and are supposed to be easy to use. If you’ve evolved with the product overtime, you’re not going to see a lot of this, but for people new to the product, it’s become a messy process out of touch with the simplicity of the product.

It’s time to take a look at it, and for each product and kit that sell, write an up to date getting started guide working through the complete process of getting all the tools installed and getting the first blinky LED project working, or asset tracking project working etc.

Much of it would be better, with better tools, but that aside, document it well and provide best practices. What could be a 1/2 hr getting started process, is more like 1-2 days now to get everything figured out.

And I come from a unix development background, I can get through this stuff, but it is irritating.


You raise some fair points, and most of them are being worked on, or at least planned to be worked on.

Not sure either, there should just be one. That’s something that needs updating for sure.

Could you give us some examples of this. Documentation is never complete, but this would give us some ideas as to where to look for improvements. If you feel like helping out, you could make edits to the docs and make pull requests. If not, you could still open issues on things you think could/should be improved. Again, it helps to know where to look as it’s hard to see missing things when you’ve been here since the beginning :wink:

The same as above, examples would be great, so we can take a closer look at that.

Same same. What have you been missing, and what areas in particular could use some extra love and attention?

At the very least, thanks for your input and possible suggestions, and sorry it hasn’t been as pleasant as you’d hoped it to be thus far. If I can speak in favor of Particle, I can assure you they’re working very hard to improve, of all aspects of the platform. They’re still a relatively small team, so some things take a bit longer than preferable, but they’re doing as much as they can to improve. Input like in these topics is thus invaluable to know where some extra attention might be needed.


First, I want to say that I think the Electron is an awesome product. I’ve got a bunch in the field that I am happy with and they are mostly performing up to my expectations. I can’t wait for an industrial castellated edges (or similar) version.

In reference to your question regarding documentation, I think there are large chunks of missing documentation on this page:

Especially in these locations:

  • PMIC
  • Fuel Gauge
  • UDP – specifically a complete example of how this should work in a robust way (calling udp.stop(); was key for me)

Also missing docs that would be nice to see:

  • How to use “safe-mode-updater” for Electrons that aren’t part of a product
  • An authoritative guide from Particle on how to avoid physical resets of devices
  • Intro to firmware and “wiring” testing and what Particle recommends for this

Ultimately referring back to the actual firmware repo at github is helping me get through these issues.