PCB für Lilygo TTGO T5 V 2.3.1

Hallo Zusammen,

passt nicht 100% zu diesem Bereich, daher wenn es nicht passt verschieben oder löschen.

Beschäftige mich mit dieser Thematik schon eine Weile und bin über viele Umwege auf dieses großartige Projekt gestoßen.
Jedoch bin ich nicht so der Fan von gesteckten und wild verdrahteten Serienlösungen ( zu viele negativen Erfahrungen und Preudofehlersuchen), daher versuche ich immer eine Platine zu entwerfen wo relativ viel enthalten ist. Hier sind schon einige guten Ideen welche ich gerne aufgreifen will. Mein Ansatz wäre folgender mit bitte um konstruktiver Kritik:

  1. Controller LILYGO®TTGO T5 V 2.3.1
    1a) Link LILYGO®TTGO T5 V 2.3.1 _ 2,13 Zoll E Papier Bildschirm Neue Fahrer Chip DEPG0213BN / GDEM0213B74 /GDEM0213B74|Circuits| - AliExpress
    1b) hat wie der Lolin 32D Pro 16MB Flash.
    1c) Jedoch kann man die SD Karte auch im MMC Modus betreiben.
    1d) Laut einigen Github repos auch Ruhestrom von 380µA machbar.
    1e) Laderegler OnBoard
    1f) Übersehe ich Nachteile bei dem Bord oder warum setzen die meisten neuerdings auf Lolin 32D Pro?

  2. Audio
    2a) Soll nicht nur für meine Kinder sein sondern auch für mich als Webradio, daher Stereo Audio mit zweimal MAX98357
    2b) Jedoch hätte ich dies gerne auf meiner Platine und nicht aufsteckbar( weniger Wackelkontakte und Platzsparender)

  3. RFID
    3a) Würde wegen Reichweite und Aufweck-Möglichkeit auf den PN5180 setzen
    3b) Hier jedoch als Einzelplatinen Lösung ( dies ist mir noch zu kritisch dies selbst zu entwerfen)

  4. Als Ruhestromfresser sehe ich nur noch den Neopixel-Ring, da würde ich gerne eure Mosfet-Schaltung umsetzen. Die anderen Komponenten sollten sich in einen stromsparenden Modus versetzen lassen oder was habe ich übersehen?

  5. Porterweiterung
    5a) Eure Porterweiterung mitteln PCA9555 ist eigentlich was einfaches und Gutes!
    5b) Jedoch habe ich schon eine Sensor-Platine über I2C, bin noch am überlegen auf welche Variante ich setze?
    - I/O mittels MAY7311 einige sind noch frei
    - Mehrere Umweltsensoren z.B. BME280, CCS811, BH1750 (müsste ja nicht alles Bestücken)

A) Herausforderung wird den RFID auf demselben SPI wie der Display zu betreiben, aber wenn man nicht zu oft zeichnet sollte dies gehen oder was meint Ihr?

B) Wo seht ihr noch Herausforderungen bzw welche falschen Annahme habe ich gemacht?
Könnte ich das ganze KiCad Projekt haben um darauf aufbauend meine eigene Platine zu entwerfen?

ECU Pinbelegung:

Platinen Pinbelegung:

2022-01-06T10:00:00Z

@Ringer: Habe deinen Beitrag mal in einen eigenen Thread nach hier verschoben.

Im Endeffekt ist es so, dass ich nicht alle Boards testen kann (und will). Was mich bei Lilygo generell so ein bisschen stört, ist die recht unübersichtliche und lahme Website. Beim T8 war für mich auch immer so die Frage, was sich zwischen den einzelnen Revisionen eigentlich im Detail geändert hat. Vom T8 gibt es auch eine Version v1.8. Die muss man aber suchen. Das finde ich irgendwie seltsam. Also grundsätzlich fehlt mir da irgendwie so ein bisschen die Transparenz und Übersicht; das ging mir (auch wenn das mit Lilygo nix zu tun hat) beim ESP32-A1S-Audiokit auch schon so. Da „fühlt“ sich ein D32 pro für mich irgendwie besser an und man kriegt den auch in Deutschland gut. Insgesamt habe ich mit den Wemos-Boards gute Erfahrungen gemacht, so dass ich sie gerne immer wieder verwende.
Da steckt natürlich viel Subjektivität drin in meinen Zeilen. Anders gesagt: Ich will dich nicht davon abbringen, den zu verwenden.

Ich meine von MAX gibt es auch einen Chip, der von Adafruit angeboten wird, der Stereo kann und eine ClassD-Amp besitzt. Aber weiß gerade die Nummer nicht. Aber ja: Gehen tut das mit zwei Stück.

Weiß nicht, an wen sich das richtet. Aber die sind auch bei mir aufgelötet. Ich hatte sie anfänglich mal gesockelt, aber damit habe ich schlechte Erfahrungen gemacht. Seitdem löte ich die Pinheader auf.

Der PN5180 frisst bissl was, wenn man darüber aufwecken möchte. Ansonsten schalte ich einfach alles ab. Aber ich denke deine Annahme ist richtig.

In wiefern schließt sich das denn aus? Du kannst doch an den i2c-Bus mehrere Geräte hängen.

Das kann ich nicht beurteilen. Ich würde Display via i2c machen, weil der i2c-Bus wegen dem Port-Expander eh schon da ist. Genau es dem Grund hat mein aktueller D32pro-PCB auch einen i2c-Breakout.

Der ESP32 verhält manchmal etwas seltsam mit seinen GPIOs, was halt dazu führt, dass es nicht unbedingt bei der ersten Iteration klappt. Da muss man halt ausprobieren.

Mir fällt gerade ein, dass ich hier schon vor zwei Wochen von @aelray nach KiCad-Files gefragt wurde und jedoch nur Gerber hochgeladen habe. Sorry, das habe ich verpeilt. Also ich lade die hier noch hoch in Kürze, aber ihr müsst euch dann halt Symbol/Footprint für die TTGO im Netz suchen.

Hallo @biologist,

vielen Dank für die Aufnahme und schnelle Beantwortung.

Dies ist völlig verständlich und war auch nicht der Wunsch. Eher ob grobe Schnitzer drinnen sind und ich mein Konzept überarbeiten sollte?

Ja nach längerem stöbern muss ich dir recht geben die Informationen von Lily sind alles andere als Gut.
Habe zwar hier was gefunden LilyGo-T5-Epaper-Series/T5V2.3.pdf at 00c7b9c83845bda234439df82081c9ce2ce434a9 · Xinyuan-LilyGO/LilyGo-T5-Epaper-Series · GitHub jedoch scheint mir dies nicht unbedingt unterschiedliche Versionen zu sein sondern schon fast unterschiedliche Varianten :see_no_evil: Mir hatte die passende Beschaltung für die SD Karte gefallen und wollte schon immer mal was mit einem Display machen ;). Wenn du da schon was mittels I2C ins Auge gefasst hat darf man Wissen was genau, vieleicht können wir da was gemeinsames machen ? Bin mit jetzt wieder unsicher auf welches µC Board ich setzen soll???

Eigentlich nicht, war nur wenn ich die große Lösung mitttels eigener SensorPlatine machen würde wäre der Portexpander doppelt/unnötig.

Wenn es da was passendes gibt gerne. Welches I2S Modus unterstützt ihr in Projekt PCM oder TDM?

Dies wäre cool hier eine gute Basis zu haben!

