IrScrutinizer: capturing, generating, analyzing, import, exp

[Barf]

There is a curious IrScrutinizer issue that I forgot to report earlier. It is occasional and occurs with iTach Flex capture. This is a popup saying:

HarcHardwareException: Hardware based exception: Hardware does not appear to support capturing.

At the same time the console shows:

Expected "IR Learner enabled", returning immediately.
...

(What is the firmware version on your GlobalCache?)

This is somewhat more complicated than I expected: I had read the GC documentation badly, the device is supposed to stay in "learning mode" until a stop_IRL is received, and should not being sent get_IRL for repeated learns. However, at least my version seemed to answer get_IRL with "IR Learner Enabled" -- except for sometimes (I really hate "statefullness" of that sort; it is just a source or problems.)

Anyhow, I have a believed fix in the current CI build, please try it.

Here you are:

Thank you. So they should be fine.

I now have the beacon working on five of my six installations of IrScrutinizer (Win10, Win8.1, and VirtualBox WinXP and Ubuntu 16.04 on both of those). Win8.1 is the only one that defeats me.

OK. I can live with your Win 8.1 being funny.

[mathdon]

Try this, jp12serial compiled on Ubuntu 12.04.05 LTS

Thank you, this works on my 32-bit Ubuntu 16.04. I have no way of testing the 64-bit version but presume that will work, too. I believe this to be the "right" solution, and will include it in the next build of RMIR v2.10.

Have you decided whether to include my Dyson IRPs in IrpTransmogrifier? I will in any case be including a Dyson protocol entry in protocols.ini. I have written and tested executors corresponding to my IRP for HCS08, S3F80, MAXQ and TI2541 processors and they all handle the long lead-outs correctly.

[mathdon]

Anyhow, I have a believed fix in the current CI build, please try it.

Yes, this seems to work. I have captured 30 signals of various protocols in a row, without any issue. I had an odd behaviour when I first opened IrScrutinizer, though, and selected GlobalCache. It found the IP address, reported the firmware version, but pressing Test gave a message that the selected capturing device was not ready (not opened?). I see there isn't an Open button for GlobalCache. I had to close and re-open IrScrutinizer to resolve that. Maybe a one-off glitch of no significance, but I thought I would mention it.

The firmware version is 710-3000-21. That should be the latest, as I did a firmware upgrade when trying to resolve my problem with its sending behaviour.

[Barf]

...I had an odd behaviour when I first opened IrScrutinizer, though, and selected GlobalCache. It found the IP address, reported the firmware version, but pressing Test gave a message that the selected capturing device was not ready (not opened?). I see there isn't an Open button for GlobalCache. I had to close and re-open IrScrutinizer to resolve that. Maybe a one-off glitch of no significance, but I thought I would mention it.

Currently, the only possibliity to close a GC is to select another one. I am fully aware that this possibility is not available to most users , and intend to fix it. Would that fix the problem? I suspect that you cannot reproduce.

The firmware version is 710-3000-21. That should be the latest, as I did a firmware upgrade when trying to resolve my problem with its sending behaviour.

OK, thankyou. I presently have -18 on mine, and I suspect that version is slightly more forgiving than yours.

[Barf]

Try this, jp12serial compiled on Ubuntu 12.04.05 LTS

Thank you, this works on my 32-bit Ubuntu 16.04. I have no way of testing the 64-bit version but presume that will work, too. I believe this to be the "right" solution, and will include it in the next build of RMIR v2.10.

OK. I intend to do some testing, so if you have a release imminent, please wait for my test. (Ping me if urgent.)

Have you decided whether to include my Dyson IRPs in IrpTransmogrifier? I will in any case be including a Dyson protocol entry in protocols.ini. I have written and tested executors corresponding to my IRP for HCS08, S3F80, MAXQ and TI2541 processors and they all handle the long lead-outs correctly.

It overwrites the current "Dyson" (previously called "Dysan"). Is this OK? Dave (3FG), do you want to comment on this?

