Forum Replies Created
-
Posts
-
I added an Advanced section to the bottom of the underwhelming WiFi docs. 🙂
Granted, it’s really just an introduction to using the Particle cloud API and SDKs. I understand you’re averse to them, but I encourage you to try them out in some respect for a trial period and see what you think. In my experience they’re rock solid, and infinitely more reliable then the built-in web server.
And, no, the Particle cloud API is not reliant on the web server. The web server is an application level library that hasn’t been updated in 3 years. Particle’s entire business model is based on enterprise scale cloud services for their family of microcontrollers.
To be honest, the reason I included the web server was because I share some of your feelings about an isolated LAN. Unfortunately the web server library is just a worse experience. You can do a lot of what you want using the exposed Command function. Maybe give it a shot and see what think?
I have added a check for restoring from an off state. It will be in the next release.
If you want to track whether the Game Frame is turning on or completely rebooting, you can visit this page and login with your Particle credentials.
https://console.particle.io/logs
Then reboot the Game Frame. You should see the log start to tick by. You can leave that up for a couple days and see what you see. If it actually crashes/reboots you’ll see it in the logs with “recover” in the data column. It says “boot” if it boots normally. That’s a little event that’s published on startup to try to troubleshoot this very issue.
I’m glad you found the HTTP commands, but as I said (and you’ve discovered) the web server is unstable and poorly supported by Particle. You’re much better off using the exposed functions to achieve the same things. They’re rock solid (independent of the web server), and just as fast, but you are using the Particle infrastructure.
You can call the functions via http, post commands, or javascript. I’ll try to update the docs in the next 24 hours with more details and followup here.
Hey JP–
Sorry for your confusion and the underwhelming docs. Let’s try to clear things up.
As far as the firmware goes, Github hosts the most recent “official” release. (The one from January you saw in the forum has no additional features.) So, yes, just grab gameFrameWifi_20161211.bin. Make sure you’re downloading properly from Github though (i.e. click the download button on this page).
You’re using the right page for managing your firmware. As for “tasty_station,” that is probably the temporary name given to your Photon when you registered it with Particle and made that account. You should have been given the opportunity to rename it then. You can change it by logging in here and clicking on the name. You can also access and play with functions that control aspects of Game Frame from there.
System version 0.6.0 is the Particle firmware version, not Game Frame firmware. To see whether the firmware uploads successfully, go to http://www.your-game-frame-ip/help and see it listed there. It should say 20161211. (It’s also very easy to tell simply using the Game Frame remote because a third mode is added (FX) in addition to Gallery and Clock.)
As for the dependence on Particle.io, you’re welcome not to use the exposed functions. You don’t even need to login to their server to update your firmware if you want to use DFU mode. I just find it’s much easier to do so. The built-in web backend (your-game-frame-ip.com) doesn’t rely on their services. That said, I’ll probably end up abandoning the web server (or making it opt-in) because it’s too buggy and causes the Game Frame to hang if it loses connection to the Internet. I run a watchdog that reboots the Game Frame in this case, which may be the root of your original problem where it suddenly turns itself on.
Can you describe what happens when it randomly boots? Does it reboot from an off state (powered down using the IR remote)? I may not have considered that case and can add a check during boot to see if it’s recovering from a hang AND was powered down, in which case it would return to an off state. I know this is a workaround, but the web server hang bug is deep in the Particle.io source and I don’t see them fixing it anytime soon. The best solution is probably to drop the web server and expand the firmware manager to have the same features as the back end, populated by exposed functions and variables. At least these don’t crash.
Brian: Send me an email (jeremy at this domain) and we’ll get you the necessary files and figure this out.
Okay, now that Particle has the Arduino compatibility bugs sorted I’ve pushed the Wi-Fi Adapter source code to GitHub. Compile using 0.6.2-rc.1 or greater. I recommend Particle Dev or command line — NOT the web IDE.
Interesting. I just made a fresh SD with three standard Game Frame animations along with two others called “spaceInvaders” and “superMarioBros” and those two never get played. Same result with Wi-Fi Adapter and original Teensy.
Well, you’re right that directory names must have a maximum of 8 characters, but this is true in both sequential and shuffle modes. Are you sure earlier firmware allowed folder names with more characters?
i haven’t tested it but there should be no difference in directory name support between sequential and shuffle modes. That said, I usually name all my folders using up to 8 characters. Do you need more than that? I’ll look into this further.
davenedde: I’m trying to ascertain whether the problem is with your remote or the receiver in the Game Frame so we don’t waste time sending the wrong replacement. Are you 100% certain squeezing the remote has an effect? That would certainly suggest the remote is faulty, but you said it’s not consistent.
Do you have another remote you could use to re-program the Game Frame using the instructions earlier in this thread? Depending on your results we could likely tell if it’s the remote or the receiver.
davenedde: Sorry you’re having remote issues. You mean you need to compress the remote to make the battery make contact? Haven’t heard that issue before, but it’s possible. Does it work consistently when you do that? Have you tried replacing the battery? Updating the firmware?
I saw that, but are you sure FastLED doesn’t need the RwReg variable or can freely use the one that’s already instantiated?
The latest Particle firmware broke compatibility with the stock FastLED library. Let’s see if that can be sorted and then I’ll look at releasing the code.
That video is very helpful. That is 100% how SK9822 LEDs behave when Game Frame is compiled for APA102. I’m certain you were sold SK9822. You’ll just need to use a newer version of FastLED. They actually added support after I sent them a panel I used to test compatibility when APA102 were out of stock, and I noticed the same thing you did.
Just use the latest master branch of FastLED. I’m not sure about your issues with the grid remaining dark. If that’s still an issue, it shouldn’t be based on the version of FastLED.
