JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Two devices with same protocol and Device ID. SOLVED !!!
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
javier



Joined: 20 Apr 2010
Posts: 18

PostPosted: Wed Apr 21, 2010 5:52 am    Post subject: Two devices with same protocol and Device ID. SOLVED !!! Reply with quote

I Have in my room two devices (TV and HDMI-Matrix) with the same protocol (NEC1) and device ID (0). The button code for TV arrow UP is the same as HDMI-Matrix Power, so when I press UP in remote TV, the HDMI-Matrix goes power off.
After many hours thinking, I am considering to change the IR frecuency of the HDMI-Matrix (IR Receiver transistor and clock if needed on the HDMI-Matrix, and IR LED and resonator inside its remote).
Then I can program again my One4All 8910 with this new modified remote, hoping the protocol/ID/OFC or wathever else change from the original code to a new one.
┐Do you think that this can work?
┐Any other ideas?

Edited: Final solution with a PIC chip is the best method and cost effective as well. Thanks to all for your support.


Last edited by javier on Tue Feb 01, 2011 5:51 am; edited 1 time in total
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 19869
Location: Chicago, IL

PostPosted: Wed Apr 21, 2010 7:34 am    Post subject: Re: Two devices with same protocol and Device ID ┐can this w Reply with quote

javier wrote:
I am considering to change the IR frequency of the HDMI-Matrix (IR Receiver transistor and clock if needed on the HDMI-Matrix, and IR LED and resonator inside its remote).

If you are able to do that, you should be able to get the 8910 to work it.

javier wrote:
Then I can program again my One4All 8910 with this new modified remote, hoping the protocol/ID/OFC or whatever else change from the original code to a new one.
┐Do you think that this can work?
┐Any other ideas?

We'll need to create a new executor for you that replicates the NEC1 protocol with the different frequency.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
javier



Joined: 20 Apr 2010
Posts: 18

PostPosted: Wed Apr 21, 2010 7:55 am    Post subject: Reply with quote

What is an executor?
It is a new protocol?
in assembler may be?

Thanks.
Back to top
View user's profile Send private message
cauer29



Joined: 03 Feb 2010
Posts: 235

PostPosted: Wed Apr 21, 2010 9:43 am    Post subject: Re: Two devices with same protocol and Device ID ┐can this w Reply with quote

javier wrote:
I Have in my room two devices (TV and HDMI-Matrix) with the same protocol (NEC1) and device ID (0). The button code for TV arrow UP is the same as HDMI-Matrix Power, so when I press UP in remote TV, the HDMI-Matrix goes power off.
After many hours thinking, I am considering to change the IR frecuency of the HDMI-Matrix (IR Receiver transistor and clock if needed on the HDMI-Matrix, and IR LED and resonator inside its remote).
Then I can program again my One4All 8910 with this new modified remote, hoping the protocol/ID/OFC or wathever else change from the original code to a new one.
┐Do you think that this can work?
┐Any other ideas?


Perhaps a simpler solution would be to read the manual for the TV to see how to change the ID the TV responds to? Then there should also be a corresponding way to change the ID that the original remote sends. This is a not at all uncommon feature of various TVs, DVRs, HTRs, etc to prevent conflicts.

If no such capability exists for your TV, you can do the mod that you described, where you change the IR pulse frequency to fix it, but you will need to change it a lot. That is, changing from 38KHz to 40KHz will not be enough. 38KHz to 56KHz would probably be enough. Also, no need to muck with clocks on the receiving end, though you will have to replace the IR receiver itself with one designed for the new frequency.

You should definitely not mess with the resonator in the sending remote, as that will change both the frequency and the modulation rate and it likely won't work. This can all be handled fairly easily on the 8910 with a different executor, as Rob mentioned.

A.A.
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4145

PostPosted: Wed Apr 21, 2010 9:52 am    Post subject: Reply with quote

Easiest solution would be to sell your switch and get a different one. I don't know how elaborate your switch is, but you could also try to use the auto-switching features of yours (assuming it can do it) so you don't have to use any remote commands and can simply block the receiver. For auto-switching to work well, just make sure only your active source is on and all others are off.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 19869
Location: Chicago, IL

PostPosted: Wed Apr 21, 2010 12:52 pm    Post subject: Reply with quote

javier wrote:
What is an executor?
It is a new protocol?
in assembler may be?

