IrScrutinizer: capturing, generating, analyzing, import, exp

[Slimline Salad Dressing]

Is the baud rate the 'bits/s' dropdown? I've tried all options with no difference.



So maybe I misunderstand how drivers work, but if on my Mac after I installed the CH340 driver and the Arduino IDE software could then see the Arduino OK, how come other software like IRScrutinizer can't see it too?

[Barf]

Is the baud rate the 'bits/s' dropdown?

You are right. (I still keep saying "baud" even though it (strictly speaking) means something different. )

Please try (with the Arduino plugged in, not running IrScrutinizer or Arduino IDE)

Code: Select all

sudo ln -s /usr/local/share/irscrutinizer/irscrutinizer.sh /usr/local/bin/harchardware
time  harchardware --class GirsClient -d /dev/ttyUSB0  --loglevel ALL version

[Slimline Salad Dressing]

Thanks - delayed by New Year - hope you had a good one.
Have entered those lines, this was the result:

time harchardware --class GirsClient -d /dev/ttyUSB0 --loglevel ALL version
[org.harctoolbox.harchardware.Main extraSetup] FINE: appHome = /usr/local/share/irscrutinizer
[org.harctoolbox.harchardware.Main extraSetup] FINE: libDir = /usr/local/share/irscrutinizer/Linux-amd64
[org.harctoolbox.harchardware.Main processCommand] FINE: Loading libdevslashlirc from /usr/local/share/irscrutinizer/Linux-amd64 succeeded

[Barf]

hope you had a good one. Thanks - delayed by New Year - hope you had a good one.

Thanx, and the same to you-

(Actually, my New year was not that good, considering returning it for a cash refund. )

time harchardware --class GirsClient -d /dev/ttyUSB0 --loglevel ALL version
[org.harctoolbox.harchardware.Main extraSetup] FINE: appHome = /usr/local/share/irscrutinizer
[org.harctoolbox.harchardware.Main extraSetup] FINE: libDir = /usr/local/share/irscrutinizer/Linux-amd64
[org.harctoolbox.harchardware.Main processCommand] FINE: Loading libdevslashlirc from /usr/local/share/irscrutinizer/Linux-amd64 succeeded

OK, so /dev/ttyUSB0 exists and can be opened, but there is nothing there responding as expected. (You can retry as root:

Code: Select all

sudo  harchardware --class GirsClient -d /dev/ttyUSB0  --loglevel ALL version

(answer the popup by "Continue") but I doubt it will make any difference.)

So the Arduino is not OK (hardware or firmware).

[Slimline Salad Dressing]

;D

Here's the output for that sudo line:

sudo harchardware --class GirsClient -d /dev/ttyUSB0 --loglevel ALL version
/usr/local/bin/harchardware: 58: /usr/local/bin/harchardware: MESSAGETAIL+=You probably want to correct this. Otherwise, functionality will be limited.\n\n: not found
/usr/local/bin/harchardware: 59: /usr/local/bin/harchardware: MESSAGETAIL+=Depending on your operating system, the command for fixing this is typically "sudo usermod -aG dialout root",\n: not found
/usr/local/bin/harchardware: 60: /usr/local/bin/harchardware: MESSAGETAIL+=after which you should logout and login again.\n\n: not found
/usr/local/bin/harchardware: 61: /usr/local/bin/harchardware: MESSAGETAIL+=Proceed anyhow?: not found
[org.harctoolbox.harchardware.Main extraSetup] FINE: appHome = /usr/local/share/irscrutinizer
[org.harctoolbox.harchardware.Main extraSetup] FINE: libDir = /usr/local/share/irscrutinizer/Linux-amd64
[org.harctoolbox.harchardware.Main processCommand] FINE: Loading libdevslashlirc from /usr/local/share/irscrutinizer/Linux-amd64 succeeded
RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0

Not really sure what any of this means?

[Barf]

... I doubt it will make any difference.

So it turned out to be right...

