开云体育

I say 'fictitious', because no such signal with that waveform was the input for the simulation.? I agree that the result of the inverse FFT is the impulse response (within limitations). There is

I presume you meant "It's unlikely that a model "will* produce curves that closely match those in the data sheet"? Of course that's not true. In many cases, you can tweak a model to almost overlay

John wrote, "... an inverse FFT will produce a (fictitious) waveform whose spectrum is the frequency response. I can't see much use for that. "? It might be useful to see the impulse response of your

The output from an .AC simulation is a high-resolution spectrum, so indeed an inverse FFT will produce a (fictitious) waveform whose spectrum is the frequency response. I can't see much use for that.

That's not a huge undershoot, not compared to the pulse itself.? The undershoot is -125 mV and it lasts for less than 10 ns.? If you made the I1 pulsewidth wide enough so that the op-amp's output

Hi Andy. Thank you for your feedback. When I mentioned that I was not seeing what I expected at the output of the TIA, I should have been more precise. I am not sure I understand why there is so much

Going back to this discussion adding another tidbit: If you run an .AC analysis, and then do a View > FFT, LTspice will gladly perform an (inverse) FFT on the frequency-domain output from the .AC

No doubt you can carry out an optimization, but it requires a deep knowledge of what each of the model's parameters determines, which is far from straightforward. It's unlikely that a model with

Good stuff. For accurate model assessment and optimisation, I also have a method of importing the datasheet data into LTspice for direct comparison. It's this latter bit that's onerous, because it

Fabulous guys. I had thought it might require me to write my own test setup but it's good to hear that these have been made available. I'm not talking about anything exotic here. I only mean BJTs,

What you say about this is true, hFE does have significant statistical spreads, but the datasheet limits are probably set at 3 sigma (any outside this being rejected, being only a 0.3% loss). 3 sigma

You put your device and its model into a curve-tracer .ASC and set it up to produce (if it will) the same curves as in the data sheet. Compare the results. You can find curve-tracer .ASCs by going to

I have searched for this and can't find anything that is generic and at my level but, is there somewhere information on a sensible validation procedure for the simple classes of model?? I mean

Christoph wrote, "Maybe there were meant to be time/value tuples in angle brackets and they were fallen victim to the HTML conversion?" I think they just got edited out or omitted by accident. Andy

That’s what I was initially thinking of (and also posted it). What you are mentioning is BNF (Backus-Naur form of descripion of higler level programming language syntax). Only I was missing the left

Alexander Bordodynov's greatly expanded standard.xxx libraries have been available for years. Alex is a highly valued member of the group. I don't know the provenance of the models in his collection,

Some valid points, but I think the proposal is not 'either/or'. I see no objection to putting the expanded files in a new subfolder of Files, as long as it has a warning about how to use it and not

I'm not against a repository of models - we already have one in the group 's Files section. But I am against trying usurp the standard libraries. Most people coming to this group, at least initially,

It sounds a very good idea, but keeping the same filenames could cause untold confusion. Is there any way of making the names different?? The only thing I can think of is making them all upper-case,

Hello All, Members could maintain a set of the standard.xxx files for use by the group. I've been doing that for many years now. If the group retained a set of maintained files in an easy to reach