Forum Replies Created

Viewing 10 posts - 16 through 25 (of 25 total)
  • Author
    Posts
  • in reply to: Remote doesn't always register #2939
    Christophe
    Participant

    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).

    in reply to: Remote doesn't always register #2934
    Christophe
    Participant

    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.

    in reply to: Remote doesn't always register #2933
    Christophe
    Participant

    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 …

    in reply to: Remote doesn't always register #2931
    Christophe
    Participant

    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.

    in reply to: Remote doesn't always register #2930
    Christophe
    Participant

    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…”

    in reply to: Remote doesn't always register #2929
    Christophe
    Participant

    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?

    in reply to: 24 hour clock? #2928
    Christophe
    Participant

    That did the trick.

    The auto-brightness control option looks cool. I guess the only way to enable it is via the CLOCK.INI file as well?

    in reply to: Remote doesn't always register #2919
    Christophe
    Participant

    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.

    Christophe
    Participant

    Yes, that would make the queue management very easy to do server-side.

    Christophe
    Participant

    That API looks very slick 🙂 Looks like it’s easy to call custom functions or push new events.

    Does the device have the notion of a playlist/queue for animations? If multiple events come in rapid succession, is it possible to let the current animation finish, but maybe clear the current queue, and replace it with new events? Would need to be able to enqueue an animation, list the queue content, clear the queue or maybe remove some animations that have not played yet? This is to prevent symptoms like my crummy GPS interrupting itself mid-sentence “Turn left on..Turn..Turn lef..turn right on… turn left on Foo boulevard…” because it’s slower to handle voiceover than the speed of the car. It would be better to be able to do the equivalent of having it say “Turn left on Foo Boulevard. *Nevermind*, please turn right on Bar boulevard *instead*” which flows better. Not sure if I make myself clear 🙂

Viewing 10 posts - 16 through 25 (of 25 total)