So the Arduino is not OK (hardware or firmware).

I cannot help you any more if you cannot address this.

[Slimline Salad Dressing]

OK, thanks for all your help.

I will look into getting a proper Arduino, not a clone, although I saw on the Arduino site the newer Uno doesn't use FTDI, but ATmega16U2 - do you think this could cause me another problem?

https://store.arduino.cc/products/arduino-uno-rev3-smd

[Barf]

First, just for a reference, the debugging command should preferably go something like this:

Code: Select all

$ harchardware --class GirsClient -d /dev/ttyUSB0  --verbose version 
LocalSerialPortBuffered.sendString: Sent '\r'.
LocalSerialPortBuffered.readString: received "OK"
LocalSerialPortBuffered.sendString: Sent 'version\r'.
LocalSerialPortBuffered.readString: received "GirsLite 1.0.3"
LocalSerialPortBuffered.sendString: Sent 'modules\r'.
LocalSerialPortBuffered.readString: received "Base Transmit Capture Receive Led Parameters"
Version of GirsClient: GirsLite 1.0.3

Now back to the program

There is nothing wrong with clones or CH340. I have built tens of this thing, all working perfectly (well, one board was DOA, but that is another story). It works fine, AT LEAST on operating systems supporting them natively, like Windows 10 and modern Linuxes.

Either you have a defect board (have you tried replacing the USB-cable?) or you have somehow broken firmware.

[WagonMaster]

Barf, many thanks for writing and maintaining IrScrutinizer! I've run it for the 1st time recently and, although I'm not utilizing even a tenth of its capabilities, I've found it to be a very convenient way to test IR signals, coupled with a variant of Kevin Timmerman's IR Widget that I lashed together a few years ago. Quite conveniently, I no longer need to find a drive with a bootable Windows partition to run 'IRScope'. I can run IrScrutinizer under Linux! So, again, thank you!

While running it, I've noticed some things that might merit your attention.

For the record, I'm running 64-bit Slackware 14.2 Linux and IrScrutinizer via 'IrScrutinizer-2.3.1-x86_64.AppImage'.

A very minor issue is seen in the window that appears after selecting the "Help" pushbutton on the "Capturing hw", "IrWidget" page. It shows the superfluous text "it":

Plug the IrWidget it into the computer.

A more troubling thing is what I find happening to my ports. Every time I start or exit IrScrutinizer, it seems to be semi-permanently disrupting communication on '/dev/ttyUSB0', even after I've configured it to find my IR Widget on a specific port (say, '/dev/ttyUSB1'). In fact, I've seen some preliminary evidence that it might even be disrupting communication on any '/dev/ttyUSB{#}' port with a lower number than the IR Widget.

In my case, my UPS is typically communicating with the PC on '/dev/ttyUSB0', so starting or stopping IrScrutinizer forces me to kill and re-start my UPS monitor.

BTW, this all happens without my having even attempted to "Open" the IR Widget via the "Capturing hw" page. For the record, when I do eventually "Open" the IR Widget, it works fine with IrScrutinizer.

Ideally, I'd be able to specify the IR Widget's port myself, much like I can in RMIR's "Port Selection" dialog for the FTDI cable used to connect a remote, rather than having to choose from a set of detected ports. More specifically, I'd really like to be able to manually enter something like '/dev/ir-widget' because that is a symbolic link set up by a 'udev' rule to whatever '/dev/ttyUSB{#}' port on which the IR Widget is detected, much like I do for all my USB devices. Running Linux means I don't usually have to put up with that Windows nonsense of playing "find the COM port". In fact, IRScope under Windows could not "open" the IR Widget on "COM15", which is what (mercifully, as it turned out!) drove me to seek alternatives, thence to IrScrutinizer.

I can do more tests if needed. Of course, none of these issues are "show stoppers", but any consideration you can give to them, whenever that might be, is appreciated.

[Barf]

Thank you very much for the feedback!

It shows the superfluous text "it":

