RMIR: Prototype IR function in RM

[gfb107]

Wow Graham, you've been busy! Well done.

[vickyg2003]

Does this Alpha version contain 3FG's decodeir Alpha?

DecodeIR is not part of the RemoteMaster.jar file and these Alpha versions only provide that jar file, so it depends on what full version you are importing the jar file into. There hasn't yet been a full version with 3FG's DecodeIR, so unless you have downloaded it separately the answer is no, but Greg has said he intends to include it in the next full release.

But it comes with a newer version of Protocols.ini, so shouldn't that be in alpha with RMIR?

[The Robman]

Does this Alpha version contain 3FG's decodeir Alpha?

I just copied the 2.42 alpha version of DecodeIR into the folder where I store the 2.02 alpha 7 version of RM, then I fired up RM and checked the "About" info and it reports DecodeIR 2.41, so it's not picking up the DLL. Therefore, I assume that it has to be included when the jar file is assembled.

[gfb107]

Try copying it into the Windows sub-folder

[The Robman]

Try copying it into the Windows sub-folder

That did it, thanks Greg. Vicky, copy the alpha DecodeIR.dll into the RM/Windows folder and RMIR will pick it up.

[mathdon]

But it comes with a newer version of Protocols.ini, so shouldn't that be in alpha with RMIR?

I regard the Alpha versions of RemoteMaster.jar as just one piece of the whole jigsaw. DecodeIR.dll and Protocols.ini are two other pieces and each piece can be updated separately. You need to start with the most recent full installation of RemoteMaster and then just replace any or all of these three files - all three, to get the most up-to-date trial version. There is nothing in RemoteMaster.jar that is tied to specific versions of DecodeIR or Protocols.ini so it will pick up whatever updated versions it finds. I wish Dave (3FG) would make his DecodeIR version "official", though, as it may not be long before an "official" RemoteMaster v2.02 is merited and it would seem odd to include a Beta of DecodeIR in that.

[3FG]

Graham,
I am actually pretty far along on a version 2.43 of DecodeIR.dll. I plan to skip V2.42, because the Beta I posted was uploaded last December to RemoteCentral and listed as V2.42 without including the Beta designation.

2.43 includes support for Apple, Velleman, Velodyne, Metz, and SIM2, besides the earlier changes to Thomson and Amino/Zaptor.

The current holdup is the Amino/Zaptor decoding, because the signals are more closely related than we had believed earlier. Specifically, the checksums are calculated identically!

I received today the official spec for Amino, which is a help. I need a few more days.

[mathdon]

I am actually pretty far along on a version 2.43 of DecodeIR.dll.

Excellent! I didn't know you were working on an even newer version, so I'm sorry to have prodded you about it. There's no great hurry as far as RM/RMIR is concerned as there are some minor tweaks to the disassembler that I want to look into first. For Greg's benefit, I'll post in this thread when I feel it is time for an official release.

[mathdon]

I have uploaded RM/RMIR v2.02 Alpha 8. This makes two improvements to the disassembler:

* it incorporates those predefined constants that are specified in the Protocol Builder read-me, such as DCBUF and XMITIR, and uses them in the disassembly where applicable;

* it adds a Comments column that is used to display some (though at present, only a little) information about the data bytes of the protocol.

I am considering further improvements before v2.02 is ready for release. but may decide to leave it at this for now.

[mathdon]

I have uploaded RM/RMIR v2.02 Alpha 9. This adds to the disassembler a new panel that gives an interpretation of the data bytes, based heavily on the corresponding panel in Protocol Builder in both its design and algorithms. The lower left part of the Manual Settings dialog is now a tabbed pane, with two tabs to switch between the existing Device data and the new Protocol data displays.

I have also added further predefined constants that name additional common functions called in protocols. The information for this, like Protocol Builder itself, comes from Mike England, to whom I am greatly indebted.

