JP1 Remotes

[ncoig]

Hey all!

Glad to see these projects continue to develop.

I have used Irscrutinizer to import a RemoteMaster file, then export it to a Pronto file in order to then convert to an "Anymote" format for my phone to issue IR commands. (I found the post later that has that export ability natively, thank you!)

However, when attempting to import my TiVo (Official) RM file, on export I get an error "UnknownProtocolException: Protocol TiVo (Official) not known"

This is odd, because I see IRS is pointed at its own protocol file, and the protocol file contains the TiVo protocol...

I'm sure I'm missing something simple, but I've no clue.

Any ideas?


Thank you!

[Barf]

Yes, indeed you are "missing something simple". The word "protocol" is used to denote two different things: protocol in the IrScrutinizer/DecodeIR sense and protocol in the RM/UEI sense (preferably should be called "executer").

The problem is described here, see also the manual. In short, the import of RM files is by necessity incomplete.

But not all is lost. With some manual tweaking, it is in general fairly easy to import most RM files -- a minute or so. Please post the file it is (or a similar), and I will guide you.

[ncoig]

The problematic device is here:

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13481

I'll be looking through that link in the interim.


Thanks,

-N

[Barf]

Ok, I downloaded the file. In IrScrutinizer, it imports fine. (Import -> RemoteMaster->Load File/URL, then "Import All", and go to "Scrutinize remote/Parametric remote"). It is just that it does not quite understand the language of RM: The protocol is called "Tivo (Official)", which is not known, and the parameters are different. But let us do some "educated guesswork":

"TiVo (Official)" is likely the "tivo" protocol, so we change that. (Right mouse in the table, Advanced -> Set protocol..., enter tivo in the popup.)Still need a "D" and a "U". Looking in RemoteMaster, we see that it has one parameter called "Main Device" (instead of "Device"), which happens to be 133, and almost surely corresponds to the device, D, in the protocol tivo, so we manually fill in D to be 133 (right mouse -> Advanced -> Set D (deviceno)...). Also, we "guess" that "Unit Code" in RM corresponds to U in protocol tivo. For U, there is no column, so we have to enter it into the "Misc. Parameter" column. (right mouse -> Advanced -> set "misc. parameters", enter U=1 (three characters) there. Finished. The table can now be exported with the export functions.

That is all. Should take a minute or two.

Makes a good example .

[ncoig]

[ncoig]

So, a followup here - was attempting to export another device, this time with the "RC-5" protocol, which IRScrutinizer doesn't recognize. Using the same basic approach above, I assigned "RC5" protocol to it, which was accepted, and put in the Device under "D" - but when I export, there are 4 parameters "Param0, param5, param3 and param1" that show up under "Misc Params" in the input, and on the export are given as WARNINGS as being unknown.

How do we contend with that? Param0 is the Device ID, param5 is always 1, and param1 is always 0. Param3 is unique to each command - perhaps corresponding to the HEX or OBC for each command...

Thanks for any pointers.

-N

[ncoig]

In looking more at this, I tried to "learn" my way to a solution -- it appears that RC5 is a combo protocol, and if the OBCs exceed a certain value a flag is supposed to be set. Of course this is labelled as "RC-5" in my RMDU file, which IRS throws up on. I looked at the protocols.ini file to try and get some insight, and find out the max value for the OBC is 127, which explains why when I try to use the context menu's auto replace of "HEX" to the "F" parameter, it vomits again.

So I learned a sample signal to try and make heads or tails of what F, D, S, etc. are supposed to be, and it shows up as RC5, Device 7, no sub, OBC 27, Hex Cmd 90 91 92, T=1.

In the working RMDU file, the same command shows as device 7,OBC<64, OBC 27, Hex 90. I won't even try to understand why that is, but it eventually led to me to ditch the whole effort as a very long way to get to an end.

So, I have gathered, however, that the Device information can't be taken straight from RMIR and put into IRS, as IRS just lumps everything it doesn't know what to do with that RMIR provides into "MISC PARAMETERS"... and in my case, part of the information was the EFC, but is inexplicably labelled as HEX by IRS... ?

Eventually, I just went down and created a whole new file... which I have now and it works, but I didn't really need to employ IRS for that -- my question at the end of this is: is it just that I happen to get these devices that don't play nice with IRS, or is the import function just a "best guess" type of thing that I shouldn't expect will pull things in easily for manipulation?

Had I somehow changed the protocol to "RC5" instead of "RC-5" before the import would it have been able to read everything in correctly? Just wondering for future reference. I may be using this program for the wrong purpose?


Thank you!

-N

[Barf]

Please upload the RMDU file to the diagnostics area so that I can have a look at it.

Bengt

[Barf]

Since you did not upload the file, you probably do not care too much about it... But it is not really crucial, I know what you are talking about.

It all boils down to the question "why is the data pf RM so hard to understand for anything else than the RM program, and possibly, Dave, Graham, and Greg?"

It is simply parametrized differently. Most importantly, it is centered around the use of "hex" and/or "EFC" which are UEI-specific, while "everything else" uses OFC (= F in IRP notation). Without going into detail, it is all in protocols.ini, where the parameter syntax and sematic are defined, including the functions needed for translating them to something we can understand, To further complicate things, some executors (like RC-5) use their own functions, defined in the Java code of the main program.

[The Robman]

Hi Neil, it's basically like Bengt said earlier, it's the difference between a "protocol" and an "executor".

A "protocol" describes the signal itself, rather than any one implementation of it. In other words, you can take a learning remote/device and capture the signal and look at it, and the details of the protocol describe what you see. Those details might include that it has a carrier frequency of 38kHz, it's 32 bits long and is broken into four 8-bit chunks where the first chunk is the function code (aka "F" or "OBC"), the second chunk is the device code, and the last two chunks are the complements of those. It would also tell you the timing pairs that constitute a logical ONE and ZERO, along with any lead-in or lead-out times and a repeating pattern. (I basically just described the simple NEC format, btw).

An "executor" is a piece of computer code, written in assembler, which replicates a protocol. There are various design choices that can be made when building an executor. In simple cases, like with an NEC signal, the executor and the protocol are going to be very close matches, with the main difference being how they construct the logical ONEs and ZEROs. You may have seen the terms LSB, MSB, LSB-COMP and MSB-COMP thrown around. LSB (least significant bit first) and MSB (most sig...) tell you how to read the binary (ie, for LSB 10000000 = one, and for MSB 00000001 = one) and the -COMP part tells you if the ONEs and ZEROs are reversed (ie, for LSB 01111111 = one and for MSB 11111110 = one).

Even a simple term like "hex" has more than one meaning. For a protocol, you can think of hex as simply being a compressed version of the binary (eg, if the binary is 00001111, the hex would be 0x0F), but for an executor, the hex code that is supplied might directly become an IR signal or it might just tell the executor what to do, or some combination of the two. In a simple case, if the executor is COMP, then 00001111 would become 0xF0 rather than 0x0F.

Another thing you you can do with an executor is make it handle more than one device code (or unit code or whatever), making it a "combo" executor. To do this requires additional logic in the assembler code and ultimately it will require additional input parameters too. This is where an executor and a protocol really start to differ because you can learn a signal and it looks nice and simple, yet when you look at the RM upgrade that generated it, there are lots of additional parameters supplied. One reason might be that the device in question uses a mixture of device codes, so in order to make one upgrade that controls the whole device, we need the ability to combine all of those device codes into a single upgrade, using a "combo" executor. However, when you learn a single signal from the remote, you won't see any of that complexity. Learn the whole remote and it becomes visible.

The Tivo signal is based on the NEC protocol, but they overlaid a unit code on half of one of the complements. When UEI originally implemented this, they used a 2 byte command code for it, but eventually they realized it was better to supply the unit code as a sort of "device code" and then use assembler to drop it into place. So that's why theTivo protocol doesn't exactly match the Tivo executor.

In the case of RC5, the protocol uses a 7-bit OBC rather than the customary 8-bits, and one of the bits is mixed in with the device code bits, so what they do in the executor is, when u supply the device code, you also have to say whether you want to use OBCs in the 0-63 range or 64-127 range, then, given that they are only using 6-bits of the command code byte for the OBC, there are 2 free bits remaining, so they use these as an index to select which device code to use. So, this is a "combo" protocol where they let you supply 3 device codes (why they didn't go with four is beyond me) where each device code has the >63 or <64 encoded in it. So, for a device that only uses 1 device code, but has OBCs in the full 0-127 range, you would provide the device code twice, once with <64 set and again with >63 set. So, it's easy to see why the UEI executor for RC5 differs greatly from the pure protocol.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[ncoig]

[ncoig]

[The Robman]

I think you've basically got the concept. If I've got you curious enough that you want to tinker, you could try experimenting with the Protocol Builder spreadsheet. You can cut & paste those protocol blocks that you used to copy from KM to IR and decode them.

A simple protocol won't need any assembler, so what you see in PB will just be timings and structure. So, in the case of your iRobot protocol, it would be easy to convert it to another supported processor (and sorry, the MAXQ isn't supported).

For am executor that does have some additional logic, you can switch over to the disassembly tab to see how it works. If you start with S3C8 executors, I can answer questions as I know that one.

Here is a file where I explain all of the functionality built into the NEC executor:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2095
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[ncoig]

[The Robman]