JP1 Remotes

This device is decoding as:

RC6-6-56 230.-176160769x (x=3, 4, 6...)

I've posted the ICT file for a few sample buttons at
https://www.hifi-remote.com/forums/dload ... e_id=11445

Any thoughts ? Easy fix or a full manual decode ?

Al

You might as well give them to us all up front. There is no simple way for you to figure out what the OBC is really going to be, from the decode. The midframe burst combined with the phase encoding, is giving decodeIR fits.

OK, file updated with all buttons. Sorry to lumber you with that amount of work

alanrichey wrote:OK, file updated with all buttons. Sorry to lumber you with that amount of work

I appreciate your trying to save us work. In that spirit, I have translated these to IR filles so the decoding experts can use the IR tools to find the 1's and 0's.

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

I think this is going to be a very complicated executor. I hope that the person you are helping will stick through the process.

This protocol reminded me of something that I worked on a while back.

Ken had posted a Entone signal that had decoded as Replay in the protocol decode section. I had arrogantly moved this to the slingbox forum, only to find that these replay decodes wouldn't respond to replay codes. Then I couldn't find it, because it wasn't in the protocols decode forum, so I had to move it back, so that I could find it again.

https://www.hifi-remote.com/forums/viewtopic.php?t=14247

Here are my files:
https://www.hifi-remote.com/forums/dload ... e_id=11447

The zip file contains:

• the IR files that Vicky created
• the text files where I manipulated the learns t get the binary
• an Excel file where I convert the binary to hex and decimal
• the PB file
• the KM file
• an RM file derived from the KM file
• Slingbox binary files

Hey Rob, I tested the output and the midframe burst seems to be too big and in the wrong place.

Do you want me to follow through with the debugging, or do you want to do it?

Could you follow thru please. What does the mid-frame burst look like? It should be -880 +880 (plus of course, the times may get merged with the pair that precedes or follows).

Could you post an IR file of the results?

Duh! The mid-frame burst thing isn't going to work here because the pair needs to be sent reversed. My code will generate +880 -880 when it should be generating -880 +880. We will need to re-work the ReplayTV protocol to get an executor for this.

Yes, it needs to be reworked. I think besides reversing, we might be missing some half bits around the midframe burst.
Here is a picture of the comparisson for those of us that use the etch-a-sketch approach.


Uploaded with ImageShack.us

These two ICTs are here
https://www.hifi-remote.com/forums/dload ... e_id=11449

I suppose you wanted the whole set, but I'm sitting in the car and don't have my JP1 tools with me. The weather here is foul, or I'd go back and get them to make a proper post.

Once I figured out the mid-frame was wrong, I didn't need the files any more. Basically, I just need to grab the code for the Replay signal and extend it.

And you need to get internet service!

The Robman wrote:Once I figured out the mid-frame was wrong, I didn't need the files any more. Basically, I just need to grab the code for the Replay signal and extend it.

I was thinking the same thing, but the Replay uses 1 bit for every 440us. Isn't this signal too long to do that? Isn't the DCBuf in the samsung chip limited to 10 bytes?

And you need to get internet service!

Don't I though! Especially when there are 50 mph winds and driving rain!

vickyg2003 wrote:I was thinking the same thing, but the Replay uses 1 bit for every 440us. Isn't this signal too long to do that? Isn't the DCBuf in the Samsung chip limited to 10 bytes?

I haven't had a chance to re-visit the Replay executor yet, but it does require the bit doubling to be done before you enter, so John's version might not work, we may need to go back to the original UEI version, or at least the version of it that I modified to only use 1 variable byte, because that version did the bit doubling in the executor, so it used less input variables. The drawback is that the executor is much larger, which might limit how many buttons you can include in a Slingbox upgrade.

OK, I just revisited the old $0092 executor and I see what you mean, I thought it was sending the pairs manually but I see that it's using the IR Engine after the bits are doubled, so it would need more than 10 input parms.

Maybe the way to do it is to break the signal into two.

Here's the Entone signal:
+2640 -880; 1110 -880 +880 11100110 00000011 10010110 11111111 11111111 1111 00000111 0000 -130000

Part one could be:
+2640 -880; 1110 -880

part two could be:
+880 11100110 00000011 10010110 11111111 11111111 1111 00000111 0000 -130000

OK, I tried re-building the ReplayTV executor using the above concept (because I could test it on my ReplayTV) and guess what, I did it and it works!!!

Here are the KM and PB files:
https://www.hifi-remote.com/forums/dload ... e_id=11450

We can now use this to build an Entone executor.