User visible changes:
General:
- AppImage (see http://appimage.org/) format available for 64-bit
Linux, #65.
- Misc. minor tweaks in the installation.
- The installation is now completely relocatable (#100). For this, filenames
must not be stored with absolut filenames if they are children of apphome.
- Does not assume that CWD = applicationHome any more.
- IrpMaster, as executable, noninteractive program, can now be invoked by
giving --irpmaster as the first argument on the command line to IrScrutinizer.
- Added directory contributed. This should contain "contributed" protocols etc.
- Wrong parameter spec in RECS80 fixed (#114).
- Remove unused DTD support (#94).
- irscrutinizer.sh: (wrapper) improved location of apphome.
- Added some XML files from W3C and Apache, adapted the XML catalog
in order to make the project more self contained, and to allow
validation without network access.

GUI:
- The panes "Sending hw" and "Capturing hw" have been interchanged (also in the manual) #150.
- There is now a confirmation dialog if exiting with non-empty remote tables, #86
- Improvements on metadata inquiry for remote exports. #89
- Files to be imported can now be given as command line arguments. #112
This allows .girr files to be associated with IrScrutinizer.
- Many files can can be plotted by dropping on "Scrutinize signal"; #127
- "Paste selection" in data window on Scrutinize signal fixed #136
- Editing of timing data in Raw Remote table now implemented #144
- Alt-R(Alt-P) now accelerators for selecting raw(Pronto) output.
- Save current pane to properties. Get "Jump to last panel" fully working.
- Generate-pane: T and "Additional parameters" now saved in properties.
- (Somewhat) better error handling and error messages.

Import:
- Many file types can now be imported by "dropped" on the GUI; #111
- Signals can now be imported to the parametric table even if the protocol
is empty or nonsensical, #120
- mode2-import (Lirc) now has its own subpane under Import #121
- GlobalCache Control Tower data base (http://irdb.globalcache.com/)
can now be "browsed", however not directly imported. #129
- LircClient now has its own timeout (Options -> Timeouts -> Lirc timeout)
- GirrImport is now capable to import directory hierarchies.
- IRDB import: at the initial load, load the first device too.

Core:
- The repeat finder of ExchangeIR has been implemented by a own implementation,
believed to be more reliable and maintainable. #21
- Robustness improvements in parsing strings on "scrutinize signal/scrutinize; #123

Hardware support:
- "Arduino support" has been replaced by "general Girs support"; #24
- Suitable hardware may now be opened both for capturing and sending, #54
- (Linux only) Devices on /dev/lirc now supported for sending and receiving; #122
- Better timeout handling for some hardware.

(i.e. a 16 bit F, as is suggested by the name) while DecodeIR is using another parametrization. It is possible to enter other versions in IrpProtoocols.ini; I think you know how. ("Additional parameters" is active if and only if there are other parameters than F, S, D, and T).

I was using IrScrutinizer with a IRToy for a while. It worked, but the IRToy seemed to hang up a lot, and I'd end up plugging/unplugging, changing COM ports, etc. to get things working again.

I just built up on of the Arduino Nano Girs clients (AGirs). That seems to be MUCH more reliable.

One suggestion for IrScrutinizer - on the "Sending hw" page, you click the "open" button to start communications with the hardware. After successfully connecting, the button should change to "close".

I discovered only by accident that it toggles between open and close. I could probably have saved myself some grief if I had known that when struggling with the IRToy.

Also, not related to irScrutinizer, but to AGirs. It would be nice to have a compiled .hex file available, so people don't have to install the Arduino IDE, figure out libraries, figure out the changes to the code needed to get it to compile, etc, just so they can make a nano AGirs.

I was using IrScrutinizer with a IRToy for a while. It worked, but the IRToy seemed to hang up a lot, and I'd end up plugging/unplugging, changing COM ports, etc. to get things working again.

Hmm, I know that some people has been complaining in the Dangerous Prototypes forum, but I have not seen those problems myself. There is an un-official "2.4 firmware" in the D.P. forums, possibly that helps.

Quote:

I just built up on of the Arduino Nano Girs clients (AGirs). That seems to be MUCH more reliable.

Quote:

One suggestion for IrScrutinizer - on the "Sending hw" page, you click the "open" button to start communications with the hardware. After successfully connecting, the button should change to "close".

I discovered only by accident that it toggles between open and close. I could probably have saved myself some grief if I had known that when struggling with the IRToy.

Hmm, The behaviour is a "push buttom with memory"; it stays "pressed" (in the selected state) until operated again, to indicate that the device is in the "opened" state. (If opening fails, it does not enter the selected state). I think that this it is logical and intuitive, but at least one person finds it confusing. I am a bit reluctant to dynamic button texts, since it may affect the layout (although this "should" not occur). Also, it may (?) cause problem for a future localization. Anyone else has an opinion...?

Quote:

Also, not related to irScrutinizer, but to AGirs. It would be nice to have a compiled .hex file available, so people don't have to install the Arduino IDE, figure out libraries, figure out the changes to the code needed to get it to compile, etc, just so they can make a nano AGirs.

The coolest thing would be have the IrScrutinizer to be able to program the Arduino... But I am afraid of opening a can of worms here. I do not want to support avrdude, nor beginners having problems with flashing...

There are also so may variations, different boards, different hardware etc. Nevertheless, providing a simple hex file for the "canonical Nano configuration is a good idea. I sometimes did that in the past.

I wrote this in the Arduino forum, on having the Arduino IDE supporting flashing directly, but as you see, it was not exactly popular...

Hmm, The behaviour is a "push buttom with memory"; it stays "pressed" (in the selected state) until operated again, to indicate that the device is in the "opened" state.

Something else that wasn't obvious to me. I expect buttons to highlight when pressed, never noticed that it "stuck" to indicate a toggle. Perhaps just change the label from "Open" to "Open/Close", since it does both?

Quote:

There are also so may variations, different boards, different hardware etc. Nevertheless, providing a simple hex file for the "canonical Nano configuration is a good idea. I sometimes did that in the past.

Yeah, just for the canonical, Nano one. If someone is going their own way with different hardware, they should know enough to know they need to compile for a different platform. I don't know enough about Arduino - can programming hex to the wrong platform lock you out from reprogramming it, or is it just that the code doesn't work as expected?

If someone is going their own way with different hardware, they should know enough to know they need to compile for a different platform. I don't know enough about Arduino - can programming hex to the wrong platform lock you out from reprogramming it, or is it just that the code doesn't work as expected?

Is it possible to use this with WinLIRC? When I try using LIRC as transmitter, I get a dialog, "No remotes present" which returns in an infinite loop when I press OK to dismiss it and end up having to kill process javaw.exe. When I try LIRC as receiver, I get "No capture device, aborting."

I'm guessing this must only work with LIRC on Linux, but is there a workaround to make it work on Windows? Reason being WinLIRC is compatible with my MCE receiver/blaster and IRScrutinizer doesn't have native support for this hardware.