@Cluso99 said:
Can you draw you power setup? Start left to right from the USB input.
Well, IDK what I should really draw. Its just 5V coming in from the FTDI cable (which I either plug into a charger or my PC through some extension cables. I've had problems using hubs before, both insufficient power (crash on SD access) and noise from other devices on the hub (such as the lighting PWM from a mouse) bleeding into the audio output), going through a switch into a 3.3v regulator. It is not complicated.
@Cluso99 said:
You have a 100nf on P1 pin 12. This is where you will need to add a 10-22uF cap across the 100nf. If you don’t have a tantalum then use an electro for now. As I said, not the best but hopefully should work. I cannot really work out what is going on at the regulator, nor what is happening after the P1 power.
Yeah, got it, will add that capacitor in the board revision. Not sure if I'll upgrade it to a tantalum, will have to look into the pricing and footprints and whatnot. And I'll probably reroute the power to the top left section so it doesn't pass underneath the P1
You’re saying a series resistor in rx stops the unwanted resets. Are you meaning the P1 receive on P63? You don’t need one in the other leg as the P1 only outputs 3v3 and that is fine into the FTDI chip.
Can you post a pic of your setup because your problem really doesn’t make a lot of sense?
No, it is the Prop TX -> FTDI RX line. I'll get a picture tomorrow. No, I don't really understand it either.
@jmg said:
If you have found a solution, try lowering the resistor until it fails to check you have enough margin.
Also check on a scope to make sure the baud rate you want to use, is ok with that series R.
Yeah, will check both of that. Although I think I'm set on 3.3k or 4.7k since that's whats needed for 5V tolerance.
It looks like you can add a 10k series R to the Reset TRX base on that layout, which would let you prove the revised reset circuit.
Yeah, I could splice one in like the RX resistor, but that's before the capacitor instead of after it. But I think that's equivalent?
On the next board revision... , I'll add the improved transistor circuit, a 10k RESn pullup and 3.3k series resistors on RX and TX (which as a bonus would allow using a serial adapter with 5V IO levels)
Sounds good, check with a scope on the RESn waveform/width and on the RX and TX levels/edges, when used with your long cable.
Checking single pulses is hard without a storage oscilloscope. I guess I could try writing a program on the PC that toggles RTS really fast.
A series resistor in the P1 TX line to FT chip is not required as you're only feeding 3v3 into the FT chip, no matter if its running on 3v3 or 5v. The only issue here is if the FT chip is not being powered from the USB. If not, then it will try and draw power from the P1 TX pin and that will definitely cause reset problems - it's a known problem! Could this be your problem?
Don't bother with a series resistor to the base of the transistor. The current RC circuit 10nf and 10k gives T=RC = 100us pulse to switch the transistor on when DTR (in your case RTS) goes inactive ie goes from 0V to 5V (DTR & RTS are inverted at TTL levels).
Just draw you power supply as it is routed. ie start from iput, show caps, regulator, caps, tracks, caps, prop pins, caps, and any other circuits. if there is a start, show it. Just do it freehand. I'm just looking for something stupid that you may have missed or messed up. I have found that often if I explain something to someone else, even if they don;t understand, you'll find your problem yourself.
You'll get tantalums typically in 35V and 0.1" pitch. They are a roundish blob just like a ceramic mono. They work really well at their job and it's only recently that monos have replaced tantalums as the preferred choice. If you ever look at an old computer board of 7400 style chips, you will seen tantalums at the power row ends, and 100nf bypasses at every chip.
Unless you have an expensive scope, you're not likely to solve this problem with a scope. I haven't unpacked my older scope for 20 years.
Be careful of what you expect from hubs or PCs , some hubs are passive and provide very little current, even some powered hubs give a max rating but turns out the individual max'es are still not enough to run much. This has caused me issues with external cd/dvd/blueray drives. Same goes for PCs. My original Surface Pro gen 1, no problem for bluray drive. Same drive no way on surface pro 6th gen.
So I did lug down ye' olde scope today and it is indeed the Prop->FTDI serial line inducing noise onto RTS, enough for the transistor to create reset pulses.
I probed a bunch of different configurations, but here's the best one IMO. Top trace is the serial data coming out of the propeller at 2V/div, bottom trace is the collector of the reset transistor, pulled up with 9.4k (and not connected to anything else) at 1V/div. Putting in the series resistor on RX reduces the RX-to-RTS coupling by a lot and removes these reset pulses.
EDIT: putting a series resistor on RTS also seems to stop the pulses
Your 9K4 is connected is between collector and 3V3, not across P9 as you showed in the first post?
Presuming your at 115200 baud, that’s approx 10us, so 2.5us per division, so the reset pulse is about 0.5us.
Your RC time is 10n x 10K = 100us, so your pulse (spike) should be more than full screen.
Working back the other way, reset pulse/spike 100us = 0.2 div (~67% rise time) so 500us per div, 2ms per bit, 500 baud.
Presuming I haven’t made a maths error, something is wrong here. Neither scenario fit the display.
Are you certain the reset series cap and resistor are actually 10nF and 10K ?
Also, try scoping the RTS pin at the input to the 10nF cap.
It’s quite likely you will see some induced switching noise on the FT chip’s RTS line due to your long wires and perhaps pcb tracks, but there shouldn’t be enough charge/noise to operate the RC circuit.
@Cluso99 said:
Your 9K4 is connected is between collector and 3V3, not across P9 as you showed in the first post?
Presuming your at 115200 baud, that’s approx 10us, so 2.5us per division, so the reset pulse is about 0.5us.
Your RC time is 10n x 10K = 100us, so your pulse (spike) should be more than full screen.
Presuming I haven’t made a maths error, something is wrong here. Neither scenario fit the display.
Not quite - The transistor is being triggered by noise, (on the rising edge), so the time constant is not 10nF, but the collecter-base miller = eg 50pF and 10k gives 500ns tau, matches the display.
....
It’s quite likely you will see some induced switching noise on the FT chip’s RTS line due to your long wires and perhaps pcb tracks, but there shouldn’t be enough charge/noise to operate the RC circuit.
See above, the transistor has a hard turn-on, once crosstalk exceeds the 500~600mV level, and the scope is nicely showing that effect.
A series R in the aggressor line drops the dV/dT and so lowers the injected energy into the base.
A series R in the base will also help, as seen in the newer reset circuits.
@Cluso99 said:
Your 9K4 is connected is between collector and 3V3, not across P9 as you showed in the first post?
Yes, I just left JP9 open and hooked the pin that goes to the collector to a 9k4 pullup and the scope probe.
Presuming your at 115200 baud, that’s approx 10us, so 2.5us per division, so the reset pulse is about 0.5us.
Yep, 115200 baud, but I was using the zoom knob in that photo, so the time/div is some uncertain value. But one bit is roughly one div, so it's more like 8.5us/div?
Are you certain the reset series cap and resistor are actually 10nF and 10K ?
There is no series resistor as-is, only one to ground. And yeah, going by the marking, its 10k. The cap doesn't have any markings, so I may actually have it swapped for a 100nF cap (the only other value that is used), but that would increase the time constant.
Also, try scoping the RTS pin at the input to the 10nF cap.
It’s quite likely you will see some induced switching noise on the FT chip’s RTS line due to your long wires and perhaps pcb tracks, but there shouldn’t be enough charge/noise to operate the RC circuit.
Yep, I actually scoped that first and it has some pretty big spikes. These photos also include the scope settings.
And here's with the RX series resistor in place
I don't have one with the RTS series resistor, but it successfully eliminates the resets, too.
@Cluso99 said:
Your 9K4 is connected is between collector and 3V3, not across P9 as you showed in the first post?
Presuming your at 115200 baud, that’s approx 10us, so 2.5us per division, so the reset pulse is about 0.5us.
Your RC time is 10n x 10K = 100us, so your pulse (spike) should be more than full screen.
Presuming I haven’t made a maths error, something is wrong here. Neither scenario fit the display.
Not quite - The transistor is being triggered by noise, (on the rising edge), so the time constant is not 10nF, but the collecter-base miller = eg 50pF and 10k gives 500ns tau, matches the display.
....
It’s quite likely you will see some induced switching noise on the FT chip’s RTS line due to your long wires and perhaps pcb tracks, but there shouldn’t be enough charge/noise to operate the RC circuit.
See above, the transistor has a hard turn-on, once crosstalk exceeds the 500~600mV level, and the scope is nicely showing that effect.
A series R in the aggressor line drops the dV/dT and so lowers the injected energy into the base.
A series R in the base will also help, as seen in the newer reset circuits.
Yea, that crosstalk seems to go to about 500mV, if the scope is to be believed.
@Wuerfel_21 said:
Voltage on collector measures as 3.30, so all is fine there. However, it does a reset when I touch the voltmeter to the pin, idk what that means.
You are introducing a small charge into the reset pin.
The reset input is quite sensitive to any spikes and it also see very short spikes.
In all my boards I have a pullup on reset and a C (10n) to GND as near as possible to the reset pin. This has solved all these spurious reset events.
I learned this the hard way with one of my first boards.
@Cluso99 said:
Your 9K4 is connected is between collector and 3V3, not across P9 as you showed in the first post?
Presuming your at 115200 baud, that’s approx 10us, so 2.5us per division, so the reset pulse is about 0.5us.
Your RC time is 10n x 10K = 100us, so your pulse (spike) should be more than full screen.
Presuming I haven’t made a maths error, something is wrong here. Neither scenario fit the display.
Not quite - The transistor is being triggered by noise, (on the rising edge), so the time constant is not 10nF, but the collecter-base miller = eg 50pF and 10k gives 500ns tau, matches the display.
....
It’s quite likely you will see some induced switching noise on the FT chip’s RTS line due to your long wires and perhaps pcb tracks, but there shouldn’t be enough charge/noise to operate the RC circuit.
See above, the transistor has a hard turn-on, once crosstalk exceeds the 500~600mV level, and the scope is nicely showing that effect.
A series R in the aggressor line drops the dV/dT and so lowers the injected energy into the base.
A series R in the base will also help, as seen in the newer reset circuits.
@jmg
Quite right. I was thinking about the scope pic being the base although I should have realised that would have been inverted. It's a spike turning on the transistor but not enough to keep it on while the RC circuit does it's job.
So yes, a series R from the 10nF to the base would limit the energy into the base. Better to fix it at the base rather than try to fix it from the collector end. A series R before the C might also work here too, and probably easier to fit.
@Wuerfel_21
I'm still not sure why there is so much noise/spikes on the RTS line.
Perhaps even a tiny cap from RTS to Gnd may squelch the spike.
Wonder if the manufacturer deleted any power filtering? Might be a cheapie clone?
And a link to the dongle might help too.
Can you post a pic of your setup and a closeup of the FT dongle? Perhaps we can see something amiss here.
I am at a loss to suggest what is the actual cause, other than power problems. Any of the main suggestions are not going to fix the cause, just hide it.
As i said, i have always used a 10k pullup on the prop reset pin. It’s been more safety than a requirement.
The problem now looks more like the FT is getting power from the prop tx pin rather than its own power supply. Perhaps you can scope the vcc and 3v3 rails on the dongle and see if this shows anything.
Capacitively-coupled crosstalk in a cable happens due to the short rise and fall times of the interfering signal. These can be lengthened with a simple RC low-pass filter at the source of each interfering signal. That's really all you have to do. Well, that and decrease the input impedance of the signal being messed with if you can.
@"Phil Pilgrim (PhiPi)"
This is interference that shouldn’t be happening in a normal setup.
@Wuerfel_21
Can you post a pic of your setup please? There is something not quite right here.
If your wires are longish then certainly this might be a problem. I haven’t seen this problem even using 100mm rainbow wire for my connections.
Seperate the power for the prop, opto isolate the game port. Or any I/O. I transmit constant bits to my PC without disruption, but start by sending a byte first from the PC.
yeah, here you go. This is with the series resistor on RX spliced in (i.e. this actually works, but doesn't if I replace the resistor with a wire). Not much to see, really.
I’m guessing that the prop plug/USB serial is connected to the rats nest on the left top of the pic. There’s no plug to be seen so guess it’s off in the distance somewhere. If that’s the case then Phil is correct, you’re getting coupling between signals. No wonder you have problems.
As soon as I’m back home and get a chance, I’ll post my P2 setup when I use a prop plug on leads. This is the same as i use for P1, without problems. My leads are only 100mm (4”) long, and my pcbs have proper bulk and bypass caps, good power tracking layout, and 10K pull-up on Reset pin (both P1 and P2).
I cannot stress the importance of a good design and layout. So many do not understand this. A poor design can have all sorts of problems that are difficult to diagnose. So, spend your time to understand the design process.
I see so many boards on many forums where the designer has absolutely no design understanding. There is a recent TTL computer design (hack a day?) where there are no bulk or bypass caps in sight!
I’m guessing that the prop plug/USB serial is connected to the rats nest on the left top of the pic. There’s no plug to be seen so guess it’s off in the distance somewhere.
Yes, the actual USB/serial converter is on the other end of the cable.
The cable is 1.80m long. Oddly enough, this alone only causes intermittent problems, but as I said earlier, adding the extra wires in between the cable and the board makes each positive edge on the RX wire cause a reset.
Ok I understand it better now. The 1.8m cable is a shielded twisted cable designed for the FTDI use. But by not connecting directly to the pcb the flying cables are causing a mismatch resulting in the cross-coupling.
When I use the short cables I am using the tiny pcb modules. There is no 1.8m cable in my setup.
We used to run RS232 between computers. RS232 was only designed to run short distances (5-15m) but we used to connect computers (minis and mainframes back in the 70’s) over 50m cables. These cables were special shielded cables. Of course these were using 1488 & 1489 drivers & receivers, and speed was often only 2400 baud. These were synchronous connections so the clocks were present in the cable too. Back then, RS232 was +/-15V. These drivers were slew rate limited. These days, the ultra-fast speeds require much faster switching which result in very square waves and these induce spikes in cables nearby.
Comments
Well, IDK what I should really draw. Its just 5V coming in from the FTDI cable (which I either plug into a charger or my PC through some extension cables. I've had problems using hubs before, both insufficient power (crash on SD access) and noise from other devices on the hub (such as the lighting PWM from a mouse) bleeding into the audio output), going through a switch into a 3.3v regulator. It is not complicated.
Yeah, got it, will add that capacitor in the board revision. Not sure if I'll upgrade it to a tantalum, will have to look into the pricing and footprints and whatnot. And I'll probably reroute the power to the top left section so it doesn't pass underneath the P1
No, it is the Prop TX -> FTDI RX line. I'll get a picture tomorrow. No, I don't really understand it either.
Yeah, will check both of that. Although I think I'm set on 3.3k or 4.7k since that's whats needed for 5V tolerance.
Yeah, I could splice one in like the RX resistor, but that's before the capacitor instead of after it. But I think that's equivalent?
Checking single pulses is hard without a storage oscilloscope. I guess I could try writing a program on the PC that toggles RTS really fast.
A series resistor in the P1 TX line to FT chip is not required as you're only feeding 3v3 into the FT chip, no matter if its running on 3v3 or 5v. The only issue here is if the FT chip is not being powered from the USB. If not, then it will try and draw power from the P1 TX pin and that will definitely cause reset problems - it's a known problem! Could this be your problem?
Don't bother with a series resistor to the base of the transistor. The current RC circuit 10nf and 10k gives T=RC = 100us pulse to switch the transistor on when DTR (in your case RTS) goes inactive ie goes from 0V to 5V (DTR & RTS are inverted at TTL levels).
Just draw you power supply as it is routed. ie start from iput, show caps, regulator, caps, tracks, caps, prop pins, caps, and any other circuits. if there is a start, show it. Just do it freehand. I'm just looking for something stupid that you may have missed or messed up. I have found that often if I explain something to someone else, even if they don;t understand, you'll find your problem yourself.
You'll get tantalums typically in 35V and 0.1" pitch. They are a roundish blob just like a ceramic mono. They work really well at their job and it's only recently that monos have replaced tantalums as the preferred choice. If you ever look at an old computer board of 7400 style chips, you will seen tantalums at the power row ends, and 100nf bypasses at every chip.
Unless you have an expensive scope, you're not likely to solve this problem with a scope. I haven't unpacked my older scope for 20 years.
Be careful of what you expect from hubs or PCs , some hubs are passive and provide very little current, even some powered hubs give a max rating but turns out the individual max'es are still not enough to run much. This has caused me issues with external cd/dvd/blueray drives. Same goes for PCs. My original Surface Pro gen 1, no problem for bluray drive. Same drive no way on surface pro 6th gen.
So I did lug down ye' olde scope today and it is indeed the Prop->FTDI serial line inducing noise onto RTS, enough for the transistor to create reset pulses.
I probed a bunch of different configurations, but here's the best one IMO. Top trace is the serial data coming out of the propeller at 2V/div, bottom trace is the collector of the reset transistor, pulled up with 9.4k (and not connected to anything else) at 1V/div. Putting in the series resistor on RX reduces the RX-to-RTS coupling by a lot and removes these reset pulses.
EDIT: putting a series resistor on RTS also seems to stop the pulses
Your 9K4 is connected is between collector and 3V3, not across P9 as you showed in the first post?
Presuming your at 115200 baud, that’s approx 10us, so 2.5us per division, so the reset pulse is about 0.5us.
Your RC time is 10n x 10K = 100us, so your pulse (spike) should be more than full screen.
Working back the other way, reset pulse/spike 100us = 0.2 div (~67% rise time) so 500us per div, 2ms per bit, 500 baud.
Presuming I haven’t made a maths error, something is wrong here. Neither scenario fit the display.
Are you certain the reset series cap and resistor are actually 10nF and 10K ?
Also, try scoping the RTS pin at the input to the 10nF cap.
It’s quite likely you will see some induced switching noise on the FT chip’s RTS line due to your long wires and perhaps pcb tracks, but there shouldn’t be enough charge/noise to operate the RC circuit.
Not quite - The transistor is being triggered by noise, (on the rising edge), so the time constant is not 10nF, but the collecter-base miller = eg 50pF and 10k gives 500ns tau, matches the display.
....
See above, the transistor has a hard turn-on, once crosstalk exceeds the 500~600mV level, and the scope is nicely showing that effect.
A series R in the aggressor line drops the dV/dT and so lowers the injected energy into the base.
A series R in the base will also help, as seen in the newer reset circuits.
Yes, I just left JP9 open and hooked the pin that goes to the collector to a 9k4 pullup and the scope probe.
Yep, 115200 baud, but I was using the zoom knob in that photo, so the time/div is some uncertain value. But one bit is roughly one div, so it's more like 8.5us/div?
There is no series resistor as-is, only one to ground. And yeah, going by the marking, its 10k. The cap doesn't have any markings, so I may actually have it swapped for a 100nF cap (the only other value that is used), but that would increase the time constant.
Yep, I actually scoped that first and it has some pretty big spikes. These photos also include the scope settings.
And here's with the RX series resistor in place
I don't have one with the RTS series resistor, but it successfully eliminates the resets, too.
Yea, that crosstalk seems to go to about 500mV, if the scope is to be believed.
You are introducing a small charge into the reset pin.
The reset input is quite sensitive to any spikes and it also see very short spikes.
In all my boards I have a pullup on reset and a C (10n) to GND as near as possible to the reset pin. This has solved all these spurious reset events.
I learned this the hard way with one of my first boards.
@jmg
Quite right. I was thinking about the scope pic being the base although I should have realised that would have been inverted. It's a spike turning on the transistor but not enough to keep it on while the RC circuit does it's job.
So yes, a series R from the 10nF to the base would limit the energy into the base. Better to fix it at the base rather than try to fix it from the collector end. A series R before the C might also work here too, and probably easier to fit.
@Wuerfel_21
I'm still not sure why there is so much noise/spikes on the RTS line.
Perhaps even a tiny cap from RTS to Gnd may squelch the spike.
Wonder if the manufacturer deleted any power filtering? Might be a cheapie clone?
And a link to the dongle might help too.
Can you post a pic of your setup and a closeup of the FT dongle? Perhaps we can see something amiss here.
As I said, it's an actual FTDI own-brand cable. I bought it off mouser along with some other stuff, so I'm fairly certain its genuine. https://www.mouser.de/ProductDetail/FTDI/TTL-232R-3V3?qs=Xb8IjHhkxj627GFcejHp0Q==
There isn't much to see on it, so posting a picture wouldn't be very helpful.
The datasheet has this partial schematic. There seem to be 270 ohm series resistors on the outputs from the cable.
Yes, I see the 270Rs.
Do you have the 3V3 link selected?
And you’re taking the 5V from the module too?
Yes to both.
I am at a loss to suggest what is the actual cause, other than power problems. Any of the main suggestions are not going to fix the cause, just hide it.
As i said, i have always used a 10k pullup on the prop reset pin. It’s been more safety than a requirement.
The problem now looks more like the FT is getting power from the prop tx pin rather than its own power supply. Perhaps you can scope the vcc and 3v3 rails on the dongle and see if this shows anything.
Capacitively-coupled crosstalk in a cable happens due to the short rise and fall times of the interfering signal. These can be lengthened with a simple RC low-pass filter at the source of each interfering signal. That's really all you have to do. Well, that and decrease the input impedance of the signal being messed with if you can.
-Phil
@"Phil Pilgrim (PhiPi)"
This is interference that shouldn’t be happening in a normal setup.
@Wuerfel_21
Can you post a pic of your setup please? There is something not quite right here.
If your wires are longish then certainly this might be a problem. I haven’t seen this problem even using 100mm rainbow wire for my connections.
But isn't the long cable what makes it an abnormal setup?
-Phil
I was under the impression that these were short cables. Unfortunately we dont have a pic to see the setup.
Seperate the power for the prop, opto isolate the game port. Or any I/O. I transmit constant bits to my PC without disruption, but start by sending a byte first from the PC.
@Wuerfel_21
An update would be nice
Oh, I have let it sit for the past couple days, so there isn't really anything to say right now
Was just wondering, will wait.
BTW as I said before, a photo might help.
yeah, here you go. This is with the series resistor on RX spliced in (i.e. this actually works, but doesn't if I replace the resistor with a wire). Not much to see, really.
I’m guessing that the prop plug/USB serial is connected to the rats nest on the left top of the pic. There’s no plug to be seen so guess it’s off in the distance somewhere. If that’s the case then Phil is correct, you’re getting coupling between signals. No wonder you have problems.
As soon as I’m back home and get a chance, I’ll post my P2 setup when I use a prop plug on leads. This is the same as i use for P1, without problems. My leads are only 100mm (4”) long, and my pcbs have proper bulk and bypass caps, good power tracking layout, and 10K pull-up on Reset pin (both P1 and P2).
I cannot stress the importance of a good design and layout. So many do not understand this. A poor design can have all sorts of problems that are difficult to diagnose. So, spend your time to understand the design process.
I see so many boards on many forums where the designer has absolutely no design understanding. There is a recent TTL computer design (hack a day?) where there are no bulk or bypass caps in sight!
Yes, the actual USB/serial converter is on the other end of the cable.
The cable is 1.80m long. Oddly enough, this alone only causes intermittent problems, but as I said earlier, adding the extra wires in between the cable and the board makes each positive edge on the RX wire cause a reset.
Ok I understand it better now. The 1.8m cable is a shielded twisted cable designed for the FTDI use. But by not connecting directly to the pcb the flying cables are causing a mismatch resulting in the cross-coupling.
When I use the short cables I am using the tiny pcb modules. There is no 1.8m cable in my setup.
We used to run RS232 between computers. RS232 was only designed to run short distances (5-15m) but we used to connect computers (minis and mainframes back in the 70’s) over 50m cables. These cables were special shielded cables. Of course these were using 1488 & 1489 drivers & receivers, and speed was often only 2400 baud. These were synchronous connections so the clocks were present in the cable too. Back then, RS232 was +/-15V. These drivers were slew rate limited. These days, the ultra-fast speeds require much faster switching which result in very square waves and these induce spikes in cables nearby.