[sdiy] DsPIC timer issue when used as DCO!

[Tom Wiltshire]

Thanks Neil, this is good stuff. Some comments inline.

> After pondering over this I think Colin is close.  Allow me to  
> expand on my thoughts.
>
> Lets refresh thanks to Tom's augmented diagram:
>
> http://www.electricdruid.com/P08Glitch.gif
>
> Start at the point where the triangle wave suddenly changes rate,  
> at about 1s710.4ms.  I think that at this moment in time the  
> control voltage, and hence integrating current, changes to a higher  
> value, resulting in a much faster ramp rate.
>
> A short time later, at about 1s710.5ms the wave folder kicks in and  
> folds over the top half of the ramp to generate the triangle.
>
> [You can see further evidence of the wavefolder at 1s707.5ms - that  
> little dip is the ramp moving out of the wavefolder.  Also notice  
> the slight curve at the bottom of the triangle - is this evidence  
> of the internal current source running out of headroom (compliance?).]
>
> At 1s711ms the folded-over ramp reaches its limit and can rise no  
> more.  As this is folded over it looks like it has stopped at the  
> bottom of the triangle.

So far, so good. All description of fact.

> Nothing happens now.  The gradual rising slope towards 0V we see  
> is, I believe, due to the AC-coupling on the output - its your  
> classic RC decay curve, for large R and large C.  You can see a  
> little more evidence of this when the oscillator gets going again -  
> notice a gradual change in the peaks after 1s725ms as the DC bias  
> is slowly filtered out.

Slightly less definite, but that's my interpretation too. The slow  
rise (and subsequent return to symmetry around 0V) suggest a RC  
drift, not a charging current in the actual ramp core. That gradual  
rising slope from 1s711mS is supposed to be flat, but we're seeing it  
the wrong side of some AC coupling.

> WHERE EXACTLY WAS THE SCOPE PROBE WHEN THIS MEASUREMENT WAS  
> TAKEN..???  If we are looking at the final audio output on the back  
> panel jack then we can definitely expect some AC coupling along the  
> path.

I agree with Colin. I doubt the person who posted this file opened  
the synth up. They took basic precautions to disable as much as they  
could (open the filter right up etc) but this is just the synth's  
output into a computer.

> Keep waiting.  At 1s723ms the timer reaches the 'old' period  
> value.  If the timers are being used as a 32-bit timer then all  
> that can happen is an interrupt or ADC being kicked.  Lets assume  
> that is the case.

Yes. I think that's a good assumption. Partly because 16-bit timers  
aren't accurate enough on their own (not even for the Juno) and the  
timer prescalers don't really solve the problem. Using 32-bit timers  
would be the logical way around it, and the numbers (1 uP for 2  
voices, 2 DCOs per voice = 4 x 32-bit timers) suggest that this is  
what has been done.

> So given what seems to be happening in the diagram it is reasonable  
> to assume that the interrupt handler itself toggles some external  
> pin to reset the analogue ramp.  If it was also the case that the  
> interrupt handler was also the ONLY place in the firmware that the  
> timer was (re)configured then that would explain precisely why what  
> happens happens.

Yes. If the charging CV were generated by the main modulation DAC, it  
would be updated every modulation cycle (which is 1.6KHz in the  
Prophet 08 I believe). The timer, however, isn't reset until the  
interrupt occurs. This leaves a *maximum* of 625uS when a glitch  
*could* occur, assuming that the DCO frequency is rising, and that  
the current timer value (TMRx) is greater than the new period  
register value (PRx).
That's a pretty short window for the glitch to happen in, and a  
couple of things that have to be true for it to happen at all - you'd  
probably just decide it was close enough, wouldn't you?!
If they thought about it at all, I think that's where DSI decided  
enough's enough. After all, they've got to get the product out of the  
door. Development time costs money, and lots of it.

> This is not a bad thing in itself - at timer compare we know pretty  
> much the state of the timer (its just reset, so pretty close to 0),  
> so its a reasonable first step to getting the timer working without  
> worrying about more complex corner cases.

There's a trade-off here. You could avoid the glitch ever happening  
by only updating the charging CV when the interrupt occurs. This  
would solve one problem, but would reduce the resolution of  
oscillator pitch modulation to a single wavecycle (e.g. pitch can  
only change at the end of wavecycle).
Doing it the way they've done it gives them pitch modulation at  
1.6KHz even for lower pitches. The potential glitch in some cases is  
the price they've paid for doing it the simple way, rather than  
trying to reset the timer during a cycle.

> If the timers are being used in 16-bit mode then the output compare  
> module can be used to generate pulses to reset the ramp.  Except  
> now we have even more registers to change every time the pitch  
> changes.  I think the greater complexity would suggest it even more  
> likely that the firmware only updates the timer/compare registers  
> at the end of a timer period.  The minimal pitch increment would  
> suggest whether the timer used was 16 or 32 bit.

Yes. The pitch steps for a 16-bit timer are around 20 steps per  
semitone at the very top end (>10KHz). I don't know whether that is  
audible - I doubt it. I know damn sure that you won't hear *any*  
steps from a 32-bit timer. The inclusion of "Oscillator slop" on the  
Prophet suggests a high pitch resolution to me - I think we're safe  
to assume 32-bit timers are used.

> At least, that's my interpretation on a Friday morning.

And those are my comments on Friday afternoon!

Thanks,
Tom