Guys, this thread is literally pain to read.
@Fungus - stop being defensive and actually do what you are asked to test if you want that people help you to diagnose the problem. You still haven't posted the entire setup - how is that Arduino powered up? Using a second USB cable? A schematic would be really helpful - it is hard to see which wire goes where.
BTW, the polyfuse stuff is nonsense - only the current through the Arduino + your Wifi is flowing through it, so if your FTDI module is drawing too much current, that
fuse cannot see that! ![Banging Head |O](https://www.eevblog.com/forum/Smileys/default/bangheadonwall.gif.pagespeed.ce.8iLbFYV4Bc.gif)
You could have a dead short on the FTDI module and the fuse wouldn't trigger, because the module isn't powered through it.
@The FTDI chip/module blamers
Of course I did. I used the python script that runs on Linux that was posted in the other thread (it does the same as FTDI's "brick-em-all" driver but non-destructively).
Yes, of course they were loaded. I was using PUTTY serial terminal to view debugging info via the FTDI adapter.
This obviously proves that the module does work and isn't bricked. I have seen that script and if the module was dead, there is no way for it to pass that test. So can we put this particular theory to rest?
Junk, you trigger on CH2. So how do you expect to see a failure on CH1. Just put resistors in series of both lines and check what happens. And those waveforms are very "clean" as I see.
P.S
So you even didn't try to check if your FTDI at least pretends to be genuine but found who to blame right away, nice.
You are too fast to judge here. What are you expecting to see? The CH1 shows data from the PC to the chip where there won't be any (he didn't transmit anything to the chip yet). Yeah, there is a bit of ringing on the signal, bloody big deal - this is 110kbps (or slower) burst ... I guess it is pointless to explain you that this cannot crash a PC, at worst the FTDI adapter would read garbage.
The Vmin/Vmax values are a red herring - the scope is picking up the ringing spikes.
Anyhow, this is pointless to continue troubleshooting like this. The circuit needs to be first cleaned up and tested bit by bit (divide and conquer strategy):
1) Test the FTDI module standalone, with connected RX to TX line (loopback). Are you seeing what you are typing in Putty? (make sure local echo is off - should be off by default). I assume this will work, because it has passed the tests, but it is a good sanity check. It will also make sure that it isn't the driver causing some weird-ass problem.
2) Make sure you have
proper ground connections everywhere. That means connecting ground wires from your level converter to the Arduino (Is that pink wire ground? It is hard to see. Man, why not to use black as ground instead as is standard?), connecting a ground wire between the FTDI and the Arduino. This is essential, without that it won't work right.
3) I am quite not understanding the point of having the Arduino in the loop (apart from using the 3.3V power rail). What is the firmware doing? Shuffling data between two UARTs, where one is connected to the FTDI and the other to the Wifi? Why aren't you using the Arduino's regular USB-to-serial instead (eliminating the FTDI?). Or why not to connect the FTDI module directly to the Wifi and using only the power regulators on the Arduino?
3.5) Connect the Arduino & the FTDI together (remove the Wifi module with its level converter). Does this work? If you are using the firmware in the Arduino to copy data between the two UARTs, you should be able to short the TX & RX lines together on the one that is to be connected to the Wifi - loopback test again. Is it working?
4) Connect the Wifi - is it working?
When anything breaks during the testing, you know it could have been only the last thing you have changed that broke the camel's back. Why did it break? Too much current? Short circuit? Measure!
Please, do the above and then report back.