-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Overcurrent protection #8
Comments
I'm working on implementing this feature in main loop. I have to retrieve current limit set by the user. It is stored in NVS and also in Channel object belonging to Screen. It seems it is easier (and safer) to get it from NVS directly, but is it as fast as reading a variable? This will be done twice every 2ms. |
I was just wondering... Since the chip has hardware overcurrent protection feature whose use was removed because of it acting too early (explanation on Odroid wiki and forum) and the feature would be useful for people using Smartpower more as cheap bench power supply... wouldn't it be more sensible to make the hardware overcurrent protection selectable in settings? Like use mode:
Or am I missing something? |
Not sure if you missed that or not, but hardware overcurrent protection has been disabled in hardware, meaning it would require PCB modification to turn it on again. IF I remember correctly... However, current measurement is still there and may be used for overcurrent protection. Some small delay under 50ms is still acceptable and better than nothing, so I think software OCP makes total sense. One thing worth noting, my current smoothing algorithm will introduce further delay in detecting the overcurrent condition, this must be taken into account. Preferably by using a separate, more conservative filter for this functionality, if any. |
Hmm, I've probably missed that - I am a noob in electronics, just skimmed over the thread and just went by the STPD datasheet which says that the CC feature can be disabled on the software side (so I've expected that's what happened). Didn't check the schematic much. Sorry. |
No worries! |
I added a quick and dirty PR that adds a very limited overcurrent protection in software: #37. That PR is severely lacking in a number of regards, but it is better than nothing and may help as a basis for a proper implementation. |
I think this is by far the most necessary lacking feature above all.
There is already a GUI mechanism for setting current that does nothing except of changing digit color to yellow.
Main
loop
can check current on each iteration and disable the channel if the current is exceeded."OC" or "OCP" icon should be highlighted in this case. It may be cleared when user enables channel again.
The text was updated successfully, but these errors were encountered: