Open Source Arduino Alternator Regulator

[markxengineerin]

ElegantOTA is working to flash updates through Wifi, using a .txt file ... ... I think this will be a nice convenience for anyone who wants to edit parameters

After taking a step back, I no longer think I have this feature working well enough. To use ElegantOTA, the user not only has to install the Arduino IDE, but make a few customizations to it, including adding a plug-in that converts the simple .txt configuration file into a .bin file that can be accepted by ElegantOTA. The location in which the plugin places this .bin file is going to be different on every computer, not easy to find, etc. Long story short, ElegantOTA is much less convenient (for changing a configuration) than just editing the code directly. For flashing an overall program "over the air", it also won't work in this application, because ElegantOTA is limited to programs that are less than half the available SRAM. I'm at 66% with not all features yet accounted for.

Instead, I'm continuing to learn about ESPAsyncWebServer, and found a few examples:
https://randomnerdtutorials.com/esp3...erver-arduino/ - controls LED lights based on buttons from a web page
https://randomnerdtutorials.com/esp3...nt-events-sse/ - update gauges on a web page with live sensor data
https://randomnerdtutorials.com/esp3...server-gauges/ - another example of above

My current thinking is to use a similar strategy as the first example, to send values from the webpage to the ESP32:


Other than having to learn some html / syntax, which I think is do-able, also need to learn how to read/write from ROM so that these settings are saved (at least the ones that should be) when the regulator is power cycled.
https://randomnerdtutorials.com/esp32-flash-memory/

Then use the other 2 examples to show whatever outputs we want on the webpage:


If anyone would like to help with coding this, or knows of a more complete example I could borrow from, that would be nice. The ideal example would communicate settings from web browser to ESP32, store some of them in ROM, to be remembered at the next re-start. The same example would also read sensor data from ESP32 and display on web browser.

[s/v Jedi]

I think you should keep at #define for now and get the regulator working 100% before adding user interface etc.

[markxengineerin]

The regulator works in breadboard form, using as many of the same components as the custom PCB as I have available. I decided not to order the first few PCB's until I had gotten far enough along with each feature request (in software too) to make sure I had the right hardware selected. This turned out to be a good decision, because the CAN hardware needed several changes.

I don't think the user interface will affect the hardware choices, but I don't know what I don't know, and this isn't delaying the PCB's at this point.
Edit: one example- if the web interface works well enough, it could be argued that there's no need for physical switches or an OLED display. That would simplify the design. I don't think I will make this decision because WIFI can be very frustrating to work with- just using this as an example of what might be learned by working on this in parallel.

[s/v Jedi]

Originally Posted by markxengineerin

The regulator works in breadboard form, using as many of the same components as the custom PCB as I have available. I decided not to order the first few PCB's until I had gotten far enough along with each feature request (in software too) to make sure I had the right hardware selected. This turned out to be a good decision, because the CAN hardware needed several changes.

I don't think the user interface will affect the hardware choices, but I don't know what I don't know, and this isn't delaying the PCB's at this point.

Will you test the beta regulator thoroughly now or rely on software changes later?

For example, did you run the alternator at high load for an extensive amount of time, testing the field current driver temperature etc. Did you put a heat gun on the alternator mounted temperature sensor to see if that triggers protection routines in the regulator?

Etc.

Would love to see pictures, performance graphs etc. Did you use N-type MOSFET? Active or passive cooling etc.

[Artey]

Mark, do you plan to sell these or leave them open source? Do you have a github repo to share? Maybe some talented coders could branch to help you finish out the user interface while you test the remainder of the scenarios and figure out the CAN?

[markxengineerin]

Will you test the beta regulator thoroughly now or rely on software changes later?

I tested what I could, created one fire, did what was possible before having the custom PCB's made. The field current driver is not the same as the custom PCB (Vishay SiC450). Breadboard used an H-Bridge motor controller (https://www.amazon.com/Teyleten-Robo...zcF9hdGY&psc=1) Passive cooling in both cases. The OneWire temperature sensor works as expected.

I will be selling and leaving as open source, both, see post 71 in this thread for more discussion on that.

