JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

IrScrutinizer: capturing, generating, analyzing, import, exp
Goto page Previous  1, 2, 3 ... 21, 22, 23, 24  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Wed Jul 01, 2020 9:05 am    Post subject: Reply with quote

Not the foggiest. Surprised Cannot reproduce, neither on my Windows 32-bit nor the 64-bit.

What happens when you double click on a jar file is mainly how the system treats java/jar files. So let's leave that out for now.

Things to try:
* reinstall java. And tell the version (java -version).
* Install IrScrutinizer *with* its embedded java jvm. You can use that for RM too, with a command line like

"c:\program files(x86)\IrScrutinizer\jre-x86-windows\bin\java -jar ...\RemoteMaster.jar

* try the irptransmogrifier.bat with argument (for example) version.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3610
Location: Cambridge, UK

PostPosted: Wed Jul 01, 2020 9:30 am    Post subject: Reply with quote

I can comment out the Decoder( tmDatabase ) line and RMIR opens but with learned signal decoding not working. So it is not a problem of Java not opening RMIR but of what happens during the opening process. The bigger issue for me is the CI builds of IrScrutinizer. I will try a .bat file for that.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3610
Location: Cambridge, UK

PostPosted: Wed Jul 01, 2020 10:00 am    Post subject: Reply with quote

Solved Embarassed Embarassed Embarassed . I was building the RemoteMaster.jar file with the wrong snapshot of IrpTransmogrifier. I had updated the build path in Eclipse but not that in build.xml for the Ant build of the jar file.

The issue of IrpTransmogrifier / IrScrutinizer not opening was due to mental confusion in my flustered state after trying to sort out the RemoteMaster problem. IrScrutinizer does open on double-clicking the jar, IrpTransmogrifier both does not and should not, as it isn't a GUI. Sorry for bothering you. Embarassed Embarassed Embarassed .
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Fri Jul 03, 2020 2:58 am    Post subject: Reply with quote

mathdon wrote:
Earlier in this thread I wrote:
mathdon wrote:
I have also made a change to the IRP of RC6-6-20 to change T from an automatic parameter to a specifiable one, as the 0020:2 executor has T as a device parameter. The notes say that this is commonly used by Sky and Sky+ remotes and the executor notes say that Sky does not toggle T.

I have since realized that this is not an isolated issue. There are nine RC6-M-N executors in protocols.ini for various values of M and N. Of these, T does not toggle in five of them and three of the remaining four select between toggle and no-toggle with a device parameter. The only one in which T always toggles is 0058:2, the RC-6 executor that is also the RC6-M-16 executor. So some means needs to be found to incorporate into irpProtocols.xml those executors that provide a choice between toggling and non-toggling behaviour.

A first thought might be to have two entries, such as RC6-6-20 and RC6-6-20n with the latter being non-toggling. These would have different IRPs, reflecting their T behaviour.

I (now Wink) agree with you totally. Having both toggling and non-toggling "dialects" would be awkward.

Quote:
However, as far as I can see, IrpTransmogrifier and IrScrutinizer behave identically, despite the difference in IRP. On decode, the value of T is shown in both cases, and on generate, T is specified and repeated generation keeps the same T value rather than toggling with one and not with the other.

This is not correct. The rendering engine for a toggling protocol does indeed toggle between successive invocations (unless the toggle variable is explicitly given).
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Fri Jul 03, 2020 3:01 am    Post subject: Reply with quote

mathdon wrote:
If I make a selection and then press Open, the directory that opens is the previously selected one, not the current one, and the selection appears to have no effect on the folder offered for entering a filename when exporting (with Automatic file names turned off).

On a second look, I indeed found a bug. Thanx for telling me.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3610
Location: Cambridge, UK

PostPosted: Fri Jul 03, 2020 5:43 am    Post subject: Reply with quote

Barf wrote:
The rendering engine for a toggling protocol does indeed toggle between successive invocations (unless the toggle variable is explicitly given).

