Remote doesn't always register

[Christophe]

1) Found a TV remote that works, and behavior is the same as with the original remote (but with different values for codes). I’m trying to record the logs over serial from the record and test screen which show interesting results.

2) under normal conditions, the gameframe responds fine to most keypress, and I can’t use the menu. The only thing “visible” is that sometimes it looks like I pressed multiple time the same button, other times, as if I did not press the button. The small arkanoid clone is mostly playble. The only huge hurdle is setting the clock because it stops but does not start when you want etc, and when retrying it always stops one before or one after the desired hour/minute. Except from this, the other major features are usable.

That’s why maybe the initial impression for new owners of the frame is similar to an old crummy remote with buttons that start failing (bad contacts, dust …)

3) I see the IR sensor allright, see attached picture.

I’l try recording a small video if I can to show the behavior…

Attachments:

You must be logged in to view attached files.

[Jeremy Williams]

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.

[Christophe]

Ok here is a test scenario I just did on the IR test mode, looking at a TV remote that I found. I’l try doing the same thing with the original remote, to see the difference, but visual behavior is the same.

=> my current thinking is that remote is perfectly OK. Pb seems to be that IR driver is not flushing the buffer of ir codes received properly or something, and that your code is reading extra stuff mixed in with the actual codes sent by the remote. Combined with your logic in the test and record screen produce this odd behavior.

Note sure if the behavior comes from incorrect configuration of the IR driver somewhere, or maybe a faulty IR sensor that behaves in a way not expected by the IR driver?

—-

### On the IR test screen, with TV remote

# I press the ‘next’ button on the back
> Loading image ‘irPowr.bmp’
> IR code: 3887053538
> Loading image ‘irMenu.bmp’

# I see the menu icon, I wait 30 sec… then press ‘1’ button on TV remote
> IR code: 3778927144
> Loading image ‘irNext.bmp’

# I see the next icon, I wait 30 sec again… then press ‘2’ button on TV rmeote
> IR code: 2908251746
> Loading image ‘irZapr.bmp’

# back on test screen, I wait 30 sec, nothing happens

# then I press the ‘1’ TV remote (which was recorded for the ‘menu’ button) and chaos happens
# => random blinkings of the various icons for about 5 seconds, and the following log
# I did NOT do anything with the remote except pressing ‘1’ briefly. I also tried putting away the remote, the sequence continues.

#(note: unfortunately, my serial console on my PC truncated the top of the log, but this is similary to the start of the next test below)
> IR code received: 2823767411
> Loading image ‘irZapr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 1322193144
> Loading image ‘irZapr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 2823767411
> Loading image ‘irZapr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 196227623
> Loading image ‘irZapr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 1574859868
> Loading image ‘irZapr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 2823767411
> Loading image ‘irZapr.bmp’
> IR code received: 1574859868

# aaaand…. stop!

# I wait a bit, press the same ‘1’ button again, and this only last a few blinks…
> IR code received: 3778927144
> Interpreted as: M
> Loading image ‘irMenu.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053539
> Loading image ‘irZapr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 3887053538
> Interpreted as: P
> Loading image ‘irPowr.bmp’
> IR code received: 2179001249
> Loading image ‘irZapr.bmp’
> IR code received: 196227623

# wait a bit, press ‘1’ again… and this time only a single blink of the menu icon (correct!)
> IR code received: 3778927144
> Interpreted as: M
> Loading image ‘irMenu.bmp’
> IR code received: 1471620857
> Loading image ‘irZapr.bmp’
> IR code received: 3887053539

[Jeremy Williams]

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.

[Christophe]

I usually use Putty, but when I go to Connection > Serial, COM3+57600, when I clic on “Open”, nothing happens 🙁

Anyway, here is the tests with gameframe remote

POWER button for 3 sec
IR code: 2155819215
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295

MENU button for 3 sec:
IR code: 2155864095
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295

Next button for 3 sec:
IR code: 2155831455
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295
IR code: 4294967295

This mode looks fine, nothing like the test or record mode 🙂

[Christophe]

Edit: I found out why putty was not working, it was problem between keyboard and chair, orz

So: with stock config remote is ~ok (except the glitchiness with short keypress especially in clock setting mode).

But once I go to test mode or record mode, things go south. Also, since the record mode captures garbage, behavior afterwards is random (all the blinkiness above) probably because of that.

