-
Mitglieder surfen ohne Werbebanner. Jetzt kostenlos registrieren!
ePF-2 Pro Akku-Verhalten
- Ersteller fireball_mh
- Erstellt am
Testfahrer
Sehr ambitioniert
- Registriert
- 21 Mai 2021
- Beiträge
- 343
- Punkte Reaktionen
- 286
- eScooter
- ePF-2 PRO
Das sind doch schonmal gute Nachrichten.
Sebastian.Irle
Einsteiger
- Registriert
- 15 Sep 2024
- Beiträge
- 18
- Punkte Reaktionen
- 15
- eScooter
- Trittbrett Fritz 2023
Sehr cool, Respekt!
Robert_Roller
Experte
- Registriert
- 26 Jun 2023
- Beiträge
- 2.819
- Punkte Reaktionen
- 5.035
- Ort
- Bad Schwartau
- eScooter
- ePF Pulse, IOH Nine
Nun schimpfe mal nicht so laut, denn ich versuche schon solche Infos mit anzugeben. Die Tour hatte ich hier im Thread auch verlinkt.
https://www.escooter-treff.de/threads/epf-2-pro-eure-reichweiten.24462/page-3#post-465335
Einzig der Untergrund fehlt da noch. Auf langen Touren wechselt der halt. Es sei den man fährt auf dem Sportplatz Kreise...^^
War aber überwiegend Asphalt.
NovaVecto
Aktiv dabei
- Registriert
- 14 Aug 2025
- Beiträge
- 63
- Punkte Reaktionen
- 205
- eScooter
- ePF-2 PRO 653Wh
Ich hab jetzt mal ein erstes Ergebnis für den Innenwiderstand meines Akkus #1 anhand der Daten vom Fahrzeug. Das Ergebnis zeigt an sich ziemlich exzellente rechnerische Zellwerte - Details und Diagramme dazu siehe weiter unten.
Wie ich das geloggt bekommen habe:
Ich habe ja anfangs herumgestöbert, welche Möglichkeiten es gibt um an mehr live-Daten aus dem Scooter zu kommen und auch überlegt, mir einen BMS-Datenlogger in den Scooter reinzubasteln. Denn es ist ja eine Sache, wenn ich den bei Raumtemperatur am Labortisch messe, aber eine ganz andere wie es "da draußen" ausschaut. Bin dann auf ZydDash gestoßen, das ist eine Tool-Sammlung von einem hiesigen Forenuser, mit dem man sich mit Bluetooth LE die Daten vom ePF-1 aufs Notebook holen kann.
Dabei ist auch ein recht einfaches Script (ePF1_gatt.py), das schon 90% von dem tut, was ich mir gewünscht habe... Ich habs mir für den ePF-2 PRO zurechtgedengelt, und bin so tatsächlich an die Live-Daten gekommen (danke an den Autor von dem ursprungsscript an der Stelle
). Nun hab ich aber keine Lenkerhalterung für mein ThinkPad ;-D, also kam ich auf die blöde Idee, dass ich diese Bluetooth-Logik aus dem Script ja einfach in eine App übertragen könnte... Mit Flutter lässt sich das in dart ja relativ easy machen, kann man sich zur Not ein paar Tutorials entlanghangeln.
Bis auf die üblichen widerlichen Marotten vom flutter-bluetooth Stack hat das auch auf anhieb geklappt und ich konnte damit vom Handy aus die Daten einfach in ein CSV aufzeichnen. \o/ Spaßhalber hab ich dann noch eine rudimentäre Bildschirmmaske als Dashboard zusammengeklatscht und meine einfache Ruhespannungs-Näherung für den Ladezustand mit eingeblendet. Die App ist wüst hingebastelt, aber reicht damit ich mir mal grob das Akkuverhalten unter Realbedingungen aufzeichnen kann
Wichtig:
Die App kann auch im Prinzip nix außer anzeigen und loggen im Moment und hat praktisch keine UI (man kann scannen und verbinden usw., aber standardmäßig verbindet es sich einfach mit dem zuletzt verbundenen Ziel und man kann mit dem button das speichern als csv auslösen, mehr brauch ich im moment ja nicht).
Grob ermittelte Daten aus der aufgezeichneten CSV:
Die Fahrt war quasi einfach mal der erste Versuch ob das überhaupt gescheit funktioniert. Bin in meiner Gasse auf und ab gefahren mit abwechselnden ruppigen Beschleunigen und Abbremsen, um schöne Daten zu generieren ... Hab ein paar Schlaglöcher gezielt angefahren (davon gibts hier genug).
Und hab dann ein paar standardgrößen aus der aufgezeichneten CSV extrahiert und errechnet. Hat noch keinen Anspruch auf Perfektion oder Richtigkeit, ist mal ein erstes Ergebnis (die Recu-Schätzung beruht nur auf beobachteten Daten und berücksichtigt nicht das Verhalten der dynamischen Bremse und anderer Verluste, wie gesagt, sind Erstergebnisse, nicht auf die goldene Waagschale legen):
Die Außentemperatur war 11°C, windig; Der SoC bei 50% laut meiner Ruhespannungs-SoC-Rechnung, 54% laut ePF-App-Anzeige bei stehendem Scooter; sobald ich ihn ganz wenig bewegt habe, sprang meine anzeige und die der ePF-App gleichlautend auf 48%.
Aus dem CSV konnte ich folgendes rechnerisch ermitteln (mittels kurzfristig umgebogenem altem Analysescript, nutzt generische li-ion 18650 Zellen als Referenz, weil ich nicht weiß was tatsächlich für zellen verbaut sind):
Recording Duration: 00:01:34.065589
Estimated Distance: 0.26 km
Moving Time (Speed > 0.5 km/h): 1.1 min
Total Consumption (P > 0): 4.63 Wh
Total Recuperation (P < 0): 0.74 Wh
Net Consumption: 3.89 Wh
Recuperation Ratio: 16.0%
Median Pack Ri: 0.278 Ohm
Estimated Ri per Cell (Profile: 13S4P nominal cell Char#139): 85.6 mOhm
Avg Speed (in motion): 14.0 km/h
Net Efficiency: 15.06 Wh/km
Der Akku hatte vermutlich grob die Temperatur meiner Garage (~15°C), hatte ich vergessen genauer nachzuprüfen.
Dass der rechnerische Einzelzell-Ri bei dem SoC und der Temperatur derart gut ausfällt, hat mich schon ein wenig überrascht. Ich habe es mit der DCIR-Standardmethode bei Betrachtung der Lastwechsel errechnet und auf die Einzelzelle runtergerechnet, der Wert sollte also nicht zu weit weg von der Realität sein.
Unter Berücksichtigung der Rechenmethode, Temperatur und SoC deuten diese ersten Werte grob gesagt auf eine exzellente Zellqualität in diesem meinen Akku #1 hin. Mal sehen ob der zweite Akku sich ähnlich gut verhält, wenn ich ihn dann irgendwann nutze.
Hier noch ein screencap der App und ein paar Diagramme von der Fahrt:
(Die Daten über BLE kommen ca. mit 10 Hz, also öfter als es die Anzeige suggeriert, das erlaubt eine bessere Berechnung der Werte, siehe Diagramme)
Wie ich das geloggt bekommen habe:
Ich habe ja anfangs herumgestöbert, welche Möglichkeiten es gibt um an mehr live-Daten aus dem Scooter zu kommen und auch überlegt, mir einen BMS-Datenlogger in den Scooter reinzubasteln. Denn es ist ja eine Sache, wenn ich den bei Raumtemperatur am Labortisch messe, aber eine ganz andere wie es "da draußen" ausschaut. Bin dann auf ZydDash gestoßen, das ist eine Tool-Sammlung von einem hiesigen Forenuser, mit dem man sich mit Bluetooth LE die Daten vom ePF-1 aufs Notebook holen kann.
Dabei ist auch ein recht einfaches Script (ePF1_gatt.py), das schon 90% von dem tut, was ich mir gewünscht habe... Ich habs mir für den ePF-2 PRO zurechtgedengelt, und bin so tatsächlich an die Live-Daten gekommen (danke an den Autor von dem ursprungsscript an der Stelle
). Nun hab ich aber keine Lenkerhalterung für mein ThinkPad ;-D, also kam ich auf die blöde Idee, dass ich diese Bluetooth-Logik aus dem Script ja einfach in eine App übertragen könnte... Mit Flutter lässt sich das in dart ja relativ easy machen, kann man sich zur Not ein paar Tutorials entlanghangeln.Bis auf die üblichen widerlichen Marotten vom flutter-bluetooth Stack hat das auch auf anhieb geklappt und ich konnte damit vom Handy aus die Daten einfach in ein CSV aufzeichnen. \o/ Spaßhalber hab ich dann noch eine rudimentäre Bildschirmmaske als Dashboard zusammengeklatscht und meine einfache Ruhespannungs-Näherung für den Ladezustand mit eingeblendet. Die App ist wüst hingebastelt, aber reicht damit ich mir mal grob das Akkuverhalten unter Realbedingungen aufzeichnen kann
Wichtig:
- Das ist nur schnell hingerotzt und hingebastelt, weils mich reizt...
- Ich hab vieles von dem was ZydDash da macht noch nicht zu Ende verstanden und daher die Telemetrielogik von ePF1_gatt.py ziemlich 1:1 übernommen... Mit dem Telemetrie-Request zwingt es mir den Scooter in "S" mit 20 km/h limit, aber es läuft immerhin schonmal. Der Trip-km (Tages-km) Wert ist auch schrott, aber egal.
- Der dargestellte OCV SoC ist ein Rechenwert von mir (auf basis der Batteriespannung) nur spaßeshalber zum Vergleich und komplett unkompensiert anhand von üblichen Zellwerten, der OCV SoC kommt also von mir, nicht vom Scooter.
Die App kann auch im Prinzip nix außer anzeigen und loggen im Moment und hat praktisch keine UI (man kann scannen und verbinden usw., aber standardmäßig verbindet es sich einfach mit dem zuletzt verbundenen Ziel und man kann mit dem button das speichern als csv auslösen, mehr brauch ich im moment ja nicht).
Grob ermittelte Daten aus der aufgezeichneten CSV:
Die Fahrt war quasi einfach mal der erste Versuch ob das überhaupt gescheit funktioniert. Bin in meiner Gasse auf und ab gefahren mit abwechselnden ruppigen Beschleunigen und Abbremsen, um schöne Daten zu generieren ... Hab ein paar Schlaglöcher gezielt angefahren (davon gibts hier genug).
Und hab dann ein paar standardgrößen aus der aufgezeichneten CSV extrahiert und errechnet. Hat noch keinen Anspruch auf Perfektion oder Richtigkeit, ist mal ein erstes Ergebnis (die Recu-Schätzung beruht nur auf beobachteten Daten und berücksichtigt nicht das Verhalten der dynamischen Bremse und anderer Verluste, wie gesagt, sind Erstergebnisse, nicht auf die goldene Waagschale legen):
Die Außentemperatur war 11°C, windig; Der SoC bei 50% laut meiner Ruhespannungs-SoC-Rechnung, 54% laut ePF-App-Anzeige bei stehendem Scooter; sobald ich ihn ganz wenig bewegt habe, sprang meine anzeige und die der ePF-App gleichlautend auf 48%.
Aus dem CSV konnte ich folgendes rechnerisch ermitteln (mittels kurzfristig umgebogenem altem Analysescript, nutzt generische li-ion 18650 Zellen als Referenz, weil ich nicht weiß was tatsächlich für zellen verbaut sind):
Recording Duration: 00:01:34.065589
Estimated Distance: 0.26 km
Moving Time (Speed > 0.5 km/h): 1.1 min
Total Consumption (P > 0): 4.63 Wh
Total Recuperation (P < 0): 0.74 Wh
Net Consumption: 3.89 Wh
Recuperation Ratio: 16.0%
Median Pack Ri: 0.278 Ohm
Estimated Ri per Cell (Profile: 13S4P nominal cell Char#139): 85.6 mOhm
Avg Speed (in motion): 14.0 km/h
Net Efficiency: 15.06 Wh/km
Der Akku hatte vermutlich grob die Temperatur meiner Garage (~15°C), hatte ich vergessen genauer nachzuprüfen.
Dass der rechnerische Einzelzell-Ri bei dem SoC und der Temperatur derart gut ausfällt, hat mich schon ein wenig überrascht. Ich habe es mit der DCIR-Standardmethode bei Betrachtung der Lastwechsel errechnet und auf die Einzelzelle runtergerechnet, der Wert sollte also nicht zu weit weg von der Realität sein.
Unter Berücksichtigung der Rechenmethode, Temperatur und SoC deuten diese ersten Werte grob gesagt auf eine exzellente Zellqualität in diesem meinen Akku #1 hin. Mal sehen ob der zweite Akku sich ähnlich gut verhält, wenn ich ihn dann irgendwann nutze.
Hier noch ein screencap der App und ein paar Diagramme von der Fahrt:
(Die Daten über BLE kommen ca. mit 10 Hz, also öfter als es die Anzeige suggeriert, das erlaubt eine bessere Berechnung der Werte, siehe Diagramme)
Sebastian.Irle
Einsteiger
- Registriert
- 15 Sep 2024
- Beiträge
- 18
- Punkte Reaktionen
- 15
- eScooter
- Trittbrett Fritz 2023
Krasser Beitrag, vielen Dank!!Ich hab jetzt mal ein erstes Ergebnis für den Innenwiderstand meines Akkus #1 anhand der Daten vom Fahrzeug. Das Ergebnis zeigt an sich ziemlich exzellente rechnerische Zellwerte - Details und Diagramme dazu siehe weiter unten.
Wie ich das geloggt bekommen habe:
Ich habe ja anfangs herumgestöbert, welche Möglichkeiten es gibt um an mehr live-Daten aus dem Scooter zu kommen und auch überlegt, mir einen BMS-Datenlogger in den Scooter reinzubasteln. Denn es ist ja eine Sache, wenn ich den bei Raumtemperatur am Labortisch messe, aber eine ganz andere wie es "da draußen" ausschaut. Bin dann auf ZydDash gestoßen, das ist eine Tool-Sammlung von einem hiesigen Forenuser, mit dem man sich mit Bluetooth LE die Daten vom ePF-1 aufs Notebook holen kann.
Dabei ist auch ein recht einfaches Script (ePF1_gatt.py), das schon 90% von dem tut, was ich mir gewünscht habe... Ich habs mir für den ePF-2 PRO zurechtgedengelt, und bin so tatsächlich an die Live-Daten gekommen (danke an den Autor von dem ursprungsscript an der Stelle
Bis auf die üblichen widerlichen Marotten vom flutter-bluetooth Stack hat das auch auf anhieb geklappt und ich konnte damit vom Handy aus die Daten einfach in ein CSV aufzeichnen. \o/ Spaßhalber hab ich dann noch eine rudimentäre Bildschirmmaske als Dashboard zusammengeklatscht und meine einfache Ruhespannungs-Näherung für den Ladezustand mit eingeblendet. Die App ist wüst hingebastelt, aber reicht damit ich mir mal grob das Akkuverhalten unter Realbedingungen aufzeichnen kann
Wichtig:
- Das ist nur schnell hingerotzt und hingebastelt, weils mich reizt...
- Ich hab vieles von dem was ZydDash da macht noch nicht zu Ende verstanden und daher die Telemetrielogik von ePF1_gatt.py ziemlich 1:1 übernommen... Mit dem Telemetrie-Request zwingt es mir den Scooter in "S" mit 20 km/h limit, aber es läuft immerhin schonmal. Der Trip-km (Tages-km) Wert ist auch schrott, aber egal.
- Der dargestellte OCV SoC ist ein Rechenwert von mir (auf basis der Batteriespannung) nur spaßeshalber zum Vergleich und komplett unkompensiert anhand von üblichen Zellwerten, der OCV SoC kommt also von mir, nicht vom Scooter.
Die App kann auch im Prinzip nix außer anzeigen und loggen im Moment und hat praktisch keine UI (man kann scannen und verbinden usw., aber standardmäßig verbindet es sich einfach mit dem zuletzt verbundenen Ziel und man kann mit dem button das speichern als csv auslösen, mehr brauch ich im moment ja nicht).
Grob ermittelte Daten aus der aufgezeichneten CSV:
Die Fahrt war quasi einfach mal der erste Versuch ob das überhaupt gescheit funktioniert. Bin in meiner Gasse auf und ab gefahren mit abwechselnden ruppigen Beschleunigen und Abbremsen, um schöne Daten zu generieren ... Hab ein paar Schlaglöcher gezielt angefahren (davon gibts hier genug).
Und hab dann ein paar standardgrößen aus der aufgezeichneten CSV extrahiert und errechnet. Hat noch keinen Anspruch auf Perfektion oder Richtigkeit, ist mal ein erstes Ergebnis (die Recu-Schätzung beruht nur auf beobachteten Daten und berücksichtigt nicht das Verhalten der dynamischen Bremse und anderer Verluste, wie gesagt, sind Erstergebnisse, nicht auf die goldene Waagschale legen):
Die Außentemperatur war 11°C, windig; Der SoC bei 50% laut meiner Ruhespannungs-SoC-Rechnung, 54% laut ePF-App-Anzeige bei stehendem Scooter; sobald ich ihn ganz wenig bewegt habe, sprang meine anzeige und die der ePF-App gleichlautend auf 48%.
Aus dem CSV konnte ich folgendes rechnerisch ermitteln (mittels kurzfristig umgebogenem altem Analysescript, nutzt generische li-ion 18650 Zellen als Referenz, weil ich nicht weiß was tatsächlich für zellen verbaut sind):
Recording Duration: 00:01:34.065589
Estimated Distance: 0.26 km
Moving Time (Speed > 0.5 km/h): 1.1 min
Total Consumption (P > 0): 4.63 Wh
Total Recuperation (P < 0): 0.74 Wh
Net Consumption: 3.89 Wh
Recuperation Ratio: 16.0%
Median Pack Ri: 0.278 Ohm
Estimated Ri per Cell (Profile: 13S4P nominal cell Char#139): 85.6 mOhm
Avg Speed (in motion): 14.0 km/h
Net Efficiency: 15.06 Wh/km
Der Akku hatte vermutlich grob die Temperatur meiner Garage (~15°C), hatte ich vergessen genauer nachzuprüfen.
Dass der rechnerische Einzelzell-Ri bei dem SoC und der Temperatur derart gut ausfällt, hat mich schon ein wenig überrascht. Ich habe es mit der DCIR-Standardmethode bei Betrachtung der Lastwechsel errechnet und auf die Einzelzelle runtergerechnet, der Wert sollte also nicht zu weit weg von der Realität sein.
Unter Berücksichtigung der Rechenmethode, Temperatur und SoC deuten diese ersten Werte grob gesagt auf eine exzellente Zellqualität in diesem meinen Akku #1 hin. Mal sehen ob der zweite Akku sich ähnlich gut verhält, wenn ich ihn dann irgendwann nutze.
Hier noch ein screencap der App und ein paar Diagramme von der Fahrt:
Anhang anzeigen 223212
(Die Daten über BLE kommen ca. mit 10 Hz, also öfter als es die Anzeige suggeriert, das erlaubt eine bessere Berechnung der Werte, siehe Diagramme)
Anhang anzeigen 223213 Anhang anzeigen 223214
Anhang anzeigen 223215
ich habe wenig verstanden. Aber das Fazit ist ja sehr gut und ich hoffe, dass die Akkuqualität bei allen usern durchgängig so gut ist.Ich hab jetzt mal ein erstes Ergebnis für den Innenwiderstand meines Akkus #1 anhand der Daten vom Fahrzeug. Das Ergebnis zeigt an sich ziemlich exzellente rechnerische Zellwerte - Details und Diagramme dazu siehe weiter unten.
Wie ich das geloggt bekommen habe:
Ich habe ja anfangs herumgestöbert, welche Möglichkeiten es gibt um an mehr live-Daten aus dem Scooter zu kommen und auch überlegt, mir einen BMS-Datenlogger in den Scooter reinzubasteln. Denn es ist ja eine Sache, wenn ich den bei Raumtemperatur am Labortisch messe, aber eine ganz andere wie es "da draußen" ausschaut. Bin dann auf ZydDash gestoßen, das ist eine Tool-Sammlung von einem hiesigen Forenuser, mit dem man sich mit Bluetooth LE die Daten vom ePF-1 aufs Notebook holen kann.
Dabei ist auch ein recht einfaches Script (ePF1_gatt.py), das schon 90% von dem tut, was ich mir gewünscht habe... Ich habs mir für den ePF-2 PRO zurechtgedengelt, und bin so tatsächlich an die Live-Daten gekommen (danke an den Autor von dem ursprungsscript an der Stelle
Bis auf die üblichen widerlichen Marotten vom flutter-bluetooth Stack hat das auch auf anhieb geklappt und ich konnte damit vom Handy aus die Daten einfach in ein CSV aufzeichnen. \o/ Spaßhalber hab ich dann noch eine rudimentäre Bildschirmmaske als Dashboard zusammengeklatscht und meine einfache Ruhespannungs-Näherung für den Ladezustand mit eingeblendet. Die App ist wüst hingebastelt, aber reicht damit ich mir mal grob das Akkuverhalten unter Realbedingungen aufzeichnen kann
Wichtig:
- Das ist nur schnell hingerotzt und hingebastelt, weils mich reizt...
- Ich hab vieles von dem was ZydDash da macht noch nicht zu Ende verstanden und daher die Telemetrielogik von ePF1_gatt.py ziemlich 1:1 übernommen... Mit dem Telemetrie-Request zwingt es mir den Scooter in "S" mit 20 km/h limit, aber es läuft immerhin schonmal. Der Trip-km (Tages-km) Wert ist auch schrott, aber egal.
- Der dargestellte OCV SoC ist ein Rechenwert von mir (auf basis der Batteriespannung) nur spaßeshalber zum Vergleich und komplett unkompensiert anhand von üblichen Zellwerten, der OCV SoC kommt also von mir, nicht vom Scooter.
Die App kann auch im Prinzip nix außer anzeigen und loggen im Moment und hat praktisch keine UI (man kann scannen und verbinden usw., aber standardmäßig verbindet es sich einfach mit dem zuletzt verbundenen Ziel und man kann mit dem button das speichern als csv auslösen, mehr brauch ich im moment ja nicht).
Grob ermittelte Daten aus der aufgezeichneten CSV:
Die Fahrt war quasi einfach mal der erste Versuch ob das überhaupt gescheit funktioniert. Bin in meiner Gasse auf und ab gefahren mit abwechselnden ruppigen Beschleunigen und Abbremsen, um schöne Daten zu generieren ... Hab ein paar Schlaglöcher gezielt angefahren (davon gibts hier genug).
Und hab dann ein paar standardgrößen aus der aufgezeichneten CSV extrahiert und errechnet. Hat noch keinen Anspruch auf Perfektion oder Richtigkeit, ist mal ein erstes Ergebnis (die Recu-Schätzung beruht nur auf beobachteten Daten und berücksichtigt nicht das Verhalten der dynamischen Bremse und anderer Verluste, wie gesagt, sind Erstergebnisse, nicht auf die goldene Waagschale legen):
Die Außentemperatur war 11°C, windig; Der SoC bei 50% laut meiner Ruhespannungs-SoC-Rechnung, 54% laut ePF-App-Anzeige bei stehendem Scooter; sobald ich ihn ganz wenig bewegt habe, sprang meine anzeige und die der ePF-App gleichlautend auf 48%.
Aus dem CSV konnte ich folgendes rechnerisch ermitteln (mittels kurzfristig umgebogenem altem Analysescript, nutzt generische li-ion 18650 Zellen als Referenz, weil ich nicht weiß was tatsächlich für zellen verbaut sind):
Recording Duration: 00:01:34.065589
Estimated Distance: 0.26 km
Moving Time (Speed > 0.5 km/h): 1.1 min
Total Consumption (P > 0): 4.63 Wh
Total Recuperation (P < 0): 0.74 Wh
Net Consumption: 3.89 Wh
Recuperation Ratio: 16.0%
Median Pack Ri: 0.278 Ohm
Estimated Ri per Cell (Profile: 13S4P nominal cell Char#139): 85.6 mOhm
Avg Speed (in motion): 14.0 km/h
Net Efficiency: 15.06 Wh/km
Der Akku hatte vermutlich grob die Temperatur meiner Garage (~15°C), hatte ich vergessen genauer nachzuprüfen.
Dass der rechnerische Einzelzell-Ri bei dem SoC und der Temperatur derart gut ausfällt, hat mich schon ein wenig überrascht. Ich habe es mit der DCIR-Standardmethode bei Betrachtung der Lastwechsel errechnet und auf die Einzelzelle runtergerechnet, der Wert sollte also nicht zu weit weg von der Realität sein.
Unter Berücksichtigung der Rechenmethode, Temperatur und SoC deuten diese ersten Werte grob gesagt auf eine exzellente Zellqualität in diesem meinen Akku #1 hin. Mal sehen ob der zweite Akku sich ähnlich gut verhält, wenn ich ihn dann irgendwann nutze.
Hier noch ein screencap der App und ein paar Diagramme von der Fahrt:
Anhang anzeigen 223212
(Die Daten über BLE kommen ca. mit 10 Hz, also öfter als es die Anzeige suggeriert, das erlaubt eine bessere Berechnung der Werte, siehe Diagramme)
Anhang anzeigen 223213 Anhang anzeigen 223214
Anhang anzeigen 223215
NovaVecto
Aktiv dabei
- Registriert
- 14 Aug 2025
- Beiträge
- 63
- Punkte Reaktionen
- 205
- eScooter
- ePF-2 PRO 653Wh
Wenn ich die App ein wenig aufgeräumt und vom experimentiercode befreit hab, kann ich die theoretisch auch weitergeben (installieren kann man sie mit dem apk)... Wenn jemand also seinen Akku verdächtigt, kann man mir da so eine Referenzfahrt (geeigneter Ladezustand, einigermaßen definierte und bekannte Umgebungstemperatur, regelmäßige starke Lastwechsel, angemessen kurze Fahrt) aufzeichnen und das CSV geben, dann jag ich das durch die Tools und kann schauen was rauskommt.
Aber erstmal will ich die App genauer beobachten, denn es hat mir den Scooter auf basis von dem ursprungsscript ja unerwartet in S und 20km/h umgeschaltet (reversibel, aber halt unerwartet)... Da will ich erstmal das Protokoll genauer verstehen und warum das so ist und es ggf. robust machen.
NovaVecto
Aktiv dabei
- Registriert
- 14 Aug 2025
- Beiträge
- 63
- Punkte Reaktionen
- 205
- eScooter
- ePF-2 PRO 653Wh
Hab mir jetzt die Steckverbinder besorgt:
Und daraus direkt erstmal einen Adapter gebaut:
Ist erst einmal primär für die Kapazitätsbestimmung (diesmal in Entladerichtung, in Laderichtung hatte ich sie ja schon gemacht), die kann ich jetzt demnächst in Angriff nehmen (Rot: Lastausgang, Gelb: Ladeeingang, Gelb+Schwarz: BMS-Bus, Schwarz: 0V/GND/-).
Aber jetzt wo ich die Steckverbinder habe, reizt es mich natürlich, mir perspektivisch auch eine parametrierbare Ladestation für den Akku zu bauen, mit dem BMS sollte das ja klaglos möglich sein.
Und daraus direkt erstmal einen Adapter gebaut:
Ist erst einmal primär für die Kapazitätsbestimmung (diesmal in Entladerichtung, in Laderichtung hatte ich sie ja schon gemacht), die kann ich jetzt demnächst in Angriff nehmen (Rot: Lastausgang, Gelb: Ladeeingang, Gelb+Schwarz: BMS-Bus, Schwarz: 0V/GND/-).
Aber jetzt wo ich die Steckverbinder habe, reizt es mich natürlich, mir perspektivisch auch eine parametrierbare Ladestation für den Akku zu bauen, mit dem BMS sollte das ja klaglos möglich sein.
Sebastian.Irle
Einsteiger
- Registriert
- 15 Sep 2024
- Beiträge
- 18
- Punkte Reaktionen
- 15
- eScooter
- Trittbrett Fritz 2023
Das ist ja sehr praktisch! Stimmt die gemessene Spannung mit der in der App angezeigten Spannung überein?Hab mir jetzt die Steckverbinder besorgt:
Anhang anzeigen 223404
Und daraus direkt erstmal einen Adapter gebaut:
Anhang anzeigen 223405 Anhang anzeigen 223406
Ist erst einmal primär für die Kapazitätsbestimmung (diesmal in Entladerichtung, in Laderichtung hatte ich sie ja schon gemacht), die kann ich jetzt demnächst in Angriff nehmen (Rot: Lastausgang, Gelb: Ladeeingang, Gelb+Schwarz: BMS-Bus, Schwarz: 0V/GND/-).
Aber jetzt wo ich die Steckverbinder habe, reizt es mich natürlich, mir perspektivisch auch eine parametrierbare Ladestation für den Akku zu bauen, mit dem BMS sollte das ja klaglos möglich sein.
NovaVecto
Aktiv dabei
- Registriert
- 14 Aug 2025
- Beiträge
- 63
- Punkte Reaktionen
- 205
- eScooter
- ePF-2 PRO 653Wh
Ja, die BMS-Daten für Spannung und Strom, wie auch die Summe der Zellspannungen, stimmen sehr gut mit meinen externen Messungen überein. Zwischen BMS und Multimeter (kalibriertes BM789) hat es ~0,015V Unterschied.
Bei den Daten vom Scooter selbst (App) hab ich bisher ähnliches beobachtet, schaut bei Spannung und Strom insgesamt alles ordentlich und korrekt justiert aus.
Sebastian.Irle
Einsteiger
- Registriert
- 15 Sep 2024
- Beiträge
- 18
- Punkte Reaktionen
- 15
- eScooter
- Trittbrett Fritz 2023
Danke!
Suppi
Einsteiger
- Registriert
- 8 Nov 2025
- Beiträge
- 5
- Punkte Reaktionen
- 1
- eScooter
- EPF-2 pro Wechselakku
Ich lese schon seit Wochen hier mit und habe die Leidensgeschichte des Wechselakkus mitgemacht. Erst aufgrund meiner Initaitive hat sich epowerfun dazu bereit erklärt, die Käufer über die weitere Vorgehensweise zu informieren, was im „Wartezimmer“ berichtet wurde. Es war nicht epowerfun, die proaktiv informiert haben, sondern weil ich dort mit Nachdruck gefordert habe, das die Käufer informiert werden. Warum erwähne ich das hier.
Nachdem der ursprüngliche Liefertermin um 1 Monat verschoben wurde, kamen die Scooter mit Problemen in Deutschland an. Wir alle wurden dann informiert über die Probleme mit dem Wechselakkuverschluss. Was ich erwartet habe: nachdem das Problem lokalisiert wurde und es sich vermutlich um ein kleineres Ersatzteil gehandelt hat, dachte ich, dass diese mit Flugzeug per Express nach Deutschland geliefert wurden, dann unmittelbar eingebaut und dann verschickt werden. Das passierte aber nicht. Stattdessen wurde das wieder per Schiff versandt, wodurch die Käufer nochmal ewig warten mussten und die Sommerzeit dann auch bald zu Ende war. Proaktiv wurde nichts von epowerfun an die Käufer weitergegeben, ich musste mit Nachdruck einfordern, dass uns mitgeteilt wird, wie denn der Plan überhaupt aussieht und ich hätte erwartet, dass wir engmaschig über den Projektplan informiert werden, damit abzusehen ist, ob der anvisierte Termin Mitte Oktober auch eingehalten wird. Wir wir mittlerweile wissen, war dem so, dass hätte aber auch anders ablaufen können.
Also bis hierher:
- massive zeitliche Verzögerung
- keine proaktiv Information an die Käufer, die alle in Vorleistung gegangen sind, auch wenn seitens epowerfun angeboten wurde, den Kaufpreis zurück zu zahlen
Und jetzt: wieder ein massives Problem, dieses mal mit dem Akku. Ich habe den großen Wechselakku, wiege 80 kg, fahre 95% ebene Strecken und komme grob geschätzt gerade mal auf 40 km.
Zudem zeigt mir die Restanzeige bei Fahrt und Stand unterschiedliche Balken an.
Was passiert bei epowerfun? Ich weiß es nicht. Hätte ich hier nicht mitgelesen und mich proaktiv dort informiert, wüsste ich bis heute nichts davon, dass dort intern Tests und Forschung zum bekannten Problem durchgeführt werden. Mittlerweile sind wieder 2 Wochen ins Land gegangen und nichts passiert. Weder eine Lösung noch eine offizielle Information, noch ein, zumindest grober Zeitplan, wie es nun weitergeht.
Ich habe mir extra einen Scooter von epowerfun gekauft aufgrund der positiven Supportbewertungen. Und gäbe es eine Alternative in Bezug auf Preis/Leistung wäre ich schon längst abgesprungen.
Aber diese Zustände sind eigentlich nicht tragbar. Ich fühle mich seit Monaten als Beta Tester für diese Scooter. Ich schreibe hier in der Hoffnung, dass dies andere auch so sehen und epowerfun hier mitliest und jetzt endlich mal in die Gänge kommt, damit wir alle einen Scooter erhalten, der so verkauft und dessen Eigenschaften so zugesichert wurden.
Schönen Abend.
Nachdem der ursprüngliche Liefertermin um 1 Monat verschoben wurde, kamen die Scooter mit Problemen in Deutschland an. Wir alle wurden dann informiert über die Probleme mit dem Wechselakkuverschluss. Was ich erwartet habe: nachdem das Problem lokalisiert wurde und es sich vermutlich um ein kleineres Ersatzteil gehandelt hat, dachte ich, dass diese mit Flugzeug per Express nach Deutschland geliefert wurden, dann unmittelbar eingebaut und dann verschickt werden. Das passierte aber nicht. Stattdessen wurde das wieder per Schiff versandt, wodurch die Käufer nochmal ewig warten mussten und die Sommerzeit dann auch bald zu Ende war. Proaktiv wurde nichts von epowerfun an die Käufer weitergegeben, ich musste mit Nachdruck einfordern, dass uns mitgeteilt wird, wie denn der Plan überhaupt aussieht und ich hätte erwartet, dass wir engmaschig über den Projektplan informiert werden, damit abzusehen ist, ob der anvisierte Termin Mitte Oktober auch eingehalten wird. Wir wir mittlerweile wissen, war dem so, dass hätte aber auch anders ablaufen können.
Also bis hierher:
- massive zeitliche Verzögerung
- keine proaktiv Information an die Käufer, die alle in Vorleistung gegangen sind, auch wenn seitens epowerfun angeboten wurde, den Kaufpreis zurück zu zahlen
Und jetzt: wieder ein massives Problem, dieses mal mit dem Akku. Ich habe den großen Wechselakku, wiege 80 kg, fahre 95% ebene Strecken und komme grob geschätzt gerade mal auf 40 km.
Zudem zeigt mir die Restanzeige bei Fahrt und Stand unterschiedliche Balken an.
Was passiert bei epowerfun? Ich weiß es nicht. Hätte ich hier nicht mitgelesen und mich proaktiv dort informiert, wüsste ich bis heute nichts davon, dass dort intern Tests und Forschung zum bekannten Problem durchgeführt werden. Mittlerweile sind wieder 2 Wochen ins Land gegangen und nichts passiert. Weder eine Lösung noch eine offizielle Information, noch ein, zumindest grober Zeitplan, wie es nun weitergeht.
Ich habe mir extra einen Scooter von epowerfun gekauft aufgrund der positiven Supportbewertungen. Und gäbe es eine Alternative in Bezug auf Preis/Leistung wäre ich schon längst abgesprungen.
Aber diese Zustände sind eigentlich nicht tragbar. Ich fühle mich seit Monaten als Beta Tester für diese Scooter. Ich schreibe hier in der Hoffnung, dass dies andere auch so sehen und epowerfun hier mitliest und jetzt endlich mal in die Gänge kommt, damit wir alle einen Scooter erhalten, der so verkauft und dessen Eigenschaften so zugesichert wurden.
Schönen Abend.
Testfahrer
Sehr ambitioniert
- Registriert
- 21 Mai 2021
- Beiträge
- 343
- Punkte Reaktionen
- 286
- eScooter
- ePF-2 PRO
Das ist kein "massives Problem", sondern erwartbar bei einem 653Wh Akku und den aktuellen Temperaturen.
Ich komme auf ähnliche Reichweiten bei 10-12 Grad und habe kein Problem damit.
Die Akkuanzeige ist tatsächlich ungenau und sprunghaft, es ist aber auch nicht so, dass man sich nicht für einige Wochen damit arrangieren könnte.
Ich bin unterm Strich äusserst zufrieden mit dem ePF-2 Pro 653W
Zuletzt bearbeitet:
Suppi
Einsteiger
- Registriert
- 8 Nov 2025
- Beiträge
- 5
- Punkte Reaktionen
- 1
- eScooter
- EPF-2 pro Wechselakku
Das ist schön und deine Meinung, die respektiere ich.
Mit massiven Problem bezog ich das auf die Probleme davor und ungeachtet dessen, dass die Käufer eigentlich noch gar nichts davon wissen.
Für mich ist es schon ein Problem, denn ich hab mir diese Akku Version extra gekauft um wesentlich weiter als 40 km zu kommen. Das der keine 80 bringt, ist mir klar, aber 50% ist definitiv zu wenig. Und dass es ein bekanntes Problem ist, wurde ja zumindest hier im Forum schon bestätigt.
Mit massiven Problem bezog ich das auf die Probleme davor und ungeachtet dessen, dass die Käufer eigentlich noch gar nichts davon wissen.
Für mich ist es schon ein Problem, denn ich hab mir diese Akku Version extra gekauft um wesentlich weiter als 40 km zu kommen. Das der keine 80 bringt, ist mir klar, aber 50% ist definitiv zu wenig. Und dass es ein bekanntes Problem ist, wurde ja zumindest hier im Forum schon bestätigt.
