JP1.2 interface using CH340 USB to Serial ?

[HWTest]

I'm trying to build a JP1.2 interface from a CH340 USB to Serial converter.
I've measured 0-3.3V signal levels on the serial side of the converter. I think that should be OK.
Here is how it is connected:

Code: Select all

	            JP1.2 IDC 6              DB9
               6 Data-Out   -------> pin 2 RxD
               2 /RESET     <------- pin 7 RTS
               4 Data-In    <------- pin 3 TxD
               3  GND       -------- pin 5 GND 

Check interface in IR 8.04 is OK but when I try to read a URC39930RJ0 it tells me the remote is unknown and the raw data are 00 01 ... 0E 0F.

I have tried the interface in Hyperterminal and when I "dial" the RTS goes from 3.3V to 0V, when I "hang up" it goes back to 3.3V

I have ran the Debug_Tester and here is the result:

Code: Select all

Opening COM8
DCB paramaters:
  DCBlength=28
  BaudRate=38400
  fBinary=1
  fParity=0
  fOutxCtsFlow=0
  fOutxDsrFlow=0
  fDtrControl=1
  fDsrSensitivity=0
  fTXContinueOnXoff=0
  fOutX=0
  fInX=0
  fErrorChar=0
  fNull=0
  fRtsControl=1
  fAbortOnError=0
  fDummy2=0
  wReserved=0
  XonLim=34496
  XoffLim=8624
  ByteSize=8
  Parity=0
  StopBits=0
  XonChar=17
  XoffChar=19
  ErrorChar=0
  EofChar=0
  EvtChar=0
  wReserved1=0
CLRRTS
CLRDTR
SETDTR
SETBREAK
CLRBREAK
Purging RX and TX buffers
Reading up to 20 bytes to flush out spurious data
Didn't get any spurious data
Sending tEst command (45h)
Reading up to 20 bytes of response
Got no response
CLRDTR
SETDTR
SETRTS
CLRRTS
Purging RX and TX buffers
Reading up to 20 bytes to flush out spurious data
Spurious data read:
  00
Sending tEst command (45h)
Reading up to 20 bytes of response
Got no response
SETBREAK
SETRTS
CLRRTS
CLRBREAK
Purging RX and TX buffers
Reading up to 20 bytes to flush out spurious data
Didn't get any spurious data
Sending tEst command (45h)
Reading up to 20 bytes of response
Bytes read:
  D1
Got D1 instead of an ACK!

Any ideas what could be wrong and what to try next to pinpoint the problem?

[3FG]

Use this document by Tommy Tyler in conjunction with RealTerm.

[HWTest]

Thank you 3FG.

Here is what happens, when proceeding:

Measured values

Code: Select all

button press     RTS         TX
TXD Set Break    3.3V        3.0V
RTS Set            0V        3.0V
RTS Clear        3.3V        3.0V
TXD Clear Break  3.3V          0V

URC39930RJ0 is inoperable after connecting and through the whole sequence, after the RTS Clear the LED blink twice.

I have also tried with an URC-8210, it is very similar, after the RTS Clear the EL blinks twice and all segments are on.

It is kind of working but not the way it is supposed to work.
What could be the problem?

[HWTest]

I was experimenting a little more.
After disconnecting pin 2 (reset) on the JP1.2 connector, the remote was still inoperable, after connecting the cable.
But after disconnecting pin 4 (data in) and reconnecting pin2 on the JP1.2 connector, it behaved like it should, it was operable when RTS cleared, inoperable when RTS was set.
Could the JP1.2 interface on the both remotes be bad?

[3FG]

We don't expect the remote to be functional in any way when the reset line is held low-- the micro is stopped. Whenever the reset line goes high, the remote briefly polls the TXD line (referred to interface). If it has been set to Break, the remote goes into communication mode. If the TXD line is in the normal state, the remote starts up in the usual operation mode, with an active keypad. So I don't see any reason to suspect that either remote is bad. At least you can put the remote into communications mode, which means that the chips do support a break signal. The Silabs CP2101, for example, doesn't.

However, both IR.exe and RMIR use JP12Serial.dll to communicate with flash remotes. It sets up the serial interface to use 2 stop bits, because that's how these UEI remotes work. Checking the CH340 data sheet shows that it is only capable of sending data with 1 stop bit. Probably this chip won't work with UEI flash remotes.

Genuine FTDI chips seem to always work.

[HWTest]

Thank you for your help 3FG. I've looked in the data sheet of the CH340 when troubleshooting the interface, but I didn't know about the two stop bits. I've verified it by connecting a DMM which uses 2 stop bits for serial communication and it too doesn't communicate through the CH340.

