Need help to determine remote protocol for a device..

[cgroen]

Hi All,
I hope that the combined experience of the forum can help me again
We have just installed a "hood" (?) in the kitchen here and I need to incorporate it into the buildings "intelligent house control" system. The "hood" comes with a IR remote control, which is not "kitchen friendly"

My plan is to make a device (PCB arriving in a couple of days) that will control the hood based on the input from the "house control" system (bunch of digital inputs) and also to monitor the current draw of the cooking top (hood will hide in the ceiling when not in use using wires).
This device has:
1) 11 digital inputs to receive commands from the house
2) A IR emitter output (to drive a IR emitter/emulate the remote control that came with the hood)
3) 3 inputs for 3 current transformers (monitors the 3 phases for the cooking top).

Now, I sniffed the IR codes already from the remote and I implemented these in a prototype. This works fine and I can control the hood just fine.
Now, this could "just be it", it works and I could be happy. BUT, I would like to know exactly what remote control protocol the hood is using, the only thing I know is that it is not RC5.

Do anyone of you have a clue, perhaps the timing makes you say "ahh, I know that one, thats a ____ protocol from _____" ??
The total length is approx 11 mS, the short pulses are about 260 uS and the long ones around 600 uS (makes not so much sense to talk about "short" and "long" as it is manchester encoded, but just to give you an idea of the screenshot and the pulses involved)


The screenshot of the timing below is inverted, a low is actually when there is "light" and high is when there is no IR light!

[cgroen]

No "Remote control protocol" wizards out there ?

[drussell]

Perhaps you could try taking a look on the JP1 forum?

http://www.hifi-remote.com/forums/

That's where I've always found everything to do with IR remotes... 

[Kjelt]

In the 90's the major companies had their own proprietary protocol.
This was before the low power microcontrollers and for the remote control to last >1 year on a battery they made their own dedicated RC chips.
Decoding was done in a microcontroller or sometimes also a dedicated chip.

These times are way past and in the meanwhile each and every company that uses IR just designs their own algorithm based on the succesfull ones from the past, just adjust the timing a bit so they won't bite eachother.
Just saying chances are slim they used a "wellknown" protocol for this, since it would be awfull if someone with an old fashioned VCR would change your kitchenhood from the living.

[cgroen]

Perhaps you could try taking a look on the JP1 forum?

http://www.hifi-remote.com/forums/

That's where I've always found everything to do with IR remotes... 

Thanks a lot for the hint! Seems there is a specialized forum for everything on earth 
I'll see if there is some success there, again, thanks a lot !

[cgroen]

In the 90's the major companies had their own proprietary protocol.
This was before the low power microcontrollers and for the remote control to last >1 year on a battery they made their own dedicated RC chips.
Decoding was done in a microcontroller or sometimes also a dedicated chip.

These times are way past and in the meanwhile each and every company that uses IR just designs their own algorithm based on the succesfull ones from the past, just adjust the timing a bit so they won't bite eachother.
Just saying chances are slim they used a "wellknown" protocol for this, since it would be awfull if someone with an old fashioned VCR would change your kitchenhood from the living.

Kjelt,
I think you are right! Of all the IR protocols I have looked at so far, there is nothing that compares to this one, so chances are probably very high that they "did their own". One thing that is "funny" is the variation of the pulses in width for the same button press, must be a sloppy microcontroller in the remote

[Kjelt]

Otherwise you can get working on it yourself, get all the codes you have write them down.
Probably looking at your sample you have two start bits for the AG amplifier to kick in, then two bytes, if they are smart the last byte is a checksum for the first byte, otherwise it might be group+command. You can tell by sampling all the codes you have, one sample is no sample 

[cgroen]

Otherwise you can get working on it yourself, get all the codes you have write them down.
Probably looking at your sample you have two start bits for the AG amplifier to kick in, then two bytes, if they are smart the last byte is a checksum for the first byte, otherwise it might be group+command. You can tell by sampling all the codes you have, one sample is no sample 

Kjelt,
I did just that when I started it, I have all the buttons in a Saleae file (attached), and there is a match of the first samples for each code etc.
I have attached the Saleae file as well as a spreadsheet with the codes from the (wrongly) manchester decode (signals are inverted when sampled...)

[Kjelt]

Indeed looks like 2 byte group/product - command if I quickly look.
Only thing left to check if it is a known format could be to use a Philips Pronto (it encodes the samples different and you can check then with remote.com (IIRC) if the protocol is known but that is a pretty big leap. Or some other intelligent decoder software , IIRC globalcache had something like that.
I don't know if a universal RC can identify the protocol? Those are $15 or something and sample the incoming IR then check to their internal db.
All unsure if they come up with what you are looking for.

[Kjelt]

Indeed looks like 2 byte group/product - command if I quickly look.
Only thing left to check if it is a known format could be to use a Philips Pronto (it encodes the samples different and you can check then with remotecentral.com (IIRC) if the protocol is known but that is a pretty big leap. Or some other intelligent decoder software , IIRC globalcache had something like that.
I don't know if a universal RC can identify the protocol? Those are $15 or something and sample the incoming IR then check to their internal db.
All unsure if they come up with what you are looking for.

[Kjelt]

Takes a long time to check m all 
http://www.remotecentral.com/cgi-bin/codes/

[cgroen]

Kjelt,
thanks for having a look and for the hints

The JP1 IRScope software looks nice, however I have not been able to find a "ready made, press here to buy" USB adapter for it. There are build instructions etc, but then that becomes "the project"
I also incorporated a IR receiver on my board and I have made the code so I can use that together with the remote and then let the system "teach" the codes (I store rising/faling edges on a pin IRQ together with a (RIT) timer value, this enables me to re-construct the codes instead of hard-wiring them in the code (although this is probably what I will end up doing anyway)

It was more that I got triggered and got curious if the protocol was something easily recognizable by some here on the forum
 

[cgroen]

Well,
I went with the easy solution, simply emulating the original remote control. Hood is now connected to the house control system (IHC) and it monitors the powerconsumption of the cooking top. Hood is lowered when cooking starts and raised when cooking ends. Lights are controlled using the control system of the house.
Works wonderful

A small video:
https://youtu.be/HxZpR6Oet80