FT232RL based IR transmitter/receiver disconnecting - Page 1
Forum section: electronics / projects

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 27, 2023, 10:32:27 am
content: I recently acquired a Keysight U1272 DMM and am working on an IR interface which is described in the AgIR project here:https://github.com/medo64/AgIR/tree/masterI downloaded the gerbers and then ordered and built the board. The board was then connected my PC running Linux and it seems to work, but only sort of. The USB connection gets dropped after a short delay of maybe maybe 10 - 20 seconds. The /dev/ttyUSB0 device then disappears, although the FTDI UART remains listed in the lsusb output. I have a couple of other devices based on the FT232RL chip and these work fine. The author describes a test whereby Tx and Rx are temporarily linked to echo the output back to the terminal. I have removed the IR devices and performed that test which resulted in maybe two or 3 characters being echoed back before the terminal shuts down.I don't have any reason to think that the chips are fake but I can never be 100% sure. I purchased a pair of them from what appeared to be a bona-fide seller and they were not that cheap. One has already been used in another project and is working fine. However, this one is playing up.The author has a hand drawn diagram on their project page, but from the design and photos of the circuit board it is evident that this is not complete. I extracted the files from the project ZIP file and loaded them into DipTrace and was able to access the BOM list. Based on this and examining the circuit board, I can see that the circuit includes the VCC filtering components that are shown on the FT232RL datasheet. For completeness, I have re-drawn the full diagram in KiCad which I have attached below.Does anyone have any idea why the serial connection on this one might be dropping out after a few seconds?

author: eneuro
author_rank: Super Contributor
timestamp: August 27, 2023, 07:32:28 pm
content: Quote from: WaveyDipole on August 27, 2023, 10:32:27 amI use Silicon Labs CP2102 Classic USB Bridge under Linux without any problemsDismiss FTDIchips after watching thisEEVblog #676 - RANT: FTDI Bricking Counterfeit Chips!:

author: dmendesf
author_rank: Frequent Contributor
timestamp: August 27, 2023, 10:18:48 pm
content: We are now in the position that you plug some random board with FTxxxx, get bad results and don't know if it's a manufacturing defect, bad project or fake chip. I've fought a lot with a FT232RL board a few weeks ago losing packets. Thought it was my bad firmware at the device being debugged but turned out to be a fake FT232RL. Had the bright idea to source some known good from Digikey/Mouser/FTDI online and change the fake but it was out of stock in all of them. At the end changed the converter board for one based on FT232HL (never saw a clone of this one) and it worked very well (even at 12Mbits/s line speed at serial side, amazing).

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 28, 2023, 10:38:03 am
content: Quote from: eneuro on August 27, 2023, 07:32:28 pmThat's quite a rant but it seems a justified one! I was aware that Prolific had rendered the PL2303 driver non-functioning under Windows when it encountered a fake chip. I ran into this problem myself after I purchased an 50GBP adapter (as priced probably over 10 years ago now) product for an Astronomy project that some time later no longer worked under Windows. It does still work under Linux so it would appear that unlike FTDI, Prolific did not update the microcode. They only updated the Windows driver to pop up a specific error message. I gather that this move did not help their reputation either either, but for the unwitting customer, although the problem was not their fault, they ended up with a product that was rendered useless for running with the Windows software for which it was intended.As Dave mentions in his video, I am one of those end users would not have known at the time of purchase that the product they had purchased contained fake versions of these chips, although in this case, Prolific rather than FTDI was responsible for the end result. I imagine such devices could theoretically be fixed by someone with the correct tools and expertise by replacing the fake chip with a genuine one, although this would not be a trivial matter for an average end user.Quote from: dmendesf on August 27, 2023, 10:18:48 pmSadly, I have to concur with your assessment and Dave's comments in the video. The PL2303 chip seems to be unobtainium, whereas the FT232RL, despite being listed, is not found in stock at the major suppliers like Farnell, RS or Digikey. This is why I ended up purchasing from eBay, but carefully choosing a UK seller whom I thought to be reputable, rather than ordering direct from China.Incidentally, I am curious as to whether anyone has had a problem with those FT232RL adapters for Arduino?https://www.ebay.co.uk/itm/255952061835There are a lot of them about as potential sources for FT232RL chips and so far, the couple I have purchased have been fine. However, again the question arises - are those chips genuine? The price of those boards would seem to suggest that the FTDI chips on them are clones.Quote from: dmendesf on August 27, 2023, 10:18:48 pmBoth the FT232HL and CP2102 mentioned by eneuro can be obtained from a major supplier, but both have a different form factor to the FT232RL. With FTDI there is now the issue of trust, however in either case the board layout would need to be modified. This is something I could probably do in KiCad and then order a new set of boards. I have never worked with QFN type chips so working with the CP2102 might prove interesting...

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 29, 2023, 03:37:54 pm
content: Ok, I think I have figured out why the device was mis-behaving, but ot was not what was expected!I found a CP2102 breakout board in my box of bits so as a test I decided to try substituting this for the FT232RL. The USB-A connector was removed and the USB cable attached in its place. I then linked up Tx and Rx. The result was disappointing because the behaviour was exactly the same as with the FT232RL. The terminal was closing almost immediately after firing it up and the /dev/ttyUSB0 device was disappearing. That seemed to eliminate the either UART chip. The USB cable was then removed and the original USB-A header put back. The CP2102 breakout board was then tested again with Rx/Tx still connected to each other, the same thing happened! Was it a problem with my Linux machine? I tried a couple of other USB breakout boards that I had and they worked just fine.It was at this point that I noticed some hot glue residue between VCC and D+ pins. Could the hot melt glue be causing the problem I wondered? The residue was removed et voillà, the CP2102 board was restored to normal working order again!Woth that in mind, I then cleaned up any remaining hot glue residue from the IR interface board and re-instated the USB cable and performed the same test. This timer the terminal was stable and characters were echoed back as expected. Problem solved! I had been securing the wires from the USB cable to the board using hot melt glue and it was the hot melt glue that was the problem!Unfortunately the IR part of the circuit still does not work. On the scope I can see normal output from the FT232RL, but the output from the FET does not look. I have subsituted the FET but no difference so I need to investigate further. At least the UART problem appears to be solved.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 31, 2023, 07:51:18 am
content: The hotmelt glue theory just doesn't make sense. I probed the resistance of the un-melted glue sticks and the melted residue but got no readings whatsoever so there is no electrical resistance in the glue. Its definitely an insulator. My remaining theory is that I was extremely unfortunate and got some contamination or stray strand of wire shorting something both times....Probing the IR circuit seems to return some rather odd results. I have been testing the receiver by pointing a TV remote at it. In circuit the scope shows no received pulses whatsoever. However, if remove the IR receiver from the PCB and connect it directly to the scope probe, I get a nice square pulse of approximately 1V in amplitude when I press a button on the remote, so the IR receiver device itself appears to be working, but nothing happens in circuit.On the sender side, the output trace on the FET looks skewed. The output rises to high and a very small pulses appear fractionally off the high level and at the end of the sequence there is a very long fall time. I tried swapping the FET, but the same result. If I remove the IR Tx LED device I get the same result. A batch of bad FETs?

