JP1 Remotes

The Robman wrote:Bit doubling is tricky to do, which is why UEI used so many bytes to do it. John is very clever at writing small code and it was him that came up with the "simple" code. I'll have to have a look to see if I have any documented PB files for it.

Yes, and I'm not sure why bit doubling needs to be done. It would seem that xmit 0 reversed that is used for "phase encouding" would take care of most of this without all the bit doubling. Having 3 device bytes and 1 command, and then changing that from within the protocol to make 1 device and 4 command bits, so you could take care of that odd sized byte would make a smaller protocol. But I was just trying to adjust some working code.

When we are talking John, is that our John Fine? HE is really clever at writing small code. I haven't seen him arround in a long time. Too bad, because I learned a heck of a lot from him, even though I was of the opinion that he thought I was a lost cause.

vickyg2003 wrote:I've created 3 different versions of the protocol. 3 Bins, give them a try. These take care of the Toggle bit, and repeating.

https://www.hifi-remote.com/forums/dload ... e_id=11358

Thanks Vincy,

The 3 bin files are working. I am new to JP1 and what's the different between the three rmdu? Which one would be the best one to simulate the remote I have?

ken chan 397 wrote:

vickyg2003 wrote:I've created 3 different versions of the protocol. 3 Bins, give them a try. These take care of the Toggle bit, and repeating.

https://www.hifi-remote.com/forums/dload ... e_id=11358

Thanks Vincy,

The 3 bin files are working. I am new to JP1 and what's the different between the three rmdu? Which one would be the best one to simulate the remote I have?

Hi Ken,

I was concerned that maybe not having at least one toggle frame was going to make the code less reliable.

For our JP1 remotes, we are looking for one that repeat when held, but for the slingbox, that doesn't matter since you can't hold a key.

Since all of them work, just take the smallest one for the sling.

Vicky

vickyg2003 wrote:I'm not sure why bit doubling needs to be done. It would seem that xmit 0 reversed that is used for "phase encouding" would take care of most of this without all the bit doubling. Having 3 device bytes and 1 command, and then changing that from within the protocol to make 1 device and 4 command bits, so you could take care of that odd sized byte would make a smaller protocol. But I was just trying to adjust some working code.

We tried doing that once upon a time, but this protocol has a double wide bit up front that is required and you can't re-create that by simply sending 0 reversed.

vickyg2003 wrote:When we are talking John, is that our John Fine? HE is really clever at writing small code. I haven't seen him arround in a long time. Too bad, because I learned a heck of a lot from him, even though I was of the opinion that he thought I was a lost cause.

Yup, that's who I'm talking about and yes, he has been AWOL too long!

Thanks everyone involved in this thread,

I have choosen Entone Kamai 500 - Single One Regular Frame.rmdu and generated 4 bin files for different type of chipset on slingbox hardware.

The bin files:
https://www.yousendit.com/download/TEhV ... NUpFQmNUQw

The rmdu files:
https://www.yousendit.com/download/TEhV ... VG1wSHNUQw

This can be use for entone Kamai 500 STB