On Tue, 29 Jul 2014 19:36:45 -0700, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

>On Tue, 29 Jul 2014 18:29:35 -0700, John Larkin <jlarkin@highlandtechnology.com>
>wrote:
>
>>On Tue, 29 Jul 2014 17:22:53 -0700, RobertMacy
>><robert.a.macy@gmail.com> wrote:
>>
>>>On Tue, 29 Jul 2014 16:48:00 -0700, John Larkin  
>>><jlarkin@highlandtechnology.com> wrote:
>>>
>>>>> ...snip....
>>>>
>>>> The alternative would be to sum a few (3-10 maybe) rand(K*time) terms
>>>> and lowpass filter just enough to tame the edges. Crest factor would
>>>> be OK for most uses... grows by square root of the number of summed
>>>> sources, I think. I don't know if that would be faster or slower than
>>>> Box-Mueller, and there's no way to tell but to try it.
>>>>
>>>> I was impressed by random() being 6:1 slower than rand().
>>>>
>>>> This discussion is interesting. I have no use for it right now, but
>>>> I'm fairly sure I will one of these days. It is a break from writing
>>>> Python test scripts.
>>>>
>>>> I wonder if LT Spice pre-compiles or interprets math expressions. That
>>>> could probably be determined by experiment.
>>>
>>>Mike has installed a gaussian function, called white()
>>>
>>>Just like rand and random, it replicates and does not reseed.
>>>
>>>However, somehow he has a very decent gaussian distribution, but the range  
>>>is limited to +/- 0.5 [I think it is] Have NO idea how he does that. The  
>>>distribution just has a small 'cutoff' with no long tails extending out.
>>
>>That's interesting; I'll try it.
>
>noise() is peculiar. You have to say   V = noise(something).
>
>If 'something' = K*TIME, it seems to work and give a new value K times per
>second. But if K is large, it sort of runs out of steam pretty soon. Crest
>factor is only about 2.
>
>If 'something' is K * V(VA) where VA is a sine wave source of some frequency, to
>keep 'something' from getting too big, weird things happen again.
>
>I haven't quite figured it out, but it seems to run slow.


'noise' is just too weird.

This is pretty good:

It runs fast, the output *looks* like noise, crest factor is good, and it's very
tolerant of changes in time step size. Has slight DC bump at startup, easily
fixed with a little more work if it matters.

Version 4
SHEET 1 1044 680
WIRE 208 64 128 64
WIRE 256 64 208 64
WIRE 416 64 336 64
WIRE 480 64 416 64
WIRE 528 64 480 64
WIRE 128 96 128 64
WIRE 416 112 416 64
WIRE 128 208 128 176
WIRE 416 208 416 176
FLAG 128 208 0
FLAG 208 64 RAW
FLAG 416 208 0
FLAG 480 64 OUT
SYMBOL bv 128 80 R0
WINDOW 0 34 107 Left 2
WINDOW 3 -80 188 Left 2
SYMATTR InstName B1
 SYMATTR Value V= VS * (  rand(K1*time) + rand(K2*time) + rand(K3*time) + rand(K4*time) - 2  )
SYMBOL res 352 48 R90
WINDOW 0 63 52 VBottom 2
WINDOW 3 68 54 VTop 2
SYMATTR InstName R1
SYMATTR Value 1
SYMBOL cap 400 112 R0
WINDOW 0 85 22 Left 2
WINDOW 3 63 55 Left 2
SYMATTR InstName C1
SYMATTR Value 1.6e-4
TEXT 704 -24 Left 2 !.tran 0 1 0 5u
TEXT 88 -64 Left 2 ;1 volt RMS  1 KHz  Time-domain Noise Generator
TEXT 240 -16 Left 2 ;J Larkin   July 29, 2014
TEXT 664 72 Left 2 !.PARAM K2 = {6582}
TEXT 664 32 Left 2 !.PARAM K1 = {3435}
TEXT 664 112 Left 2 !.PARAM K3 = {5678}
TEXT 664 152 Left 2 !.PARAM K4 = {7777}
TEXT 664 192 Left 2 !.PARAM VS = {2.74}