Also über Displays etc pp kann ich nix sagen. Aber wenn ich das richtig gesehen habe, ist dort ein E-Ink-Display verbaut. Ich hatte für ein anderes Projekt überlegt, ob ich E-Ink nehme und hatte jedoch gelesen, dass das für schnelle Aktualisierungen nicht so taugt. Wenn ich jetzt überlege, dass man ein Display hat, dann will man dort sicherlich auch die Lautstärke (0 bis 21) anzeigen. Dreht man am Drehencoder, dann ändert sich das schnell. Frage (nein, nicht rhetorisch, weil ich habe es selbst noch nie getestet): Macht sowas mit E-Ink-Display Sinn?

Ansonsten habe ich noch gesehen, dass du für SD vier Pins reserviert hast. Das brauchst bei SD_MMC nicht. Da sind nur 2, 14 und 15 notwendig. CS wird nur für SPI gebraucht.

Zum MAX fande ich es in einem Sheet übrigens witzig, dass die Zahl hinten pro Zeile inkrementiert wird. Aber mir ist schon klar, wie es dazu kam :smiley:

@tueddy Du hattest doch von Lilygo noch was am Start. War das T18 oder so!? Vielleicht kannst dazu was sagen.

Für ein anderes Projekt habe ich sowas hier verwendet: NEUE 0,96 Zoll IIC Serien Weiß/Blau/Gelb OLED Display Modul 128X64 I2C SSD1306 12864 LCD Bildschirm Bord für Arduino|LCD Modules| - AliExpress. Das war eigentlich ok. Mit anderen Displays habe ich noch keine Erfahrung. Das geht jedenfalls über i2c.

Tja, so geht mir das auch manchmal, hehe. Aber am End bin ich dann doch immer zu Wemos irgendwie zurückgekehrt. Deren Boards kriegt man auch gut zu kaufen und das ja irgendwie auch wichtig für das Projekt hier.

ESPuino macht hier so gesehen gar nix und ist quasi „nur“ der Wrapper für diese Lib: GitHub - schreibfaul1/ESP32-audioI2S: Play mp3 files from SD via I2S. Die entscheidet quasi im Audiobereich final darüber, was ESPuino kann und was nicht. Erfolgreich getestet via ESPuino sind (soweit ich weiß) bisher: MAX98357a, UDA1334, PCM5102, MS6324G, AC101 und PT2811 (der braucht I2S_COMM_FMT_LSB_ENABLE).

Hallo @Ringer ,
1:)
Ich habe mich für den TTGO T18 entschieden:
Der ist stromsparend für Batteriebetrieb, hat Laderegler und Akku drauf und kann bis 1A laden. Außerdem viele Pins nach außen gelegt. Zwei Pins sind NC (not connected), da habe ich einmal die Batterie zur Spannungsmessung und auf dem zweiten Pin die USB 5V drraufgelegt um evt. den Netzbetrieb zu erkennen:

IMG_8680
IMG_8681

Wenn Du kein Display benötigst ist dieses Board ein Versuch wert…

3.) Unbedingt PN5180. Minimal teurer aber die Reichweite ist unschlagbar und Du könntest auch die Figuren eines sehr populären Kinderr-MP3-Box-Herstellers verwenden :sunglasses:

@Display

Die Display über I2C und mit dem SDD1306 sind weit verbreitet und gut getestest, würde ich auch nehmen.

In einem anderen Projekt nutze ist das auch (eine Uhr) da kommt es zu Einbrenn Effekten (typisch für OLED), die werden wohl erst nach etlichen Tagen/Wochen Laufzeit auftreten, aber sollte man vielleicht im Hinterkopf behalten…

E-Inks sind leifer nicht sehr schnell…

(Weiter unten die Tabelle mit „Full Refresh Time (s)“ man kann garantiert nur Teile neu zeichnen, aber sollte man vorher mal testen)

