IrScrutinizer
IrScrutinizer copied to clipboard
bengtmartensson
Visual inspection of decode
When decoding isn't going quite right, it's useful to overlay a plot of the raw signal with a plot of the decoded-reencoded signal, to make a human decision about whether the decode is good or not. (And if some small proportion of the decodes for a remote are not good, to try other likely parameters and see whether the plots can be made to match up.)
Currently in IrScrutinizer, it's possible to import the raw signals to both the Parametric Remote and the Raw Remote tabs, and then send one signal from each tab to Scrutinize Signal (using Clone Plot in between). Am I overlooking a shorter process here?
I have ideas about streamlined comparision for decodes of remotes, but wanted to hear your outline thoughts on the matter first.
I am very well aware that there is a certain potential for improvements here. I see this in the context of an subframes GUI, so that "scrutinize signal" will be a sub-tool in a sub-frame, one that can be instantiated zero or more times. "To scrutinize signal" will then open a new such "subtool". There should then be a possibility to "diff-ing" any two of these displays.
Another direction would be to shove the data to an external program (octave, gnuplot, audacity, scilab,... ) Your suggestions are welcome.
I don't think having the signals in two windows is the best thing for comparing, because they need to be aligned on the same time axis. If both signals are on the one plot, they get scaled together. Vertically, they want to be close, maybe overlapping or maybe not (could be an option).
I was wondering about having a plot which communicates with the Raw Remote table, updating automatically depending on which row(s) are selected. That would save a lot of clicks for some use cases. In the future rearrangeable GUI, it could be a separate thing. In the current GUI structure, it could just be another strip below the table.
There is a slight complication if there might be more than one decode source. Is the Analyze column for ExchangeIR results? And by the way, what does the "Ver." column do? Though if, as in the roadmap, you mean to write a better decoding engine, there may not be a need for any others.
Currently, the "Decode" column is populated automatically when the raw signal is added. It can then be edited, but this doesn't do anything (e.g. exporting a Girr file takes the original values). I'm not sure about the best way to make it properly editable. Maybe mark it as edited somehow, and have a "redo decode" option on the right-click menu to return to the original values? Or make the Decode and Analyze columns read-only and have another one for editing (but the number of columns is getting a bit much already).
Is the Analyze column for ExchangeIR results?
Yes
what does the "Ver." column do?
The user can use it any way (s)he likes, it is not evaluated.
Currently, the "Decode" column is populated automatically when the raw signal is added. It can then be edited, but this doesn't do anything (e.g. exporting a Girr file takes the original values). ...
A raw signal is a raw signal, meaning that it is determined entirely by its timing data. The "decode" and "Analyze" columns are just "comment".
Anther thing I have been considering is to save the current table layout to the properties. (With some option for returning to defailt).
A raw signal is a raw signal, meaning that it is determined entirely by its timing data. The "decode" and "Analyze" columns are just "comment".
That was in the context of the human "helping" with the decode. The raw signal is defined by its timing data. The parameters are derived from the timing data, but perhaps with a little intervention.
Perhaps one should use a Parametric Remote table in addition to the Raw Remote table. In a rearrangeable GUI, it would be possible to place the two tables next to each other. But this is still clumsy, since rows in one table logically correspond to rows in the other table, without IrScrutinizer knowing about it.
There is presently no way to turn a raw signal (= a row in the raw table) into a parametric one, or vice versa. However, it would be relatively easy to implement, in the context menu of the tables, a possibility to copy (or even move) to the parametric (or raw) table. In a future subwindow GUI, this could possibly even be done by "dropping" the signal(s) with the mouse.
That would be useful too, but doesn't quite solve what I'm talking about here (not sure if I've managed to explain what it is yet).
Or make the Decode and Analyze columns read-only and have another one for editing ...
This is probably both the cleanest and easiest way. I agree that it is silly to let the user enter information that is thrown away, The "Another one" column is "Comment".
I might come back to that later if I think of a better way to say it...
Anyway, what do you think about plots with more than one trace on the same time axis?
Interactive data analysis etc is IMHO better done with tools specialized for that purpose. I am as a general principle very skeptical to creating a mjni version these tools. Have you looked at the tools I previously mentioned to see if any of those can be used, in one way or the other? But of course I am open to your suggestions.
Shoving the data to an external program limits the possible interaction with IrScrutinizer, and I'd be concerned about it being slow and unreliable/unportable. But indeed it's best not to reinvent the wheel in writing plotting software. Maybe a "mini tool" based on a pure Java plotting library like JChart2D or JCCKit (I haven't used either).
There is certainly much to be done in the long term. I would like to see this in the context of a future subframe GUI. I do not see any immediate things to be done, although I suspect that @HelenFoster disagrees...
Another use case that I am interesting in is this: giving a small number of raw captures, the task is to tailor an IRP protocol to the data.
It may also be worthwhile to have a look at AnalysIR.