Unstable sine PWM output

[pxidr84]

No ideas for this problem?

[cncmachineguy]

Not sure of a solution yet, but from watching the posted video, I am guessing the problem is some kind of timing issue. I don't think you have things configured wrong as the output looks great most of the time. Rather I think there are some times when a counter gets reset of an interrupt gets interrupted. It glitches then goes right back to perfect wave.

If you watch it and don't alter the frequency, does the glitch happen at regular intervals, or is it random in nature?

[mister_e]

I think Alain may have a point, I would try to skip the DIV32... let's say assign a fixed value there and let it run idle to see if the problem persist.

[HenrikOlsson]

Hi,
I don't know if DT-Ints have any impact on DIV32, I'd guess no but I don't know. The manual says that it's not recomended to have interrupts enbles if using ON INTERRUPT because the system variables that DIV32 relies on might get changed by the ISR. But DT-Ints saves the system variables so I don't think it should be an issue.

With that said I don't see the reason for calculating the interrupt frequency "all the time". If I read your code correctly your TMR0 interrupt executes at around 38Hz so it calculates the reload values 38 times per second. As long as the desired frequency isn't changed the reload value for TMR1 doesn't change so why keep calculating it?

Instead, do it in your Main-loop and even better calculatie it only when the desired frequency have changed.

Now, I think you think that you AREN'T calculating it "all the time" but look closely at your TMR0 interrupt service routine:

' PWM calculation interrupt (Timer 0)
calcint:
' Recalculations
if flag=%1 THEN             '<----Calculate only when Flag=1
   ' Reload timer calculation
  dum=dum1*dum2
  reload=Div32 freq
  reload=(65535-reload)+8
  ' U/F calculation
  if freq<=500 then
     amp=(freq*131)+35
  ELSE
      AMP=65535
  ENDIF
  flag=%0
ENDIF
' Frequency reference control by potentiometer
potsense=((potsense<<6)**maxfreq)+5
if potsense<>freq then freq=potsense:flag=%1
' Frequency limits
if freq<minfreq then freq=minfreq
if freq>maxfreq then freq=maxfreq
@ INT_RETURN

That flag=%1 is NOT part of the IF-THEN statement so flag will get set every interrupt no matter if the frequency have changed or not and therfor the calculations of the reload values will get executed every interrupt.

[pxidr84]

Thanks for your help.

So I've tried first to set a fixed reload value (64594) without calculations (to obtain 120Hz sine, the max. frequency). The sine wave was perfectly stable on the oscilloscope.

This :

dum=dum1*dum2
reload=DIV32 freq
reload=(65535-reload)+8

was removed and replaced with :

reload=64594

I've also applied Henrik tips, like this :

' Frequency reference control by potentiometer
potsense=(potsense<<6)**maxfreq
IF potsense<>freq THEN 
freq=potsense
flag=%1
endif

And set the reload calculation routine into the main loop.

Results : it's more stable, but the glitches still appears when I change the frequency of the sine (so the reload calculation routine is executed during this time).

I'm pretty sure that the problem is caused by DIV32. However this routine is needed :

dum=dum1*dum2
reload=DIV32 freq
reload=(65535-reload)+8

How to replace the "DIV32" by an another thing? It is possible to use that : http://melabs.com/resources/fp.htm ? Or anything else?

[HenrikOlsson]

Hi,
It might be the DIV32, we'll have to get Darrel to answer that or have someone dig into the ASM code and figure out if the PBP registers used by DIV32 are being saved by DT-Ints or not (I still think they are).

My guess is that it isn't actually DIV32 that is causing it but something else with the way the frequency is changed. Why not try constantly ramping the frequency up and down in your main loop? Don't use DIV32, just "sweep" the reload value up and down between your MIN and MAX values. Does it still glitch? If so we know that it's not DIV32 that's causing it but something else.

If it turns out that it IS DIV32 then we can look at other solutions. The DIV32 thing was in response to your request of directly calculating the reload value based on the desired output frequency scaled in Hz. Simply rescaling to some arbitrary "unit" might allow the calculations to be done without DIV32 but it comes with a couple of commitments which I won't go into until we know that that DIV32 is the problem.

Can you explain to me where the values 34696 and 32 comes from?

/Henrik.

[pxidr84]

Hi,
It might be the DIV32, we'll have to get Darrel to answer that or have someone dig into the ASM code and figure out if the PBP registers used by DIV32 are being saved by DT-Ints or not (I still think they are).

My guess is that it isn't actually DIV32 that is causing it but something else with the way the frequency is changed. Why not try constantly ramping the frequency up and down in your main loop? Don't use DIV32, just "sweep" the reload value up and down between your MIN and MAX values. Does it still glitch? If so we know that it's not DIV32 that's causing it but something else.

If it turns out that it IS DIV32 then we can look at other solutions. The DIV32 thing was in response to your request of directly calculating the reload value based on the desired output frequency scaled in Hz. Simply rescaling to some arbitrary "unit" might allow the calculations to be done without DIV32 but it comes with a couple of commitments which I won't go into until we know that that DIV32 is the problem.

Can you explain to me where the values 34696 and 32 comes from?

/Henrik.

I've done like you said a simple ramp in the main loop :

reload=reload-1
if reload<40000 then reload=64600

The sine frequency ramped down, and after many cycles, no glitch appeared on the oscilloscope. During this time I've played with the potentiometer to vary the amplitude and also I navigate into the inverter menu, the sine wave was not disturbed at all.

So the problem is clearly DIV32. Apparently this command disturbs DT Instant Interrupts.

I've already changed the "34696" and "32" dummy values to "1120" and "1000", it's far better to understand.