DIYstompboxes.com

What are some basic EE or electroic engineer designer basics please

1.) Seperate the power supply from other boards
     so if the power supply components short or open u can easily replace
      it with another wall wart easier to troubleshoot when its seperated

2.) Don't mix power supply voltages for digital components and analog components
     they should be seperated power supply lines
     (can cause ticking or switching off/on sounds bleeding into the analog signals)
    The digital components should be "isolated" from the analog components for
    power supply voltages

3.) What components that are really close together can use noise or create
      oscillation sounds when to close together like stray capacitance?
     Because when doing the schematic of the board your going to make in
     electronic workbench or some type of software it will do tracemaking
     for the boards thats sent to the CNC machine shop to press the boards
     When making putting the components/parts and soldering to the boards
      when made sometimes if components/parts are to close together can
      create oscillations or noises in the real world that u didn't know when proto
      typing it on a breadboard or simulating it in software it didn't happen but
      when u make the real board with components solder to it causes oscillation
      and noises from certain components/parts to close together

      Which components/parts when close together would cause oscillations or
      noises please?

Shielding:
4.) When making a prototype on a breadboard of the circuit for a R&D department
     how do u shield the circuit?
      When making the board in real life there is mostly a shielding problem
     what are some basic EE shielding tricks to do in general for basic digital and
      analog circuits?

5.) EE engineers focus on Shielding and ground loops
     What are some basic EE ground loop trick to do in general for basic digital and
     analog circuits?

6.) What others do u guys know about please that can add to my list?

but what do most digital test technicians do ?

What kind of waveform analysis for digital test technicians do ? with truth tables,data sheets(for digital components), pulse train charts

pulse train charts are like 16 or more parallel square or PWM waveforms
and u have to find the time interval offset or phase shift

How would i know if the clock signals are all synced up?

List 10 things a EE designer must know when making a prototype and PCB boards?

You do not need separate digital/analog supplies if you are not doing much switching.  Only when you have clocks and even then you might not worry if the clock is so high that it is out of band for the analog stuff.

1. Separating the power supply is added cost.  The reason to separate the supply to a wall wart is UL.  If you don't plug directly into the wall, you don't have to do that UL stuff, just buy approved AC adaptors.

2. Isolation is good, but again cost, if you don't need to separate things, don't.  Over engineering can lose in the market place as your costs are higher than the other guy's.

3. Inductors are the worst as they create big fields that could go through other loops of wire.  Other than that, just separate wires of vastly different gains, and decouple decouple decouple.

4.  For this read some of the great articles from Linear Tech, or the article by Paul Brokaw of Analog Devices.  These guys have lived this stuff longer than most anyone.

5.  Don't make ground loops that is the secret.

6. have good flow on the board.  If the board is not flowing then you are hosed.

7. aesthetics do count.  If something looks ugly usually it is.

8. The slew of other questions are way too application specific to give a generalized answer.  It is like asking how do you remove the gall bladder of some animal and not naming the animal.

this is for the edification of others.

I shield things on the board and under the board with the insulation from wires I have stripped.  I usually save all of my stripped insulation, so I have a lot to use.

Heres an example (I didnt clean up my board yet):
(http://i14.photobucket.com/albums/a303/call1800ksmyazz/So%20Simple%20Compressor/Compressor2002.jpg)

Heres a few questions...
1. I know its good to clean the bottom of the board's solder joints after you finish to clean off excess flux, but what if it gets to the components?  Can it damage them?
2. What about water, can it damage parts to dip them in water?

QuoteList 10 things a EE designer must know when making a prototype and PCB boards?

1. When to stop.

The others are all trivial compared to that one.

Thanks alot Sir HC for the help

what is good to Isolate or what is some basic engineering component to component isolation to know about please?

Capacitors,inductors,transformers should not be close together right? or close to op-amp input pins or transitors input pins
can amplify noise or oscillations right?

These two are the bomb:

http://www.analog.com/UploadedFiles/Application_Notes/135208865AN-202.pdf

http://www.mit.edu/~6.331/an47fa.pdf

These two guys bring more to the table than all the Red Lobsters combined.

 Sir H C y did u pick those 2 pdf files are they about EE designer they seem to be about decoupling only

Sir HC did u go to EE school? what kind of pdf files are good for EE designers for this type of subject we are talking about
to add on to the list . Like if one of us went on a R&D job interview and they said list 20 things that a EE designer should know
about what would u guys list please?

Ground loops,isolations,seperations etc. what else please?

Did you even look at the two files?  One is on decoupling.  That is huge in PCB design.

The other is on high speed PCB design.  Everything about isolation, and the rest.

All your questions are answered there.  That is why I chose those two articles.

For the twenty things, buy the book by Jim Williams "The Art and Science of Analog Circuit Design".  There is a great quiz for the prospective student there.  But before you get an interview, you have to get the degree.  VERY few people without an EE degree get design positions in industry.  Ground Loops, Isolation, and that crap would be very far down the list, those are secondary and tertiary issues, you have to know C=I dv/dt before those. 

Read those two papers, *understand* those two papers.  Those two guys are great writers and very clear in what they say.  They cover all you asked.

call1800ksmyazz-
Usually water is not a problem.  Old carbon-comp resistors and some old germanium transistors might have moisture issues, but most modern parts are designed to be washed when they are made.  One technique was to put PCBs in the dish washer and run it.  I don't recommend that, but some water or rubbing alcohol shouldn't be too detrimental to the board.  The problem with flux is usually that it can become conductive with moisture and then that starts messing with your circuit.

Thanks Sir HC for the help and information

I went to amazon to look for EE designer books which ones should i get or which ones did any of u guys have when u guys took your EE courses to know about EE designing for R&D

Yes decoupling is going for digital chips,clocks,switching,LFO ticking, thats all i can think of what else is decoupling for?

R&D designer:
basic EE designer should know:
1.) Decoupling
2.) Isolation of components to other components, traces are to close, magnetic fields to close,
        a.) Not good isolation can cause oscillation frequency,ringing,noise, interference
3.) ground loops
4.) shielding- for interferences
5.) ? anything else please?

R&D designer math:
1.) Calculating the input and output impedances and wattage values for resistors
2.) using fourier transform math,fourier series math,laplace transform math
3.) What else do R&D EE designers use math formulas for please?

Paul Brokaw is an analog design engineer working for ANALOG DEVICES.  His decoupling deals with analog circuits.

