Cricket OARK02R notes

[Stu_Rock]

I just got an OARK02R Cricket remote to use for controlling two projectors in a university classroom setting. I've been programming JP1 remotes for a few years and expected such a simple remote to be easy, but it wasn't. JP1 documentation for this unit seems to be lacking, so I thought I'd join the forum and post my findings so others can program them.

1. The Cricket is nominally a two-device remote. EDIT: You simply select which device is used for volume and which device is used for channels. See later posts for more. The following italicized text is incorrect. It is always in TV mode, and you cannot switch it to CBL, even if you assign a macro to a key that contains a "CBL" keypress. Volume punch-through governs which device is used for VOL+, VOL-, and MUTE, while "channel control lock" governs which device is used for CH+, CH-, and the number keys (on=CBL, off=TV).

2. There is a bug in the RDF file that needs to be fixed for homemade device upgrades to work. Add to the first block:

Code: Select all

2BytePid=Yes

3. The number keys accept macros only. Device upgrades do not assign functions to them. Not only that, but when a number key is pressed, the remote control appends an ENTER command to the macro, provided that the selected device has an ENTER command. See (4) below.

4. There are two "phantom" keys (CBL $90 and TV $91). These keys hold the ENTER commands sent after number keys are pressed. An aside: I disagree with calling them "phantom1" and "phantom2", since we might as well call the number keys in a device upgrade "phantoms" as well (see [3]). In my modified RDF, I call them "CBL_Enter" and "TV_Enter."

5. The ON/OFF key always sends POWER commands for both CBL and TV devices, in that order. Assigning a macro to that key does not change that behavior.

6. The remote is supported in IR and RM, but not in KM. However, KM will produce correct upgrades if you select an RCRP05B remote and use only the following keys:

Code: Select all

0,1,2,3,4,5,6,7,8,9,VOL+,VOL-,MUTE,CH+,CH-,POWER,MENU

where the first 15 keys are exact matches and MENU on the RCRP05B corresponds to the OARK02R's phantom ENTER key.

7. I neglected to test whether keymoves can be applied to the number keys or the ON/OFF key. If so, that might be a workaround to the forced macro behavior.

It took me a few hours of experimenting to understand how the Cricket works and to be able to program it how I wanted. For the two projectors, I ultimately used the NEC1 2DEV protocol to create a TV device upgrade, leaving the phantom ENTER blank. I also created a CBL upgrade that contains no key assignments and I set "channel control lock" off. I had to create 10 macros, one for each number key, each containing a single keypress of the corresponding number. After all that work, the remote seems perfect for the application. I do recommend it for applications where limited user control is required, like for children or child-like users (professors).

Code: Select all

[eferz]

I just got an OARK02R Cricket remote to use for controlling two projectors in a university classroom setting. I've been programming JP1 remotes for a few years and expected such a simple remote to be easy, but it wasn't. JP1 documentation for this unit seems to be lacking, so I thought I'd join the forum and post my findings so others can program them.

Aweseome! Thanks for the information and welcome to the forums btw.

I do recommend it for applications where limited user control is required, like for children or child-like users (professors).

Haha. I lol'ed

[Stu_Rock]

Thanks for the welcome.

It's finals week right now, so the classroom is unused and I was able to go back in an experiment a little more with the Cricket. I tried keymoves--both keypress and EFC types--and they do not work on the numbered keys or the ON/OFF key.

I forgot to mention before that I did download the factory data from the remote; I can upload the IR file if anyone is interested. It came with a CBL 1377 DirecTV device upgrade (even though the RDF indicates that 1377 is already present). Studying that led me to some of the findings that I posted earlier (regarding the 2BytePid and phantom Enter key behavior).

[Stu_Rock]

I know I'm talking to myself here, but I brought the Cricket remote home for more testing this weekend. After a lot of experimentation, I realized that a lot of changes to the RDF were necessary. I uploaded a new one to the file section, along with a tweaked map file

1. The [Settings] section was really screwed up in the original RDF. Based on 973 and 993 behavior, I deduced the correct bits for channel and volume controls. This remote doesn't really have VPT and Channel lock. You are simply forced to choose one device for volume and one device for channels.

2. There are some bits in the $00E to $013 range that are set to 1 but don't change the remote's behavior. However, if they are not set, the remote has an increased likelihood of completely freezing (requiring battery reinstallation), or sometimes reverting to a factory-default behavior (TV 0047 and CBL 1877). I put some of them in a new [FixedData] section, but some bits are in bytes used for other settings. I don't know what the standard practice is for that situation, but I added two entries with only one option each that lets the user set them correctly.

3. There's one bit in the settings that doesn't do anything but gets set to 1 after a 981 reset. I added an entry for it called "Functionless bit."

4. The ON/OFF key actually has four pre-set macros to choose from:

Code: Select all

(CBL power; TV power), (TV power; CBL power), (CBL power), (TV power)

I added that setting.

