Remote doesn't always register

[Brendelino]

Hi There!

Update: I changed the original an full (!) 2025 CR Battery on the original Remote and now it works without any problems! How easy was that? 😀 Now everything works fine!

Thanks for your support, Jeremy!

P.S. The Gameframe is the nicest Toy ever! Love the it!

[Christophe]

Received mine today, and I seem to also have issues with the IR remote.

Using the IR test mode (booting with NEXT pressed):
– when pressing any button on the reboot, the icon for each button blinks randomly for 1, 2 or 3 seconds, before settling down to the “on” state.
– when releasing the button, the icon disappear immediately.
– using the physical buttons behind on the motherboard works fine.

This behavior is the same, even with the IR led a few millimeters away from the remote sensor or a few meters away, or from the side…

This probably mean that one physical press of a button on the remote is registered as a random sequence of keypress by the GameFrame, leading to weirdness.

That was particularily bad when setting the time in clock mode 🙂 Also, I noticed that sometimes the “next” button on the remote was interpreted the same as “menu” (was advancing the hours). Could be explained by a discharged or faulty battery.

I’ll try swaping the CR 2025 battery with a new one, and see if this fixes the issue.

[Jeremy Williams]

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…

[Christophe]

Unfortunately, changing the CR 2025 battery did not change anything. Icons on the test screen blink randomly 2 or 3 times when pressing any button.

I tried teaching new remote codes by pressing NEXT while in the test screen, and something strange happens: I see the red border, but the screen almost immediately switch to the MENU or event NEXT image: the POWER icon is only briefly seen. Then when I press the corresponding button on the remote, it works well. After that, pressing any button makes all icons display in some random order.

Reopening the remote.ini file, I see this: (there is an extra line with ‘55831455’ ?)

—
[remote]

# Learned Codes
power = 3887053538
menu = 2823767411
next = 2155819215
55831455
—

The original file before editing:

—
[remote]

# Stock Game Frame Remote
power = 2155819215
menu = 2155864095
next = 2155831455
—

Note sure what happens: looks like the IR sensor is “seeing” things, so when the code waits for the ICON button, it immediately “reads” stuff.

The ‘3887053538’ and ‘2823767411’ codes may be what is being read by the IR sensor and triggering the move to the following icon. The ‘next = 2155819215’ is because I pressed the POWER button instead on the remote, which was read properly.

I tried covering the frame with a black cloth and it does not change anything.

Any ideas?

[Christophe]

I tried in a different room where there is no IR devices, and same behavior:
– on the remote test screen, when pressing NEXT I see the red and blue icons flashing at probably 1 frame each
– then the green ‘>’ icon with red border stays there until I press a button on the remote (tried waiting up to 1 minute, it waits for a valid input).
– If I press any button on the remote, the green icon+red border disappear immediately
– if I extract the SD card and read the content of remote.ini, I see: “power = 3887053538”, “menu = 2823767411”, and “next = whatever code corresponds to the button I pressed”.

Was not able to reproduce the extra “55831455” from the first attempt, though after that, the GameFrame did not reboot properly (flashing white screen, or black screen with random pixels on the left and right columns). Had to re-edit the remote.ini file to put back the original codes, and then the frame did restart properly…

