• Direct digital synthesis of square waves

    From Anthony William Sloman@21:1/5 to All on Sat Aug 13 23:51:32 2022
    It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    The LTC2000 can be clocked at 2.5GHz, so the rising and falling edges could be just 6.4nsec wide, and your maximum full amplitude output frequency would be a 78MHz triangular wave.

    The trick is that you could have 1024 different rising or falling edges, with all the steps moved up or down in in steps of 0.1% of the full scale swing.

    Only the first and last steps of the staircase would look different.

    If you low pass filtered the waveform the zero crossing point would move across the 0.4nsec clock period in steps of 0.4psec.

    The trick would be to use a Bessel - linear phase - filter which has a little bit of output ripple (figure 2.58 in Williams and Taylor) where the impulse response crosses the zero line, and put that point at the 3.2 nsec zero-crossing point ( picking the
    filter time constant to be about 0.64nsec, depending on the filter order) which would stop the odd first step from having much effect on the zero crossing point.

    You could get any frequency less than 78.125 MHz, and you could step the period up in increments of 0.4.psec. 78.123 MHz would be the next one down

    Because your filter only deals with rising an falling edges, you don't need to change it when you are synthesising much slower square waves.

    It should work. I'd hate to build it - the LTC2000 comes in a ball grid array package.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Sun Aug 14 02:22:50 2022
    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't matter, why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse

    Version 4
    SHEET 1 3724 680
    WIRE 480 48 432 48
    WIRE 160 64 48 64
    WIRE 272 64 240 64
    WIRE 368 64 272 64
    WIRE 272 80 272 64
    WIRE 48 96 48 64
    FLAG 272 144 0
    FLAG 48 176 0
    SYMBOL voltage 48 80 R0
    WINDOW 3 -363 55 Left 2
    WINDOW 123 0 0 Left 0
    WINDOW 39 0 0 Left 0
    SYMATTR InstName V1
    SYMATTR Value PULSE(0 {v} 10n 1p 1p .1u .2u)
    SYMBOL res 256 48 R90
    WINDOW 0 0 56 VBottom 2
    WINDOW 3 32 56 VTop 2
    SYMATTR InstName R1
    SYMATTR Value 100
    SYMBOL cap 256 80 R0
    SYMATTR InstName C1
    SYMATTR Value 200p
    SYMBOL Digital\\buf 368 0 R0
    SYMATTR InstName A1
    TEXT -394 -48 Left 2 !.tran 0 40n 0 .1n
    TEXT -56 -96 Left 2 !.step param v list 0.79061 0.80014 0.81067 0.82231 0.83517 0.84939 0.86510 0.88246 0.90165 0.92286 0.94630 0.97221 1.00083 1.03247 1.06744 1.10608 1.14879 1.19599 1.24815 1.30580 1.36952 1.
    43993 1.51775 1.60375 1.69880 1.80385 1.91994 2.04824 2.19004 2.34675 2.51994



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Monett VE3BTI@21:1/5 to Lasse Langwadt Christensen on Sun Aug 14 14:14:36 2022
    Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    [...]

    since it is for a trigger and the falling edge probably doesn't matter,
    why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse

    See if this works to get it on screen:

    Version 4
    SHEET 1 3724 680
    WIRE 464 48 432 48
    WIRE 480 48 464 48
    WIRE 64 64 48 64
    WIRE 160 64 64 64
    WIRE 272 64 240 64
    WIRE 304 64 272 64
    WIRE 368 64 304 64
    WIRE 272 80 272 64
    WIRE 48 96 48 64
    WIRE 48 192 48 176
    FLAG 272 144 0
    FLAG 48 192 0
    FLAG 64 64 Pin
    FLAG 304 64 R1C1
    FLAG 464 48 A1O
    SYMBOL voltage 48 80 R0
    WINDOW 3 -30 151 Left 2
    WINDOW 123 0 0 Left 2
    WINDOW 39 0 0 Left 2
    SYMATTR Value PULSE(0 {v} 10n 1p 1p .1u .2u)
    SYMATTR InstName V1
    SYMBOL res 256 48 R90
    WINDOW 0 0 56 VBottom 2
    WINDOW 3 32 56 VTop 2
    SYMATTR InstName R1
    SYMATTR Value 100
    SYMBOL cap 256 80 R0
    SYMATTR InstName C1
    SYMATTR Value 200p
    SYMBOL Digital\\buf 368 0 R0
    SYMATTR InstName A1
    TEXT 192 -160 Left 2 !.tran 0 40n 0 0.01n
    TEXT -56 -96 Left 2 !.step param v list 0.79061 0.80014 0.81067
    0.82231 0.83517 0.84939 0.86510\n+0.88246 0.90165 0.92286
    0.94630 0.97221 1.00083 1.03247 1.06744\n+1.10608 1.14879
    1.19599 1.24815 1.30580 1.36952 1.43993 1.51775\n+1.60375
    1.69880 1.80385 1.91994 2.04824 2.19004 2.34675 2.51994
    TEXT 200 -200 Left 2 ;'Step Timing


    --
    MRM

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Sun Aug 14 07:14:04 2022
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    sřndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't matter, why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time resolution, less jitter, at low frequencies.

    Conventional thinking treats the DDS as the tail end of a Shannon
    sampling system. But that requires that the signal that we're trying
    to make is perfectly bandlimited, which a sine is but a trapezoid
    isn't. So wave goodby to Shannon.

    So we need to synthesize a fast edge, much faster than a sine, and
    poke that into an interpolation filter with a short attention span,
    one that sees the smooth part of the slope but forgets the sharp
    transition. Maybe synthesise an s-shaped rising edge to reduce the
    signal bandwidth some.

    And of course we need to reach farther right into the phase
    accumulator bits, in real life or maybe by interpolation.

    Hmmm, I could put a function, tanh or something, after the sine lookup
    in my DDS sim, to speed up the mid slope. That at least helps the
    comparator. Gotta think about that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Sun Aug 14 07:33:23 2022
    søndag den 14. august 2022 kl. 16.14.43 UTC+2 skrev Mike Monett VE3BTI:
    Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    [...]
    since it is for a trigger and the falling edge probably doesn't matter, why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse
    See if this works to get it on screen:

    the step param list needs to be one single long line

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Sun Aug 14 09:36:44 2022
    søndag den 14. august 2022 kl. 18.19.28 UTC+2 skrev Mike Monett VE3BTI:
    Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 16.14.43 UTC+2 skrev Mike Monett VE3BTI:
    Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    [...]
    since it is for a trigger and the falling edge probably doesn't
    matter,

    why not a single variable voltage step into a filter, sorta like a
    time-to-amplitude in reverse
    See if this works to get it on screen:

    the step param list needs to be one single long line
    No, it does not need to be one single line. Run the ASC file I posted. It runs fine in LTspice IV and XVII.

    you can use \n to make it multi line the schematic but it still needs to be a single line in the .asc file

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Monett VE3BTI@21:1/5 to Lasse Langwadt Christensen on Sun Aug 14 16:19:20 2022
    Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 16.14.43 UTC+2 skrev Mike Monett VE3BTI:
    Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    [...]
    since it is for a trigger and the falling edge probably doesn't
    matter,

    why not a single variable voltage step into a filter, sorta like a
    time-to-amplitude in reverse
    See if this works to get it on screen:

    the step param list needs to be one single long line

    No, it does not need to be one single line. Run the ASC file I posted. It
    runs fine in LTspice IV and XVII.

    It is a good idea to label each node as I have done. If you plot an
    unlabeled node, and make one change to the circuit, all the nodes get renumbered. So you lose the waveform on the node you want, and get some
    other waveform that you don't want.

    There is no notice that the nodes have been renumbered, so you will think
    you have done something to wreck the circuit. This may take a bit of
    wasted effort trying to figure out what you have done.

    If you label all the nodes, and make a change, the waveform will stay with
    the node you want.



    --
    MRM

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Monett VE3BTI@21:1/5 to Lasse Langwadt Christensen on Sun Aug 14 17:08:43 2022
    Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 18.19.28 UTC+2 skrev Mike Monett VE3BTI:

    [...]

    the step param list needs to be one single long line
    No, it does not need to be one single line. Run the ASC file I posted.
    It

    runs fine in LTspice IV and XVII.

    you can use \n to make it multi line the schematic but it still needs to
    be a single line in the .asc file

    No it does not. Here is the line in the ASC file:

    TEXT 192 -160 Left 2 !.tran 0 40n 0 0.01n
    TEXT -56 -96 Left 2 !.step param v list 0.79061 0.80014 0.81067
    0.82231 0.83517 0.84939 0.86510\n+0.88246 0.90165 0.92286
    0.94630 0.97221 1.00083 1.03247 1.06744\n+1.10608 1.14879
    1.19599 1.24815 1.30580 1.36952 1.43993 1.51775\n+1.60375
    1.69880 1.80385 1.91994 2.04824 2.19004 2.34675 2.51994

    Those line returns are Windows ASCII OD,OA, not Linux OD



    --
    MRM

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Sun Aug 14 19:49:27 2022
    Am 14.08.22 um 16:14 schrieb jlarkin@highlandsniptechnology.com:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't matter, why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time resolution, less jitter, at low frequencies.

    Conventional thinking treats the DDS as the tail end of a Shannon
    sampling system. But that requires that the signal that we're trying
    to make is perfectly bandlimited, which a sine is but a trapezoid
    isn't. So wave goodby to Shannon.

    So we need to synthesize a fast edge, much faster than a sine, and
    poke that into an interpolation filter with a short attention span,
    one that sees the smooth part of the slope but forgets the sharp
    transition. Maybe synthesise an s-shaped rising edge to reduce the
    signal bandwidth some.

    And of course we need to reach farther right into the phase
    accumulator bits, in real life or maybe by interpolation.

    Hmmm, I could put a function, tanh or something, after the sine lookup
    in my DDS sim, to speed up the mid slope. That at least helps the
    comparator. Gotta think about that.

    You can take my VHDL design and have one of your FPGA guys
    replace sin(x) by sin(x) * tanh(x) and simulate it in a few
    seconds in Modelsim, Questasim or whatever you have.
    You get a pseudo-analog output.

    The code that fills the ROM is a single process that feels
    like Pascal, no concurrency. The intermediate results are even
    files that could be used in Matlab.

    That all does not have much to do with VHDL; I just choose VHDL
    because you need it anyway for compiling the chip. It could
    just as good have been C or Pascal; that would require more
    infrastructure such as gcc or turbo-pascal. It only generates
    a text file that is put into the ROM when builing the chip.


    Cheers, Gerhard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Sun Aug 14 10:27:23 2022
    søndag den 14. august 2022 kl. 19.08.50 UTC+2 skrev Mike Monett VE3BTI:
    Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 18.19.28 UTC+2 skrev Mike Monett VE3BTI:
    [...]
    the step param list needs to be one single long line
    No, it does not need to be one single line. Run the ASC file I posted.
    It

    runs fine in LTspice IV and XVII.

    you can use \n to make it multi line the schematic but it still needs to be a single line in the .asc file
    No it does not. Here is the line in the ASC file:
    TEXT 192 -160 Left 2 !.tran 0 40n 0 0.01n
    TEXT -56 -96 Left 2 !.step param v list 0.79061 0.80014 0.81067
    0.82231 0.83517 0.84939 0.86510\n+0.88246 0.90165 0.92286
    0.94630 0.97221 1.00083 1.03247 1.06744\n+1.10608 1.14879
    1.19599 1.24815 1.30580 1.36952 1.43993 1.51775\n+1.60375
    1.69880 1.80385 1.91994 2.04824 2.19004 2.34675 2.51994
    Those line returns are Windows ASCII OD,OA, not Linux OD


    let me spell it out: IT DOES NOT WORK

    it has to be one line in the .asc file

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Sun Aug 14 14:09:34 2022
    On Sun, 14 Aug 2022 19:49:27 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
    wrote:

    Am 14.08.22 um 16:14 schrieb jlarkin@highlandsniptechnology.com:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    sřndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't matter, why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    Conventional thinking treats the DDS as the tail end of a Shannon
    sampling system. But that requires that the signal that we're trying
    to make is perfectly bandlimited, which a sine is but a trapezoid
    isn't. So wave goodby to Shannon.

    So we need to synthesize a fast edge, much faster than a sine, and
    poke that into an interpolation filter with a short attention span,
    one that sees the smooth part of the slope but forgets the sharp
    transition. Maybe synthesise an s-shaped rising edge to reduce the
    signal bandwidth some.

    And of course we need to reach farther right into the phase
    accumulator bits, in real life or maybe by interpolation.

    Hmmm, I could put a function, tanh or something, after the sine lookup
    in my DDS sim, to speed up the mid slope. That at least helps the
    comparator. Gotta think about that.

    You can take my VHDL design and have one of your FPGA guys
    replace sin(x) by sin(x) * tanh(x) and simulate it in a few
    seconds in Modelsim, Questasim or whatever you have.
    You get a pseudo-analog output.

    The code that fills the ROM is a single process that feels
    like Pascal, no concurrency. The intermediate results are even
    files that could be used in Matlab.

    That all does not have much to do with VHDL; I just choose VHDL
    because you need it anyway for compiling the chip. It could
    just as good have been C or Pascal; that would require more
    infrastructure such as gcc or turbo-pascal. It only generates
    a text file that is put into the ROM when builing the chip.


    Cheers, Gerhard





    My DDS sim is in Spice. I posted that a few threads above.

    I've parameterized it and added a sort of jitter computer; I'll post
    that soon. It's a platform for trying things out.

    A 5 us run takes about an hour at 1 ps time step.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Monett VE3BTI@21:1/5 to Lasse Langwadt Christensen on Sun Aug 14 21:58:47 2022
    Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 19.08.50 UTC+2 skrev Mike Monett VE3BTI:
    Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 18.19.28 UTC+2 skrev Mike Monett VE
    3BTI:
    [...]
    the step param list needs to be one single long line
    No, it does not need to be one single line. Run the ASC file I
    posted.

    It

    runs fine in LTspice IV and XVII.

    you can use \n to make it multi line the schematic but it still needs
    t o be a single line in the .asc file
    No it does not. Here is the line in the ASC file:
    TEXT 192 -160 Left 2 !.tran 0 40n 0 0.01n
    TEXT -56 -96 Left 2 !.step param v list 0.79061 0.80014 0.81067
    0.82231 0.83517 0.84939 0.86510\n+0.88246 0.90165 0.92286
    0.94630 0.97221 1.00083 1.03247 1.06744\n+1.10608 1.14879
    1.19599 1.24815 1.30580 1.36952 1.43993 1.51775\n+1.60375
    1.69880 1.80385 1.91994 2.04824 2.19004 2.34675 2.51994
    Those line returns are Windows ASCII OD,OA, not Linux OD


    let me spell it out: IT DOES NOT WORK

    it has to be one line in the .asc file

    It works fine in LTspice IV and XVII. I tested it before posting.

    I downloaded the file from google groups. It is not the same as the one I posted.

    My original file is 1085 bytes long. The google groups file is 1071 bytes
    long.

    It turns out the three spaces between each step parameter in the original
    have been replaced with the single ascii code 249. It will not load.

    It aborts with the error message "Unknown schematic syntax"

    So the problem is somewhere in my news client or in eternal-september.org
    or in the newsgroup service itself.

    I have zipped the original and uploaded it to Google Drive. Please
    download it at https://tinyurl.com/3x256eej and see if it runs better.

    Meanwhile, I will try adding three spaces between these words and see
    what happens.


    --
    MRM

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Vestergaard Kragelund@21:1/5 to Lasse Langwadt Christensen on Sun Aug 14 23:58:03 2022
    On 14/08/2022 11.22, Lasse Langwadt Christensen wrote:
    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't matter, why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse

    Version 4
    SHEET 1 3724 680
    WIRE 480 48 432 48
    WIRE 160 64 48 64
    WIRE 272 64 240 64
    WIRE 368 64 272 64
    WIRE 272 80 272 64
    WIRE 48 96 48 64
    FLAG 272 144 0
    FLAG 48 176 0
    SYMBOL voltage 48 80 R0
    WINDOW 3 -363 55 Left 2
    WINDOW 123 0 0 Left 0
    WINDOW 39 0 0 Left 0
    SYMATTR InstName V1
    SYMATTR Value PULSE(0 {v} 10n 1p 1p .1u .2u)
    SYMBOL res 256 48 R90
    WINDOW 0 0 56 VBottom 2
    WINDOW 3 32 56 VTop 2
    SYMATTR InstName R1
    SYMATTR Value 100
    SYMBOL cap 256 80 R0
    SYMATTR InstName C1
    SYMATTR Value 200p
    SYMBOL Digital\\buf 368 0 R0
    SYMATTR InstName A1
    TEXT -394 -48 Left 2 !.tran 0 40n 0 .1n
    TEXT -56 -96 Left 2 !.step param v list 0.79061 0.80014 0.81067 0.82231 0.83517 0.84939 0.86510 0.88246 0.90165 0.92286 0.94630 0.97221 1.00083 1.03247 1.06744 1.10608 1.14879 1.19599 1.24815 1.30580 1.36952 1.
    43993 1.51775 1.60375 1.69880 1.80385 1.91994 2.04824 2.19004 2.34675 2.51994


    That's a really clever idea

    One could perhaps instead use a variable cap?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to jlarkin@highlandsniptechnology.com on Mon Aug 15 00:46:15 2022
    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't matter, why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Sun Aug 14 15:08:36 2022
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    sřndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't matter, why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to jlarkin@highlandsniptechnology.com on Mon Aug 15 01:41:30 2022
    On 8/15/2022 1:08, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org: >>>>> It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng
    edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't matter, why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Monett VE3BTI@21:1/5 to spamme@not.com on Sun Aug 14 23:57:37 2022
    Mike Monett VE3BTI <spamme@not.com> wrote:

    I have zipped the original and uploaded it to Google Drive. Please
    download it at https://tinyurl.com/3x256eej and see if it runs better.

    It also runs fine if you replace the three spaces between the parameters with
    a single space.

    Something is seriously wrong with sending LTspice files to the newsgroup. We also run into problems with line wrap and ASC files.

    From now on, I will zip the files and upload them to Google Drive.


    --
    MRM

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to jla...@highlandsniptechnology.com on Sun Aug 14 18:08:51 2022
    On Monday, August 15, 2022 at 8:08:46 AM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:
    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    sĹłndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org: >>>> It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng
    edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't matter, why not a single variable voltage step into a filter, sorta like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"?
    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?

    Your original idea was that a trapezium would would be better than a sine wave. If you keep the slope of the sloped bits constant, you can stick to the same the low pass filter time constant to smooth out the steps in the stair-case approximation to the
    sloped segments.

    I just proposed a DAC based scheme for doing that.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to All on Mon Aug 15 12:54:56 2022
    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org: >>>>>> It strikes me that John Larkin's original idea of synthesising
    trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>> fed into your comparator would be made up of four sequential
    components - all coming out of the DAC - high segment of arbitrary >>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as
    16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't
    matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform >>>> to make a faster edge into a filter and comparator, to get better time >>>> resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time. It will probably mean adding memory of course. Obviously
    you know all that and this is what you a re trying to wrestle,
    I don't think there is a better way to do it though (better
    than adding memory so your update rate remains constant).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Mon Aug 15 07:17:44 2022
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>> <langwadt@fonz.dk> wrote:

    sřndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org: >>>>>>> It strikes me that John Larkin's original idea of synthesising
    trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>> fed into your comparator would be made up of four sequential
    components - all coming out of the DAC - high segment of arbitrary >>>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't
    matter, why not a single variable voltage step into a filter, sorta >>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform >>>>> to make a faster edge into a filter and comparator, to get better time >>>>> resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort >>>> of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to jla...@highlandsniptechnology.com on Mon Aug 15 08:25:22 2022
    On Tuesday, August 16, 2022 at 12:17:56 AM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com wrote: >On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:

    <snip>

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries.

    Only if you chose to do that way. You could rewrite the look-up table every time you changed the frequency.

    And an equally impossible DAC and comparator.

    So think it out again.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    What's difficult about that? It isn't as if there are any moving parts involved. The customer needs to tell you the frequency they want the machine to push out, and you need to be able to reconfigure it so that is the frequency which comes out.

    That could get interesting.

    Only if if you make life difficult for yourself by failing to tear up your original idea when it started looking half-baked.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Mon Aug 15 08:35:17 2022
    mandag den 15. august 2022 kl. 17.25.26 UTC+2 skrev bill....@ieee.org:
    On Tuesday, August 16, 2022 at 12:17:56 AM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com wrote:
    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    <snip>
    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries.
    Only if you chose to do that way. You could rewrite the look-up table every time you changed the frequency.
    And an equally impossible DAC and comparator.
    So think it out again.
    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts appear to be seamless.
    What's difficult about that? It isn't as if there are any moving parts involved. The customer needs to tell you the frequency they want the machine to push out, and you need to be able to reconfigure it so that is the frequency which comes out.

    but what happens when you change from one frequency to another?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to jla...@highlandsniptechnology.com on Mon Aug 15 09:26:16 2022
    On Monday, August 15, 2022 at 10:17:56 AM UTC-4, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>> wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>> <lang...@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>> fed into your comparator would be made up of four sequential
    components - all coming out of the DAC - high segment of arbitrary >>>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>> matter, why not a single variable voltage step into a filter, sorta >>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform >>>>> to make a faster edge into a filter and comparator, to get better time >>>>> resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort >>>> of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.
    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.

    A single, large lookup table is not the only way to generate a sine function.

    This is one of the problems with trying to brain storm a complex task rather than to research it and learn how the problem has been solved in the past.

    sin (a+b) = sin (a) * cos(b) + cos(a) * sin(b),

    where a and b are the msbs and lsbs of the phase counter.
    Because b is always very small, cos(b) is always very close to 1. sin(b) will always be small, so sin(a) is a reasonable approximation to that term. sin(b) * cos(a) can be a table lookup with less than the full value of a used. With two tables, the
    result can be calculated with a single addition. This was used in a very early device where memory was much more limited than today.

    Or if you are religious, and don't want to lose any precision, it is not hard to do the full precision math in an FPGA, still with much smaller look up tables.

    In a DDS, your result will still be limited by the size of your DAC, but 16 bits is not unreasonable.

    To avoid messiness at the changes, you can construct the DDS in an FPGA and handle the changes so that the octave change is made when the DDS is set to the slower of the two DDS settings.

    You can also stop the DDS, make all changes, then resume the DDS. If this is done within the FPGA, there will be no glitches. The octave counters can be reset during the process, eliminating any spurious pulse widths. The method that works best for a
    given frequency transition can be used. It doesn't need to be a one-size-fits-all approach.

    --

    Rick C.

    - Get 1,000 miles of free Supercharging
    - Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to lang...@fonz.dk on Mon Aug 15 09:27:58 2022
    On Monday, August 15, 2022 at 11:35:21 AM UTC-4, lang...@fonz.dk wrote:
    mandag den 15. august 2022 kl. 17.25.26 UTC+2 skrev bill....@ieee.org:
    On Tuesday, August 16, 2022 at 12:17:56 AM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com wrote:
    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    <snip>
    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That needs a sine lookup table with about 50 billion entries.
    Only if you chose to do that way. You could rewrite the look-up table every time you changed the frequency.
    And an equally impossible DAC and comparator.
    So think it out again.
    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts appear to be seamless.
    What's difficult about that? It isn't as if there are any moving parts involved. The customer needs to tell you the frequency they want the machine to push out, and you need to be able to reconfigure it so that is the frequency which comes out.
    but what happens when you change from one frequency to another?

    Uh, the output frequency changes?

    --

    Rick C.

    + Get 1,000 miles of free Supercharging
    + Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Mon Aug 15 10:06:55 2022
    On Mon, 15 Aug 2022 08:35:17 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    mandag den 15. august 2022 kl. 17.25.26 UTC+2 skrev bill....@ieee.org:
    On Tuesday, August 16, 2022 at 12:17:56 AM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com wrote:
    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    sřndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    <snip>
    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries.
    Only if you chose to do that way. You could rewrite the look-up table every time you changed the frequency.
    And an equally impossible DAC and comparator.
    So think it out again.
    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.
    What's difficult about that? It isn't as if there are any moving parts involved. The customer needs to tell you the frequency they want the machine to push out, and you need to be able to reconfigure it so that is the frequency which comes out.

    but what happens when you change from one frequency to another?



    There are dilemmas. What exactly do you do when the frequency was 1
    mHz, and you are 500 seconds from a trigger, and the user sets the
    rate to 10 Hz?

    How about the reverse?

    What do you do if the requested transition was from 1 Hz to 0.99 Hz?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to jla...@highlandsniptechnology.com on Mon Aug 15 10:18:47 2022
    On Monday, August 15, 2022 at 1:07:03 PM UTC-4, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 08:35:17 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    mandag den 15. august 2022 kl. 17.25.26 UTC+2 skrev bill....@ieee.org:
    On Tuesday, August 16, 2022 at 12:17:56 AM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com wrote:
    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    <snip>
    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries.
    Only if you chose to do that way. You could rewrite the look-up table every time you changed the frequency.
    And an equally impossible DAC and comparator.
    So think it out again.
    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.
    What's difficult about that? It isn't as if there are any moving parts involved. The customer needs to tell you the frequency they want the machine to push out, and you need to be able to reconfigure it so that is the frequency which comes out.

    but what happens when you change from one frequency to another?


    There are dilemmas. What exactly do you do when the frequency was 1
    mHz, and you are 500 seconds from a trigger, and the user sets the
    rate to 10 Hz?

    How about the reverse?

    What do you do if the requested transition was from 1 Hz to 0.99 Hz?

    I would always stop the pulse generation during the settings change. The changeover can happen in one clock cycle of your master clock, so the circuit will resume with very little delay. The filter will be the slow part of the whole thing. The worst
    case delay from frequency change will be one new period.

    Are you adding new requirements, that the delay between previous clock output and next clock output must always be within the range of the two settings? If so, then the actual change should be triggered off the output clock. It would result in a delay
    until the change of up to one old clock period.

    Have you asked your customer how they would like for these cases to be handled?

    --

    Rick C.

    -- Get 1,000 miles of free Supercharging
    -- Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Ricky on Mon Aug 15 10:44:44 2022
    On Monday, August 15, 2022 at 1:18:51 PM UTC-4, Ricky wrote:
    On Monday, August 15, 2022 at 1:07:03 PM UTC-4, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 08:35:17 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    mandag den 15. august 2022 kl. 17.25.26 UTC+2 skrev bill....@ieee.org:
    On Tuesday, August 16, 2022 at 12:17:56 AM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com wrote:
    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    <snip>
    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That >> > needs a sine lookup table with about 50 billion entries.
    Only if you chose to do that way. You could rewrite the look-up table every time you changed the frequency.
    And an equally impossible DAC and comparator.
    So think it out again.
    We'll probably wind up synthesizing the high range, an octave or so, >> > and divide down as needed. The trick will be to make the gear shifts >> > appear to be seamless.
    What's difficult about that? It isn't as if there are any moving parts involved. The customer needs to tell you the frequency they want the machine to push out, and you need to be able to reconfigure it so that is the frequency which comes out.

    but what happens when you change from one frequency to another?


    There are dilemmas. What exactly do you do when the frequency was 1
    mHz, and you are 500 seconds from a trigger, and the user sets the
    rate to 10 Hz?

    How about the reverse?

    What do you do if the requested transition was from 1 Hz to 0.99 Hz?
    I would always stop the pulse generation during the settings change. The changeover can happen in one clock cycle of your master clock, so the circuit will resume with very little delay. The filter will be the slow part of the whole thing. The worst
    case delay from frequency change will be one new period.

    Are you adding new requirements, that the delay between previous clock output and next clock output must always be within the range of the two settings? If so, then the actual change should be triggered off the output clock. It would result in a delay
    until the change of up to one old clock period.

    Have you asked your customer how they would like for these cases to be handled?

    Actually, this is an easy one to solve. I was picturing a fixed counter and selecting taps. But instead, use a programmable counter which is reset to zero and counts up to a threshold. If you change the threshold to a larger value, the counter
    continues counting up until the new threshold. If you change the threshold to a lower value, the counter will either continue counting up to the new threshold, or if it has already been passed, immediately reset and generate a clock edge.

    This combination of a DDS and a programmable divider can give very good results as shown in many applications.

    --

    Rick C.

    -+ Get 1,000 miles of free Supercharging
    -+ Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to jlarkin@highlandsniptechnology.com on Mon Aug 15 22:42:11 2022
    On 8/15/2022 17:17, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>>> <langwadt@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org: >>>>>>>> It strikes me that John Larkin's original idea of synthesising >>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>>> fed into your comparator would be made up of four sequential
    components - all coming out of the DAC - high segment of arbitrary >>>>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't
    matter, why not a single variable voltage step into a filter, sorta >>>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform >>>>>> to make a faster edge into a filter and comparator, to get better time >>>>>> resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort >>>>> of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table.
    If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something
    more than that - which I haven't got yet.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Mon Aug 15 12:56:15 2022
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:
    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>> wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>>> <lang...@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>>> fed into your comparator would be made up of four sequential >>>>>>>> components - all coming out of the DAC - high segment of arbitrary >>>>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>> matter, why not a single variable voltage step into a filter, sorta >>>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort >>>>> of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts appear to be seamless.

    That could get interesting.

    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to Lasse Langwadt Christensen on Tue Aug 16 00:03:13 2022
    On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:
    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>>>> wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>>>>> <lang...@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>>>>> fed into your comparator would be made up of four sequential >>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary >>>>>>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>> matter, why not a single variable voltage step into a filter, sorta >>>>>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform >>>>>>>> to make a faster edge into a filter and comparator, to get better time >>>>>>>> resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort >>>>>>> of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.

    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M


    I don't understand what a neat frequency is, either. Any periodic
    waveform at 1 MHz (the worst case) at 100 Msps update rate takes
    a 100 entry table.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to Dimiter Popoff on Mon Aug 15 16:45:18 2022
    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote:
    On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:

    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic
    waveform at 1 MHz (the worst case) at 100 Msps update rate takes
    a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table?
    And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table size, and the 'update rate' might not be fine-adjustable enough. In contrast to a variable-LC tuning scheme, digital synthesis tables require... an exercise in ratios of integers to approximate a real number.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to All on Tue Aug 16 03:13:46 2022
    On 8/16/2022 2:45, whit3rd wrote:
    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote:
    On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:

    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic
    waveform at 1 MHz (the worst case) at 100 Msps update rate takes
    a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table?
    And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.


    No, of course not :-). Of course it will take some "oversampling" etc.,
    but it is still trivial.
    All it takes is say (for simplicity) a 2^16 long waveform lookup table,
    a factor being the quotient period/max. period normalized such that
    adding it to a sum each sample the sum it will be the offset to the
    next table entry to take. Obviously the sum is kept anded to $ffff
    and is never altered by other means; if we want to change the output
    frequency we only recalculate the quotient and keep adding.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Mon Aug 15 17:23:53 2022
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote:
    On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:

    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic
    waveform at 1 MHz (the worst case) at 100 Msps update rate takes
    a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table?
    And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table >size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load
    N.

    The sine lookup table is addressed by some number of MSBs of the phase accumulator, 10 to 16 typically. It doesn't change in a given system.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Mon Aug 15 19:26:28 2022
    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 17:17, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>>>> <langwadt@fonz.dk> wrote:

    sřndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org: >>>>>>>>> It strikes me that John Larkin's original idea of synthesising >>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>>>> fed into your comparator would be made up of four sequential >>>>>>>>> components - all coming out of the DAC - high segment of arbitrary >>>>>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>> matter, why not a single variable voltage step into a filter, sorta >>>>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform >>>>>>> to make a faster edge into a filter and comparator, to get better time >>>>>>> resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort >>>>>> of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table.
    If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something
    more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes
    frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to jla...@highlandsniptechnology.com on Mon Aug 15 21:47:58 2022
    On Tuesday, August 16, 2022 at 12:26:40 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com>> wrote:
    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>>>> <lang...@fonz.dk> wrote:
    sĹłndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:

    <snip>

    I just want a programmable-frequency trigger generator that changes frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    The period difference between 15 MHz and 14,999,999.999 Hz is 4.44E-15 seconds.

    That would be demanding. 0.1% frequency setability should be impressive enough, and that would only demand a 70 psec increment in period at 15MHz.

    You could get that out of an MC 100EP195

    https://www.onsemi.com/pdf/datasheet/mc100ep195-d.pdf

    John Larkin needs to start thinking about what his specifications mean.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to jlarkin@highlandsniptechnology.com on Tue Aug 16 05:36:30 2022
    On a sunny day (Mon, 15 Aug 2022 19:26:28 -0700) it happened jlarkin@highlandsniptechnology.com wrote in <npvlfhtkcnupjs4ndt8petfffkqkjghi7b@4ax.com>:

    I just want a programmable-frequency trigger generator that changes
    frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    Well the antique way would be to mix 2 carriers.
    Say 100 MHz and 100 MHz mix and low pass the differnce.
    Now FM modulate one, from 100 MHz down to 90 MHz.
    (100 MHz just for example)
    Kids stuff.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to jlarkin@highlandsniptechnology.com on Tue Aug 16 14:03:48 2022
    On 8/16/2022 5:26, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 17:17, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>>>> wrote:

    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>>>>> <langwadt@fonz.dk> wrote:

    søndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>>>>> fed into your comparator would be made up of four sequential >>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary >>>>>>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>> matter, why not a single variable voltage step into a filter, sorta >>>>>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform >>>>>>>> to make a faster edge into a filter and comparator, to get better time >>>>>>>> resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort >>>>>>> of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table.
    If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something
    more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes
    frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.


    Now I get it. I had misread mHz as MHz.... :D.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Tue Aug 16 06:02:53 2022
    tirsdag den 16. august 2022 kl. 04.26.40 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>>> wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>>>> <lang...@fonz.dk> wrote:

    sĹłndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>>>> fed into your comparator would be made up of four sequential >>>>>>>>> components - all coming out of the DAC - high segment of arbitrary >>>>>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>> matter, why not a single variable voltage step into a filter, sorta >>>>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table.
    If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something
    more than that - which I haven't got yet.
    I just want a programmable-frequency trigger generator that changes frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    add a frequency dependent gain and clamp to the sine to keep a reasonable slew rate?

    possibly to the triangular wave input to the lookup table so you get sine edges with flat tops

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to John Larkin on Tue Aug 16 15:44:27 2022
    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote:
    On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:

    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic
    waveform at 1 MHz (the worst case) at 100 Msps update rate takes
    a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table?
    And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table >> size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load
    N.

    The sine lookup table is addressed by some number of MSBs of the phase accumulator, 10 to 16 typically. It doesn't change in a given system.




    Perhaps you could shorten the lookup table to some manageable size if
    you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Tue Aug 16 07:02:52 2022
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote:
    On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:

    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>>> wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic
    waveform at 1 MHz (the worst case) at 100 Msps update rate takes
    a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table?
    And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table >>> size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load
    N.

    The sine lookup table is addressed by some number of MSBs of the phase
    accumulator, 10 to 16 typically. It doesn't change in a given system.




    Perhaps you could shorten the lookup table to some manageable size if
    you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1,
    so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the
    phase accumulator. A group of MS bits becomes the gate for a cluster
    of LS bits. Envision a spinner dial that mostly parks at 0 degrees and
    once in a while makes a single fast rotation. That essentially puts a
    divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Tue Aug 16 09:49:10 2022
    tirsdag den 16. august 2022 kl. 16.03.01 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:
    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote: >>>> On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:

    I still don't understand what you are trying to do. Periodic sine >>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>>> wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic
    waveform at 1 MHz (the worst case) at 100 Msps update rate takes
    a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table?
    And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table
    size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load
    N.

    The sine lookup table is addressed by some number of MSBs of the phase
    accumulator, 10 to 16 typically. It doesn't change in a given system.




    Perhaps you could shorten the lookup table to some manageable size if
    you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.
    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1,
    so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the
    phase accumulator. A group of MS bits becomes the gate for a cluster
    of LS bits. Envision a spinner dial that mostly parks at 0 degrees and
    once in a while makes a single fast rotation. That essentially puts a
    divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.


    take you favorite programming language (or a spreadsheet) make a textfile
    with two columns time and value, a voltage source can load that as a pwl file

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to jlarkin@highlandsniptechnology.com on Tue Aug 16 19:51:04 2022
    On 8/16/2022 17:02, jlarkin@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote: >>>>> On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:

    I still don't understand what you are trying to do. Periodic sine >>>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>>>> wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic
    waveform at 1 MHz (the worst case) at 100 Msps update rate takes
    a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table?
    And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table >>>> size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load
    N.

    The sine lookup table is addressed by some number of MSBs of the phase
    accumulator, 10 to 16 typically. It doesn't change in a given system.




    Perhaps you could shorten the lookup table to some manageable size if
    you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1,
    so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the
    phase accumulator. A group of MS bits becomes the gate for a cluster
    of LS bits. Envision a spinner dial that mostly parks at 0 degrees and
    once in a while makes a single fast rotation. That essentially puts a
    divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.




    But if this is to be used as a trigger (similar to the sweep trigger
    on a scope, level knob etc.) can't you just do triangular instead of
    sine wave? Should even be better for that purpose - and no need for a
    lookup table at all...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Tue Aug 16 10:13:43 2022
    On Tue, 16 Aug 2022 19:51:04 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/16/2022 17:02, jlarkin@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote: >>>>>> On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff: >>>>>
    I still don't understand what you are trying to do. Periodic sine >>>>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>>>>> wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic
    waveform at 1 MHz (the worst case) at 100 Msps update rate takes
    a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table? >>>>> And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table
    size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load
    N.

    The sine lookup table is addressed by some number of MSBs of the phase >>>> accumulator, 10 to 16 typically. It doesn't change in a given system.




    Perhaps you could shorten the lookup table to some manageable size if
    you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1,
    so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the
    phase accumulator. A group of MS bits becomes the gate for a cluster
    of LS bits. Envision a spinner dial that mostly parks at 0 degrees and
    once in a while makes a single fast rotation. That essentially puts a
    divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.




    But if this is to be used as a trigger (similar to the sweep trigger
    on a scope, level knob etc.) can't you just do triangular instead of
    sine wave? Should even be better for that purpose - and no need for a
    lookup table at all...

    That has been considered. But Claude Shannon is the evil stepmother
    lurking and plotting to keep us from living happily after.

    The sampling frequency is async to the trigger rate that we want, so
    is a source of jitter. A triangle is not bandlimited to below the
    Nyquist rate, and we can't afford an ideal lowpass filter either.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to jla...@highlandsniptechnology.com on Tue Aug 16 10:34:05 2022
    On Tuesday, August 16, 2022 at 7:03:01 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:
    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote: >>>> On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:

    I still don't understand what you are trying to do. Periodic sine >>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>>> wave lookup table for the slowest case.

    The small-integer ratios for a given frequency don't support a fixed table
    size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load
    N.

    The sine lookup table is addressed by some number of MSBs of the phase
    accumulator, 10 to 16 typically. It doesn't change in a given system.

    Perhaps you could shorten the lookup table to some manageable size if
    you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1,
    so we can easily do 64K points of 16 bit data.

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table. Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase accumulator' is for, estimating the 'b'?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to All on Tue Aug 16 13:46:32 2022
    On Mon, 15 Aug 2022 19:26:28 -0700, jlarkin@highlandsniptechnology.com
    wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 17:17, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>>>> wrote:

    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>>>>> <langwadt@fonz.dk> wrote:

    sřndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>>>>> fed into your comparator would be made up of four sequential >>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary >>>>>>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>> matter, why not a single variable voltage step into a filter, sorta >>>>>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform >>>>>>>> to make a faster edge into a filter and comparator, to get better time >>>>>>>> resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort >>>>>>> of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table.
    If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something
    more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes
    frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit accumulators can do just this, with phase continuity between the two frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary:
    table-lookup and CORDIC being very common approaches.

    Perhaps it's time to bring the various discussion threads together and
    re-focus by restating the problem to be solved.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Tue Aug 16 11:32:12 2022
    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joegwinn@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jlarkin@highlandsniptechnology.com
    wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 17:17, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>>>>> wrote:

    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote: >>>>>>>>> On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>>>>>> <langwadt@fonz.dk> wrote:

    sřndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>>>>>> fed into your comparator would be made up of four sequential >>>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary >>>>>>>>>>> length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>>> matter, why not a single variable voltage step into a filter, sorta >>>>>>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort >>>>>>>> of "the larger the step the less low pass I want applied to it"? >>>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table. >>>If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >>>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes >>frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit >accumulators can do just this, with phase continuity between the two >frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary:
    table-lookup and CORDIC being very common approaches.


    One problem is that, at low frequencies, the LSB of that 10 to 14 bits
    changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter

    Perhaps it's time to bring the various discussion threads together and >re-focus by restating the problem to be solved.

    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    It's an interesting problem.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Tue Aug 16 11:50:57 2022
    tirsdag den 16. august 2022 kl. 19.46.45 UTC+2 skrev Joe Gwinn:
    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com
    wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com> >wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>> wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>>>> wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote: >>>>>>>> On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    sĹłndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential >>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge >>>>>>>>>>
    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>> matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly >>>>>> through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies >>>>> is perhaps to have two DACs, one of them making the output filter >>>>> programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by >>operator action you have milliseconds of time to recalculate the table. >>If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes >frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.
    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit accumulators can do just this, with phase continuity between the two frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary:
    table-lookup and CORDIC being very common approaches.

    Perhaps it's time to bring the various discussion threads together and re-focus by restating the problem to be solved.

    https://imgur.com/GwZ2q8A

    stepping through a sine table at F and 8*F
    much exaggerated by short sine table and low resolution

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Tue Aug 16 12:05:23 2022
    tirsdag den 16. august 2022 kl. 20.32.22 UTC+2 skrev John Larkin:
    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joeg...@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com >wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>> wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote: >>>>>>>>> On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    sĹłndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential >>>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge >>>>>>>>>>>
    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>>> matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >>>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly >>>>>>> through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies >>>>>> is perhaps to have two DACs, one of them making the output filter >>>>>> programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure >>>>>> it is practical, not only because it is complex but also because >>>>>> I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That >>>> needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so, >>>> and divide down as needed. The trick will be to make the gear shifts >>>> appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>wave lookup table for the slowest case. If you want to switch by >>>operator action you have milliseconds of time to recalculate the table. >>>If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >>>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes >>frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other >>words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit >accumulators can do just this, with phase continuity between the two >frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary: >table-lookup and CORDIC being very common approaches.

    One problem is that, at low frequencies, the LSB of that 10 to 14 bits changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter
    Perhaps it's time to bring the various discussion threads together and >re-focus by restating the problem to be solved.
    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    It's an interesting problem.

    https://imgur.com/6KqpCW9

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Joe Gwinn on Tue Aug 16 18:12:13 2022
    On Tuesday, August 16, 2022 at 1:46:45 PM UTC-4, Joe Gwinn wrote:
    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com
    wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com> >wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>> wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>>>> wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote: >>>>>>>> On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    sĹłndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential >>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge >>>>>>>>>>
    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>> matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly >>>>>> through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies >>>>> is perhaps to have two DACs, one of them making the output filter >>>>> programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by >>operator action you have milliseconds of time to recalculate the table. >>If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes >frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.
    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit accumulators can do just this, with phase continuity between the two frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary:
    table-lookup and CORDIC being very common approaches.

    Perhaps it's time to bring the various discussion threads together and re-focus by restating the problem to be solved.

    Or maybe someone could just read how it has been done for over a decade. This is all well traveled ground. I see people now repeating things I said days ago.

    The DDS should be designed to generate a top frequency over a 2:1 range. This is easy stuff, with good accuracy and very low jitter if properly designed (use of a long phase word).

    A programmable divider then divides by 2**N by counting up to the set value.

    A final FF buffer register of your favorite technology will provide the actual pulse output with an appropriate jitter.

    These two units can both be changed on a single clock cycle by writing to a buffer register and updating the actual operational registers simultaneously on a cue. The DDS will continue from the present phase, so will produce one clock pulse that is an
    intermediate period. The programmable divider will continue from the current count, either triggering right away, or continuing to count from the present value. Either way it will always produce an output pulse that is within the range of the two
    settings, the prior setting and the new setting.

    --

    Rick C.

    +- Get 1,000 miles of free Supercharging
    +- Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to John Larkin on Tue Aug 16 18:50:39 2022
    On Wednesday, August 17, 2022 at 4:32:22 AM UTC+10, John Larkin wrote:
    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joeg...@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com >wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>> wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote: >>>>>>>>> On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    sĹłndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential >>>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge >>>>>>>>>>>
    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>>> matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >>>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly >>>>>>> through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies >>>>>> is perhaps to have two DACs, one of them making the output filter >>>>>> programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure >>>>>> it is practical, not only because it is complex but also because >>>>>> I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That >>>> needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so, >>>> and divide down as needed. The trick will be to make the gear shifts >>>> appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>wave lookup table for the slowest case. If you want to switch by >>>operator action you have milliseconds of time to recalculate the table. >>>If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >>>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes >>frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other >>words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit >accumulators can do just this, with phase continuity between the two >frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary: >table-lookup and CORDIC being very common approaches.

    One problem is that, at low frequencies, the LSB of that 10 to 14 bits changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter.

    But you can solve that by synthesising a trapezium wave rather than a sine wave, and sticking to a constant slope for the sloped bits of the trapezium wave.

    Perhaps it's time to bring the various discussion threads together and re-focus by restating the problem to be solved.

    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    Not to mention motherhood and apple pie.

    A trigger clock that is always right can never be reprogrammed, because it's going to be wrong until the newly programmed frequency has been established,

    You don't want to think about what you are asking for.

    It's an interesting problem.

    In the same sense as the sound of one hand clapping.
    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Tue Aug 16 20:12:22 2022
    On Tue, 16 Aug 2022 11:50:57 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    tirsdag den 16. august 2022 kl. 19.46.45 UTC+2 skrev Joe Gwinn:
    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com
    wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> >> >>>>>> wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    s?ndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising
    trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential
    components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >> >>>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't
    matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table.
    If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something
    more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes
    frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.
    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit
    accumulators can do just this, with phase continuity between the two
    frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary:
    table-lookup and CORDIC being very common approaches.

    Perhaps it's time to bring the various discussion threads together and
    re-focus by restating the problem to be solved.

    https://imgur.com/GwZ2q8A

    stepping through a sine table at F and 8*F
    much exaggerated by short sine table and low resolution




    One could think of clusters of bits as harmonic terms in a Fourier
    series. A bit of grouping and scaling and adding could reshape a sine
    into something more square. That's hard to think about too.

    Bummer is, a DDS doesn't generally step one tick at a time. In fact,
    it's a mess.

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    and it's very different at low frequencies.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to jla...@highlandsniptechnology.com on Tue Aug 16 22:03:45 2022
    On Wednesday, August 17, 2022 at 1:12:32 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 11:50:57 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    tirsdag den 16. august 2022 kl. 19.46.45 UTC+2 skrev Joe Gwinn:
    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    <snip>
    s?ndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:

    One could think of clusters of bits as harmonic terms in a Fourier
    series. A bit of grouping and scaling and adding could reshape a sine
    into something more square. That's hard to think about too.

    What puzzles me is how John Larkin finds customers dumb enough to be impressed by this kind of meaningless twaddle.

    Bummer is, a DDS doesn't generally step one tick at a time. In fact, it's a mess.

    A DDS doesn't generate ticks. It generates a staircase approximations to sine waves. John Larkin's mode of thinking about what's going on is definitely a mess.

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    and it's very different at low frequencies.

    The treads on the staircase are very close together - with 14-bit DAC there are 16,384 of them - and each one can sit there for a while.

    So what?

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jasen Betts@21:1/5 to whit3rd@gmail.com on Wed Aug 17 06:44:18 2022
    On 2022-08-16, whit3rd <whit3rd@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table. Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    --
    Jasen.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to usenet@revmaps.no-ip.org on Wed Aug 17 06:58:23 2022
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts <usenet@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whit3rd@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table. >> Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase >> accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to jla...@highlandsniptechnology.com on Wed Aug 17 07:48:20 2022
    On Wednesday, August 17, 2022 at 11:58:31 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table. >> Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase >> accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table resolution.

    It's always the limit.Getting the numbers precise enough to fully exploit the DAC you've got is just putting enough digital hardware together to get long enough words. It may not be trivial, but it's always do-able.

    Using the DAC sensibly to solve the problem that you've got doesn't seem to be trivial either.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to jlarkin@highland_atwork_technology. on Wed Aug 17 13:02:37 2022
    On Tue, 16 Aug 2022 11:32:12 -0700, John Larkin <jlarkin@highland_atwork_technology.com> wrote:

    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joegwinn@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jlarkin@highlandsniptechnology.com >>wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>wrote:

    On 8/15/2022 17:17, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jlarkin@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>>>>>> wrote:

    On 8/14/2022 17:14, jlarkin@highlandsniptechnology.com wrote: >>>>>>>>>> On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen >>>>>>>>>> <langwadt@fonz.dk> wrote:

    sřndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you >>>>>>>>>>>> fed into your comparator would be made up of four sequential >>>>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary >>>>>>>>>>>> length, a falling edge, a low segment, and a risng edge >>>>>>>>>>>>
    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as >>>>>>>>>>>> 16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>>>> matter, why not a single variable voltage step into a filter, sorta >>>>>>>>>>> like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >>>>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly >>>>>>>> through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies >>>>>>> is perhaps to have two DACs, one of them making the output filter >>>>>>> programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because >>>>>>> I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That >>>>> needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so, >>>>> and divide down as needed. The trick will be to make the gear shifts >>>>> appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by >>>>operator action you have milliseconds of time to recalculate the table. >>>>If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >>>>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes >>>frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit >>accumulators can do just this, with phase continuity between the two >>frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary: >>table-lookup and CORDIC being very common approaches.


    One problem is that, at low frequencies, the LSB of that 10 to 14 bits >changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter

    Perhaps it's time to bring the various discussion threads together and >>re-focus by restating the problem to be solved.

    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    It's an interesting problem.

    If all you want to do is to generate a trigger at any frequency from
    10^-3 Hz to 15*10^6 Hz in 10^-3 Hz steps, that is easily done in a
    phase-only DDS topology (no trig conversion needed), which can be
    implemented directly in a FPGA.

    This is also known as a Numerically Controlled Oscillator:

    .<https://en.wikipedia.org/wiki/Numerically-controlled_oscillator>

    Our output would be point /M in Figure 1 in the above Wiki article.
    (Never mind that M is actually a bit width in that figure.)

    How big must the accumulator be? 15*10^6/10^-3 = 15*10^9 possible
    frequencies. Log2[ 15*10^9 ] = 33.8 bits. There was also talk of
    needing 50^10^9 steps, which would be 35.5 bits, minimum. In either
    case, a 48-bit accumulator will work with room to spare.

    If not, simply make the accumulator larger - 64 bits is also common.
    One can also choose the clock rate for convenience given the chosen
    accumulator length.

    The trigger signal is when the accumulator rolls over. If the
    Frequency Control Word is small, this will take some time. If large,
    much faster.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Wed Aug 17 11:15:06 2022
    onsdag den 17. august 2022 kl. 19.02.50 UTC+2 skrev Joe Gwinn:
    On Tue, 16 Aug 2022 11:32:12 -0700, John Larkin <jlarkin@highland_atwork_technology.com> wrote:

    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joeg...@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com >>wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>>> wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote: >>>>>>>>>> On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    sĹłndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential >>>>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge >>>>>>>>>>>>
    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as
    16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>>>> matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >>>>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly >>>>>>>> through the waveform lookup table and a fixed filter doesn't >>>>>>>> interpolate waveform steps any more; it settles every step. >>>>>>>>
    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem, >>>>>>> likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies >>>>>>> is perhaps to have two DACs, one of them making the output filter >>>>>>> programmable so you can dynamically change it, based on step, >>>>>>> with some preemption etc., you get the idea - and I am not sure >>>>>>> it is practical, not only because it is complex but also because >>>>>>> I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the >>>>>> time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That >>>>> needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so, >>>>> and divide down as needed. The trick will be to make the gear shifts >>>>> appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine >>>>wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>wave lookup table for the slowest case. If you want to switch by >>>>operator action you have milliseconds of time to recalculate the table. >>>>If you want to switch by some external gating you only need two >>>>tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >>>>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes >>>frequency on demand and doesn't stop for reprogramming and doesn't >>>blow up someone's laser by generating any goofy triggers. In other >>>words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit >>accumulators can do just this, with phase continuity between the two >>frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary: >>table-lookup and CORDIC being very common approaches.


    One problem is that, at low frequencies, the LSB of that 10 to 14 bits >changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter

    Perhaps it's time to bring the various discussion threads together and >>re-focus by restating the problem to be solved.

    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    It's an interesting problem.
    If all you want to do is to generate a trigger at any frequency from
    10^-3 Hz to 15*10^6 Hz in 10^-3 Hz steps, that is easily done in a phase-only DDS topology (no trig conversion needed), which can be implemented directly in a FPGA.

    This is also known as a Numerically Controlled Oscillator:

    .<https://en.wikipedia.org/wiki/Numerically-controlled_oscillator>

    Our output would be point /M in Figure 1 in the above Wiki article.
    (Never mind that M is actually a bit width in that figure.)

    How big must the accumulator be? 15*10^6/10^-3 = 15*10^9 possible frequencies. Log2[ 15*10^9 ] = 33.8 bits. There was also talk of
    needing 50^10^9 steps, which would be 35.5 bits, minimum. In either
    case, a 48-bit accumulator will work with room to spare.

    If not, simply make the accumulator larger - 64 bits is also common.
    One can also choose the clock rate for convenience given the chosen accumulator length.

    The trigger signal is when the accumulator rolls over. If the

    did you miss the whole discussion?

    doing that with say a 100MHz clock give you 10ns jitter, which might be ok low frequency, but terrible at 15MHz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Wed Aug 17 12:07:09 2022
    On Wed, 17 Aug 2022 11:15:06 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    onsdag den 17. august 2022 kl. 19.02.50 UTC+2 skrev Joe Gwinn:
    On Tue, 16 Aug 2022 11:32:12 -0700, John Larkin
    <jlarkin@highland_atwork_technology.com> wrote:

    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joeg...@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com
    wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> >> >>>>> wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    s?ndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >> >>>>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential
    components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as
    16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >> >>>>>>>>>>> matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >> >>>>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That >> >>>>> needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so, >> >>>>> and divide down as needed. The trick will be to make the gear shifts >> >>>>> appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table. >> >>>>If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something
    more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes
    frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit
    accumulators can do just this, with phase continuity between the two
    frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary:
    table-lookup and CORDIC being very common approaches.


    One problem is that, at low frequencies, the LSB of that 10 to 14 bits
    changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter

    Perhaps it's time to bring the various discussion threads together and
    re-focus by restating the problem to be solved.

    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    It's an interesting problem.
    If all you want to do is to generate a trigger at any frequency from
    10^-3 Hz to 15*10^6 Hz in 10^-3 Hz steps, that is easily done in a
    phase-only DDS topology (no trig conversion needed), which can be
    implemented directly in a FPGA.

    This is also known as a Numerically Controlled Oscillator:

    .<https://en.wikipedia.org/wiki/Numerically-controlled_oscillator>

    Our output would be point /M in Figure 1 in the above Wiki article.
    (Never mind that M is actually a bit width in that figure.)

    How big must the accumulator be? 15*10^6/10^-3 = 15*10^9 possible
    frequencies. Log2[ 15*10^9 ] = 33.8 bits. There was also talk of
    needing 50^10^9 steps, which would be 35.5 bits, minimum. In either
    case, a 48-bit accumulator will work with room to spare.

    If not, simply make the accumulator larger - 64 bits is also common.
    One can also choose the clock rate for convenience given the chosen
    accumulator length.

    The trigger signal is when the accumulator rolls over. If the

    did you miss the whole discussion?

    doing that with say a 100MHz clock give you 10ns jitter, which might be ok low frequency, but terrible at 15MHz



    The lowpass filter, between the DAC and the comparator, smooths the
    samples and reduces the jitter to picoseconds.

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    The real jitter problem is at low frequencies where the filter doesn't
    help much.

    I was doodling a lowpass filter that is sort of adaptive, to help the
    low-end jitter. Mr Shannon was a nice guy, but we aren't trying to
    reproduce a signal, we just want to make a clock.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Wed Aug 17 14:03:36 2022
    onsdag den 17. august 2022 kl. 21.07.20 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Wed, 17 Aug 2022 11:15:06 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    onsdag den 17. august 2022 kl. 19.02.50 UTC+2 skrev Joe Gwinn:
    On Tue, 16 Aug 2022 11:32:12 -0700, John Larkin
    <jlarkin@highland_atwork_technology.com> wrote:

    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joeg...@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com
    wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com> >> >>>wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    s?ndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising
    trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential >> >>>>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as
    16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't
    matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >> >>>>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly >> >>>>>>>> through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies >> >>>>>>> is perhaps to have two DACs, one of them making the output filter >> >>>>>>> programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because >> >>>>>>> I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That >> >>>>> needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so, >> >>>>> and divide down as needed. The trick will be to make the gear shifts >> >>>>> appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table.
    If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >> >>>>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes
    frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit
    accumulators can do just this, with phase continuity between the two
    frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary:
    table-lookup and CORDIC being very common approaches.


    One problem is that, at low frequencies, the LSB of that 10 to 14 bits
    changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter

    Perhaps it's time to bring the various discussion threads together and >> >>re-focus by restating the problem to be solved.

    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    It's an interesting problem.
    If all you want to do is to generate a trigger at any frequency from
    10^-3 Hz to 15*10^6 Hz in 10^-3 Hz steps, that is easily done in a
    phase-only DDS topology (no trig conversion needed), which can be
    implemented directly in a FPGA.

    This is also known as a Numerically Controlled Oscillator:

    .<https://en.wikipedia.org/wiki/Numerically-controlled_oscillator>

    Our output would be point /M in Figure 1 in the above Wiki article.
    (Never mind that M is actually a bit width in that figure.)

    How big must the accumulator be? 15*10^6/10^-3 = 15*10^9 possible
    frequencies. Log2[ 15*10^9 ] = 33.8 bits. There was also talk of
    needing 50^10^9 steps, which would be 35.5 bits, minimum. In either
    case, a 48-bit accumulator will work with room to spare.

    If not, simply make the accumulator larger - 64 bits is also common.
    One can also choose the clock rate for convenience given the chosen
    accumulator length.

    The trigger signal is when the accumulator rolls over. If the

    did you miss the whole discussion?

    doing that with say a 100MHz clock give you 10ns jitter, which might be ok low frequency, but terrible at 15MHz


    The lowpass filter, between the DAC and the comparator, smooths the
    samples and reduces the jitter to picoseconds.

    sure but not if you make the square wave directly from the MSB of the accumulator with no DAC

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    The real jitter problem is at low frequencies where the filter doesn't
    help much.

    you could also question how much 10ns of jitter matters on a 1Hz signal, it's 10ppb
    how accurate is the oscillator over a second?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to jla...@highlandsniptechnology.com on Wed Aug 17 13:26:53 2022
    On Wednesday, August 17, 2022 at 12:07:20 PM UTC-7, jla...@highlandsniptechnology.com wrote:

    The real jitter problem is at low frequencies where the filter doesn't
    help much.

    I was doodling a lowpass filter that is sort of adaptive, to help the
    low-end jitter.

    By 'doodling', I trust you mean that the tracking filter isn't looking
    like a good solution.

    Mr Shannon was a nice guy, but we aren't trying to
    reproduce a signal, we just want to make a clock.

    Oh, no, you already HAVE a clock, what you want is a derived infinitely-adjustable variable clock based on that digital clock source.

    An easy way, is to use integer-ratio phase locking to
    the master clock to generate a digitally adjustable clock#2,
    for coarse adjustments, and use a sinewave variable oscillator
    (yeah, LC and varactor or moving parts) which can be metered by the master clock
    and fine-adjusted, then with a diode mixer combine the two.

    One discrete-time oscillator and one infinitely-adjustable oscillator, and a mixer.
    Follow up with an IF-style filter to make sinewaves, then amplifier to make 'em square.
    'Tracking filter' functionality is exactly the LC oscillator feature that a totally digital
    system is missing, and gives you the ability to fill in the gaps in an N/M synthesis.

    Mr. Shannon assures us that there will be jitter, as does quantum mechanics, and
    thermodynamics. Making it small enough is your only option; frequency, for instance,
    is UNDEFINED mathematically, except for long time scales (it isn't just warmup time
    that makes a precise frequency measurement of long duration).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to All on Wed Aug 17 17:36:27 2022
    On Wed, 17 Aug 2022 12:07:09 -0700, jlarkin@highlandsniptechnology.com
    wrote:

    On Wed, 17 Aug 2022 11:15:06 -0700 (PDT), Lasse Langwadt Christensen ><langwadt@fonz.dk> wrote:

    onsdag den 17. august 2022 kl. 19.02.50 UTC+2 skrev Joe Gwinn:
    On Tue, 16 Aug 2022 11:32:12 -0700, John Larkin
    <jlarkin@highland_atwork_technology.com> wrote:

    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joeg...@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com
    wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>> >>>wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>> >>>>> wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    s?ndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>> >>>>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential >>> >>>>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as
    16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>> >>>>>>>>>>> matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >>> >>>>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly >>> >>>>>>>> through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies >>> >>>>>>> is perhaps to have two DACs, one of them making the output filter >>> >>>>>>> programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure
    it is practical, not only because it is complex but also because >>> >>>>>>> I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the
    time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That >>> >>>>> needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so, >>> >>>>> and divide down as needed. The trick will be to make the gear shifts >>> >>>>> appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table. >>> >>>>If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >>> >>>>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes
    frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit
    accumulators can do just this, with phase continuity between the two
    frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary:
    table-lookup and CORDIC being very common approaches.


    One problem is that, at low frequencies, the LSB of that 10 to 14 bits
    changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter

    Perhaps it's time to bring the various discussion threads together and >>> >>re-focus by restating the problem to be solved.

    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    It's an interesting problem.
    If all you want to do is to generate a trigger at any frequency from
    10^-3 Hz to 15*10^6 Hz in 10^-3 Hz steps, that is easily done in a
    phase-only DDS topology (no trig conversion needed), which can be
    implemented directly in a FPGA.

    This is also known as a Numerically Controlled Oscillator:

    .<https://en.wikipedia.org/wiki/Numerically-controlled_oscillator>

    Our output would be point /M in Figure 1 in the above Wiki article.
    (Never mind that M is actually a bit width in that figure.)

    How big must the accumulator be? 15*10^6/10^-3 = 15*10^9 possible
    frequencies. Log2[ 15*10^9 ] = 33.8 bits. There was also talk of
    needing 50^10^9 steps, which would be 35.5 bits, minimum. In either
    case, a 48-bit accumulator will work with room to spare.

    If not, simply make the accumulator larger - 64 bits is also common.
    One can also choose the clock rate for convenience given the chosen
    accumulator length.

    The trigger signal is when the accumulator rolls over. If the

    did you miss the whole discussion?

    In a sense, yes. Thus the call for a re-baseline.


    doing that with say a 100MHz clock give you 10ns jitter, which might be ok low frequency, but terrible at 15MHz



    The lowpass filter, between the DAC and the comparator, smooths the
    samples and reduces the jitter to picoseconds.

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    The real jitter problem is at low frequencies where the filter doesn't
    help much.

    I was doodling a lowpass filter that is sort of adaptive, to help the
    low-end jitter. Mr Shannon was a nice guy, but we aren't trying to
    reproduce a signal, we just want to make a clock.

    Well, I didn't mention it, but there are some classic dodges:

    Pre-packaged full DDS units are made to fit presumed markets, and may
    not fit the uncommon requirement. But if one implements the NCO plus
    sinus conversion in a FPGA and uses the output to drive a ADC chip,
    it's easy to get many more bits of analog width.

    First is to use a wider DAC to convert phase to sinus voltage; this
    will smooth the jaggies at 15 MHz (which is pretty slow by current DAC standards.

    Second is to have two paths in parallel, we'll call them fast and
    slow, with their analog outputs combined by means of a crossover
    network of some kind.

    Third is to multiply the 200 MHz up to say 800 MHz, limited only by
    the FPGA.

    Or some combination of all above.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Wed Aug 17 14:31:11 2022
    On Wed, 17 Aug 2022 13:26:53 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Wednesday, August 17, 2022 at 12:07:20 PM UTC-7, jla...@highlandsniptechnology.com wrote:

    The real jitter problem is at low frequencies where the filter doesn't
    help much.

    I was doodling a lowpass filter that is sort of adaptive, to help the
    low-end jitter.

    By 'doodling', I trust you mean that the tracking filter isn't looking
    like a good solution.

    Thinking is not a bad thing to do now and then. And I said adaptive,
    not tracking.

    I'd have to simulate it to see if it's worth doing, and what the side
    effects might be.




    Mr Shannon was a nice guy, but we aren't trying to
    reproduce a signal, we just want to make a clock.

    Oh, no, you already HAVE a clock, what you want is a derived >infinitely-adjustable variable clock based on that digital clock source.

    An easy way, is to use integer-ratio phase locking to
    the master clock to generate a digitally adjustable clock#2,
    for coarse adjustments, and use a sinewave variable oscillator
    (yeah, LC and varactor or moving parts) which can be metered by the master clock
    and fine-adjusted, then with a diode mixer combine the two.

    One discrete-time oscillator and one infinitely-adjustable oscillator, and a mixer.
    Follow up with an IF-style filter to make sinewaves, then amplifier to make 'em square.
    'Tracking filter' functionality is exactly the LC oscillator feature that a totally digital
    system is missing, and gives you the ability to fill in the gaps in an N/M synthesis.

    Mr. Shannon assures us that there will be jitter,

    The Sampling Theorem describes a sampled system that perfectly
    reproduces its input. No time delay even.

    https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem

    Someone noted that most of the great Nobel scientists at Bell Labs had
    one thing in common: they ate lunch with Harry Nyquist.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Wed Aug 17 15:05:28 2022
    onsdag den 17. august 2022 kl. 23.49.21 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Wed, 17 Aug 2022 14:03:36 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    onsdag den 17. august 2022 kl. 21.07.20 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Wed, 17 Aug 2022 11:15:06 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    onsdag den 17. august 2022 kl. 19.02.50 UTC+2 skrev Joe Gwinn:
    On Tue, 16 Aug 2022 11:32:12 -0700, John Larkin
    <jlarkin@highland_atwork_technology.com> wrote:

    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joeg...@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com >> >> >>wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote: >> >> >>>>>>>>>> On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    s?ndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising
    trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential
    components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as
    16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't
    matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly
    through the waveform lookup table and a fixed filter doesn't >> >> >>>>>>>> interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem, >> >> >>>>>>> likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies
    is perhaps to have two DACs, one of them making the output filter
    programmable so you can dynamically change it, based on step, >> >> >>>>>>> with some preemption etc., you get the idea - and I am not sure >> >> >>>>>>> it is practical, not only because it is complex but also because
    I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the >> >> >>>>>> time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an >> >> >>>>> equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine >> >> >>>>wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >> >> >>>>wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table.
    If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something
    more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes >> >> >>>frequency on demand and doesn't stop for reprogramming and doesn't >> >> >>>blow up someone's laser by generating any goofy triggers. In other >> >> >>>words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit
    accumulators can do just this, with phase continuity between the two >> >> >>frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary:
    table-lookup and CORDIC being very common approaches.


    One problem is that, at low frequencies, the LSB of that 10 to 14 bits >> >> >changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter

    Perhaps it's time to bring the various discussion threads together and
    re-focus by restating the problem to be solved.

    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    It's an interesting problem.
    If all you want to do is to generate a trigger at any frequency from
    10^-3 Hz to 15*10^6 Hz in 10^-3 Hz steps, that is easily done in a
    phase-only DDS topology (no trig conversion needed), which can be
    implemented directly in a FPGA.

    This is also known as a Numerically Controlled Oscillator:

    .<https://en.wikipedia.org/wiki/Numerically-controlled_oscillator>

    Our output would be point /M in Figure 1 in the above Wiki article.
    (Never mind that M is actually a bit width in that figure.)

    How big must the accumulator be? 15*10^6/10^-3 = 15*10^9 possible
    frequencies. Log2[ 15*10^9 ] = 33.8 bits. There was also talk of
    needing 50^10^9 steps, which would be 35.5 bits, minimum. In either
    case, a 48-bit accumulator will work with room to spare.

    If not, simply make the accumulator larger - 64 bits is also common.
    One can also choose the clock rate for convenience given the chosen
    accumulator length.

    The trigger signal is when the accumulator rolls over. If the

    did you miss the whole discussion?

    doing that with say a 100MHz clock give you 10ns jitter, which might be ok low frequency, but terrible at 15MHz


    The lowpass filter, between the DAC and the comparator, smooths the
    samples and reduces the jitter to picoseconds.

    sure but not if you make the square wave directly from the MSB of the accumulator with no DAC
    The phase accumulator MSB is pretty good at low frequencies and
    hideous at high frequencies. Possibly we can make a reasonably clean transition from sinewave DDS to MSB only at some frequency.

    just add a frequency dependent gain so the the slew rate stays roughly the same, then there is no transition

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Wed Aug 17 14:49:11 2022
    On Wed, 17 Aug 2022 14:03:36 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    onsdag den 17. august 2022 kl. 21.07.20 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Wed, 17 Aug 2022 11:15:06 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    onsdag den 17. august 2022 kl. 19.02.50 UTC+2 skrev Joe Gwinn:
    On Tue, 16 Aug 2022 11:32:12 -0700, John Larkin
    <jlarkin@highland_atwork_technology.com> wrote:

    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joeg...@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com >> >> >>wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com> >> >> >>>wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote:
    On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    s?ndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising
    trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential >> >> >>>>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as
    16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't
    matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"?

    When synthesizing a low frequency DDS sine wave, we step slowly >> >> >>>>>>>> through the waveform lookup table and a fixed filter doesn't
    interpolate waveform steps any more; it settles every step.

    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem,
    likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies >> >> >>>>>>> is perhaps to have two DACs, one of them making the output filter >> >> >>>>>>> programmable so you can dynamically change it, based on step,
    with some preemption etc., you get the idea - and I am not sure >> >> >>>>>>> it is practical, not only because it is complex but also because >> >> >>>>>>> I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the >> >> >>>>>> time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
    needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so,
    and divide down as needed. The trick will be to make the gear shifts
    appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine
    wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case. If you want to switch by
    operator action you have milliseconds of time to recalculate the table.
    If you want to switch by some external gating you only need two
    tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >> >> >>>>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes
    frequency on demand and doesn't stop for reprogramming and doesn't
    blow up someone's laser by generating any goofy triggers. In other
    words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit
    accumulators can do just this, with phase continuity between the two
    frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary:
    table-lookup and CORDIC being very common approaches.


    One problem is that, at low frequencies, the LSB of that 10 to 14 bits >> >> >changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter

    Perhaps it's time to bring the various discussion threads together and >> >> >>re-focus by restating the problem to be solved.

    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    It's an interesting problem.
    If all you want to do is to generate a trigger at any frequency from
    10^-3 Hz to 15*10^6 Hz in 10^-3 Hz steps, that is easily done in a
    phase-only DDS topology (no trig conversion needed), which can be
    implemented directly in a FPGA.

    This is also known as a Numerically Controlled Oscillator:

    .<https://en.wikipedia.org/wiki/Numerically-controlled_oscillator>

    Our output would be point /M in Figure 1 in the above Wiki article.
    (Never mind that M is actually a bit width in that figure.)

    How big must the accumulator be? 15*10^6/10^-3 = 15*10^9 possible
    frequencies. Log2[ 15*10^9 ] = 33.8 bits. There was also talk of
    needing 50^10^9 steps, which would be 35.5 bits, minimum. In either
    case, a 48-bit accumulator will work with room to spare.

    If not, simply make the accumulator larger - 64 bits is also common.
    One can also choose the clock rate for convenience given the chosen
    accumulator length.

    The trigger signal is when the accumulator rolls over. If the

    did you miss the whole discussion?

    doing that with say a 100MHz clock give you 10ns jitter, which might be ok low frequency, but terrible at 15MHz


    The lowpass filter, between the DAC and the comparator, smooths the
    samples and reduces the jitter to picoseconds.

    sure but not if you make the square wave directly from the MSB of the accumulator with no DAC

    The phase accumulator MSB is pretty good at low frequencies and
    hideous at high frequencies. Possibly we can make a reasonably clean
    transition from sinewave DDS to MSB only at some frequency.


    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    The real jitter problem is at low frequencies where the filter doesn't
    help much.

    you could also question how much 10ns of jitter matters on a 1Hz signal, it's 10ppb
    how accurate is the oscillator over a second?

    1 PPM RMS jitter would be OK. We're redesigning a product, and the old
    one uses an ADI spi-interface DDS chip that has horrible jitter at low frequencies, something like 100 PPM.

    A customer can program it high and kick in a divisor, which reduces
    jitter radically, but the transition to a new frequency is messy and
    some people whine about blown-up lasers or something silly like that.

    Our XO can be locked to a better oscillator, and we have an internal
    OCXO option. Only a few per cent of our sales have the OCXO.

    http://www.highlandtechnology.com/DSS/T564DS.shtml

    It's pretty good, but I want to make it better next rev. Prettier too.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to John Larkin on Thu Aug 18 01:22:51 2022
    On 8/16/2022 20:13, John Larkin wrote:
    On Tue, 16 Aug 2022 19:51:04 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/16/2022 17:02, jlarkin@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>> wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote: >>>>>>> On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff: >>>>>>
    I still don't understand what you are trying to do. Periodic sine >>>>>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>>>>>> wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic >>>>>>> waveform at 1 MHz (the worst case) at 100 Msps update rate takes >>>>>>> a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table? >>>>>> And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table
    size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load >>>>> N.

    The sine lookup table is addressed by some number of MSBs of the phase >>>>> accumulator, 10 to 16 typically. It doesn't change in a given system. >>>>>



    Perhaps you could shorten the lookup table to some manageable size if
    you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1,
    so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the
    phase accumulator. A group of MS bits becomes the gate for a cluster
    of LS bits. Envision a spinner dial that mostly parks at 0 degrees and
    once in a while makes a single fast rotation. That essentially puts a
    divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.




    But if this is to be used as a trigger (similar to the sweep trigger
    on a scope, level knob etc.) can't you just do triangular instead of
    sine wave? Should even be better for that purpose - and no need for a
    lookup table at all...

    That has been considered. But Claude Shannon is the evil stepmother
    lurking and plotting to keep us from living happily after.

    The sampling frequency is async to the trigger rate that we want, so
    is a source of jitter. A triangle is not bandlimited to below the
    Nyquist rate, and we can't afford an ideal lowpass filter either.


    I still don't understand why someone would need sine wave for triggering
    rather than just some TTL or whatever pulse generator, you must have
    made dozens of these. Just dividing some low jitter oscillator is as
    trivial as it can get. But if it has to be sine wave well, things do
    get complicated. I anticipate once you have made that superb sine
    wave generator they will find out that noise or whatever is a source
    of some jitter to which the generator's will be negligible....
    I don't know the application of course, this is how it looks
    to me at this point.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Wed Aug 17 15:37:30 2022
    torsdag den 18. august 2022 kl. 00.23.00 UTC+2 skrev Dimiter Popoff:
    On 8/16/2022 20:13, John Larkin wrote:
    On Tue, 16 Aug 2022 19:51:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:

    On 8/16/2022 17:02, jla...@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whi...@gmail.com> >>>>> wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote: >>>>>>> On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff: >>>>>>
    I still don't understand what you are trying to do. Periodic sine >>>>>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>>>>>> wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic >>>>>>> waveform at 1 MHz (the worst case) at 100 Msps update rate takes >>>>>>> a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table? >>>>>> And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table
    size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load >>>>> N.

    The sine lookup table is addressed by some number of MSBs of the phase >>>>> accumulator, 10 to 16 typically. It doesn't change in a given system. >>>>>



    Perhaps you could shorten the lookup table to some manageable size if >>>> you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1,
    so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the
    phase accumulator. A group of MS bits becomes the gate for a cluster
    of LS bits. Envision a spinner dial that mostly parks at 0 degrees and >>> once in a while makes a single fast rotation. That essentially puts a
    divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.




    But if this is to be used as a trigger (similar to the sweep trigger
    on a scope, level knob etc.) can't you just do triangular instead of
    sine wave? Should even be better for that purpose - and no need for a
    lookup table at all...

    That has been considered. But Claude Shannon is the evil stepmother
    lurking and plotting to keep us from living happily after.

    The sampling frequency is async to the trigger rate that we want, so
    is a source of jitter. A triangle is not bandlimited to below the
    Nyquist rate, and we can't afford an ideal lowpass filter either.

    I still don't understand why someone would need sine wave for triggering rather than just some TTL or whatever pulse generator, you must have
    made dozens of these. Just dividing some low jitter oscillator is as
    trivial as it can get. But if it has to be sine wave well, things do
    get complicated. I anticipate once you have made that superb sine
    wave generator they will find out that noise or whatever is a source
    of some jitter to which the generator's will be negligible....
    I don't know the application of course, this is how it looks
    to me at this point.

    try generating arbitrary frequencies that isn't necessarily a multiple of 10ns with a 100MHz clk
    with just a divider...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to Lasse Langwadt Christensen on Thu Aug 18 02:11:15 2022
    On 8/18/2022 1:37, Lasse Langwadt Christensen wrote:
    torsdag den 18. august 2022 kl. 00.23.00 UTC+2 skrev Dimiter Popoff:
    On 8/16/2022 20:13, John Larkin wrote:
    On Tue, 16 Aug 2022 19:51:04 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/16/2022 17:02, jla...@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>>> wrote:

    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whi...@gmail.com> >>>>>>> wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote: >>>>>>>>> On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff: >>>>>>>>
    I still don't understand what you are trying to do. Periodic sine >>>>>>>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>>>>>>>> wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic >>>>>>>>> waveform at 1 MHz (the worst case) at 100 Msps update rate takes >>>>>>>>> a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table? >>>>>>>> And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table
    size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load >>>>>>> N.

    The sine lookup table is addressed by some number of MSBs of the phase >>>>>>> accumulator, 10 to 16 typically. It doesn't change in a given system. >>>>>>>



    Perhaps you could shorten the lookup table to some manageable size if >>>>>> you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1, >>>>> so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the
    phase accumulator. A group of MS bits becomes the gate for a cluster >>>>> of LS bits. Envision a spinner dial that mostly parks at 0 degrees and >>>>> once in a while makes a single fast rotation. That essentially puts a >>>>> divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.




    But if this is to be used as a trigger (similar to the sweep trigger
    on a scope, level knob etc.) can't you just do triangular instead of
    sine wave? Should even be better for that purpose - and no need for a
    lookup table at all...

    That has been considered. But Claude Shannon is the evil stepmother
    lurking and plotting to keep us from living happily after.

    The sampling frequency is async to the trigger rate that we want, so
    is a source of jitter. A triangle is not bandlimited to below the
    Nyquist rate, and we can't afford an ideal lowpass filter either.

    I still don't understand why someone would need sine wave for triggering
    rather than just some TTL or whatever pulse generator, you must have
    made dozens of these. Just dividing some low jitter oscillator is as
    trivial as it can get. But if it has to be sine wave well, things do
    get complicated. I anticipate once you have made that superb sine
    wave generator they will find out that noise or whatever is a source
    of some jitter to which the generator's will be negligible....
    I don't know the application of course, this is how it looks
    to me at this point.

    try generating arbitrary frequencies that isn't necessarily a multiple of 10ns with a 100MHz clk
    with just a divider...

    Obviously you can't do that, I am just wondering about the application
    that needs 10 seconds period with picoseconds of jitter. Or with a ns
    of jitter, for that.
    But other people asked about making sort of the same thing, clearly
    there is some demand.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Wed Aug 17 16:20:25 2022
    torsdag den 18. august 2022 kl. 01.11.22 UTC+2 skrev Dimiter Popoff:
    On 8/18/2022 1:37, Lasse Langwadt Christensen wrote:
    torsdag den 18. august 2022 kl. 00.23.00 UTC+2 skrev Dimiter Popoff:
    On 8/16/2022 20:13, John Larkin wrote:
    On Tue, 16 Aug 2022 19:51:04 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/16/2022 17:02, jla...@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>>> wrote:

    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whi...@gmail.com> >>>>>>> wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote:
    On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:

    I still don't understand what you are trying to do. Periodic sine >>>>>>>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic >>>>>>>>> waveform at 1 MHz (the worst case) at 100 Msps update rate takes >>>>>>>>> a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table?
    And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table
    size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load >>>>>>> N.

    The sine lookup table is addressed by some number of MSBs of the phase
    accumulator, 10 to 16 typically. It doesn't change in a given system. >>>>>>>



    Perhaps you could shorten the lookup table to some manageable size if >>>>>> you do lookup-and-interpolate. Will still be huge... And division >>>>>> at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix, >>>>> lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1, >>>>> so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the >>>>> phase accumulator. A group of MS bits becomes the gate for a cluster >>>>> of LS bits. Envision a spinner dial that mostly parks at 0 degrees and >>>>> once in a while makes a single fast rotation. That essentially puts a >>>>> divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.




    But if this is to be used as a trigger (similar to the sweep trigger >>>> on a scope, level knob etc.) can't you just do triangular instead of >>>> sine wave? Should even be better for that purpose - and no need for a >>>> lookup table at all...

    That has been considered. But Claude Shannon is the evil stepmother
    lurking and plotting to keep us from living happily after.

    The sampling frequency is async to the trigger rate that we want, so
    is a source of jitter. A triangle is not bandlimited to below the
    Nyquist rate, and we can't afford an ideal lowpass filter either.

    I still don't understand why someone would need sine wave for triggering >> rather than just some TTL or whatever pulse generator, you must have
    made dozens of these. Just dividing some low jitter oscillator is as
    trivial as it can get. But if it has to be sine wave well, things do
    get complicated. I anticipate once you have made that superb sine
    wave generator they will find out that noise or whatever is a source
    of some jitter to which the generator's will be negligible....
    I don't know the application of course, this is how it looks
    to me at this point.

    try generating arbitrary frequencies that isn't necessarily a multiple of 10ns with a 100MHz clk
    with just a divider...
    Obviously you can't do that, I am just wondering about the application
    that needs 10 seconds period with picoseconds of jitter. Or with a ns
    of jitter, for that.
    But other people asked about making sort of the same thing, clearly
    there is some demand.

    the discussion is about making a dothat that does everything from 10 sec to ~60ns periods with
    low jitter in all cases and no weird transitions

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to jla...@highlandsniptechnology.com on Wed Aug 17 18:51:36 2022
    On Wednesday, August 17, 2022 at 2:31:22 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 13:26:53 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

    Mr. Shannon assures us that there will be jitter,
    The Sampling Theorem describes a sampled system that perfectly
    reproduces its input. No time delay even.

    Irrelevant; the OTHER Shannon work is information content limited by bandwidth and
    signal/noise, and... the 'ideal' zero-jitter constant frequency with a broad frequency range just has too much information content; whatever number of bits you
    use to describe the output frequency, it's not enough bits.

    My proposed 'IF filter' solution only covers a limited bandwidth, by intent; you'd use regular
    old synchronous counters to divide down the (high) frequency to your target; jitter at
    low frequency is assuredly not high.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Dimiter Popoff on Wed Aug 17 19:52:18 2022
    On Wednesday, August 17, 2022 at 6:23:00 PM UTC-4, Dimiter Popoff wrote:
    On 8/16/2022 20:13, John Larkin wrote:
    On Tue, 16 Aug 2022 19:51:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:

    On 8/16/2022 17:02, jla...@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whi...@gmail.com> >>>>> wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote: >>>>>>> On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff: >>>>>>
    I still don't understand what you are trying to do. Periodic sine >>>>>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>>>>>> wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic >>>>>>> waveform at 1 MHz (the worst case) at 100 Msps update rate takes >>>>>>> a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table? >>>>>> And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table
    size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load >>>>> N.

    The sine lookup table is addressed by some number of MSBs of the phase >>>>> accumulator, 10 to 16 typically. It doesn't change in a given system. >>>>>



    Perhaps you could shorten the lookup table to some manageable size if >>>> you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1,
    so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the
    phase accumulator. A group of MS bits becomes the gate for a cluster
    of LS bits. Envision a spinner dial that mostly parks at 0 degrees and >>> once in a while makes a single fast rotation. That essentially puts a
    divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.




    But if this is to be used as a trigger (similar to the sweep trigger
    on a scope, level knob etc.) can't you just do triangular instead of
    sine wave? Should even be better for that purpose - and no need for a
    lookup table at all...

    That has been considered. But Claude Shannon is the evil stepmother
    lurking and plotting to keep us from living happily after.

    The sampling frequency is async to the trigger rate that we want, so
    is a source of jitter. A triangle is not bandlimited to below the
    Nyquist rate, and we can't afford an ideal lowpass filter either.

    I still don't understand why someone would need sine wave for triggering rather than just some TTL or whatever pulse generator, you must have
    made dozens of these. Just dividing some low jitter oscillator is as
    trivial as it can get. But if it has to be sine wave well, things do
    get complicated. I anticipate once you have made that superb sine
    wave generator they will find out that noise or whatever is a source
    of some jitter to which the generator's will be negligible....
    I don't know the application of course, this is how it looks
    to me at this point.

    Ok, generate a 1.23456789 MHz clock from a 100 MHz reference using simple digital dividers.

    The sine wave is how the jitter is reduced to as close to zero as you can afford with the filtering.

    --

    Rick C.

    --- Get 1,000 miles of free Supercharging
    --- Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Joe Gwinn on Wed Aug 17 19:47:48 2022
    On Wednesday, August 17, 2022 at 1:02:50 PM UTC-4, Joe Gwinn wrote:
    On Tue, 16 Aug 2022 11:32:12 -0700, John Larkin <jlarkin@highland_atwork_technology.com> wrote:

    On Tue, 16 Aug 2022 13:46:32 -0400, Joe Gwinn <joeg...@comcast.net>
    wrote:

    On Mon, 15 Aug 2022 19:26:28 -0700, jla...@highlandsniptechnology.com >>wrote:

    On Mon, 15 Aug 2022 22:42:11 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>wrote:

    On 8/15/2022 17:17, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>>>> wrote:

    On 8/15/2022 1:41, Dimiter_Popoff wrote:
    On 8/15/2022 1:08, jla...@highlandsniptechnology.com wrote:
    On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/14/2022 17:14, jla...@highlandsniptechnology.com wrote: >>>>>>>>>> On Sun, 14 Aug 2022 02:22:50 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    sĹłndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:
    It strikes me that John Larkin's original idea of synthesising >>>>>>>>>>>> trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you
    fed into your comparator would be made up of four sequential >>>>>>>>>>>> components - all coming out of the DAC - high segment of arbitrary
    length, a falling edge, a low segment, and a risng edge >>>>>>>>>>>>
    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf


    you'd synthisese the rising and falling edges of the trapezia as
    16-successive steps of a staircase waveform.

    since it is for a trigger and the falling edge probably doesn't >>>>>>>>>>> matter, why not a single variable voltage step into a filter, sorta
    like a time-to-amplitude in reverse

    My question is basically whether one can DDS a non-sinusoidal waveform
    to make a faster edge into a filter and comparator, to get better time
    resolution, less jitter, at low frequencies.

    I am only curious if I understand what you are after - is it some sort
    of "the larger the step the less low pass I want applied to it"? >>>>>>>>
    When synthesizing a low frequency DDS sine wave, we step slowly >>>>>>>> through the waveform lookup table and a fixed filter doesn't >>>>>>>> interpolate waveform steps any more; it settles every step. >>>>>>>>
    So, is there a better waveform to use at low frequencies?


    Hmmm. I get it now (though I don't get why this is a problem, >>>>>>> likely specific to your application). I don't know how one
    waveform would be better for you that another, don't know
    what it is you are doing (perhaps you said and I missed it,
    I am not following closely).
    A pretty complex way of dealing with the steps at low frequencies >>>>>>> is perhaps to have two DACs, one of them making the output filter >>>>>>> programmable so you can dynamically change it, based on step, >>>>>>> with some preemption etc., you get the idea - and I am not sure >>>>>>> it is practical, not only because it is complex but also because >>>>>>> I have never done this, I am just musing.

    I missed the "we step slowly" in your post, now I get it.
    Well, the simplest way out is to step at a constant rate all the >>>>>> time.

    I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That >>>>> needs a sine lookup table with about 50 billion entries. And an
    equally impossible DAC and comparator.

    We'll probably wind up synthesizing the high range, an octave or so, >>>>> and divide down as needed. The trick will be to make the gear shifts >>>>> appear to be seamless.

    That could get interesting.


    I still don't understand what you are trying to do. Periodic sine >>>>wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>wave lookup table for the slowest case. If you want to switch by >>>>operator action you have milliseconds of time to recalculate the table. >>>>If you want to switch by some external gating you only need two >>>>tables to switch between, this makes up to 200 entries.
    This is all way too simple and obvious so you must be after something >>>>more than that - which I haven't got yet.

    I just want a programmable-frequency trigger generator that changes >>>frequency on demand and doesn't stop for reprogramming and doesn't >>>blow up someone's laser by generating any goofy triggers. In other >>>words, goes smoothly from F1 to F2.

    With low period jitter from, say, 1 mHz to 15 Mhz.

    mHz resolution is good too.

    I guess I'm not seeing the problem. Ordinary DDS units with 48-bit >>accumulators can do just this, with phase continuity between the two >>frequencies, so no glitches. People implement arbitrary
    frequency-keyed waveforms this way.

    The phase to trig converter typically uses only the upper 10 to 14
    bits of the 48-bit accumulator. Converter implementations vary: >>table-lookup and CORDIC being very common approaches.


    One problem is that, at low frequencies, the LSB of that 10 to 14 bits >changes infrequently and the lowpass filter doesn't interpolate
    multiple points any more. So one gets a lot of period jitter

    Perhaps it's time to bring the various discussion threads together and >>re-focus by restating the problem to be solved.

    I've stated it a few times: We want a perfect, programmable,
    glitch-free, always right, low period jitter trigger clock.

    It's an interesting problem.
    If all you want to do is to generate a trigger at any frequency from
    10^-3 Hz to 15*10^6 Hz in 10^-3 Hz steps, that is easily done in a phase-only DDS topology (no trig conversion needed), which can be implemented directly in a FPGA.

    This is also known as a Numerically Controlled Oscillator:

    .<https://en.wikipedia.org/wiki/Numerically-controlled_oscillator>

    Our output would be point /M in Figure 1 in the above Wiki article.
    (Never mind that M is actually a bit width in that figure.)

    How big must the accumulator be? 15*10^6/10^-3 = 15*10^9 possible frequencies. Log2[ 15*10^9 ] = 33.8 bits. There was also talk of
    needing 50^10^9 steps, which would be 35.5 bits, minimum. In either
    case, a 48-bit accumulator will work with room to spare.

    If not, simply make the accumulator larger - 64 bits is also common.
    One can also choose the clock rate for convenience given the chosen accumulator length.

    The trigger signal is when the accumulator rolls over. If the
    Frequency Control Word is small, this will take some time. If large,
    much faster.

    The problem is the jitter is a full clock cycle. That's the point of generating a sine wave, then filtering it. The zero crossing is no longer aligned to the master clock and you have a new clock related by the ratio of two large integers, so lots of
    resolution and low jitter.

    --

    Rick C.

    ++ Get 1,000 miles of free Supercharging
    ++ Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Thu Aug 18 00:23:02 2022
    torsdag den 18. august 2022 kl. 04.52.23 UTC+2 skrev Ricky:
    On Wednesday, August 17, 2022 at 6:23:00 PM UTC-4, Dimiter Popoff wrote:
    On 8/16/2022 20:13, John Larkin wrote:
    On Tue, 16 Aug 2022 19:51:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:

    On 8/16/2022 17:02, jla...@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <d...@tgi-sci.com> >>> wrote:

    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whi...@gmail.com> >>>>> wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote:
    On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff:

    I still don't understand what you are trying to do. Periodic sine >>>>>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine
    wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic >>>>>>> waveform at 1 MHz (the worst case) at 100 Msps update rate takes >>>>>>> a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table?
    And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table
    size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load >>>>> N.

    The sine lookup table is addressed by some number of MSBs of the phase
    accumulator, 10 to 16 typically. It doesn't change in a given system. >>>>>



    Perhaps you could shorten the lookup table to some manageable size if >>>> you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1, >>> so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the
    phase accumulator. A group of MS bits becomes the gate for a cluster >>> of LS bits. Envision a spinner dial that mostly parks at 0 degrees and >>> once in a while makes a single fast rotation. That essentially puts a >>> divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.




    But if this is to be used as a trigger (similar to the sweep trigger
    on a scope, level knob etc.) can't you just do triangular instead of
    sine wave? Should even be better for that purpose - and no need for a
    lookup table at all...

    That has been considered. But Claude Shannon is the evil stepmother lurking and plotting to keep us from living happily after.

    The sampling frequency is async to the trigger rate that we want, so
    is a source of jitter. A triangle is not bandlimited to below the
    Nyquist rate, and we can't afford an ideal lowpass filter either.

    I still don't understand why someone would need sine wave for triggering rather than just some TTL or whatever pulse generator, you must have
    made dozens of these. Just dividing some low jitter oscillator is as trivial as it can get. But if it has to be sine wave well, things do
    get complicated. I anticipate once you have made that superb sine
    wave generator they will find out that noise or whatever is a source
    of some jitter to which the generator's will be negligible....
    I don't know the application of course, this is how it looks
    to me at this point.
    Ok, generate a 1.23456789 MHz clock from a 100 MHz reference using simple digital dividers.

    divide by 81 ;)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Monett VE3BTI@21:1/5 to Lasse Langwadt Christensen on Thu Aug 18 08:20:41 2022
    Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    Ok, generate a 1.23456789 MHz clock from a 100 MHz reference using
    simple digital dividers.

    divide by 81 ;)


    Off a bit:
    100/81 = 1.23456790123

    --
    MRM

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Thu Aug 18 05:13:22 2022
    torsdag den 18. august 2022 kl. 10.20.49 UTC+2 skrev Mike Monett VE3BTI:
    Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    Ok, generate a 1.23456789 MHz clock from a 100 MHz reference using
    simple digital dividers.

    divide by 81 ;)

    Off a bit:
    100/81 = 1.23456790123

    ~1ppm

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Monett VE3BTI@21:1/5 to Lasse Langwadt Christensen on Thu Aug 18 13:41:46 2022
    Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    torsdag den 18. august 2022 kl. 10.20.49 UTC+2 skrev Mike Monett VE3BTI:
    Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    Ok, generate a 1.23456789 MHz clock from a 100 MHz reference using
    simple digital dividers.

    divide by 81 ;)

    Off a bit:
    100/81 = 1.23456790123

    ~1ppm

    Set the frequency to 1.23456789 * 81 = 99.99999909 MHz
    - exact

    Use a GPSDO for 1e-12 accuracy

    Measure with a FA-2 counter:

    https://www.banggood.com/FA-2-1Hz-12_4GHz-Frequency-Counter-Kit-Frequency- Meter-Statistical-Function-11-bits-or-sec-Tester-with-Power-Adapter-p- 1645869.html

    Manual:
    https://www.eevblog.com/forum/metrology/bg7tbl-fa1-frequency-analyzer/? action=dlattach;attach=876418

    Discussion: https://www.eevblog.com/forum/metrology/bg7tbl-fa1-frequency-analyzer/

    Time-Nuts Discussion: https://www.mail-archive.com/search?q=fa-2+counter&l=time-nuts% 40lists.febo.com

    Alternative:
    Stanford Research Frequency Counter
    SR620 — 13 digit Time interval / frequency counter, from $4950 https://www.thinksrs.com/products/sr620.html

    Make it into a SRS SG380 Signal Generator:

    The Stanford Research Systems group has introduced a new method of
    frequency generation described below:

    Introducing the new SG380 Series RF Signal Generators - finally, high performance, affordable RF sources.

    The SG380 Series RF Signal Generators use a unique, innovative architecture (Rational Approximation Frequency Synthesis) to deliver ultra-high
    frequency resolution (1 µHz), excellent phase noise, and versatile
    modulation capabilities (AM, FM, ŘM, pulse modulation and sweeps) at a
    fraction of the cost of competing designs.

    A New Frequency Synthesis Technique

    The SG380 Series Signal Generators are based on a new frequency synthesis technique called Rational Approximation Frequency Synthesis (RAFS). RAFS
    uses small integer divisors in a conventional phase-locked loop (PLL) to synthesize a frequency that would be close to the desired frequency
    (typically within ±100 ppm) using the nominal PLL reference frequency. The
    PLL reference frequency, which is sourced by a voltage control crystal oscillator that is phase locked to a dithered direct digital synthesizer,
    is adjusted so that the PLL generates the exact frequency. Doing so
    provides a high phase comparison frequency (typically 25 MHz) yielding low phase noise while moving the PLL reference spurs far from the carrier where they can be easily removed. The end result is an agile RF source with low
    phase noise, essentially infinite frequency resolution, without the spurs
    of fractional-N synthesis or the cost of a YIG oscillator.

    https://www.thinksrs.com/products/sg380.html

    The manual is at

    https://www.thinksrs.com/downloads/pdfs/manuals/SG380m.pdf

    The description of Rational Approximation Synthesis starts on page 151. A
    block diagram is on page 156.




    --
    MRM

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Thu Aug 18 12:41:33 2022
    On 8/17/22 9:58 AM, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts <usenet@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whit3rd@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table. >>> Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    https://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Thu Aug 18 11:35:32 2022
    torsdag den 18. august 2022 kl. 18.41.52 UTC+2 skrev Phil Hobbs:
    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase >>> accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.

    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.


    something like this should be simple to implement by gaining and clamping
    the triangular wave going into the sine table

    https://imgur.com/6KqpCW9

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Phil Hobbs on Thu Aug 18 12:10:16 2022
    On Thursday, August 18, 2022 at 12:41:52 PM UTC-4, Phil Hobbs wrote:
    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table resolution.

    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.


    The problem with the low frequency is not "Numerical gain", which is an odd way of putting it. If you use a standard sine table, it won't matter how much gain you provide after the quantization in the table output. The damage has been done. The issue
    becomes one of defining the transition from much lower significance bits in the phase word than the table can be sized for. Thus, a special transition table needs to be used, addressed only by the lsbs of the phase word, enabled by the upper bits.

    None of this complication is needed. A standard DDS can be used to create a high rate clock over a 2:1 frequency range. This clock will have low jitter. This clock can then be reduced by a programmable octave divider, to provide the final frequency.
    If this divider does not have sufficient jitter stability, this output is run through a FF, clocked by the output of the DDS, and using a technology which has sufficiently low jitter as to meet the requirement.

    Both the DDS and the programmable divider can be changed on the same clock cycle which means there will be no disruption in observed frequency output. Each pulse will be either one rate or the other or some period in between during the transition.

    No need for messy nonsense of trying to work around the issue of slow sine waves. The sine wave is always high frequency using well understood techniques.

    You are welcome.

    --

    Rick C.

    --+ Get 1,000 miles of free Supercharging
    --+ Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Monett VE3BTI@21:1/5 to spamme@not.com on Thu Aug 18 20:09:28 2022
    Mike Monett VE3BTI <spamme@not.com> wrote:

    Set the frequency to 1.23456789 * 81 = 99.99999909 MHz
    - exact

    TTCalc By Tomasz Sowa

    Free

    Developer's Description

    TTCalc is an open source bignum mathematical calculator. It features arithmetical functions, trigonometric functions, inverse trigonometric functions, hyperbolic functions, inverse hyperbolic functions, logical operators, logarithms, functions for converting between degrees and radians
    and so on. Additionally the program allows a user to define his own
    variables and functions.

    Operating Systems

    Windows 2003, Windows 2000, Windows Vista, Windows 98, Windows Me, Windows, Windows NT, Windows 7, Windows XP

    https://download.cnet.com/TTCalc/3000-2053_4-75445805.html



    --
    MRM

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Thu Aug 18 14:11:00 2022
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <usenet@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whit3rd@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table. >>>> Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating >arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits.
    Somehow. Seamlessly.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Thu Aug 18 14:03:03 2022
    On Thu, 18 Aug 2022 01:22:51 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/16/2022 20:13, John Larkin wrote:
    On Tue, 16 Aug 2022 19:51:04 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/16/2022 17:02, jlarkin@highlandsniptechnology.com wrote:
    On Tue, 16 Aug 2022 15:44:27 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/16/2022 3:23, John Larkin wrote:
    On Mon, 15 Aug 2022 16:45:18 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>>> wrote:

    On Monday, August 15, 2022 at 2:03:21 PM UTC-7, Dimiter Popoff wrote: >>>>>>>> On 8/15/2022 22:56, Lasse Langwadt Christensen wrote:
    mandag den 15. august 2022 kl. 21.42.18 UTC+2 skrev Dimiter Popoff: >>>>>>>
    I still don't understand what you are trying to do. Periodic sine >>>>>>>>>> wave 1 to 15 MHz at 100 Msps is trivial, it takes a 100 entry sine >>>>>>>>>> wave lookup table for the slowest case.

    only if you want neat frequencies that add up to 100M

    I don't understand what a neat frequency is, either. Any periodic >>>>>>>> waveform at 1 MHz (the worst case) at 100 Msps update rate takes >>>>>>>> a 100 entry table.

    But suppose you adjust to 0.99 MHz; do you now use a 101 entry table? >>>>>>> And how about 0.995 MHz?
    The small-integer ratios for a given frequency don't support a fixed table
    size, and the 'update rate' might not be fine-adjustable enough. In contrast
    to a variable-LC tuning scheme, digital synthesis tables require... an exercise
    in ratios of integers to approximate a real number.

    With a DDS phase accumulator, the output frequency is

    Fxo * N / M

    where Fxo is the 100 MHz xtal oscillator

    N is the frequency set word

    M is the accumulator max count, say 2^48.

    Frequency set resolution would be below 1 uHz in this case. Just load >>>>>> N.

    The sine lookup table is addressed by some number of MSBs of the phase >>>>>> accumulator, 10 to 16 typically. It doesn't change in a given system. >>>>>>



    Perhaps you could shorten the lookup table to some manageable size if >>>>> you do lookup-and-interpolate. Will still be huge... And division
    at 100 Msps may well be prohibitive.

    Our FPGA will have at least a megabit of ram if we use the efinix,
    lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1,
    so we can easily do 64K points of 16 bit data.

    One of my guys proposed an architecture that uses more bits of the
    phase accumulator. A group of MS bits becomes the gate for a cluster
    of LS bits. Envision a spinner dial that mostly parks at 0 degrees and >>>> once in a while makes a single fast rotation. That essentially puts a
    divisor *before* a cosine lookup table and DAC.

    Gotta simulate that somehow.




    But if this is to be used as a trigger (similar to the sweep trigger
    on a scope, level knob etc.) can't you just do triangular instead of
    sine wave? Should even be better for that purpose - and no need for a
    lookup table at all...

    That has been considered. But Claude Shannon is the evil stepmother
    lurking and plotting to keep us from living happily after.

    The sampling frequency is async to the trigger rate that we want, so
    is a source of jitter. A triangle is not bandlimited to below the
    Nyquist rate, and we can't afford an ideal lowpass filter either.


    I still don't understand why someone would need sine wave for triggering >rather than just some TTL or whatever pulse generator, you must have
    made dozens of these.

    Most DDS theory uses sine waves. There could well be a better
    waveform, like a trapezoid, but that's going to need a lot of
    simulation to evaluate.

    Just dividing some low jitter oscillator is as
    trivial as it can get.

    DDS has arbitrary frequency resolution and, potentially, very low
    jitter. Divisors have low jitter but quantify the frequency selections
    hard. Our users can already select the internal XO and a divisor. In
    fact, they can program a burst of N pulses every M pulses no matter
    what the clock source.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeroen Belleman@21:1/5 to John Larkin on Thu Aug 18 23:37:25 2022
    On 2022-08-18 23:11, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <usenet@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whit3rd@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all. >>
    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    [...]

    Don't use a trapezoid then. Approximate one summing a series
    of sinc(x).

    Jeroen Belleman

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to jlarkin@highland_atwork_technology. on Thu Aug 18 18:15:46 2022
    On Thu, 18 Aug 2022 14:11:00 -0700, John Larkin <jlarkin@highland_atwork_technology.com> wrote:

    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs ><pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <usenet@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whit3rd@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all. >>
    If you have enough bits in the phase accumulator, and apply the right >>amount of numerical gain ahead of the DAC, you can always get a >>well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating >>arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by >>the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. >Somehow. Seamlessly.

    With a NCO implemented in a FPGA, it's pretty easy to generate a
    trigger when the phase angle is at a specified distance from
    roll-over, and use this (plus the bottom bits of the phase
    accumulator) to implement the transition. One can control the
    transition rate by choosing which bottom bits to use.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Joe Gwinn on Thu Aug 18 16:12:15 2022
    On Thursday, August 18, 2022 at 6:16:07 PM UTC-4, Joe Gwinn wrote:
    On Thu, 18 Aug 2022 14:11:00 -0700, John Larkin <jlarkin@highland_atwork_technology.com> wrote:

    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs ><pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right >>amount of numerical gain ahead of the DAC, you can always get a >>well-behaved trapezoidal waveform with a nice smooth fine-grained >>staircase near the zero crossing, which will filter well. (Saturating >>arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at >>least twice the filter's settling time (to the required accuracy), so >>that the ringing from the corner of the trapezoid has all settled out by >>the time you get to the zero crossing. If you increase the numerical >>gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output >jitter, so the filter has to forget that corner but average as many >samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the >trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. >Somehow. Seamlessly.
    With a NCO implemented in a FPGA, it's pretty easy to generate a
    trigger when the phase angle is at a specified distance from
    roll-over, and use this (plus the bottom bits of the phase
    accumulator) to implement the transition. One can control the
    transition rate by choosing which bottom bits to use.

    That, as you describe it, a simple "trigger" won't work. The transition has to be queued to the long word phase generator so the transition happens as an "average" of the multiple samples and so splits the clock cycle to obtain finer resolution. The
    values in the samples of the transition each have to be scaled to the lsbs of the phase word. Perhaps that's what you meant by "implement the transition".

    But none of this is useful since this design is easily done using a standard DDS design with a 2:1 range of output frequency allowing a filter to be optimized. Follow this with a programmable octave divider and you can cover any range of frequency you
    wish. No limit to the low end. The frequency resolution is only limited by the length of the phase word, which also determines the added jitter of the DDS, or at least is the largest contributor if designed properly.

    --

    Rick C.

    -+- Get 1,000 miles of free Supercharging
    -+- Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to John Larkin on Fri Aug 19 12:14:25 2022
    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <usenet@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whit3rd@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all. >>
    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same
    amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.

    You don't care about Nyquist here--you're a time domain guy, remember? ;)

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    https://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Fri Aug 19 09:22:35 2022
    fredag den 19. august 2022 kl. 18.14.35 UTC+2 skrev Phil Hobbs:
    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by >> the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. Somehow. Seamlessly.

    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.

    and if you do it before the sine table you get sine shaped edges

    sorta like S-shape acceleration/deceleration on a CNC/robot
    limiting jerk

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Lasse Langwadt Christensen on Fri Aug 19 12:34:24 2022
    On 8/19/22 12:22 PM, Lasse Langwadt Christensen wrote:
    fredag den 19. august 2022 kl. 18.14.35 UTC+2 skrev Phil Hobbs:
    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation >>>>> slope table and maybe just add. Do the math at compile time, not run >>>>> time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by >>>> the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits.
    Somehow. Seamlessly.

    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same
    amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.

    and if you do it before the sine table you get sine shaped edges

    sorta like S-shape acceleration/deceleration on a CNC/robot
    limiting jerk


    Interesting point.

    Normally, dorking a rectangle window to try to reduce the ringing is
    somewhat disappointing--the first derivative is continuous, but the
    second isn't. The ringing thus asymptotically goes like one more power
    of 1/t, which helps but isn't a complete fix.

    On the other hand, doing it your way has the important advantage that it switches seamlessly to the continuous-sinusoid case at high frequency,
    with no nasty artifacts at the changeover frequency.

    I like it.

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    https://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Fri Aug 19 13:02:42 2022
    On Fri, 19 Aug 2022 12:34:24 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 8/19/22 12:22 PM, Lasse Langwadt Christensen wrote:
    fredag den 19. august 2022 kl. 18.14.35 UTC+2 skrev Phil Hobbs:
    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation >>>>>> slope table and maybe just add. Do the math at compile time, not run >>>>>> time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right >>>>> amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating >>>>> arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at >>>>> least twice the filter's settling time (to the required accuracy), so >>>>> that the ringing from the corner of the trapezoid has all settled out by >>>>> the time you get to the zero crossing. If you increase the numerical >>>>> gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits.
    Somehow. Seamlessly.

    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same
    amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.

    and if you do it before the sine table you get sine shaped edges

    sorta like S-shape acceleration/deceleration on a CNC/robot
    limiting jerk


    Interesting point.

    Normally, dorking a rectangle window to try to reduce the ringing is
    somewhat disappointing--the first derivative is continuous, but the
    second isn't. The ringing thus asymptotically goes like one more power
    of 1/t, which helps but isn't a complete fix.

    On the other hand, doing it your way has the important advantage that it >switches seamlessly to the continuous-sinusoid case at high frequency,
    with no nasty artifacts at the changeover frequency.

    I like it.

    Yes. To which I'll add a bit of business from the radar world:

    One must shape the RF amplitude envelope to reduce harmonic
    generation, to meet NTIA (National Telecommunications and Information Administration) regulations.

    While one can simply limit how small the rise and fall times can be,
    this is often not quite enough for very powerful radars, and so the
    pulse edges are shaped into a reasonable approximation of a Gaussian
    CDF, which is a S-curve. Or a hyperbolic tangent function. So long
    as no corners survive.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Fri Aug 19 11:33:57 2022
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <usenet@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whit3rd@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by >>> the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits.
    Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same >amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.

    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table,
    in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitide
    jumps bigger.


    You don't care about Nyquist here--you're a time domain guy, remember? ;)

    Yes. Things like trapezoids and filter responses and jitter are better
    thought about in time domain. But Nyquist still lurks and leers at us.




    Cheers

    Phil Hobbs

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to langwadt@fonz.dk on Fri Aug 19 11:37:46 2022
    On Fri, 19 Aug 2022 09:22:35 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 18.14.35 UTC+2 skrev Phil Hobbs:
    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by >> >> the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits.
    Somehow. Seamlessly.

    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same
    amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.

    and if you do it before the sine table you get sine shaped edges

    sorta like S-shape acceleration/deceleration on a CNC/robot
    limiting jerk

    The "sine" table could have an s-shaped waveform to steepen the zero
    crossing into the comparator. The waveform need not be time symmetric,
    since the comparator only cares about the rising edge.

    Sort of a soft sawtooth?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Fri Aug 19 12:38:08 2022
    fredag den 19. august 2022 kl. 20.37.59 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 09:22:35 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 18.14.35 UTC+2 skrev Phil Hobbs:
    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation >> >>> slope table and maybe just add. Do the math at compile time, not run >> >>> time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right >> >> amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating >> >> arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at >> >> least twice the filter's settling time (to the required accuracy), so >> >> that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits.
    Somehow. Seamlessly.

    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same
    amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.

    and if you do it before the sine table you get sine shaped edges

    sorta like S-shape acceleration/deceleration on a CNC/robot
    limiting jerk
    The "sine" table could have an s-shaped waveform to steepen the zero
    crossing into the comparator. The waveform need not be time symmetric,
    since the comparator only cares about the rising edge.

    Sort of a soft sawtooth?

    why not a sine? https://imgur.com/6KqpCW9

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to langwadt@fonz.dk on Fri Aug 19 12:48:40 2022
    On Fri, 19 Aug 2022 12:38:08 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 20.37.59 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 09:22:35 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 18.14.35 UTC+2 skrev Phil Hobbs:
    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation >> >> >>> slope table and maybe just add. Do the math at compile time, not run >> >> >>> time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right >> >> >> amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating >> >> >> arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at >> >> >> least twice the filter's settling time (to the required accuracy), so >> >> >> that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical >> >> >> gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output >> >> > jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. >> >> > Somehow. Seamlessly.

    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same >> >> amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.

    and if you do it before the sine table you get sine shaped edges

    sorta like S-shape acceleration/deceleration on a CNC/robot
    limiting jerk
    The "sine" table could have an s-shaped waveform to steepen the zero
    crossing into the comparator. The waveform need not be time symmetric,
    since the comparator only cares about the rising edge.

    Sort of a soft sawtooth?

    why not a sine? https://imgur.com/6KqpCW9



    What's the blue thing? Its zero crossing is no steeper than the sine.
    Maybe noisier too.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Fri Aug 19 13:00:13 2022
    fredag den 19. august 2022 kl. 21.48.51 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:38:08 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 20.37.59 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 09:22:35 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 18.14.35 UTC+2 skrev Phil Hobbs:
    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical >> >> >> gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output >> >> > jitter, so the filter has to forget that corner but average as many >> >> > samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. >> >> > Somehow. Seamlessly.

    You just multiply by 1/f, using saturating arithmetic. That keeps the >> >> slope at the zero crossing the same at all frequencies, allows the same >> >> amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.

    and if you do it before the sine table you get sine shaped edges

    sorta like S-shape acceleration/deceleration on a CNC/robot
    limiting jerk
    The "sine" table could have an s-shaped waveform to steepen the zero
    crossing into the comparator. The waveform need not be time symmetric,
    since the comparator only cares about the rising edge.

    Sort of a soft sawtooth?

    why not a sine? https://imgur.com/6KqpCW9


    What's the blue thing? Its zero crossing is no steeper than the sine.

    green and blue are two different frequencies

    Maybe noisier too.

    the edges are the same

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Fri Aug 19 14:41:47 2022
    fredag den 19. august 2022 kl. 20.34.09 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:

    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation >>>> slope table and maybe just add. Do the math at compile time, not run >>>> time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by >>> the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits.
    Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same >amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.
    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table,
    in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitide
    jumps bigger.

    multiply before truncating

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Fri Aug 19 20:33:47 2022
    On Fri, 19 Aug 2022 14:41:47 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 20.34.09 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by >> >>> the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits.
    Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same
    amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.
    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table,
    in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitide
    jumps bigger.

    multiply before truncating



    I think that makes jitter worse. It violates Nyquist reconstruction
    principles by adding sharp XO-clocked corners.

    Putting gain in front of a zero-crossing comparator does nothing. It's
    still a zero-crossing comparator.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to jla...@highlandsniptechnology.com on Fri Aug 19 21:01:49 2022
    On Saturday, August 20, 2022 at 1:33:55 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Fri, 19 Aug 2022 14:41:47 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    fredag den 19. august 2022 kl. 20.34.09 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:
    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:
    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts <use...@revmaps.no-ip.org> wrote:
    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    <snip>

    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same >> >amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.

    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table,
    in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitude
    jumps bigger.

    multiply before truncating


    I think that makes jitter worse. It violates Nyquist reconstruction principles by adding sharp XO-clocked corners.

    But far enough away from the zero-crossings that defines your output edges that they don't make any difference to the output jitter (or a least not enough to matter). In the explicit DAC-generated trapezium version, you can fudge individual edges to
    compensate for difference at the starting points of the ramps.

    Putting gain in front of a zero-crossing comparator does nothing. It's still a zero-crossing comparator.

    But you can tweak when thinks it sees a zero-crossing, quite subtley, if you tweak far enough before the zero-crossing.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Sat Aug 20 12:00:00 2022
    On 8/19/22 11:33 PM, jlarkin@highlandsniptechnology.com wrote:
    On Fri, 19 Aug 2022 14:41:47 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 20.34.09 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation >>>>>>> slope table and maybe just add. Do the math at compile time, not run >>>>>>> time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right >>>>>> amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating >>>>>> arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at >>>>>> least twice the filter's settling time (to the required accuracy), so >>>>>> that the ringing from the corner of the trapezoid has all settled out by >>>>>> the time you get to the zero crossing. If you increase the numerical >>>>>> gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output >>>>> jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. >>>>> Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same >>>> amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.
    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table,
    in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitide
    jumps bigger.

    multiply before truncating



    I think that makes jitter worse. It violates Nyquist reconstruction principles by adding sharp XO-clocked corners.

    Putting gain in front of a zero-crossing comparator does nothing. It's
    still a zero-crossing comparator.




    Upthread you were correctly complaining about how, at low frequency, the
    DAC code can stay the same for many clock cycles, so that the
    reconstruction filter doesn't help the jitter much.

    At sufficiently high (saturating) gain, every sine wave looks exactly
    like a trapezoid near the zero crossing. If you multiply the amplitude
    by 1/f, every sine wave looks exactly like the _same_ trapezoid near zero.

    So that solves the first problem, by rendering the dV/dt and DAC
    resolution at the zero crossing frequency-independent. Thus if you make
    the linear portion (say) 32 samples wide, and your DAC has 12 bits, the
    DAC code will change by 16 codes per clock, independent of frequency.
    (At some frequency the numerical amplitude will equal the range of the
    DAC, so you don't need to do the 1/f thing above there.)

    The sampling theorem is only one way of bounding the error in this
    procedure, and in this case it isn't an especially helpful one.

    Provided that your reconstruction filter has settled to the required
    accuracy by the zero crossing, it's a simple propagation-of-errors
    calculation to figure out what jitter that can contribute.

    Lasse's suggestion of running the trapezoid through the sine lookup
    table automatically gives you a rounded trapezoid with an edge slope
    pi/2 times higher than the (constant) trapezoid slope, and if you pick
    the right gain constant, dV/dt will be continuous, which helps the
    filter settling.

    As the frequency rises and the numerical gain approaches 1.0, the
    rounded falling edge approaches the rounded rising edge, so that the
    flat spot disappears smoothly when the numerical gain is 1.0. Above
    that frequency, you don't apply the 1/f gain, so you have a vanilla DDS.

    Any timing nonlinearities this contributes will be determined by the
    settling time of the reconstruction filter, which is easy to bound, so
    you can be sure that the performance is what you want.

    What's not to like?

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    https://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Sat Aug 20 11:07:59 2022
    On Sat, 20 Aug 2022 12:00:00 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 8/19/22 11:33 PM, jlarkin@highlandsniptechnology.com wrote:
    On Fri, 19 Aug 2022 14:41:47 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 20.34.09 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation >>>>>>>> slope table and maybe just add. Do the math at compile time, not run >>>>>>>> time.

    At some point, dac resolution becomes the limit, not sine table >>>>>>>> resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right >>>>>>> amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained >>>>>>> staircase near the zero crossing, which will filter well. (Saturating >>>>>>> arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at >>>>>>> least twice the filter's settling time (to the required accuracy), so >>>>>>> that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical >>>>>>> gain like 1/f, this works down to as low a frequency as you like. >>>>>>
    Right. The trapezoid corner happens at an XO edge, which makes output >>>>>> jitter, so the filter has to forget that corner but average as many >>>>>> samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. >>>>>> Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the >>>>> slope at the zero crossing the same at all frequencies, allows the same >>>>> amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.
    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table,
    in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitide
    jumps bigger.

    multiply before truncating



    I think that makes jitter worse. It violates Nyquist reconstruction
    principles by adding sharp XO-clocked corners.

    Putting gain in front of a zero-crossing comparator does nothing. It's
    still a zero-crossing comparator.




    Upthread you were correctly complaining about how, at low frequency, the
    DAC code can stay the same for many clock cycles, so that the
    reconstruction filter doesn't help the jitter much.

    At sufficiently high (saturating) gain, every sine wave looks exactly
    like a trapezoid near the zero crossing. If you multiply the amplitude
    by 1/f, every sine wave looks exactly like the _same_ trapezoid near zero.

    So that solves the first problem, by rendering the dV/dt and DAC
    resolution at the zero crossing frequency-independent. Thus if you make
    the linear portion (say) 32 samples wide, and your DAC has 12 bits, the
    DAC code will change by 16 codes per clock, independent of frequency.
    (At some frequency the numerical amplitude will equal the range of the
    DAC, so you don't need to do the 1/f thing above there.)

    The sampling theorem is only one way of bounding the error in this
    procedure, and in this case it isn't an especially helpful one.

    One problem at higher frequencies is that the lowpass filter has
    memory. Any real filter has infinite memory of its past input. A
    zoomed trapezoid may look like a zoomed sine wave, but they have
    different histories. The trap has bigger XO-clock components
    (frequency or time domain) so potentially more jitter.


    Provided that your reconstruction filter has settled to the required
    accuracy by the zero crossing, it's a simple propagation-of-errors >calculation to figure out what jitter that can contribute.

    Lasse's suggestion of running the trapezoid through the sine lookup
    table automatically gives you a rounded trapezoid with an edge slope
    pi/2 times higher than the (constant) trapezoid slope, and if you pick
    the right gain constant, dV/dt will be continuous, which helps the
    filter settling.

    Filter settling is precisely the problem at low frequencies. We want
    sample interpolation, not steps.


    As the frequency rises and the numerical gain approaches 1.0, the
    rounded falling edge approaches the rounded rising edge, so that the
    flat spot disappears smoothly when the numerical gain is 1.0. Above
    that frequency, you don't apply the 1/f gain, so you have a vanilla DDS.

    Any timing nonlinearities this contributes will be determined by the
    settling time of the reconstruction filter, which is easy to bound, so
    you can be sure that the performance is what you want.

    What's not to like?

    What's bad is that at low frequencies and using a practical number of
    phase accumulator MSBs into a practical LUT and a real DAC, the
    comparator sees infrequent steps and the ca 15 MHz reconstruction
    filter doesn't interpolate. May as well use the MSB of the phase
    accumulator as the output clock.

    We need a sneaky algorithm that increases the slope and creates useful
    DAC points at 100 MHz, so the filter still interpolates.

    Rob has an idea for doing this digitally, sort of puting a divisor
    *ahead* of the sine LUT and DAC and always output useful steps at 100
    MHz so that the filter works. Imagine a spinner arrow that makes one
    full-speed spin once in a while. It would output a fast trapezoid or a
    cosine. I've been Spicing the DDS, because I know how to do that, but
    testing Rob's idea needs some fancier math sim program than I know how
    to use. He can do that when he has time.

    If we get the PCB layout right we can futz FPGA code later. "Right"
    may include a fancy filter and a comparator with a non-zero threshold.
    And as many DAC bits as we can afford.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to jla...@highlandsniptechnology.com on Sat Aug 20 12:03:42 2022
    On Friday, August 19, 2022 at 11:33:55 PM UTC-4, jla...@highlandsniptechnology.com wrote:
    On Fri, 19 Aug 2022 14:41:47 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 20.34.09 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation >> >>>> slope table and maybe just add. Do the math at compile time, not run >> >>>> time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right >> >>> amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating >> >>> arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at >> >>> least twice the filter's settling time (to the required accuracy), so >> >>> that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical >> >>> gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output >> >> jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. >> >> Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same >> >amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.
    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table,
    in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitide
    jumps bigger.

    multiply before truncating


    I think that makes jitter worse. It violates Nyquist reconstruction principles by adding sharp XO-clocked corners.

    Putting gain in front of a zero-crossing comparator does nothing. It's
    still a zero-crossing comparator.

    It is comments like these that make me doubt Larkin's sanity. Isn't he the one who started the idea in this thread of increasing the ramp rate by gain?

    --

    Rick C.

    -++ Get 1,000 miles of free Supercharging
    -++ Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Sat Aug 20 12:34:28 2022
    lørdag den 20. august 2022 kl. 05.33.55 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Fri, 19 Aug 2022 14:41:47 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 20.34.09 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation >> >>>> slope table and maybe just add. Do the math at compile time, not run >> >>>> time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right >> >>> amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating >> >>> arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at >> >>> least twice the filter's settling time (to the required accuracy), so >> >>> that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical >> >>> gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output >> >> jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. >> >> Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same >> >amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.
    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table,
    in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitide
    jumps bigger.

    multiply before truncating


    I think that makes jitter worse. It violates Nyquist reconstruction principles by adding sharp XO-clocked corners.

    Putting gain in front of a zero-crossing comparator does nothing. It's
    still a zero-crossing comparator.

    here's a simple example

    17bit accumulator, turned into 16bit 0-pi angle

    angle15_8 is upper 8bit of angle, used to index sine table to generate out1 anglex16clamp_11_4, is angle x16 clamped used as index sine table to generate out2

    https://imgur.com/gTpi1IA

    zoomed in on the zero crossing:

    https://imgur.com/vX27f0m

    zoomed in with same scale on out1 and out2:

    https://imgur.com/1vl9fZw

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Sat Aug 20 13:34:51 2022
    On Sat, 20 Aug 2022 12:34:28 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    lřrdag den 20. august 2022 kl. 05.33.55 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Fri, 19 Aug 2022 14:41:47 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 20.34.09 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation >> >> >>>> slope table and maybe just add. Do the math at compile time, not run >> >> >>>> time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right >> >> >>> amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating >> >> >>> arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at >> >> >>> least twice the filter's settling time (to the required accuracy), so >> >> >>> that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical >> >> >>> gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output >> >> >> jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the
    trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits. >> >> >> Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the
    slope at the zero crossing the same at all frequencies, allows the same >> >> >amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you
    do it the normal way.
    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table,
    in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitide
    jumps bigger.

    multiply before truncating


    I think that makes jitter worse. It violates Nyquist reconstruction
    principles by adding sharp XO-clocked corners.

    Putting gain in front of a zero-crossing comparator does nothing. It's
    still a zero-crossing comparator.

    here's a simple example

    17bit accumulator, turned into 16bit 0-pi angle

    angle15_8 is upper 8bit of angle, used to index sine table to generate out1 >anglex16clamp_11_4, is angle x16 clamped used as index sine table to generate out2

    https://imgur.com/gTpi1IA

    zoomed in on the zero crossing:

    https://imgur.com/vX27f0m

    Sure, you picked a lowpass filter to smooth out those giant slow
    steps. Some of those steps are half a microsecond.

    Try it with a filter that will work at 15 MHz.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Sat Aug 20 13:50:23 2022
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Sat, 20 Aug 2022 12:34:28 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    lørdag den 20. august 2022 kl. 05.33.55 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Fri, 19 Aug 2022 14:41:47 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 20.34.09 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table >> >> >>>> resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained >> >> >>> staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like. >> >> >>
    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many >> >> >> samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the >> >> >> trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits.
    Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the >> >> >slope at the zero crossing the same at all frequencies, allows the same
    amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you >> >> >do it the normal way.
    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table, >> >> in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitide
    jumps bigger.

    multiply before truncating


    I think that makes jitter worse. It violates Nyquist reconstruction
    principles by adding sharp XO-clocked corners.

    Putting gain in front of a zero-crossing comparator does nothing. It's
    still a zero-crossing comparator.

    here's a simple example

    17bit accumulator, turned into 16bit 0-pi angle

    angle15_8 is upper 8bit of angle, used to index sine table to generate out1 >anglex16clamp_11_4, is angle x16 clamped used as index sine table to generate out2

    https://imgur.com/gTpi1IA

    zoomed in on the zero crossing:

    https://imgur.com/vX27f0m

    Sure, you picked a lowpass filter to smooth out those giant slow
    steps. Some of those steps are half a microsecond.

    there is no filter, just scaled clamped indexing into the sine table

    Try it with a filter that will work at 15 MHz.

    there is no filter, it is raw samples from the sine table

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Sat Aug 20 18:04:24 2022
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    lřrdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Sat, 20 Aug 2022 12:34:28 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    lřrdag den 20. august 2022 kl. 05.33.55 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Fri, 19 Aug 2022 14:41:47 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    fredag den 19. august 2022 kl. 20.34.09 UTC+2 skrev John Larkin:
    On Fri, 19 Aug 2022 12:14:25 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/18/22 5:11 PM, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jla...@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <use...@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whi...@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table, two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10),
    you can make that one multiply and an add. Perhaps that's what the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table >> >> >> >>>> resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained >> >> >> >>> staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by
    the time you get to the zero crossing. If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like. >> >> >> >>
    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many >> >> >> >> samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    This argues for making the comparator trip at near the top of the >> >> >> >> trapezoid, not the mid-voltage zero crossing equivalent.

    One might make the trapezoid edge steeper at low synthesized
    frequencies and maybe incorporate more LSBish phase accumulator bits.
    Somehow. Seamlessly.


    You just multiply by 1/f, using saturating arithmetic. That keeps the >> >> >> >slope at the zero crossing the same at all frequencies, allows the same
    amount of time for the filter to settle, produces nearly the same
    settling artifacts, and so forth and so on. At high frequencies you >> >> >> >do it the normal way.
    At low frequencies, we need to use more of the bits of the phase
    accumulator, and equivalently more entries in the sine lookup table, >> >> >> in order to keep pumping out DAC codes at a rate the filter can
    smooth.

    Multiplying a sine lookup integer by 1/f just makes the amplitide
    jumps bigger.

    multiply before truncating


    I think that makes jitter worse. It violates Nyquist reconstruction
    principles by adding sharp XO-clocked corners.

    Putting gain in front of a zero-crossing comparator does nothing. It's
    still a zero-crossing comparator.

    here's a simple example

    17bit accumulator, turned into 16bit 0-pi angle

    angle15_8 is upper 8bit of angle, used to index sine table to generate out1 >> >anglex16clamp_11_4, is angle x16 clamped used as index sine table to generate out2

    https://imgur.com/gTpi1IA

    zoomed in on the zero crossing:

    https://imgur.com/vX27f0m

    Sure, you picked a lowpass filter to smooth out those giant slow
    steps. Some of those steps are half a microsecond.

    there is no filter, just scaled clamped indexing into the sine table

    Try it with a filter that will work at 15 MHz.

    there is no filter, it is raw samples from the sine table


    So, ignore the sine curve.

    The output of the sine table is still coarse steps, with no filter to interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to jla...@highlandsniptechnology.com on Sat Aug 20 20:35:45 2022
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense, and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not
    a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access
    to the PAST of the signal.

    Most vitally, in the Fourier-trasform sense, a frequency is DEFINITIVE of a sine,
    and no other signal, after filtering, has an unchanged 'frequency' character. If
    there's a filter involved, a sine is the One True Input form that gives you an output
    frequency to rely on. You aren't making a mess (or knife-fighting with "messer" items)
    when you consult a sine table, but are gathering wisdom from an oracle.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to All on Sat Aug 20 21:46:13 2022
    On Saturday, August 20, 2022 at 11:35:49 PM UTC-4, whit3rd wrote:
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.
    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense, and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access to the PAST of the signal.

    How is that different? Are you trying to say interpolation looks at future samples? Delay that interpolation output and you get the exact same thing as the filter output that only looks at past samples.


    Most vitally, in the Fourier-trasform sense, a frequency is DEFINITIVE of a sine,
    and no other signal, after filtering, has an unchanged 'frequency' character. If
    there's a filter involved, a sine is the One True Input form that gives you an output
    frequency to rely on. You aren't making a mess (or knife-fighting with "messer" items)
    when you consult a sine table, but are gathering wisdom from an oracle.

    The problem people are concerned about with the sine wave is that the slope is so shallow, that a very small amount of noise adds a large amount of jitter.

    Why can't people understand that the DDS can use a sine wave at the highest frequency, over a 2:1 range of frequency to generate the fundamental with very low jitter? This signal can be run through a programmable divider to divide the DDS output by
    octaves to obtain any lower frequency you wish, with the same jitter, other than jitter introduced by the logic implementation. This jitter can be removed by running the output through a FF of some technology that restores the jitter of the DDS output.

    None of this nonsense of trying to implement trapezoids is needed.

    --

    Rick C.

    +-- Get 1,000 miles of free Supercharging
    +-- Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to Ricky on Sat Aug 20 22:00:33 2022
    On Saturday, August 20, 2022 at 9:46:17 PM UTC-7, Ricky wrote:
    On Saturday, August 20, 2022 at 11:35:49 PM UTC-4, whit3rd wrote:

    Second, a filter does not 'interpolate' a time sequence, it only has access to the PAST of the signal.

    How is that different? Are you trying to say interpolation looks at future samples? Delay that interpolation output and you get the exact same thing as the filter output that only looks at past samples.

    If one wants 'interpolation', an FIR filter, applied in advance of the D-to-A step, can easily perform it;
    a real-components analog filter, though, cannot be described as an interpolation unless one has some kind
    of way of blinding the filter to the past AND the future of a time interval (maybe with delay lines?).
    The arrow-of-time is absent in true interpolation.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to Ricky on Sat Aug 20 22:16:32 2022
    On Sunday, August 21, 2022 at 2:46:17 PM UTC+10, Ricky wrote:
    On Saturday, August 20, 2022 at 11:35:49 PM UTC-4, whit3rd wrote:
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    <snip>

    Most vitally, in the Fourier-trasform sense, a frequency is DEFINITIVE of a sine,
    and no other signal, after filtering, has an unchanged 'frequency' character. If
    there's a filter involved, a sine is the One True Input form that gives you an output
    frequency to rely on. You aren't making a mess (or knife-fighting with "messer" items)
    when you consult a sine table, but are gathering wisdom from an oracle.
    The problem people are concerned about with the sine wave is that the slope is so shallow, that a very small amount of noise adds a large amount of jitter.

    Why can't people understand that the DDS can use a sine wave at the highest frequency, over a 2:1 range of frequency to generate the fundamental with very low jitter? This signal can be run through a programmable divider to divide the DDS output by
    octaves to obtain any lower frequency you wish, with the same jitter, other than jitter introduced by the logic implementation. This jitter can be removed by running the output through a FF of some technology that restores the jitter of the DDS output.

    None of this nonsense of trying to implement trapezoids is needed.

    The 2:1 range sine generator followed by divider would work. So would a trapeziod generator. The questions are which would be cheaper which is an interesting question and which would perform better, which isn't all that interesting because they'd
    probably perform identically if competently executed.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Jeroen Belleman on Sun Aug 21 10:36:21 2022
    On 18/08/2022 22:37, Jeroen Belleman wrote:
    On 2022-08-18 23:11, John Larkin wrote:
    On Thu, 18 Aug 2022 12:41:33 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 8/17/22 9:58 AM, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 17 Aug 2022 06:44:18 -0000 (UTC), Jasen Betts
    <usenet@revmaps.no-ip.org> wrote:

    On 2022-08-16, whit3rd <whit3rd@gmail.com> wrote:

    A smaller sine/cos table might be used with

    sine(a+b) = sine(a) cos(b) + cos(a)sine(b)

    as in, with small deviations 'b' from major steps in the table,
    two multiplies and
    an add give you 2^20 different accurate sines from a 2^10 size
    sine table.
    Since cos(b) will always be near unity ( 1 plus order of 2^-20
    when b is under 2^-10),
    you can make that one multiply and an add.    Perhaps that's what >>>>>> the 'phase
    accumulator' is for, estimating the 'b'?

    AKA "CORDIC"

    In an FPGA, one could have the basic sine table and an interpolation
    slope table and maybe just add. Do the math at compile time, not run
    time.

    At some point, dac resolution becomes the limit, not sine table
    resolution.


    Apologies if somebody has pointed this out upthread--I didn't follow
    it all.

    If you have enough bits in the phase accumulator, and apply the right
    amount of numerical gain ahead of the DAC, you can always get a
    well-behaved trapezoidal waveform with a nice smooth fine-grained
    staircase near the zero crossing, which will filter well. (Saturating
    arithmetic is required, obviously.)

    You just need to make sure that the duration of the linear part is at
    least twice the filter's settling time (to the required accuracy), so
    that the ringing from the corner of the trapezoid has all settled out by >>> the time you get to the zero crossing.  If you increase the numerical
    gain like 1/f, this works down to as low a frequency as you like.

    Right. The trapezoid corner happens at an XO edge, which makes output
    jitter, so the filter has to forget that corner but average as many
    samples as it can along the linear slope. The trapezoid is not
    bandlimited so violates the concept of the Sampling Theorem.

    [...]

    Don't use a trapezoid then. Approximate one summing a series
    of sinc(x).

    Sinc(x) is generally a bad idea in practice even if it is theoretically
    the optimum solution for band limited in the FT domain. It goes to zero
    far too slowly to be useful. If you want something reasonably well
    behaved then the prolate spheroidal Bessel functions are worth a look.

    Like Gaussians they have the interesting property that when band limited
    over a given domain then to within a scaling factor they are their own
    Fourier transform over that same domain (but not everywhere positive).

    They provide near optimum interpolation in one domain that is to within
    a multiplicative factor accurate in the Fourier transform domain. They
    are the eigenfunctions of repeatedly Fourier transforming a function and
    then band limiting it. The original paper by Slepian & Pollak 1960's is
    well worth a read if you have to do this stuff for real.

    https://onlinelibrary.wiley.com/doi/abs/10.1002/j.1538-7305.1961.tb03977.x

    https://arxiv.org/abs/1710.02874

    https://epubs.siam.org/doi/epdf/10.1137/1025078

    Slightly more recent but SIAM & Bell TJ behind a pay wall.


    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Sun Aug 21 08:12:57 2022
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    lřrdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to
    interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense,

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    looks pretty coarse to me. You only get small amplitude steps at low frequencies... and then you get slow unfiltered time steps too. That's
    the low frequency jitter problem. And in real life, low slopes reveal comparator imperfections too.


    and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not >a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access >to the PAST of the signal.

    Any real lowpass filter has time delay. So relative to its output, it
    is blending past and future inputs.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to jlarkin@highlandsniptechnology.com on Sun Aug 21 19:27:33 2022
    On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to
    interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense,

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    looks pretty coarse to me. You only get small amplitude steps at low frequencies... and then you get slow unfiltered time steps too. That's
    the low frequency jitter problem. And in real life, low slopes reveal comparator imperfections too.


    and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not
    a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access >> to the PAST of the signal.

    Any real lowpass filter has time delay. So relative to its output, it
    is blending past and future inputs.


    As far as I can see you are going to do sine wave. In that case I would
    do as much brute force as is practical - the is, as long a sine lookup
    table as possible - and then interpolate. Those dsp sections they put
    in fpga-s must be kept busy? 10 ns is not a lot of time to do it but
    it must be doable. And second or even third order interpolation
    is not that hard - and can probably give you virtually error free
    values even for the 1mHz case.
    Easier said than done I suppose but that's the advantage of giving
    an opinion and not having to deliver the goods.... :D.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Sun Aug 21 09:40:09 2022
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    lřrdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to
    interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense,

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    looks pretty coarse to me. You only get small amplitude steps at low
    frequencies... and then you get slow unfiltered time steps too. That's
    the low frequency jitter problem. And in real life, low slopes reveal
    comparator imperfections too.


    and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not
    a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access >>> to the PAST of the signal.

    Any real lowpass filter has time delay. So relative to its output, it
    is blending past and future inputs.


    As far as I can see you are going to do sine wave. In that case I would
    do as much brute force as is practical - the is, as long a sine lookup
    table as possible - and then interpolate. Those dsp sections they put
    in fpga-s must be kept busy? 10 ns is not a lot of time to do it but
    it must be doable. And second or even third order interpolation
    is not that hard - and can probably give you virtually error free
    values even for the 1mHz case.
    Easier said than done I suppose but that's the advantage of giving
    an opinion and not having to deliver the goods.... :D.

    It has been suggested that, at low frequencies, we interpolate between
    sine table entries so we can keep approximating the sine wave at the
    100 MHz clock rate, instead of making a step now and then as the
    selected MS bits of the phase accumulator tick over. That does still
    make a slow sine wave at the lowpass filter output.

    Straight-line interpolation is probably good enough for short segments
    of a sine. The interpolation slopes could be another lookup table.

    The idea of making a perfect DDS clock is a deliciously complex
    problem. Just thinking about it is educational.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From antispam@math.uni.wroc.pl@21:1/5 to Anthony William Sloman on Sun Aug 21 17:42:14 2022
    Anthony William Sloman <bill.sloman@ieee.org> wrote:
    It strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.

    You would still use a fast 14- or 16 bit DAC, but the waveform you fed into your comparator would be made up of four sequential components - all coming out of the DAC - high segment of arbitrary length, a falling edge, a low segment, and a risng edge

    With a 14-bit DAC - the LTC2000 comes to mind

    https://www.analog.com/media/en/technical-documentation/data-sheets/2000fb.pdf

    you'd synthisese the rising and falling edges of the trapezia as 16-successive steps of a staircase waveform.

    The LTC2000 can be clocked at 2.5GHz, so the rising and falling edges could be just 6.4nsec wide, and your maximum full amplitude output frequency would be a 78MHz triangular wave.

    The trick is that you could have 1024 different rising or falling edges, with all the steps moved up or down in in steps of 0.1% of the full scale swing.

    Only the first and last steps of the staircase would look different.

    If you low pass filtered the waveform the zero crossing point would move across the 0.4nsec clock period in steps of 0.4psec.

    The trick would be to use a Bessel - linear phase - filter which has a little bit of output ripple (figure 2.58 in Williams and Taylor) where the impulse response crosses the zero line, and put that point at the 3.2 nsec zero-crossing point ( picking
    the filter time constant to be about 0.64nsec, depending on the filter order) which would stop the odd first step from having much effect on the zero crossing point.

    You could get any frequency less than 78.125 MHz, and you could step the period up in increments of 0.4.psec. 78.123 MHz would be the next one down

    Because your filter only deals with rising an falling edges, you don't need to change it when you are synthesising much slower square waves.


    That could work, but looks somewhat suboptimal. Generally, let us
    assume that we try to generate some periodic f(t) and pass result
    to comparator. Due to discrete nature of syntesis we will
    have some error, call it r(t). So comparator instead at zeros
    of f(t) will switch at zeros of f(t) + r(t). Assuming that error
    is resonably small we can estimate shift of zero using deriavative
    of f: delta t_0 \approx -r(t_0)/f'(t_0). So, to have best accuracy
    we want:
    - have f' at zeros of f as big as possible
    - have r as small as possible

    Let us first look at r, there are two components to error.
    One is discretization error of voltage level due to finite
    resulution from DAC. Second, due to discrete time we get
    mirror freqencies. More precisly, when

    f(t) = \sum_n c_n \exp(iw_1nt)

    (where i is imaginary unit), and w_1 pulsation of f,
    discrete time version g(t) has form

    g(t) = \sum_n \sum_m c_n \exp(i(w_1n + w_2m)t)

    where w_2 is pulsation of DAC clock. We apply low pass filter
    to eliminate unwanted high frequencies. It seems that frequent
    choice is filter with bandpass up to w_2/3 and delivering
    string attenuation at 2w_2/3. Now, if |w_1n + w_2m| < w_2/3
    mirror freqency will be in bandpass. For m not equal to 0
    it means that c_n should be very small, preferably 0 (othewise
    we will get error which can not be removed by filtering).
    In other words, to avoid error immune to filtering we want
    c_n to be 0 when |w_1n| > w_2/3. So f(t) should be
    trigonometric polynomial with frequencies satifying condition
    above.

    Now, we want f which has fast transition trough 0. Obvious
    choice is trigonometric approximation to square wave. This
    has horrible ringing. Theoretically, if phase shifts vary
    within 20-30 degrees over bandpass ringing should be no
    problem. If ringing turns out to be problematic one can
    reduce it using trigonmetric approximation to trapezoidal
    waveform, getting slower transition.


    --
    Waldek Hebisch

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to jlarkin@highlandsniptechnology.com on Sun Aug 21 22:02:52 2022
    On 8/21/2022 19:40, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen >>>>> <lang...@fonz.dk> wrote:

    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to >>>>> interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense,

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    looks pretty coarse to me. You only get small amplitude steps at low
    frequencies... and then you get slow unfiltered time steps too. That's
    the low frequency jitter problem. And in real life, low slopes reveal
    comparator imperfections too.


    and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not
    a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access
    to the PAST of the signal.

    Any real lowpass filter has time delay. So relative to its output, it
    is blending past and future inputs.


    As far as I can see you are going to do sine wave. In that case I would
    do as much brute force as is practical - the is, as long a sine lookup
    table as possible - and then interpolate. Those dsp sections they put
    in fpga-s must be kept busy? 10 ns is not a lot of time to do it but
    it must be doable. And second or even third order interpolation
    is not that hard - and can probably give you virtually error free
    values even for the 1mHz case.
    Easier said than done I suppose but that's the advantage of giving
    an opinion and not having to deliver the goods.... :D.

    It has been suggested that, at low frequencies, we interpolate between
    sine table entries so we can keep approximating the sine wave at the
    100 MHz clock rate, instead of making a step now and then as the
    selected MS bits of the phase accumulator tick over. That does still
    make a slow sine wave at the lowpass filter output.

    Straight-line interpolation is probably good enough for short segments
    of a sine. The interpolation slopes could be another lookup table.

    The idea of making a perfect DDS clock is a deliciously complex
    problem. Just thinking about it is educational.


    Educational it certainly is, I'd say it will take more brute force
    than complexity but it is clearly a lot harder than it seems at first
    glance.
    I'd make sure I have the horsepowers in case linear interpolation is
    not good enough and I'd have to go second or third order... I have not experience with these fpga dsp sections but I have seen some have
    dozens of them, the interpolation needed can be parallelized as much
    as it takes. Dealing with the heath may also be needed :).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to All on Sun Aug 21 12:51:09 2022
    On Sunday, August 21, 2022 at 1:00:37 AM UTC-4, whit3rd wrote:
    On Saturday, August 20, 2022 at 9:46:17 PM UTC-7, Ricky wrote:
    On Saturday, August 20, 2022 at 11:35:49 PM UTC-4, whit3rd wrote:

    Second, a filter does not 'interpolate' a time sequence, it only has access
    to the PAST of the signal.

    How is that different? Are you trying to say interpolation looks at future samples? Delay that interpolation output and you get the exact same thing as the filter output that only looks at past samples.
    If one wants 'interpolation', an FIR filter, applied in advance of the D-to-A step, can easily perform it;
    a real-components analog filter, though, cannot be described as an interpolation unless one has some kind
    of way of blinding the filter to the past AND the future of a time interval (maybe with delay lines?).
    The arrow-of-time is absent in true interpolation.

    Ok, so you are picking a nit. I'm not aware of any definition of "interpolate" that requires it be limited to inputs of specific samples. It simply means values are inserted. I've seen digital interpolation by inserting samples with values of zero
    and having no correspondence to the samples on the input stream.

    If you want to *average* in analog, I can do that with sample and holds and an opamp to combine the two values. Not so har really.

    --

    Rick C.

    +-+ Get 1,000 miles of free Supercharging
    +-+ Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to jlarkin@highlandsniptechnology.com on Sun Aug 21 23:35:04 2022
    On 8/21/2022 19:40, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen >>>>> <lang...@fonz.dk> wrote:

    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to >>>>> interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense,

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    looks pretty coarse to me. You only get small amplitude steps at low
    frequencies... and then you get slow unfiltered time steps too. That's
    the low frequency jitter problem. And in real life, low slopes reveal
    comparator imperfections too.


    and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not
    a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access
    to the PAST of the signal.

    Any real lowpass filter has time delay. So relative to its output, it
    is blending past and future inputs.


    As far as I can see you are going to do sine wave. In that case I would
    do as much brute force as is practical - the is, as long a sine lookup
    table as possible - and then interpolate. Those dsp sections they put
    in fpga-s must be kept busy? 10 ns is not a lot of time to do it but
    it must be doable. And second or even third order interpolation
    is not that hard - and can probably give you virtually error free
    values even for the 1mHz case.
    Easier said than done I suppose but that's the advantage of giving
    an opinion and not having to deliver the goods.... :D.

    It has been suggested that, at low frequencies, we interpolate between
    sine table entries so we can keep approximating the sine wave at the
    100 MHz clock rate, instead of making a step now and then as the
    selected MS bits of the phase accumulator tick over. That does still
    make a slow sine wave at the lowpass filter output.

    Straight-line interpolation is probably good enough for short segments
    of a sine. The interpolation slopes could be another lookup table.

    The idea of making a perfect DDS clock is a deliciously complex
    problem. Just thinking about it is educational.


    I did a quick misuse of my filter editor to draw a sine wave and
    see what interpolation looks like. 64 points, interpolated into
    16384 points. You'll need a lot more than that but this might give
    an idea. The linear interpolation looks edgy, but the difference
    between second ad third order interpolation is practically invisible at
    this scale.
    http://tgi-sci.com/misc/sine_all.gif <-- the whole period
    then a small region at the top:
    http://tgi-sci.com/misc/sine_1.gif <-- first order interpolation, http://tgi-sci.com/misc/sine_2.gif <-- second order, http://tgi-sci.com/misc/sine_3.gif <-- third order.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to jla...@highlandsniptechnology.com on Sun Aug 21 17:27:53 2022
    On Monday, August 22, 2022 at 1:13:07 AM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote: >On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    <snip>

    Any real lowpass filter has time delay. So relative to its output, it
    is blending past and future inputs.

    No real low pass filter is ever going to blend in future inputs. The output is a weighed sum of past inputs, but future inputs are inaccessible.

    The most recent past input won't have much effect on the output - that's the time delay through the filter - bu there's a whole load of theory that spells that out in detail. Read Williams and Taylor.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to All on Sun Aug 21 17:41:02 2022
    On Sunday, August 21, 2022 at 1:35:49 PM UTC+10, whit3rd wrote:
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense, and you can dither and interpose as many time
    steps of alternating values as you care to.

    Coarse in time is a choice, not a requirement.

    Actually, it is fundamental to the digital domain. You have to start off with one low jitter clock, and every digital output is clocked out by that single clock.

    The whole point of the low pass filter in a DDS set-up is to cope with with the fact that you've only got one set of clock edges to play with.

    Second, a filter does not 'interpolate' a time sequence, it only has access to the PAST of the signal.

    Most vitally, in the Fourier-trasform sense, a frequency is DEFINITIVE of a sine,
    and no other signal, after filtering, has an unchanged 'frequency' character. If
    there's a filter involved, a sine is the One True Input form that gives you an output
    frequency to rely on. You aren't making a mess (or knife-fighting with "messer" items)
    when you consult a sine table, but are gathering wisdom from an oracle.

    All true. But without the low pass filter, the staircase artefacts add a lot of higher frequencies into your One True sine wave.

    That's what John Larkin is rather ineptly wresting with.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to Dimiter Popoff on Sun Aug 21 17:46:47 2022
    On Monday, August 22, 2022 at 6:35:14 AM UTC+10, Dimiter Popoff wrote:
    On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen >>>>> <lang...@fonz.dk> wrote:
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    It has been suggested that, at low frequencies, we interpolate between sine table entries so we can keep approximating the sine wave at the
    100 MHz clock rate, instead of making a step now and then as the
    selected MS bits of the phase accumulator tick over. That does still
    make a slow sine wave at the lowpass filter output.

    Straight-line interpolation is probably good enough for short segments
    of a sine. The interpolation slopes could be another lookup table.

    The idea of making a perfect DDS clock is a deliciously complex
    problem. Just thinking about it is educational.

    We are looking forward to you starting on that. at moment you are merely being confused about what's going on.

    I did a quick misuse of my filter editor to draw a sine wave and
    see what interpolation looks like. 64 points, interpolated into
    16384 points. You'll need a lot more than that but this might give
    an idea. The linear interpolation looks edgy, but the difference
    between second ad third order interpolation is practically invisible at
    this scale.

    Since you can't use digital interpolation to get your zero=-crossing point any where except on your master clock edges, it's not worth thinking about.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to All on Sun Aug 21 21:12:38 2022
    On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 19:40, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen >>>>>> <lang...@fonz.dk> wrote:

    lřrdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to >>>>>> interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense,

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    looks pretty coarse to me. You only get small amplitude steps at low
    frequencies... and then you get slow unfiltered time steps too. That's >>>> the low frequency jitter problem. And in real life, low slopes reveal
    comparator imperfections too.


    and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not
    a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access
    to the PAST of the signal.

    Any real lowpass filter has time delay. So relative to its output, it
    is blending past and future inputs.


    As far as I can see you are going to do sine wave. In that case I would
    do as much brute force as is practical - the is, as long a sine lookup
    table as possible - and then interpolate. Those dsp sections they put
    in fpga-s must be kept busy? 10 ns is not a lot of time to do it but
    it must be doable. And second or even third order interpolation
    is not that hard - and can probably give you virtually error free
    values even for the 1mHz case.
    Easier said than done I suppose but that's the advantage of giving
    an opinion and not having to deliver the goods.... :D.

    It has been suggested that, at low frequencies, we interpolate between
    sine table entries so we can keep approximating the sine wave at the
    100 MHz clock rate, instead of making a step now and then as the
    selected MS bits of the phase accumulator tick over. That does still
    make a slow sine wave at the lowpass filter output.

    Straight-line interpolation is probably good enough for short segments
    of a sine. The interpolation slopes could be another lookup table.

    The idea of making a perfect DDS clock is a deliciously complex
    problem. Just thinking about it is educational.


    I did a quick misuse of my filter editor to draw a sine wave and
    see what interpolation looks like. 64 points, interpolated into
    16384 points. You'll need a lot more than that but this might give
    an idea. The linear interpolation looks edgy, but the difference
    between second ad third order interpolation is practically invisible at
    this scale.
    <http://tgi-sci.com/misc/sine_all.gif> <-- the whole period
    then a small region at the top:
    <http://tgi-sci.com/misc/sine_1.gif> <-- first order interpolation, <http://tgi-sci.com/misc/sine_2.gif> <-- second order,
    < http://tgi-sci.com/misc/sine_3.gif> <-- third order.

    What about the zero-crossing region? That's the critical area. Cubic
    may be best there.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Joe Gwinn on Sun Aug 21 18:35:43 2022
    On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
    On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:

    On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> >>>> wrote:

    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen >>>>>> <lang...@fonz.dk> wrote:

    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to >>>>>> interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense,

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    looks pretty coarse to me. You only get small amplitude steps at low >>>> frequencies... and then you get slow unfiltered time steps too. That's >>>> the low frequency jitter problem. And in real life, low slopes reveal >>>> comparator imperfections too.


    and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not
    a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access
    to the PAST of the signal.

    Any real lowpass filter has time delay. So relative to its output, it >>>> is blending past and future inputs.


    As far as I can see you are going to do sine wave. In that case I would >>> do as much brute force as is practical - the is, as long a sine lookup >>> table as possible - and then interpolate. Those dsp sections they put >>> in fpga-s must be kept busy? 10 ns is not a lot of time to do it but
    it must be doable. And second or even third order interpolation
    is not that hard - and can probably give you virtually error free
    values even for the 1mHz case.
    Easier said than done I suppose but that's the advantage of giving
    an opinion and not having to deliver the goods.... :D.

    It has been suggested that, at low frequencies, we interpolate between
    sine table entries so we can keep approximating the sine wave at the
    100 MHz clock rate, instead of making a step now and then as the
    selected MS bits of the phase accumulator tick over. That does still
    make a slow sine wave at the lowpass filter output.

    Straight-line interpolation is probably good enough for short segments
    of a sine. The interpolation slopes could be another lookup table.

    The idea of making a perfect DDS clock is a deliciously complex
    problem. Just thinking about it is educational.


    I did a quick misuse of my filter editor to draw a sine wave and
    see what interpolation looks like. 64 points, interpolated into
    16384 points. You'll need a lot more than that but this might give
    an idea. The linear interpolation looks edgy, but the difference
    between second ad third order interpolation is practically invisible at >this scale.
    <http://tgi-sci.com/misc/sine_all.gif> <-- the whole period
    then a small region at the top:
    <http://tgi-sci.com/misc/sine_1.gif> <-- first order interpolation, <http://tgi-sci.com/misc/sine_2.gif> <-- second order,
    < http://tgi-sci.com/misc/sine_3.gif> <-- third order.

    What about the zero-crossing region? That's the critical area. Cubic
    may be best there.

    For a sine wave the zero crossing is the point where the function is perfectly linear.

    I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass filter and
    comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It's not like this is a new problem.

    The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.

    --

    Rick C.

    ++- Get 1,000 miles of free Supercharging
    ++- Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to Ricky on Sun Aug 21 18:49:57 2022
    On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote:
    On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
    On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    <snip>

    For a sine wave the zero crossing is the point where the function is perfectly linear.

    I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass filter
    and comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It's not like this is a new problem.

    The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.

    That's exactly what it avoids.The sloped bits of the trapezoid were to have exactly the same slope no matter what frequency is being generated. Same slope, same low pass filter. Massive simplification.

    Really fast 14--bit DACs aren't cheap, but once John Larkin specified his maximum frequency to be 15MHz, and his master clock frequency as 100MHz, slower cheaper DACs would be worth looking for, if there was any prospect that he'd pay any attention.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to Joe Gwinn on Mon Aug 22 05:18:22 2022
    On 8/22/2022 4:12, Joe Gwinn wrote:
    On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 19:40, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>> wrote:

    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen >>>>>>> <lang...@fonz.dk> wrote:

    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to >>>>>>> interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense,

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    looks pretty coarse to me. You only get small amplitude steps at low >>>>> frequencies... and then you get slow unfiltered time steps too. That's >>>>> the low frequency jitter problem. And in real life, low slopes reveal >>>>> comparator imperfections too.


    and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not
    a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access
    to the PAST of the signal.

    Any real lowpass filter has time delay. So relative to its output, it >>>>> is blending past and future inputs.


    As far as I can see you are going to do sine wave. In that case I would >>>> do as much brute force as is practical - the is, as long a sine lookup >>>> table as possible - and then interpolate. Those dsp sections they put
    in fpga-s must be kept busy? 10 ns is not a lot of time to do it but
    it must be doable. And second or even third order interpolation
    is not that hard - and can probably give you virtually error free
    values even for the 1mHz case.
    Easier said than done I suppose but that's the advantage of giving
    an opinion and not having to deliver the goods.... :D.

    It has been suggested that, at low frequencies, we interpolate between
    sine table entries so we can keep approximating the sine wave at the
    100 MHz clock rate, instead of making a step now and then as the
    selected MS bits of the phase accumulator tick over. That does still
    make a slow sine wave at the lowpass filter output.

    Straight-line interpolation is probably good enough for short segments
    of a sine. The interpolation slopes could be another lookup table.

    The idea of making a perfect DDS clock is a deliciously complex
    problem. Just thinking about it is educational.


    I did a quick misuse of my filter editor to draw a sine wave and
    see what interpolation looks like. 64 points, interpolated into
    16384 points. You'll need a lot more than that but this might give
    an idea. The linear interpolation looks edgy, but the difference
    between second ad third order interpolation is practically invisible at
    this scale.
    <http://tgi-sci.com/misc/sine_all.gif> <-- the whole period
    then a small region at the top:
    <http://tgi-sci.com/misc/sine_1.gif> <-- first order interpolation,
    <http://tgi-sci.com/misc/sine_2.gif> <-- second order,
    < http://tgi-sci.com/misc/sine_3.gif> <-- third order.

    What about the zero-crossing region? That's the critical area. Cubic
    may be best there.

    Joe Gwinn

    I'll screenshot it tomorrow, now I am briefly awake only... :)
    [some noise woke me up, stopped when I turned on the light;
    was very faint, I lay listening for may be 2-3 minutes.
    May be some insect or something...).]
    I looked at the zero crossing region, it is the steepest
    and closest to linear. Perhaps the top was the least linear,
    did not look too much though.
    But if just the zero-crossing were the problematic area no sine
    would be necessary anyway (which is what I thought once I knew
    it was about just triggering something but John wants a perfect
    sine).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to bill....@ieee.org on Sun Aug 21 19:27:38 2022
    On Sunday, August 21, 2022 at 5:41:06 PM UTC-7, bill....@ieee.org wrote:
    On Sunday, August 21, 2022 at 1:35:49 PM UTC+10, whit3rd wrote:
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense, and you can dither and interpose as many time
    steps of alternating values as you care to.

    Coarse in time is a choice, not a requirement.

    Actually, it is fundamental to the digital domain. You have to start off with one low jitter clock, and every digital output is clocked out by that single clock.

    The whole point of the low pass filter in a DDS set-up is to cope with with the fact that you've only got one set of clock edges to play with.

    But, if you decide on a thousand-point table for the DAC to perform, all it takes is a
    tiny bit of logic in a tight-time loop to weighted-sum two DAC outputs, one for the last sample
    another for the next sample, in analog summing-junction style, thus actually doing an
    interpolation as mentioned. Even though the points as DAC-generated number only
    a thousand, you don't need to have a thousand-step staircase, it could also
    be a finer staircase hitting those thousand marks, but microstepping between.

    My preference would be to do that all analog, phase-locking to make the inner clock for the lowest
    output frequencies. Needn't be any microstepping, if current-steering is run by a trianglewave
    VCO.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to bill....@ieee.org on Sun Aug 21 21:07:03 2022
    On Sunday, August 21, 2022 at 9:50:01 PM UTC-4, bill....@ieee.org wrote:
    On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote:
    On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
    On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:
    <snip>
    For a sine wave the zero crossing is the point where the function is perfectly linear.

    I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass filter
    and comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It's not like this is a new problem.

    The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.
    That's exactly what it avoids.The sloped bits of the trapezoid were to have exactly the same slope no matter what frequency is being generated. Same slope, same low pass filter. Massive simplification.

    Sounds good on the downstream side, but how do you generate the samples to feed the DAC? If you want to have variable frequency, you need to adjust the lookup table for every frequency you choose. How else are you generating the DAC samples?

    You can't just load the table with one set of values and expect it to generate the same slope for every frequency. If you use the same LUT for a slow and fast output frequency, the fast output frequency would have a large enough step size through the
    LUT to literally skip over the ramp. At sufficiently low sample rates, the slow again turns into a slow ramp.

    Is this about no LUT at all? Just using the LSBs of the phase ramp? But that still gives you varying ramp slopes.

    --

    Rick C.

    +++ Get 1,000 miles of free Supercharging
    +++ Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to Ricky on Sun Aug 21 22:07:45 2022
    On Monday, August 22, 2022 at 2:07:08 PM UTC+10, Ricky wrote:
    On Sunday, August 21, 2022 at 9:50:01 PM UTC-4, bill....@ieee.org wrote:
    On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote:
    On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
    On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:
    <snip>
    For a sine wave the zero crossing is the point where the function is perfectly linear.

    I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass
    filter and comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It's not like this is a new problem.


    The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.

    That's exactly what it avoids.The sloped bits of the trapezoid were to have exactly the same slope no matter what frequency is being generated. Same slope, same low pass filter. Massive simplification.

    Sounds good on the downstream side, but how do you generate the samples to feed the DAC? If you want to have variable frequency, you need to adjust the lookup table for every frequency you choose. How else are you generating the DAC samples?

    It's just arithmetic. Your programmable logic gets told how much time you want between each zero crossing and programs the counter to step the DAC along at maximum or minimum output until you want the ramp to start, then steps it through the ramp look-up
    table picking up the series of values that will put the zero-crossing in the right place.

    You can't just load the table with one set of values and expect it to generate the same slope for every frequency.

    Actually you can. There are going to be a lot of different ramps in there - each with the same slope - each one putting the zero-crossings at different particular offsets from the clock, and the arithmetic engine has to pick the right set of sample to
    generate the right ramp.

    If the clock ticks are the integral part of the delay, the offset of the zero-crossing from the clock tick is the fractional part, and you pick the set of DAC inputs you want to give you that offset, and step through just them.

    If you use the same LUT for a slow and fast output frequency, the fast output frequency would have a large enough step size through the LUT to literally skip over the ramp. At sufficiently low sample rates, the slow again turns into a slow ramp.

    It might if you weren't thinking about what you were doing.

    Is this about no LUT at all? Just using the LSBs of the phase ramp? But that still gives you varying ramp slopes.

    Obviously not.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to bill....@ieee.org on Mon Aug 22 01:37:34 2022
    On Monday, August 22, 2022 at 1:07:49 AM UTC-4, bill....@ieee.org wrote:
    On Monday, August 22, 2022 at 2:07:08 PM UTC+10, Ricky wrote:
    On Sunday, August 21, 2022 at 9:50:01 PM UTC-4, bill....@ieee.org wrote:
    On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote:
    On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
    On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote: >>>> On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:
    <snip>
    For a sine wave the zero crossing is the point where the function is perfectly linear.

    I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass
    filter and comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It's not like this is a new problem.


    The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.

    That's exactly what it avoids.The sloped bits of the trapezoid were to have exactly the same slope no matter what frequency is being generated. Same slope, same low pass filter. Massive simplification.

    Sounds good on the downstream side, but how do you generate the samples to feed the DAC? If you want to have variable frequency, you need to adjust the lookup table for every frequency you choose. How else are you generating the DAC samples?
    It's just arithmetic. Your programmable logic gets told how much time you want between each zero crossing and programs the counter to step the DAC along at maximum or minimum output until you want the ramp to start, then steps it through the ramp look-
    up table picking up the series of values that will put the zero-crossing in the right place.

    What you are describing won't get you the timing alignment required. The point of the DDS is to provide a waveform that, once filtered, has accuracy better than the clock period. The sine generation uses additional resolution in amplitude to provide
    additional resolution in timing.


    You can't just load the table with one set of values and expect it to generate the same slope for every frequency.
    Actually you can. There are going to be a lot of different ramps in there - each with the same slope - each one putting the zero-crossings at different particular offsets from the clock, and the arithmetic engine has to pick the right set of sample to
    generate the right ramp.

    I'm not sure what "logic" you are describing. I think you have not looked at how the logic would need to operate if you aren't using a LUT.


    If the clock ticks are the integral part of the delay, the offset of the zero-crossing from the clock tick is the fractional part, and you pick the set of DAC inputs you want to give you that offset, and step through just them.

    You "pick"? Yes, that's a good description if you aren't actually designing it. The phase accumulator controls the timing and selects the amplitude through the lookup table. I'm not picturing how this would work usefully to generate a largely
    rectangular pulse with the same rise/fall times independent of frequency. So something else would need to be used. I'm not sure how you get the appropriate fractional clock timing.


    If you use the same LUT for a slow and fast output frequency, the fast output frequency would have a large enough step size through the LUT to literally skip over the ramp. At sufficiently low sample rates, the slow again turns into a slow ramp.
    It might if you weren't thinking about what you were doing.

    Typical Sloman response when he is in over his head. You don't actually know what you are doing at this point, so you criticize the person you are talking to. Ok, I get it.


    Is this about no LUT at all? Just using the LSBs of the phase ramp? But that still gives you varying ramp slopes.
    Obviously not.

    If you say so.

    Bottom line is, this complex goofy thing is not even needed. A programmable octave divider can follow a proper DDS using a 2:1 range to give the same timing precision and jitter from any frequency the DDS outputs down as low as you wish to go. No goofy
    complexities. Just a simple design that has been proven over and over again. If all the logic is implemented in the same FPGA, it can all be updated simultaneously to never cause a glitch in the pulse timing.

    --

    Rick C.

    ---- Get 1,000 miles of free Supercharging
    ---- Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to Ricky on Mon Aug 22 04:54:10 2022
    On Monday, August 22, 2022 at 6:37:38 PM UTC+10, Ricky wrote:
    On Monday, August 22, 2022 at 1:07:49 AM UTC-4, bill....@ieee.org wrote:
    On Monday, August 22, 2022 at 2:07:08 PM UTC+10, Ricky wrote:
    On Sunday, August 21, 2022 at 9:50:01 PM UTC-4, bill....@ieee.org wrote:
    On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote:
    On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
    On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
    On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote: >>>> On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
    lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    <snip>

    For a sine wave the zero crossing is the point where the function is perfectly linear.

    I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass
    filter and comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It's not like this is a new problem.


    The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.

    That's exactly what it avoids.The sloped bits of the trapezoid were to have exactly the same slope no matter what frequency is being generated. Same slope, same low pass filter. Massive simplification.

    Sounds good on the downstream side, but how do you generate the samples to feed the DAC? If you want to have variable frequency, you need to adjust the lookup table for every frequency you choose. How else are you generating the DAC samples?

    It's just arithmetic. Your programmable logic gets told how much time you want between each zero crossing and programs the counter to step the DAC along at maximum or minimum output until you want the ramp to start, then steps it through the ramp
    look-up table picking up the series of values that will put the zero-crossing in the right place.

    What you are describing won't get you the timing alignment required.

    It will.

    The point of the DDS is to provide a waveform that, once filtered, has accuracy better than the clock period. The sine generation uses additional resolution in amplitude to provide additional resolution in timing.

    In John Larkin's application, you only need to get it right at the zero-crossing points, and the trapezium approach provides the extra resolution where you need it, and pretty much only where you need it.

    You can't just load the table with one set of values and expect it to generate the same slope for every frequency.

    Actually you can. There are going to be a lot of different ramps in there - each with the same slope - each one putting the zero-crossings at different particular offsets from the clock, and the arithmetic engine has to pick the right set of sample
    to generate the right ramp.

    I'm not sure what "logic" you are describing. I think you have not looked at how the logic would need to operate if you aren't using a LUT.

    You are using look-up table. For a 14-bit DAC you'd select one of 1024 possible 16-step ramps to get the zero -crossing at one of 1024 possible points between clock edges.

    If the clock ticks are the integral part of the delay, the offset of the zero-crossing from the clock tick is the fractional part, and you pick the set of DAC inputs you want to give you that offset, and step through just them.

    After each output edge you use an adder to work out exactly when the next output clock edge has to appear. You know where the last output clock edge was - to an integral number of clock ticks plus that fraction of the tick that you set up, and you just
    add the delay you want to get time location of the next output clock edge. The sum has integral number of clock ticks plus a fractional part. You start the ramp exactly eight clock ticks before the interval where you want to the zero crossing to happen,
    and the fractional part selects which of the 1024 possible ramps you chose to get the next clock edge in the right place.

    It's just arithmetic.

    You "pick"? Yes, that's a good description if you aren't actually designing it.

    It's a brief description that tells you what the design has to do. It doesn't seem to have told you enough.

    The phase accumulator controls the timing and selects the amplitude through the lookup table. I'm not picturing how this would work usefully to generate a largely rectangular pulse with the same rise/fall times independent of frequency. So something
    else would need to be used. I'm not sure how you get the appropriate fractional clock timing.

    If you use the same LUT for a slow and fast output frequency, the fast output frequency would have a large enough step size through the LUT to literally skip over the ramp. At sufficiently low sample rates, the slow again turns into a slow ramp.

    It might if you weren't thinking about what you were doing.

    Typical Sloman response when he is in over his head. You don't actually know what you are doing at this point, so you criticize the person you are talking to.

    I knew exactly what I was doing, but I was keeping the description short.

    Ok, I get it.

    You clearly didn't.

    Is this about no LUT at all? Just using the LSBs of the phase ramp? But that still gives you varying ramp slopes.

    Obviously not.

    If you say so.

    I do say so, and I hope I've given enough detail this time around so that it is now as obvious to you as it was to me.

    Bottom line is, this complex goofy thing is not even needed.

    The fact that you didn't get it doesn't actually make it goofy, and it's less complex than a DDS because it's only making the square wave and leaving out the sine.

    Analog Devices will sell you the whole DDS as a single (expensive) chip which would make life simpler for the designer, but it may not be the cheapest, or the lowest jitter solution.

    A programmable octave divider can follow a proper DDS using a 2:1 range to give the same timing precision and jitter from any frequency the DDS outputs down as low as you wish to go. No goofy complexities.

    None that you are aware of.

    Just a simple design that has been proven over and over again. If all the logic is implemented in the same FPGA, it can all be updated simultaneously to never cause a glitch in the pulse timing.

    If you use a DDS chip. most of the logic is implemented inside the chip, not in an FPGA. My impression was that John Larkin was planning on avoiding paying for an expensive DDS chip by doing his own logic in an FPGA and using it to drive a DAC, which is
    perfectly feasible, if rather fiddly.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to All on Mon Aug 22 10:57:11 2022
    On Mon, 22 Aug 2022 05:18:22 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/22/2022 4:12, Joe Gwinn wrote:
    On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 19:40, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>>> wrote:

    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen >>>>>>>> <lang...@fonz.dk> wrote:

    lřrdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to >>>>>>>> interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense,

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    looks pretty coarse to me. You only get small amplitude steps at low >>>>>> frequencies... and then you get slow unfiltered time steps too. That's >>>>>> the low frequency jitter problem. And in real life, low slopes reveal >>>>>> comparator imperfections too.


    and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not
    a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access
    to the PAST of the signal.

    Any real lowpass filter has time delay. So relative to its output, it >>>>>> is blending past and future inputs.


    As far as I can see you are going to do sine wave. In that case I would >>>>> do as much brute force as is practical - the is, as long a sine lookup >>>>> table as possible - and then interpolate. Those dsp sections they put >>>>> in fpga-s must be kept busy? 10 ns is not a lot of time to do it but >>>>> it must be doable. And second or even third order interpolation
    is not that hard - and can probably give you virtually error free
    values even for the 1mHz case.
    Easier said than done I suppose but that's the advantage of giving
    an opinion and not having to deliver the goods.... :D.

    It has been suggested that, at low frequencies, we interpolate between >>>> sine table entries so we can keep approximating the sine wave at the
    100 MHz clock rate, instead of making a step now and then as the
    selected MS bits of the phase accumulator tick over. That does still
    make a slow sine wave at the lowpass filter output.

    Straight-line interpolation is probably good enough for short segments >>>> of a sine. The interpolation slopes could be another lookup table.

    The idea of making a perfect DDS clock is a deliciously complex
    problem. Just thinking about it is educational.


    I did a quick misuse of my filter editor to draw a sine wave and
    see what interpolation looks like. 64 points, interpolated into
    16384 points. You'll need a lot more than that but this might give
    an idea. The linear interpolation looks edgy, but the difference
    between second ad third order interpolation is practically invisible at
    this scale.
    <http://tgi-sci.com/misc/sine_all.gif> <-- the whole period
    then a small region at the top:
    <http://tgi-sci.com/misc/sine_1.gif> <-- first order interpolation,
    <http://tgi-sci.com/misc/sine_2.gif> <-- second order,
    < http://tgi-sci.com/misc/sine_3.gif> <-- third order.

    What about the zero-crossing region? That's the critical area. Cubic
    may be best there.

    Joe Gwinn

    I'll screenshot it tomorrow, now I am briefly awake only... :)
    [some noise woke me up, stopped when I turned on the light;
    was very faint, I lay listening for may be 2-3 minutes.
    May be some insect or something...).]
    I looked at the zero crossing region, it is the steepest
    and closest to linear. Perhaps the top was the least linear,
    did not look too much though.
    But if just the zero-crossing were the problematic area no sine
    would be necessary anyway (which is what I thought once I knew
    it was about just triggering something but John wants a perfect
    sine).

    No, John L does not care if the sine is perfect. The issue is to
    interpolate the zero crossing region to achieve picosecond time
    accuracy despite using 100 MHz NCO clock.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Mon Aug 22 08:46:13 2022
    On Mon, 22 Aug 2022 05:18:22 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/22/2022 4:12, Joe Gwinn wrote:
    On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 19:40, jlarkin@highlandsniptechnology.com wrote:
    On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>>> wrote:

    On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen >>>>>>>> <lang...@fonz.dk> wrote:

    lřrdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

    The output of the sine table is still coarse steps, with no filter to >>>>>>>> interpolate them. May as well just use the MSB of the phase
    accumulator and not mess with sine tables.

    That's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
    not 'coarse' in the voltage sense,

    https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

    looks pretty coarse to me. You only get small amplitude steps at low >>>>>> frequencies... and then you get slow unfiltered time steps too. That's >>>>>> the low frequency jitter problem. And in real life, low slopes reveal >>>>>> comparator imperfections too.


    and you can dither and interpose as many time
    steps of alternating values as you care to. Coarse in time is a choice, not
    a requireent.

    Second, a filter does not 'interpolate' a time sequence, it only has access
    to the PAST of the signal.

    Any real lowpass filter has time delay. So relative to its output, it >>>>>> is blending past and future inputs.


    As far as I can see you are going to do sine wave. In that case I would >>>>> do as much brute force as is practical - the is, as long a sine lookup >>>>> table as possible - and then interpolate. Those dsp sections they put >>>>> in fpga-s must be kept busy? 10 ns is not a lot of time to do it but >>>>> it must be doable. And second or even third order interpolation
    is not that hard - and can probably give you virtually error free
    values even for the 1mHz case.
    Easier said than done I suppose but that's the advantage of giving
    an opinion and not having to deliver the goods.... :D.

    It has been suggested that, at low frequencies, we interpolate between >>>> sine table entries so we can keep approximating the sine wave at the
    100 MHz clock rate, instead of making a step now and then as the
    selected MS bits of the phase accumulator tick over. That does still
    make a slow sine wave at the lowpass filter output.

    Straight-line interpolation is probably good enough for short segments >>>> of a sine. The interpolation slopes could be another lookup table.

    The idea of making a perfect DDS clock is a deliciously complex
    problem. Just thinking about it is educational.


    I did a quick misuse of my filter editor to draw a sine wave and
    see what interpolation looks like. 64 points, interpolated into
    16384 points. You'll need a lot more than that but this might give
    an idea. The linear interpolation looks edgy, but the difference
    between second ad third order interpolation is practically invisible at
    this scale.
    <http://tgi-sci.com/misc/sine_all.gif> <-- the whole period
    then a small region at the top:
    <http://tgi-sci.com/misc/sine_1.gif> <-- first order interpolation,
    <http://tgi-sci.com/misc/sine_2.gif> <-- second order,
    < http://tgi-sci.com/misc/sine_3.gif> <-- third order.

    What about the zero-crossing region? That's the critical area. Cubic
    may be best there.

    Joe Gwinn

    I'll screenshot it tomorrow, now I am briefly awake only... :)
    [some noise woke me up, stopped when I turned on the light;
    was very faint, I lay listening for may be 2-3 minutes.
    May be some insect or something...).]
    I looked at the zero crossing region, it is the steepest
    and closest to linear. Perhaps the top was the least linear,
    did not look too much though.
    But if just the zero-crossing were the problematic area no sine
    would be necessary anyway (which is what I thought once I knew
    it was about just triggering something but John wants a perfect
    sine).

    I don't want a perfect sine, but a classic sine-output DDS is easy to understand and changes frequency coherently.

    Here's a minor revelation:

    At lower frequencies, using more MS bits of the phase accumulator (ie,
    a bigger sine lookup table) and more DAC bits makes a surprisingly
    clean sine wave in my sim. 15 bits of lookup and 12 bits of dac look
    great for output frequencies from 15 MHz to well below 150K, which is
    two decades of frequency.

    But the sine slope gets low at low frequencies. Using a single-end
    terminated lowpass filter helps 2:1, at least. But the comparator may
    well be the jitter limit.

    Our old product uses an AD9850 DDS chip. It has a max output voltage
    of 1.5 unipolar; divide by 2 for a double-loaded LC filter. What's
    worse is that we used the chip's internal comparator, which is on the
    same chip as all the clocked logic, and crosstalk will be hideous.

    So, a good DDS needs good analog bits.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to Joe Gwinn on Tue Aug 23 11:21:00 2022
    On 23/8/22 00:57, Joe Gwinn wrote:
    On Mon, 22 Aug 2022 05:18:22 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:
    I looked at the zero crossing region, it is the steepest
    and closest to linear. Perhaps the top was the least linear,
    did not look too much though.
    But if just the zero-crossing were the problematic area no sine
    would be necessary anyway (which is what I thought once I knew
    it was about just triggering something but John wants a perfect
    sine).

    No, John L does not care if the sine is perfect. The issue is to
    interpolate the zero crossing region to achieve picosecond time
    accuracy despite using 100 MHz NCO clock.

    With that succinct restatement of the OP, I'll repeat my answer.

    Use only the top bit of the DDS phase accumulator, with as many as you
    can of the following bits stuffed into a digital delay generator that's triggered by that top bit.

    John already knows how to do a good DDG. It needs to be linear, of
    course, or be fed through a lookup table that's calibrated.

    Clifford Heath.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to no_spam@please.net on Mon Aug 22 19:12:32 2022
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
    <no_spam@please.net> wrote:

    On 23/8/22 00:57, Joe Gwinn wrote:
    On Mon, 22 Aug 2022 05:18:22 +0300, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:
    I looked at the zero crossing region, it is the steepest
    and closest to linear. Perhaps the top was the least linear,
    did not look too much though.
    But if just the zero-crossing were the problematic area no sine
    would be necessary anyway (which is what I thought once I knew
    it was about just triggering something but John wants a perfect
    sine).

    No, John L does not care if the sine is perfect. The issue is to
    interpolate the zero crossing region to achieve picosecond time
    accuracy despite using 100 MHz NCO clock.

    With that succinct restatement of the OP, I'll repeat my answer.

    Use only the top bit of the DDS phase accumulator, with as many as you
    can of the following bits stuffed into a digital delay generator that's >triggered by that top bit.

    John already knows how to do a good DDG.

    The concept is sound, but it would need a delay generator that has
    picosecond accuracy and can be reloaded about every 60 ns. Some
    pipelining would be involved, which is OK for a frequency source.

    Gotta think about that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to jla...@highlandsniptechnology.com on Mon Aug 22 19:31:22 2022
    On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
    <no_...@please.net> wrote:

    On 23/8/22 00:57, Joe Gwinn wrote:
    On Mon, 22 Aug 2022 05:18:22 +0300, Dimiter_Popoff <d...@tgi-sci.com>
    wrote:
    I looked at the zero crossing region, it is the steepest
    and closest to linear. Perhaps the top was the least linear,
    did not look too much though.
    But if just the zero-crossing were the problematic area no sine
    would be necessary anyway (which is what I thought once I knew
    it was about just triggering something but John wants a perfect
    sine).

    No, John L does not care if the sine is perfect. The issue is to
    interpolate the zero crossing region to achieve picosecond time
    accuracy despite using 100 MHz NCO clock.

    With that succinct restatement of the OP, I'll repeat my answer.

    Use only the top bit of the DDS phase accumulator, with as many as you
    can of the following bits stuffed into a digital delay generator that's >triggered by that top bit.

    John already knows how to do a good DDG.
    The concept is sound, but it would need a delay generator that has picosecond accuracy and can be reloaded about every 60 ns. Some
    pipelining would be involved, which is OK for a frequency source.

    Gotta think about that.

    That's what the trapezium slope generator seems to offer. If you wanted pico-second resolution you'd need at least a 500Mhz clock and a 16 -bit DAC. My example envisaged a 2.5GHz clock and 14-bit DAC and had a 0.4psec granularity. The clock and the DAC
    would have to be pretty good to offer that kind of accuracy.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to jla...@highlandsniptechnology.com on Mon Aug 22 21:53:03 2022
    On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
    <no_...@please.net> wrote:
    Use only the top bit of the DDS phase accumulator, with as many as you
    can of the following bits stuffed into a digital delay generator that's >triggered by that top bit.

    John already knows how to do a good DDG.
    The concept is sound, but it would need a delay generator that has picosecond accuracy and can be reloaded about every 60 ns. Some
    pipelining would be involved, which is OK for a frequency source.

    Gotta think about that.

    Honestly I think filtering a staircase to get a ramp to feed into a comparator looks a lot harder (with many more variables to control) than just triggering a linear(-ized) ramp into the same comparator. But that's just me, I never claimed to be a
    picosecond guy.

    Clifford Heath

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to Clifford Heath on Mon Aug 22 22:58:06 2022
    On Tuesday, August 23, 2022 at 2:53:08 PM UTC+10, Clifford Heath wrote:
    On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
    <no_...@please.net> wrote:
    Use only the top bit of the DDS phase accumulator, with as many as you >can of the following bits stuffed into a digital delay generator that's >triggered by that top bit.

    John already knows how to do a good DDG.
    The concept is sound, but it would need a delay generator that has picosecond accuracy and can be reloaded about every 60 ns. Some
    pipelining would be involved, which is OK for a frequency source.

    Gotta think about that.

    Honestly I think filtering a staircase to get a ramp to feed into a comparator looks a lot harder (with many more variables to control) than just triggering a linear(-ized) ramp into the same comparator. But that's just me, I never claimed to be a
    picosecond guy.

    It's not the picoseconds per se that are the problem, but the accuracy, Buying the ADC to make the ramp buys you a lot of accuracy. Making a linear ramp that's accurate to a picosecond over a nanosecond or two is doable, but it's a better than 0.1%
    accurate current into a better than 0.1% stable capacitor, and when I last did something like it back in around 1988 we autocalibrated the system every ten minutes to keep it accurate. It only took a few milliseconds but it's a considerable complication.
    The ADC saves you from that.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to clifford.heath@gmail.com on Wed Aug 24 10:13:52 2022
    On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <clifford.heath@gmail.com> wrote:

    On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
    <no_...@please.net> wrote:
    Use only the top bit of the DDS phase accumulator, with as many as you
    can of the following bits stuffed into a digital delay generator that's
    triggered by that top bit.

    John already knows how to do a good DDG.
    The concept is sound, but it would need a delay generator that has
    picosecond accuracy and can be reloaded about every 60 ns. Some
    pipelining would be involved, which is OK for a frequency source.

    Gotta think about that.

    Honestly I think filtering a staircase to get a ramp to feed into a comparator looks a lot harder (with many more variables to control) than just triggering a linear(-ized) ramp into the same comparator. But that's just me, I never claimed to be a
    picosecond guy.

    It occurs to me that one gets to choose which accumulator bit (or bit
    field) to use, and each bit alternates trice as fast as the next most significant bit. From the NCO frequency control word, we know exactly
    what frequency is being generated.

    This allows us to compute the pre-trigger phase angle, used to
    generate the pre-trigger signal needed to know when to start the
    interpolator hardware, and what period it is to interpolate over
    (which is loaded into the interpolator ahead of the trigger).

    This also allows us to compute which accumulator bit alternates at the
    correct rate. When this bit changes, the interpolator commences its
    run, yielding a delayed trigger that is intended to be at the actual
    zero crossing. The use of the pre-trigger removes the which-cycle
    ambiguity of a fast-alternating accumulator bit.

    The above is the bare-bones approach. One can also use multiple
    accumulator bits to trigger the run-up steps before the interpolator
    run.

    One can also approximate Phil H's 1/f scheme in the above, largely by
    choice of accumulator bits to use.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Joe Gwinn on Wed Aug 24 13:30:07 2022
    On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:
    On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor...@gmail.com> wrote:

    On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
    <no_...@please.net> wrote:
    Use only the top bit of the DDS phase accumulator, with as many as you >> >can of the following bits stuffed into a digital delay generator that's >> >triggered by that top bit.

    John already knows how to do a good DDG.
    The concept is sound, but it would need a delay generator that has
    picosecond accuracy and can be reloaded about every 60 ns. Some
    pipelining would be involved, which is OK for a frequency source.

    Gotta think about that.

    Honestly I think filtering a staircase to get a ramp to feed into a comparator looks a lot harder (with many more variables to control) than just triggering a linear(-ized) ramp into the same comparator. But that's just me, I never claimed to be a
    picosecond guy.
    It occurs to me that one gets to choose which accumulator bit (or bit
    field) to use, and each bit alternates trice as fast as the next most significant bit. From the NCO frequency control word, we know exactly
    what frequency is being generated.
    This allows us to compute the pre-trigger phase angle, used to
    generate the pre-trigger signal needed to know when to start the interpolator hardware, and what period it is to interpolate over
    (which is loaded into the interpolator ahead of the trigger).

    This also allows us to compute which accumulator bit alternates at the correct rate. When this bit changes, the interpolator commences its
    run, yielding a delayed trigger that is intended to be at the actual
    zero crossing. The use of the pre-trigger removes the which-cycle
    ambiguity of a fast-alternating accumulator bit.

    The above is the bare-bones approach. One can also use multiple
    accumulator bits to trigger the run-up steps before the interpolator
    run.

    One can also approximate Phil H's 1/f scheme in the above, largely by
    choice of accumulator bits to use.

    That's all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave divider, all
    updatable from a single command, so completely synchronized, never producing a glitch pulse?

    --

    Rick C.

    ---+ Get 1,000 miles of free Supercharging
    ---+ Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to Ricky on Wed Aug 24 19:30:09 2022
    On Thursday, August 25, 2022 at 6:30:11 AM UTC+10, Ricky wrote:
    On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:
    On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor...@gmail.com> wrote:
    On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath <no_...@please.net> wrote:

    <snip>

    That's all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave divider,
    all updatable from a single command, so completely synchronized, never producing a glitch pulse?

    Of course, if you buy an Analog Devices DDS chip, the logic is all buried in the chip, so you don't have to buy or program the FPGA.

    The reason that John Larkin isn't doing that does seem to be that the Analog Devices DDS chips are expensive, and an FPGA and a DAC to do the same job are cheaper (and harder to copy and look more like an original design). Once you've got to that point,
    it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to bill....@ieee.org on Wed Aug 24 20:24:50 2022
    On Wednesday, August 24, 2022 at 10:30:13 PM UTC-4, bill....@ieee.org wrote:
    On Thursday, August 25, 2022 at 6:30:11 AM UTC+10, Ricky wrote:
    On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:
    On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor...@gmail.com> wrote:
    On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath <no_...@please.net> wrote:
    <snip>
    That's all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave divider,
    all updatable from a single command, so completely synchronized, never producing a glitch pulse?
    Of course, if you buy an Analog Devices DDS chip, the logic is all buried in the chip, so you don't have to buy or program the FPGA.

    The reason that John Larkin isn't doing that does seem to be that the Analog Devices DDS chips are expensive, and an FPGA and a DAC to do the same job are cheaper (and harder to copy and look more like an original design). Once you've got to that point,
    it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.

    It also does not meet all his requirements, which is to produce pulses without glitches when retuned. By implementing the DDS in the FPGA, the DDS and the octave divider can be reprogrammed on the same clock cycle, making a glitchless transition.

    There may be one issue to work out. The DDS will be running from the master clock. The octave divider will be running on the DDS output clock. So the octave threshold setting update will, by definition, not be perfectly synchronous with the DDS update.
    So this might need a bit of thought to make sure there are no glitches during a rate transition.

    --

    Rick C.

    --+- Get 1,000 miles of free Supercharging
    --+- Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to Ricky on Wed Aug 24 21:50:42 2022
    On Thursday, August 25, 2022 at 1:24:55 PM UTC+10, Ricky wrote:
    On Wednesday, August 24, 2022 at 10:30:13 PM UTC-4, bill....@ieee.org wrote:
    On Thursday, August 25, 2022 at 6:30:11 AM UTC+10, Ricky wrote:
    On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:
    On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor...@gmail.com> wrote:
    On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath <no_...@please.net> wrote:
    <snip>
    That's all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave divider,
    all updatable from a single command, so completely synchronized, never producing a glitch pulse?

    Of course, if you buy an Analog Devices DDS chip, the logic is all buried in the chip, so you don't have to buy or program the FPGA.

    The reason that John Larkin isn't doing that does seem to be that the Analog Devices DDS chips are expensive, and an FPGA and a DAC to do the same job are cheaper (and harder to copy and look more like an original design). Once you've got to that
    point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.

    It also does not meet all his requirements, which is to produce pulses without glitches when retuned. By implementing the DDS in the FPGA, the DDS and the octave divider can be reprogrammed on the same clock cycle, making a glitchless transition.

    Have you any idea how the Analog Devices chips work? Or what's being asked for? The Analog Devices part produce a continuous signal through a frequency transition so one transition is going to be in the wrong place in terms of either frequency regime,
    but that's inevitable, unless you make the transition on an output clock edge. which would take work.

    There may be one issue to work out. The DDS will be running from the master clock. The octave divider will be running on the DDS output clock. So the octave threshold setting update will, by definition, not be perfectly synchronous with the DDS update.
    So this might need a bit of thought to make sure there are no glitches during a rate transition.

    The trapezium ramp scheme wouldn't need an "octave divider" so it wouldn't have that problem.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to bill....@ieee.org on Wed Aug 24 23:43:47 2022
    On Thursday, August 25, 2022 at 12:50:47 AM UTC-4, bill....@ieee.org wrote:
    On Thursday, August 25, 2022 at 1:24:55 PM UTC+10, Ricky wrote:
    On Wednesday, August 24, 2022 at 10:30:13 PM UTC-4, bill....@ieee.org wrote:
    On Thursday, August 25, 2022 at 6:30:11 AM UTC+10, Ricky wrote:
    On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:
    On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor...@gmail.com> wrote:
    On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath <no_...@please.net> wrote:
    <snip>
    That's all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave
    divider, all updatable from a single command, so completely synchronized, never producing a glitch pulse?

    Of course, if you buy an Analog Devices DDS chip, the logic is all buried in the chip, so you don't have to buy or program the FPGA.

    The reason that John Larkin isn't doing that does seem to be that the Analog Devices DDS chips are expensive, and an FPGA and a DAC to do the same job are cheaper (and harder to copy and look more like an original design). Once you've got to that
    point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.

    It also does not meet all his requirements, which is to produce pulses without glitches when retuned. By implementing the DDS in the FPGA, the DDS and the octave divider can be reprogrammed on the same clock cycle, making a glitchless transition.
    Have you any idea how the Analog Devices chips work? Or what's being asked for? The Analog Devices part produce a continuous signal through a frequency transition so one transition is going to be in the wrong place in terms of either frequency regime,
    but that's inevitable, unless you make the transition on an output clock edge. which would take work.
    There may be one issue to work out. The DDS will be running from the master clock. The octave divider will be running on the DDS output clock. So the octave threshold setting update will, by definition, not be perfectly synchronous with the DDS
    update. So this might need a bit of thought to make sure there are no glitches during a rate transition.
    The trapezium ramp scheme wouldn't need an "octave divider" so it wouldn't have that problem.

    The "trapezium" scheme has the problem that it isn't designed and may have other problems.

    --

    Rick C.

    --++ Get 1,000 miles of free Supercharging
    --++ Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to Ricky on Thu Aug 25 03:54:19 2022
    On Thursday, August 25, 2022 at 4:43:52 PM UTC+10, Ricky wrote:
    On Thursday, August 25, 2022 at 12:50:47 AM UTC-4, bill....@ieee.org wrote:
    On Thursday, August 25, 2022 at 1:24:55 PM UTC+10, Ricky wrote:
    On Wednesday, August 24, 2022 at 10:30:13 PM UTC-4, bill....@ieee.org wrote:
    On Thursday, August 25, 2022 at 6:30:11 AM UTC+10, Ricky wrote:
    On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:
    On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor...@gmail.com> wrote:
    On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
    On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath <no_...@please.net> wrote:
    <snip>
    That's all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave
    divider, all updatable from a single command, so completely synchronized, never producing a glitch pulse?

    Of course, if you buy an Analog Devices DDS chip, the logic is all buried in the chip, so you don't have to buy or program the FPGA.

    The reason that John Larkin isn't doing that does seem to be that the Analog Devices DDS chips are expensive, and an FPGA and a DAC to do the same job are cheaper (and harder to copy and look more like an original design). Once you've got to that
    point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.

    It also does not meet all his requirements, which is to produce pulses without glitches when retuned. By implementing the DDS in the FPGA, the DDS and the octave divider can be reprogrammed on the same clock cycle, making a glitchless transition.

    Have you any idea how the Analog Devices chips work? Or what's being asked for? The Analog Devices part produce a continuous signal through a frequency transition so one transition is going to be in the wrong place in terms of either frequency regime,
    but that's inevitable, unless you make the transition on an output clock edge. which would take work.

    There may be one issue to work out. The DDS will be running from the master clock. The octave divider will be running on the DDS output clock. So the octave threshold setting update will, by definition, not be perfectly synchronous with the DDS
    update. So this might need a bit of thought to make sure there are no glitches during a rate transition.

    The trapezium ramp scheme wouldn't need an "octave divider" so it wouldn't have that problem.

    The "trapezium" scheme has the problem that it isn't designed and may have other problems.

    Of course it isn't designed. I'm not going to put it into production, and John Larkin wouldn't pay me money to design it for him.

    The detailed design phase is where you find and sort out a whole lot of - hopefully - minor problems. Back when I was getting paid to do that kind of work I was pretty good at it, but that's a long time ago. What I've spelled out here strikes me as good
    beginning, but John Larkin may have some particularly rabid customer to satisfy, and he hasn't been all that forth-coming about the end application.

    A lot of the point of having this kind of early stage design is to clarify what's going on and what needs to go on.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)