Thanks for pointing this out. If I generate an RC6 Pronto signal in IrScrutinizer with a blank T and decode that in IRScope, I see that it does indeed toggle. I tried testing this before I posted that statement, but I did so by pressing "To param. remote" on the Generate tab, rather than Generate. It goes into Parametric Remote with a blank T. I had expected, and think it would be preferable, if in this situation it showed an explicit T value that toggled on successive insertions into that table.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3610
Location: Cambridge, UK

PostPosted: Sat Jul 04, 2020 9:16 am    Post subject: Reply with quote

I am trying to find out in what circumstances a toggling signal actually toggles when transmitted with IrScrutinizer. What I had hoped was as follows. I have used RMIR to export my entire URC-6440 as a Girr file and have imported that into IrScrutinizer. It includes a remote (in your terminology) with RC5 signals. If I select one of those signals and "Transmit selected" several times, all the signals captured by IRScope have T=0. There is no T value set in the Girr file, and this is confirmed if I do "Import select/param" on that signal. It goes into "Scrutinize remote" with the T-value blank. However, if I put its parameters into the Generate tab and press Transmit, the signal does toggle. Similarly if I press Generate, I can see that the generated Pronto toggles.

What I was hoping to do was to refine my Export to Girr process in RMIR so that on importing the Girr into IrScrutinizer and transmitting the signals from the Import tab, the toggle behaviour was that of the executor of the exported device upgrade. So from my URC-6440 the RC5 signals would toggle and the RC6-6-20 signals (I have a Sky+ box) would not. The export process as it currently is will never set the T value, so I was expecting both the RC5 and RC6-6-20 signals to toggle. The hope was to set the T value explicitly for non-toggling signals and leave it out for the toggling ones, in the belief that the generated signals would then either toggle or take their fixed value accordingly. But with the current behaviour of IrScrutinizer, that won't work, none of the signals would toggle.

Is this a bug or planned behaviour? If the latter, can it be changed? It would be really nice, from a logical point of view (even if unlikely to be used in practice) for the export process to export the correct toggle behaviour.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Sun Jul 05, 2020 5:05 am    Post subject: Reply with quote

I am not quite sure what you goal is. Recall that (as the name suggests) IrScruitinizer is not intended as a deployment remote.

IrScrutinizer handles toggles correctly in import and export. The values, including "no value" are preserved. By export in a few formats (Girr, Text, irplus, possibly some more), raw and Pronto Hex for all possible toggle values are generated. (OK, it is assumed that the toggle variable is called "T".) Explicit values in "Parameteric Remote" are honoured.

What is not (at least not yet) implemented is toggling in the "Parametric remote" and "Import" tree view. In the view of the above, this is "not implemented", and not "bug".

Have I understood you correctly?

Having said that, I don't think it would be too hard to implement: just to recycle all instances of NamedProtocol instead of new-ing.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3610
Location: Cambridge, UK

PostPosted: Sun Jul 05, 2020 7:59 am    Post subject: Reply with quote

Barf wrote:
IrScrutinizer handles toggles correctly in import and export.

I am not questioning that. I am questioning the handling in Transmit. One can transmit from the Generate tab and also from the Import tab. From the Generate tab a signal with an unspecified T value toggles. From the Import tab it does not. This to me is an inconsistency, even if it is not a bug.

You ask what is my goal. I could reply by asking you what was your goal in suggesting that I implement, as I have done, the export of an entire remote (in the RMIR sense) as a Girr file containing multiple remotes (in the IrScrutinizer sense). The only place such a file can be imported in IrScrutinizer is in the Import tab, on which a command can be selected and then transmitted. My goal is to have that transmission being a correct reflection, for toggling protocols, of the toggle behaviour set in the device upgrade of the RMIR remote. This does not seem to me to conflict with any design principles of IrScrutinizer.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3610
Location: Cambridge, UK

PostPosted: Tue Jul 14, 2020 12:40 pm    Post subject: Reply with quote

In testing your new RMIR feature for exporting timings as a Girr file, I have done the following. I loaded this file from the Cap'n into RMIR v2.11 build 3 and set the frequency tolerance to 3500Hz so that the NEC2 files with an unusual frequency would decode. I also exported the timing summary as a .girr file, set the frequency tolerance in IrScrutinizer to 3500 and imported the Girr file.

