Shuttletec Satella 2: need help modifying protocol

chuliu · Post by **chuliu** » Sun Oct 25, 2015 11:27 pm

The Robman wrote:Truth is, I don't know how you do it in RM, the manual protocol stuff in RM has always been a mystery to me. So, I created it in KM, which has better support for manual protocols, and then imported the KM file into RM.

I have set the number of repeats of the POWER/RECORD button to 8, you can adjust this higher or lower by changing the first device code in RM.

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

I am remote to the satella 2 and I ask friend to test it locally with his s2.
I changed the repeat to 255 but still it is in standby mode.
Friend said he would need to press power for 5-6 seconds for it to go to power off mode.
I don't know how to do that.
5-6 seconds translate to how many repeats.
If additional repeat is needed, can we change the first device byte to 9 bits.
I don't know if we can specify all the repeats we want with assembler.

If it cannot be done, I thank you for your efforts so far.

Thanks.

chuliu · Post by **chuliu** » Sun Oct 25, 2015 11:29 pm

BTW, why do the device bytes and command byte are set to complement?

That's why I fail to make the bin to work in the first try.
I saw that they are complement in your file and I changed that in my own file, it started to work.

I see that you set in the assembler telling the assembler to pick up the device and command byte starting from device byte 2, not device byte 1. Also, if record is pressed, it tells the assembler to repeat the number of repeats specified in the r03 register, which is the first device byte.

Nice work.

Post by **vickyg2003** » Mon Oct 26, 2015 2:21 am

Robman wrote: And Vicky, I hope you are following along too.

Yes I am. Like you, I'm unfamiliar in how to do this in RemoteMaster, but I want to learn. I currently have Microsoft Office, but I am beginning to HATE them for these W10 automatic updates. They decided it is okay to reboot my machine at 3:51AM so I just lost my whole response!

chuliu wrote:I ask because if I check nec 1 no repeat protocol, either device byte or command byte are msb( lsb unchecked)

Apparently RemoteMaster doesn't show you the LSB and COMP checkmarks on a built in, only on a custom remote. You might notice it when you do input that 1 becomes 7Fh instead of 80h or you might need to open protocols ini and see the translation.

chuliu wrote:BTW, why do the device bytes and command byte are set to complement?

That's why I fail to make the bin to work in the first try.
I saw that they are complement in your file and I changed that in my own file, it started to work.

Since the official UEI executors have the bits flipped, we do that with our NEC1 upgrades to keep them compatible and make it easier for users to switch between the various Nec executors.

Post by **The Robman** » Mon Oct 26, 2015 6:34 am

Regarding the complements, normally if I am writing an executor from scratch, I don't use complements as I don't see any need for them, but UEI almost always uses them, and since this executor is based on NEC, they just ended up that way. Truth is I didn't even think about it, but it does make sense because, let's say you wanted to add a function and you knew the EFC, if I had flipped the complement thing, that EFC wouldn't work.

As for the assembler logic itself, it's almost all pulled from the original NEC executor, so I wasn't inventing anything new. The only thing that wasn't in the original was loading R0D to set the number of repeats. I had to look at the Zenith executor to remind myself how to do that. I have been away from remote stuff for about 2 years, so I have forgotten a lot.

Vicky, if you have time, could you try loading this into a remote to verify if the RECORD button is actually sending a long signal?

Post by **vickyg2003** » Mon Oct 26, 2015 8:41 am

The Robman wrote: Vicky, if you have time, could you try loading this into a remote to verify if the RECORD button is actually sending a long signal?

Nope, it didn't repeat, it left the LED on for a duration of 7261.

Post by **The Robman** » Mon Oct 26, 2015 9:29 am

So u think it's just extending the light, but not repeating the IR signal? Curious. If you can, see if you can tweak the protocol to fix the problem. Otherwise, I can try re-working it to work my TV and try experimenting with it this evening.

chuliu · Post by **chuliu** » Mon Oct 26, 2015 9:36 am

I do have the remote on hand. If you need me to capture its signal for long pressing and pressing once, let me know.

3FG · Post by **3FG** » Mon Oct 26, 2015 10:57 am

Please do capture the two signals. It is possible that the original remote sends a different IR signal (probably a different OBC) for a long press.

chuliu · Post by **chuliu** » Mon Oct 26, 2015 11:22 am

here it is
https://www.hifi-remote.com/forums/dload ... e_id=13651

I also upload the upgrade with record and power midified to my rcrp05b and compared the signal. It seems the record button send no repeat nec1 signal with obc the same as the power of the original remote.

Post by **The Robman** » Mon Oct 26, 2015 12:07 pm

You did this capture from the original Shuttletec remote, right? If so, it confirms that both the long and short presses send the same OBC, but the first learn shows 46 repeats. The real question is, how many repeats are actually needed in order to get the device to shut down?

And on our side, we need to run some tests with the protocol that I created to see what it's really doing and what changes we need to make in order for it to send a repeating signal.

Post by **vickyg2003** » Mon Oct 26, 2015 12:32 pm

The Robman wrote:You did this capture from the original Shuttletec remote, right? If so, it confirms that both the long and short presses send the same OBC, but the first learn shows 46 repeats. The real question is, how many repeats are actually needed in order to get the device to shut down?

And on our side, we need to run some tests with the protocol that I created to see what it's really doing and what changes we need to make in order for it to send a repeating signal.

It seems to be something in the protocol flag data.none of the keys shhota a nec. I comments out the repeat stuff thinkIng maybe something was clobbering a register and I'm still getting that humongous time on.

chuliu · Post by **chuliu** » Mon Oct 26, 2015 6:04 pm

The Robman wrote:You did this capture from the original Shuttletec remote, right? If so, it confirms that both the long and short presses send the same OBC, but the first learn shows 46 repeats. The real question is, how many repeats are actually needed in order to get the device to shut down?

And on our side, we need to run some tests with the protocol that I created to see what it's really doing and what changes we need to make in order for it to send a repeating signal.

Yes, it is captured from a orogianl shuttletec s2 remote.
I capture it with ir widget set to 5000 mSec and I pressed and hold the power button till ir widget stops receiving signal. Therefore I think 46 or at most 66 repeat is enough.

Post by **The Robman** » Mon Oct 26, 2015 10:15 pm

This one should work, it holds the RECORD button on for about 6 seconds:
https://www.hifi-remote.com/forums/dload ... e_id=13650

Post by **vickyg2003** » Tue Oct 27, 2015 4:14 am

Rob,

I know that when we are going to have an executor calculate a second Function byte, that we have PB calculate the protocol bits bases on having 2 function bytes, and then change that to 1 in the assembly code,

But I don't know what to do in this situation to trick protocol builder to calculate the right protocol flags, when we are using the first byte of the fixed data for flags that are not going to be sent, and then using an index to skip past that first byte and increase the number of cbytes. I tried to fix this yesterday and then got frustrated.

Post by **The Robman** » Tue Oct 27, 2015 6:49 am

I increase R01 to make it ignore the first fixed byte.