Your Universal Remote Control Center
RemoteCentral.com
Philips Pronto NG Family Forum - View Post
Previous section Next section Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Topic:
Asus "digmatrix" media PC controling problem
This thread has 8 replies. Displaying all posts.
Post 1 made on Sunday August 28, 2005 at 06:46
oferpeleg
Long Time Member
Joined:
Posts:
November 2003
34
Hi,

I ran into a controling problem (with RF UNIT) over this media pc,
I tried everything i know about IR codes (long,short,duration,clean,dirty ... )
And IR emitter location was checked.
And still i can't control this PC.

Directed IR is working.

Do you thing that This media Pc is NOT controllable with an RF unit ???


Please help.

Ofer.
Post 2 made on Sunday August 28, 2005 at 07:49
Boarderbiker
Long Time Member
Joined:
Posts:
December 2003
135
Are you saying that your PC is running Windows Media Center using the IR receiver, remote, and IR blaster kit intended for use with Windows Media Center?
OP | Post 3 made on Sunday August 28, 2005 at 15:40
oferpeleg
Long Time Member
Joined:
Posts:
November 2003
34
No, i'm talking on a HTPC in a box (by asus) .

[Link: digit-life.com]
Post 4 made on Sunday August 28, 2005 at 16:39
Boarderbiker
Long Time Member
Joined:
Posts:
December 2003
135
Sorry, but I find your original post confusing. Your subsequent post only clears things up slightly. You are mentioning IR and RF and apparently interchanging them. FYI, IR=InfraRed RF=Radio Frequency. They are totally different. Since this problem has still not been explained in a clear, concise way any help received will be limited.

Are you trying to learn the codes from the remote pictured on the link in your previous post? Are you learning the codes but they don't work? Which remote are you using? Are you even using a Pronto? Are you having difficulty using the stock remote? Give us more info and maybe we can help.
OP | Post 5 made on Monday August 29, 2005 at 11:09
oferpeleg
Long Time Member
Joined:
Posts:
November 2003
34
OK,
so lets clear things out :

I'm using ProntoPro 980(tsu-7000) with the latest firmware,i had learend the codes from the original remote in the most "clear" way the IR codes are still long (5 raws).
In IR mode i can control this HTCP,but the control is not perfect(sometimes it misses a function).
In RF mode(with RF extender) the HTPC is'nt reacting at all (one movment to 15-20 button press).

the "up" code look like this :

0000 0064 0000 001A 0174 00B9 0019 0015 0019 0015 0019 0044 0019 0044 0019 0015 0019 0044 0019 0015 0019 0044 0019 0044 0019 0044 0019 0044 0019 0015 0019 0044 0019 0015 0019 0015 0019 0015 0019 0015 0019 0015 0019 0015 0019 0044 0019 0015 0019 0044 0019 0044 0019 0044 0019 04A3

As i said before it's clearly not an IR emitter problem (replaced IR emitters,switched places and etc)

all the rest of the system componnets are working fine in RF mode.

I hope i gave you all the info you need to help me.

Thank you.
Post 6 made on Monday August 29, 2005 at 17:38
Boarderbiker
Long Time Member
Joined:
Posts:
December 2003
135
Sorry, I've got nothing. Perhaps one of the gurus who are following this thread can spot something in the posted code.
Post 7 made on Monday August 29, 2005 at 20:42
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
The protocol of that learned signal is one I've seen before only in Dgtec HDTV receivers. I didn't really understand what sort of brand/device this thread is about, so I don't know if there is any connection.

The device number and frequency of your sample are different from the Dgtec HDTV. It makes sense for the device number to be different if the brand or model is different, and a learning error couldn't cause that device number change.

But the frequency change is more questionable. It might be right. But it is luncommon for a different brand/model using the same distinctive protocol to change the frequency. It is fairly common for an NG Pronto to learn a seriously wrong frequency.

If the frequency is wrong, that might be the reason the signal is unreliable by direct IR and even worse by RF.

Before leaping to that conclusion, I'd like to see several more signals to see if it really is the protocol it seems to be from that one sample and to see how the frequency varies across learns.

I just made a .irp file for Dgtec, which I'll paste in below. You can try that with my MakeHex program (discussed in many threads here). The command you pasted in was device 172, command 23. You can take the Pronto Hex for command 23 from the MakeHex output and try that in place of your up command. If it helps then frequency was a problem. If it doesn't frequency still might be a problem, but not the key problem.

