So I’ve been working on an imp project and it was going fine. I was able to blink up, and program my imp. Then a slipped probe killed my imp, and I had to ordered a new one.
I’ve been using the spark fun version of the April board, and I put the new imp in my project, and blinked it. However the imp then goes into a state where it will slow green blink (1 sec speed) for as little as three or as many as 12 green blinks in a row, but then followed by a bunch of red blinks (.5) and then it goes back to green blinking. It just gets suck in this loop, but the number of green blinks in a row seems random. I’ve never seen more than 12 in a row, but it never shows up in the planner.
I know my router is compatible since the previous imp worked fine, but now this new imp is stuck in limbo.
(This new imps mac is 0c:2a:69:00:08:c6 )
I’m not sure what to try from here. I assume the blink up went fine since I get some green blinks, but something is screwed up since it then goes into red. After a lot of looping between the random number of slow greens and then faster reds it’ll eventually give up and stay dark, but it never shows up. sigh Is there some sort of definitive flow chart for debugging these connection problems? I guess I was spoiled because my first imp blink up went without a hitch.
Sounds like you have a compilation error in your code. Do you see any log events in the planner IDE for your impee?
You can also try changing the firmware on that particular impee and reinserting the imp - if it work’s as you expect then that is definitely the issue.
Well, it’s not a compilation error since it never shows up in the planner, and the code is unchanged from what I was downloading before. I guess I’ll read up on firmware update stuff, but I’d think the impee would have to be visible on the site to be able to do anything to it? Thanks for the info I’ll poke around some more.
That pattern is, as deldrid1 says, usually associated with an error - generally this would be a runtime error though as the code is running, then falling over (red blinks) then it reconnects, loads the same code which falls over again etc.
It won’t necessarily appear in the planner if it’s not got to the imp.configure line in the code. It will be running the last code you had associated with that april (even though it’s a different imp) - can you just chop that code down to an imp.configure line (so there’s no place it could get upset) and see if it appears?
Oh interesting. How would I do that if nothings in the planner? Is it just trying to download the same named src file? I guess I could chop that src file down to a single imp.configure and it’ll be trying to download that file? Great, I’ll give that a try tonight. Thanks!
I was a bit worried that maybe my probe slip had also fried the unique id chip, and that I’d have to reorder the April board and then totally rebuild my project around that. Not something I was looking forward to. Lets hope this software fix works!
Oh hmm. Yes, that could also cause this issue (if the imp fails to read the ATSHA).
However, it would appear that you may have changed your password and not logged out/in again in the blinkup app (ie, you have a stale token). Can you try signing out of the app then re-logging in and re-blinking up?
Woot! That was totally it! I had forgotten about having to change my password, and didn’t even remember that the blinkup needed that password. lol. I bet that the app should try re-verifying the userID/password when you blinkup so it could give you nicer error UI about how it couldn’t log in. Instead of putting you in blink decoding hell. :] Thank you SO much. I’m back to the races! Now to try and get the servo code working properly… Thank goodness I don’t have to order another April board and rebuild the whole thing.
Other than this glitch with the password my exp. using the imp has been pretty smooth. I’ve wanted to play with the imp since your demo at the H conference, and this cross country gonging robot thing seemed like the perfect application for the imp.
Thanks again for your awesome help!