Here us a couple of good articles to get you started: What is bypass/decoupling capacitor? - Tech Explorations https://g.co/kgs/ySVuTwQ
What Is the Difference Between a Bypass Vs Decoupling Capacitor https://www.alliedcomponents.com/blog/bypass-vs-decoupling-capacitor Decoupling Capacitors And Bypass Capacitors In PCB. - Jhdpcb https://jhdpcb.com/blog/bypass-capacitor-vs-decoupling-capacitor/ https://components101.com/articles/decoupling-capacitor-vs-bypass-capacitors-working-and-applications On Sat, Mar 23, 2024, 9:48 PM Scott Hall <scottgha...@gmail.com> wrote: > In the past folks would add a .022uf bead cap next to each chip across the > chip's power and ground to reduce noise to that chip. Not near the DC-DC > converter, but next to each chip. This goes for the 3.3V regulator as well. > It increased the parts count, but reduced the noise. Then on the lower > voltage, an additional bead cap was added next to each chip or module that > was fed by the lower voltage rail -- something like .010uf. The whole > purpose was to shunt or drain any high frequency component away at the > point of power entry into each integrated component. > > On Sat, Mar 23, 2024, 9:36 PM Charles West via TriEmbed < > triembed@triembed.org> wrote: > >> Hello, >> >> I took up John's offer to help try to figure it out and had a great time >> working on it with him today. I've put the Kicad files up on Github if >> anyone else wants to take a look ( >> https://github.com/charlesrwest/GoodBotControlBoard). Initial >> conclusions are below (John is welcome to double check my notes if he >> wants): >> >> 1. The power line feeding into the linear regulator that feeds the >> microcontroller on the board is fairly noisy. This noise gets >> significantly worse when the Nano is drawing larger amounts of current. >> 2. Adding a large capacitor on the microcontroller side of the linear >> regulator did not seem to help. It still started acting weird when the >> nano booted. >> 3. It appeared that the 5 volt buck regulator in the board was the >> primary source of the noise. >> 4. Replacing the large capacitors in the 5 volt regulators seemed to >> significantly reduce the noise (around half as much?) but didn't solve the >> primary problem. >> 5. John discovered that the buck regulator had a number of different >> modes it can operate in. Some are more likely to produce high frequency >> noise than others and switching to a different mode might help. However, >> switching a resistor appears to have somewhat changed the output voltage to >> 5.5 volts, which makes it unusable for the Jetson nano (but it wasn't >> working anyway and John came up with a work around, so no biggy). >> 6. The big capacitors for the motors are probably too high ESR and I >> should look into replacing them if possible (and doesn't kill price). >> 7. The linear regulator for the microcontroller should probably be >> replaced. It is probably near its limits with the current voltage drop and >> current draw. >> 8. It would probably be a good idea to isolate the voltage sources from >> each other using something like passive t filters in the next design. >> 9. If powering the nano with the buck on the board kills the MCU, maybe >> don't do that? A temporary solution for the demo may be to reuse an old 5 >> volt buck module to power the nano and leave the buck on the board idle. >> 10. The buck on the board might be overpowered for what it is currently >> being used for and that might be a partial cause for the noise. >> >> @Trampas: >> You are 100% correct and I thank you for the offer to use the O-Scope. >> It was the MVP working on this today with John. Your solution is also more >> or less what I'm going to do to see if I can get it demoable. Thank you. >> >> @Nick: >> I think it's more of a power for the boards than control signals issue. >> Also thank you for the battery offer. However, I think I would have to >> redesign the chassis to make that work. >> >> @brian: >> 100%. The power is not stable and needs to be figured out. I'm gonna >> try to patch it to see if I can get it demoable and then do a redesign >> (John's offered to review) to try to get it stable. >> >> I don't think it's the firmware (this time) because the serial >> communication between the nano and the microcontroller had been >> disconnected. The only possible way for them to effect each other right >> now is through the power rails. >> >> Thanks, >> Charlie >> >> >> On Sat, Mar 23, 2024 at 12:46 PM Brian via TriEmbed < >> triembed@triembed.org> wrote: >> >>> Hi Charles, >>> >>> Hearty +1 for everything everyone has said so far. Trampas in >>> particular for suggesting you use a scope on your power rails. Most >>> DMMs do quite a bit of filtering (even if it's in the form of a very >>> slow sample rate) and can't tell you about high-frequency trash on the >>> supply rails (or other lines) that can wreak havoc with sensitive logic >>> systems. If your DMM has a DC+AC mode, try turning that on and seeing >>> what it says is the AC component of the power supply as an intermediate >>> step. >>> >>> Definitely make sure your power is good first; if your power isn't >>> stable, all other bets are off. You want to see a nice flat line with >>> minimal ripple. Make sure you zoom right in on the time axis to see if >>> there's any high-frequency garbage. Also measure as close to the >>> consumers of power as possible (i.e., at IC pins, not at the regulator). >>> Note that DC-DC converters tend to have relatively high amounts of >>> ripple; the 3v3 regulator will filter a lot of that out, but if anything >>> is being fed directly by the 5V supply, you might need more filtering on >>> that rail. >>> >>> Following that, I'd check your ARM firmware for things like polling >>> loops without adequate timeouts when talking to off-chip peripherals. >>> The fact that everything is copacetic until the nano is in the picture >>> makes me wonder if perhaps the ARM core is getting stuck waiting for >>> communication with the nano to finish (assuming they are talking to each >>> other). If you're doing time-critical tasks on the ARM and aren't >>> already, I suggest picking an RTOS (I'm partial to FreeRTOS mainly >>> because of its use on the ESP32 product family; several are available >>> directly in the STM Cube IDE) and learning how to prioritize >>> time-critical tasks so that unpredictable asynchronous communication >>> issues won't get in the way. >>> >>> This is, of course, all very generic advice based on knowing absolutely >>> nothing about your design. :-D Just stuff I've run into on my own >>> travels. >>> >>> Cheers, >>> -Brian >>> >>> >>> On 3/23/24 07:07, Trampas Stern via TriEmbed wrote: >>> > Charles, >>> > >>> > The problem could be several things, the best thing to do is put an >>> > oscilloscope on the power rail and see if that is the problem. I have >>> > an oscilloscope you can borrow if you need one. >>> > >>> > The problem could be many things from noise on ground, to noise on a >>> pin >>> > on the micro, or noise getting to crystal for the micro, again an >>> > oscilloscope will help. However good diagnostic techniques can be >>> > used. For example if you suspect it is the power supply, remove the >>> > 3.3V linear and power the 3.3V from a bench supply and see if the >>> > problem goes away. This does not tell you what is wrong with the 3.3V >>> > rail but lets you isolate the problem for more investigation. >>> > >>> > Trampas >>> > >>> <snippysnip> >>> >>> _______________________________________________ >>> Triangle, NC Embedded Interest Group mailing list >>> >>> To post message: TriEmbed@triembed.org >>> List info: >>> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org >>> TriEmbed web site: https://TriEmbed.org >>> To unsubscribe, click link and send a blank message: mailto: >>> unsubscribe-triem...@bitser.net?subject=unsubscribe >>> Searchable email archive available at >>> https://www.mail-archive.com/triembed@triembed.org/ >>> >>> _______________________________________________ >> Triangle, NC Embedded Interest Group mailing list >> >> To post message: TriEmbed@triembed.org >> List info: >> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org >> TriEmbed web site: https://TriEmbed.org >> To unsubscribe, click link and send a blank message: mailto: >> unsubscribe-triem...@bitser.net?subject=unsubscribe >> Searchable email archive available at >> https://www.mail-archive.com/triembed@triembed.org/ >> >>
_______________________________________________ Triangle, NC Embedded Interest Group mailing list To post message: TriEmbed@triembed.org List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org TriEmbed web site: https://TriEmbed.org To unsubscribe, click link and send a blank message: mailto:unsubscribe-triem...@bitser.net?subject=unsubscribe Searchable email archive available at https://www.mail-archive.com/triembed@triembed.org/
