designs right off the data sheets

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

pucho812

Well-known member
Joined
Oct 4, 2004
Messages
14,948
Location
third stone from the sun
what is acceptable in terms of gear manufacturing when the design or part of the design is pulled right from the data sheet?

I'm talking what is cool to do, not cool to do, etc, etc, etc

 
The designs on the datasheets are great jumping off points, and as far as I can tell it's pretty common place to use them in conjunction with the layouts found on the coresponding demo/eval boards when designing a new prototype. 

The real design work is in the details anyway, and that's usually not found on any datasheets or eval boards.
 
true but what if the data sheet has all you need, you have mocked up one on protoboard it and it works as you want it to.  then what? Would it still be lacceptable to manufacture?  especially if there is no way around it with out that one part. GS aside who would rip it apart is it o.k.?
 
Who would know if they were ever told ?
I suppose if the design sounded too good to ignore or the price was unresistable
people would put their bias aside ,
Would the manufacturer care if 3 companies used the same design and companies
may not care that it is un-patentable
Weren't the pico's based off of app notes ?

one would have to be careful with the marketing as the big thing
 
Compare the Reamp (now ProRMP) to the Jensen line to guitar amp app note.

Compare any number of THAT1512/1646 pres to the datasheets.

Component values 'n stuff may be different, but they're basically the same.
 
It's fine. Back in the 80s I designed the Dragon 32 Home Computer. The basic circuit came straight from the Motorola data sheet. Of course Motorola got lot's of business from it. About 200,000 were sold in the first year.

Cheers

Ian
 
the writers of the app notes want to sell parts... even a direct lift of their art accomplishes that end.  if they wanted to branch out into consumer products then they might have a problem with copy/paste, but they stick to the building blocks as it's their expertise.  it's like a programmer's SDK- sure you could write the whole thing in assembly language, but it'll save you a whole hell of a lot of time using higher-level functions.  adapt where you should, but obviously not where it's already optimized.
 
pucho812 said:
what is acceptable in terms of gear manufacturing when the design or part of the design is pulled right from the data sheet?

I'm talking what is cool to do, not cool to do, etc, etc, etc

It depends. At one point in my career I managed an engineering group, and the objective manager says don't re-invent any wheels that already roll (and rock). If the app note design is practical and cost effective, don't mess with changing it. The subjective "engineering" manager in me, always thinks any design worth doing is worth improving, while this doesn't mean just adding more expensive parts (I worked at Peavey and that was a sharp pencil crowd).

In some cases it depends on the app note. I seem to recall many app notes from larger manufacturers that had a tendency to load them up with glue parts made by them also, even if they weren't cost effective for the application, so be alert for that.

At a minimum manufacturers will often adapt a app note to use parts already in the manufacturers system to reduce the cost and overhead of bringing in otherwise similar new parts.

I have (almost) never used a design app without changing something (perhaps a personal affectation) but it is foolish to not dig deep enough to understand the design choices. Some things you just don't mess with. If the manufacturer says a so and so needs this much PS decoupling to be stable, you use that or more.

I recall one example where a well know kit designer (who shall remain nameless since he is still alive and well respected) just about copied a design application note verbatim for a kit he did way back when, but he did make one change substituting an opamp for a comparator to simplify his parts list. I can only speculate that he didn't fully appreciate the difference or reason a comparator was used in the original app note (to prevent input bias current from causing a DC error after a blocking capacitor). I guess he could have gotten away with the opamp swap if he used a bifet or JFET input opamp, but this was back in the old days when those were premium parts, so his design did not work as well as the app note.

For lots of simple stuff there just isn't much external glue to change ... For example I am using a slick class D  driver chip in one new designs that just has a couple input resistors, and simple output filter (ferrite beads and caps). Not much for even me to mess with. 

When in doubt use the app note as written. It should always be a good starting point. Some products like switching power supply controllers can include a preferred PCB layout. Deviate from that at your own risk. OTOH sometimes the app note is cheapened down for mass appeal. One example of that was one or more THAT corp VCA app notes. I recall reading the AES paper the VCA designer wrote with a detailed inspection of all the improvements in the latest generation of VCAs. If you paid attention to the journal paper you would notice that the circuits shown for the performance graphs used higher performance opamps than their application notes. So the app notes may not always be best but should at least deliver the promised performance level.

One last anecdote about using app notes verbatim, and I've told this story before so bear with me, when I did a kit CX record NR decoder, I not only changed CBS's app note to use a quieter gain element, but I discovered a mistake in their side chain time constant, so I made mine agree with the formal CX system specification, and the standard record encoder.  After I advised CBS of the error in their application note circuit, I heard nothing back from them, but later learned from an engineer at the company who made the encoder that CBS changed the encoder and CX standard to agree with the mistake since there were already tens of thousands of decoders built by two different consumer product manufacturers who copied the app note without bothering to understand what the circuit was actually doing.

So there is your smoking gun that some manufacturers do indeed copy app notes literally... and some don't.

JR
 
ruffrecords said:
Back in the 80s I designed the Dragon 32 Home Computer.

Did you, Ian? I remember those! Pretty cool at the time.

http://www.kropotkin.co.uk/images/cgeuk05/dragon32.jpg

(I was a young whippersnapper at the time - my brother was in a computer club, but I just wanted to play my guitar :D)
 
zebra50 said:
ruffrecords said:
Back in the 80s I designed the Dragon 32 Home Computer.

Did you, Ian? I remember those! Pretty cool at the time.

http://www.kropotkin.co.uk/images/cgeuk05/dragon32.jpg

(I was a young whippersnapper at the time - my brother was in a computer club, but I just wanted to play my guitar :D)

Yes, it was my first high volume product design (before that I had worked at Neve and British Aerospace). The Motorola sales manager at the time was none other than Robin Saxby (now of ARM fame) and we are still occasionally in touch. I was a senior engineer at the consultants PA Technology and had recently finished a product development using the Motorola 6809, so when Mettoy approached us saying they wanted to make a home computer similar to the Tandy CoCo (which uses a 6809) I suddenly found myself to be the resident expert.

Cheers

Ian
 
pucho812 said:
what is acceptable in terms of gear manufacturing when the design or part of the design is pulled right from the data sheet?

I'll speak from the digital-design point of view. Most eval kits for processors and FPGAs and other things take a kitchen-sink approach, so there could be options and jumpers and things you won't need on your product.

For example, if your Xilinx FPGA is configured only from the standard config EEPROM, you don't need to support changing the M[2:0] pins. Just tie them low (master serial mode).

Some of these kits include the bogus sort of RC reset. You want a proper reset supervisor in a real design.

These kits usually have hooks in to monitor power-supply consumption and other things that you likely don't want in your hardware.

-a
 
JohnRoberts said:
pucho812 said:
what is acceptable in terms of gear manufacturing when the design or part of the design is pulled right from the data sheet?

I'm talking what is cool to do, not cool to do, etc, etc, etc

It depends. At one point in my career I managed an engineering group, and the objective manager says don't re-invent any wheels that already roll (and rock). If the app note design is practical and cost effective, don't mess with changing it. The subjective "engineering" manager in me, always thinks any design worth doing is worth improving, while this doesn't mean just adding more expensive parts (I worked at Peavey and that was a sharp pencil crowd).

In some cases it depends on the app note. I seem to recall many app notes from larger manufacturers that had a tendency to load them up with glue parts made by them also, even if they weren't cost effective for the application, so be alert for that.

At a minimum manufacturers will often adapt a app note to use parts already in the manufacturers system to reduce the cost and overhead of bringing in otherwise similar new parts.

I have (almost) never used a design app without changing something (perhaps a personal affectation) but it is foolish to not dig deep enough to understand the design choices. Some things you just don't mess with. If the manufacturer says a so and so needs this much PS decoupling to be stable, you use that or more.

I recall one example where a well know kit designer (who shall remain nameless since he is still alive and well respected) just about copied a design application note verbatim for a kit he did way back when, but he did make one change substituting an opamp for a comparator to simplify his parts list. I can only speculate that he didn't fully appreciate the difference or reason a comparator was used in the original app note (to prevent input bias current from causing a DC error after a blocking capacitor). I guess he could have gotten away with the opamp swap if he used a bifet or JFET input opamp, but this was back in the old days when those were premium parts, so his design did not work as well as the app note.

For lots of simple stuff there just isn't much external glue to change ... For example I am using a slick class D  driver chip in one new designs that just has a couple input resistors, and simple output filter (ferrite beads and caps). Not much for even me to mess with. 

When in doubt use the app note as written. It should always be a good starting point. Some products like switching power supply controllers can include a preferred PCB layout. Deviate from that at your own risk. OTOH sometimes the app note is cheapened down for mass appeal. One example of that was one or more THAT corp VCA app notes. I recall reading the AES paper the VCA designer wrote with a detailed inspection of all the improvements in the latest generation of VCAs. If you paid attention to the journal paper you would notice that the circuits shown for the performance graphs used higher performance opamps than their application notes. So the app notes may not always be best but should at least deliver the promised performance level.

One last anecdote about using app notes verbatim, and I've told this story before so bear with me, when I did a kit CX record NR decoder, I not only changed CBS's app note to use a quieter gain element, but I discovered a mistake in their side chain time constant, so I made mine agree with the formal CX system specification, and the standard record encoder.  After I advised CBS of the error in their application note circuit, I heard nothing back from them, but later learned from an engineer at the company who made the encoder that CBS changed the encoder and CX standard to agree with the mistake since there were already tens of thousands of decoders built by two different consumer product manufacturers who copied the app note without bothering to understand what the circuit was actually doing.

So there is your smoking gun that some manufacturers do indeed copy app notes literally... and some don't.

JR
I've always known some have done it verbatim from the data sheet, but was more asking how if any acceptable this and  apparently it is.
 
They really do all that leg work for you to sell products. So as somebody already said, if you rip the app note verbatim, mission accomplished.
 
Ruffrecords: that is really great! I could learn so much from you.

Pucho: I heard that the NYD 1 bottle is ripped right from the RCA design handbook. I also hear ripping strait from datasheets is very common. You can tweak things from there.
 
I happen to be good friends with NYdave outside of forum and such. I seriously doubt that the one bottle came from any designers hand book.  But for someone less experienced such as myself, pulling from a design handbook and or data sheets is sometimes required.
 
pucho812 said:
I seriously doubt that the one bottle came from any designers hand book.

Somewhat fitting on the topic of the thread, it's not far. It's direct tube datasheet values interfaced with the implementers choice of I/O compromise.

But then, isn't everything?
 
Back
Top