Math formulas:

I=C dv/dt
V=L di/dt
Ic = Is * exp(Vbe/Vt) + 1
Id = const * (Vgs - Vth)^2 (or some other number)

And a ton more. 

Those are the "rate of change" formulas for current and voltage through a cap or inductor

Quote from: markphaser on November 20, 2006, 03:09:11 PM
Those are the "rate of change" formulas for current and voltage through a cap or inductor

the first two, then the bipolar and mos equations.

Quote from: R.G. on November 19, 2006, 10:54:34 PM

QuoteList 10 things a EE designer must know when making a prototype and PCB boards?

1. When to stop.

The others are all trivial compared to that one.

+1

Quote from: call1800ksmyazz on November 19, 2006, 09:49:06 PM
I shield things on the board and under the board with the insulation from wires I have stripped.  I usually save all of my stripped insulation, so I have a lot to use.

thats not really sheilding, thats just the rubber insulation making sure you don't accidently short out anything, sheilding would be an actual outer conductor which is connected to ground, surrounding the wire thats carrying the signal (shielded cable or coaxial cable), preventing noise and other things from messing with your signal

Seljer is right

Sir H C why would EE designers need to know the rate of change of current going in and out of the cap,inducator,transistor,op-amp,mosfet,fet,tube? what information are they going to use or do with this information from knowing the rate of change or
"transconductance" of input/output and through the component?

they will receive calls for a job-offer.

(seriously!)

Quote from: johngreene on November 20, 2006, 04:08:05 PM

Quote from: R.G. on November 19, 2006, 10:54:34 PM

QuoteList 10 things a EE designer must know when making a prototype and PCB boards?

1. When to stop.

The others are all trivial compared to that one.

+1

I would say:
1) when to start and what the progression of developing an idea is
- In real engineering situations, I have seen more good-ideas/projects fail due to a poor understanding of when you are finished with design and ready to simulate and prototype. Any efficient design effort is going to have a progression of:

idea <-> head-scratching/thought <-> initial design <-> simulation -> prototype -> finish (PCB/writeup...)

If you don't jump steps in that process, generally you can finish what you start - if it was do-able in the first place. Once you have a good simulation (of which paper simulation works too) of the idea, a prototype effort would not involve debugging (a major time-sink) except for trivial stuff. Debugging a design is a strong indicator that an engineer needs to look at how they are doing things rather than the design itself.

- Also, if you have all of the design/prototype work done, the time spent on making a PCB layout is minimal and efficient.

2) When to stop...

Quote from: mojotron on November 20, 2006, 05:47:02 PM

Quote from: johngreene on November 20, 2006, 04:08:05 PM

Quote from: R.G. on November 19, 2006, 10:54:34 PM

QuoteList 10 things a EE designer must know when making a prototype and PCB boards?

1. When to stop.

The others are all trivial compared to that one.

+1

I would say:
1) when to start and what the progression of developing an idea is
- In real engineering situations, I have seen more good-ideas/projects fail due to a poor understanding of when you are finished with design and ready to simulate and prototype. Any efficient design effort is going to have a progression of:

idea <-> head-scratching/thought <-> initial design <-> simulation -> prototype -> finish (PCB/writeup...)

If you don't jump steps in that process, generally you can finish what you start - if it was do-able in the first place. Once you have a good simulation (of which paper simulation works too) of the idea, a prototype effort would not involve debugging (a major time-sink) except for trivial stuff. Debugging a design is a strong indicator that an engineer needs to look at how they are doing things rather than the design itself.

- Also, if you have all of the design/prototype work done, the time spent on making a PCB layout is minimal and efficient.

2) When to stop...

But you need to define 'done'. :)

What I see over and over again, is engineers (we are talking about electronic engineering here and not hobby enthusiast) are always thinking about the design and as it progresses, and test data is collected, they come up with better ways of doing it. Continuously. So it is the common problem of wanting to make the design 'perfect' which is a never-ending process. So, an engineer that is capable of meeting milestones knows when the design is 'good enough' to satisfy the requirements and resist the temptation to make it even better when in the end, it will never be noticed.

It has nothing to do with debugging, it is all about knowing when to stop designing.

--john

thermal design problems/issues:
Its common to have a product come back afters its been sent out PCB and certain components resistors or IC op-amps or transitors that are causes to much heat burning the board what would cause this problems please? to much current or the part is not the right rating for wattage? or op-amp ,transitors voltage rating problem?

PROTECTION circuits in power supplys,op-amps,transistors should have protection diodes for the inputs,outputs,power,ground pins so if any surge of current it protects the IC pins or components

I re-phrased my question

What are 10 to 20 EE electronic designer "issues" or "common problems"?

I need to know the most common designer issues and common problems in general or basics for any PCB boards or circuits please?

Quote from: markphaser on November 20, 2006, 06:43:45 PM

What are 10 to 20 EE electronic designer "issues" or "common problems"?

If it was that simple I probably wouldn't have a job. :)

I'm not saying its simple thats why its 10 to 20 things just to start with some common issues and common problems to list

Quote from: markphaser on November 20, 2006, 04:54:16 PM
Seljer is right

Sir H C why would EE designers need to know the rate of change of current going in and out of the cap,inducator,transistor,op-amp,mosfet,fet,tube? what information are they going to use or do with this information from knowing the rate of change or
"transconductance" of input/output and through the component?

If you don't have an intuitive feel for the circuits then all the math in the world won't help you.

I can look at an op-amp circuit and quickly tell the pertinent details, # of stages, folded or not, and a lot more.  Knowing these equations (I use them on a daily basis) among others gets you solving problems a lot faster than if you have to shotgun it with the simulator.  If you don't have a "feel" for the design you will be slower and, bluntly put, suck.

johngreene-

There was a brilliant book that I got years back on digital design for the 8088 processor.  I forget the writer, but he was great.  He had a ton of maxims that were great for the engineer.  He opened his book with reference to Camus' "The Plague" where one character is working on the "perfect" novel.  He has been toiling away for 10 or so years (I ended up reading the book because of this guy's comments, and it is great to read) and is still on the first chapter.  This is the difference between university papers in the red rag and real-world engineers.  I have to design to specifications on time and in budget.  I don't have to exceed by a huge margin, and often you "save" those really killer ideas for the follow-on.

I think the book above is "The 8086/8088 Primer: An Introduction to Their Architecture, System Design, and Programming (Paperback) "  by Stephen Morse.  It is old, but I have to find more by this guy, he is an engineer's engineer.

Hmmm, now I'm not that sure of what this thread is about???

Quote from: johngreene on November 20, 2006, 06:40:02 PM
...
But you need to define 'done'. :)

What I see over and over again, is engineers (we are talking about electronic engineering here and not hobby enthusiast) are always thinking about the design and as it progresses, and test data is collected, they come up with better ways of doing it. Continuously. So it is the common problem of wanting to make the design 'perfect' which is a never-ending process. So, an engineer that is capable of meeting milestones knows when the design is 'good enough' to satisfy the requirements and resist the temptation to make it even better when in the end, it will never be noticed.

I think this happens a lot when you don't have solid, specific, requirements that scope the design. If you have a schedule and a set of requirements that don't change, you will know when you are done.

One time, a long time ago :icon_redface:, I was on a team designing and laying-out a segmentation/reassembly ASIC for a custom serial interface on a PC add-in card. We did not really have solid direction wrt schedule/requirements for this thing and we spent a lot of time re-doing traces on every layer, making that thing extremely compact, reducing timing skews, chasing down every DRC violation... so that we could put it into several different pin packages and it should work. As soon as we thought we got it done, one of us realized that there was some header bits that were ignored in our design, that were really important if we ever wanted to sniff/sample the wire... As soon as we thought it was OK (we did not need to redirect packets and dropping packets that were not addressed to the unit was OK) we get a change in requirements that it needed to handle those header bits - Yikes!!!  Bad design, bad process, bad requirements - but one heck of a layout if you need a 1/16thW 13 ohm resistor!

Sir HC so why do u use those formulas what for? and why tho?

Markphaser,

Re. your first post: Read chapter 12 of the Art of Electronics (ISBN 0-521-37095-7).

Gentlemen - you are feeding the markphaser.

I can't possibly boil down electrical engineering into a 10-20 point bullet list (which seems to be markphaser's preferred method of communication) but I can give him some reading material. Of course, he probably won't read it or even acknowledge that someone took the time to give him a nice nugget of info, since it requires some effort on his part. He'll just keep broadcasting his endless questions as long as others keep responding to his brainpicking in nauseating detail.

IMO it's better to point the way for someone to find info for themselves and learn than to just spoon-feed them, but whatever... I gave up a long time ago on trying to understand the paint-by-number mentality in this forum- first in circuits, now apparently, in education too. In the end it makes no matter to me. I added my 2 cents and can now ignore this thread as easily as I do others.

Quote from: mojotron on November 21, 2006, 02:02:11 AM
Hmmm, now I'm not that sure of what this thread is about???

Quote from: johngreene on November 20, 2006, 06:40:02 PM
...
But you need to define 'done'. :)

What I see over and over again, is engineers (we are talking about electronic engineering here and not hobby enthusiast) are always thinking about the design and as it progresses, and test data is collected, they come up with better ways of doing it. Continuously. So it is the common problem of wanting to make the design 'perfect' which is a never-ending process. So, an engineer that is capable of meeting milestones knows when the design is 'good enough' to satisfy the requirements and resist the temptation to make it even better when in the end, it will never be noticed.

I think this happens a lot when you don't have solid, specific, requirements that scope the design. If you have a schedule and a set of requirements that don't change, you will know when you are done.

Aha, rarely have I ever seen a solid, specific, requirement spec for a design. Even at this "unamed" Globally established company I worked for, they were re-writing the specification document after the product was 'done' per the previous spec.

Quote from: mojotron on November 21, 2006, 02:02:11 AM
One time, a long time ago :icon_redface:, I was on a team designing and laying-out a segmentation/reassembly ASIC for a custom serial interface on a PC add-in card. We did not really have solid direction wrt schedule/requirements for this thing and we spent a lot of time re-doing traces on every layer, making that thing extremely compact, reducing timing skews, chasing down every DRC violation... so that we could put it into several different pin packages and it should work. As soon as we thought we got it done, one of us realized that there was some header bits that were ignored in our design, that were really important if we ever wanted to sniff/sample the wire... As soon as we thought it was OK (we did not need to redirect packets and dropping packets that were not addressed to the unit was OK) we get a change in requirements that it needed to handle those header bits - Yikes!!!  Bad design, bad process, bad requirements - but one heck of a layout if you need a 1/16thW 13 ohm resistor!

I find that the design process for ASICs tends to be very structured because of the development systems used. They kind of force the function. Where I often see the breakdown is at the system or even board level. People don't review specs, don't participate in meetings, so you don't find out until you are well into it that something isn't right or has been overlooked because someone just now had to get started writing software for it, designing an interface for it, or some other activity that involves them and they finally took a good look at the spec.

--john

the Art of Electronics (ISBN 0-521-37095-7).
Read chapter 12 , is chapter 12 about EE design issues Doug H?

What other books are about EE design issues and EE design common problems please?

Chap 12 covers construction techniques, packaging, pcb layout, etc which addresses your 1st post.

Quote from: johngreene on November 21, 2006, 02:30:23 PM

Quote from: mojotron on November 21, 2006, 02:02:11 AM
Hmmm, now I'm not that sure of what this thread is about???

Quote from: johngreene on November 20, 2006, 06:40:02 PM
...
But you need to define 'done'. :)

What I see over and over again, is engineers (we are talking about electronic engineering here and not hobby enthusiast) are always thinking about the design and as it progresses, and test data is collected, they come up with better ways of doing it. Continuously. So it is the common problem of wanting to make the design 'perfect' which is a never-ending process. So, an engineer that is capable of meeting milestones knows when the design is 'good enough' to satisfy the requirements and resist the temptation to make it even better when in the end, it will never be noticed.

I think this happens a lot when you don't have solid, specific, requirements that scope the design. If you have a schedule and a set of requirements that don't change, you will know when you are done.

Aha, rarely have I ever seen a solid, specific, requirement spec for a design. Even at this "unamed" Globally established company I worked for, they were re-writing the specification document after the product was 'done' per the previous spec.

Quote from: mojotron on November 21, 2006, 02:02:11 AM
One time, a long time ago :icon_redface:, I was on a team designing and laying-out a segmentation/reassembly ASIC for a custom serial interface on a PC add-in card. We did not really have solid direction wrt schedule/requirements for this thing and we spent a lot of time re-doing traces on every layer, making that thing extremely compact, reducing timing skews, chasing down every DRC violation... so that we could put it into several different pin packages and it should work. As soon as we thought we got it done, one of us realized that there was some header bits that were ignored in our design, that were really important if we ever wanted to sniff/sample the wire... As soon as we thought it was OK (we did not need to redirect packets and dropping packets that were not addressed to the unit was OK) we get a change in requirements that it needed to handle those header bits - Yikes!!!  Bad design, bad process, bad requirements - but one heck of a layout if you need a 1/16thW 13 ohm resistor!

I find that the design process for ASICs tends to be very structured because of the development systems used. They kind of force the function. Where I often see the breakdown is at the system or even board level. People don't review specs, don't participate in meetings, so you don't find out until you are well into it that something isn't right or has been overlooked because someone just now had to get started writing software for it, designing an interface for it, or some other activity that involves them and they finally took a good look at the spec.

--john

I have done several ASIC cycles where specs were thown in very late in the game.  Did a motor controller where after the circuit design review they decided to add a new mode of operation.  That sucked. 

Quote from: johngreene on November 21, 2006, 02:30:23 PM
Aha, rarely have I ever seen a solid, specific, requirement spec for a design. Even at this "unamed" Globally established company I worked for, they were re-writing the specification document after the product was 'done' per the previous spec.

This has a LOT of relevance to stompboxing... the best time to 'mod' the circuit is BEFORE you lay it out!
As for the 'moving target' specs... the only upside is, if you have to redo a project, you can use a few things that you learnt the first time.... I notice that in software, if you FULLY specify what you want, the coding goes 100 times faster, funny that :icon_rolleyes:

QuoteAha, rarely have I ever seen a solid, specific, requirement spec for a design. Even at this "unamed" Globally established company I worked for, they were re-writing the specification document after the product was 'done' per the previous spec.

That's one sure way to build in disasters. Another name for that is code-to-market-date or feature-to-whim design.

QuoteI notice that in software, if you FULLY specify what you want, the coding goes 100 times faster, funny that

At one time I managed a software development department responsible for maintenance and new releases of a custom Unix kernel. It became obvious to us that you should spend 80% of your schedule time designing, specifying and reviewing. 10% went to coding, and 10% to testing. We looked at the schedule time available, took our history on code production and could tell within a week when the code would be done. We never missed a ship date. But the long design was the important part.

If you write out in clean, clear prose what is to happen, and document interfaces clearly, you save yourself untold misery in final test.

The other key is the no one ever puts in a single line of code that is not reviewed by another person. Not even the most senior, highly respected coder you have.

Quote from: R.G. on November 21, 2006, 06:59:07 PM

QuoteAha, rarely have I ever seen a solid, specific, requirement spec for a design. Even at this "unamed" Globally established company I worked for, they were re-writing the specification document after the product was 'done' per the previous spec.

That's one sure way to build in disasters. Another name for that is code-to-market-date or feature-to-whim design.

I've heard it called "Feature-creep" http://searchcio.techtarget.com/sDefinition/0,,sid19_gci860179,00.html (http://searchcio.techtarget.com/sDefinition/0,,sid19_gci860179,00.html)

Quote

QuoteI notice that in software, if you FULLY specify what you want, the coding goes 100 times faster, funny that

At one time I managed a software development department responsible for maintenance and new releases of a custom Unix kernel. It became obvious to us that you should spend 80% of your schedule time designing, specifying and reviewing. 10% went to coding, and 10% to testing. We looked at the schedule time available, took our history on code production and could tell within a week when the code would be done. We never missed a ship date. But the long design was the important part.

If you write out in clean, clear prose what is to happen, and document interfaces clearly, you save yourself untold misery in final test.

The other key is the no one ever puts in a single line of code that is not reviewed by another person. Not even the most senior, highly respected coder you have.

Sounds like a large, well-funded company. I've only spent 1/3 of my career at such places and will agree. The other 2/3 of the time I've spent in small commercial startups and it is always a moving target. People want you to put 'something' together so they can see it, then list all the things they hate about it and tell you to do it again. After 4 or 5 rounds of that, they start complaining about it taking too long. Then it's "We need it in 2 months for the 'blah blah' show". You work nights and weekends trying to get it all working in time. They get some feedback from some big-mouth at the show who says "if it does -this- we would order 1000s of these", so the whole things starts over. Naturally it was all fluff and they don't buy it even though they caused the product to morph into something it was never intended to be. So now it is months behind schedule, many times over budget, and it is something that noone wants.

It's all marketing's fault.  :icon_wink:

--john

A sure way to stop that stuff is to require whomever is requesting extra features or added function to write down, date and sign the instructions to do it, along with the financial authorization to pay for the changes.

Or at least it would be if they were dumb enough to actually write it down. Organizational political smarts are not equally distributed.  :icon_biggrin:

I was extruded through formal project management training as a condition of continued employment, and found I liked it. One facet of this training is that there is no such thing as a free lunch. Each time you change something, it costs money and time. And a clear recognition of that is tough to get a loosey-goosey organization to understand.

I PM'd a couple of product releases in the several $10M class, piddly things by that organization's standards. But it was a beautiful and self-actualizing thing to do on the couple of occasions when I was able to ask a VP who had just dictated a product change "How would you like to pay for that?"

The question is just as, if not more appropriate for a small, nimble organization. If your bosses were REALLY good, they would say "How much time and money does it add to the schedule to put in X feature starting in three days when you have had time to evaluate it, and how much does that evaluation process cost me?" Both costs may or may not be considerable, but it's sure that they're not free.

One of the primary values of formal PM is that there are techniques for you to figure out early in the program that you will not make schedule or budget, and estimate by how much. In some cases, you can say with certainty that you are already dead with as little as 20% of schedule time past and 20% of money spent.  It's hard to make a gut-feeling, seat-of-the-pants entrepreneur believe that, though.

Oh, yeah, markphaser. You need to know all this too. Otherwise you'll be fired if you do get an EE job.

R.G is one of those EE 4.0 graduate degree students that get a job as a R&D and the real EE designer sits little bratty R.G in front of a Black box with 3 or 4 wire/terminals and R.G just stares at it like a deer looking at a car's headlights coming at him. The real EE designer comes back every 1hour is everything ok R.G yes yes doesn't have anyones hand to have to hold on to. So i figured R.G is really a R&D graduate with a job screwing light bulds around the R&D department claiming he is a R&D engineer or EE but really just a hobbyist little bratty that his daddy sent him to upper divisions schools all paid for spoon feeding him but don't forget R.G not everyone gets the same fold of cards are u did.

