advertisement


LTSpice sim of Naim/Avondale amplifier circuit?

bugbear

pfm Member
Has anyone done one of these? If so could I have a copy?

(I could do it myself, but I'm lazy!)

BugBear
 
I did the Nait2 for giggles while helping @hifiaf with a recap, really I just did the schematic in LTSpice and rummaged about for models of most components that are raguely correct. There is work to do to make this a good simulation depending on what you are trying to simulate. You have to ask yourself how accurate and which parameters are modelled for every device. I didn't dissappear down thar particular rabbit hole but you may wish to. Let me know if you would like a copy of what I have with no guarantees of completeness or correctness :)
 
I have some sim files which I cribbed from DIYA. PM me your email address if you want them.

I didn't do much with them, so don't know how accurate they are.
I prefer to build things and fiddle/scope them.
 
I'm using "proper" models for all the actives, now I need to seek out better models for the passives. They're all LTSpice "perfect" at the moment.

EDIT; can anyone point me at parasitic figures for caps?

LTSpice wants them in these terms:

https://ltwiki.org/files/LTspiceHelp.chm/html/C-device.htm

The only datasheets I can find that give anything at all are big (PSU type) Electrolytics, which often list ESR.
 
Last edited:
I'm out for a few days, but I would love to play with this next week. I'm an LTSpice n00b, but I love to learn. ;)
 
Smaller capacitors are almost ideal. The only parasitic important to simulation is the lead inductance (self resonance), which is rarely an audio circuit issue except for output device RF oscillation
 
"darn"

Somewhere in my work to make things more realistic, I stopped it functioning at all.

And (despite being a life-long computer guy) I didn't have back ups.
 
Source control, it is the only way, then back up the source control, at least twice, at least once off site, but then you already know this.

Once upon a time, a friend (a friend you understand, couldn't possibly be me) accidentally hit a known bug in a device driver and when formatting a drive trashed their work on another drive, losing 6 months of work. It didn't take that long to redo, perhaps a month or two second time round, but still, once is enough ... for this friend of mine ...
 
Found it!

When changing TR10 from NPN+Diode (NCC200) to PNP (NCC220) I'd buggered up the connections of the emitter degeneration resistor.

I also learnt quite a lot about 3 stage audio amplifier designs during the debug process, so it's all good, in the end.
 
For audio amps, the main limitation on simulation accuracy is the active device models, especially for the power transistors. The standard models don't describe saturation very well, which can vary a lot with different device types. So don't expect detailed agreement with behaviour near clipping.
 
Since there seems to be some interest in this simulation, I'll make it available.

It's as close a transcription as I can manage of the schematic in this post by RichardH

QUDOS - the brilliant new amplifier boards from Avondale

I have tuned output bias current and DC offset (with input signal set to 0) by using LTSpices .step features on R1 and P1. Just to make life fun, they interract somewhat. My DC offset was initially a somewhat high 90 mV, now tuned down to 0, with R1 at 1.4K.

But playing around with stuff is the whole point of simulation, so if you don't like my changes, it costs nothing but time to change them to your liking.

Logistics; I'm using a large file of MODELS first shown to me over on DIYaudio by Mooly in this post;

https://www.diyaudio.com/community/threads/simulating-rotel-rb850-in-ltspice.328790/post-5575447

Such actives as are not present in that, I gathered by find original PSpice models on manufacturers websites, and adding to a MODEL library of my own (bugbear.lib).

The schematic file itself is called ncc220.real.asc (the "real" is as opposed to another copy I have called ncc220.ideal.asc, which uses LTSpice built in "ideal" components). Due to time
spent tracing my mistake, I have not yet made the passive components "real".

I have placed my two files on dropbox:

https://www.dropbox.com/s/k4dhsfwwsl6k3co/bugbear.lib?dl=0
https://www.dropbox.com/s/dgdu4ryixgxbtz7/ncc220.real.asc?dl=0

Enjoy!

BugBear
 
Last edited:
Question for the tidy minded. In a component like the bc546, is it conventional to use block caps (BC546) or lower case (bc546).

LTSpice appears to be case insensitive. Manufacturers' data sheets seem to always use block caps. General usage on forums is "all over the place".

BugBear
 
LTSpice uses capitals as well.
The original usage of the letters was meant to be upper case
LTSpice uses whatever you type. No matter what the case usage in the MODEL statement, any combination of upper/lower case letter can be used in the schematic, and the model will be picked up from the file perfectly well.

But it appears that upper case is "correct", or at least intended by the manufacturers.

BugBear
 
The list to choose from when you change part is upper case.
Ah, got you. Since I'm using external libraries I have to key in the name, not use the drop down.
I get careful of case here as Unix origin software like NGspice tend to be case sensitive
I'm using LTSpice on Linux, but under Wine. I know Windows apps have a bias towards case-insensitivity. As a Unix guy since '86, this drives me crazy.

But my question was not just "how do I make LTSpice work" but what is correct in the context of electronic design in the abstract.

All ways up, "block caps" seems to be the answer.

BugBear
 
Question for the tidy minded. In a component like the bc546, is it conventional to use block caps (BC546) or lower case (bc546).
Originally transistor naming followed the Mullard valve convention: 0C81= zero volt heater single 'triode'. Later the redundant '0' was dropped and A or B added where A = germanium B = silicon so BCxxx = silicon 'triode'. Much more info here, but always upper case: https://www.electronics-notes.com/a...nts/transistor/transistor-codes-numbering.php
 
Originally transistor naming followed the Mullard valve convention: 0C81= zero volt heater single 'triode'. Later the redundant '0' was dropped and A or B added where A = germanium B = silicon so BCxxx = silicon 'triode'. Much more info here, but always upper case: https://www.electronics-notes.com/a...nts/transistor/transistor-codes-numbering.php
That's a VERY helpful link/response. It answers my question about caps, and tells me so much more besides. Joy to my slightly completist side!

BugBear
 


advertisement


Back
Top