Frequency related pulseio PWMOut.duty_cycle does not retain set values accurately #1118
Comments
|
Does this still happen with 3.0.2? Thanks! |
|
Unfortunately, it still happens. I finally got a chance to test this again (on 3.1.1) |
|
Now that I read this I realize its by design. The number you read back is the actual duty cycle being output. As you've found, the accuracy varies somewhat with frequency. This is due to the top value of the underlying counter varying to achieve the target frequency. I think this is how it should work, if we store the input value and then return it we'd be giving false info back. If you want to ensure even steps from your end I recommend storing the last set value. Will that work for you? I'm closing this now but we can continue the conversation as needed to get you going. |
|
Your statement seems to imply that the read back value of the actual duty
cycle would fluctuate slightly because the underlying target counter is
fluctuating? So if I repeatedly give it the same value at the same
frequency, and read back the result, then, because the underlying target
counter is fluctuating, the read back value would fluctuate?
I did a series of tests involving setting the duty cycle to a constant and
printing out the value. I did these at multiple frequencies and with a
range of duty cycle values. And I found that:
* The read back value is a constant.
* The read back value is always 1 lower than the set value for frequencies
from 1 to 2354
* For frequencies of 2355 and above you start to see discrete instances
where the read back value is 2 lower, but most are 1 lower.
* As you continue to increase the frequency you start to see read back
values of increasing discrepancies.
I've already started managing my own set values on my end to limit the
ramifications of the phenomenon and limiting my frequency to no higher than
2354. As such, I can simply use a +1 value for my initial duty cycle value
and I'm having zero discrepancy issues.
I don't really have any stake in this being looked at other than an
interest in improving the product. But I think there is still a -1 error
in setting the initial duty cycle and I think there's a rounding error that
starts becoming a factor at frequencies above 2354.
…On Tue, Nov 27, 2018 at 12:55 PM Scott Shawcroft ***@***.***> wrote:
Closed #1118 <#1118>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1118 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Am0D2uU915rKN73hWSes8ZdAeXuAqA5cks5uzZi7gaJpZM4V-mx9>
.
|
|
Sorry, I meant to say the read back value may be different from the set value. The returned value should always be the same for a given frequency, set value and underlying timer. Its due to resolution loss in the underlying capture/compare value that drives the duty cycle. |
|
Okie Dokie
…On Tue, Nov 27, 2018 at 11:49 PM Scott Shawcroft ***@***.***> wrote:
Sorry, I meant to say the read back value may be different from the set
value. The returned value should always be the same for a given frequency,
set value and underlying timer. Its due to resolution loss in the
underlying capture/compare value that drives the duty cycle.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1118 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Am0D2nF83-A_jkFF-BBhwvAclOBGGazoks5uzjIFgaJpZM4V-mx9>
.
|
In general, PWMOut.duty_cycle does not retain or increment or set values correctly.
It is also frequency dependent, so the amount of incorrectness changes with frequency.
It may be that frequency changes are simply compounding the initial value inaccuracy.
May or may not be related to #1106
And now for some examples:
The text was updated successfully, but these errors were encountered: