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

Hardware Revision 4 Initial Commit #82

Merged
merged 3 commits into from
May 25, 2024
Merged

Hardware Revision 4 Initial Commit #82

merged 3 commits into from
May 25, 2024

Conversation

CoretechR
Copy link
Owner

I am really happy about the interest interest in this project and the support from the community. That is why I wanted to fix a few issues and hardware-bugs with a new hardware revision. The changes for this new revision 4 are intentionally kept simple, so existing boards will still be software-compatible. I have lots of ideas for major changes to the hardware, but that is something for a later date. For now this is what's new:

Changes in hardware:

  • Fuel gauge IC for battery monitoring
    The MAX17048 is a so called fuel gauge, meaning that it monitors the battery charging and discharging. It does not actually measure current but does some fancy guesswork based on the battery voltage. Instead of having to use the ESP32 ADC, the fuel gauge outputs the battery voltage and percentage via I2C. This makes for a much more precise battery monitoring, similar to a smartphone.
  • Onboard LiPo protection (Battery discharge protection #53)
    Using a battery with internal protection is still recommended but the OMOTE now features internal protection for overvoltage, undervoltage and overcurrent using the DW01A. This IC is inexpensive and can be found in many off the shelf LiPo chargers.
  • Testpoints added for critical signals (as suggested by @Dark1886)
  • Capacitor on ESP32_EN changed from 100nF to 1uF ( C15 too small for reliable uploads with Windows 11 #62)
  • Easier to source and cheaper LiPo charger (TP4056)
  • LiPo charger status input fixed(Battery charge status not reliable #55)
    The status pin is now pulled up to 3.3V instead of 5V

Changes in software:

  • MAX17048 added
    The fuel gauge can be enabled by defining board revision 4 in Platformio.ini. For older board revisions the battery monitoring is unchanged.

Changes in hardware:
- MAX17048 for battery monitoring instead of ESP32 ADC
- Onboard LiPo protection for overvoltage, undervoltage and overcurrent (DW01A) (issue #53)
- Testpoints added for critical signals
- Capacitor on ESP32_EN changed from 100nF to 1uF ( issue #62)
- Easier to source LiPo charger (TP4056)
- LiPo charger status input fixed(issue #55)
Changes in software:
- MAX17048G added as source for battery stats (enabled by defining board revision 4 in Platformio.ini)
@KlausMu
Copy link
Collaborator

KlausMu commented Apr 25, 2024

Thanks, @CoretechR
Software part looks perfect. Only this line was lost in the branch: https://github.com/CoretechR/OMOTE/blob/84e889510298cc2fc874d3830630d6d83d682210/Platformio/src/applicationInternal/hardware/hardwarePresenter.h#L58C3-L58C24

IR_PROTOCOL_SAMSUNG36 had been removed by mistake
@KlausMu
Copy link
Collaborator

KlausMu commented Apr 25, 2024

In main.cpp, we now have inits in the following order:

init_battery();
...
init_tft()
...
// setup the Inertial Measurement Unit (IMU) for motion detection. Has to be after init_gui(), otherwise I2C will not work
init_IMU();

Are you sure that this works? Because init_battery() now uses I2C, but the I2C pins are set later in init_tft().

@CoretechR
Copy link
Owner Author

Yes, the battery monitor is definitely working. Why is a good question, @KlausMu. The begin() function seems to not do anything but check if the device responds. It probably only starts to work correctly after the touchscreen was initialized.
Should we move the battery init after the touchscreen init? Maybe that is not necessary if it works anyway.

@KlausMu
Copy link
Collaborator

KlausMu commented Apr 25, 2024

Yes, fuelGauge.begin(); has a return value, which we ignore. But I think the result is not important, because further calls to the library do not depend on the result of fuelGauge.begin();

Probably you could even replace fuelGauge.begin(); with fuelGauge.setWirePort(Wire); and it will still work, without ever calling fuelGauge.begin();

So I think we can keep the init where it is.

@JustMe-NL
Copy link
Contributor

I like the idea of the fuel gauge. Should be pretty easy to add to ref. 3 in deadbugstyle as well. I’ll order some and try it out.

Thank you Discord user TechnoSwiss!
@CoretechR CoretechR merged commit 9966a8f into main May 25, 2024
4 checks passed
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

Successfully merging this pull request may close these issues.

None yet

3 participants