Phase Noise vs. Jitter

On Sat, 21 Sep 2019 00:56:01 +0000 (UTC),
DecadentLinuxUserNumeroUno@decadence.org wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote in
news:aj2aoe9c3t5a8ku36tpa52m2gtrqm6bqvs@4ax.com:

On Fri, 20 Sep 2019 03:05:50 -0700 (PDT), "John Miles, KE5FX"
jmiles@gmail.com> wrote:

On Wednesday, September 18, 2019 at 7:27:11 PM UTC-7,
I snooped the switcher node, Rigol scope FFT and a big ole
spectrum analyzer, but neither is dramatically instructive.

Hmm, and now I can't repro it here, either. At one point I was
getting a lot of EMI at 30 kHz (IIRC) from this setup in
spread-spectrum mode:

http://www.ke5fx.com/LT8650S.gif

Of course I didn't save any plots at the time, or keep any actual
notes. Oh, well, guess it fixed itself.

-- john, KE5FX

My FPGA kids refuse to use enough core current to get my switcher
out of burp mode. They should compute pi to a trillion places or
something. Burp complicates the spectrum.

Here's the board.

https://www.dropbox.com/s/45i9bfmzr9b2pf5/TPlus_E2_Leds.JPG?raw=1

Seems to work first try. My big mistake was making the blue LED
too bright, but I think we'll fix that in the FPGA.


That could just be an effect of the camera angle and that specific
LED's reflecto-dish. Or like you said... a different current limit
resistor driving it.

No, it's really annoyingly bright. We can PWM it in the FPGA, so I
don't have to write an ECO to change the resistor.

It would be cool to go to production on this board with no ECOs.

 

jlarkin@highlandsniptechnology.com wrote in
news:hnvaoepn3kc0lpu185u64ec9j9l4unlmv8@4ax.com:

On Sat, 21 Sep 2019 00:56:01 +0000 (UTC),
DecadentLinuxUserNumeroUno@decadence.org wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote in
news:aj2aoe9c3t5a8ku36tpa52m2gtrqm6bqvs@4ax.com:

On Fri, 20 Sep 2019 03:05:50 -0700 (PDT), "John Miles, KE5FX"
jmiles@gmail.com> wrote:

On Wednesday, September 18, 2019 at 7:27:11 PM UTC-7,
I snooped the switcher node, Rigol scope FFT and a big ole
spectrum analyzer, but neither is dramatically instructive.

Hmm, and now I can't repro it here, either. At one point I was
getting a lot of EMI at 30 kHz (IIRC) from this setup in
spread-spectrum mode:

http://www.ke5fx.com/LT8650S.gif

Of course I didn't save any plots at the time, or keep any actual
notes. Oh, well, guess it fixed itself.

-- john, KE5FX

My FPGA kids refuse to use enough core current to get my switcher
out of burp mode. They should compute pi to a trillion places or
something. Burp complicates the spectrum.

Here's the board.

https://www.dropbox.com/s/45i9bfmzr9b2pf5/TPlus_E2_Leds.JPG?raw=1

Seems to work first try. My big mistake was making the blue LED
too bright, but I think we'll fix that in the FPGA.


That could just be an effect of the camera angle and that
specific
LED's reflecto-dish. Or like you said... a different current
limit
resistor driving it.

No, it's really annoyingly bright. We can PWM it in the FPGA, so I
don't have to write an ECO to change the resistor.

It would be cool to go to production on this board with no ECOs.

Don't you have to write an ECO (albeit an easier to implement one)
to change the FPGA as well? Or that does not get a part number stamp
until it is all ironed out?

 

On Sat, 21 Sep 2019 02:17:27 +0000 (UTC),
DecadentLinuxUserNumeroUno@decadence.org wrote:

jlarkin@highlandsniptechnology.com wrote in
news:hnvaoepn3kc0lpu185u64ec9j9l4unlmv8@4ax.com:

On Sat, 21 Sep 2019 00:56:01 +0000 (UTC),
DecadentLinuxUserNumeroUno@decadence.org wrote:

John Larkin <jlarkin@highland_atwork_technology.com> wrote in
news:aj2aoe9c3t5a8ku36tpa52m2gtrqm6bqvs@4ax.com:

On Fri, 20 Sep 2019 03:05:50 -0700 (PDT), "John Miles, KE5FX"
jmiles@gmail.com> wrote:

On Wednesday, September 18, 2019 at 7:27:11 PM UTC-7,
I snooped the switcher node, Rigol scope FFT and a big ole
spectrum analyzer, but neither is dramatically instructive.

Hmm, and now I can't repro it here, either. At one point I was
getting a lot of EMI at 30 kHz (IIRC) from this setup in
spread-spectrum mode:

http://www.ke5fx.com/LT8650S.gif

Of course I didn't save any plots at the time, or keep any actual
notes. Oh, well, guess it fixed itself.

-- john, KE5FX

My FPGA kids refuse to use enough core current to get my switcher
out of burp mode. They should compute pi to a trillion places or
something. Burp complicates the spectrum.

Here's the board.

https://www.dropbox.com/s/45i9bfmzr9b2pf5/TPlus_E2_Leds.JPG?raw=1

Seems to work first try. My big mistake was making the blue LED
too bright, but I think we'll fix that in the FPGA.


That could just be an effect of the camera angle and that
specific
LED's reflecto-dish. Or like you said... a different current
limit
resistor driving it.

No, it's really annoyingly bright. We can PWM it in the FPGA, so I
don't have to write an ECO to change the resistor.

It would be cool to go to production on this board with no ECOs.


Don't you have to write an ECO (albeit an easier to implement one)
to change the FPGA as well? Or that does not get a part number stamp
until it is all ironed out?

The uP and FPGA code are still in development and not released yet.
Both will be born and released as rev A, and that's already called out
on the BOM.

Some people use an ECO to do anything, but we literally use it as a
Change order. Releases are, well, just released.

 

[Clifford Heath]

On 21/9/19 7:18 am, Gerhard Hoffmann wrote:

Am 20.09.19 um 22:20 schrieb John Larkin:
On Fri, 20 Sep 2019 20:29:15 +0200, Gerhard Hoffmann <dk4xp@arcor.de
wrote:
Am 20.09.19 um 19:44 schrieb John Larkin:
My FPGA kids refuse to use enough core current to get my switcher out
of burp mode. They should compute pi to a trillion places or
something. Burp complicates the spectrum.

Tell them to make a LFSR counter with 10K flipflops and toggle it with
the highest clock they have on the chip. Binary counters do not work.
There, the lowest bit takes all the power, the higher bits don't
"count".
I feel somewhat guilty.

Admitting to eco-terrorism?

Gerhard
Period = 2^10000 - 1
One problem is to keep the compiler from optimizing out something that
has no function. The fix is to do something that is too complex for
the compiler to understand, and bring it out to a pin.
The run length does not matter. The point is that about half the FFs
toggle each clock. Having one output pin to nirvana is the easiest way
to make sure that it is not optimized away.

Surely driving the output pin costs more than the flip flop anyhow. If
the objective is to burn power, bring out more of the stages to pins and
add a load.

Clifford Heath

 

[Cursitor Doom]

On Thu, 19 Sep 2019 08:29:32 -0700, bloggs.fredbloggs.fred wrote:

> career malingerer and ne'er do well.

Sloman? That's tough - but fair. :-D




--
This message may be freely reproduced without limit or charge only via
the Usenet protocol. Reproduction in whole or part through other
protocols, whether for profit or not, is conditional upon a charge of
GBP10.00 per reproduction. Publication in this manner via non-Usenet
protocols constitutes acceptance of this condition.

 

[Bill Sloman]

On Saturday, September 21, 2019 at 9:58:54 PM UTC+10, Cursitor Doom wrote:

On Thu, 19 Sep 2019 08:29:32 -0700, bloggs.fredbloggs.fred wrote:

career malingerer and ne'er do well.

Sloman? That's tough - but fair. :-D

Cursitor Doom reminds us that he hasn't got a clue, and probably never had.

https://www.google.com/search?client=firefox-b-d&q=malingering+meaning

One has to wonder what disease he thinks I might have pretended to have had?

Even when I had my aortic valve replaced, I wasn't sick (though I might have become sick if it hadn't been done). My diagnostician's letter the surgeon started off with "The patient isn't sick". In Dutch as it happens.

--
Bill Sloman, Sydney