I have checked the data interpretation against that of Protocol Builder for a selection of protocols for various processors, but I would be pleased to know of any discrepancies or other errors that come to light. In my checking, I discovered that there are substantial differences between the data interpretations for different processor implementations of the same protocol. The RC5 protocol, for instance, shows "Xmit 0 reversed" to be true (which is correct) for the S3C80, HCS08 and 6805-RC16/18 processors but false (which is surely wrong) for the older 6805-C9 and 740 processors. The protocol code may make up for this difference, but I found it very surprising. This is one I checked against PB, which gives the same results. Can anyone shed light on this and the many other strange differences that seem to be present?

Apart from dealing with bug fixes or other comments, this seems a suitable stopping point for v2.02. I have no other enhancements in the pipeline, though in the longer term I hope to add protocol building facilites to complement the new disassembly features.

[The Robman]

I like what you're doing with this Graham. Are you open to requests?

If so, in addition to the PD00/PD01 type labels, I'd also like to see the actual register names in the comments. For example, for a S3C8 remote, the PD00/PD01 word is actually registers R12 and R13. So I'd like the comment to read something like "PD00/PD01: R12/R13". This file lists the register names for each processor.

Would it be possible to have some user options too? For starters, it would be nice if there was an option to switch between predefined constants and the real registers/addresses. This would be useful to me as I'm more used to the register names and vector addresses than the predefined constants (as I've been coding since before PB was invented).

It would also be nice if there was an option to have all the scratch registers display as either (a) always RCn, (b) always Wn or (c) as dictated by the code. Whenever I disassemble an executor, the first thing I do is go through and change all of the RCn registers to Wn.

It would also be nice if the "Protocol Data" could be made to pop out, as the box that it's in is kinda small and therefore requires a lot of scrolling. Maybe if you double click on the tab name, that could make it pop out.

Still on the subject of "Protocol Data", it might be a good idea to have a more advanced tab too where, instead of having the options made more "user friendly" like they are in PB, the raw data is dissected and displayed in a meaningful way. This doc describes each of the bits in the protocol data bytes and what they do, so it would be cool if the UI had a drop down menu for each.

[vickyg2003]

I have uploaded RM/RMIR v2.02 Alpha 9.

Oh pooh! I just installed 8 on my machines this morning!

Nice work from what I've seen so far.

Apart from dealing with bug fixes or other comments, this seems a suitable stopping point for v2.02. I have no other enhancements in the pipeline, though in the longer term I hope to add protocol building facilites to complement the new disassembly features.

When using this for protocol development there is one more thing that still is high on my wish list. When changing the protocol I'd like the ability to deterimine whether to preserv OBC's or EFC's. If I had this capability I wouldn't have to switch between KM and RM all the time.

[mathdon]

Rob: Yes, I'm open to suggestions but I should like to pause for a while. I've had an intensive time doing this latest work to the exclusion of most other things, as it keeps things in the mind to work like that, but I'm going to take another break. I'll regard your list as a "wish list" for v2.03 if that's OK. As for

This doc describes each of the bits in the protocol data bytes and what they do, so it would be cool if the UI had a drop down menu for each.

that document only seems to apply to S3C80, though I know the HCS08 is very similar. I've been looking for the same for the other processors. The 740 and 6805-C9 seem very different.

When changing the protocol I'd like the ability to deterimine whether to preserv OBC's or EFC's. If I had this capability I wouldn't have to switch between KM and RM all the time.

Vicky, I did that at your request for v2.01. Both RM and RMIR have an item "Primacy" on their Advanced menu that does precisely that. If it doesn't work, or is not what you intended, do let me know.

[mathdon]

Rob, I forgot to mention that the RM/RMIR window is re-sizeable, and that if you increase the height then you get more of the protocol data visible. The screen resolution on my laptop is 1680 x 1050 and I can easily get the whole of the protocol data visible by stretching the RM window.

[vickyg2003]

When changing the protocol I'd like the ability to deterimine whether to preserv OBC's or EFC's. If I had this capability I wouldn't have to switch between KM and RM all the time.

Vicky, I did that at your request for v2.01. Both RM and RMIR have an item "Primacy" on their Advanced menu that does precisely that. If it doesn't work, or is not what you intended, do let me know.

Sorry, I haven't done much protocol work in the last few months.
I didn't remember ever testing that. Works like a charm. Thanks. That will be very useful!!!!!