The most frustrating dev board ever

Troubleshooting
1

I apologize for this rant, but I was really looking forward to working with the Photon but it’s tried my patience to the max. I am happy to hear from people that can point out what I’m doing wrong and I hope Particle is listening.

I bought the Photon because it was a cheap wifi micro that (I thought) would work well for an RFID timeclock project I want to make. I’m an experienced engineer and have done C as well as assembly embedded programming. I’ve used many dev environments before.

Needing to install an app on my phone just (and only just) to “claim” a photon is a pain. I don’t install apps willy-nilly like most people. Fortunately you only really have to do it once. Ok, I can live with that. I used an old phone. The claiming process was without it’s hiccups, but I got it going.

While the documentation seems to be fairly robust, It took me WAY too long to figure out that what I was looking for was an expanded menu under “Firmware” (on this page https://docs.particle.io/reference/firmware/photon/). Why would you call the language reference “Firmware”. I didn’t click on it because I assumed it had firmware files. Because of that I didn’t look at it hard enough to notice there was a little plus sign over on the other side that would expand it. That was only the beginning of my frustrations.

The web IDE UX around loading projects is wonky and not intuitive. The slideout when you click the <> is just too busy and has too many different aspects. The whole including libraries vs adding them is not clear at all. My first project I think I just include()ed it, but the library did not show up in the file tabs at the top. In another project I somehow added them to my actual project.

Several aspects of the UI are blocked by Chrome overlays. If you have the Chrome find box open, it covers the “add file” plus sign. Another thing that took me forever to find because it was hiding. The compile status is partially blocked by the URL preview at the bottom left of the screen. I’m still unclear if I have to click verify before I flash or if flash verifies, compiles and flashes. I have been clicking verify first, so I hover over flash before verify is done, bringing up the URL preview at the bottom, blocking the status.

And that brings me to the actual Photon. If I’m really lucky, after a flash the thing, it will connect (breathing blue) in 10-15 seconds. That happens about 1 in 20 flashes. Most of the other time it takes 1-3 minutes. It sits there alternating between really fast green and fast green. The Wifi AP is less than 10 ft away and I even put an external antenna on it. Didn’t help at all. It is INCREDIBLY frustrating to have to wait 3 minutes after every little change.

To make matters worse, the USB serial port stops working on every flash. This causes putty to close. I have to hard reset it (and sometimes unplug it completely) after it’s flashed and restart putty. How does anyone get anything done? I was using the TX/RX as a serial port which works better because Windows doesn’t see the USB drop, but it’s now connected to the RFID module so I have to use USB.

Now I’m battling an issue where the httpclient example works, but my derivative code (even though I didn’t change the library) seems to be missing the HTTP response headers so it comes back as result code -1.

Maybe I’m the only one with these issues, but I would not have the patience to use this platform for anything but the simplest of projects. The development flow is just way too clunky.

-Mike

2

Hi @turbo2ltr,

Well yes you are correct that the Web IDE is very clunky.

Have you tried Particle Dev? It provides many more features over the Web IDE.

You can flash firmware over USB using dfu-util instead of flashing over Wi-Fi by using particle-cli.

You can claim photons using particle-cli as well:

$ particle setup
4 Likes
3

Hey there @turbo2ltr – my name is Will, and I just wanted to thank you for providing honest feedback on the experience you’ve had with our developer tools so far. It sounds like it hasn’t been the experience you were hoping for, so I’m thankful that you took the time to provide so many examples where we could improve.

Regarding each opportunity you cited where we could improve:

Setup
We agree that mobile setup can be a pain. Native mobile setup is difficult to maintain as a small team, especially because there is enough variation between Wi-Fi environments without adding additional complexity of different versions of mobile operating systems, especially with Android. Our Android app has a bunch of known issues, but we’ll be releasing a new version in the next 2 weeks that should address most of the setup issues you might have run into.

Our setup process using the CLI is pretty good, and in general we recommend the CLI for pro users like yourself. We’re also launching a beta version of browser based softAP setup in the next 2 weeks that we intend to become the new default setup process for the Photon.

Documentation
Sorry you had trouble finding the Firmware API reference documentation. Because we have both firmware and Cloud APIs for developers, we tried to differentiate them by the part of the stack they live in. Good feedback on expected vs. actual labeling.

Web IDE
The Web IDE is one of our first and oldest developer environments, and there’s definitely room for improvement. We’re continuously trying to bring the development experience there more in line with our Desktop IDE and CLI, and agree that the navigation could use a facelift. Expect to see steady progress here over the next several months.

Photon connectivity
The reliability of the connection is an area where our platform usually shines. if you’re seeing stability issues with your Photon, please reach out to our Customer Support team who can help diagnose any issues you might be having and help with a replacement in the event that there’s a problem with the hardware.

USB serial
We’ve got a quick fix for this one! If you download the Particle CLI and use the particle serial monitor --follow command (a community pull request!) it will automatically recognize when your device comes back online and restart the flow of serial commands.

Thank you again for such a comprehensive summary of your frustrations. We’re a very small team of engineers trying to provide support for a wide variety of development interfaces, SDKs, documentation, and cloud infrastructure but actionable feedback from customers is what helps ensure we continue to point our efforts in the right direction!

If we’re not where you’d like us to be today, I hope you’ll revisit our tools in 3-6 months to see the progress we’ve made. Cheers from Particle!

7 Likes
4

Hi @turbo2ltr,

I personally do not use any of the tools you mention for my professional Photon development. There is also no need to “claim” if you are not using the Particle Cloud features.

If you are experienced, please head to https://github.com/spark/firmware and compile/deploy locally as described there. You can also use the programmer shield then to debug with openocd/gdb. I personally use Eclipse as IDE - not to compile (although that can be set up) but only to write the code. The indexer/autocomplete of Eclipse is excellent even without a fully setup toolchain.

Let me now if you run into issues.

1 Like
5

I pretty much use Atom and po-util exclusively when developing with Particle, using particle-cli to do cloud stuff and interact with devices over the internet.

po-util is a tool I created for expediting the installation and use of the local toolchain on macOS and Linux.

1 Like
6

Thank you everyone for your replies! I will most certainly check out the alternative tools. It sounds like using them will provide a much more familiar and less frustrating dev cycle.

Will, thank you for your comprehensive reply. I speaks volumes about the company.

Since I posted this, I moved the unit to my office. I have pushed a few updates to it and I have not seen the long reconnect time yet. But I have another connectivity issue I’m battling. I will post in a different thread.

Thanks again everyone, I look forward to trying out the other tools mentioned here.

-Mike

6 Likes
7

The long connect time could be due to how long the Wi-Fi access point takes to provide an IP Address. Currently the device will wait 7 seconds before retrying. This is what happens when the device LED blinks fast green after the slow green blink. So if the access point takes longer than 7 seconds to provide an address, it may not connect.

We are considering lengthening the timeout and/or making it configurable.

2 Likes
8

Wow, po-util looks really interesting. I’m gonna check it out. Thanks for creating it!

1 Like
9

Well I installed the command line tool. That was pretty easy to get the device connected and registered this way… Unfortunately it then bluescreened my computer and stayed in a blusecreen boot loop until I disconnected the photon. I promptly uninstalled the CLI tool.

10

@turbo2ltr, what operating system are you using? I have never had nor ever heard of the CLI causing a blue screen!

1 Like
11

Win 7.

This computer has never blue screened since I did a fresh install a few months ago, and runs 24/7. I was already hesitant in installing the CLI and this is exactly why I try VERY hard not to install stuff I don’t absolutely have to. I need to get a good VM machine up and running for stuff like this.

This is what I did.
Used the CLI to set the Wifi
Used the CLI to get the device ID
Used the CLI to add the device.
Once I did that it showed up on the online portal and I renamed it on the portal.
I was powering it from my computer so I left it plugged in and then flashed it from the web IDE with the Sparkfun MicroOLED example program.
It was during the flash, or after the flash while it was rebooting when the computer bluescreened.

Only time will tell if it was related or just an unfortunate coincidence.

12

I’m not sure if this actually is an issue with CLI.
My Win7 machine did sometimes hang on bootup when I had the Photon (or even some USB thumb drive) plugged in.
There also were issues with Photon sketches that hammered the USB Serial too violently which caused troubles with the mouse pointer or other issues.
These were actually Win issues but got triggered by the Photon (or other devices behaving similar - e.g. Teensy).

13

@turbo2tlr, By any chance, do you have other USB device drivers installed on your machine? Windows USB drivers are notoriously flakey, which is why zadig came into existence in order to get good USB drivers onto windows machines. Anyways, another custom USB driver might be reacting badly with the Photon.

I also use Win 7. I also had issues with connecting over USB. At one point my mouse stopped working. Clearing out old USB drivers that I no longer needed and getting the latest USB drivers (borth normal and DFU mode) from zadig was my solution. However, it never got as bad as the blue screen of death in my case.

14

Not sure if you mean in general...if so then, of course.

Computer has been operating fine since uninstall.

A little update..
My second Photon did not have the connectivity issues after flash like the first one. It very reliably reconnected after a flash.

The first Photon has been running my program (no dev) at a different location without too much issue. (RFID punchclock) Adding the server heartbeat seems to have helped a lot, though it's not perfect.

With this second one, I have added the Sparkfun OLED screen and expanded on the code to show some diagnostic info about the httpclient. I have optimized some of the code in the httpclient (there is a forced 200ms delay for some reason) and have also identified the program path in the client when the connection fails. Though it's rather intermittent so hard to test.

New version doesn't quite fit in the box like the old one did..

20170327_121115.jpg4032×3024 2.46 MB

15

@turbo2ltr,since I am also using Windows 7, I will explain what I went through with USB drivers.
My first install of drivers was using the npm command, which it turns out did not work correctly. I later tried an npm update of the drivers, which did not help.
I then went to zadig and installed the USB driver and then my mouse stopped working. At some point along the way, I tried the windows install for the CLI without removing previous installs. Then I went through the Windows device manager and removed the particle drivers, zadig drivers AND all other USB drivers that I no longer needed. I kept only the bare minimum USB drivers plus drivers for USB memory sticks that I still have.
After that, my mouse started working again. At that point, I tried the windows installer for CLI (which by this point was a newer version) and it then worked successfully. I no longer remember whether or not I then had to install the DFU driver from zadig.

I think the key points might be:

  • remove all unnecessary USB drivers
  • make sure any particle CLI, DFU and drivers are removed
  • install using the windows installer (not using npm)

Hope this helps!