RMDU for TERK TUNVR1 HDMI Video Recorder

Thomas · Post by **Thomas** » Sat Sep 30, 2017 7:01 am

Posted in Misc section of Device Upgrades

https://www.hifi-remote.com/forums/dload ... e_id=14713

You may note a few pecularities in the assignments for my setup: RCRP05B, Samsung LN37A. On this setup, I have to first power on the TERK before the tv can select the HDMI input mode. Took me a bit of experimentation before I entered 255 for subdevice, which then matched the (blank subdevice) output from the TERK remote.

BTW this inexpensive (~$50) OTA tuner does a nice job of handling tuning and USB recording. The unit is about the size of a paperback book - one limitation is that there is no bypass output to feed the source input back to the tv when the TERK is in standby (use a cheap splitter). The method for selecting channels and setting up recording is a little quirky, but usable and not too complicated. Owner's manual is in English and sufficient for use.

The main reason for generating this RMDU file is that the supplied remote is rather flimsy. Better use it as a backup and load the codes into my reliable main UEI remote.
Tom

Post by **The Robman** » Sat Sep 30, 2017 8:54 am

Thomas wrote:Took me a bit of experimentation before I entered 255 for subdevice, which then matched the (blank subdevice) output from the TERK remote.

That's because you're supposed to leave it blank, if the learns show blank. If you re-open your file, you'll notice that RM saved it as blank.

Thomas · Post by **Thomas** » Sat Sep 30, 2017 11:24 am

In this case, IRScope showed that the original remote was sending 0-0-0-0 , leaving the subdevice field blank for my UEI remote produced 0-0-F-F, and the tuner would not accept it. Changing the subdevice to 255 gave me a blank field for UEI AND 0-0-0-0 AND the tuner accepted that. As I said, took a while to figure that out.

Thomas · Post by **Thomas** » Sat Sep 30, 2017 11:29 am

Addendum:
Code uploaded to RCRP05B, with extender v1.02. For whatever reason, the only way to make it work was to use subdevice 255, which then got inverted to 0-0-0-0 in the preamble.

Post by **The Robman** » Sat Sep 30, 2017 12:37 pm

Thomas wrote:In this case, IRScope showed that the original remote was sending 0-0-0-0 , leaving the subdevice field blank for my UEI remote produced 0-0-F-F, and the tuner would not accept it. Changing the subdevice to 255 gave me a blank field for UEI AND 0-0-0-0 AND the tuner accepted that. As I said, took a while to figure that out.

Where are you reading the 0000 and 00FF from? 0 and 255 are not the same.

Thomas · Post by **Thomas** » Sat Sep 30, 2017 2:27 pm

IRScope graph from RCRP05B, I learned 'Power' keypress from original remote, then captured the learned code, graph preamble was 0-0-F-F (hex) when the subdevice was blank.
From the original remote, Power preamble in graph was 0-0-0-0, subdevice also was blank but IRP was undetermined.
Tuner would not respond until I changed the subdevice in Remote Master to 255. That produced a blank subdevice field in IRScope and tuner accepted the signal.

/edit: When creating a new rmdu file, the 255 was put into subdevice field inRemote Master. When I saved and reopened it, the subdevice field was blank, and IRScope displayed 0-0-0-0. Dunno why....

Post by **The Robman** » Sat Sep 30, 2017 2:43 pm

Let me explain the NEC protocol. There are always 2 spots for device codes, but originally all devices had the device code in the first spot and the complement in the second (a complement is the original device code subtracted from 255). But eventually they ran out of device codes, so they started using different values in the 2nd spot.

When you create an upgrade using any of the NEC variants, if you leave the second spot blank, the signal will have the complement in that spot. So, when you enter 0 as the 1st device code and 255 as the 2nd, you will get exactly the same signal as if you'd just left the 2nd spot blank (note: blank and zero are not the same).

Given that NEC is the most widely used protocol in remotes, there's no chance that our software got it wrong, which means you are reading things wrong.

Thomas · Post by **Thomas** » Mon Oct 02, 2017 11:55 am

I wish that were true -- I read what I see. THe Terk remote produced ICT captures that indicate subdevice is 'undetermined.' Building an rmdu from the hex function codes with Remote Master produced an rmir for the RCRP05B that the TERK tuner would not accept. Leaving the subdevice blank in rmdu did not work, inserting 255 did. Now, the rmir file works.

But I am beginning to think that there is another explanation. The RCRP05B had extender v3.02. I know that the extender makes learning option non-functional. I disabled the extender and tried to learn just the 'power' code. Did not work. But, after removing the unsuccessful learn, reactivating the extender, other device functions still worked ok.

So, I re-built the rmdu with subdevice 255. Successful rmdu. Added it (new device) to my RCRP05B rmir file. Everything worked. And IRScope now captures the TERK functions from RCRP05B as expected, NEC or NEC1.

So, the failed learn may have left some artifacts which interfered with the original upload. But, that TERK remote still pproduces cpatures which have subdevice undetermined.

Post by **The Robman** » Mon Oct 02, 2017 12:20 pm

Can I see both the ICT file from IRScope and the RMDU file that you created?

JP1 Remotes

RMDU for TERK TUNVR1 HDMI Video Recorder

RMDU for TERK TUNVR1 HDMI Video Recorder

Re: RMDU for TERK TUNVR1 HDMI Video Recorder