ALSO, I’ve seen in remote.ini again the same thing with an extra line after ‘next = ….’ with an extra number.

I THINK this bug is because here you overwrite the file with the new codes: https://github.com/Jerware/GameFrameV2/blob/master/gameFrameV2.ino#L523 and then close the file, without truncating it. But maybe if one of the codes is shorter than before, the tail of the previous number will be left.

let’s say before you had:
next = 1234567890[CR][LF]
… rest of the file

but now you write the new values.
next = 1234[CR][LF]

and close file, the file now contains
next = 1234[CR][LF]7890[CR][LF]
… rest of the file

Which looks like there is an extra “7890” on a new line but it is the remainder of previous version of file.

You would need to truncate the file (but loos the comments at the end of remote.ini, OR maybe write an extra ‘#’ at the end that would make the extra numbers look like a comment (hacky but may be good enough)

[Jeremy Williams]

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.

[Christophe]

In normal use it’s very minimal and not that bothersome (except I now have a ready made excuse when I lose at arkanoid 🙂 ). I’ll try later this night playing with it again, see if I can reproduce in the crash test mode.

This week end, I will install the arduino IDE, see if I can build the firmware myself, and maybe try playing with the code, see if I can get more details on what exactly is happening.

Thanks for the help 🙂

[Christophe]

Was able to finally install Arduino IDE and start playing with the code comfortably on my mac at home. So this is a different place, which would rule out any outside IR perturbation from other devices at work.

btw: I’m having some issues when building for Teensy LC (will probably open a new post for that) with gameFrameV2.ino.elf section '.text' will not fit in region'FLASH' and region 'FLASH' overflowed by 3036 bytes. Had some difficulty finding the correct versions of some lib (SdFat) which have changed recently, and also Teensyduino needs to be in 1.31-beta to be compatible with Arduino 1.6.12 (which I downloaded).

Anyway, with the Arduino serial monitor, I see the following happening when using the stock remote with stock remote.ini on GameFrame with stock firmware (logs below)

You can see that there is always a rogue IR code received before the correct one.
This would explain why the IR record screen has issues: it probably reads these codes and think that they are the code the for first POWER button. Also would maybe explain the “blinking” of icons: usually the sequence is “bad code, REPEAT, good code”. Your code in irReceiver() may not understand whats going on, and think that it was a repeat of the last key pressed on the remote, and return command ‘R’ to the caller code, instead of the intended code (‘M’ in this case). But if I press the button long enough on the remote (> 150ms?) then maybe it will have a chance to see the proper code. This would explain the symptom of having to press hard/longer on buttons just so that it last more than 150 or 300ms??

# from the clock screen, I press menu a few times

Loading image ‘/00system/digits.bmp’
IR code received: 1032981240 <— 3D920AF8 ?
IR code received: 2155864095 <— MENU BUTTON correct code for menu
Interpreted as: M

# switching to the menu screen
Loading image ‘/00system/bright_1.bmp’
IR code received: 3887053538 <—- E7AFBAE2 (this one is seen frequently)
IR code received: 4294967295 <—- FFFFFFFF
Interpreted as: R
IR code received: 2155864095 <— pressed MENU again
Interpreted as: M

Loading image ‘/00system/play_1.bmp’
IR code received: 3887053538 <— E7AFBAE2 this code again
IR code received: 4294967295 <— FFFFFFFF
Interpreted as: R
IR code received: 2155864095 <— MENU BUTTON
Interpreted as: M

Loading image ‘/00system/time_3.bmp’
IR code received: 196227623 <— 0BB23227 another weird code
IR code received: 4294967295
Interpreted as: R
IR code received: 2155864095 <— MENU BUTTON
Interpreted as: M

Loading image ‘/00system/mode_1.bmp’
IR code received: 3887053538 <– E7AFBAE2 gain
IR code received: 4294967295
Interpreted as: R
IR code received: 2155864095 <— MENU BUTTON
Interpreted as: M

Loading image ‘/00system/game.bmp’
IR code received: 3887053538 <— E7AFBAE2 again
IR code received: 2155864095 <— MENU BUTTON
Interpreted as: M

Loading image ‘/00system/bright_1.bmp’
IR code received: 2823767411 <— A84F4573
IR code received: 4294967295 <— FFFFFFFF
Interpreted as: R
IR code received: 2155864095 <— MENU BUTTON
Interpreted as: M

Loading image ‘/00system/play_1.bmp’
IR code received: 3887053538 <— E7AFBAE2 again
IR code received: 4294967295 <— FFFFFFFF
Interpreted as: R
IR code received: 32895 <— 807F truncated prefix of valid code
IR code received: 4294967295 <— FFFFFFFF
Interpreted as: R
IR code received: 2155864095 <— MENU BUTTON
Interpreted as: M

Loading image ‘/00system/time_3.bmp’
IR code received: 3887053538 <— E7AFBAE2
IR code received: 2400927396 <— 8F1B3EA4 ??
IR code received: 4294967295 <— FFFFFFFF
Interpreted as: R

# then the regular clock resumes

[Christophe]

After performing a “breakoutectomy”, I was able to slim the code and allow it to build. With that, I could play with the gameframe a bit more 🙂

I now think I get a good sense of what’s going on, and the issue can be worked around in almost all the cases…. but it does not look like it is worth it for normal use (code would become bloated with checks that would take more space in the flash only to fix visual glitches in remote test mode, and the record mode is not really important for me … as long as I don’t lose the remote)

The issue is indeed caused by phantom codes being read by irrecv.decode(..). I changed the irReceiver() code to have a new value of ‘X’ for irCommand when the code is not recognized, which filters bad codes out.

The glitchiness in the remoteTest() code is due to the way you deal with ‘timeout’ of key presses, by simply waiting more than the typical delay between IR codes: but when you read an invalid code, you wait again 150ms before reading the next (which is the correct code still in the irrecv buffer somewhere). If the IR buffer is filled with random junk, you will need multiple reads to clear it, and at 150ms per read, this can take up to a few seconds of blinking when there is a lot of stuff there.

I tried changing the code logic with a timeout counter, and a delay of 10ms between reads, and it works almost in all cases… but it does not seem like its worth complicating the code for this.

I have *NO* idea, after reading and testing the code, why the crash test screen does not show these phantom codes (unless in rare cases where I have to spam key remote keys…), probably due to the timing?

Stupid idea: most of the code that produces random codes is almost always before/after refreshing the entire LED screen (which will flash), while the crash test screen does nothing to the screen (only writes to serial port).

Maayyyybe the LCD driver is interfering with the IR receiver somehow? (either on the data bus, electrically, or maybe even the light emitted by the LED would impact the receiver

[Jeremy Williams]

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.

[Jeremy Williams]

Christophe, do me a favor and try this firmware. See if it solves or changes the behavior in remoteTest() and recordIRCodes().

https://www.ledseq.com/downloads/gameFrame_irFix.hex

[Christophe]

I needed a different command because no IR code received is also ‘Z’, and I needed to know if I needed to read an IR code immediately (bad code usually followed by correct code) or not (no button pressed).

Your updated firmware seems to completely fix the issue in remoteTest() and in general use of the menus, but setting the clock is still almost impossible (pressing menu is only recognized 1 out of 3 times maybe, and it does not recognize when I release the button well), and recordIRCodes() still has the same issue (though this time, it asked me for the MENU code, but then the NEXT code flashed without asking me anything), and remote.ini looks like this after (not even one valid code was read) :

[remote]

# Learned Codes
power = 715979422
menu = 32895
next = 1699874231
1455

As far as I’m concerned the remaining issues are not that big a deal (can set time using physical buttons, and if I ever need to change remote, I can use the crash test screen to read the code, and edit the remote.ini file by hand).

What did you change in this firmware?

[Jeremy Williams]

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]

Updated the firmware, and we are almost there:
– remote test screen: it reacts to keypress, but sometimes, it shows the previous button instead: example, I press the sequence POWER-MENU-MENU-MENU, and it will display “POWER-POWER-MENU-MENU”.
– remote record screen: it worked, but I had to press MENU two times for it to be recognized. the remote.ini contains the correct codes.
– clock: was able to set the time no problem, which i think was the most visible issue “out of the box”
– normal use: as with previous update, did not notice anything obvious, appart from the occasional missed keypress here and there.
– breakout: I still lost because the ball physics are a bit … random 🙂

Overall, this firmware is really an improvement on the stock one, for board that would have an issue with IR sensors. great work 🙂

[Author]

Posts