You will be creating a new protocol when you modify your TV. Currently it responds to NEC1, which has a frequency of 38kHz, so when you change the frequency to (let's say) 56 kHz, you will no longer be using the NEC1 protocol (and hopefully, your TV will no longer respond to the NEC1 protocol). You will instead be using a new protocol, which is similar to NEC1 but has a different frequency.

When you program your URC-8910 remote, using RM or KM, you won't be able to select the 56 kHz version of NEC1 because it doesn't exist. Therefore, one of us will need to create a hacked version of the NEC1 executor which has a frequency of 56 kHz.

An executor is a piece of assembler that invokes the IR engine that is built into your remote. Whenever you copy a protocol upgrade, what you are really copying is an executor.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
javier



Joined: 20 Apr 2010
Posts: 18

PostPosted: Wed Apr 21, 2010 5:10 pm    Post subject: Reply with quote

I understand.
Where is there any documentation about executors, and/or assembly language for the s3c80+?
Since I am a programmer with experience on assembly programming, I would like to learn about this.
Thanks.
Back to top
View user's profile Send private message
cauer29



Joined: 03 Feb 2010
Posts: 235

PostPosted: Wed Apr 21, 2010 10:59 pm    Post subject: Reply with quote

javier wrote:
I understand.
Where is there any documentation about executors, and/or assembly language for the s3c80+?
Since I am a programmer with experience on assembly programming, I would like to learn about this.
Thanks.


Don't forget the 56KHz IR receiver. Something like this one:

http://www.pololu.com/catalog/product/837/resources

You'll need to open the TV or switch, whichever one you want to change and remove the existing IR receiver, replacing it with a 56KHz version like the one above. Soldering skills will be required.

A.A.
Back to top
View user's profile Send private message
javier



Joined: 20 Apr 2010
Posts: 18

PostPosted: Thu Apr 22, 2010 6:52 am    Post subject: Reply with quote

The Robman wrote:
javier wrote:
What is an executor?
It is a new protocol?
in assembler may be?

You will be creating a new protocol when you modify your TV. Currently it responds to NEC1, which has a frequency of 38kHz, so when you change the frequency to (let's say) 56 kHz, you will no longer be using the NEC1 protocol (and hopefully, your TV will no longer respond to the NEC1 protocol). You will instead be using a new protocol, which is similar to NEC1 but has a different frequency.

When you program your URC-8910 remote, using RM or KM, you won't be able to select the 56 kHz version of NEC1 because it doesn't exist. Therefore, one of us will need to create a hacked version of the NEC1 executor which has a frequency of 56 kHz.

An executor is a piece of assembler that invokes the IR engine that is built into your remote. Whenever you copy a protocol upgrade, what you are really copying is an executor.


I found the NEC1 protocol in File Section -> JP1 File Section -> Protocols.
Is this one:
[NEC] Code.S3C80=43 8B 31 8B 12 CF ......... 12 01 8B E4
To change it to 56Khz, its enough to change the firts two bytes?
I have calculated 2E 5D, which are carrier of 56KHz and Duty Cicle 33%.
Is it correct?
Thank you.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 19869
Location: Chicago, IL

PostPosted: Thu Apr 22, 2010 7:31 am    Post subject: Reply with quote

Changing the first two bytes is the correct approach, but the NEC executor is huge, so if it were me, I would produce a scaled down version that just produced the NEC1 signal, at 56kHz, with no other options.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
javier



Joined: 20 Apr 2010
Posts: 18

PostPosted: Thu Apr 22, 2010 10:09 am    Post subject: Reply with quote

The Robman wrote:
Changing the first two bytes is the correct approach, but the NEC executor is huge, so if it were me, I would produce a scaled down version that just produced the NEC1 signal, at 56kHz, with no other options.

I agree with you.
I will use the complete version of the NEC executor just to test, and then, if it was succesfully I will ask help to you to build a reduced version.
Thank you very much for your support.
Back to top
View user's profile Send private message
javier



Joined: 20 Apr 2010
Posts: 18

PostPosted: Mon Apr 26, 2010 1:41 am    Post subject: Reply with quote

javier wrote:
The Robman wrote:
Changing the first two bytes is the correct approach, but the NEC executor is huge, so if it were me, I would produce a scaled down version that just produced the NEC1 signal, at 56kHz, with no other options.

I agree with you.
I will use the complete version of the NEC executor just to test, and then, if it was succesfully I will ask help to you to build a reduced version.
Thank you very much for your support.

This weekend I have made some tests:
I have used the protocol NEC at 40khz that I found in the file section.
Actually, I have used this protocol changing the two first bytes (freq. and duty cycle) to test it at 30, 36, 40 and 56Khz.
Incredible: The TV recognizes the codes in all frecuencies. I double checked it. Really I was sending IR codes in that different frecuencies (I used IR learning with another One4All to check it).
Another finding: May be that this protocol file has a bug. I have analized the bytes sent. I expected Device, !Device, Data, !Data (Nec protocol 1 device standard) but, I do not know why, the sencond data byte are not the complemented one (bug?). Anyway, the TV recognizes the codes perfectly. So it seems that it does not verify the comp-data.
On the other hand, the HDMI-Matrix checks this byte. So I have a protocol that is recognized in the TV but not in the HDMI-Matrix. Smile
Funny: If I could find another way to send a modified protocol NEC that it could be recognized in the HDMI-Matrix, but not in the TV, I will have my problem fixed without changing any IR receiver modules.
Back to top
View user's profile Send private message
cauer29



Joined: 03 Feb 2010
Posts: 235

PostPosted: Mon Apr 26, 2010 9:29 am    Post subject: Reply with quote

javier wrote:
javier wrote:
The Robman wrote:
Changing the first two bytes is the correct approach, but the NEC executor is huge, so if it were me, I would produce a scaled down version that just produced the NEC1 signal, at 56kHz, with no other options.

I agree with you.
I will use the complete version of the NEC executor just to test, and then, if it was succesfully I will ask help to you to build a reduced version.
Thank you very much for your support.

This weekend I have made some tests:
I have used the protocol NEC at 40khz that I found in the file section.
Actually, I have used this protocol changing the two first bytes (freq. and duty cycle) to test it at 30, 36, 40 and 56Khz.
Incredible: The TV recognizes the codes in all frecuencies. I double checked it. Really I was sending IR codes in that different frecuencies (I used IR learning with another One4All to check it).
Another finding: May be that this protocol file has a bug. I have analized the bytes sent. I expected Device, !Device, Data, !Data (Nec protocol 1 device standard) but, I do not know why, the sencond data byte are not the complemented one (bug?). Anyway, the TV recognizes the codes perfectly. So it seems that it does not verify the comp-data.
On the other hand, the HDMI-Matrix checks this byte. So I have a protocol that is recognized in the TV but not in the HDMI-Matrix. Smile
Funny: If I could find another way to send a modified protocol NEC that it could be recognized in the HDMI-Matrix, but not in the TV, I will have my problem fixed without changing any IR receiver modules.


Here's a picture showing the frequency response curve of a typical IR receiver:



If the TV's IR receiver is centered at 38KHz, then you can see that it would still respond quite readily at the frequencies that you tried. That's why I suggested 56KHz. That puts it far enough away frequency-wise, that the receiver would would not pick up much signal.

Also, mucking with the duty cycle of the IR signal will at best reduce the remote's battery life and at worst reduce the effective range.

A.A.
Back to top
View user's profile Send private message
javier



Joined: 20 Apr 2010
Posts: 18

PostPosted: Fri Apr 30, 2010 1:32 am    Post subject: Reply with quote

Thank you very much to everybody.
I fixed this problem without modify anything in the devices.
The only things I used to solve this problem was JP1 protocols, my brain, and your unvaluable help.
What I did was to build two NEC1 new protocols, one of them for the TV and another one for the HDMI-Matrix.
Both of them are NEC1 protocols to be used with device 0, but there are very different.
The protocol for the TV sends a wrong complementary byte command in the NEC1 protocol.Funny: The TV responds well to it, because does not check it. The HDMI-Matrix ignores it because is not a valid NEC1 signal, actually.
And the protocol for the HDMI-Matrix sends a command (not mapped in the Matrix to any function) to the TV before and after the real command to the HDMI-Matrix, in order to put the TV in a special menu that ignores the command to the HDMI-Matrix, and finally puts the TV in normal mode again.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 19869
Location: Chicago, IL

PostPosted: Fri Apr 30, 2010 7:17 am    Post subject: Reply with quote

Congrats Javier, I'm going to keep your HDMI fix in mind for the next time someone posts about 2 devices responding to the same protocol.

If you haven't already done so, please zip your files together and post them.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central