I expected the decodes in RMIR and IrScrutinizer to be the same, as they are both using IrpTransmogrifier on the same data, but they are not. What shows in RMIR as NEC2 shows only as NEC in IrScrutinizer, and four signals that do not decode in RMIR show as NECx2. But they are not actually NECx2, they are NECx1 with a 1-bit where there should be a 0-bit in the repeat, so as far as I am concerned, RMIR is correct in not decoding them.

Why the difference?
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Wed Jul 15, 2020 2:20 pm    Post subject: Reply with quote

With your latest protocol patches (and increased frequency tolerance), all the > 40000 Hz signals look ok. The reason for the (agreed, erroneous) NECx2 is this: The decoder finds the intro signal, it is satisfies with that, and outputs NECx2. (recall, the D:1 is only part of the repeat). So we do not like this, and it seems like we should not accept a signal as NECx2 unless it has a matching repeat. Theoretically, this can be achieved with a "+" instead of "*" in the IRP, but this has other disadvantages. So therefor there is a parameter "reject-repeatless". I see that in the file there is this parameter set, but commented out! I cannot remember why or when!!

Anyhow, out-commenting-out, and the decode is gone. Instead NECx-f16 shows up, but this is OK, since it denotes a repeatless signal, and is (through "decode-only") not a first class decode.

So I suggest putting "reject-repeatless" in the NECx2 protocol. OK?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Wed Jul 15, 2020 2:35 pm    Post subject: Reply with quote

Addressing the need to chop monster signals (for example from IrScope), I have implemented some new functionallity.

The ICT importer can optionally chop the import according to the user parameter chopThreshold (default 100ms). Works like this: every time a silence >= chopThreshold, there is a cut.

In the "Scrutinize raw remote" there is a new entry in the popup menu: "Chop selected signals at long gaps". This works similarly; the selected signals are chopped and the chopped-of parts added as signals.

For technical reasons, the newest IrpProtocols.xml file is not included in the snapshot.

Furthermore: There has not been, and likely will not be, a release 2.2.7.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3610
Location: Cambridge, UK

PostPosted: Thu Jul 16, 2020 4:46 am    Post subject: Reply with quote

Barf wrote:
So I suggest putting "reject-repeatless" in the NECx2 protocol. OK?

Yes.
Quote:
The ICT importer can optionally chop the import according to the user parameter chopThreshold (default 100ms)

Yesterday, independently and not yet posted, I did this also in RMIR, with minor differences. It is not optional and the chopThreshold is not a parameter, it is fixed at 200ms as study of the IRScope source showed that is what IRScope does. Since the aim, or my aim at least, is to reproduce the splitting behaviour that a user would see on opening in IRScope. this seemed the logical choice.

Quote:
There has not been, and likely will not be, a release 2.2.7.

I hope this means that the next release will be 2.2.8, not that there will not be any more releases.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Thu Jul 16, 2020 2:23 pm    Post subject: Reply with quote

mathdon wrote:
I am questioning the handling in Transmit. One can transmit from the Generate tab and also from the Import tab. From the Generate tab a signal with an unspecified T value toggles. From the Import tab it does not. This to me is an inconsistency, even if it is not a bug.


To me, it is still a very "optional" and not extremely useful feature, due to the nature of the program -- as opposed to for example JGirs.

Anyhow, it is implemented in the current shapshot.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3610
Location: Cambridge, UK

PostPosted: Sat Jul 18, 2020 6:21 am    Post subject: Reply with quote

Barf wrote:
Anyhow, it is implemented in the current shapshot.

Thank you. Tested and found working. From the export of my entire URC6440 as a Girr file, the Sky HD device (RC6-6-20 non-toggle) and the Virgin Media cable box (RC5, toggle) both have the correct toggle behaviour on Transmit. As a development tool it seems as useful to me to be able to test the toggle behaviour as to test any other feature of the transmitted signal, so I must beg to differ from you on its usefulness.
_________________
Graham
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3 ... 21, 22, 23, 24  Next
Page 22 of 24

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central