...............????troll..............

Quotetroll

No, he's just irritated. He gets downright belligerent over on HC where he uses walters9515 for an ID.

I do wish there was some way I could help him understand some basics, but I don't think it can be done. And for the life of me I wish I could simply stop responding to this stuff. But it seems to trigger me to try to keep the information straight for the beginners. The correct response to all of this is simply no response at all. I try, but am not always successful.

walters/markphaser/brent/brentwalters/walters9515 is really unusual in that the words appear to get picked up, but there is no understanding that ever gets picked up with them. It is very much like the difference between optical character scanning and reading. OCR turns a picture into letters. Reading turns a picture into knowledge.

The longer and more involved the explanations mp is given, the more questions come back; and the more a complete lack of understanding of the context and meaning behind the words become obvious.

And markphaser, I was not being snide or snotty to you. I was telling you the literal truth. These days, an EE who has no concept of project management is going to have a very difficult time holding on to a good job, and will certainly not get ahead in the organization. It's not enough to know the equations and real world practice of electronics. You have to learn the economics of engineering design, the management and scheduling of projects, and the politics of  your organization.

I have a good book for you to find and read. Go look up and read the PMBOK, the Project Management Body of Knowledge. It'll be very enlightening.

The difference I found between software and hardware is that you have to stop feature creep much earlier in hardware.  Since the top guys know you can always "recompile" the software up until the release day, they think they can change the specs until that point.  Since you have to send out for masks and the like, test jigs, and packaging for hardware, it is harder to keep the changes coming.  Still we add extra transistors and gates on the ICs in case something goes awry.

I don't work the commercial side, I do embedded sys s/w stuff for govt/aerospace. On one project I did, the way we handled requirements creep was to put a prototype out in the field that the customers could play with while we were developing the real system in the lab. That wasn't as burdensome as it might seem, they just got dumps of our lab code when we did new releases and we supported them during operations with it, which were sporadic. This helped give them a reality-check of the capabilities they would have and helped us understand their real requirements and operational environment better. Instead of getting hit with a laundry-list of "stuff they wish we had done" at the last minute, we were able to make small tweaks and course-corrections along the way as we developed the system. It ended up being very successful and they gave us a 99% rating on a customer survey we did after we turned it over. I don't remember what we got dinged the 1% for.

I realize this is a different situation than the typical commercial setup where you have the marketing-sales-team promising everyone the world and etc. Even though its more of a closed and contained environment you still might be surprised. I've had projects cancelled due to out of control requirements creep combined with politics because the right people didnt' show up to the right meetings and etc, etc. In the end a lot of it comes down to how strong (competent) your project management is.

That is a great way to work if your customer is tolerant of it. We did that with some university research people as "customers" on my skunk-works megacomputer back in the day. They liked it a lot.

Some customers cannot tolerate a try-and-tweak approach. In general, business oriented applications such as inventory tracking, accounting, anything where there are dollars and cents immediately in the balance are intolerant. Customers who are themselves developing applications or who are developing research or one-time results are generally more tolerant of tweaks along the way.

And remember, Bill Gates became the wealthiest man on the planet, worth more than the GDP of many countries, by promising us everything, then giving us Windows, a little dribble at a time, and convincing us that really, no fooling, the next release would work better and be more resistant to hacking. So dribbling can be good business, too.

Another 'long time ago', I worked for a huge company on a CPU debugger that literally had to be perfect in it's core features - that project had crazy amounts of process over-head on everything, but we always had rock-solid requirements and were expected to deliver flawlessly on schedule - slipping schedules on hardware, FPGAs, firmware and software was, for the most part, unacceptable. Some people really liked working in that environment because there were no suprises and all of the engineers all of the resources they wanted, used the very best tools and techniques. I initially thought this was pretty cool, but as time went by, I really wanted to do something where I had fewer constraints and moved on.

This was a great experience for me to learn how to do things absolutely 'the right way' - but I was not excited about the work I was doing. And, I also discovered that when there is a situation where you can get all the right resources/time to do things right - you have to deliver to a whole new level of expectations. All of that is good stuff, but it wears on you after a while because people are not perfect and are going to screw up form time to time - and that leads to a threshold of anxiety that is difficult to manage.

From there I worked in a 'lab' job where I did rapid prototyping doing all kinds of HW and lowlevel SW work - the expectations were quite low for the engineering that got done - but everyday was something different. I got tired of that too, there was no real engineering going on with that stuff because there was really no product - all we did was file patents and write papers. Some people really like the freedom of that situation too, but I really wanted something much more sane.

From there I worked for startups and other situations... I know the situation John describes very well, where sometimes you have to do what you have to do for a bunch of very good reasons, few of which are good engineering reasons/decisions. I think what R.G. mentioned about engineers knowing a lot more about the business decisions rings very true with my experience. I think I have found a good balance between innovation/freedom/process/management for me in my current job because I work with a bunch of people (from the top down) that seem to understand that everyone in the organization has to support good engineering practices at all levels to get things done.

Quote
That is a great way to work if your customer is tolerant of it. We did that with some university research people as "customers" on my skunk-works megacomputer back in the day. They liked it a lot.

Yeah, this was a skunk-works environment I used to work in. I really loved that. We did some good work.

Quote
Some customers cannot tolerate a try-and-tweak approach. In general, business oriented applications such as inventory tracking, accounting, anything where there are dollars and cents immediately in the balance are intolerant. Customers who are themselves developing applications or who are developing research or one-time results are generally more tolerant of tweaks along the way.

Yes, it all depends on the business you're in. In this case it was replacing some old 1968-vintage "apollo control room" technology. The customers/operators were all near retirement and among other things, pretty computer illiterate at the time. A few years ago I had to review the system for return to flight and in the process asked one of the "new, young" operators what they still thought of the system. He gave it a big thumbs-up- that made me feel good.

Quote
And remember, Bill Gates became the wealthiest man on the planet, worth more than the GDP of many countries, by promising us everything, then giving us Windows, a little dribble at a time, and convincing us that really, no fooling, the next release would work better and be more resistant to hacking. So dribbling can be good business, too.

I suspect people in general have a better understanding of vaporware promises these days, partially due to the popularity of personal computers that Mr. Gates had a part in.