Thanx; fixed.

Every time I start or exit IrScrutinizer, it seems to be semi-permanently disrupting communication on '/dev/ttyUSB0',

Hmmm, you are having the UPS connected to /dev/ttyUSB0, the IrWidget to /dev/ttyUSB1, and just starting IrScrutinizer breaks the UPS connection. When starting, the program looks for serial devices using CommPortIdentifier.getPortIdentifiers() from the serial library nrjavaserial. My guess is that breaks the USP connection somehow.

In fact, I've seen some preliminary evidence that it might even be disrupting communication on any '/dev/ttyUSB{#}' port with a lower number than the IR Widget.

I find this very implausible; can you please verify?

This is strange, and I have not seen anything like that before. It can be a problem with nrjavaserial, the OS, or the UPS. (Subjectively, I consider the last one most likely).

Ideally, I'd be able to specify the IR Widget's port myself, much like I can in RMIR's "Port Selection" dialog for the FTDI cable used to connect a remote, rather than having to choose from a set of detected ports. More specifically, I'd really like to be able to manually enter something like '/dev/ir-widget' because that is a symbolic link set up by a 'udev' rule to whatever '/dev/ttyUSB{#}' port on which the IR Widget is detected, much like I do for all my USB devices.

Point taken. It appears that you know how to configure udev, but, as you write, it won't really help.

Please post the output of lsusb with both the UPS and the IrWidget plugged in. What is the exact manufacturer and type of the UPS?

The current development version is very close to the soon-to-be-release 2.4.0. It would be nice if you can try that.

[WagonMaster]

The plot thickens...

I've done some more testing. But let me first mention:

1. The (RS-232) UPS is actually irrelevant. It communicates with the PC through an 'Iogear' RS-232-to-USB converter, model 'GUC232A'. That's what my Linux PC is really interfacing with.
   
   But today's testing convinces me that those details are probably irrelevant. Nevertheless, I want to be 100% clear on my hardware setup to avoid confusion.
2. This testing discussed below was done without the IR Widget ever being plugged in.
3. Contrary to what I believed yesterday, I've seen evidence that the latest version of RMIR may also be disrupting communication in what appears to be the same way, but under different circumstances. I will have to look into that more when time allows. But, for today's testing, I did not run RMIR at all. (I think running RMIR was contributing to some confusion in my testing when I was alternately running it and IrScrutinizer yesterday.)

As I said in the OP, typically, the UPS is on '/dev/ttyUSB0' (because that GUC232A is usually the only "serial" USB device connected to the PC at bootup. But, for irrelevant reasons, today's testing was done with the UPS/GUC232A on '/dev/ttyUSB1'. That turned out to be convenient because when I plugged in my FTDI cable ('TTL-232R-3V3-WE', used for JP1 for over 11 years now), it appeared on '/dev/ttyUSB0'.

So, in short:

• ttyUSB0 = FTDI cable (URC-8820 remote control)
• ttyUSB1= GUC232A (UPS)

I opened a couple of consoles and ran a command-line Linux app in each that would open the relevant device and continually read from it (URC-8820 remote control and UPS), so that I could immediately see any comm disruption.

I ran 'IrScrutinizer-2.3.1-x86_64.AppImage'. Both consoles showed immediate evidence that the reads had been disrupted and they did not recover. And, just like my main (GUI) 'UPS monitor' app mentioned in the OP, they had to be killed and re-started. When re-started, both command-line apps begin to report valid data from the UPS and the URC-8820 remote again.

So, AFAICT, something that the 'nrjavaserial' library is doing on IrScrutinizer startup is "naughty".

I don't think it will help much, but, as requested:

Code: Select all

==> lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 004: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]
Bus 005 Device 003: ID 8564:1000 Transcend Information, Inc. JetFlash
Bus 005 Device 002: ID 04d8:0055 Microchip Technology, Inc. 
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 026: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 003: ID 05ac:024f Apple, Inc. 
Bus 001 Device 002: ID 046d:c408 Logitech, Inc. Marble Mouse (4-button)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The GUC232A is:

Code: Select all

Bus 005 Device 004: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]