Sehr viele Anregungen sehr schööön.
Ja E-Paper Displays sind sehr langsam aber auch sehr stromsparend, eigentlich ideal wenn man was anzeigen will auch wenn grad mal keine Spannung anliegt(sogar Stunden später kann man dies noch gut erkennen. Für schnelle Lautstärkenänderungen wahrlich nicht ideal. Ja macht das Oled schon wieder viel mehr Sinn vor allem wenn es über I2C geht .

@biologist : SD-CS ist gelöscht und MAX Iteration auch korrigiert.

Bezüglich Stereo Endstufe mit Kopfhörerausgang habe ich auch noch was gefunden. Da könnte man sich die Kopfhörer Erkennung via SW und extra Pin sparen da in HW gelöst. Und auch den SD Pin auf dem MAX würde man nicht benötigen wenn man eh alles abschaltet.

@tueddy: Komme auch immer mehr von dem e-Paper ab , da schaue ich mir diesen T18 an, danke dafür.

Was mir gerade aufgefallen ist mit Stereo 3W komme ich wohl in Schwierigkeiten mit dem Endladestrom. Dies ist dann im reine Batteriemodus mit max Laustärke nicht machbar oder?

@tueddy : wie lang läuft dies mit dem Akku im Betrieb?

Das geht auch aktuell schon bei den Lösungen, die es hier gibt. Der Punkt ist nur, dass man damit die Möglichkeit vergibt, dass ESPuino zwei unterschiedliche MAX-Lautstärken (Lautsprecher und Kopfhörer) setzen kann. Weil will man die setzen, dann muss der ESP32 natürlich wissen, welche Modus gerade gefordert ist. Die Lösung für dieses Problem ist allerdings einfach: Man nimmt halt den Port-Expander und genau das habe ich auch getan.

Mit 3.3 V kriegst du eh keine 3 W raus. Ich meine sowas wie 1,8 W oder so im Kopf zu haben.

Hallo Zusammen,
hat jemand Erfahrung mit PN 532 GitHub - adafruit/Adafruit-PN532: Arduino library for SPI and I2C access to the PN532 RFID/Near Field Communication chip würde über I2C gehen. Wäre nochmal ein Ansatz um die Pins zu reduzieren. Scheint weniger als der PN5180 zu können, aber was wären die echten Einschränkungen?

Den PN532 habe ich hier sogar liegen, weil das früher schon mal angefragt wurde, aber dafür nie Software entwickelt. Grund: Es wird einfach zu viel, das alles zu supporten. Und es ist auch so, dass der RC522 auch mit i2c erhältlich ist; @Wolle hat den glaube ich so laufen und kann vielleicht nochmal einen Link dazu posten!? Und dann hat er ggü. RC522 keinen Vorteil mehr, was dann ferner bedeutet, dass man sich die Arbeit sparen kann :slight_smile:. Zum PN532 wurde mir berichtet, dass er zum RC522 etwa äquivalent ist. @compactflash hatte da früher soweit ich weiß mal Tests gemacht.

RC522 via i2c kommt vor allem aus der ESP32-A1S Audiokit-Ecke, weil man dort super wenig Pins hat. Das Standard-RC522-Board hat irgendwie eine Einschränkung, dass man es mit i2c nicht betreiben kann. Aber es gibt auf jeden Fall RC522-Boards, mit denen das geht.

Der RC522 läuft doch bereits mit i2c. Schau mal in die settings.h
image

Und in das jeweilige Board-Setting
image

1 „Gefällt mir“
  1. Ok der PN532 hat dann kein Mehrwert.
  2. Hab mir dies mal genauer mit den Neopixelring angeschaut, da macht ein Display echt nicht mehr viel Sinn.

Ok dies macht Sinn.

Da muss ich mir ernsthaft Gedanken über eine 5V USB Powerbank machen, eigentlich liegt eine rum die ich eh so gut wie nie benötige.

  1. habe mir mal die settings.h für einen TTGO T8 angeschaut ESPuino/settings-ttgo_t8.h at master · biologist79/ESPuino · GitHub
    Kann es sein dass da einige Fehler drinn sind?
    5a) #define ext_IIC_DATA 2 // i2c-SDA (data) [Zeile77] und nochmal für SD MMC 2 D0 [Zeile22)
    5b) #define HP_DETECT 13 [Zeile 94] und #define RFID_IRQ 13 [Zeile 43]
    5c) #define RFID_RST 22 [Zeile 42] und #define IRLED_PIN 22 [Zeile 112]
    Tritt natürlich nur auf wenn man alle Optionen aktiviert hat .
    So könnte dies aussehen

