Page 15 of 27
Posted: Wed Apr 29, 2020 11:34 am
by Barf
mathdon wrote:1. The change of default export directory probably resolves my issue. I'll know better when I try it.
Don't forget to reset the properties (File -> Set properties to default). (But I still do not see why it is such an issue; you just change it and the changes are persistent.)
3. Pity about the maximum lead-out on the Arduino device. Is there any chance of the complicated fix??
Yes, but unlikely very soon...
Keyboard shortcuts in Swing. I have just copied code that Greg wrote, when I need it, without a deep understanding but it works and I will try to extract some examples for you.
Please no examples. (There are tons on the internet...)
10. If I do Help > Program Documentation and click on any of the first three items under "GUI Elements walk through", which are those for "Scrutinize signal" pane, "Scrutinize remote" pane and "Generate" pane, they do not work.
What browser are you using? It works with Firefox.
One further question: why have you stuck to the mis-spelling "Dysan"? You say somewhere that it is from 3FG. I presume it is a typo on his behalf.
Dave, are you there?
Posted: Wed Apr 29, 2020 12:25 pm
by mathdon
The default export directory is an issue if you use Export before setting the directory, and in Windows at least, it goes into some weird MS default that no-one ever looks at.
For keyboard shortcuts in RMIR, see RMPanel.java. It uses KeyListener().
My browser is MS Edge.
Posted: Wed Apr 29, 2020 2:49 pm
by 3FG
It definitely should be Dyson. I took most of the signals from Remote Central and most posters there spelled it correctly.
But my misspelling wasn't a typo, but worse. I confused the fan and vacuum cleaner company with the long gone Fortune 500 company that made computer storage media. They were the premier supplier of 5.25" and later 3.5" floppy disks. It's a name and logo I saw very often back when it took a minute or two to write 1Mbyte of data.
Posted: Thu Apr 30, 2020 5:32 am
by mathdon
I have a .girr file of my Dyson signals and I try importing it with various forms of the Dyson IRP in my version of IrpProtocols.xml. If I comment out the Dyson protocol, or have an IRP that does not decode those signals, the import process works OK with the protocol fields left blank in the "Scrutinize remote" pane. That is fine and is what I expect. But if I select one of those signals and do "Scrutinize selected", I get error messages:
Code: Select all
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at org.harctoolbox.girr.Command.<init>(Command.java:386)
at org.harctoolbox.girr.Command.<init>(Command.java:379)
at org.harctoolbox.irscrutinizer.ParametrizedIrSignal.toCommand(ParametrizedIrSignal.java:211)
at org.harctoolbox.irscrutinizer.ParametrizedIrSignal$ParameterIrSignalTableModel.toCommand(ParametrizedIrSignal.java:449)
at org.harctoolbox.irscrutinizer.TableUtils.commandTableSelected(TableUtils.java:140)
at org.harctoolbox.irscrutinizer.TableUtils.commandTableSelectedRow(TableUtils.java:131)
at org.harctoolbox.irscrutinizer.GuiMain.scrutinizeIrSignal(GuiMain.java:1277)
at org.harctoolbox.irscrutinizer.GuiMain.scrutinizeParametricMenuItemActionPerformed(GuiMain.java:8997)
at org.harctoolbox.irscrutinizer.GuiMain.access$4400(GuiMain.java:104)
at org.harctoolbox.irscrutinizer.GuiMain$34.actionPerformed(GuiMain.java:2746)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
...
I would expect to get a signal analysis in the "Scrutnize signal" pane but with no decode.
Posted: Thu Apr 30, 2020 6:35 am
by Barf
mathdon wrote:I have a .girr file of my Dyson signals and I try importing it with various forms of the Dyson IRP in my version of IrpProtocols.xml. If I comment out the Dyson protocol, or have an IRP that does not decode those signals, the import process works OK with the protocol fields left blank in the "Scrutinize remote" pane. That is fine and is what I expect. But if I select one of those signals and do "Scrutinize selected", I get error messages:
Code: Select all
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at org.harctoolbox.girr.Command.<init>(Command.java:386)
at org.harctoolbox.girr.Command.<init>(Command.java:379)
...
I would expect to get a signal analysis in the "Scrutnize signal" pane but with no decode.
An uncaught NPE is always a bug, you should not expect anything...
Indeed the case in 2.2.4, but was fixed
here. Current CI build contains the fix.
Posted: Thu Apr 30, 2020 6:47 am
by Barf
mathdon wrote:... It is that panel in Import > Wave display which says "No remotes loaded" and which, when you load the test file, changes to a tree structure with a top node of "Remotes" that made me think it might be able to do something with an RMIR wave file. I am unclear what that panel is for, if the wave files are simply one IR signal converted to a .wav file.
"No remotes loaded" has been changed to "--Empty--".
Import of Metadata has been implemented. But note that since import and export is not really in 1-to-1 correspondence, this is to be considered as heuristics. It works as follows: When pressing "Import all" or "Import all/raw" in the TreeImporter, the just-read metadata (if non-trivial) becomes the program's MetaData. (Import selected etc does not consider meta data.)
For Mac users, there is now a .dmg file in addition to the compressed app. (The latter will probably be deleted in the future.)
Available in the CI build.
Posted: Thu Apr 30, 2020 7:22 am
by mathdon
Barf wrote:An uncaught NPE is always a bug, you should not expect anything...
Indeed the case in 2.2.4, but was fixed here. Current CI build contains the fix.
Indeed, I no longer get an NPE. Instead I get an Unknown protocol exception: Protocol null not found.
Is that what you intend? Can't I scrutinize a signal that it does not decode?
Posted: Thu Apr 30, 2020 7:57 am
by Barf
Yes you can. From the "Raw Remote" panel.
Issue on MS Edge.
Posted: Fri May 01, 2020 5:08 am
by mathdon
OK, so I have captured a set of signals as a Parametric Remote. Some of them do not decode. I want to analyse them without having to capture them again. How do I move/copy them to the Raw Remote panel?
Having failed on that, I tried a different approach. Capture them one by one on the "Scrutinize signal" panel so that I can see the analysis, and decode if any, before copying it to Parametric Remote. However, I can find no way of copying it to either Parametric or Raw Remote.
Posted: Fri May 01, 2020 5:45 am
by mathdon
After a lot of experimenting, I have finally arrived at IRPs for the Dyson protocol that both decode and generate complete signals as sent by my AM05 heater remote. I believe the only difference between the various Dyson models, apart from parameter values, may be the toggle. On the AM05 it cycles through 0,1,2 and then back to 0, so not using the value 3. The Dyson discussion thread indicates that some models do use T=3, and it is possible that they may omit some other value or use a different ordering, such as in reverse. So I have created IRPs that do not include an assignment element for the toggle, and which set its range as 0..3.
My final discovery, which I do not fully understand, was that if the IRP includes the ditto repeats and the signal has no dittos, it decodes only if Repeat Finder is turned off. Another issue, which I should have anticipated, is that they do not work with the Arduino device as its limitation of lead-outs to a maximum of 65535us appears to apply to capturing as well as transmitting. For these reasons I have included a Dyson_relaxed as a fallback that works in all cases. So with this in mind, I offer the following as a revision of the Dyson entry in IrpProtocols.xml:
Code: Select all
<irp:protocol name="Dyson">
<irp:parameter name="prefer-over">Dyson_relaxed</irp:parameter>
<irp:irp><![CDATA[{780,38k}<1,-1|1,-2>(3,-1,D:7,F:6,T:-2,1,-100m,3,-1,D:7,F:6,T:-2,1,-60m,(3,-1,1:1,1,-60m)*)[D:0..127,F:0..63,T:0..3=0]]]></irp:irp>
<irp:documentation>This protocol is used by Dyson fan heaters. T is a toggle but its range of values may depend on the Dyson model. For example,
the AM05 cycles T through 0,1,2 leaving the value 3 unused. The Dyson2 protocol differs in having a longer lead-out between the two full frames.
It is used in the AM05 for the Power button. For signals with no ditto repeat frames to be decoded by IrpTransmogrifier, Repeat Finder must be
turned off.</irp:documentation>
</irp:protocol>
<irp:protocol name="Dyson2">
<irp:parameter name="prefer-over">Dyson_relaxed</irp:parameter>
<irp:irp><![CDATA[{780,38k}<1,-1|1,-2>(3,-1,D:7,F:6,T:-2,1,-400m,3,-1,D:7,F:6,T:-2,1,-60m,(3,-1,1:1,1,-60m)*)[D:0..127,F:0..63,T:0..3=0]]]></irp:irp>
<irp:documentation>The Dyson protocol is used by Dyson fan heaters. T is a toggle but its range of values may depend on the Dyson model. For example,
the AM05 cycles T through 0,1,2 leaving the value 3 unused. The Dyson2 protocol differs in having a longer lead-out between the two full frames.
It is used in the AM05 for the Power button. For signals with no ditto repeat frames to be decoded by IrpTransmogrifier, Repeat Finder must be
turned off.</irp:documentation>
</irp:protocol>
<irp:protocol name="Dyson_relaxed">
<irp:parameter name="decode-only">true</irp:parameter>
<irp:irp><![CDATA[{780,38k}<1,-1|1,-2>(3,-1,D:7,F:6,T:-2,1,-100m)+[D:0..127,F:0..63,T:0..3=0]]]></irp:irp>
<irp:documentation>Relaxed version of the Dyson and Dyson2 protocols, which tests only the first frame. A signal may decode as Dyson_relaxed
because (a) the signal is incomplete, or (b) the capture hardware cannot report lead-out values greater than 0xFFFF microseconds, or (c) the
signal has no ditto repeat frames and Repeat Finder is turned on for IrpTransmogrifier.</irp:documentation>
</irp:protocol>
Posted: Fri May 01, 2020 10:55 am
by Barf
mathdon wrote:OK, so I have captured a set of signals as a Parametric Remote. Some of them do not decode. I want to analyse them without having to capture them again. How do I move/copy them to the Raw Remote panel?
You can't. It does not make sense. A line in the Parametric Remote has no timing information. How have you succeeded in getting a captured, non-decoded signal there? When I try to shoot an undecodable signal with the current version, I get "Undecodable signal, ignored", and no entry.
Having failed on that, I tried a different approach. Capture them one by one on the "Scrutinize signal" panel so that I can see the analysis, and decode if any, before copying it to Parametric Remote. However, I can find no way of copying it to either Parametric or Raw Remote.
Why don't you capture them on "Raw remote"? They are still decoded (to the extent possible), and analyzed.
Transferring signals with a decode from Raw to Parametrized would make sense but is not (yet?) implemented. Care for it?
Posted: Sat May 02, 2020 6:26 am
by Barf
mathdon wrote:My final discovery, which I do not fully understand, was that if the IRP includes the ditto repeats and the signal has no dittos, it decodes only if Repeat Finder is turned off.
In IrpTransmogrifier, there are IrSequences (a number of interleaving flash and gaps), and IrSignals (consisting of an intro-, a repeat-, and an ending sequence (some may be empty)). A decoder operates either on an IrSequence or an IrSignal, in some cases producing slightly different results. A RepeatFinder maps an IrSequence to an IrSignal. So if the input has no repeats, it is by the RepeatFinder mapped to an IrSignal with empty repeat, which may be rejected by the decoder, if the expected signal has a non-empty repeat.
The decoding is pretty forgiving, accepting intros as repeats and vice versa (unless --strict is given), but there are limits.
Having said that, I am slightly uncomfortable with your huge gaps
within a sequence (60ms, 100ms, 400ms). Is this one sequence with a lunch break, or is it several sequences? Yes, my firmware has a problem with it, but I am pretty sure that it goes for many other types of hardware too. (Not all of them have setable ending timeout...)
Final remark: since some time, I try to write text that is going to be formatted (like the content of the <irp:documentation> element) to be diff-friendly, using the following rule: Every sentence starts on a new line. Running the "diff" program (or any "diff-like program", like Beyond Compare or diffuse or DiffMerge) (to compare new versions to the old) produce slightly more readable result, for example if a sentence has been added. Consider it?
Posted: Sat May 02, 2020 10:11 am
by mathdon
Barf wrote:Is this one sequence with a lunch break, or is it several sequences?
It is one sequence, in my view, because however brief the keypress, you get two full frames with the gap of 100ms or 400ms as appropriate. On those keys that send ditto repeats, a brief press gives these two full frames and no dittos. A longer press gives the two full frames and dittos for as long as the key is held.
I will try to follow your rule if I write any further documentation entries, but I have no experience of diff programs. As far as I am aware, there are no Windows utilities to generate or handle them.
Posted: Sat May 02, 2020 10:50 am
by mathdon
Barf wrote:A line in the Parametric Remote has no timing information. How have you succeeded in getting a captured, non-decoded signal there? When I try to shoot an undecodable signal with the current version, I get "Undecodable signal, ignored", and no entry.
I have misunderstood the Parametric Remote panel. I assumed the timing info was still held "behind the scenes", as you can export it as a .ict file that is purely timing data. I presume the timings are re-generated but that was not obvious to me.
I still have a great deal of trouble with Capture, in its various guises. This is nothing to do with any features of the Dyson signals, it was an issue I mentioned in my first report on IrScrutinizer. I get "No signal", "Internal error: IrSequence has odd length = xxx" or "Undecodable signal, ignored" frequently for signals that should be perfectly decodable, so frequently that I have come to ignore all of them, treating them as a glitch and repeating the signal in the hope of better luck next time. So if I want to be sure the IrScrutinizer is getting complete signals and to save myself this frustration, I capture them with IRScope, export them as a .ict file and import that into IrScrutinizer. That's how I got the parametric signals that show as blank lines with no decode, during my Dyson experiments.
I cannot make the capture glitches reproducible as they occur randomly, but I have a theory that I have not yet put to the test. Many, and possibly all, the glitches may be the result of the capture process capturing a signal with the beginning missing. The glitches happen even with Capture (cont) and with Capture on the "Scrutinize remote" panel, which is also continuous. On IRScope there is an activation delay. You press Capture and then wait for the beep, which occurs after a short but apparently variable length delay. Is there an activation delay on IrScrutinizer? On continuous capture, could it be triggered by the start of a new signal and not respond fast enough (on some machines, as you say you cannot reproduce this) to register the beginning of the signal in its capture?
Posted: Sat May 02, 2020 1:18 pm
by Barf
mathdon wrote:Barf wrote:A line in the Parametric Remote has no timing information. How have you succeeded in getting a captured, non-decoded signal there? When I try to shoot an undecodable signal with the current version, I get "Undecodable signal, ignored", and no entry.
I have misunderstood the Parametric Remote panel. I assumed the timing info was still held "behind the scenes", as you can export it as a .ict file that is purely timing data. I presume the timings are re-generated but that was not obvious to me.
I think the problem was that the (here) meaningless signals were accepted for import.
I consider this a bug, and moreover, it is now fixed.
Furthermore, I have improved the button texts and the tooltips to be more unambiguous.
Glitches: are you talking about the IrWidget or the Arduino? On the Arduino, the yellow LED indicates that capturing takes place.