The FTDI cable is:

Code: Select all

Bus 001 Device 026: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

Remember: I never plugged the IR Widget in at all today.

FWIW, unlike yesterday, I do not see IrScrutinizer disrupting any '/dev/ttyUSB{#}' port on exit. So I rescind that observation/accusation in light of today's enlightened and somewhat more controlled testing.

As requested, I also repeated the 2-console apps debug test with the latest version ('IrScrutinizer-2.3.2-SNAPSHOT-x86_64.AppImage'). Behavior was the same. Comm on both ports is semi-permanently disrupted.

If there's anything else I should test, please let me know.

Thanks for your interest in this!

[Barf]

I claim that, generally speaking, serial-over-USB is not a very good idea. Instead of making a proper USB device, a serial communication from the previous century is just squeezed into USB. To have a security critical component (like a UPS) depend on this does not appear to be a very good idea to me. If you cannot accept "resets", you should not use serial-over-USB. IMHO.

The fact that there does not exist an official, maintained library for serial communication in Java does not exactly make serial-over-USB more attractive. (However, there are several libraries of "hacker quality", nrjavaserial/RXTX,....)

The "disruptive" serial port scan of nrjavaserial (which is nothing but a slightly developed version of RXTX) appear to sit deep in the library. I did some attempt to have it to work without the port scan, but it was not successful. If you want to try, the sources are available at Github.

I also should point out that programs like RMIR and IrScrutinizer are user programs, occasionally invoked willingly by the user, who can fix possible side effects. It is not used for "deployment" nor are they invoked as system programs.

Your desire to use user-supplied device names, which are links and not read device nodes (like /dev/irwidget) is reasonable. It will not make it into 2.4.0 though. I will be happy for a patch...

[WagonMaster]

Barf,

Thank you for taking time to investigate this!

I claim that, generally speaking, serial-over-USB is not a very good idea. Instead of making a proper USB device, a serial communication from the previous century is just squeezed into USB. To have a security critical component (like a UPS) depend on this does not appear to be a very good idea to me.

I don't share your disdain for and/or aversion to "serial over USB". It's a very handy way to leverage "mountains" of hardware and software from the past. Case in point: I simply refuse to stop using (let alone discard) my expensive, perfectly functional UPS, which has been in daily use for 23 years now, simply because it natively speaks RS-232. A simple, common, inexpensive RS-232-to-USB adapter was all that I needed to connect it to my latest motherboard.

If you cannot accept "resets", you should not use serial-over-USB. IMHO.

Even after accounting for the "IMHO" part, I'm quite surprised (and disappointed) to hear you say that.

You're using the euphemism "reset" for what I would call "bad, entirely preventable behavior" (i.e. deliberately and automatically opening a serial port without knowing if it's in use or not).

Surely you would not consider it acceptable for a native USB device to be reset simply because some badly designed software decides that it's convenient to see what USB devices are connected by watching them enumerate on the bus. Right??? Because that's analogous to what's going on here.

I have more to say about the subject, but I think it's best to "agree to disagree".

The "disruptive" serial port scan of nrjavaserial (which is nothing but a slightly developed version of RXTX) appear to sit deep in the library. I did some attempt to have it to work without the port scan, but it was not successful. If you want to try, the sources are available at Github.

Respectfully, I'll pass on that. You know Java far, far better than I do. Frankly, I despise it and hope to continue happily minimizing all encounters with it. So if you tried and failed, I have no chance whatsoever, being honest with myself.

I wrote a simple Linux command-line app a few years ago to read from my IR Widget. The most likely outcome of all this is that I'll put whatever effort I decide to apply into that program at some point instead, since I don't really need a GUI and, if I ever decide I do, can whip one up pretty easily.