Das kannst du natürlich machen. Im Nachbarforum wird das viel gemacht in Verbindung mit einem Pololu-Switch. Da wird halt ich sage mal traditionell mit 5 V gearbeitet, da das halt die Betriebsspannung vom Arduino nano ist.

Es gibt halt einfach nicht genügend GPIOs, um alles eindeutig und sicher zu vergeben. Ich habe mich entsprechend auf den PCB konzentriert und den Rest, der dafür keine Rolle spielt, halt so gelassen, wie er war. Wenn du dir das anpassen willst, dann kannst du das natürlich machen. Gibt nur so ein paar Dinge, die man beachten sollte: 📗 Die GPIOs des ESP32: Welche eignen sich für was?.

Du meinst die Laufzeit?
Der Chinamann schreibt dazu Schlafen aktuellen 1mA
Hm OK…Ich meine mit einen deep-sleep Beispiel so ca. 350uA gemessen zu haben. Das TTGO T18 Board eignet sich also gut für Batteriebetrieb.
Habe hier auch mal ein besonders sparsames ausprobiert: ePulse - Low Power ESP32 development board • ThingPulse

Hallo Zusammen,

@biologist: habe mir dein Zip File angeschaut, Danke dafür.
Anfangs habe ich mich gewundert wie man mit einen N-FET ohne Booster-Schaltung dies umsetzen kann. Aber nach einem Blick ins Datenblatt war klar ist ein P-FET (Hier sollte man noch das Schaltbild ändern). Aber dennoch noch die Frage warum wurde zum Schalten so ein großer N-FET wie der IRL3103 ausgewählt und nicht was Kleineres wie z.B. irlml6244?

Als ich den PCB damals gemacht habe, hatte ich selbst noch kein SMD gelötet und wollte was haben, was einfach zu löten ist. Klar, dass die Mosfets mit TO-Gehäuse dafür eigentlich totaler Overkill sind, darüber haben wir keine zwei Meinungen.
Bei meinem PCB für den D32 pro habe ich ja auch auf SMD gewechselt. Aber hier muss man schon klar sagen, dass allenfalls 40% der User, die mich anschreiben, dies selbst löten möchten. Also die Eintrittsschwelle liegt damit erheblich höher. Wenn man das nicht kompensiert, was ich z.B. in Form von „ich löte dir die SMD-Teile“ mache, dann findet das einfach weniger Akzeptanz.

Was man sich natürlich generell eigentlich sparen kann, das ist der N-Channel-Mosfet, wenn man die Schaltlogik umkehrt. Ich habe das mehr aus ich sage mal traditionellen Gründen drin gelassen, aber es wird auch demnächst einen Patch geben, dass man die Schaltlogik invertieren kann. Man muss halt immer auch schauen, dass man die Leute nicht zu sehr verwirrt. Man kann ja nicht verlangen, dass sich jeder damit immer dauerhaft befasst - das mache ich bei anderen Projekten ja auch nicht :slight_smile:.

Ok damit hast vollkommen recht.

Also im Prinzip, wenn du die Schaltlogik umkehrst, dann kommst du mit einem einzigen IRLML2244 oder IRLML6401 oder AO3401A aus. Die habe ich alle drei schon getestet. Sicher gehen auch Andere, aber sind jetzt auch keine Unmengen, die man zur Auswahl hat, da die Vgs doch recht niedrig ist.
https://www.mikrocontroller.net/articles/MOSFET-Übersicht

1 „Gefällt mir“