Two sinewave generators, each one implemented with a PIC 16F84A, its own keypad and the output via PORTB, going to an R-2R network. A 4 pole filter completes the circuit. Both driven by a common 4 MHz clock and both running EXACTLY the same software.
In each generator, following the principle of of DDS, one value, PHASE_INC (3-bytes), is repetitively added to a PHASE_ACCUMULATOR (3-bytes as well). The bits b6:b0 of the accumulator's MSB are used to read a look up table with sine values from 1 to 128 and b7 of that MSB is used to know when to calculate the complement.
To change the frequency, withs keys "FREQ-UP" and "FREQ_UP", I can increase / decrease PHASE_INC value in unitary steps (yes, one unit at a time).
Everything works as expected except one thing: If I vary PHASE_INC in one of them to any axtent and then try to bring it to its original frequency by increasing / decreasing PHASE_INC, it is close to impossible getting the orginal value again, albeit VERY VERY close.
Just in case, please note:
a - Both generators , independently checked proved to be stable enough in the long term. They start with the same PHASE_INC value, thus their frequencies match each other 100% and stay like that forever. That's the reason for the common clock and it works OK.
b - According to theory, using UNITARY steps, sooner or later I should get again the PHASE_INC initial value where I started from, that is the initial frequency (mathcing again the other generator). In software I included enough delays to make the unitary changes of PHASE_INC painfully SLOW ensuring to have a smooth control of the changes. Simulation shows that PHASE_INC is increased/decreased by one, every time. (?)
c - I have an option, via keypad where I can change the PHASE_INC to different fixed values. Doing that to both generators, I get again matching (and stable) frequencies at the output. It's the up / down thing that ruins everything.
Please, can anyone tell me if I am overlooking something too obvious regarding the DDS principle, considering that the problem shows up only when I change one of them whether Up or Down.
Help really appreciated. (I wish I could explain this in a shorter text!! - Sorry)
In each generator, following the principle of of DDS, one value, PHASE_INC (3-bytes), is repetitively added to a PHASE_ACCUMULATOR (3-bytes as well). The bits b6:b0 of the accumulator's MSB are used to read a look up table with sine values from 1 to 128 and b7 of that MSB is used to know when to calculate the complement.
To change the frequency, withs keys "FREQ-UP" and "FREQ_UP", I can increase / decrease PHASE_INC value in unitary steps (yes, one unit at a time).
Everything works as expected except one thing: If I vary PHASE_INC in one of them to any axtent and then try to bring it to its original frequency by increasing / decreasing PHASE_INC, it is close to impossible getting the orginal value again, albeit VERY VERY close.
Just in case, please note:
a - Both generators , independently checked proved to be stable enough in the long term. They start with the same PHASE_INC value, thus their frequencies match each other 100% and stay like that forever. That's the reason for the common clock and it works OK.
b - According to theory, using UNITARY steps, sooner or later I should get again the PHASE_INC initial value where I started from, that is the initial frequency (mathcing again the other generator). In software I included enough delays to make the unitary changes of PHASE_INC painfully SLOW ensuring to have a smooth control of the changes. Simulation shows that PHASE_INC is increased/decreased by one, every time. (?)
c - I have an option, via keypad where I can change the PHASE_INC to different fixed values. Doing that to both generators, I get again matching (and stable) frequencies at the output. It's the up / down thing that ruins everything.
Please, can anyone tell me if I am overlooking something too obvious regarding the DDS principle, considering that the problem shows up only when I change one of them whether Up or Down.
Help really appreciated. (I wish I could explain this in a shorter text!! - Sorry)