author: RoGeorge
author_rank: Super Contributor
timestamp: August 31, 2023, 10:28:24 am
content: Take it step by step, disconnect the IR receiver power pin and the Tx IR LED too, so to make sure there are no shorts that draw too much power in the IR part. Leave only the USB to serial chip and test the chip is detected. You should have decoupling capacitors on +5 Vcc, but not too big so to not mess with the USB standards, any <10uF+100nF in parallel should be good enough.First of all, measure if you have stable +5V at your board. Might be just a bad cable or a bad connector somewhere. Once your chip is detected, try to write something to it, to see if you have access rights, e.g. try als > /dev/ttyUSB0. Use whatever name your device enumerates, mine was /devttyUSB0. Should give no errors, and the output oflsshould go to the serial port (for this command only).If you don't have access rights and the above gives access errors, add your username to the group 'dialout', on a Debian based distro, that would besudo adduser $USER dialout. If after that you still don't have rights to access the USB serial ports (maybe your distro doesn't have the 'dialout' group configured), you may try to create a new cdev rule file, so to grant access upon whatever you need.Once you have access rights, tie together the Tx and the Rx pins on the serial side, so to echo back whatever you send, and check with a dumb terminal liketio -b 9600 /dev/ttyUSB0(where line feed isCTRL+j), or maybe withpicocom -b 9600 --imap crcrlf /dev/ttyUSB0. You should see the text typed from the keyboard back on the screen, but only when Tx is tied with Rx.Only after this, try to add one by one the Tx IR LED, then check again from tio or minitel (without instrument) then with both the Tx IR LED and the Rx IR receiver, and test again it all still working (from tio or minitel).

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 31, 2023, 01:41:13 pm
content: As IRLML2246 is a P-channel MOSFET that conducts when the gate is at least 1V below the source potential (3.3V in your case), the signal is inverted. So, you'll probably want to reprogram the FT232RL EEPROM to invert TXD.IRLML2246 pinout in SOT-23 is 1-Gate, 2-Source, 3-Drain, which differs from the KiCAD schematic shown. Check your circuit!At 3.3V VCCIO, FT232RL TX high can be as low as 2.2 V if "high current I/O" is not enabled in the EEPROM, and that is not high enough to stop the IRLML2246 from conducting. Thus, I suspect the IR LED is constantly lit. Most cameras are sensitive to IR light, so if you use your cellphone camera to look at the IR LED, you should see if it is lit or not. (The modulation is way too fast to see as any kind of flicker.)You should definitely reprogram the FT232RL EEPROM to enable high current I/O; this might fix your issues.In general, it would make more sense to use an N-channel MOSFET as a low-side switch, i.e. source to ground, gate to TXD via a suitable resistor (3.3k if FT232RL is configured for standard current I/O, 680 Ohm if configured for high current I/O), emitter to IR LED cathode, IR LED anode to a current-limiting resistor, which connects to VCC (5V). 220 Ohm resistor would limit the IR LED current to about (5-1.2)/220=0.017 or 17 mA, but I'd choose the resistor based on the IR LED you use.My current favourite N-channel depletion-mode MOSFET in SOT-23, Nexperia NX138AKR, would be well suited for this, and quite cheap. Others that should work fine are BSS138, NX138BKR, and 2N7002E; many exist, just check that drain current is at least 50mA at 2.2V gate-source voltage at 3.5V drain-source voltage, and Rds(on) is less than ten ohms or so.If you have an NPN BJT, that would also work. It might even be a better choice here. For example, BC847C,215 (my current favourite NPN BJT in SOT-23) would work just fine, although not as a drop-in because the pinout is different. Almost any NPN BJT should work here, because hFE only needs to be about 20 at Ic=20mA, Vce=3.5V for it to work here.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 31, 2023, 06:08:31 pm
content: Quote from: RoGeorge on August 31, 2023, 10:28:24 amThanks RoGeorge. All good advice. Those stages are now tested and working. I have a number of other UART and MCU boards which work fine on the PC, including those based on the FT232RL so can confidently state that Linux USB permissions are OK. With IR parts removed from the board, I can confirm a stable 5V on the USB bus, although at 3.16V the 3.3V output is a little low. On Linux, assuming no other UART device is plugged in, this FT232RL presents itself as /dev/ttyUSB0. The UART now seems stable on the USB bus and when Rx and Tx are connected together, characters typed at the terminal are echoed back and displayed as expected so we know that the UART is now working OK.On the subject of IR parts, I have a variety to hand. Some devices have part numbers and I have identified these as 950nm parts. I also have one bag of unknown IR transmitter/receiver pairs with clear and dark lenses and it is these I had tried in the first instance. I also have a bag of clear IR 850nm LEDs from Bright Components. It would seem that the colour of the lens is not indicative of the function of the device and online images can be mis-leading. While transmitter diodes are usually bluish for 950nm and dark for 850nm, they can also be clear. The same seems to be true of IR receiver parts. Receivers can also be either photo-transistors or photo-diodes and may have either 2 or 3 pins. The devices I have, with one exception, have two pins. It was worthwhile to spend a little time identifying exactly what I have and I should have done that in the first place instead of just hoping that the unmarked IR devices would just work. I know I have 850nm IR LEDs as they are clearly identified, but I have no idea whether the receiver parts are photo-transistors or photo-diodes and whether they receive on a wavelength 850nm or 950nm. So as to be sure, I have now ordered the receiver photo-transistor part (Osram SFH314) that the author was using in his design.Quote from: Nominal Animal on August 31, 2023, 01:41:13 pmThank you for spotting that. I copied the authors original hand made drawing but when I selected the part in Kicad, I chose the wrong pinout option. I have now corrected that. The PCB, however, was ordered using the author's own gerber files and I had assumed those to be correct. Nevertheless, I have since checked and it does seem to be wired correctly for the FET in question.Quote from: Nominal Animal on August 31, 2023, 01:41:13 pmThat was an excellent idea! I couldn't see anything on the phone camera but the remote control did light up while pressing its buttons while viewing with another camera. Initially I had the thought to try substituting the IR LED with a standard colour one which proved useful. The LED stayed turned off, but did flash in response to characters being typed on the keyboard, which indicated that the circuit was working OK. Next I tried the IR LED while viewing through the camera and saw no output at all. A couple of other IR LEDs were then tested and they both worked. I could see a soft flash of light in the camera viewer in response to characters being typed at the keyboard. It therefore seem that the IR LED I was using has failed. This has now been replaced with a new 850nm IR LED and the circuit re-tested to make sure all is still OK.I will have a look at the receiver side once the Osram photo-transistors arrive.Quote from: Nominal Animal on August 31, 2023, 01:41:13 pmI was not aware that it could be. This is something I will need to read up on. Thanks.Quote from: Nominal Animal on August 31, 2023, 01:41:13 pmThanks for those options. I did wonder whether a BJT would work. Some time ago I constructed an IR interface for a Fluke 187 and that uses BJTs rather then JFETs or FETs and works very well.

author: RoGeorge
author_rank: Super Contributor
timestamp: August 31, 2023, 07:05:15 pm
content: Quote from: WaveyDipole on August 31, 2023, 06:08:31 pmIn practice that doesn't make much difference, almost anything would work. Ideal would be to use the same wavelength, for maximum sensitivity, but in practice would work anyway. The selectivity is not that sharp.If you have a working and stable Rx/Tx echo without LEDs, then it means something is very wrong in how the LED and the photodetector are powered.If the USB link drops when the IR components are in circuit it means some spike of current are high enough that the USB port can't deliver (default is 100mA, 500mA is max, but has to be negotiated in software first IIRC) so I suspect the USB supply voltage goes from 5V to something low enough to drop the USB connection.Again take one at a time. Start with the transmitter only, and all the other Rx photodetector part disconnected from power, just to make sure it doesn't draw any faulty current. When youls > /dev/ttyUSB0, if you look at the IR LED through any webcam or mobile phone camera you should see the IR LED flickering. Camera sensors are sensitive to IR, too, not only to the visible spectrum. The USB link should stay rock solid ad the IR LED should appear quite bright on the phone display.If not, there can be that you draw too much current from the 3V3 (that LDO has a max 50mA for FT232RL). Would be easier to drive all from +5V USB, why bothering with 3.3V when you need all you can get for LED and receiver.The transistor that drives the LED is important, though you described so many variants that I don't know what you have right now. To make sure the IR LED is working, power the LED separately from DC, through a series resistor calculated such that the current will be ~10mA or so, and look through the phone or webcam to see if it light in IR.Once you have the IR Tx LED working while the USB link remains stable, we can move to the IR receiver.Also, please post the current schematic you are using now. A photo with the physical circuit might help spotting any unexpected errors, because you described a lot of substitutes and trials, plus linked to another github schematic, such that it is not clear at all with which parts you are working now.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 04, 2023, 01:52:37 pm
content: Ok, making some progress. The Osram SFH314 IR photo-transistors arrived today and I installed one on the PCB in place of what I was using previously. I was able to capture the mode (*3, *4 etc) codes being transmitted as the rotary control was rotated to select a function on the DMM. Unfortunately sending an *idn? (or *IDN?) did not elicit a response. I had a look at the LED through a camera and it does still flash faintly. I also checked the waveforms on the scope. The graphics show the output from the FT232RL via the 1K resistor when sending an 'a' and the inverted output from the FET. The waveforms seem to be normal to me so I am wondering whether it is now down to the wavelength of the LED?

author: RoGeorge
author_rank: Super Contributor
timestamp: September 04, 2023, 02:02:19 pm
content: Quote from: WaveyDipole on September 04, 2023, 01:52:37 pmThat would work if your instrument is speaking SCPI over IR. Is your DMM an SCPI instrument?Asking because many DMMs do not use SCPI. SCPI is usually find in bench instruments, it originates in orchestrating many instruments for automated testing. Handheld instruments like a DMM that can connect to a PC is not guaranteed to talk SCPI. For example, my Metrix mtx3283 DMM is using MODBUS over its serial IR cable. There is yet another software component that can take SCPI commands (like *IDN?) and translate them into their corresponding MODBUS commands for that particular DMM model mtx3283.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 04, 2023, 05:20:50 pm
content: It works!The DMM is a Keysight U1272A and yes, it should respond to *IDN?However, There were two problems. Firstly, the sent sequence must end in CRLF but PuTTy sends only CR.The second was that the IR device wasn't quite aligned.I ended up loading up Win10 virtual machine and using Realterm (which allows configuration of the line termination characters) to experiment. I now need to find a Realterm alternative for Linux. I tried both GtkTerm and screen. GtkTerm does not find /dev/rfcomm0 and screen does not work. Google searches lead me to beleive that some experimentation with stty ought to be able to set the line ending to CRLF, but no success yet.Can't believe that such a straightforward project has given me such a headache!I probably need to file down the box a bit more for a snugger fit and fill the hole around the cable relief with something. One day, when I get a 3D printer, I might print a custom box for it!.

author: RoGeorge
author_rank: Super Contributor
timestamp: September 04, 2023, 06:37:04 pm
content: Quote from: WaveyDipole on September 04, 2023, 05:20:50 pmRealTerm should work from Linux, too, if you install WineHQ. Might be lighter than to keep a Windows VM, and faster to start because WineHQ doesn't need to boot first. Wine only translate Windows OS calls into Linux OS calls.In Linux, for examplepicocomcan do key remapping:Code:sudo apt install picocompicocom -b 9600 --imap crcrlf /dev/ttyUSB0though, sending SCPI text from a terminal might be too spartan in practice. Ideally one would have to interrogate the instrument for errors, deal with timeouts, convert received results and so on.Might be easier to use something like PyVISA (from Python), or even to write your own SCPI tools.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 05, 2023, 07:35:17 am
content: Thanks. PuTTy and RealTerm were just for test purposes really, although as it turned out on this occasion, PuTTy proved to be misleading.For real use I was intending to try it with Sigrok, although I will have a look at PyVISA as well.