Frequency Synthesis using the NCO. Cascading Counters.

Duane C. Johnson

I'm trying to use the Numerically Controlled Oscillators to drive a second NCO which will be used as a long binary counter.

I'm trying to obtain a square wave signal with a period of about 10 minutes. This square wave needs to have both high stability and be varied a few % with high resolution. Its a solar tracker application where the clock follows Sidereal Time instead of Clock Time.

Here is a FemtoBasic program I'm using to test this.

NEW
110 OUTA[27]=0 : REM NOTE! PIN[27] Is Connected to PIN[17]
120 X=INA[17]
130 OUTA[16]=0
200 REM This works fine and Outputs 1 MHz on PIN[27]
201 REM and is routed to PIN[26}
210 FRQA = $03333888 : REM 1 MHz
220 A = $4 : REM CTRMODE A
230 B = $0 : REM PLLDIV A
240 C = 0 : REM BPIN A
250 D = 27 : REM APIN A
290 CTRA = A * $4000000 + B * $800000 + C * $200 + D : REM Put the word together
300 REM If this works right the output should be 1 MHz / 4 = 250KHz
301 REM Nothing I can do gives me this.
302 REM Instead I either get 20MHz or nothing
310 FRQB = $10000000 : REM 5 MHz
320 E = $4 : REM CTRMODE B 5MHz $4,$5,$6,$7 80MHz $2,$3
330 F = $7 : REM PLLDIV B
340 G = 17 : REM BPIN B
350 H = 16 : REM APIN B
360 CTRB = E * $4000000 + F * $800000 + G * $200 + H : REM Put the word together
RUN

I tried all kinds of combinations and nothing will make
Counter B take its source from the external PIN[17].

What am I doing wrong?
Or is it just impossible to use an external oscillator on the NCO?

OK, the hardware solution is to use an external binary divider.
But I thought I could get CTRB to do this.

Duane

Phil Pilgrim (PhiPi)

NCO mode counters always uses the internal clock. You can't daisy-chain them.

-Phil

kuroneko

Adding to Phil's comment, the available counter modes unfortunately either listen to inputs or drive outputs but not both (feedback is a special case and only reflects the input).

Have you considered a s/w solution, i.e. simply toggling a pin at 5min intervals?

Duane C. Johnson

There are a number of ways to attack the problem.
1. Do the full mathematics and directly calculate the equation of time. However, this is quite calculation intensive and full of fairly high precision trig functions. The procedures are well known since at least Newtons time.

2. Use sensor based solar trackers with their problems of clouds, haze and dirty optics.

3. Lookup table methods which seam to be looking pretty good to me now that large and cheap SD Cards are available.
3A. Calculate AZimuth/ALTitude vs. Clock time.
3B. Calculate AZimuth/ALTitude vs. Sidereal time.

Actually solar position tables are simplified quite a bit if the local clock is sidereal. For instance, the sun is always due south at solar noon.

The sun leads and trails clock time by as much as +-15 minutes or so over a 4 month period and trails and leads about -+7 minutes the other 8 months.

That I'm proposing, for the present project, is to create a master clock that provides a time tick every 10 sidereal minutes. Then read the table and make my stepper motors move at a linear interpolated rate until the next tick.

The difference between 10 sidereal minutes and 10 clock minutes isn't very much. About .02% or so. Ya, not much, but this accumulates over time to cause a fairly large error.

There are 2 methods to try:
A. What I was hoping to do with the two NCOs in a COG Cascade them. OK, only one NCO and an external binary divider will do the same thing.
B. Use a standard time clock chip and use an NCO to provide the 32768 Hz input. And control it by the +-.02% with great resolution.

If done right the sidereal and civil clocks should match each other 4 times per year and the totals for the year are also exactly the same, (excluding precession).

I have done all these methods. Some cost more than others, some more difficult to do.
I recon this sidereal timer with table lookup has the potential to be the lowest cost.

This first try is for a direct solar tracker but there are no obstacles to doing this for a heliostat.

Anyway, to bad CTRB can't take an external input. I suppose the counters are intimately integrated into the arithmetic unit.

Duane

Duane C. Johnson

Here's a code snippet for a Digital Oscillator
using one of the Propeller NCOs. Cool huh!

Duane

NEW
1 PRINT "Simple example of a Digital Oscillator"
10 REM 53.68848576 (2^31 / 39998960Hz = 53.6884857584176)
20 A = 39998960
30 B = $4 : REM CTRMODE A
40 C = $0 : REM PLLDIV A
50 D = 0 : REM BPIN A
60 E = 27 : REM APIN A
70 PRINT "1 to 39998960 Hz"
80 INPUT " ? "; N
90 IF N > A THEN PRINT " To Large" : GOTO 30
100 IF N < 1 THEN PRINT " Not Negative" : GOTO 30
110 OUTA[27]=0 : FRQA = N*53+N*6/10+N*8/100+N*8/1000+N*48/100000+N*5/1000000+N*7/10000000+N*6/ 100000000
120 REM PRINT FRQA
130 CTRA = B * $4000000 + C * $800000 + D * $200 + E
140 GOTO 70
RUN

Mike Green

If you have a spare I/O pin, you can setup the NCO to output to that pin, then use the same pin as input to a second cog counter, probably using the edge triggered mode. The 2nd counter will count up by FRQx with each leading edge of the 1st counter.

Duane C. Johnson

Can the second counter be in the same cog as the first counter?

kuroneko

Duane C. Johnson wrote: »

Can the second counter be in the same cog as the first counter?

Yes, but as it's an input sensitive counter (mode) you can't drive any output with that second counter.

Duane C. Johnson

Thanks All for the help.

Yes, the 2 counters can be cascaded. Well sort of.
The first primary counter is run in "PLL single-ended" mode and the
secondary counter is run in "POSEDGE detector" mode.

The primary counter is intended to be variable for changing the timing and
the secondary be fixed.

Unfortunaly CTRB can't output to a pin when in POSEDGE detector mode.
Software can watch the MSB of the PHSB accumulator to determain when
it roles over for the output. Apparently timing can be as long as 58000 years.

To help with working with the complexities of doing this I wrote an
Excel Spreadsheet with which counter variables can be tested

http://www.redrok.com/CTRA.xls.

Duane

NEW
10 PRINT "Test Values for use with CTRA.XLS"
210 OUTA[17]=0
220 FRQA = 384316908 : REM 1 MHz
230 A = $2 : REM CTRMODE A
240 B = $3 : REM PLLDIV A
250 C = 0 : REM BPIN A
260 D = 17 : REM APIN A
290 CTRA = A * $4000000 + B * $800000 + C * $200 + D
310 OUTA[17]=0
320 FRQB = 1
330 E = $A : REM CTRMODE B
340 F = $0 : REM PLLDIV B
350 G = 0 : REM BPIN B
360 H = 17 : REM APIN B
390 CTRB = E * $4000000 + F * $800000 + G * $200 + H
420 OUTA[16]=PHSB REV 32 : GOTO 420
RUN

And two test programs to be used with a frequency counter on PIN[17] to measure the clock frequency.

NEW
10 PRINT "Test for 80 MHz Reference"
20 OUTA[17]=0 : FRQA = $10000000
30 CTRA = $2 * $4000000 + $7 * $800000 + 0 * $200 + 17
RUN

NEW
10 PRINT "Test for 40 MHz Reference"
20 OUTA[17]=0 : FRQA = $80000000
30 CTRA = $4 * $4000000 + $0 * $800000 + 0 * $200 + 17
RUN