FTDI Cable shuts down Remotemaster

ckeays · Post by **ckeays** » Tue Nov 12, 2019 11:35 am

Hello everyone,

I purchased four FTDI USBtoTTL cables about a year ago. They were purchased from the same ebay vendor at the same time.

Three of them worked with remotemaster, one I just tried today actually shuts down remotemaster.

I jumpered TXD and RXD on the cable and checked in teraterm by typing any keys on my keyboard, the chars are echoed back to the screen even @ 115200 baud, so I know the cable works.

I also removed the usb connector covering and matched the pinout of a working cable to the non working cable. (sometimes they wire the RXD and TXD or the CTS & RTS backwards). The wiring is good. I even traced each wire in the cable from the connector to the circuit board on the USB side, wiring is good.

I am using the latest remotemaster with windows 7 x64.
RemoteMaster v2.09 build 8
java.version = "1.8.0_231"

Anyone ever see this problem?
I don't care if I have to throw the cable in the garbage, just curious to know the reason why this is happening or if there may be a simple solution.

mdavej · Post by **mdavej** » Wed Nov 13, 2019 11:03 am

I've had this issue for a few years now. In my case, it's not the cable, rather RM's port scan that crashes RM. If I specify the comm port instead of using "auto", I can avoid the crash.

I assumed it was a Java thing specific to my hardware, so never reported it.

ckeays · Post by **ckeays** » Wed Nov 13, 2019 1:15 pm

mdavej wrote:I've had this issue for a few years now. In my case, it's not the cable, rather RM's port scan that crashes RM. If I specify the comm port instead of using "auto", I can avoid the crash.

I assumed it was a Java thing specific to my hardware, so never reported it.

It worked. I have to specify the com port like you suggested.

The error only occurred on win7x64 and not on my older Windows XP computer. Must be the java version.

Thanks

Barf · Post by **Barf** » Wed Nov 13, 2019 1:55 pm

There is almost always interesting information in rmaster.err when something like that happens. Please upload to the diagnostics area.

ckeays wrote: I purchased four FTDI USBtoTTL cables about a year ago. They were purchased from the same ebay vendor at the same time.

5 volts or 3.3 volts?

ckeays · Post by **ckeays** » Wed Nov 13, 2019 5:13 pm

Barf wrote:There is almost always interesting information in rmaster.err when something like that happens. Please upload to the diagnostics area.

here it is:
http://www.hifi-remote.com/forums/dload ... e_id=25713

Barf wrote:
ckeays wrote: I purchased four FTDI USBtoTTL cables about a year ago. They were purchased from the same ebay vendor at the same time.
5 volts or 3.3 volts?

I don't understand the question. I thought all of the data lines in USB are 3V. (never 5V)
There is no power connected to the remote from the cable, the remote uses 2 AA batteries. The remote is a URC-2125.
The wires that are connected to the remote are RTS, RXD, TXD, and GND.
The three other cables are working without errors. This is the only cable giving me trouble and it isn't a problem as long as the com port is selected and autodetect is off.
thanks

Barf · Post by **Barf** » Thu Nov 14, 2019 7:08 am

Hmmm, nothing really interesting there. The last line says

Code: Select all

Testing interface: JP1.X Serial

so I assume that the program crashed just after.

When a JNI library crashes Java (like here), Java normally writes a crash file somewhere. Can you find that file?

5 volts or 3.3 volts?
I don't understand the question. I thought all of the data lines in USB are 3V. (never 5V)

USB is USB, but the purpose on the chip/cable is to translate the USB world to an outside serial world, possibly with other signal levels. There are FTDI products with several different levels. The one to use for JP1 remotes is normally (?) 3.3 Volts.

ckeays · Post by **ckeays** » Thu Nov 14, 2019 4:00 pm

I searched and I cannot find any log files.
No big deal, I won't use this cable.

Thanks

mdavej · Post by **mdavej** » Thu Nov 14, 2019 4:44 pm

Barf,

Thanks for helping on this issue. It's pretty repeatable on my system. I'll give it a try in the next few days and post the logs if I can find them.

Barf · Post by **Barf** » Fri Nov 15, 2019 1:33 am

Barf wrote:When a JNI library crashes Java (like here), Java normally writes a crash file somewhere.

On Linux, this file is called hs_err_pid<pid>.log (where <pid> is the process number) and is written in the current directory. So probably there is something similar on Windows. Possibly in a hidden directory...

Article from Oracle.