Eratic behaviour with NEC1 protocol

General JP1 chit-chat. Developing special protocols, decoding IR signals, etc. Also a place to discuss Tips, Tricks, and How-To's.

Moderator: Moderators

Post Reply
mortod
Posts: 22
Joined: Thu Nov 13, 2003 9:39 am
Location: London

Eratic behaviour with NEC1 protocol

Post by mortod »

Let me start by saying that I'm not sure whether this is an issue with JP1 or the receiver box itself; I aquired the PVR for free as someone was junking it as his dog had eaten the remote - I was assured that the unit itself was working fine. But I am unable to test with the original remote.

It is a Humax 9200T PVR (UK), and I am using an original URC6131 2k as modified by Rob. Using the RM files available here I have set up the remote using the NEC1 protocol with device number 0.49, and fixed data 20 FF 73.

I find that the remote works fine some of the time, but at other times the receiver either ignores it completely or behaves as if I had held a remote button down continuously (eg scanning through all the channels after a single CH+ press). The receiver seems to behave fine if I use one of the few buttons on the front panel.

Is there anything odd about the NEC1 protocol, or can I modify it, eg, to extend the duration of the IR pulse emmitted after a button press? I did try modifying the fixed data to 22 as suggest in a previous post, but sure enough that just sent a double signal.

Or should I be looking for dry joints or such like inside the receiver?
The Robman
Site Owner
Posts: 21948
Joined: Fri Aug 01, 2003 9:37 am
Location: Chicago, IL
Contact:

Re: Eratic behaviour with NEC1 protocol

Post by The Robman »

mortod wrote:...at other times the receiver ... behaves as if I had held a remote button down continuously (eg scanning through all the channels after a single CH+ press).
You can easily confirm that this is not a remote issue by covering the front of the remote with your hand. If the PVR immediately stops scanning, it's a remote problem, but if it keeps scanning, it's a PVR problem.

My hunch is that it's a PVR problem.
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
mortod
Posts: 22
Joined: Thu Nov 13, 2003 9:39 am
Location: London

Post by mortod »

Thanks Rob.

I'm pretty sure the remote is not transmitting multiple CH+ commands - its more that the PVR hasn't interpreted the remote signal properly and has got into a confused state. That is why I'm thinking that a longer duration might give it a clearer signal (& hence also resolve those times when it does not seem to respond at all).

But I suspect you're right. Shame as much easier to fix the remote than try to find a fault inside the PVR.
The Robman
Site Owner
Posts: 21948
Joined: Fri Aug 01, 2003 9:37 am
Location: Chicago, IL
Contact:

Post by The Robman »

I don't think a longer duration would cause it to stop scanning the channels, logic would say that it would have the exact opposite effect.

Plus, the NEC1 signal structure is such that the data only gets sent once, after that it's a dataless signal who's only purpose is to tell the device to keep doing what it's doing, but if the device missed the data portion, it wouldn't know what to repeat.

You've already experimented with sending multiple signals (with the "22" parm) and got the results that we would have expected (ie, the device responds multiple times).
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
mortod
Posts: 22
Joined: Thu Nov 13, 2003 9:39 am
Location: London

Post by mortod »

Have been digging around and it seems this is a common performance issues with the 9200T. See discussion here, and the following quote from Humax:

http://www.digitalspy.co.uk/forums/show ... 399&page=4

While in writing we are aware that a small number of Freeview+ PVR users are experiencing issues with their remote controls being sluggish or unresponsive, and boxes occasionally locking up following the recent "National retune day" and the DSO's. This has been caused by minor changes (that Humax were not made aware of) to the broadcast signal in certain areas, and is not a hardware fault.
Post Reply