Controlling two (programmable) NEC1 devices

underquark · Post by **underquark** » Mon Dec 26, 2005 4:27 am

I have a PVR device (Topfiled TF5800PVR) and control it via my URC8910 using this upgrade which covers 46 buttons total, of which some 30 or so are essential. Some people have two such devices but report problems when trying to use two in the same room (same remote codes and the IR receivers are very sensitive in this particular device).

The devices use the NEC1 protocol, device#32 with the first 32 OBC's all used apart from one code and about half of the OBCs from 64 to 95 used. I am reliably informed (by the guys here that the devices can be programmed to receive one code and map it to any given function and that this might provide a way of controlling two devices. Which of the following are correct (if any

?:

1] I can simply make two upgrades with the second one being the same as the first plus 32 and then program device #2 accordingly.

2] 1] won't work because of the way the NEC1 protocol is set up as NEC1 can't use codes 32 to 63 (and 96 to 127).

3] 2] is correct but NEC1 can use higher codes.

4] All of the above are wrong and I'm stuck with using the few unused codes in the 64 to 93 range.

My excuse for asking this rather than doing a full search which might well yield the answer is that I'm having difficulty connecting and the second excuse is that it's Christmas so Happy Christmas to one and all, by the way, and please be charitable to me.

Post by **The Robman** » Mon Dec 26, 2005 10:29 am

It might help if you post a link to the Toppy thread where they told you how to make the device respond to different codes (as I know nothing about the process).

The answer we give you very much depends on what you're able to do on the device side. I suspect that you can make the device respond to a different device code or sub-device code, in which case the button codes (OBCs) won't change.

Regarding the OBC 32 to 63 rule, I don't know what the story is there. I've seen many devices that use the NEC protocol that skip that range (and the corresponding higher ranges) but I have no idea why. There are certainly other devices out there that use OBCs in those "forbidden" ranges.

underquark · Post by **underquark** » Mon Dec 26, 2005 2:43 pm

Thanks for reply. Details of the "Toppy's" behavior will have to wait until I receive replies from some e-mails but basically the device uses a RISC processor and some sort of Linux-ish OS. The manufacturers released the spec's and several 3rd-party programs (TAPs - Topfield Application Program) have been written to correct its faults and to enhance its default behavior. Most of these trap "normal" remote-control signals such as red/green/yellow/blue to do things such as skip forwards 3 minutes, back 30 seconds or to set up keyword searches and set timers for future recordings.

The key thing is that small programs can be run on it that intercept the remote control signal before it is acted upon by the main operating system. Some codes have been found - by trial and error - that are picked up by the device but that are not acted upon. I now have information that codes 40 thru 49 have been tested and have been found to be both non-functional and "safe" so I think we might well be on our way to solving this.

Armed with your information regarding the NEC1 protocol I can see that as many as four devices could potentially be controlled but I can't see too much demand for recording 8 channels at once (although you never know). UK shut-down over festive period (hey at least the web site still works, though

) means that the various parties involved probably won't get together again for a week or two but I'll post again if and when we get it working.

classicsat · Post by **classicsat** » Wed Dec 28, 2005 2:12 pm

If some lower level software or hardware detects the NEC code and the device code, leaving you with 8 bits, you could lilkely do what you want, as the protocol in the JP1 remote (if that is what you are asking) I believe will just spit out whatever binary value you set for the key, so the lower 5 bits for 32 keys, upper 2 or 3 bits for an "address", if it is impossible to address it with device codes.

The way my understanding of the NEC code (from reading a datasheet for one of the chips), is that bits D0 to D4 are for keys 1-32, Keys 33 to 64 are respectively the same, but with D6 set. (hence the 64 to 95 value). Bit D5 is for some key shifting scheme (only a few keys support that), and bit D7 is directly tied to a pin on the encoder IC, and will refelect the logic impressed on that pin.