|
I'm getting odd behaviour trying to generate an FM waveform using a Bsource. Here is the netlist:
V1 vc 0 10.7
V2 fr vc PULSE(-1 1 0 1m 1m 1u 2m)
B1 fm 0 V=sin(2*3.14159262*v(fr)*time*1000000)
.tran 0 10m 5m 1n
.backanno
.end
If I cut and paste the B source definition into a new trace I get the correct waveform but its not the same as the waveform in the sim at the 'fm' node.
I set the min time step to 1ns to ensure there was no time-step sampling issues, and this is more than aggressive enough for a 10MHz waveform..
Any ideas why I get this odd behaviour? looks like a bug to me..
version is XVII(x64) Jun 21 2018 10:02:22
Kevin.
PS, I know there is a keyword for pi, but I was stripping the problem down, and I know there is an FM source, but the B source should work OK..
|
Hello, Please upload your schematic to this folder.
> I f
I cut and paste the B source definition into a new trace I get the
correct waveform but its not the same as the waveform in the sim at the
'fm' node.
I hope the schematic(s) you will hopefully upload shows what this procedure means.
Best regards, Helmut
|
I've posted up some screen shots..
Just re-activated my Yahoo account, so not sure how it worked out.. Our internet service is hosted in the Netherlands which ties it in knots and my Dutch isnt very good :-)
Kevin.
|
What I mean is that if I copy the exact text from the B source and use this to calculate a new trace in the trace window then the results differ.
I Hope thats clear :-)
Kevin.
|
I'm getting odd behaviour trying to generate an FM waveform using a Bsource.
Here is the netlist:
V1 vc 0 10.7
V2 fr vc PULSE(-1 1 0 1m 1m 1u 2m)
B1 fm 0 V=sin(2*3.14159262*v(fr)*time*1000000)
.tran 0 10m 5m 1n
.backanno
.end
If I cut and paste the B source definition into a new trace I get the
correct waveform but its not the same as the waveform in the sim at the 'fm'
node.
I set the min time step to 1ns to ensure there was no time-step sampling
issues, and this is more than aggressive enough for a 10MHz waveform..
Any ideas why I get this odd behaviour? looks like a bug to me.. The correct formula for LTspice is sin(2*pi*idt(v(fr))), there are also examples in the Files section. That's because the quantity to pass to sin() is an integral of the time. What you provided is a strange mix of a normal, time varying voltage, multiplied by time, which is the reminisce of x**2/2 when integrating x, together with a time varying voltage. -- Vlad ______________________ ltspicegoodies.ltwiki.org -- holding, among others: a universal analog/digital filter, block-level models for power electronics (and not only), math blocks with a more stream-lined approach, some digital ADC, DAC, (synchronous-)counter, JKflop, etc.
|
I dont agree with your mathematics, but thats not the point - why is the waveform correct in the waveform viewer but not in the simulations? If I have the same expression I expect the same answer!
Kevin.
|
Hello, Thanks Vlad fo the explanations about the correct formula with teh inegration.
In this case the B-source should be
V=sin(2*3.14159262*idt(v(fr))*1000000)
You can add a 2k-1nF lowpass to check that the FM-works. Plot the voltage of the capacitor, e.g. V(c)*500. The amplitude is proportional to frequency and in phase with the modulated signal.
There is a great FM/AM modulator available from LTspice too - modulae, modulate2 from the folder [Special Functions].
There is an example in this folder below . Please try it.
Modulate2_test1.asc
Best regards, Helmut
|
I'm sorry but you miss the point - not what the best way to represent FM - that the tool has different answers in sim and from calculation.
Now the maths is a distraction, but the formula I'm using is just sin(w.f.t) and f is a slow moving (compared to cycle time) frequency value - this is identical with what you are describing and I dont care about the difference for now. Vide - constant frequency - idt(const) == time no? Can we drop the maths lecture and answer why the tool gives different answers !
Kevin.
|
Hello Kevin,
I tried your circuit with PSPICE A/D Lite 17.2 . The simulation result has been the same as with LTspiceXVII - a? strange result near 5.4m (0.4m). Now I am sure it's simply the math. it's not a problem of LTspiceXVII.
Best regards, Helmut
Netlist for PSPICE file "BsourceIssue.cir"
* D:\xyz\BsourceIssue.asc
V1 vc 0 10.7
V2 fr vc PULSE(-1 1 0 1m 1m 1u 2m)
E1 fm 0 VALUE = { sin(2*3.14159262*v(fr)*time*1000000) }
.tran 0 6m 5m 1n
.probe
.end
|
but if you copy the text from the Bsource definition exactly and paste into a new trace you will see a different answer with no abberations. This is the issue - put the same math into matlab and you get what the waveform plotting? trace says - spice is wrong even by its own admission
Kevin.
|
Kevin,
Let's face it. Your math IS wrong! LTspice calculated the math correctly in its Bsource. You didn't.
This is NOT the way to make an FM modulator. Take Helmut's advice or Vlad's advice for doing it the correct way. I recommend using the "Modulate" component in LTspice for correctly doing FM (or a VCO). The way you've done it in your simulation is NOT correct, and it will NOT give you the correct picture of an FM waveform. It gives you the mathematically correct waveform that you specified, which is NOT what an FM waveform really looks like. The formula you used is correct ONLY when the modulation voltage is absolutely pure DC. If it varies at all, it is not correct.
If you don't believe me, then pull out your calculator and prove it for yourself. It will take a lot of time, but you will get the same awful waveform that LTspice shows you in its simulation. I can guarantee that.
I can't speak directly to the "waveform viewer math" picture because I have not looked at that yet, but I'm guessing there is a reason why it deceptively shows you the incorrect FM result. It must be calculating something differently, for some reason.
Regards,
Andy
|
I now see why the "waveform math" version is different. Because you used ".tran 0 10m 5m 1n" in your simulation, the version of "time" that is in the simulation, differs from the version of "time" that is in the waveform viewer. There is a 5ms time offset. In the simulation, time goes from 0 to 10ms. But you asked LTspice to start saving data at 5ms. The way that SPICE (since the 1970s) handles this, is to start saving data at 5ms, but call that 0ms in the output data, and go up from there. Therefore, in the saved data, "time" in the saved data runs from 0 to 5ms, even though "time" within the simulation is going from 5ms to 10ms over that very same interval of time. It's confusing, if you don't remember what's happening and why. If you don't believe me, plot the full extent of the waveforms. Note that the X (time) axis goes from 0 to 5ms, even though you asked for the data from 5ms to 10ms. SPICE (and LTspice) always begins with the "time" in the output data at 0. It has a built-in time offset. Now, when the waveform viewer evaluates your formula "sin(2*3.14159262*v(fr)*time*1000000)", its version of "time" is NOT the same "time" that LTspice used within the simulation itself, because it has been offset by 5ms. Hence the difference between the simulated waveform and your formula. Regards, Andy ---In LTspice@..., <ai.egrps@...> wrote : Kevin, Let's face it. Your math IS wrong! LTspice calculated the math correctly in its Bsource. You didn't. This is NOT the way to make an FM modulator. Take Helmut's advice or Vlad's advice for doing it the correct way. I recommend using the "Modulate" component in LTspice for correctly doing FM (or a VCO). The way you've done it in your simulation is NOT correct, and it will NOT give you the correct picture of an FM waveform. It gives you the mathematically correct waveform that you specified, which is NOT what an FM waveform really looks like. The formula you used is correct ONLY when the modulation voltage is absolutely pure DC. If it varies at all, it is not correct. If you don't believe me, then pull out your calculator and prove it for yourself. It will take a lot of time, but you will get the same awful waveform that LTspice shows you in its simulation. I can guarantee that. I can't speak directly to the "waveform viewer math" picture because I have not looked at that yet, but I'm guessing there is a reason why it deceptively shows you the incorrect FM result. It must be calculating something differently, for some reason. Regards, Andy
|
Hello Kevin,
I tried a similar example with lower frequency with Gnu-Octave and LTspiceXVII. Both showed exactly this artifact near 0.55ms. The results have been identical.
? Changes to the schematic for a shorter simulation.
V1: 1.2
V2:? PULSE(1 -1 0 1m 1m 1u 2m)
.tran 0 1m 0 10n
Bv (no change) V=sin(2*3.14159262*v(fr)*time*1000000)
Octave:
>> t=0:100000;
>> t=1e-8*t;
>> m=0:100000;
>> m=2.2-2e-5*m;
>> y= sin(2*3.14159262.*m.*t*1000000);
>> plot(t,y)
Best regards, Helmut
|
Hello Kevin
In addition to Andy's comments :
In Tools>Control Panel>Waveforms
check? Use Radians in waveform expressions
Regards, PhB
|
Hello,
> In Tools>Control Panel>Waveforms > check? Use Radians in waveform expressions
This setting is only for expressions in the waveform viewer but not for the formula of a B-source.
Best regards, Helmut
?
|
Hi, Andy finally answered the question. Thank-you.
If I turn on radians in the analyser and set the start recording time to 0 then all is well and the two waveforms overlap properly.
Its obviously a trap for the unwary that 'time' in the waveform analyser is not the simulation'time'. Hence the confusion. That was my concern. So in future I shall be wary of using time in that way with a delayed start ( the delay was used from the original circuit that I trimmed down..)
When I checked that waveform analysis, of course I used the same span as the analysis window, and got the same answers in matlab too.
And now I can remind myself that frequency is the integral of phase and get the expression sorted out. This is just down to careless hacking in a hurry and not stopping to think :-)
Thanks,
Kevin.
|
?PhB wrote,
"In Tools>Control Panel>Waveforms
check Use Radians in waveform expressions"
Good point. Thank you.
Helmut wrote, "This setting is only for expressions in the waveform viewer but not for the formula of a B-source."
That's true; but it is a necessary step to get the two waveforms to agree in the waveform viewer. Two changes are needed to see agreement:
(1) Start the simulation at Tstart=0 instead of 5ms: ".tran 0 10m 0 1n"
(2) Make sure the waveform viewer uses Radians, by checking the setting mentioned by PhB.
Now, when you plot V(fm) and sin(2*3.14159262*v(fr)*time*1000000)*1V, the two are essentially the same. They have that funny looking thing that happens at about 5.4ms. It is mathematically correct. And it's not what a real FM signal would look like.
Regards,
Andy
|
Alternatively, use the original simulation with ".tran 0 10m 5m 1n", but instead of plotting the formula from the B-source, plot it with the 5ms time offset:
sin(2*3.14159262*v(fr)*(time+5m)*1000000)*1V
and be sure to use the Control Panel setting for Radians in waveform expressions.
The addition of "*1V" in the waveform expression is there to change it from unit-less, to units of Volts. It's no big deal, but it allows both waveforms to share the same Y-axis.
Regards,
Andy
|
Hello PhB,
Sorry for my last comment. Your answer has been the key.
I hadn't understood? what Kevin said with this sentence below.
> If
I cut and paste the B source definition into a new trace I get the
correct waveform but its not the same as the waveform in the sim at the
'fm' node.
Now after I read the message from Andy, I understand which traces Kevin compared.?
> If
I cut and paste the B source definition into a new trace I get the
correct waveform but its not the same as the waveform in the sim at the
'fm' node.
Best regards, Helmut
|
Kevin, not that it matters in the big picture, but it's the other way around. Phase is the integral of frequency (or frequency is the derivative of phase). That's why Vlad's solution uses the idt() function, to turn frequency into phase.
It's not a surprise that you thought your formula would make an FM signal. I even remember being taught that, in elementary trig classes, many years ago. It's not until you work out all the math, that one discovers it's wrong.
Regards,
Andy
|