Graham, can the GlobalCache handle the 400ms duration?

[mathdon]

Currently, the only possibility to close a GC is to select another one. I am fully aware that this possibility is not available to most users , and intend to fix it. Would that fix the problem? I suspect that you cannot reproduce.

Yes it would fix it, provided that after the close, there was a way of re-opening it. And no, I cannot reproduce it. Only seen once.

OK. I intend to do some testing, so if you have a release imminent, please wait for my test.

I would like to do a release asap, but I am waiting for a final release of IrpTransmogrifier 1.2.6 for inclusion, hence the question about the Dyson IRP.

It overwrites the current "Dyson" (previously called "Dysan"). Is this OK?

My suggestion includes three entries: Dyson, Dyson2 and Dyson_relaxed. The current Dyson is essentially my Dyson_relaxed (I may have tweaked it, I can't actually remember), so you are not losing anything. It is in fact essential to keep this, for those sensors that cannot handle the longer leadouts.

Graham, can the GlobalCache handle the 400ms duration?

Yes, on both capturing and transmitting.

[mathdon]

On further thought, I realize I don't know whether the GlobalCache can handle 400ms leadout on capturing. It can certainly handle the 100ms. Here's the capture of a Dyson signal with dittos, and its decode:

Freq=38277Hz[+2195,-732,+732,-1594,+732,-810,+732,-810,+732,-1594,+732,-810,+732,-810,+732,-810,+732,-810,+732,-1594,
+732,-810,+732,-1594,+732,-810,+732,-1594,+732,-1594,+732,-810,+732,-99407,+2195,-732,+732,-1594,+732,-810,+732,-810,
+732,-1594,+732,-810,+732,-810,+732,-810,+732,-810,+732,-1594,+732,-810,+732,-1594,+732,-810,+732,-1594,+732,-1594,+732,
-810,+732,-59644,+2195,-732,+732,-1594,+732,-59644,+2195,-732,+732,-1594,+732,-59644,+2195,-732,+732,-1594,+732,-99982][][]

Dyson: {D=9,F=42,T=2}, beg=0, end=85, reps=3

I've highlighted the leadouts, showing in particular the 100ms leadout between the two full frames. The ending leadout of 99982 appears to be a limit set by irScrutinizer, and if I send a Dyson Power signal with the 400ms gap, I get

+2195,-732,+732,-1594,+732,-810,+732,-810,+732,-1594,+732,-810,+732,-810,+732,-810,+732,-810,+732,-810,+732,-810,+732,
-810,+732,-810,+732,-810,+732,-810,+732,-1594,+732,-99982

Dyson_relaxed: {D=9,F=0,T=1}, beg=0, end=33

with the same maximum at the end. So it appears to be a limitation of IrScrutinizer rather than GlobalCache that it doesn't record the 400ms leadout.

There is no ambiguity with sending, however. Here is the IRScope summary of the Power signal sent by GlobalCache. I have edited out the empty columns. It shows as two entries but is a single captured waveform, as the Start and End values show, and the 400ms leadout is clear at the end of the first signal.

Code: Select all

DECODES:

#    Frequency  Protocol   Start   End
1    37763      <unknown>  0       16	
2    37763      <unknown>  17      39	

RAW TIMING DATA:

1:    +2337 -790 +757 -1596 +757 -816 +758 -816 +757 -1569 +758 -816 +757 -822 +752 -822 +778 -795 +758 -816 +757 -822
      +752 -822 +757 -816 +758 -816 +784 -795 +778 -1569 +758 -399042 
2:    +2305 -822 +757 -1569 +752 -822 +757 -816 +758 -1569 +778 -795 +784 -790 +784 -795 +778 -796 +778 -795 +784 -790
      +784 -795 +778 -796 +778 -795 +784 -790 +784 -1569 +757 -59869 +2331 -790 +784 -1569 +757 -59869 +2331 -816 +758
      -1569 +757 -1409095 

[Barf]

The ending leadout of 99982 appears to be a limit set by irScrutinizer, and if I send a Dyson Power signal with the 400ms gap, I get...

There is no such limit in IrScrutinizer. Please turn on "verbose"; there you see exactly what the GC sent. To me, it appears that GC has an (undocumented) endingTimeout of approximately 100ms.

[Barf]

I am waiting for a final release of IrpTransmogrifier 1.2.6 for inclusion, hence the question about the Dyson IRP.

Release candidate 1.2.6 is available. I have essentially taken your protocol definition and deleted the old "Dyson". However, I have made the following changes:

Dysan_relaxed: changed "+" to "*", because the former does not really decode.

Minor changes to the verbal descriptions.

[mathdon]

To me, it appears that GC has an (undocumented) endingTimeout of approximately 100ms.

You are right. The limit appears to be the maximum number of whole clock cycles in 100ms. "Verbose" showed a frequency of 38277kHz and a final leadout of 3827 clock cycles, which is 99982us to the nearest microsecond, exactly as I had found.

I have continued to try, without success, to get IrScrutinizer to treat the two frames of the Power signal, with their 400ms separation, as a single signal. As I have reported before, it seems to me that setting "Ending silence" to more than 400ms should achieve this. That does not do it.

I think that until today, I had not tried this on the only one of my six implementations that supports the Widget without any glitches, namely Ubuntu 16.04 in VirtualBox on the Win10 laptop. I did so today and found to my astonishment and delight that IrScrutinizer then does exactly as I had hoped. With Ending silence set to the default 300ms it sees the Power signal as two frames and decodes it as Dyson_relaxed. With it set to 500ms it sees the Power signal as one frame and decodes it as Dyson2. Wonderful . Many apologies for doubting its behaviour, which clearly had resulted from issues with the capture device having a timeout or from the Widget glitch in Windows. Now if you could just make capture devices with a timeout behave the same way ...

I have found another peculiarity that is not important but which puzzles me. I have reported before that on my Win8.1 machine with Ubuntu 16.04 in a VirtualBox, IrScrutinizer does not find any serial ports for the Widget, despite dmesg showing it is connected at dev/ttyUSB0. I looked today at the properties file and found it has both captureDevice=IrWidget and irWidgetCapturePortName=/dev/ttyUSB0. So it appears to be found and written to the properties file, despite not showing up even after pressing Refresh on the capture hw pane. Can you see a reason for this?

[Barf]

I think that until today, I had not tried this on the only one of my six implementations that supports the Widget without any glitches, namely Ubuntu 16.04 in VirtualBox on the Win10 laptop. I did so today and found to my astonishment and delight that IrScrutinizer then does exactly as I had hoped. With Ending silence set to the default 300ms it sees the Power signal as two frames and decodes it as Dyson_relaxed. With it set to 500ms it sees the Power signal as one frame and decodes it as Dyson2. Wonderful . Many apologies for doubting its behaviour, which clearly had resulted from issues with the capture device having a timeout or from the Widget glitch in Windows. Now if you could just make capture devices with a timeout behave the same way ...

Glad to hear that. I definitely intend to get the Arduino/Girs to be working the sames way. The IrWidget is completely governed by the Java driver (the hardware just spits out the number of (positiive?) edges encountered last 100 micros.) (IIRC, IrScope has 500ms hard soldered in.) For the record: the IrToy has fixed endingTimeout, around 1.6 seconds(!) (which makes it feel pretty sluggish when you are bulk capturing). CommandFusion: 191ms fixed. /dev/lirc + HP MCE receiver: tried it and got 100ms, but it is probably changeable.

I have found another peculiarity that is not important but which puzzles me. I have reported before that on my Win8.1 machine with Ubuntu 16.04 in a VirtualBox, IrScrutinizer does not find any serial ports for the Widget, despite dmesg showing it is connected at dev/ttyUSB0. I looked today at the properties file and found it has both captureDevice=IrWidget and irWidgetCapturePortName=/dev/ttyUSB0. So it appears to be found and written to the properties file, despite not showing up even after pressing Refresh on the capture hw pane. Can you see a reason for this?

/dev/ttyUSB0 is the default, so it does not carry any information. Also the captureDevice is the last one the user selected, regardless if it worked or not.

One good command that I often use is

Code: Select all

ls /dev/tty????

(exacty four question marks), lists all FTDI (like IrWidget, some Arduino). other Arduinos, IrToy, CommandFusion, TIRA, USB/UIRT, etc. Another useful command is lsusb; sometimes the output is a bit hard to read, since it also lists all sort of uninteresting "junk", like keyboards, mice etc. You can compare the output with and without your device plugged in.

Serial: I will concentrate on getting the "new driver" (alternative: steal what the Arduino IDE is using) to work, and do not plan to address issues with the current driver RXTX.

[Barf]

IrScrutinizer 2.2.6 has been released, and is available here. This release contains a number of bugfixes and minor improvements, as has been discussed on the last few pages of this thread. (Still a few issues left that I plan to address later.)

Lot of thanx to Graham for his feedback!

Release notes:

Code: Select all

Version 2.2.6, released 2020-05-25.

* Uses IrpTransmogrifier 2.2.6, see IrpTransmogrifier.releasenotes.txt.
* Improved text in GUI on capture parameters.
* Author's public key now available as popup.
* If capture thread stops by exception, the program was left in unusable state. #383.
* The help popup now has a popup menu for copy, save, print.
* Scrutinize remote: Commands in advanced menu now operates on selection. #368.
* Scrutinize Remote/Raw: Possibility to copy commands to Parametric Remote. #380.
* Change accelerator for exit from Escape to Ctrl-Q.
* Scrutinize remote: Possibility to clear selection. #382.
* Replace non-functional accelerators by keybindings in the tables. #373.
* Generate pane: Replace the "T" combobox with normal text field. #372.
* Lirc-export: More protocols to reject generating cooked Lirc exports. #363.
* Fixed anchor problem in generated html-files, like IrScrutinizer.html. #371.
* Reorganized checksums in distro. #381.
* Several menu text/tooltip text improvements.
* New user parameter ignoreLeadingGarbage. #377.
* Import to param. remote now rejects undecodable signals. #376.
* New export format irdb cvs. #374.
* Exportformat Spreadsheet: small cleanup.
* Changed empty TreeImporter text to "--EMPTY--" 
* Importers now import also metadata, whenever possible. #352.
* Do not check/create Export dir if automatic file names is not selected. #370.
* Change initial export director to $HOME/Documents/IrScutinizer.
* Rename column Date in Parametric/Raw Remote to Timestamp.
* Create *.dmg install file for MacOS, replacing zipped app. #369.
* New "contributed" wrappers for ghostscript.
* Nuke sendir configuration panel. #323 (partially).
* Remove "Ver." box in Parameteric/Raw remote. #367.
* Property invokeAnalyzer changed default to true.
* Remoteeditors: Implemented multi-row pasting in columns. #365.
* Functions for making command names unique. #364.
* Improvements to parameteric csv import. #362.
* Minor improvements to RemoteMaster export.
* Fixed decoding of "short Pronto". #358.
* Some documentation update, in particular on installation.

Keep scrutinizing!

[mathdon]

Thanks, Bengt, for this new version. The upgrade of my installations went smoothly. I have noticed that the version of protocols.ini that is included is that from RMIR v2.08, so is very out of date. I know this is a very minor file as far as IrScrutinizer is concerned, but thought I would point this out anyway.

[Barf]

Thanx Graham for the reminder. It has already been checked in (and I put it on my checklist for new releases )

[mathdon]

I have just tried to find documentation on the Girr file format by opening Help > Program Documentation, going to Export Pane > Girr and clicking the Documentation link that is there. I am using MS Edge. I get a message that it cannot find the page: file:///C:/Program%20Files%20(x86)/IrScrutinizer/doc/Girr.html

On checking the doc folder I find that Girr.html is missing, so the message appears to be real.