Looks like the IR sensor and remote do work, but maybe the code that reads it is not clearing the buffer properly? (as in if this was code that reads from the keyboard, when you call ‘readline()’ without clearing the buffer, you would get whatever the user pressed BEFORE, which would then be read immediately…”

[Christophe]

Looking at https://github.com/Jerware/GameFrameV2/blob/master/gameFrameV2.ino#L463

I see that the code that read the NEXT code does filter if the code is the same as the two before it (line 507)… maybe that would explain while it always bypass the first two, and only waits for the third: somehow, the IR sensor always reads 2 different codes “from the ether”, and only pressing a button on the remote provides a new 3rd code that makes it complete the process.

Looks like you are writing some debug stuff to a serial port. How can I tap into that? I could give you more helpful logs that way…

edit: nooooooo https://github.com/Jerware/GameFrameV2/blob/master/gameFrameV2.ino#L62 looks like I need to rebuild the thing, unless there’s a debug firmware image somewhere ?

edit2: after plugging the microUSB port on the board to my pc, I see a COM3 port, but without a debug firmware, it won’t probably read anything.

[Jeremy Williams]

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?

[Christophe]

I’m using the GameFrame remote that came in the box.

Got some codes on from the serial.

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.

But some other times, pressing the same button, I also get “IR code: 32895” (followed by the same stream of 0xFFFFFFFF until I release the button) or “IR code: 2797241768”

Here’s an example of spamming randomly the POWER button on the remote:
IR code: 2155819215 <– POWER button
IR code: 4294967295 <– “still pressed after X ms”
IR code: 2797241768 <– what’s this?
IR code: 2155819215
IR code: 2155819215
IR code: 2155819215
IR code: 2155819215
IR code: 2797241768 <– again
IR code: 32895 <– and this one?
IR code: 2155819215
IR code: 2797241768 <– again
IR code: 2155819215

Looks like there’s always the same 2 random codes that pop up: 2797241768 (0xA6BA85A8 ?) and 32895 (0x807F), which could explain why NEXT code recording works (it spins until it get a different 3rd code, which in this case is exactly what happens).

Also: the test loop that prints the code the the serial port does a ‘sleep(1)’ between reads of the remote, while the record mode does not …

[Christophe]

power = 2155819215 = 0x807F30CF
menu = 2155864095 = 0x807FE01F
next = 2155831455 = 0x807F609F

32895 = 0x807F
2797241768 = 0xA6BA85A8

First one seems to be a truncated version of the legit codes.
Second one is some random stuff.

Looking at some IR code databases, looks like 807F is the prefix for NEC devices, but the second one yields nothing…

So yeah it could be a faulty IR sensor or something? If I could run the firmware in debug mode, maybe I could see detailed logs from the irReceiver() to be sure.

[Jeremy Williams]

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.

[Christophe]

Oh no, this is not frustrating at all 🙂 The frame is pretty useable as it is, only setting the time requires using the back buttons. I’m just using this as an excuse to learn more about arduinos, IR remote codes, etc… 🙂

Yes you are right: in the “crash” test loop, it prints the correct code for the button pressed (so not only NEXT) + 0xFFFFFFFF every 150-200 ms, until the remote is released. When spamming the button on the remote, I SOMETIMES get the two weird codes (not always).

When using the remoteTest(), when pressing any button, I see the correct icon blinking two or three times, before staying put (until I release the remote button)

In the record mode, as soon as I press the button on the back, I see the POWER/MENU icons in a flash, then only the NEXT button icon (until I press a button). SOMETIMES, it will stay on the MENU icon (ie: only the POWER one flashed by). When reading the remote.ini afterwards, the first two codes are “garbage” and the 3rd one is always the correct one.

My intuition is that the remote works just fine, and that maybe the IR sensor is reading bad codes intermixed with the correct codes sent by the remote

All of the three modes above have a difference in the value of the delay that wait between reading the IR code: sleep(1), sleep(150)? and no wait at all, which could explain the slightly different behavior?

Edit: so.. pretty sure that if there is an issue, it can probably be fixed by software (even by simply blacklist the few weird codes I get sometime).

[Jeremy Williams]

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?

[Christophe]

(On mobile right now) Sorry, force of habit, not sleep() but delay() of course.

– remoteTest() waits 125 before calling irReceiver()
– recordIRCode() does not call delay()
– sdErrorMessage() seems to wait 1

With remoteTest I see icon blinking at 2 or 3 ha which is about 125ms x 2
With recordIRCode it does not wait… but maybe it waits 2 ms?
With sdErrorMessage I only see other codes when I quickly spam a button, less if I press buttons for a long time

I don’t have any activity when I don’t press a button on the remote is all 3 cases

Tried some random remote but it did not react, will need to find another remote to test

[Christophe]

(damn autocorrect) for remoteTest(): blinking 2-3-4 times about 2 or 3 *hertz*

[Jeremy Williams]

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?

Attachments:

You must be logged in to view attached files.

[Author]

Posts