(does that leading space fix the wrap problem?)







-- 

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation

On Tue, 29 Jul 2014 06:34:35 -0700, RobertMacy <robert.a.macy@gmail.com>
wrote:

>On Mon, 28 Jul 2014 20:21:45 -0700, Phil Hobbs =20
><pcdhSpamMeSenseless@electrooptical.net> wrote:
>
>> On 7/28/2014 7:02 PM, RobertMacy wrote:
>>> On Sat, 26 Jul 2014 14:34:46 -0700, John Larkin
>>> <jjlarkin@highnotlandthistechnologypart.com> wrote:
>>>
>>>>> ..snip...
>>>>
>>>> Post an LT Spice demo.
>>>>
>>>
>>> whew
>>>
>>> Since limited by length here, will try to put everything in.
>>>
>>
>> Eternal September costs the same as aioe, and doesn't have the silly =20
>> limitation.
>>
>> Cheers
>>
>> Phil Hobbs
>>
>>
>
>Yes, I am signed up for Eternal September and use it to receive every =20
>Usenet, but alt.home.repair
>
>but alas some setting I haven't figured out won't let me post through =
it, =20
>keep getting an error about some setting is wrong.
>
>So, when Aioe allowed me to instantly get going, was done.

Please, Please put forth the effort to resolve that.  Everyone will be
happier.

?-)
=20

On Tue, 29 Jul 2014 18:29:35 -0700, John Larkin <jlarkin@highlandtechnology.com>
wrote:

>On Tue, 29 Jul 2014 17:22:53 -0700, RobertMacy
><robert.a.macy@gmail.com> wrote:
>
>>On Tue, 29 Jul 2014 16:48:00 -0700, John Larkin  
>><jlarkin@highlandtechnology.com> wrote:
>>
>>>> ...snip....
>>>
>>> The alternative would be to sum a few (3-10 maybe) rand(K*time) terms
>>> and lowpass filter just enough to tame the edges. Crest factor would
>>> be OK for most uses... grows by square root of the number of summed
>>> sources, I think. I don't know if that would be faster or slower than
>>> Box-Mueller, and there's no way to tell but to try it.
>>>
>>> I was impressed by random() being 6:1 slower than rand().
>>>
>>> This discussion is interesting. I have no use for it right now, but
>>> I'm fairly sure I will one of these days. It is a break from writing
>>> Python test scripts.
>>>
>>> I wonder if LT Spice pre-compiles or interprets math expressions. That
>>> could probably be determined by experiment.
>>
>>Mike has installed a gaussian function, called white()
>>
>>Just like rand and random, it replicates and does not reseed.
>>
>>However, somehow he has a very decent gaussian distribution, but the range  
>>is limited to +/- 0.5 [I think it is] Have NO idea how he does that. The  
>>distribution just has a small 'cutoff' with no long tails extending out.
>
>That's interesting; I'll try it.

noise() is peculiar. You have to say   V = noise(something).

If 'something' = K*TIME, it seems to work and give a new value K times per
second. But if K is large, it sort of runs out of steam pretty soon. Crest
factor is only about 2.

If 'something' is K * V(VA) where VA is a sine wave source of some frequency, to
keep 'something' from getting too big, weird things happen again.

I haven't quite figured it out, but it seems to run slow.


-- 

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation

On Tue, 29 Jul 2014 17:22:53 -0700, RobertMacy
<robert.a.macy@gmail.com> wrote:

>On Tue, 29 Jul 2014 16:48:00 -0700, John Larkin  
><jlarkin@highlandtechnology.com> wrote:
>
>>> ...snip....
>>
>> The alternative would be to sum a few (3-10 maybe) rand(K*time) terms
>> and lowpass filter just enough to tame the edges. Crest factor would
>> be OK for most uses... grows by square root of the number of summed
>> sources, I think. I don't know if that would be faster or slower than
>> Box-Mueller, and there's no way to tell but to try it.
>>
>> I was impressed by random() being 6:1 slower than rand().
>>
>> This discussion is interesting. I have no use for it right now, but
>> I'm fairly sure I will one of these days. It is a break from writing
>> Python test scripts.
>>
>> I wonder if LT Spice pre-compiles or interprets math expressions. That
>> could probably be determined by experiment.
>
>Mike has installed a gaussian function, called white()
>
>Just like rand and random, it replicates and does not reseed.
>
>However, somehow he has a very decent gaussian distribution, but the range  
>is limited to +/- 0.5 [I think it is] Have NO idea how he does that. The  
>distribution just has a small 'cutoff' with no long tails extending out.

That's interesting; I'll try it.


-- 

John Larkin         Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

On Tue, 29 Jul 2014 16:48:00 -0700, John Larkin  
<jlarkin@highlandtechnology.com> wrote:

>> ...snip....
>
> The alternative would be to sum a few (3-10 maybe) rand(K*time) terms
> and lowpass filter just enough to tame the edges. Crest factor would
> be OK for most uses... grows by square root of the number of summed
> sources, I think. I don't know if that would be faster or slower than
> Box-Mueller, and there's no way to tell but to try it.
>
> I was impressed by random() being 6:1 slower than rand().
>
> This discussion is interesting. I have no use for it right now, but
> I'm fairly sure I will one of these days. It is a break from writing
> Python test scripts.
>
> I wonder if LT Spice pre-compiles or interprets math expressions. That
> could probably be determined by experiment.

Mike has installed a gaussian function, called white()

Just like rand and random, it replicates and does not reseed.

However, somehow he has a very decent gaussian distribution, but the range  
is limited to +/- 0.5 [I think it is] Have NO idea how he does that. The  
distribution just has a small 'cutoff' with no long tails extending out.

On Tue, 29 Jul 2014 12:58:03 -0700, Jim Thompson  
<To-Email-Use-The-Envelope-Icon@on-my-web-site.com> wrote:

> Barfs repeatedly for syntax errors.  Probably you need to post with
> wrap turned off.
> Also LTspice doesn't like "time_scale_factor={dt}"
> 		
>                                         ...Jim Thompson

No control over the wrap, have to straighten out by examination.

But, the LTspice version I have, 4.20x, May 2014, demands I put dt in {}

that's supposed to be all one line, not a single line by itself.

I'll send to you as .asc

