IrScrutinizer: capturing, generating, analyzing, import, exp

[mathdon]

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 ...

Having discovered that this prevents my Dyson signals with a 400ms gap from importing into RMIR , I have now made this optional, though it defaults on (for Rob's benefit) and the threshold is still fixed at 200ms.

[ckeays]

Sometimes I get "InvalidArgumentException: Data contains duration of length 0"

I am seeing this error often. (I don't know what this error means).
I have searched through the help files, I cannot find a solution.
This error does not occur every single time. It seems random.

Anyone know why this error is being displayed?
Could it be the arduino firmware?
Java Issues?
I am also seeing "No Capture Device Selected, Aborting" message even though IRScrutinizer detected my device. Again this does not happen every single time.

I am not complaining, I am just eager to use IRScrutinizer.
So far I have not had very much success.

[Barf]

I am also seeing "No Capture Device Selected, Aborting" message even though IRScrutinizer detected my device. Again this does not happen every single time.

You have to not only open the hardware but also select if for capture: Assuming that it has been opened, select the "Capturing hardware" and then the subpane for the actual typ of hardware deployed.

Sometimes I get "InvalidArgumentException: Data contains duration of length 0"

I am seeing this error often. (I don't know what this error means).

An IR sequence is a number of interleaved durations, interleaved flashes (on-periods, sometimes called marks) and pauses, sometimes called gaps, spaces,... The error means, not unsurprisingly, that at least one on these durations is 0. This is really a weird description: what does it mean to wait for 0 time units? (If someone asks you to do something for 0 seconds, you will likely question their sanity )

Could it be the arduino firmware?

In a good error posting you explain what you want to do, in detail what you actually do to achieve that goal, what goes wrong and the error messages you get. Here I must guess. The above sentence leads makes me assume that you are using an Arduino with AGirs software. Chances are that you left out the non-demodulating receiver (TSMP-58000), or that it is not working. If so, just check the checkbox "Use receive for capture", the demodulating sensor will then be used, and you should be all set.

[ckeays]

You have to not only open the hardware but also select if for capture: Assuming that it has been opened, select the "Capturing hardware" and then the subpane for the actual typ of hardware deployed.

This seems to happen when I switch between the arduino and the USBIRToyv2. I can see that IRScrutinizer detected my arduino device, but I still get the message. YES, I did select the capturing hardware type.

The error means, not unsurprisingly, that at least one on these durations is 0.

I am using a TSMP-58000. The datasheet shows a capacitor and two resistors, perhaps the problems are due to noise. I think I will add these components to see it it makes a difference.

In a good error posting you explain what you want to do, in detail what you actually do to achieve that goal, what goes wrong and the error messages you get. Here I must guess. The above sentence leads makes me assume that you are using an Arduino with AGirs software. Chances are that you left out the non-demodulating receiver (TSMP-58000), or that it is not working. If so, just check the checkbox "Use receive for capture", the demodulating sensor will then be used, and you should be all set.

Yes I followed the instruction exactly on how to modify the NANO. I am using an Arduino NANO with AGirs software and a TSMP-58000 as mentioned above. No led's, no TSOP34438. I used the "GirsLite-1.0.2-nano-flasher.bat", I did not compile the source. I will try the capacitor and the resistors on the TSMP-58000. This is likely the problem with the TSMP-58000 receiving data correctly.
Thank you for responding, I will post my results.

[Barf]

Please turn on the "verbose" option, found under Option, restart, open, shoot a well known (HC5, NEC1,...) signal at the receiver, then copy the content of the console and post it here.

Although 100nF (for example) between Vcc and GND (pin 9 and 10) does not hurt, I have never seen a case when it has made a difference.

[Barf]

Finally!! I have a new version replacing the ancient RXTX by NrSerialJava, and addressing a number of problems with serial communication (including the IrWidget). A test version is available here.

Please test, and report the outcome.

[mathdon]

Please test, and report the outcome.

With pleasure . I hope to get back to you with the outcome in a few days' time.

[mathdon]

Here are my preliminary findings on Win 10, capturing with Scrutinize remote > Parametric Remote. I have not been able to fault it with IR Widget, Arduino or IR Learner so it is an enormous improvement. It is at last a cross-platform replacement for IrScope, so congratulations .

I find IRToy to be temperamental, but that is true also on Linux with earlier builds, so I think it is a problem with IrToy and not IrScrutinizer. It seems to be very fussy about the signal. If I get the remote at the right distance and the right angle, which appears to be at a slight angle from below, then I can get it to decode fairly consistently, but otherwise I get most captures showing as undecodable signals, ignored. Do you have problems with IrToy or have I got a problematic one?

I think those are the only devices that use the USB port. I have not tested either sending or anything with Linux, but will do both in the next few days. It was Windows that RXTX had problems with, so I gave priority to testing capture with Windows. Congratulations again!

[Barf]

Thank you very much for the report. I am happy to hear the positive results for non-IrToy.

Turned out that I made a fairly complete rewrite of the serial classes, just deploying NRJavaSerial instead of RXTX was not such a big deal: There was exactly one problem that was fixed by that, namely that close caused a crash on MacOS. The reason why I did not use jserialcomm as you suggested is that it had a completely different API, and did not do any locking. NRJavaSerial is essentially nothing but RXTX revived and somewhat cleaned and modernized.

IrToy: sometime I wrote in the IrToy forum that it was running "rock solid". I have no idea why, possibly I had tested badly. Yes, it runs quite erratically for me too. I recently tried different baud rates, different firmware versions, and turned off the debugging LED support (causes "unnecessary" serial communication). Nothing helped. Since the IrToy does not seems to be available any more, I think it is time to "unsupport" it. (If it was more widely spread, it may have been possible to try to port my Arduino-firmware to it.)

IIRC, first there was a version with only a decoding IR receiver, the non-decoding (QSE159 - same as in IrWidget) was added later ("version 2?"), and somehow its data ist just somehow "tucked upon" the data from the demodulating sensor.

[mathdon]

IrToy: sometime I wrote in the IrToy forum that it was running "rock solid". I have no idea why, possibly I had tested badly. Yes, it runs quite erratically for me too.

More to the point, your documentation says

What is on the splash screen?

From left to right, a Global Cache iTach Flex, an IrToy, and a low-cost clone of an Arduino Nano, the latter equipped with a non-demodulating IR detector (TSMP4138) for capturing and an IR diode (SFH415) for sending. These are all hardware which work well with IrScrutinizer, both for sending and capturing.

The IrToy takes centre stage there and is said to work well, so you may wish to change your splash screen if you "unsupport" it . Because of this note about the splash screen, I felt I must be doing something wrong with my IrToy or had a defective one. I am glad, at least, that is not so and you have problems with it too.

[mathdon]

I have done some more testing in Win10. I cannot fault 2.3.0 in sending, with any of Arduino, IrToy and IR Learner. The receiver was dev/lirc (HP media center device) on Linux.

I have also done some more capture testing with IrToy. I found that if I send the signal from below at an angle of about 45 degrees, it is pretty reliable. So I would not unsupport it, especially as it is fine in sending and you have IrTrans supported which is send-only. It would not be my preferred choice for capture, but if that is what a user has then it would be a pity to stop it being used. If you can verify my finding about angling the signal from below then it might be worth a note in the documentation. It is pretty weird behaviour but I know nothing about the hardware. Perhaps you have some idea of why this might be so? An internal reflection messing it up if the signal is aimed straight on, perhaps??

[mathdon]

All tests now repeated on Linux (4 capturing devices, 3 sending devices) with the same results, including the comments on IrToy. Sending was tested with capturing on Win10 with IR Widget. So as far as I can tell, all is good to go .

[Barf]

Version 2.3.0 has been released, and is available for download here. (It is the first release after 2.2.6.)

The handling of serial devices (in particular IrWidget, IrToy, CommandFusion) has been vastly improved, in particular for capturing. The newer NrJavaSerial library is used instead of the old RXTX.

Release notes:

Code: Select all

Version 2.3.0, released 2020-09-25.

* Use NRJavaSerial instead of RXTX, through HardHardware 2.3.0.
* Reworked serial hardware for better performance and reliability.
* Added commitId to About popup (if version ends with -SNAPSHOT).
* Cleanup and fixes of IctImporter.
* Arduino raw export: support boards without flash functions. #398.
* Optionally chop the signals of IctImporter. #395.
* Make chopThreshold user settable and persistent.
* Possibility to invoke chop on raw signals. #394.
* File -> Import -> Import as raw -> RMDU now invokes correct importer. #388.
* RmduImporter: Better handling of not understood protocols/executors.
* New user option; removeDefaultedParameters.
* Updated protocols.ini to the version of RemoteMaster 2.10build9.
* Misc. bug- and documentation fixes.

Thanx to Graham for feedback and testing!

[mathdon]

I have downloaded both the AppImage and the binary distro to my Linux machine and have noticed a trivial but curious difference between them. It is probably due to the different Java versions, the AppImage using Java 11 and the binary distro the Java 8 of my machine. If I go to any of the sending or capturing tabs that has an Open button, that button displays correctly from the binary distro but the AppImage version truncates the text to "Op...". I only mention this because I assume the AppImage is the preferred installation for Linux and "Op..." is ugly and possibly confusing to new users.

[Barf]

Probably slighty different fonts. I will make the Open-buttons wider. Issue.