Skip to content
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

Open
tomek-szczesny opened this issue Nov 4, 2021 · 6 comments
Open

[Feature] Overcurrent protection #8

tomek-szczesny opened this issue Nov 4, 2021 · 6 comments

Comments

@tomek-szczesny
Copy link
Contributor

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.

@tomek-szczesny
Copy link
Contributor Author

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.

@cedel1
Copy link
Contributor

cedel1 commented Apr 3, 2023

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:

  1. hardware overcurrent protection up to 2.4A ("super-safe" mode for hacking),
  2. Software or no overcurrent protection - like it is now (for device consumption measurment) allowing temporary peaks.

Or am I missing something?

@tomek-szczesny
Copy link
Contributor Author

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.

@cedel1
Copy link
Contributor

cedel1 commented Apr 3, 2023

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.

@tomek-szczesny
Copy link
Contributor Author

No worries!

@maribu
Copy link

maribu commented Feb 1, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants