Running the simulation above put out some wrong values, it seems like the post processing of the numbers happens in a random order. (if param n is stepped from 1 to 4)
but when running only one itteration yields the correct answer, could something be wrong in the ordering of calculations?
Br. Marc
I see you results are correct, when I do the calculations myself I just get different results.
regarding the missing resistor, it is a parasitic component of the inductor.
I’ll dig deeper into my simulation to find the issue 
//Marc
Q4 sim = 24.833
Q4 calc = 32.866
And just looking at the bandwith outputs the Q output does not make sense, it should be small bandwith high Q and visaversa but this does not seem to be the case.
//Marc
@MarcMunkstrup OK, I identify the cause, it is related to the sequence of .meas. From your display, the actual sequence in your netlist should be .meas Vmax > Q > BW > fh > fl > fo. With this sequence, possibly, in .step simulation, may previous step calculated result confused current step, and therefore, mismatch in solution.
In your schematic, it looks like they are in order Vmax > fo > fl > fh > BW > Q, but actually, that is only how you organize your text sequence, it is nothing to do with netlist sequence. Netlist sequence is based on which text is first enter and which text follow. If you cut and paste a text box, it sequence can change. You can View > Netlist to check if your sequence followed my guess.
The solution is that, when you write multiple .meas, you use one text (box) instead of multiple text.
After text is place, you can edit by double clicking on it. Now, you are able to create new line within this text by Ctrl+<Enter>. The text within this text (box) is ordered in your desired sequence.
Normally, I use this method to create .plot and .meas command, to restrict their sequence when netlist is generated. Please review if this help to resolve your problem.
The problem is solved, than so much for the help
Actually, this all was a bug in QSPICE. The .meas statements are supposed to comprise a declarative language.
A declarative language differs from a procedural language. In a procedural language, you can write x = x + 1. It simply gives a procedure to increment x. But in a declarative language, it makes no sense since x cannot equal x plus one.
In a declarative language, the order of the lines makes no difference on the results – though run times can be impacted since it can take longer to solve everything in reverse order.
Anyway, as of this morning, this problem should be fixed.
–Mike