The fact that there does not exist an official, maintained library for serial communication in Java does not exactly make serial-over-USB more attractive. (However, there are several libraries of "hacker quality", nrjavaserial/RXTX,....)

Just another reason why I'll never embrace Java.

I also should point out that programs like RMIR and IrScrutinizer are user programs, occasionally invoked willingly by the user, who can fix possible side effects. It is not used for "deployment" nor are they invoked as system programs.

Now that really seems like a rather odd position to take. It seems to me to be attempting to defend the bad behavior of that Java serial library.

IrScrutinizer (using the 3rd-party 'nrjavaserial' library) and RMIR (using the JP1 project's own 'jp12serial' library) are the only times I've encountered software that opens serial ports inappropriately, as far back as I can recall.

But we are clearly of different minds on this point. So, again here, I'll "agree to disagree".

Your desire to use user-supplied device names, which are links and not read device nodes (like /dev/irwidget) is reasonable. It will not make it into 2.4.0 though. I will be happy for a patch...

But as useful as that capability might be, there is absolutely no point (for me) in adding that as long as IrScrutinizer continues to let 'nrjavaserial' abuse my open serial port(s) at startup, before any attempt to use an IR Widget is even begun! So, again here, no patch will be forthcoming.

Regardless of my disagreement with your point of view on "serial over USB" and on the acceptability of a program totally disrupting another program's communication, I still do appreciate your having taken the time to look into the whole issue. I know more now than I did a day ago and that's always a good thing.

[Barf]

IrScrutinizer 2.4.0 has been released, downloadable from here.

This release contains a number of fairly important improvement and fixes. Everyone is encouraged to update, although a snapshot from the last few months is fairly close.

A big thank-you goes to Graham (mathdon) for a number of bug reports and suggestions.

Release notes:

Code: Select all

* Documentation improvements. #269.
* Re-installed the irptransmogrifier command on Windows/setup.exe. #468.
* Fix HardwareManager.close() misbehavior when called during shutdown. #463.
* IrWidget: Add option for not dropping DTR and RTS when opening the device. #462.
* Uses IrpTransmogrifier 1.2.11, see IrpTransmogrifier.releasenotes.txt.
* Option for reporting all decodes, corresponding to decode --all in IrpTransmogrifier. #457.
* Remove incomplete HTTP proxy support. #456.
* Some export formats erroneously case sensitive wrt protocol name. #453.
* Default name ("remote") in MetaDataDialog.
* New name transformations in Parametric Remote: lowercase, uppercase, capitilize. #447.
* Updated export formats Lirc.
* New command line option --loglevel, cf. IrpTransmogrifier.
* Exportformats: better handling of export format parameters. Implemented export formats documentation. #323.
* Some layout tweaks. #366, #401.
* Remove Lirc as sending device (partially replaced by NamedCommandSender). #399.
* Remove IrTrans support (except for the NamedCommandSender).
* Remove explicit IrToy sending/capturing support (in Linux, still indirectly supported through DevSlashLirc).
* AppImage, Mac & Windows w/ embedded Java https bug fixed. #448.
* Intervals in Render/F, S, F, etc now parsed correctly. #437.
* Remove "LIRC Mode 2" as capturing device. #378.
* Redesign hardware configuration and selection. #281.
* New tool for sending named commands "Named Command Sender". #128.

(Actually, 99% of what is now 2.4.0 was finished in June, unfortunately I did not succeed to wrap it up then. Sorry for that.)

[stama]

I don't know if this is the right place to report an issue, but here goes.

I discovered that IrScrutinizer doesn't like to import from file paths containing brackets.

It will throw a "MalformedURLException" when trying to load
- a file named "[2022 09 30] Samsung QLED, Frame, Serif and OLED TVs.girr"
- or from a path which contains brackets, such as: "C:\[2023 08 29] Some folder\Samsung QLED, Frame, Serif and OLED TVs.girr"

If the brackets are not present in the file path/name, then the import works fine.