Device=172
Function=0..255
Frequency=38000
Time Base=560
Zero=1,-1
One=1,-3
Form=;16,-8,D:8,F:8,~F:8,1,^108m
OP | Post 8 made on Tuesday August 30, 2005 at 02:53
oferpeleg
Long Time Member
Joined:
Posts:
November 2003
34
OK,

I'll try your Hex maker....

some more codes:

HOME: 0000 0065 0000 001A 0170 00B7 0018 0015 0018 0015 0018 0043 0018 0043 0018 0015 0018 0043 0018 0015 0018 0043 0018 0015 0018 0043 0018 0015 0018 0015 0018 0015 0018 0043 0018 0015 0018 0015 0018 0043 0018 0015 0018 0043 0018 0043 0018 0043 0018 0015 0018 0043 0018 0043 0018 0496

POWER: 0000 0065 0000 001A 0170 00B7 0018 0015 0018 0015 0018 0043 0018 0043 0018 0015 0018 0043 0018 0015 0018 0043 0018 0015 0018 0015 0018 0043 0018 0043 0018 0015 0018 0015 0018 0015 0018 0015 0018 0043 0018 0043 0018 0015 0018 0015 0018 0043 0018 0043 0018 0043 0018 0043 0018 0496

PLAY: 0000 0064 0000 001A 0174 00B9 0019 0016 0019 0016 0019 0044 0019 0044 0019 0016 0019 0044 0019 0016 0019 0044 0019 0044 0019 0044 0019 0016 0019 0016 0019 0016 0019 0044 0019 0016 0019 0016 0019 0016 0019 0016 0019 0044 0019 0044 0019 0044 0019 0016 0019 0044 0019 0044 0019 04A3

NUM 1 : 0000 0065 0000 001A 0170 00B7 0018 0015 0018 0015 0018 0043 0018 0043 0018 0015 0018 0043 0018 0015 0018 0043 0018 0015 0018 0015 0018 0015 0018 0015 0018 0015 0018 0015 0018 0015 0018 0015 0018 0043 0018 0043 0018 0043 0018 0043 0018 0043 0018 0043 0018 0043 0018 0043 0018 0496

NUM 2 : 0000 0064 0000 001A 0174 00B9 0019 0016 0019 0016 0019 0044 0019 0044 0019 0016 0019 0044 0019 0016 0019 0044 0019 0044 0019 0016 0019 0016 0019 0016 0019 0016 0019 0016 0019 0016 0019 0016 0019 0016 0019 0044 0019 0044 0019 0044 0019 0044 0019 0044 0019 0044 0019 0044 0019 04A3

Thank you johnsfine !

Ofer.
Post 9 made on Tuesday August 30, 2005 at 10:48
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
I hope MakeHex (and changing the frequency) solves it for you. But those new samples make me less confident that it will.

Those are pretty consistent at the higher frequency. I don't expect NG Protos to be that consistent when learning frequency incorrectly.

I think your issue may have more to do with the process of relaying IR through RF than with the signals themselves. I don't know enough about either your physical setup or the Pronto NG RF system to give you much help with that. Hopefully you can get another expert interested.

On general principles of IR/RF relay, the first thing I would investigate is whether there is a second (or more) path for the signal to ultimately reach the device as IR. Any time there are two paths there is the possibility for them to interfere with each other. If I understand correctly (don't bet on it) the NG Pronto itself sends either IR or RF but not both together, so the common (in other IR/RF remotes) two path problem (direct IR from remote and IR via RF) shouldn't be an issue. But do you have multiple emitters or other ways to get two path issues?

The other big issue is emitter placement. Are you really sure you know the spot on the device where it receives IR? Even knowing that, is the emmiter too strong or too weak? Does it need to be further away or does it need to be aimed better or what?

On 08/29/05 11:09 ET, oferpeleg said...
As i said before it's clearly not an IR emitter
problem (replaced IR emitters,switched places
and etc)

Maybe you know a lot more about emitter issues than I do. But I don't see how the above statement could be valid. There are so many ways in which a problem like thos could be an emitter problem, and the testing gives you such poor information about which direction thing are flawed in. I think you never know it wasn't an emitter problem until you solve whatever it actually was.


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse