Does the Oak have a future??

[postuma]

So - there's much I love about my Oaks - but they can be a major PITA to initialize - in some cases it's taken me hours. I don't think any of us have heard from Erik in quite some time? I don't know if there's any ongoing development?

Had to reprogram a Digispark Pro a few days ago and it blew me away just how quickly and easily this worked over the USB connection - I actually felt nostalgic.

Unless the initial bootloader issues can be solved, and we have an easy (i.e. non-UART serial) method of locally uploading code (i.e. non-Particle), I just can't see recommending Oaks to others, and I'm seriously tempted to give the Feather Huzzah a go.

Thoughts, folks?

[emardee]

I really hope the Oak has a future. It really does have a lot of potential, and if the final features promised in the Kickstarter campaign are ever fully delivered in a reliable and supported manner, then it could yet get there still.

Unfortunately unforeseen delays at Erik's end, them having a new child, the decision to switch to Particle and then discovering the platform wasn't ready to support Oak, have all added frustrations to the mix! I think the hardest of which to cope with is the silence from Erik, which breeds that deeper uncertainty about the future.

If the support and development was more visible and proactive, (or to be honest, even if Erik was just more vocal!) the delays would be much more bearable.

So I'm still hoping for the missing pieces to arrive. For the support to be slightly more visible. And the platform therefore to become the great product it has the potential to become!

Here's hoping!

Mike

[PeterF]

Hey... if worst comes to the worst... it's a great ESP8266 module programmable over serial. It just isn't a wifi/cloud programmable one unless you want to play with the ESP8266 Arduino OTA stuff. Which, given that the Oak has 4MB, is actually possible, as opposed to the ESP01s I was playing with before.

Having said that... I don't think it's anywhere near a write-off just yet... just doesn't have much of 'development team', so it's all on Erik! :-O Now, if we are still wondering about this in 6 months time... shoe might be on the other foot! :-P

[exeng]

I have a misbehaving Oak that is physically difficult to get to and refusing to OTA update. I suspect it needs  the pin 1 to GND treatment. Once I get my hands on it and try to OTA update while it is physically in my control, I'll formulate an my final opinion. But aside from the temperamental initial updates of new Oaks, they have generally behaved. I have used my Oaks far more than any other micro I have for real projects and I have learn more from that experience than any other. So, my opinion is still positive.

Second, despite Erik's low key approach to the forum and updates, I believe he does check in and read the posts periodically. Also, when one has a legit (emphases on legit) support question, he does respond to inquiries at the support email address. For these reasons I continue to fully back Erik and assume that he is just too busy to spend all of his time on the Oak. I can live this given the Oak does most of what was promised. I have 5 in service right now.

All that said, I too long for a simple USB update via the IDE. I know that serial is available be that requires an effect to get out the FTDI (if you have one) board and hook it up.
That usually happens after some frustration trying to OTA update. I am also curious about future plans for the Oak and possibly other boards.

UPDATE: Well there is something very weird going on. I did the pin 1 to GND and tried to OTA upload a simple blink sketch. I'm getting

Code: [Select]

Flashing............................................................................................
Error : Flash timeout - flash failed.
Error : Flash timeout - flash failed.
and it continues loading after the error messages and seems to go on for far too long. The sketch is working though, suggesting that load was indeed successful. I'm using the Arduino 1.8.1 IDE so I don't if that is related. I would have to go back to 1.6.7 to know for sure.

This kind of behavior is yet another reason to have available a simple serial upload capability.

[postuma]

The "flash failed" message has been happening to me for the last week, on three different Oaks. Others have reported it as well; see https://digistump.com/board/index.php/topic,2615.0.html. Still, same as you and the others have noted, it does eventually work - some three dozen flashes for me have gone fine, despite the time-out.

Please don't get me wrong: I do love the Oaks that I have working (there's still two out of about 15 that are giving me config nightmares, despite uploading via serial, and the various OTA tricks using phone/tablet that sometimes work). I love the power and versatility this chip offers, and I love being able to do OTA updates for Oaks already committed to existing projects - not having to take stuff apart every time you advance functionality - great!

I also agree that when I've had a specific question for Erik he's been very forthcoming, very helpful. He's put a huge amount of work into this project - but that also has me worried about sustainability. I suspect his return on investment is pretty minimal - I doubt he's made much money off this venture, and certainly not enough to adequately pay for his time.

It can take me years to complete one small project. Whether he can keep this huge project on the rails with all the demands on his time - I wonder. And as far as I'm concerned, family, health and happiness come first.

[exeng]

Well I too have begun to experience the OTA flash update failed but is actually working. Based upon my previous post update, I tried a different machine with 1.6.5 IDE and uploaded the full working sketch that my Oak was previously running. It "failed" but is actually working as I put it back in service and can see that it is functioning properly. So it appears to have nothing to do with the local environment/IDE version.

So now I understand the frustration. Most (all but the persistent Oak experience enthusiasts) will throw their hands up and head to the forum for help. Makes me wonder if Particle changed something recently that is affecting the upload behavior. I hope this gets fixed and I also wish there was a simple IDE USB based local update available.

[emardee]

Sounds like this is actually something that should be run past Erik by email. He probably needs to liaise with Particle team to work out what was broken, and how it should be fixed.

Mike

[PeterF]

Yeah, someone else posted that their Oak was being stubborn (postuma posted the link to that thread above) and it didn't appear to be related to their recent outage, so I flashing something to an Oak to see if there was still an issue, and it appears that FastOTA updates aren't working, so the IDE upload process reaches its timeout and spits the dummy, but the Oak is still updating, and finishes the upload after five minutes. Beyond that, I know nothing. Other than that direct WiFi OTA upload via the ESP8266 Arduino are FAST... like less than 5 seconds.. i.e. serial uploads are SLOOOOOWWW in comparison

btw, exeng.. I also have a Oak that doesn't like to upload... every time I push an update it crashes... probably something to do with the LCD code... so I always trigger it into config mode via OakTerm before it uploads... and it generally behaves itself then. Just an idea if it does the same - b0rks at accepting new code, but is still online and controllable prior to pushing new code.

[exeng]

Duh! Pete thanks for reminding me that OakTerm is available to trigger config mode. For whatever reason one Oak stops posting to the cloud after a very very long period of operation (months). It remains online but the upload fails (or does it?). So then I have to climb a ladder, stand on the very top (not a good idea) and retrieve it so I can do the pin 1 to ground thing. Next time this happens I'll give OakTerm a try. Other than that, I very rarely have to update Oaks. Months can go buy before I have to touch one of my operating Oaks.

[PeterF]

lol... just make sure you do remember... might save you a trip to the hospital!

Same here... my sensor Oaks are plodding along happily without being touched for several months... and I only work on the display unit infrequently atm as other stuff keeps getting on the way... which means this slow upload issue would be a real pain if I were to want to start working on it again soon...

I sent an email to Erik a couple days ago to touch base and see how things are going, but no reply yet. More concerning is that he hasn't been on the forum in over a month... which is a bit unusual... so I hope nothing has happened to him!

[exeng]

I contacted Erik at the support email about a week ago about a part he sourced for the Oak kit. He responded rather quickly, so I know he's around. He has said that he monitors the forum but probably doesn't always login unless he is responding to something. 

[marcmerlin]

Ok, so apparently I can't even open a new thread, it's just left in limbo with no one to moderate/approve it.
As a result, I'll post here, sorry

Subject: how can you develop with a >2mn wait between each flash?
I just wasted hours, and I mean hours, setting up my first oak. First it wouldn't connect to wifi and get the update (finally it got it) and then it would not show up on particle, so I tried again and again and again until I found that I had to connect to the device, get the device id via 192.168.0.1/device-id and manually add it on particle.
Why is this still broken and not working out of the box?

Anyway, now I can flash blink, but it takes 2mh to flash, each time (not counting the timeout on the arduino side that says the flash has failed when it fact it's still going on)
[22 :41: 53] Event: spark/flash/status - started
[22 :43: 45] Event: spark/flash/status - success
[22 :43: 46] Event: spark/status - offline
[22 :43: 55] Event: spark/status - online

How can you write code and test it with such a lag? I can't go to the fridge or get a coffee between each cycle, I'd end up fat and going to the toilet all the time...
Is everyone putting up with that, or are you doing local flashing, or testing on another esp8266 board first?

[PeterF]

Not sure what the problem is there... I've never seen anything about posts on this forum needing moderation, and  I was able to post a new thread just now with your message in it, which I will reply to over there...

http://digistump.com/board/index.php/topic,2630.0.html

[malaire]

Not sure what the problem is there... I've never seen anything about posts on this forum needing moderation, and  I was able to post a new thread just now with your message in it, which I will reply to over there...

http://digistump.com/board/index.php/topic,2630.0.html

Everytime I post new thread here, the web browser tab goes to some kind of infinite loop and it never seems to finish. But actual posting does succeed, I just need to close that tab and go to forums again to see the new thread.

[postuma]

FWIW when I start a new post, it does for some reason take minutes for it to process. Don't know why - responses to posts go up immediately. I just walk away, grab a drink, use the facilities, do some light stretches, acknowledge my family, read a book ... and the new topic shows up.