I recently bought a FTDI JP1.2-3 cable and it worked but it wasn't reliable. I upgraded the FTDI drivers to the latest version and that was the end. Because it was a fake FTDI chip, the drivers soft bricked the chip (PID0000).
I've sent the cable back to the seller. When researching, what the problem was, I found out, there are a lot of fake FTDI chips out there and you don't know until you install the latest drivers. Now while trying to source a genuine FTDI cable I got the idea to DIY a cable from the CH340 I have and don't use. Now I know it's a no go.

[3FG]

Does your CH340 communicate with any serial device? If it can, that would tend to confirm that the problem does revolve around stop bits, as opposed to the possibility that your particular chip is defective in some way.

I'm interested in stop bits, because the Prolific chipsets don't work with JP2/3 remotes, but do work with JP1.2 or JP1.3 remotes. We have speculated that stop bits are the problem with them also. In Prolific's case, they claim to support 2 stop bits, but folks who write Linux drivers report that the chips don't handle 2 stops entirely correctly. Perhaps the Maxim microcontrollers in JP2/3 remotes are more sensitive to this issue than the Samsung or Motorola micros. We're guessing her to some extent because of course UEI hasn't published their serial protocol. We just know that 8n2 works.

Regarding your experience with a fake FTDI chip, it would help the rest of the community if you tell us which provider sold you a fake chip.

[HWTest]

I've tried the CH340 with an old IMV (Victron) Match 600 UPS (smart serial interface) and PowerFLAG (monitoring software for the UPS) and that worked.

I bought the cable on eBay from the seller zillashop. The cable looks exactly the same as this http://www.diygadget.com/jp1-1-1-1-2-1- ... -chip.html cable on diygadget.com. There was a business card from www.youpcb.com with the cable, which is the same company (TIAO Corp.) which manufactures the cables for diygadget.com. This makes me think, it is the same cable from the same manufacturer.
When I wrote the seller about the soft brick (change of PID to 0000), he was assuring me the FTDI chip in the cable is authentic and offered a replacement cable or a refund, when I send the cable back. Later he wrote he will contact the chip vendor and see what is their position to this issue and also also removed the listing from eBay.
I've sent the cable back and got my refund.

[3FG]

For anyone who may have a bricked "FTDI" counterfeit chip, this post explains how to get Windows to recognize the chip with PID=0000. Once Windows has recognized it, you can then use FTDI's FT-Prog utility to restore the PID to 6001. Of course, you need to have replaced the driver which bricked the chip, but either older or newer ones should work.

[HWTest]

I've found a local FTDI reseller, I have ordered a TTL-232R-3V3 cable and I hope this time it is really genuine.

[HWTest]

The FTDI cable arrived today, it's really genuine (working with the latest FTDI drivers v2.12.00 WHQL) and is working like a charm. Now I'm finally working on my upgrades. I'll upload them, when they are finished.

One tip - you can use an USB PC bracket connector to make the 6 pin JP1 connector. I've took out the contacts from the 5 pin original connector with the help of a needle and then put them in the middle of the 2x5 USB bracket connector. There is enough room around the JP1.2 connector in my remotes, so it fits without cutting or grinding it to 2x3.

[shenson]

It seems I may be having a similar problem to the OP with a CH340 chip. The board I have uses DTR. If I follow the realterm instructions (using DTR instead of RTS) everything is fine and I get back the expected remote ID.

However neither jp1xtest nor RemoteMaster can see the any remotes.

RemoteMaster does cause some activity on the USB serial adapter and the remote does flash though.

[The Robman]

The following is not an answer to your question, but more information to anyone else thinking of trying this. If you just happen to have a USB to serial cable lying around that you want to use, that's fine, but if you're thinking of buying one for this purpose, be aware that there is a cheap cable that is ready to go in every respect except for the fact that it doesn't have an IDC plug on the end. It comes with 6 single pin connectors, which can be glued together or can be replaced with an IDC. Current ebay price is $9 shipped, from China.

Details here:
http://www.hifi-remote.com/forums/viewtopic.php?t=16360

[shenson]

Is the source code to jp12serial available anywhere? If so I don't mind messing around with it to see if I can get this chipset to work. I can think of a few possible workarounds if it is a stop bit issue.

I can see why the realterm test might work: if you're just sending a single character then 1 stop bit looks just like 2 (or more) on the wire.

[The Robman]

Is the source code to jp12serial available anywhere?

Yup, it's in here:
http://www.hifi-remote.com/forums/dload ... &cat_id=41