JP1 Remotes

Alan - I have tried testing your draft bin file. I have a Slingbox Pro HD so had to do it through the slingbox set up way.

It accepts the bin file but nothing happens on the Sky box. I've tried looking and moving the ir cables but still no luck. I've asked a computer engineer friend of mine to pop down to look and see if the IR cables are connected fine or not.

swadez wrote:Alan - I have tried testing your draft bin file. I have a Slingbox Pro HD so had to do it through the slingbox set up way

No, you MUST do it based on my instructions and do all the checks and answer all the questions, otherwise it means nothing.

The Robman wrote:I see what you did there, very clever. When I first saw your fixed data, I wondered why there was an extra "C" in front, but I see that you carved out some of the leadin pair to make another double wide pair, which re-aligned the bytes so that the command code takes up all 16 bits of the final 2 bytes, rather than being spread across 3 bytes.

Clever, or Lazy, it works well for the JP1.2 executor, but when Swadez said it wasn't working, I realize I needed to test it here to see.

My tester had ruptured its AAA batteries and all I had on hand is AA. I had assumed that the SC308 processor would work, because there is no code. Finally got some batteries, and see that only the leadin pair is being sent, so I need to look at that a little closer to see why this is producing a flatline.

Alan, sorry, don't know what is going on with this protocol. It works with the JP1.2 engine just fine. I'll look into this later today.

Sorry about that.

so basically, you got the same results as me. We're obviously tripping some limit in the internal IR engine

Alan I have followed your instructions to the letter. Sling accepts the first bin file and remote pops up but nothing is happening on the Sky Q Mini. I have checked everything - even the IR blasters and all is well - it definitly is the file.

Has anyone got this working:?

vickyg2003 wrote:Alan, sorry, don't know what is going on with this protocol. It works with the JP1.2 engine just fine. I'll look into this later today.

No need to apologise, both you and Rob have gone well above and beyond the call of duty already. We are all very grateful for your efforts so far. Best of luck in figuring it out.

swadez wrote:Has anyone got this working:?

You jumped in before Vicky or myself had a chance to test it using an S3C8 remote, and once Vicky did test it, she got the same non-working results that I did.

My conclusion is that we are tripping a limit in the S3C8 engine and we will have to manually format the signal using assembler. I did notice that there is an executor for RC6-6-32 in protocols.ini, so it might not be that hard to reduce that one for RC6-6-28, but it is long, it's already 150 bytes so it might be a bit long for the Slingbox.

Here's a PB file for RC6-6-32
https://www.hifi-remote.com/forums/dload ... e_id=13973

Ok, I have written a new exec that should (hopefully) generate an RC6-6-28 signal. I won't be able to test this until later this evening, so if anybody is able to test this before then, to see if it generates an RC6-6-28 signal, give it a shot.

You will need to add the following protocols.ini entry first: https://www.hifi-remote.com/forums/dload ... e_id=13974

Afraid not. IR Scope is decoding it as RC6-6-36 14.2074

https://www.hifi-remote.com/forums/dload ... e_id=13975 has a couple of buttons. Do you need me to do a full learn ?

alanrichey wrote:Afraid not. IR Scope is decoding it as RC6-6-36 14.2074

https://www.hifi-remote.com/forums/dload ... e_id=13975 has a couple of buttons. Do you need me to do a full learn ?

That's great Alan, that shows a perfectly formatted signal, it's just 1 byte too long, which shouldn't be too hard to fix.

I have re-loaded the file with a correction, if you'd like to try again.
https://www.hifi-remote.com/forums/dload ... e_id=13974

Here's the PB file, for anyone that's interested:
https://www.hifi-remote.com/forums/dload ... e_id=13976

I converted Rob's file to bin and there is good news and slight bad news.

Good news is that it finally works. Bad news is that the UP button seems to be doing something else than up - its end function seems to be identical to the RIGHT button.

But apart from that everything else works great.

Amazing job guys - thanks. And past few days I've learnt a new skill sitting at home. Not sure how valuable it will be to me but it feels great and its all because of you guys.

swadez wrote:Bad news is that the UP button seems to be doing something else than up - its end function seems to be identical to the RIGHT button.

I just rechecked the learns that Alan posted and that's the code that he included, but I also notice that the UP and OK buttons use the same code. This is totally a wild assed guess, but try changing the UP code from 92 to 88.

If that doesn't work, we'll have to wait for Alan to re-learn the codes tomorrow.

Rob, I opened up the file in Protocol Builder, that must not be the correct place since the protocol flags are not listed in the assembly language. One thing I did notice is that PB and RM are setting different protocol flags. I know for a fact that if the IREngine doesn't like your PB settings, it is not going to send the signals that you expect!

If this is supposed to be opened in RM's PB, might I suggest we use RMPB instead of PB as the file designation. Otherwise people like me who still use PB, might not be able to puzzle out the protocol builder settings to make a new protocol.

This was done with the regular PB, what issues are you having with it?