Amino set-top box Aminet110

Capn Trips · Post by **Capn Trips** » Sat Aug 22, 2009 11:08 am

mathdon, fyi (an incomplete list):

0181 ToadTog
01FE Device Multiplexer
01FC Device Specific Macro
01FB Pause
01F9 Long/Double Keypress
01F8 Custom Mode Name (for LCD display)

Post by **mathdon** » Sat Aug 22, 2009 11:33 am

Sorry, I didn't think of Special Protocols

. I'll change to 01Ex values. I know that the "standard" ad hoc code is 01FF, which is fine in PB, but if you are putting them into protocols.ini then they will be used by users who do not know about editing protocols.ini to change the PID. I hope Rob will come up with some ruling on what we should do, as it seems to me to defeat the point of adding non-UEI protocols to DecodeIR if they are not also in RM so that users can make use of what DecodeIR tells them.

I know Rob said in some post or other, when I started adding things to DecodeIR, that we can make it so that it is irrelevant to users whether or not a protocol is a UEI one or one of our construction. That's what I am trying to do.
_____________
Graham

Post by **The Robman** » Sat Aug 22, 2009 4:12 pm

Here's a possibility, but it would require an IR change. We could add all custom executors to protocol.ini as $01FF then when the user copies the code over to IR, if it detects that there's already a different protocol upgrade present that's using the $01FF pid, it could automatically change it to something else. (We'd need to define a list of acceptable alternative pids).

I guess the problem with this suggestion is that the user has to paste the device and protocol upgrades separately, so IR won't know which upgrade should use the $01FF pid and which should use the new pid, unless it keeps a copy of the original IR file in it's memory.

I've been thinking for a long time that it might be a good idea to come up with a combined upgrade format which would let the user paste the device and protocol upgrades at once. The benefit of doing this would be that IR would know which upgrade goes with which executor and it would make things a bit simpler for the user.

alanrichey · Post by **alanrichey** » Tue Oct 06, 2009 4:22 am

I notice Amino is now sensed as a valid protocol by IRSCOPE but hasn't made it into RemoteMaster 1.96 ? Is that likely to happen ?

Capn Trips · Post by **Capn Trips** » Tue Oct 06, 2009 5:48 am

It's not in 1.98 Beta 4 either.

Post by **mathdon** » Tue Oct 06, 2009 11:18 am

It's up to Greg whether he puts Amino, and other protocols that I have added into DecodeIR, into RemoteMaster but you can put them in yourself. If you have any of the recent IR 8.01 RC versions, you will see that the zip package contains a folder "protocols.ini Add-in", in which is a file "protocolsX.ini" and some read-me info. You can copy any or all of the 8 entries in "protocolsX.ini" (these .ini files are ordinary text files) into the protocols.ini file in your RM folder and then they will appear along with all the others when you open RM. RM 1.96 and later include CanalSat from my extras, but not the other 7. I think the problem is that although CanalSat has an official UEI PID, Amino and most of the others do not. I have given them PIDs that (at that time, at any rate) appear to be unallocated, but you can always change them if you wish when you copy the entries into protocols.ini.
_______________
Graham

alanrichey · Post by **alanrichey** » Tue Oct 06, 2009 12:06 pm

Thanks Graham , all done.

Could I also take this opportunity to give you my thanks for DecodeIR, as I am now using IRSCOPE and DecodeIR 2-3 times a day making Custom Remotes for people who have Slingboxes and do not have supported devices. Using these tools make it very easy to produce the remotes and although they thank me I know I couldn't do it without you

Now if only IRSCOPE could remember settings between sessions...

Cheers

Al

Post by **mathdon** » Tue Oct 06, 2009 2:26 pm

Thanks, Al, but John Fine is the brains behind DecodeIR. My part is only the recent enhancements (v2.37 and the under-development v2.38).

As for IRScope, I agree. I would also like to be able to re-size the window. I've thought of looking into that, but I don't want to stick my fingers into everyone's pies or I'll get a reputation for meddling in other people's business when it is not wanted. I'm only trying to help out when original developers no longer have the time to do so.
________________
Graham

alanrichey · Post by **alanrichey** » Tue Oct 06, 2009 2:30 pm

Assuming he reads this post then thanks to John as well

alanrichey · Post by **alanrichey** » Tue Oct 20, 2009 1:58 pm

mathdon wrote:If you have any of the recent IR 8.01 RC versions, you will see that the zip package contains a folder "protocols.ini Add-in", in which is a file "protocolsX.ini" and some read-me info. You can copy any or all of the 8 entries in "protocolsX.ini" (these .ini files are ordinary text files) into the protocols.ini file in your RM folder and then they will appear along with all the others when you open RM.

I did this, and used the TDC protocol in anger the first time today. The problem I have is that about half of the buttons do not register (4 of the 10 numbers for example). Inside RM this protocol allows only codes from 0-63 and I have tried all these codes with no success.

I am wondering if these buttons need codes higher than 63. Is there any way I can amend the protocol to try these higher numbers ?

Post by **mathdon** » Tue Oct 20, 2009 3:42 pm

Hi Alan

I'm not sure what you mean by "do not register". Do you mean you can't reproduce them? Have you any info about these buttons? A .irc file from IRScope with their signals, for example? From the data I have, TDC protocol only uses 6-bit commands (0-63). If there were a 7th bit it would mean that I have the division between command code and subdevice wrong. I don't know if you are using the default subdevice code (26), but if you are, try 27. If you are using any other subdevice value, if it is even then try adding 1, if it is odd try subtracting 1. But if you have no success with this, please give me as much info as you have about the signals you can't reproduce.
_____________
Graham

alanrichey · Post by **alanrichey** » Wed Oct 21, 2009 1:25 am

Hi Graham

OK, a few more details. The remote I am trying to learn is a Tilkin Mood 400. I have loaded it on my Harmony Remote and used IRScope to check the codes. It happily decoded many of the keys as IR Protocol TDC-38, Device 8, Sub-Device 10. Other keys were not recognised as valid.

Testing by the actual owner showed the Protocol and device/sub-device is working OK for some keys, so your basic logic must be correct.

I have posted 4 ICT files at http://www.hifi-remote.com/forums/dload ... le_id=7393 that will hopefully help

These demonstrate the following examples:

Button 1 is happily recognised as above and with Code 15

Button 2 is not recognised by IRSCOPE as a valid code. Subsequent testing with the owner showed it is actually the same protocol/device with Code 1.

Button 3 is not recognised by IRSCOPE and although the user tested all 64 codes, none of them activated the '3'.

Button 4 is happily recognised as above and with Code 16

If you need any more info let me know.

Cheers

Al

Post by **mathdon** » Wed Oct 21, 2009 6:43 am

Al, you have found a new variant of the TDC protocol. What was thought to be a 6-bit OBC with a 1-bit check bit seems actually to be a true 7-bit OBC. I will amend DecodeIR.dll to handle this in the next release, and send you privately a temporary fix.
______________
Graham