QuoteFrom there I worked in a 'lab' job where I did rapid prototyping doing all kinds of HW and lowlevel SW work - the expectations were quite low for the engineering that got done - but everyday was something different. I got tired of that too, there was no real engineering going on with that stuff because there was really no product

I've done projects which were more R&D oriented, trying to develop or apply a new technology, etc, with a report or demo as the "product". They were fun while I was working on them but when we finished I missed that satisfaction I got from "producing"- that is, turning something over to a customer and seeing them actually use it. I get a deep satisfaction from knowing there is stuff out in the field being used today that I had a hand in- where there is documentation, source code, etc that has my name in it.

I'm mostly looking for a list that are 10 or 20 most common designer issues and designer PCB or layouts problems

the biggest is: TIME

(or rather: the lack of...)

QuoteI'm mostly looking for a list that are 10 or 20 most common designer issues and designer PCB or layouts problems

What lot of the replies here have been about is, loosely stated, the fact that it is impossible to give you that. There are ten to twenty THOUSAND most common problems. This is not like finding the ten most important things about baking bread, or sailing a schooner, or things to take on vacation with you. In any given design problem you will have to use a different set of most important things. You can only list meta-issues as the most important design issues or problems.

I'll do a representative list of those for you, though.

Top Ten electronic design meta-issues:
1. Knowing when to stop
2. Knowing who to call.
3. Knowing who's paying the bills
4. Knowing what minimum features must be met and what features are negotiable.
5. Knowing what the maximum allowable cost is.
6. Knowing what the maximum allowable completion time is.
7. Stopping feature creep.
8. Recognizing all of the stakeholders
9. Recognizing the political realities of the project
10. Knowing technologies which can be used.

Notice that the least important of the top ten is anything to do with the actual technologies.

Of course, that's not what you wanted to know. What you wanted to know is that equations to solve, what procedures to do, what tricks to do in design. That stuff is a set of minimum requirements. It's on the bottom of things you need.

It is not most important to know Ohm's law, or to be able to say why dual opamps are better than singles or quads, or to know what PCB trace thickness is needed. But it is mandatory. If you know all of this lowest level stuff but not any of the top ten meta-issues, you will fail. If you know all of the top ten, and expecially 1, 2, and 3, you will probably be successful in spite of not knowing the minimum requirements. I've seen people who don't have a clue about how to design a memory chip, lay out a board, do a thermal analysis, compute an error budget on an A-D converter and a million other things be successful because they knew the first three.

There is another way for you to answer your own question. This forum is a treasure trove of things that can and have gone wrong in making effects. If you find and list the most common things that have gone wrong with an effects design, those will be the most important things to get right, and you have your list. Just do a search in the archives.

why dual opamps are better than singles or quads?

This seems like more the R&D Buyer/sales persons job they handle all of this:
Top Ten electronic design meta-issues:
1. Knowing when to stop
2. Knowing who to call.
3. Knowing who's paying the bills
4. Knowing what minimum features must be met and what features are negotiable.
5. Knowing what the maximum allowable cost is.
6. Knowing what the maximum allowable completion time is.
7. Stopping feature creep.
8. Recognizing all of the stakeholders
9. Recognizing the political realities of the project
10. Knowing technologies which can be used.

a good designer is the best R&D buyer...



a dual got least pins for most function without routing probs...

MP,

If you, as the designer, do not know these things, no matter what you design you will be late with completion, not have a suitable price/performance, be over budget, have the wrong features (as seen by the people who pay your salary) not have enough features, have "defects" as seen by the customers, and your bosses will be furious.

Believe me, if you are a designer and the buyer does all this for you, you'll get fired; it's certain that you *should* be fired.

Please understand; I'm telling you the straight facts. I wish I had learned these in college instead of painfully over three decades of engineering practice. Let me repeat:

QuoteAnd markphaser, I was not being snide or snotty to you. I was telling you the literal truth. These days, an EE who has no concept of project management is going to have a very difficult time holding on to a good job, and will certainly not get ahead in the organization. It's not enough to know the equations and real world practice of electronics. You have to learn the economics of engineering design, the management and scheduling of projects, and the politics of  your organization.

I have a good book for you to find and read. Go look up and read the PMBOK, the Project Management Body of Knowledge. It'll be very enlightening.

Not at the most jobs i worked at the R&D buyer did all that hard work i done intern at many jobs i never seen the electronic EE designer worry about how much the parts were going to cost thats not his jobs and doing the accounting also please R.G u must have worked at really really small companies

So tell us MP, at what companies did you intern, what kinds of things did you do?

Dang it. R.G. beat me to it.

Andrew

Sorry - I would have waited had I known.  :)

i intern doing testing,checking,troubleshooting from technical write ups from the R&D department of various stuff different products the technical write up tell u what to do and how and where to measure plus with the new digital oscilloscope its even easier. I then intern for school at various jobs in the R&D departments and watched engineer asst. which they prototyped the new product mostly like 10 or more people in the R&D department doing different tasks like buyers,schematic software drawing,software simulations,C++ programmers,a couple of EE math guys to do the analysis of the circuit beyond ohms law, PCB simulation program, trace,routing software programs,i just mostly watched and asked questions and helped out it was internships for school

Your saying its one guy doing all this and i have to disagree with u again there is no way one guy can do all this. If my questions were saying what is a R&D department thats another story but i asked only about PCB design issues and PCB problems

 

Quotei intern doing testing,checking,troubleshooting ... it was internships for school

Cool!

What school and what company was this?

What is "intern"? Please forgive my simple English brain, but I thought doctors were interns before they qualified.

Ah, it's an unpaid slave!! :icon_lol: :icon_lol: :icon_lol: :icon_lol: :icon_lol:

Stephen, aren't we all 'interns' at the end of the day??

You could be right there!! I remember when I first heard the word "intern" - it was on Dr Kildare in the 60s.

Quote from: R.G. on November 24, 2006, 12:20:25 AM

Quotei intern doing testing,checking,troubleshooting ... it was internships for school

Cool!

What school and what company was this?

I bet $100 we won't get any traceable answer from this guy.

The pattern is to always ask questions and rephrase new questions when answers and/or advice are provided.  The new questions inexorably show no attempt to comprehend the previous answers and no effort in reading or checking any external link or reference provided.  And crowning the aforementioned, no concrete answers are provided back to direct and simple questions.

In summary, a waste of time and an unpleasant disruption to the otherwise friendly community in this forum.

Sorry - I would have waited had I known.
   You got'ta know when to hold 'em...

  Oh you want SB EE info...
  We all do our best.
  I can only figure out part of it...
  I can say to figure out what the parts do is a great place to start. Get some parts and try to figure out what they're actually doing for you. Data sheets and seek out component explanation pages...there are some really good ones with pic's 'n texts.
  Not that I don't bend it to find targets, because I'm not an EE and don't do exact maths, but ohms law explains alot of it.

Quote from: StephenGiles on November 24, 2006, 02:54:52 AM
Ah, it's an unpaid slave!! :icon_lol: :icon_lol: :icon_lol: :icon_lol: :icon_lol:

We prefer the term "Gimp" (from Pulp Fiction, you must see to really get it).

Works as a verb "I am gimping him to do my busy work"

Noun

"He is a gimp on the project"

Quote from: markphaser on November 23, 2006, 10:17:22 PM
i intern doing testing,checking,troubleshooting from technical write ups from the R&D department of various stuff different products the technical write up tell u what to do and how and where to measure plus with the new digital oscilloscope its even easier. I then intern for school at various jobs in the R&D departments and watched engineer asst. which they prototyped the new product mostly like 10 or more people in the R&D department doing different tasks like buyers,schematic software drawing,software simulations,C++ programmers,a couple of EE math guys to do the analysis of the circuit beyond ohms law, PCB simulation program, trace,routing software programs,i just mostly watched and asked questions and helped out it was internships for school

Your saying its one guy doing all this and i have to disagree with u again there is no way one guy can do all this. If my questions were saying what is a R&D department thats another story but i asked only about PCB design issues and PCB problems

 

WTF?  I am a designer.  I have done projects where I have done everything but the IC layout (and some where I did parts of that).  PC board?  Me.  Test plan?  Me.  Design?  Me.  R&D department?  WHo are they?

I realize I'm getting in rather late in the game on this one but possibly I can offer a fresh perspective. 

It seems you're original intent on this post was to find out a few basic things you need to learn in order to design electronics projects better.  It also seems that most of the responses have been along the lines of how to get ahead in your career as an EE. 

I don't work in hardware currently (I do software R&D) but I do have a degree in in Computer Engineering and our courses were mostly the same as the EE's at my school plus some CS stuff.  For me, the keys were always to first understand the parameters of the project.  What does the circuit need to do?  How much room, parts, money, etc. can you use?  Being as specific as possible here is important so you can make a good design the  first time around. 

Next, do a general design.  Break the thing into sections and draw up a nice signal flow block diagram.

Now you can design each piece of the puzzle to do it's job and test them out.  This may be simulations or breadboards or whatever.  The project and the available resources will dictate how you test.

Next, look at the design as a whole.  Are 2 pieces that you designed seperately really going to interact and screw things up?  Once the big picture looks good, mock that sucker up and see if it does it's thing.  Usually, something will not work quite as planned so now you debug (as it was stated earlier, a good design and good testing of parts of the project will minimize headaches here).  When you're done debugging, project complete (or on to version 2.0).

Hopefully that helps a bit.  The key I think is being able to break a circuit into functional parts and to see how those parts interact.  You need to be able to see what the whole circuit does, what each part is doing, and also how individual parts make up filters and gain stages and bias voltage supplies etc.  It's seeing those filters and gain stages and whatnot, that was always the hardest part for me in school.  I could understand the big picture, and I knew what each component would do, but how will a coupling capcitor affect a nearby RC filter? That sort of thing seems to just take time and experience. 

Interesting phrase - "get ahead". Perhaps someone would like to elaborate.

 :icon_question:

Look @ this: http://www.diystompboxes.com/smfforum/index.php?topic=51789 !!!
(this is a clickable link to another thread,
with a link to an interesting video)

watchit!



(tnx, gez)

QuoteI realize I'm getting in rather late in the game on this one but possibly I can offer a fresh perspective. 

You may not want to.

markphaser is a longtime participant in the forum. The problem is that we just can't tell if he's human or not.

Literally. He fails the Turing test as we would apply it through forum messaging. No one is quite sure that he's not some grad student's AI program gone amok. If he's a person, he's either cleverly malicious or sadly disadvantaged.

Do some searching on "walters", "walters9515", "brent" , "brentwalters", "markphaser", and "surfman" in this and other audio, dsp, and microcontroller forums. The prose style is unmistakable.

No amount of explanation ever results in any understanding happening on the other side. No verifiable information about the person on the other side ever gets displayed.

I think that the term "walters" may be destined to become an internet term descriptive of the style, much like "hack" and "troll" have entered the lexicon.

_  ?:icon_question:? _ (http://en.wikipedia.org/wiki/Loebner_prize#2007_Loebner_Prize)

Walters' "Resume":

http://www.diystompboxes.com/smfforum/index.php?topic=32043.0

Ah memories.

Andrew

Ye ole sentimentalist...   :icon_biggrin:

Sir HC

What IC layout issues/flaws/problems have u learn or is common?

What PC board issues/flaws/problems have u learn or is common?

What Test plans do u do please??

What jobs has R.G and others work doing R&D or in a R&D department?

 What the hell? This looks an awful lot like an insane thread about Leslies over at HC... Bizarre...

(http://swg.stratics.com/content/lore/personas/images/yoda.gif)

Perhaps Putin has a solution here!!!

If you're usin' Putin's solution, you'll be needing absolution.

:icon_wink:

off to the sushi bar!

R.G  whats the answers

The answer is that you are currently failing the Turing Test. Please try again.

U failed to u haven't listed anything maybe u don't know as much as u front on people

 Do you even know what a Turing test is? I'll give ya a hint- getting all petty and bitter is coming pretty close to passing... if ya handle it the right way.

If you want to know R.G.'s credentials, go look him up. Try google for instance. You can do that, you know, if you're not a bot. After you do, maybe you'll understand why he feels no need to prove himself to you. I challenge you to prove he's not who and what he "front on people"!

And, for that matter, you were addressing H.C. and suddenly act as if the latest barrage of questions was directed at R.G. The least you could do is remember who you're attacking.

I never knew Yoda was a troll...

why he feels no need to prove himself to you

Its a two way street not a one way street i don't have to prove myself to him either he acts like everyone rolls out the red carpet for him
which is not someone i want to look up too really

Allow me to invite both of You, R.G., and mp, for a cup of tea,
a glass of wine,
a (bottle of) beer,
or (any) other drink you prefer
towards the end of next month.

There will not be a red carpet;
There will be a great firework, however!
dress as you like.

The road from me to You
is as long and winding
as the road from You to me...

QuoteIts a two way street

And here we get right down to the meat and potatoes... the two way street.

What has R.G. contributed to the diy stompbox community? Would we even exist without him? The reason people roll out the red carpet for him is because he has very much EARNED that kind of respect.

In exchange for what must be the single most overwhelming contribution of information, experience, and solid advice in the entire DIY stompbox world someone comes along and demands proof of credentials... Someone who as far as I can tell has not offered one single bit of advice or help to anyone round here at all, yet claims some sort of "electroic" engineering experience. Are you just data mining here? Will you ever contribute anything at all beyond endless questions?

If you don't choose to look up R.G., that's your perogative, but be aware that you certainly cannot know what you're talking about, since you won't even look into WHO you're talking about. But, you've been here before, as has been pointed out,  so you KNOW who he is, don't you?

Extraordinary claims require extraordinary evidence to back them to reach the threshold of believability. R.G.'s years and years of work in this field speak for him. For many many reasons already stated, your claims of an engineering background are quite extraordinary. The burden of proof is on YOU.

So, it's a two way street. He's certainly done his part. Where's yours?

You walk into a room containing a few engineers and claim to be a peer, it won't take long to figure out if that's true or not...

The thing that puzzles me here is the motivation... What exactly are you getting out of this? This is just about the strangest approach to trolling I've ever seen... Fascinating, in a train wreck kinda way...

Prior to my first post, I thought the references to MarkPhase as non-human were just jabs at what I took to be poor grammer due to english being not his first language.  Since then, I've realized that he really may be AI (well the "I" part may be an overstatement).  How freakin' weird.  Now I feel a little dumb for trying to help the guy.

Meanderthal why don't u start your own thread and i'll go into it and drill u,spam it,call u names see how u like that.
Really i don't care what R.G does for anyone else none of my business and i stay away from what he trys to say to others
threads becaues really R.G owns this board like u said this board wouldn't exist without R.G he has earn the red carpet for people
that need to know how to solder a jack to a footpedal or a DC plug/jack and lets just start about 1000 threads covers a fuzzface
and a wah pedal but anything outside of the box is clearly wrong,weird,trolling because its not really Aron's forum its R.G's forum
and i didn't know i have to go get a EE degree like R.G to have a chip on my shoulder looking down at others and having a red carpet
rolled out in front of me becaues i know how to measure a battery or solder a jack to a stereo plug to a foot pedal or measure DC voltages for baising a fuzz face get real Meanderthal i am a tech if u like it or not i worked at many many companys with 1000 and more people so i have good people skills or i would have been fired the seperations between me and others is i have some electronic background that makes R.G's stomach just sick for some reason maybe he thinks his EE degree means "Ego Extreme"

 

 LOL! How can you have people skills if you can't convince people that you're even human? Personally, I'm leaning towards human after your last couple posts(that makes you much less fascinating), but there's still the possibility that you're the most advanced AI I've ever seen. After all, it IS possible to simulate an emotional response...

Feel free to dig up any of the threads I've started and call me names, expose my ignorance, and humiliate me by pointing out my every mistake. That would be... contributing, however indirectly. You see, it dosen't really matter if I'm wrong, progress is still achieved.

You STILL haven't quite passed the Turing test... but you're getting closer...

Quote from: markphaser on November 24, 2006, 07:17:36 PM
Sir HC

What IC layout issues/flaws/problems have u learn or is common?

What PC board issues/flaws/problems have u learn or is common?

What Test plans do u do please??

What jobs has R.G and others work doing R&D or in a R&D department?

Dude, answering #1 for you would be like teaching a parrot how to operate a nuclear submarine.  Very far out of league.

But to have fun:

Signals, what, where.
Substrate currents.
SCRs, oh the SCRs.
Vias and current density.
Rmetal.
Matching.

The other questions?  Dude, I don't have to time to write essays here.

I don't do R&D, I design for production.

Considering

Quote from: markphaser on November 26, 2006, 11:20:56 PM
Meanderthal why don't u start your own thread and i'll go into it and drill u,spam it,call u names see how u like that. Really i don't care what R.G does for anyone else none of my business and i stay away from what he trys to say to others threads becaues really R.G owns this board like u said this board wouldn't exist without R.G he has earn the red carpet for people that need to know how to solder a jack to a footpedal or a DC plug/jack and lets just start about 1000 threads covers a fuzzface and a wah pedal but anything outside of the box is clearly wrong, weird, trolling because its not really Aron's forum its R.G's forum and i didn't know i have to go get a EE degree like R.G to have a chip on my shoulder looking down at others and having a red carpet rolled out in front of me becaues i know how to measure a battery or solder a jack to a stereo plug to a foot pedal or measure DC voltages for baising a fuzz face get real Meanderthal i am a tech if u like it or not i worked at many many companys with 1000 and more people so i have good people skills or i would have been fired the seperations between me and others is i have some electronic background that makes R.G's stomach just sick for some reason maybe he thinks his EE degree means "Ego Extreme"

and the "Anyone found attacking others will face losing posting privileges." post by Aron on October 11th 2006 at the "READ THIS BEFORE YOU POST" thread,

and the knowledge of the "walters", "walters9515", "brent" , "brentwalters", "markphaser", and "surfman" posts in this and other audio, dsp, and microcontroller forums,

and the "About registration. Every registration is moderated. Please do not waste my time and try to register with a name like "wewillspamU" or bother to try and register from a known spamming address. I will delete your request immediately." post by Aron on November 25th 2006, at the "READ THIS BEFORE YOU POST" thread,

I wonder: What the heck are the moderators waiting to remove the posting privileges of this troll?

Quote from: markphaser on November 26, 2006, 11:20:56 PM
maybe he thinks his EE degree means "Ego Extreme"  

No,  remember, you can't have a beer without a EE.

Someone here has either a very limited knowledge of English or an EXTREMELY good knowledge of perl (or perhaps python).

For a variety of reasons, this thread should be locked.  It is becoming exclusionary and unpleasant.  Let's start over.

Totally agree Mark (reported).

So do I.

(http://www.diystompboxes.com/smfforum/Themes/safbluerc1/images/english/admin_lock.gif) :icon_question:

Andrew