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
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
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 reverseSee if this works to get it on screen:
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 aSee if this works to get it on screen:
time-to-amplitude in reverse
the step param list needs to be one single long lineNo, it does not need to be one single line. Run the ASC file I posted. It runs fine in LTspice IV and XVII.
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 aSee if this works to get it on screen:
time-to-amplitude in reverse
the step param list needs to be one single long line
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 lineNo, 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
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.
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 lineNo, 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 fileNo 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
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
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 lineNo, it does not need to be one single line. Run the ASC file I
posted.
No it does not. Here is the line in the ASC file: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
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
sÃ¸ndag den 14. august 2022 kl. 08.51.36 UTC+2 skrev bill....@ieee.org:43993 1.51775 1.60375 1.69880 1.80385 1.91994 2.04824 2.19004 2.34675 2.51994
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.
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.
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"?
On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <dp@tgi-sci.com>edge
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
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?
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.
On Mon, 15 Aug 2022 00:46:15 +0300, Dimiter_Popoff <d...@tgi-sci.com>edge
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
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 sortWhen synthesizing a low frequency DDS sine wave, we step slowly
of "the larger the step the less low pass I want applied to it"?
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?
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.
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.
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:
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.
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:<snip>
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:
I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. ThatOnly if you chose to do that way. You could rewrite the look-up table every time you changed the frequency.
needs a sine lookup table with about 50 billion entries.
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,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.
and divide down as needed. The trick will be to make the gear shifts appear to be seamless.
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.I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. That
Well, the simplest way out is to step at a constant rate all the
time.
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.
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:but what happens when you change from one frequency to another?
On Mon, 15 Aug 2022 12:54:56 +0300, Dimiter_Popoff <d...@tgi-sci.com wrote:<snip>
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:
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,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.
and divide down as needed. The trick will be to make the gear shifts appear to be seamless.
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:<snip>
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:
I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. ThatOnly if you chose to do that way. You could rewrite the look-up table every time you changed the frequency.
needs a sine lookup table with about 50 billion entries.
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,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.
and divide down as needed. The trick will be to make the gear shifts
appear to be seamless.
but what happens when you change from one frequency to another?
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:<snip>
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:
I want to synthesize 1 mHz to 15 MHz, with a 100 MHz DDS clock. ThatOnly if you chose to do that way. You could rewrite the look-up table every time you changed the frequency.
needs a sine lookup table with about 50 billion entries.
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,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.
and divide down as needed. The trick will be to make the gear shifts
appear to be seamless.
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?
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:<snip>
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:
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?
case delay from frequency change will be one new period.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
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 delayuntil the change of up to one old clock period.
Have you asked your customer how they would like for these cases to be handled?
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.
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.
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>I still don't understand what you are trying to do. Periodic sine
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.
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
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.
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 don't understand what a neat frequency is, either. Any periodicI 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
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.
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 don't understand what a neat frequency is, either. Any periodicI 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
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.
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.
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:
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 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.
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.
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:When synthesizing a low frequency DDS sine wave, we step slowly
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"? >>>>>
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 sineI just want a programmable-frequency trigger generator that changes frequency on demand and doesn't stop for reprogramming and doesn't
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.
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.
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 don't understand what a neat frequency is, either. Any periodicI 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
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.
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 don't understand what a neat frequency is, either. Any periodicI 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
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.
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 don't understand what a neat frequency is, either. Any periodicI 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
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 ifOur FPGA will have at least a megabit of ram if we use the efinix,
you do lookup-and-interpolate. Will still be huge... And division
at 100 Msps may well be prohibitive.
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.
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 don't understand what a neat frequency is, either. Any periodicI 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
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.
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 don't understand what a neat frequency is, either. Any periodic
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
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...
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.
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.
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:When synthesizing a low frequency DDS sine wave, we step slowly
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"? >>>>>>>
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.
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 ChristensenWhen synthesizing a low frequency DDS sine wave, we step slowly >>>>>> through the waveform lookup table and a fixed filter doesn't
<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"? >>>>>>
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.
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 ChristensenWhen synthesizing a low frequency DDS sine wave, we step slowly >>>>>>> through the waveform lookup table and a fixed filter doesn't
<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"? >>>>>>>
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.
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 ChristensenWhen synthesizing a low frequency DDS sine wave, we step slowly >>>>>> through the waveform lookup table and a fixed filter doesn't
<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"? >>>>>>
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.
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 ChristensenWhen synthesizing a low frequency DDS sine wave, we step slowly >>>>>>> through the waveform lookup table and a fixed filter doesn't
<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"? >>>>>>>
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.
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>I guess I'm not seeing the problem. Ordinary DDS units with 48-bit
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.
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
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:
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.
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.
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'?
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"
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.
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:When synthesizing a low frequency DDS sine wave, we step slowly >>>>>>>> through the waveform lookup table and a fixed filter doesn't
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"? >>>>>>>>
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.
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 ChristensenWhen 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. >>>>>>>>
<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"? >>>>>>>>
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
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>If all you want to do is to generate a trigger at any frequency from
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:When synthesizing a low frequency DDS sine wave, we step slowly
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"? >> >>>>>>>>
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.
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
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>If all you want to do is to generate a trigger at any frequency from
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:When synthesizing a low frequency DDS sine wave, we step slowly >> >>>>>>>> through the waveform lookup table and a fixed filter doesn't
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"? >> >>>>>>>>
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.
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.
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.
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>If all you want to do is to generate a trigger at any frequency from
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:When synthesizing a low frequency DDS sine wave, we step slowly >>> >>>>>>>> through the waveform lookup table and a fixed filter doesn't
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"? >>> >>>>>>>>
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.
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.
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,
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:The lowpass filter, between the DAC and the comparator, smooths the
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>If all you want to do is to generate a trigger at any frequency from
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.
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
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 DACThe 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.
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:The lowpass filter, between the DAC and the comparator, smooths the
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>If all you want to do is to generate a trigger at any frequency from
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.
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
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?
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 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.
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
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.
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 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.
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
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.
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>I still don't understand why someone would need sine wave for triggering
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 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.
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
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.
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...
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>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
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 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.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
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.
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 clkObviously you can't do that, I am just wondering about the application
with just a divider...
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.
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.
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 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.
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
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.
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 ChristensenWhen 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. >>>>>>>>
<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"? >>>>>>>>
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.
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 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.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
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 haveOk, generate a 1.23456789 MHz clock from a 100 MHz reference using simple digital dividers.
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 ;)
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
torsdag den 18. august 2022 kl. 10.20.49 UTC+2 skrev Mike Monett VE3BTI:
Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
Off a bit:Ok, generate a 1.23456789 MHz clock from a 100 MHz reference using
simple digital dividers.
divide by 81 ;)
100/81 = 1.23456790123
~1ppm
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.
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.
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.
Set the frequency to 1.23456789 * 81 = 99.99999909 MHz
- exact
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.
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 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.
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
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.
trivial as it can get.
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.
[...]
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.
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 synthesizedWith a NCO implemented in a FPGA, it's pretty easy to generate a
frequencies and maybe incorporate more LSBish phase accumulator bits. >Somehow. Seamlessly.
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.
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.
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.
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 HobbsYou just multiply by 1/f, using saturating arithmetic. That keeps the
<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.
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
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 HobbsYou just multiply by 1/f, using saturating arithmetic. That keeps the
<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.
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.
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
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 HobbsYou just multiply by 1/f, using saturating arithmetic. That keeps the
<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.
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
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 HobbsYou just multiply by 1/f, using saturating arithmetic. That keeps the
<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.
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/robotThe "sine" table could have an s-shaped waveform to steepen the zero
limiting jerk
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?
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:The "sine" table could have an s-shaped waveform to steepen the zero
On 8/18/22 5:11 PM, John Larkin wrote:
On Thu, 18 Aug 2022 12:41:33 -0400, Phil HobbsYou just multiply by 1/f, using saturating arithmetic. That keeps the
<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.
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
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
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:The "sine" table could have an s-shaped waveform to steepen the zero
On 8/18/22 5:11 PM, John Larkin wrote:
On Thu, 18 Aug 2022 12:41:33 -0400, Phil HobbsYou 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
<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.
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
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.
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 theAt low frequencies, we need to use more of the bits of the phase
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.
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.
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:At low frequencies, we need to use more of the bits of the phase
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.
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
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:
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.
Putting gain in front of a zero-crossing comparator does nothing. It's still a zero-crossing comparator.
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:At low frequencies, we need to use more of the bits of the phase
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.
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.
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:At low frequencies, we need to use more of the bits of the phase
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: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
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. >>>>>>
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.
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?
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:At low frequencies, we need to use more of the bits of the phase
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.
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.
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:At low frequencies, we need to use more of the bits of the phase
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.
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.
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:I think that makes jitter worse. It violates Nyquist reconstruction
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:At low frequencies, we need to use more of the bits of the phase
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.
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
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
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:I think that makes jitter worse. It violates Nyquist reconstruction
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:At low frequencies, we need to use more of the bits of the phase
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:Right. The trapezoid corner happens at an XO edge, which makes output
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. >> >> >>
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.
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
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.
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:I think that makes jitter worse. It violates Nyquist reconstruction
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:At low frequencies, we need to use more of the bits of the phase
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:Right. The trapezoid corner happens at an XO edge, which makes output
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. >> >> >> >>
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.
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
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
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.
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 phaseThat's illogical. Firstly, the output of the sine table is parts-per-thousand steps,
accumulator and not mess with sine tables.
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.
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.
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:
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.Most vitally, in the Fourier-trasform sense, a frequency is DEFINITIVE of a sine,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.
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.
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
None of this nonsense of trying to implement trapezoids is needed.
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).
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,
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.
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.
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 strikes me that John Larkin's original idea of synthesising trapezoids can be made to work.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 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
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.
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.
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.
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.
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:
Any real lowpass filter has time delay. So relative to its output, it
is blending past and future inputs.
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.
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.
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.
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.
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.
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.
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:
For a sine wave the zero crossing is the point where the function is perfectly linear.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.
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
The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.
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:What about the zero-crossing region? That's the critical area. Cubic
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.
may be best there.
Joe Gwinn
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.
On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote: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.
On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:<snip>
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:
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
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.
On Sunday, August 21, 2022 at 9:50:01 PM UTC-4, bill....@ieee.org wrote: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.
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:<snip>
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:
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
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.
On Monday, August 22, 2022 at 2:07:08 PM UTC+10, Ricky wrote: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.
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:<snip>
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:
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
up table picking up the series of values that will put the zero-crossing in the right place.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-
generate the right ramp.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
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.
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:
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.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
look-up table picking up the series of values that will put the zero-crossing in the right place.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
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.
to generate the right ramp.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
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 somethingelse 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.
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:What about the zero-crossing region? That's the critical area. Cubic
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.
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).
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:What about the zero-crossing region? That's the critical area. Cubic
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.
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).
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.
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.
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.
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.
On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:picosecond guy.
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
On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:picosecond guy.
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 youThe concept is sound, but it would need a delay generator that has
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.
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
On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor...@gmail.com> wrote:picosecond guy.
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.The concept is sound, but it would need a delay generator that has
John already knows how to do a good DDG.
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
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.
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:
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?
On Thursday, August 25, 2022 at 6:30:11 AM UTC+10, Ricky wrote:all updatable from a single command, so completely synchronized, never producing a glitch pulse?
On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:<snip>
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:
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,
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.it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.
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,
On Wednesday, August 24, 2022 at 10:30:13 PM UTC-4, bill....@ieee.org wrote:all updatable from a single command, so completely synchronized, never producing a glitch pulse?
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:<snip>
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:
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,
point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.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
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.
On Thursday, August 25, 2022 at 1:24:55 PM UTC+10, Ricky wrote:divider, all updatable from a single command, so completely synchronized, never producing a glitch pulse?
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:<snip>
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:
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
point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.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
but that's inevitable, unless you make the transition on an output clock edge. which would take work.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,
update. So this might need a bit of thought to make sure there are no glitches during a rate 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
The trapezium ramp scheme wouldn't need an "octave divider" so it wouldn't have that problem.
On Thursday, August 25, 2022 at 12:50:47 AM UTC-4, bill....@ieee.org wrote:divider, all updatable from a single command, so completely synchronized, never producing a glitch pulse?
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:<snip>
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:
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
point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.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
but that's inevitable, unless you make the transition on an output clock edge. which would take work.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,
update. So this might need a bit of thought to make sure there are no glitches during a rate 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
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 135 |
Nodes: | 16 (0 / 16) |
Uptime: | 39:29:45 |
Calls: | 2,791 |
Calls today: | 3 |
Files: | 9,644 |
Messages: | 2,483,106 |