[Solved] *Still* unable to update my Oak

[Nilz]

Hi everyone, I've been having issues updating my Oak ever since I got it. I've just now tried to update it again, but no dice. Here's what I did:

• I tried to update it with my linux laptop, when filling in the AP details it went "saving settings to Oak", but never proceeds to do anything.
• Tried updating with my Android phone: connects to the Acorn AP, but the configuration fails to connect to the Oak: "Unable to connect to the Oak".
• I then tried to change all my WIFI settings: different channel, lower speed, only Wifi B, enable guest network without security, same effects.
• I downloaded the local update server and ran it on my linux laptop. My phone still is unable to connect to the Oak, so I try my desktop PC but the result is the same: "Unable to connect to the Oak"

I like the idea of OTA updates, but come on, at least give the option to update the firmware via USB or something if the OTA fails. I know I'm not the only one.
So, does anybody have an idea on what to try next?

[PeterF]

Hey there Nilz... looks like you have a stubborn 'lil sucker. You've done pretty much all the wifi update troubleshooting that has been recommended... and it's still not being co-operative. I'd try a couple more times with Wifi B, guest mode, any wifi channel but 1, and trying to run SoftAP on your phone. Make sure you're not too close... proximity is NOT a good thing with RF stuff. Make sure the Oak is at least a meter away (more is better) from your router, and your phone is also more than a meter away (otherwise the RF/wifi signal may be getting swamped). I usually connect with an android tablet, and it configures more reliably than with a windows box. The trick I've found is to connect to the Acorn network, and then wait for about 20 seconds before moving on with the SoftAP configuration - it seems to take a little while for the wifi to fully negotiate and settle down.

If it's still playing up, the best option now is to just forcibly install via serial. You'll need a USB to serial adapter if you don't have one, and it needs to have 3.3v logic levels. I recommend the CH340-based ones, which you can buy for as low as US$1!!

Hope that is of some help, and let us know how you go!

[emardee]

I echo the suggestion to get one of those usb serial interfaces. They are so cheap, and will help you if you have problems in the future too... so get one ordered ASAP and then it can be in its way to you whilst you try Peter's other suggestions.

Good luck.

[Nilz]

We have liftoff!

Thanks guys. I didn't know the Oak could be updated via serial. Once I tried that, it worked, it connected and it now shows up on the Particle Build site.

[PeterF]

Yay! Just be warned that AFAIK, Particle Build is good at bricking Oaks atm - every time I've tried it (including 5 minutes ago!) it bricks the Oak being programmed, and it needs to have it's firmware restored again via Serial.

[pkourany]

Yay! Just be warned that AFAIK, Particle Build is good at bricking Oaks atm - every time I've tried it (including 5 minutes ago!) it bricks the Oak being programmed, and it needs to have it's firmware restored again via Serial.

Peter, I believe Wojtek at Particle is waiting on the Oak team to supply a fix for the Particle IDE.  Are you part of that?

[PeterF]

No, I'm not. I just saw the rely back from suda on the Particle forum, so at least I know we haven't been forgotten. Ok then, so the current state of affairs is Redis ran out of memory, and b0rked the Particle Build compile/verify process for a while, and has been resolved for now. So we're back to the 'one-click-to-brick' feature! That sound about right?

[JohnP]

Count me in on the "still having problems with initial WIFI based registration and serial reflash journey through hell" team...  I hope this trip report helps someone else...

One of my 10 Oaks (the first I tried, of course) worked exactly as expected.  I've developed an interesting model railroad CTC and field unit based control system using WIFI/MQTT as a code line; it runs on Oak, Photons an raw ESP8266's with I2C peripherals.

Now it is time to deploy the rest of the Oaks out to the layout, and I'm stuck: The other 9 Oaks are FAILing 100% of the time to do the IOS wifi setup dance (stuck in 'Saving settings to your device...'), even after using the serial process to re-flash the firmware.

[Edit:  in desperation, I gave up on the iPhone and tried the digistu.mp/oakconfig URL on my Mac, where things "just worked".  Even the 'remember my credentials' nit I mentioned below are handled...  Is this a IOS -vs- MacOS issue? ]

For those on a similar journey, I got stuck with an esptool error(A fatal error occurred: Invalid head of packet) with multiple Oaks, using several prolific USB adapters.  The tool Connected, erased and then got stuck writing at random percentages - between 30 and 60, always at about the 20 second time mark.  The Oak simply stopped responding and needed a full power cycle to do anything else.

This ESP8266 thread (http://www.esp8266.com/viewtopic.php?f=6&t=2791&start=20) shed a clue - apparently there is a brownout issue with programming large blocks and cheap usb power sources.  The esptool "fix" that worked for me is to reduce the buffer sizes to lessen the power consumption duty cycle:

• Edit esptool.py so that:
  ESP_RAM_BLOCK = 0x180
  ESP_FLASH_BLOCK = 0x40
  

Unfortunately, even with the new firmware, the IOS Oak WiFi Config program STILL hangs forever on the "Saving settings" page...

Help!  There has to be a better way!  I've got a 90% failure rate using the iPhone/IOS web app!  [Edit:  using MacOS and Chrome, things worked quickly and correctly...] 

There are some medium sized bugs in the web claim-a-device tool itself:

• IOS: The web "app" should have a way to remember my particle info and my local wifi info between runs (cookies?) - 10x devices times dozens of retries to get the process to work = bad usability.
  
• The list of SSIDs shows duplicates - 1, 2 or even 3 copies of my home SSID show up on the list - something is caching things and not filtering dups
  
• The browser's back button doesn't restart the app when it hangs - I need to reload it from the digistump site every time.  See the usability comment above...
  
• Please, someone with wiki edit privs, please fix the http://digistump.com/wiki/oak/tutorials/serial_through_arduino page !!!
  

[PeterF]

Whilst I don't know much about the coding of the SoftAP config app, and can't do anything about that, I do agree that usability when there is problems or multiple devices to provision isn't the best!

As far as issues with one device or another, the general consensus appears to be that PCs/laptops are problematic, whereas phones and tablets appear to be more compatible. A lot of it has to do with the specific wireless setup - wifi channel clashes, proximity (being closer is not a good thing, exactly the opposite in fact)... annoying little things like that.

The best way to power the Oak when using the USB-to-serial adapter is to power the oak properly via the microUSB connector - you only connect GND, TX and RX from the adapter, thus the Oak remains powered via the stable USB supply.

What specifically is wrong on the wiki page? Can't fix anything if we don't know what is fixed. And whilst I didn't write anything on that page, I think the user who wrote the warning on the top went over the top a bit... as the diagrams he's saying are wrong are indeed right... as per the third way of representing voltage dividers as per the illustration in the sparkfun guide. However, it probably isn't the best, as it can confuse when written that way, as new users don't realise you attach between the resistors.

Regardless, any feedback and ways to improve are welcome. And, btw, since you are registered on the forum, you can also edit the wiki... that is all that is needed to edit it (thus a community effort!)

[JohnP]

Thanks for the wiki-edit note, I'll give it a try