JP1 Remotes

[Capn Trips]

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)
_________________
Beginners - Read this thread first
READ BEFORE POSTING or your post will be DELETED!


Remotes:Atlas OCAP URC 1056
TVs: Panasonic TH-50PE700U; JVC AV-29VS24; Sharp Aquos LC-60C46U; RCVR: Pioneer VSX-D2016S;Onkyo TX-SR875
DVD/VCR: Sharp DV-NC85 (multi-region, multi-system DVD-VCR), Pioneer DV-400VK (multi-region DVD), Sony BDP-S350 (Blu-ray), Toshiba HD-A1 (HD-DVD), Panasonic AG-W1 (Multi-system VCR); Laserdisc/CD changer: Pioneer CLD-M450; CLD-704. (But I still have to get up for my beer)

[mathdon]

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

[The Robman]

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[alanrichey]

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]

It's not in 1.98 Beta 4 either.
_________________
Beginners - Read this thread first
READ BEFORE POSTING or your post will be DELETED!


Remotes:Atlas OCAP URC 1056
TVs: Panasonic TH-50PE700U; JVC AV-29VS24; Sharp Aquos LC-60C46U; RCVR: Pioneer VSX-D2016S;Onkyo TX-SR875
DVD/VCR: Sharp DV-NC85 (multi-region, multi-system DVD-VCR), Pioneer DV-400VK (multi-region DVD), Sony BDP-S350 (Blu-ray), Toshiba HD-A1 (HD-DVD), Panasonic AG-W1 (Multi-system VCR); Laserdisc/CD changer: Pioneer CLD-M450; CLD-704. (But I still have to get up for my beer)

[mathdon]

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]

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

[mathdon]

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]

Assuming he reads this post then thanks to John as well

[alanrichey]

[mathdon]

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]

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.php?action=file&file_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

[mathdon]

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

[The Robman]

I've just received some learns that are very similar to the Amino learns in this thread, which I was alerted to as they decoded as Amino, but there are differences.

The new learns are for a Motorola Zaptor. The freq is different (36k), the toggle bit is different and the checksum is different, but the overall structure is very similar. Oh yeah, the toggle doesn't flip every repeat like the Amino version does, this one sends out a post-repeat signal with the toggle flipped.

The following zip file contains the IR files, along with some other files that may be of interest. Please note however, that the included upgrade files have not been tested yet.

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8016
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[mathdon]

Rob, I see that you have the checksum as a data byte in your rmdu file. Compared with Amino, it is a trivial checksum to calculate. The high nibble is 5 and the low nibble is (mod 16) 5 more than the sum of the six nibbles in the device, subdevice and OBC codes. This deals with the change in the checksum in the toggle frame, as the toggle appears to be the top bit of subdevice.

What do you want to call this, if I put it into DecodeIR?

Edit: That high nibble of C is presumably the checksum seed. There's another protocol like that, but at present I can't remember which one.
______________
Graham