Kai Geschrieben 3. Mai 2020 Geschrieben 3. Mai 2020 Ich habe bei meinem kleinen Schlampa einen sau doofen Effekt. Wenn ich stark und schell beschleunige und schnell wieder vom Gas runter gehe dann beschleunigt das Board noch 1-2 Sekunden nach. Je stärker und länger die Beschleunigung ist desto stärker ist der Effekt. In der metr.app wurde kein Fehler protokoliert. Die Konfiguration ist vom Vesc-Tool Assistenten, hab an keinen Werten rumgespielt. Ist das Phänomen bekannt? Was könnte als Ursache in Frage kommen? Zitieren
oldtrapper Geschrieben 3. Mai 2020 Geschrieben 3. Mai 2020 (bearbeitet) vor 2 Stunden schrieb Kai: Ich habe bei meinem kleinen Schlampa einen sau doofen Effekt. Wenn ich stark und schell beschleunige und schnell wieder vom Gas runter gehe dann beschleunigt das Board noch 1-2 Sekunden nach. Je stärker und länger die Beschleunigung ist desto stärker ist der Effekt. In der metr.app wurde kein Fehler protokoliert. Die Konfiguration ist vom VESC®-Tool Assistenten, hab an keinen Werten rumgespielt. Ist das Phänomen bekannt? Was könnte als Ursache in Frage kommen? Wenn nichts an der Konfiguration verändert wurde, tippe ich auf Interferenzen im 2,4 Ghz Bereich, sollte die Funke diese Frequenzen nutzen. Die Interferenzen entstehen meist im Zusammenhang mit Smartwatches oder - in besiedelten Gebieten - durch stark frequentiertes WLAN in der Umgebung. Wenn Dein Handy noch dazu die erweiterte Positionsbestimmung (GPS und WLAN) nutzt, werden die Signale des 2,4 Ghz-WLAN analysiert, auch wenn das Handy nicht eingebucht ist. Das alles stört die Signalübertragung zwischen Funke und Board und hat Latenzen zur Folge. Zum Testen mal das Handy in den Flugmodus und ggf die Smartwatch und die Wireless Kopfhörer ausmachen. Alternativ den Antennendraht am ESC prüfen und, falls nicht ohnehin so vorgesehen, aus dem Gehäuse herausführen. Bei FOC ist ein Verlegen entlang der Motorkabel unkritisch. bei reiner PCM-Ansteuerung der Motoren darf die Antenne nicht parallel zu einem Motorkabel liegen. Hier kann man zum Testen mal ausprobieren, auf welche Entfernung Du mit Funke das Board noch beschleunigen und bremsen kannst. 20 m zwischen Dir mit Funke und dem Board sollten schon drin sein. Ist es weniger, könnte die Antenne nicht ok sein. Zum Schluss ganz primitiv: Vlt mal ne andere Funke anlernen und schauen, ob es an der Funke selbst liegt. Mehr fällt mir grad nicht ein bearbeitet 3. Mai 2020 von oldtrapper Zitieren
Kai Geschrieben 3. Mai 2020 Autor Geschrieben 3. Mai 2020 Das es EMF Störungen sein könnten habe ich auch in Erwägung gezogen. Dien Funke geht aber 20m ohne Probleme und bei nicht aggressiven Fahren trat der Effekt noch nicht auf. WerdenFunkabrisse protokolliert? Zitieren
Kai Geschrieben 3. Mai 2020 Autor Geschrieben 3. Mai 2020 Ergänzend noch, ganz ausschließen möchte ich als Ursache der Störungen der Fernbedienung durch BackEMF der Motorphasen nicht. Die Regler sind für FOC konfiguriert. meine Hyothesen: - wenn BackEmf der Motor Phasen die Kommunikation zwischen FB und Empfänger zuverlässig bis zur Unzuverlässigkeit stören können , warum sind die Phasen dann nicht standardmäßig abgeschirmt? Zitieren
visnu777 Geschrieben 4. Mai 2020 Geschrieben 4. Mai 2020 (bearbeitet) vor 8 Stunden schrieb Kai: WerdenFunkabrisse protokolliert? Ppm wird geloggt, musst das nur in der Auswertung anstellen (kleines Dreieck im Kreis) bearbeitet 4. Mai 2020 von visnu777 Zitieren
oldtrapper Geschrieben 4. Mai 2020 Geschrieben 4. Mai 2020 (bearbeitet) vor 12 Stunden schrieb Kai: Ergänzend noch, ganz ausschließen möchte ich als Ursache der Störungen der Fernbedienung durch BackEMF der Motorphasen nicht. Die Regler sind für FOC konfiguriert. meine Hyothesen: - wenn BackEmf der Motor Phasen die Kommunikation zwischen FB und Empfänger zuverlässig bis zur Unzuverlässigkeit stören können , warum sind die Phasen dann nicht standardmäßig abgeschirmt? Dass die Interferenzen und damit die Latenzen bei höheren Strömen ebenfalls zunehmen stützt diese These. Wenn Motor und "übermäßg" BackEMF die Ursachen sind, könnte man das vlt auch an der Temperatur feststellen. Test: Haben beide Motoren nach einiger Fahrt die gleichen Temperaturen? Wenn man den Unterschied mit der Hand schon feststellen kann, würde ich das für signifikant halten, bei ein paar Grad Unterschied mit dem IR-Thermometer wäre das noch kein beweiskräftiges Indiz, denke ich. Am Fahrverhalten kann man vermutlich nicht feststellen, ob nur ein Motor betroffen ist, oder? Abschirmung kostet Geld 🙂 , und es entstehen kapazitive Scheinwiderstände, die mitunter auch nicht unproblematisch sind. Ich habe auch schon Konstruktionen mit nur einer gemeinsamen Masseleitung gebaut. Alles nicht so wild, solange es sich nicht um Hochfrequenz UND zweistellige Amperewerte handelt. Noch ein Gedanke: Bei aggressivem Fahren können hohe Temperaturen den oder die Hall-Sensoren bis zur Funktionslosigkeit stören. Wenn da irwo Bleilot verwendet wurde, kann auch schnell ne Kaltlötstelle entstehen, sobald die Temperatur einen gewissen Wert übersteigt, und dann wird der Motor vorübergehend nicht geregelt, sobald die Schwelle wieder unterschritten ist, ist alles gut. Wie sich das beim Fahren auswirkt, kann ich mangels eigener Erfahrung nicht einschätzen. bearbeitet 4. Mai 2020 von oldtrapper Zitieren
Kai Geschrieben 4. Mai 2020 Autor Geschrieben 4. Mai 2020 Ich werde wenn ich wieder im Geschäft sein kann mal testen was passiert wenn ich beim Gasgeben den Akku der Fernbedienung abziehe. Und dann nochmal schauen welche FW-Version ich fahre und ob mir das Externe Links nur für Mitglieder sichtbar was sagen will. Ich glaube ich hab noch 3.irgendwas Zitieren
oldtrapper Geschrieben 4. Mai 2020 Geschrieben 4. Mai 2020 Nur leicht OT: Was Phasenlage, Frequenzen, Spulen und Strom im richtigen Verhältnis so anstellen können :-) Externe Links nur für Mitglieder sichtbar Zitieren
visnu777 Geschrieben 4. Mai 2020 Geschrieben 4. Mai 2020 3.63 hatte einen Bug wo die Priorität UART vs PPM fehlerhaft war, evtl. ist es also tatsächlich mit einem FW Update getan. Ansonsten: Hast du nicht ein Carbondeck? Das kann auch die Funkleistung beeinträchtigen. Zitieren
oldtrapper Geschrieben 16. Mai 2020 Geschrieben 16. Mai 2020 Wir hatten unlängst in einer Telegramgruppe ein ähnliches Thema ... dort war das Ergebnis ein altes Poti, das ausgetauscht werden muss Zitieren
Kai Geschrieben 7. Juni 2020 Autor Geschrieben 7. Juni 2020 FW war 3.58 und ist mittlerweile auf 5.1 aktualisiert. Reproduzierbar ist der Effekt in dem man, während man beschleunigt, - die Fernbedienung abschaltet (oder Funkabriss) - die Verbindung vom Empfänger zum VESC trennt, also das Kabel vom Empfänger abzieht. Dann beschleunigt der VESC 3-4 Sekunden immer weiter bis er dann in den Leerlauf geht. Sollte also Firmwaresache sein. Die Einstellungen im vesc_tool für App sind default. Außer Timeout (1000ms) konnte ich keinen Zusammenhang in den Einstellungen erkennen. Zitieren
Kai Geschrieben 7. Juni 2020 Autor Geschrieben 7. Juni 2020 Am 4.5.2020 um 16:02 schrieb visnu777: Ansonsten: Hast du nicht ein Carbondeck? Das kann auch die Funkleistung beeinträchtigen. Das Deck ist ein HolyPro von Trampa. also kein Carbon sonder sowas wie Kohlefaser Fiberglas Verbund Plastik. Protokollieren der Signalstärke ... gute Idee... ist das in der VESC FW integriert? PPM Log ist leider nur der Dezimalwert von 1.00 und 2.00 oder? Also die "Stellung" des Gashebels. 1.50 für Mittelstellung. Zitieren
oldtrapper Geschrieben 7. Juni 2020 Geschrieben 7. Juni 2020 Ich kenn mich mit aktuellen VESC leider nicht gut aus ... gibt's da ne Einstellung "failsafe" oder ähnliches ... dann könnte da auch ein Timerwert drin stehen. Ansonsten kann das Funkabrissproblem auch in der Fernbedienung zu finden sein ... Kaltlötstelle oder Leiterbruch nach Runterfallen. Zitieren
Kai Geschrieben 7. Juni 2020 Autor Geschrieben 7. Juni 2020 Ich konnte keinen Zusammenhang in den Einstellungen erkennen, auch keine die direkt auf ein Failsafe Verhalten Rückschlüsse ziehen lässt, außer Timeout und Timeout Brake Current. Ramping Time und Median Filter könnten auf das Verhalten Einfluss drauf haben. Offensichtlich IMHO nicht direkt, dokumentiert auch nicht. Das Thema spaltet sich in zwei Themen 1. Funkabriss Ursachen 2 Failsafe-Algorithmus der VESC-FW Die Ursachen von Funkabrissen zu kennen und so bestmöglich zu vermeiden ist wichtig. Sollte es trotzdem dazu kommen ist ein optimaler Failsafe-Algorithmus um so wichtiger. Woher der Funkabriss in meinem konkreten Fall kam können wir zur Zeit nur spekulieren. Ob das Signal der FB beim Empfänger zu schwach ankommt und somit leicht gestört werden kann, ob es ein Wackelkontakt ist usw. Ohne Auswertung der Signalstärke sind alle Optimierungen ins Blaue gefeuert. Schaden werden die Optimierungen nicht nur selbst wenn der Fehler damit erstmal nicht wieder auftritt, bleibt die unvorhersehbare Überraschung wenn der Fehler plötzlich doch wieder zuschlägt. Also wie sollte ein Board reagieren wenn es keine Steuersignale mehr erhält? Wo liegen die Herausforderungen einen Ausfall der Steuersignale in "Echtzeit" zu erkennen. Aber die wäre da ein neuer Thread. Nicht nur ich habe mir da sicherlich bereits Gedanken darüber gemacht. Zitieren
oldtrapper Geschrieben 7. Juni 2020 Geschrieben 7. Juni 2020 vor 12 Minuten schrieb Kai: 1. Funkabriss Ursachen Was spricht dagegen, einfach mal ne andere Funke anzulernen und zu testen? Du müsstest doch "an der Quelle" sitzen 🙂 Zitieren
Kai Geschrieben 7. Juni 2020 Autor Geschrieben 7. Juni 2020 Die Schmerzen 😄 Also noch mal. Den Effekt bekommt man mit jeder Funke rekonstruiert in dem man den Empfänger vom VESC trennt. Zitieren
oldtrapper Geschrieben 7. Juni 2020 Geschrieben 7. Juni 2020 Dann muss ich das "mit jeder Funke" im bisherigen Verlauf wohl übersehen haben. So long Zitieren
Kai Geschrieben 8. Juni 2020 Autor Geschrieben 8. Juni 2020 vor 7 Stunden schrieb Kai: Protokollieren der Signalstärke ... gute Idee... ist das in der VESC FW integriert? Da habe ich wohl zu laut nicht zu Ende gedacht. Das PPM Eingangssignal hat leider keine Informationen zur Signalstärke. Wir haben da ja nur Pulsweiten. Und das lässt mich direkt in Richtung NRF Fernbedienung schauen... Zitieren
oldtrapper Geschrieben 8. Juni 2020 Geschrieben 8. Juni 2020 (bearbeitet) vor 3 Stunden schrieb Kai: ... NRF Fernbedienung schauen... Wo Du nRF erwähnst ... Externe Links nur für Mitglieder sichtbar In dem Beitrag läuft es auf die unzureichende Rechenleistung hinaus bearbeitet 8. Juni 2020 von oldtrapper Zitieren
Kai Geschrieben 8. Juni 2020 Autor Geschrieben 8. Juni 2020 Der STM32 vom VESC hat ein wenig mehr Performance als der Atmega vom Uno und die Reaktionszeiten des Vesc sind ja sonst auch nicht im Sekundenbereich aber als ich heute morgen beim Warten auf Externe Links nur für Mitglieder sichtbar einen kurzen in den Quelltext wagte viel mir auf das zum Beispiel die IMU standardmäßig initialisiert wird. Und der IMU Typ standardmäßig auf internal gesetzt ist und nicht auf Naja also wenn kein IMU vorhanden muss der Code eigentlich nicht einkompiliert werden oder wenigstens nicht ausgeführt werden. Aber ich hab zu wenig reingeschaut, das viel mir soweit nur auf. Nun muss ich mich aber zusammenreißen und mich wieder der Arbeit widmen. Zitieren
oldtrapper Geschrieben 8. Juni 2020 Geschrieben 8. Juni 2020 Mit Arbeit versaut man sich den ganzen Tag Zitieren
Empfohlene Beiträge
Tritt dem Gespräch bei
Du kannst jetzt posten und dich später registrieren. Wenn du bereits einen Account hast kannst du dich hier anmelden.