Home
Help
Search
Login
Register
Recent Posts1
Power/Renewable Energy/EV's / Re: Power supply EMC document is erroneous?
« Last post by AnalogTodd on Today at 02:54:46 pm »Simplification and idealization is used so much in our world to make solving problems easier (not to mention teaching of difficult concepts). Do you take into account the few milliohms of impedance between every connection in a circuit? Very few people do in their designs. Once you get into the 'real world' you often run into these bits cropping up and throwing off your design. The difference between a good designer and a great designer is in being able to figure out what is happening and learn from their mistakes.
How many companies out there just have good designers that don't understand real world implications? You can usually tell by the number of failed projects being left in their wake. Didn't design it with proper filtering? It doesn't pass certifications and it goes on the junk pile when someone can't figure out why it fails. I was involved in figuring out that 40dB drop in supply rejection on a linear regulator that I showed. It could have been left alone and written off as circuit models in SPICE not being as accurate as possible. Instead, we spent time playing with the circuit and found out that the MLCC we had at the input of the regulator made things worse, then spent time figuring out WHY it did so.
In that same vein, there are also people who are great for writing this stuff out in technical articles and including the real world issues. There are also people who are crap at it. Who are authors that you trust their writing and circuits? Personally, I think Jim Williams and Bob Pease were great at getting the details that mattered included in their writing. I've written articles and app notes over the years. I was fortunate to have some of the best engineers in industry review them before publication. I've also been the reviewer of writing that others have done and found fundamental flaws in their arguments. If you don't have the right reviewers going over a technical piece those flaws may never get discovered. I will be one of the first to admit my writing isn't perfect--sometimes you re-read everything you wrote over and over and see what you meant for it to say instead of what it actually says. You can't see the forest because of all the trees blocking your view.
So why spend all this time and energy pointing out the mistakes others make? There are plenty of companies out there trying to do things based on those mistakes and the circuits end up in the trash. Instead, make a better circuit to sell. Are you worried that younger engineers may read this stuff and make mistakes based on it? Then be a mentor to engineers directly instead of in an anonymous internet forum.
Engineering is about designing the best possible solution for a problem at a price point that maximizes profits. A simpler solution may not work as well as a more expensive one, but it may be 'good enough' that it gets the sale. There are plenty of engineers out there who will design the low-end stuff that sells at profit margins that are barely sustainable and will make ends meet based on quantity sales. Those of us who design the higher end solutions don't get the number of sales as the low-end guys, but we make enough in profits from it to be comfortable.
How many companies out there just have good designers that don't understand real world implications? You can usually tell by the number of failed projects being left in their wake. Didn't design it with proper filtering? It doesn't pass certifications and it goes on the junk pile when someone can't figure out why it fails. I was involved in figuring out that 40dB drop in supply rejection on a linear regulator that I showed. It could have been left alone and written off as circuit models in SPICE not being as accurate as possible. Instead, we spent time playing with the circuit and found out that the MLCC we had at the input of the regulator made things worse, then spent time figuring out WHY it did so.
In that same vein, there are also people who are great for writing this stuff out in technical articles and including the real world issues. There are also people who are crap at it. Who are authors that you trust their writing and circuits? Personally, I think Jim Williams and Bob Pease were great at getting the details that mattered included in their writing. I've written articles and app notes over the years. I was fortunate to have some of the best engineers in industry review them before publication. I've also been the reviewer of writing that others have done and found fundamental flaws in their arguments. If you don't have the right reviewers going over a technical piece those flaws may never get discovered. I will be one of the first to admit my writing isn't perfect--sometimes you re-read everything you wrote over and over and see what you meant for it to say instead of what it actually says. You can't see the forest because of all the trees blocking your view.
So why spend all this time and energy pointing out the mistakes others make? There are plenty of companies out there trying to do things based on those mistakes and the circuits end up in the trash. Instead, make a better circuit to sell. Are you worried that younger engineers may read this stuff and make mistakes based on it? Then be a mentor to engineers directly instead of in an anonymous internet forum.
Engineering is about designing the best possible solution for a problem at a price point that maximizes profits. A simpler solution may not work as well as a more expensive one, but it may be 'good enough' that it gets the sale. There are plenty of engineers out there who will design the low-end stuff that sells at profit margins that are barely sustainable and will make ends meet based on quantity sales. Those of us who design the higher end solutions don't get the number of sales as the low-end guys, but we make enough in profits from it to be comfortable.
. Both the offset and the input current will drift noticeably when you open/close the cover however by several iterations it is possible to get a reasonable result.