Forum Replies Created
-
Posts
-
Yeah, your guess is as good as mine as to the root cause. Thanks for bringing it to my attention. Code changes are reflected on GitHub now.
Great! One last update that should fix the previous button issue. I’ll get the code up on GitHub later today.
https://www.ledseq.com/downloads/gameFrame_irFix.hex
Rather than showing the wrong signal it will just show no signal at all. Previously any repeat signal was accepted, and it would always repeat the last prime signal detected. Now it won’t accept repeat signals if there has been a 250ms delay since the last valid signal (prime or repeat).
The remote record screen issue is acceptable. You may need to press a button twice, but at least it’s not accepting bogus signals. I’m also really happy it’s storing them correctly.
Setting the clock is a better user experience all around and is better for everyone. I’m glad you provided the impetus to change it.
Breakout is kind of random. If you hit on the center pixel it’s a 1:1 deflection. If you hit on the side pixels it deflects in that direction at a random angle. Speed increases with each brick hit. It is hard, but it is possible to beat. 🙂
Christophe, I just updated the irFix firmware. When you have a moment please try it again.
https://www.ledseq.com/downloads/gameFrame_irFix.hex
While you may be the only one to report these issues (and you are technical enough to workaround them), I’d like to solve them for the sake of other potentially less technical customers. I appreciate your help.
RecordIRCodes() now only allows NEC-compatible codes, and I’ve rewritten the clock set functions. You’ll no longer need to hold down MENU to advance digits. You still can, but you can also mash MENU to advance the digits.
I’ll update the source on GitHub once we have this figured out.
Christophe, do me a favor and try this firmware. See if it solves or changes the behavior in remoteTest() and recordIRCodes().
I’m confused why you needed irCommand to == X for unrecognized commands since it was already setting it to ‘Z’ for unrecognized ones.
For what it’s worth, I can’t reproduce any glitchiness in remoteTest(). I try pressing buttons before it loads, spamming buttons when it’s on, holding buttons for a long time. It works fine, and the serial output looks clean. I also can’t reproduce any problems in recordIRCodes().
Are you 100% certain the IRRemote library buffers multiple commands? I was under the impression that it stores one command at a time and only looks for a new IR signal once it’s been decoded (i.e. irrecv.decode(&results)).
The delay(125) in remoteTest() exists only to keep the graphic on the screen. I could rewrite that so the remote is checked constantly for that 125ms. Would that solve your issue?
As for compiling, see the notes on the GitHub. You need Arduino IDE 1.6.3 and Teensyduino 1.22. If you still have trouble, let me know.
Yeah, the way it stores the codes is janky but it works. The INI reader will ignore the second line. It just reads everything between “next = ” and [CR][LF]. Very few people use this feature though, so fixing what is essentially a visual blemish is a low priority.
Setting the clock is a one-time thing, so you shouldn’t have to worry about that once it’s done. It’s also worth noting that when setting clock you do have to hold down MENU (not tap it) to advance the numbers. Then you tap NEXT quickly to set the hour or save the time. I know it’s fiddly but, again, it’s a one-time thing.
That still doesn’t explain any occasional glitchiness in the menus — are you still experiencing that? If so, you should be able to reproduce some anomalies in the “crash” test stream. If you can do that, I might be able to provide a software fix like you said.
What is that 3887053538 code?! The re-programming stuff is less useful than the actual data stream from the “crash” test. Can you restore the REMOTE.INI file to its stock state, go into the crash test, and record yourself hitting each of the three Game Frame remote buttons once and holding them down for 3 seconds each?
Putty is a nice serial monitor and you can set how many lines it records so you won’t lose anything.
Well that should NOT be the experience of new owners. 🙂 The remote should work very consistently and reliably.
You said that your other remote exhibited the same issues. To be clear, does this mean that the Game Frame would see a unique code followed by the 0xFFFFFFFF repeat code until you released it — but occasionally it would also get totally random codes interspersed between the repeat codes? As you suspected, I think we’re zeroing in on something wrong on the receiver end.
remoteTest() waits 125ms because it takes that long to receive a new IR signal, and if I check before then the image would disappear (which shouldn’t happen until you release the button). The other processes don’t require that kind of visual feedback.
A few things….
1) Definitely try to find another remote so we can compare. Most remotes should work, since most use NEC-compatible signals. We’re looking for one unique code followed by infinite 4294967295 (0xFFFFFFFF) until you release the button. You may need to aim generally at the IR receiver but it should work up to a few meters away.
2) I realized you never explained the behavior you’re seeing under normal conditions, just trying to use the menus. Can you explain? Perhaps a short video would help illustrate?
3) Just to be sure, can you shine a light into your IR receiver on the Game Frame and verify that it’s oriented properly and you can see it like in the attached photo?
Where are you seeing sleep() commands? I don’t see that in the source at all. There is also no delay() used in the recordIRCodes() function. For each step it waits until the remote signal doesn’t equal any of the previous codes received (or the “repeat” code 0xFFFFFFFF).
Anyway the “crash” test results you’re getting are correct, which makes this all the more confusing. Do you get phantom codes reported during that test if you don’t press any buttons at all for a minute or so? I still can’t figure out why you’re getting phantom codes when you start the recording process of learning new codes.
Did you try a different IR remote to see if it gives consistent codes in the “crash” test?
I realize this must be very frustrating for you but I appreciate the detailed testing and feedback. I’m anxious to figure out what is going on.
Can you please perform the same serial log test on another remote? I’m curious to see if you get consistent results from another remote or not. That might help narrow down whether you need a new IR receiver (LED board) or a new remote control. Given that you’re getting flaky results from the stock remote — but consistently flaky — I’m now wondering if the remote you got was possibly mis-programmed at the factory or something. Pressing POWR or MENU should definitely never give you the NEXT code.
EDIT: Maybe I misunderstood you?…. You said:
So usually, If i press any button on the remote, I get “IR Code: 2155831455” (NEXT) then “IR code: 4294967295” (0xFFFFFFFF) repeated about 4 or 5 times a second, until I release the button.
Does this mean you get the NEXT code when you hit any button, or is the the behavior when you hit the NEXT button specifically? If so, this would be the correct behavior. 0xFFFFFFFFF is always repeated on NEC-compatible remotes until the button is released.
Hey Christophe! Sorry to see you’re still having issues with the remote. You’ll get prints from the COM port even though the debug bool isn’t set. (That just gives more verbose ones.) Just use a terminal program like Putty to read what’s coming in through the port at 57600 baud. Then turn on the Game Frame and pop out the microSD card. You should be able to get remote code prints while the SD error screen is shown on the display.
If we can’t figure this out I’ll get you some new hardware. Feel free to email me (jeremy at this domain).
EDIT: Re-reading your analysis (great work btw) it sounds to me like an issue with the IR receiver. I haven’t seen that before, but there’s a first time for everything. Why else would it act like it received IR signals even with something covering the IR port? The curious thing is why doesn’t it continue to receive phantom codes when it asks you to provide a code for the NEXT button. Fascinating! 🙂
EDIT: One other note, some remotes emit two codes before the repeating code (0xFFFFFFFF/4294967295). I’ve seen this on an apple remote, and these are incompatible with Game Frame. You’re not by chance using one of those, are you? Are all of your experiments with the stock Game Frame remote?
Yes, please let me know if a new battery solves it. It has for other customers. It seems some of the batteries are in better condition than others. Grrr…