On Tue, 29 Jul 2014 19:12:30 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>On 7/28/2014 11:52 PM, John Larkin wrote:
>> On Mon, 28 Jul 2014 22:36:45 -0400, Phil Hobbs <hobbs@electrooptical.net> wrote:
>>
>>> On 7/28/2014 9:24 PM, John Larkin wrote:
>>>> On Mon, 28 Jul 2014 16:31:38 -0700, RobertMacy
>>>> <robert.a.macy@gmail.com> wrote:
>>>>
>>>>> On Mon, 28 Jul 2014 16:15:18 -0700, Phil Hobbs <hobbs@electrooptical.net>
>>>>> wrote:
>>>>>
>>>>>>>> ...snip....
>>>>>>
>>>>>> I discussed how to fix that in later posts, like so.  I asked on the
>>>>>> Yahoo LTspice group whether there's any way to do frequency binning on
>>>>>> the LTspice FFT function.  So far, it doesn't look like it.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Phil Hobbs
>>>>>>
>>>>> I saw that, ....but didn't understand the purpose of the discussion and
>>>>> deleted the thread.  didn't know you started it, thought John Woodgate, UK
>>>>> started it. oops.
>>>>>
>>>>> Check a reply to John Larking, the FULL details of how to do the
>>>>> .transoise technique are in there.
>>>>
>>>> Seems awfully complex. This is pretty good:
>>>>
>>>>
>>>> Version 4
>>>> SHEET 1 880 680
>>>> WIRE 192 64 128 64
>>>> WIRE 272 64 192 64
>>>> WIRE 432 64 352 64
>>>> WIRE 512 64 432 64
>>>> WIRE 576 64 512 64
>>>> WIRE 128 96 128 64
>>>> WIRE 432 112 432 64
>>>> WIRE 128 208 128 176
>>>> WIRE 432 208 432 176
>>>> FLAG 128 208 0
>>>> FLAG 192 64 NOISE
>>>> FLAG 432 208 0
>>>> FLAG 512 64 LPF
>>>> SYMBOL bv 128 80 R0
>>>> WINDOW 0 -68 104 Left 2
>>>> WINDOW 3 -225 179 Left 2
>>>> SYMATTR InstName B1
>>>> SYMATTR Value V=58.65 * ( rand(12345*time) - 0.5 )
>>>> SYMBOL res 368 48 R90
>>>> WINDOW 0 72 56 VBottom 2
>>>> WINDOW 3 78 56 VTop 2
>>>> SYMATTR InstName R1
>>>> SYMATTR Value 1
>>>> SYMBOL cap 416 112 R0
>>>> WINDOW 0 70 20 Left 2
>>>> WINDOW 3 63 53 Left 2
>>>> SYMATTR InstName C1
>>>> SYMATTR Value 0.016
>>>> TEXT -176 104 Left 2 !.tran 0 10 0 10u
>>>> TEXT 24 -40 Left 2 ;10 Hz Noise Source   J Larkin   July 28, 2014
>>>>
>>>>
>>>> rand() runs about 6 times faster than random() and gives slightly
>>>> better crest factors and a mildly messier spectrum. Shaping the noise
>>>> spectrum would be easy by futzing the filter.
>>>>
>>>>
>>>
>>> That method is appealingly simple, I agree.  It generates independent
>>> samples much more slowly than the Box-Mueller approach, though, because
>>> you're relying on the central limit theorem to give you your Gaussian
>>> statistics, rather than applying the inverse function.
>>>
>>> Cheers
>>>
>>> Phil Hobbs
>>
>> Wouldn't you want to soften the sharp edges anyhow?
>>
>>
>>
>
>Sure, but not by that large a factor, I shouldn't think.   Modelling the 
>edges of the distribution accurately out so some crest factor M requires 
>integrating uniformly-distributed noise for some really long time 
>(something like exp(M**2/2) samples), whereas with the Box-Mueller 
>method, you get the Gaussian distribution to machine precision (or 
>whatever your random generator can do) in one step.
>
>Of course in LTspice, the rounded edges happen before the Box-Mueller 
>transform, which will mess up the distribution a bit.  One should really 
>sample in the middle of the interval, transform, and then smooth again.
>
>Whether any of that is worth the trouble depends on the situation.  Shot 
>noise and Johnson noise are really really Gaussian, so if one were 
>trying to model the counting statistics of threshold crossings, for 
>instance, you'd care quite a lot.
>
>Cheers
>
>Phil Hobbs

The alternative would be to sum a few (3-10 maybe) rand(K*time) terms
and lowpass filter just enough to tame the edges. Crest factor would
be OK for most uses... grows by square root of the number of summed
sources, I think. I don't know if that would be faster or slower than
Box-Mueller, and there's no way to tell but to try it.

I was impressed by random() being 6:1 slower than rand().

This discussion is interesting. I have no use for it right now, but
I'm fairly sure I will one of these days. It is a break from writing
Python test scripts.

I wonder if LT Spice pre-compiles or interprets math expressions. That
could probably be determined by experiment.



-- 

John Larkin         Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

On 7/28/2014 11:52 PM, John Larkin wrote:
> On Mon, 28 Jul 2014 22:36:45 -0400, Phil Hobbs <hobbs@electrooptical.net> wrote:
>
>> On 7/28/2014 9:24 PM, John Larkin wrote:
>>> On Mon, 28 Jul 2014 16:31:38 -0700, RobertMacy
>>> <robert.a.macy@gmail.com> wrote:
>>>
>>>> On Mon, 28 Jul 2014 16:15:18 -0700, Phil Hobbs <hobbs@electrooptical.net>
>>>> wrote:
>>>>
>>>>>>> ...snip....
>>>>>
>>>>> I discussed how to fix that in later posts, like so.  I asked on the
>>>>> Yahoo LTspice group whether there's any way to do frequency binning on
>>>>> the LTspice FFT function.  So far, it doesn't look like it.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Phil Hobbs
>>>>>
>>>> I saw that, ....but didn't understand the purpose of the discussion and
>>>> deleted the thread.  didn't know you started it, thought John Woodgate, UK
>>>> started it. oops.
>>>>
>>>> Check a reply to John Larking, the FULL details of how to do the
>>>> .transoise technique are in there.
>>>
>>> Seems awfully complex. This is pretty good:
>>>
>>>
>>> Version 4
>>> SHEET 1 880 680
>>> WIRE 192 64 128 64
>>> WIRE 272 64 192 64
>>> WIRE 432 64 352 64
>>> WIRE 512 64 432 64
>>> WIRE 576 64 512 64
>>> WIRE 128 96 128 64
>>> WIRE 432 112 432 64
>>> WIRE 128 208 128 176
>>> WIRE 432 208 432 176
>>> FLAG 128 208 0
>>> FLAG 192 64 NOISE
>>> FLAG 432 208 0
>>> FLAG 512 64 LPF
>>> SYMBOL bv 128 80 R0
>>> WINDOW 0 -68 104 Left 2
>>> WINDOW 3 -225 179 Left 2
>>> SYMATTR InstName B1
>>> SYMATTR Value V=58.65 * ( rand(12345*time) - 0.5 )
>>> SYMBOL res 368 48 R90
>>> WINDOW 0 72 56 VBottom 2
>>> WINDOW 3 78 56 VTop 2
>>> SYMATTR InstName R1
>>> SYMATTR Value 1
>>> SYMBOL cap 416 112 R0
>>> WINDOW 0 70 20 Left 2
>>> WINDOW 3 63 53 Left 2
>>> SYMATTR InstName C1
>>> SYMATTR Value 0.016
>>> TEXT -176 104 Left 2 !.tran 0 10 0 10u
>>> TEXT 24 -40 Left 2 ;10 Hz Noise Source   J Larkin   July 28, 2014
>>>
>>>
>>> rand() runs about 6 times faster than random() and gives slightly
>>> better crest factors and a mildly messier spectrum. Shaping the noise
>>> spectrum would be easy by futzing the filter.
>>>
>>>
>>
>> That method is appealingly simple, I agree.  It generates independent
>> samples much more slowly than the Box-Mueller approach, though, because
>> you're relying on the central limit theorem to give you your Gaussian
>> statistics, rather than applying the inverse function.
>>
>> Cheers
>>
>> Phil Hobbs
>
> Wouldn't you want to soften the sharp edges anyhow?
>
>
>

Sure, but not by that large a factor, I shouldn't think.   Modelling the 
edges of the distribution accurately out so some crest factor M requires 
integrating uniformly-distributed noise for some really long time 
(something like exp(M**2/2) samples), whereas with the Box-Mueller 
method, you get the Gaussian distribution to machine precision (or 
whatever your random generator can do) in one step.

Of course in LTspice, the rounded edges happen before the Box-Mueller 
transform, which will mess up the distribution a bit.  One should really 
sample in the middle of the interval, transform, and then smooth again.

Whether any of that is worth the trouble depends on the situation.  Shot 
noise and Johnson noise are really really Gaussian, so if one were 
trying to model the counting statistics of threshold crossings, for 
instance, you'd care quite a lot.

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

On Tue, 29 Jul 2014 12:25:56 -0700, RobertMacy
<robert.a.macy@gmail.com> wrote:

>On Mon, 28 Jul 2014 21:00:57 -0700, John Larkin  
><jjlarkin@highnotlandthistechnologypart.com> wrote:
>
>>> ...snip....
>>
>> Point is, rand(time) can be the basis of a pretty good time-domain noise  
>> source,
>> and it's easy.
>
>As promised here is a simple resistor network with CALIBRATED noise  
>sources. The schematic has comparison notes. It is interesting to note  
>that the resistor networks do NOT even add a single node to the PSpice  
>solution matrix, which maintains speed [and I'll bet accuracy]
>
>some of the fonts may not transfer.
>
>ResistorCompare.asc
>
>Version 4
>SHEET 1 27404 712
>WIRE 896 -16 880 -16
>WIRE 1344 -16 896 -16
>WIRE 1936 -16 1424 -16
>WIRE 2048 -16 1936 -16
>WIRE 2112 -16 2048 -16
>WIRE 2208 -16 2112 -16
>WIRE 880 16 880 -16
>WIRE 1936 16 1936 -16
>WIRE 2048 32 2048 -16
>WIRE 2144 32 2048 32
>WIRE 2048 112 2048 96
>WIRE 2144 112 2048 112
>WIRE 2368 112 2256 112
>WIRE 2416 112 2368 112
>WIRE 880 144 880 96
>WIRE 1936 144 1936 96
>WIRE 2048 144 2048 112
>WIRE 2256 160 2256 112
>WIRE 2208 176 2208 -16
>WIRE 2256 272 2256 240
>WIRE 1248 320 1232 320
>WIRE 1312 320 1248 320
>WIRE 1328 320 1312 320
>WIRE 1424 320 1408 320
>WIRE 1936 320 1424 320
>WIRE 2048 320 1936 320
>WIRE 2112 320 2048 320
>WIRE 2208 320 2208 224
>WIRE 2208 320 2112 320
>WIRE 1936 336 1936 320
>WIRE 1936 336 1856 336
>WIRE 1856 352 1856 336
>WIRE 1936 352 1936 336
>WIRE 2048 368 2048 320
>WIRE 2144 368 2048 368
>WIRE 1312 400 1312 320
>WIRE 1328 400 1312 400
>WIRE 1424 400 1424 320
>WIRE 1424 400 1408 400
>WIRE 1856 448 1856 432
>WIRE 1936 448 1936 432
>WIRE 1936 448 1856 448
>WIRE 2048 448 2048 432
>WIRE 2144 448 2048 448
>WIRE 1936 480 1936 448
>WIRE 2048 480 2048 448
>FLAG 880 144 0
>FLAG 1936 144 0
>FLAG 2048 144 0
>FLAG 1936 480 0
>FLAG 2048 480 0
>FLAG 896 -16 in
>FLAG 1248 320 in
>FLAG 2112 320 out
>FLAG 2112 -16 out1
>FLAG 2256 272 0
>FLAG 2368 112 compare
>SYMBOL res 1328 0 R270
>WINDOW 0 32 56 VTop 2
>WINDOW 3 0 56 VBottom 2
>SYMATTR InstName Rs1
>SYMATTR Value {Rs}
>SYMBOL res 1920 0 R0
>SYMATTR InstName Rload1
>SYMATTR Value {Rload}
>SYMBOL voltage 880 0 R0
>WINDOW 0 -119 20 Left 2
>WINDOW 3 -249 101 Left 2
>WINDOW 123 -131 67 Left 2
>WINDOW 39 0 0 Left 2
>SYMATTR InstName Vin
>SYMATTR Value SINE(0 100uV 100kHz)
>SYMATTR Value2 AC 1
>SYMBOL cap 2032 32 R0
>SYMATTR InstName Cload1
>SYMATTR Value 1nF
>SYMBOL res 1312 336 R270
>WINDOW 0 32 56 VTop 2
>WINDOW 3 -1 62 VBottom 2
>SYMATTR InstName Rs2
>SYMATTR Value {Rs}
>SYMBOL res 1920 336 R0
>SYMATTR InstName Rload2
>SYMATTR Value {Rload}
>SYMBOL cap 2032 368 R0
>SYMATTR InstName Cload2
>SYMATTR Value 1nF
>SYMBOL e 2256 144 R0
>SYMATTR InstName Ecompare
>SYMATTR Value 1
>SYMBOL current 1328 400 R270
>WINDOW 0 -66 33 VTop 2
>WINDOW 3 -94 33 VTop 2
>SYMATTR InstName InoiseRs
>SYMATTR Value PWL  value_scale_factor={sqrt(4*k*T/Rs*fmax)}  
>time_scale_factor={dt}  file=Vn1.txt
>SYMBOL current 1856 352 R0
>WINDOW 0 -142 -7 Left 2
>WINDOW 3 -154 176 Left 2
>SYMATTR InstName InoiseRload
>SYMATTR Value PWL  value_scale_factor={sqrt(4*k*T/Rload*fmax)}  
>time_scale_factor={dt}  file=Vn2.txt
>TEXT 584 424 Left 2 !.tran 0 {Tstop} {Tstart} {dt/2}
>TEXT 592 344 Left 2 ;.ac dec 100  {BW} {fmax}
>TEXT 592 376 Left 2 ;.noise V(out) Vin dec 100 {BW}  {fmax}
>TEXT 1400 -104 Left 2 ;NORMAL CIRCUIT
>TEXT 1376 232 Left 2 ;.TRANOISE CIRCUIT
>TEXT 584 168 Left 2 !.options  plotwinsize=0\n.param  Rs=1k   
>Rload=5k\n.param  k=1.38e-23  T=300   N=20000  fmax=10MEG\n.param   
>Tstop={1.1*N/2/fmax}  Tstart={0.1*N/2/fmax}\n.param  dt={1/2/fmax}   
>BW={2*fmax/N}
>TEXT 1256 104 Left 2 ;Circuit set up for 1kHz to 10MHz operation
>TEXT 2472 -16 Left 2 ;.ac  V(out) at 100kHz is -2.62657dB, if rms for  
>100uVp signal that is 52.258 uVrms\n.noise    V(onoise) shows  
>2.0199&#4294967295;Vrms\n                    with no cap, 11.752&#4294967295;Vrms\n              
>starts at 3.71659nV/Hz&#4294967295;\n                    with no cap,  
>3.71664nV/Hz&#4294967295;\n.tran  V(compare) ctl-left-clk shows approx  
>2.0245&#4294967295;Vrms\n                                              with no cap,  
>11.522&#4294967295;Vrms\n           from FFT approx starts at  -140dBV, estimate start  
>at 3.2 nV/rtHz\n                     with no cap, approx -140dBV, estimate  
>3.2 nVrms/rtHz\n             using V(out), peak arppox -86.0377dBV\n   
>octave Post Processing:\n       using V(compare_eq)\n                       
>time waveform, 2.04uVrms\n          after conversion to spectrum using  
>time2freq, starts with 3.64nV/rtHz\n      using V(out_eq)\n          after  
>conversion to spectrum using time2freq, peak occurs at -85.639 dBV,  
>52.246uVrms
>TEXT 824 520 Left 2 ;NOTE: Usually the full formula of each PWL  
>description are NOT shown,\n            but are left shown here for review.

Barfs repeatedly for syntax errors.  Probably you need to post with
wrap turned off.

Also LTspice doesn't like "time_scale_factor={dt}"
		
                                        ...Jim Thompson
-- 
| James E.Thompson                                 |    mens     |
| Analog Innovations                               |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| San Tan Valley, AZ 85142     Skype: skypeanalog  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |
             
I love to cook with wine.     Sometimes I even put it in the food.