Skip to content

Commit

Permalink
auto commit via obsidian-git: 2024-04-08 19:11:25
Browse files Browse the repository at this point in the history
Affected files:
content/Max number of multiplexed elements depends indirectly on channel output capacity and speed of PWM clock.md
  • Loading branch information
smaroukis committed Apr 8, 2024
1 parent e522162 commit 85eb75d
Showing 1 changed file with 5 additions and 3 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -79,9 +79,11 @@ So here is the summary of the specific case (N=10, $f_{RR}=100$, $f_{PWM}=1\text
## Final Thoughts

Things to note
- number of segments doesn't really affect anything except for the current requirements (these are basically parallel outputs) → although the MCU will have to either cycle through $K_{seg}$ to check if it should be still "on" or not for the individual brightness control OR setup callback timers depending on the individual brightness levels, so it does add complexity to the serial code
- tradeoff between $M_{perceived}$, levels of perceived brightness, and $N_{digits}$, since the more digits we have cuts into the number of PWM units we can give to each multiplex cycle.
- I think the limiting factor on $N_{digits}$ is the $f_{RR}$ and the minimum on-time. But note that the minimum on-time is actually very dependent on the amount of current that we push through it, so actually **the channel max current limits the number of multiplexed digits _indirectly_ through $T_{mux,min}$** — even though we noted that the channel current directly impacts the number of _segments_ (parallel outputs) and not the number of multiplexed digits.
- although it seems like the number of segments doesn't really affect anything directly except for the current requirements, actually it will be this per channel max current along with the duty cycle and desired brightness that will determine the maximum number of multiplexed elements we can use (see bullet below)
- more segments could increase number of MCU cycles which has to either cycle through $K_{seg}$ to check if it should be still "on" or not for the individual brightness control OR setup callback timers depending on the individual brightness levels, so it does add complexity to the serial code (still TBD on implementation which could be done with interrupts to avoid MCU having to check each segment during each cycle)
- there is a tradeoff between $M_{perceived}$, levels of perceived brightness, and $N_{digits}$, since the more digits we have cuts into the number of PWM units we can give to each multiplex cycle.
- $f_{RR}$ and the minimum desired on-time will set a limit on $N_{digits}$
- furthermore the minimum on-time is actually very dependent on the amount of current that we push through it, so actually **the channel max current limits the number of multiplexed digits _indirectly_ through $T_{digit,min}$** — even though we noted that the channel current directly impacts the number of _segments_ (parallel outputs) and not the number of multiplexed digits, it is the duty cycle that sets $T_{digit}$ and as more multiplexed elements are added the required instantaneous channel current increases proportionally.

[^1]: this nth root function is similar to $\log_2 x$ but with less of a "knee"
[^2]: I will also need to add off time for de-ghosting

0 comments on commit 85eb75d

Please sign in to comment.