5. Keymoves are just plain not supported in this remote. I added "KeyMoveSupport=No" and "DefaultRestriction=Shift"

6. I deleted some keys from the [Buttons] section. Since keymoves are not supported, only keys in the [ButtonMaps] section can be accessed. All the others might as well not exist. EDIT: some have been restored; see below.

7. I added "AllMacroBind" restrictions to the ON/OFF (to reflect remote behavior) and phantom ENTER keys (to clean up the list in IR/RMIR).

8. As mentioned in my first post, "2BytePid" is now set.

Finally, some additional observations of the remote's behavior:
A. Macros can be assigned to VOL,MUTE,CH keys.
B. For all macros on any key, the ENTER command is appended, if defined.
C. Since there is no set/setup/magic key, the way to enter 9xx commands is by pressing MUTE and ON/OFF together for 3 sec.
D. To set the ON/OFF macro, the command is set-995-ON/OFF-#, where # is 0,1,2, or 3 (see table above). Press MUTE for 2 sec to complete the setting.

[3FG]

I don't know anything about the Cricket, but the following has me puzzled:

6. I deleted some keys from the [Buttons] section. Since keymoves are not supported, only keys in the [ButtonMaps] section can be accessed. All the others might as well not exist.

The device buttons were among the removed buttons. But why wouldn't you want to be able to change device modes in a macro? To do that via JP1 tools, the device buttons have to be defined in the [Buttons] section.

[Stu_Rock]

The Cricket does not have device buttons or device modes. Including a device keypress in a macro does nothing. I'm curious how the original RDF author even identified hex identifiers for device buttons.

Let me know if I'm neglecting some reason to include those buttons. No one will be using the classroom remote all week, so I am free to test ideas at any time.

[binky123]

The moderator, Robman, was given one of these remotes a long time ago and we looked at it and discovered the ButtonMaps and got a rough RDF going. I think you are the first user to actually post that is using the remote with JP1 tools. No one has really looked into the internal workings of this remote though. The device button hex codes($78, $77) should be left in the RDF even though they can't be generated from pressing physical buttons.

[Stu_Rock]

I did some more experimentation. A helpful behavior of the Cricket is that it appends TV_ENTER to any macro that contains invalid button codes, even if both volume and channel devices are set to CBL. Lo and behold, the only valid button codes that aren't in ButtonMaps are $77, $78, and $2E/setup (I created macros directly in the hex buffer calling out all 255 hex codes). I am impressed that Robman was able to identify those codes, since they don't really do anything in macros. I restored them to the RDF. The $72 button code in Robman's RDF is invalid.

There is one exception to the last paragraph. It turns out that you can preface an ENTER command with CBL or TV in order to select which one. And since ENTER is automatically appended to all macros, you can end a macro with CBL or TV to select which ENTER gets sent. For example, if the channel device is set to CBL and you define a macro

Code: Select all

1; 2; TV; TV Enter; 3; 4

the Cricket will send

Code: Select all

cable 1
cable 2
tv enter
cable 3
cable 4
cable enter

Another way of looking at it is that the channel device and the volume device CANNOT be overridden inside a macro, but you can choose an "enter" device.

[3FG]

The number keys accept macros only. Device upgrades do not assign functions to them.

Would you mind expanding? Do you mean that RMIR/IR won't generate the raw data bytes to upload hex data for number buttons? Or the upload of hex data is successful, and can be downloaded, but the remote ignores the assignments? Or the remote resets if it encounters an upgrade that assigns hex data to number buttons? Or ...?

Also, are the results different if the intended upgrade uses a digit table versus explicitly providing hex data?

[Stu_Rock]

The number buttons (1=$02,2=$03,3=$04,4=$05,5=$06,6=$07,7=$08,8=$09,9=$0A,0=$0B) are phantoms. You assign codes to them with an upgrade, but there is no physical key that causes the remote to send the code.

The numbered keys on the remote are macro keys. They are assigned with regular macro structures, and byte 1 does correspond to the list above.

If you neglect to set a macro to a number key, that key is inactive.

[3FG]

OK, I think I understand. It is disappointing that if no macro is assigned the key is inactive. Nearly any other UEI remote will give priority to keymoves, then macros, and then assigned hex data.

BTW, I think you're using the term phantom differently than most do here. The number buttons are real buttons, and they have button numbers associated with them. So they are not phantoms. Most people would call $2E, $77, and $78 phantoms-- the remote knows about these "button" numbers, and responds to virtual presses of these "buttons", but there is no physical button.

[Stu_Rock]

It is somewhat disappointing, since it means you can't press-and-hold a number key.

The other disappointment is that there isn't a second (actual) phantom key. For TVs, it would be really useful for the dash function, since some units require it to be punched in for ATSC channel numbers.

I do think phantom is not quite the right word for the numbers (and also power!), but it seems to get the point across. I want some way to differentiate it from VOL+, VOL-, MUTE, CH+, and CH-, which are the only keys that actually send assigned hex data.