I have never used GitHub but will try to figure that out tonight. The issue with the code is that it's being assembled in pieces, which mostly work individually, but the overall program isn't started yet, and I'm not sure how much useful testing would be possible without the hardware. However, we have to start somewhere, so I'll try to document a starting point as of today.

[markxengineerin]

https://github.com/markliquid1/AltRegESP32

[Artey]

Originally Posted by markxengineerin

https://github.com/markliquid1/AltRegESP32

I'm learning it all too, for my personal python, ESP, and Arduino projects. I'll take a look when I have some more time and see if I can branch and look at the user interface stuff. I'm probably in the same starting point as you when it comes to the CAN stuff. Everything you've done to this point is pretty incredible man! Keep it up!

[markxengineerin]

Thanks!

Coming back to optoisolators for the digital inputs

I could use advice on how to down-select from more than 2000 opto-isolators on DigiKey.

Goals:

-Appropriate for switches/push buttons (somewhat slow speed is ok for these). Most digital input channels will connect to toggle switches, plan to use ESP32 internal pull up resistors (3.3V).

-One channel should accept a 3-15V "stop charging" signal from outside battery management system.

-One channel will be used for "OneWire" temperature sensors- this one may have speed needs, I am not sure how tough they will be to meet.

-cheap and easy to implement , KISS principle

-popular chip that will be easily available

-An 8 channel chip, or 8 single channel circuits, doesn't matter to me. I'm making up the number 8, but the needs are likely ~ that many channels or less.

[spirare]

Originally Posted by markxengineerin

Thanks!

Coming back to optoisolators for the digital inputs...

Let me have a look and get back to you.

[spirare]

Originally Posted by s/v Jedi

Will you test the beta regulator thoroughly now or rely on software changes later?

For example, did you run the alternator at high load for an extensive amount of time, testing the field current driver temperature etc. Did you put a heat gun on the alternator mounted temperature sensor to see if that triggers protection routines in the regulator?.

Extensive testing but more importantly at this stage are all the built-in software & hardware fail-safe mode are in the design yet ? For example; a broken temperature sensor wire should put the regulator in a safe mode (low amp. output)...etc.

[FPNC]

A stator tach signal that will maintain stability and not cut out.

[markxengineerin]

A stator tach signal that will maintain stability and not cut out.

https://www.ti.com/lit/ds/symlink/lm...oogle.com%252F

Datasheet is confusing as hell. What level of signal is needed for this chip to work?
I can't speak for all alternators, but the lowest my Hamilton Ferris small frame alternator goes, with no field current, is +/- 50mV. As long as I'm reading the datasheet correctly and others are similar, I think we're good on that.

[markxengineerin]

all the built-in software & hardware fail-safe mode

Work on software has been minimal, I've only done the minimum to prove to myself that that hardware choices are good. I am hoping for significant software contribution from the community once the hardware is finalized and perhaps someone with more software development experience takes over. My code is not clean, I'm a self-taught mechanical engineer.

Most safeties, in my mind, are completely software. The only hardware one I'm planning is, in the case of a hardware failure outside of the INA3221, this card will shut down field current when it measures a battery voltage >threshold, independent of any other components working. The odds of this card failing at the exact same time as the microcontroller, but the SiC450 surviving (this is the component making the field current), seem very low. So I think it's quite safe.

Open to other suggestions for hardware safeties. There's also the usual fuse on the input power, should be set to something just > the highest required field amps. For me, it's ~5.

[markxengineerin]

For optical isolation, I had an easier time selecting a chip for the UART channels than for the physical switches, because the speed requirement narrowed it down quickly. I'm thinking this one:
https://toshiba.semicon-storage.com/...odName=TLP2270

Using it seems as easy as this:


But this will be untested. I've been using a 5V/3.3V logic level shifter instead of the optoisolator because it's all I have on hand, and my test signals are limited to 5V maximum anyway.

If I understand correctly, the optoisolator with above layout will send a 3.3V logic signal out to the ESP32 with any serial input signal between 3.3V and 15V.

I was not planning any low pass filter in this circuit, but could add one if people feel it's needed.