Oak is not connecting my home ssid

[Ultiman]

no luck for me

same problem has before

[gkelly]

No luck for me either.  The SoftAP configuration page just shows "Your Oak failed to download the update. Please power cycle your Oak, reconnect to its AP [...]".  I'm going to try to attach to the UART to see if there's anything helpful debugging-wise there.  My WiFi configuration is an Asus RT-N66U in WPA2 mode.  I also tried to download the update by using the hotspot on my Nexus 5X.  This actually looked like it might work (I saw the fast-blinking pattern for the first time, it's ~5Hz if you're wondering if you've seen it) but the end result was the same.

[werner]

I've configured 5 Oaks up to the point where they connect to the Particle cloud and can also be programmed with some example sketches.   But it took a lot of patience and many retries to get to this point.   And one of the five stopped connecting to the Particle cloud completely.  I tried to unbrick it (which kind of worked with the LED flashing as expected, except that it does not show up as a WiFi APN anymore).   I also tried to resend its device id via serial cable, but that did not work either.   So for now I've put that one unit to one side and just using the other four to play with for now.  Maybe with the next firmware release I will re-attempt to revive it.

[PeterF]

I had issues getting any Oaks to register on the particle cloud after connecting to my normal home AP (router). I ended up connecting via a portable AP (filehub), and then was able to get them to update and register on particle (the particle registration appeared to be the biggest issue). After doing that, and uploading a blink program, I was able to turn off the AP, and when SoftAP went into failsafe mode and started the configuration process up again, I was able to connect to my normal AP, and then upload another blinky sketch, which they have been happily running for about 20 hours now.

Hope that helps narrow down the problem / helps someone else out.

Pete

[claudiuo]

I keep reading these forum posts hoping I'll get some advice and there are plenty of ideas but nothing seems to work for me. Since I got my Oaks more than a week ago I tried to download the firmware on 2 of them, used 2 different routers at home, tried at work, moved the Oaks away from the routers, tried to use my Android phone as a hotspot (I see the Oak connecting and then it disconnects) - nothing seems to do it. I've seen the LED blink fast quite a few times, sometimes for 4-5 seconds, a couple times about 20s but in the end nothing. What else can I try?

Please understand that this is not a complaint addressed to Erik. He is one of the few on kickstarter that goes above and beyond trying to have a smooth campaign and to make sure his boards work as they should; even after these Oak issues, I would still back any new projects he comes up with in a heartbeat. I am just trying to figure out what to do next.

Keep trying everyday maybe it will work - did anyone go this route and eventually it worked?

Get one of those serial boards and try the OakRestore way - I am worried I may brick my Oaks but if it worked for many people, I would try it.

Wait until later when things will be more ironed out?

Are there any other ideas I may have missed?

I know most of these questions are rhetorical, I am really not sure what to do and trying to find answers from anyone that was able to make the Oaks work in the end... Thanks in advance for any thoughts that could help.

[werner]

Keep trying everyday maybe it will work - did anyone go this route and eventually it worked?

That's more or less what I did.  Some of my boards connected quickly to the Particle cloud.  Others  took many attempts but it eventually worked.

Get one of those serial boards and try the OakRestore way - I am worried I may brick my Oaks but if it worked for many people, I would try it.

I think part of the problem is that people confuse a working app with with bricking.  You must remember that once you load your own app, it replaces the existing initial base one.  So the LED might not flash anymore and it may no longer be visible as a WiFi AP anymore.  But that does not mean its bricked.  It just means your own app is running.  (This concept confused me also in the beginning.   

But having said that, I have no doubt that at at least two of my Oaks really got bricked but I can at least confirm the serial unbrick method worked for me .  I've done it several times.

Get one of those serial boards and try the OakRestore way -

I highly recommend it.  It is also invaluable to me as a debug tool as well.  (I can't imagine trying to work without a serial debug output on this)

You can also just get a FTDI USB to TTL cable like this one I use:
http://www.dx.com/p/ft232-to-usb-ttl-wire-integrated-terminal-cable-for-programmer-black-95cm-203717#.Vrr7L1nhNaQ

Wait until later when things will be more ironed out?

I think once you can get past the problem of connecting to the particle cloud, then loading your own apps onto the Oak works quite reliably.  I have no doubt things will become more stable over time, but its quite fun to get into the thick of it already.

One thing I think would have helped a lot of Kickstarters is better documentation that is a bit more chronological and logical.  Instead I find it a bit all over the place with little bits on all kind of places.   I think I probably wasted several hours just wading through everything to form a good understanding of what I actually needed to get started.  This is also not a criticism to Erik, but I think if he anticipated that new enthusiastic backers will get confused by things that is not documented well before shipping the rewards, then it would have saved himself and lots of the backers lots of time and frustration.   

The product itself is quite remarkable and I'm still very happy I backed it.   And I'm thinking of nice things to do with them all the time.

[digistump]

I think part of the problem is that people confuse a working app with with bricking.  You must remember that once you load your own app, it replaces the existing initial base one.  So the LED might not flash anymore and it may no longer be visible as a WiFi AP anymore.  But that does not mean its bricked.  It just means your own app is running.  (This concept confused me also in the beginning.   

But having said that, I have no doubt that at at least two of my Oaks really got bricked but I can at least confirm the serial unbrick method worked for me .  I've done it several times.

I want to clarify part of this: An Oak has 3 rom slots, one holds your Config rom, one holds your User rom (what you upload), the other is empty. When you upload a new User rom or a new Config rom (due to an update), it goes to the empty slot and once confirmed complete and good the pointer to that rom is changed to point to that slot.

If you think you've totally bricked it - I really really would love to get a copy of the sketch and/or bin file that did that to confirm if it was in fact a brick, and if so, to ensure that we have a failsafe to get you out of it without a serial adapter.

Thanks everyone for all the testing, do know that even if time limits how much I respond to at any given time, I am reading this all and shaping what I try to fix next based on your feedback

[digistump]

I was finally able to replicate the update issues reliably - specifically they seem to involve fast connections allowing the device to download data so fast that each loop to write the data to the Oak's memory goes so fast that it outpaces the Oaks ability to erase the next block of memory before writing it. (This bug seems to possibly have some deep roots in the chips internal libraries).

I was not able to reliably replicate this previously because, being in a rural area, my internet connection is slower than many (1.5mbps on a good day) and all of my local testing was done with extensive debugging output turned on, which slowed down the loops enough to prevent this from showing up. Stripping my debug output down significantly and ensuring no output occurred during the write/erase loops, while also hosting it locally within my network allowed me to reproduce the issue 100% of the time.

My fix is to have the web server send only one sector worth of data every 50 milliseconds. This results in a total time of at least 150ms per sector, which seems to fix this issue. I've tested it locally and remotely with 100% success.

This fix is live and you can test it by retrying the update (no changes to the Oak or Config App needed).

If the update still fails to work then please download the newest OakRestore here (https://github.com/digistump/OakRestore) and follow the instructions to provide the debugging output so we can look into it further, as this very well could be one issue of several.

(Sorry that's very long winded as I'm copying the text from a Kickstarter update I'm preparing, but seems worth posting here)

[claudiuo]

Thanks a lot, @werner for your reply. I still didn't have any success but I will keep trying. As you suggested, I am trying every day with both my Oaks but until now nothing. All I get is fast blinking (starting anywhwere between 45-50 seconds on the countdown timer) that lasts to approx. 20-26s on the countdown. Then slow blinking again and a report that the download was not successful.

I highly recommend it.  It is also invaluable to me as a debug tool as well.  (I can't imagine trying to work without a serial debug output on this)

I ordered one of those boards now waiting patiently for it to arrive slowly from China.

I see Erik said he may have found the issue, unfortunately it didn't work for me but as I said, I will keep trying.

Thanks again for all the suggestions.

[starwolf73]

@Claudiuo, please see my post. It may help you resolved some issues. http://digistump.com/board/index.php?topic=2046.msg9239#msg9239