borg

Galileo wird seit Mitte 2022 unterstützt, anscheinend hatte damals niemand die API-Doku aktualisiert 🙈. Hab die API-Doku gerade gefixt.

Das ist sehr komisch, hast du irgendwie beiden Bricklets ausversehen die gleiche UID gegeben (die UID bei den Bricklets kann man ja überschreiben)?

Die externe Steuerung muss in den neueren Firmwares nicht mehr aktiviert werden, allerdings sollte sie nach einem Update natürlich nicht blocken. Das schauen wir uns an, gibt dann denke ich noch ein schnelles Release hinterher was das fixt. Falls sonst noch jemand das Problem hat: Ihr könnt unter Wallbox -> Ladestatus bei "Externe Steuerung" auf zurücksetzen klicken, dann passt auch wieder alles.

Der Stecker ist ein JST PH

Das dachte ich mir, d.h. der SHARP IR Sensor gibt die Werte so analog zurück, da können wir dann nichts machen.

Kannst du den "Analog Value" auch einmal mit plotten? Hat der auch so Stufen?

Hab gerade kurz in den Code geschaut, beim Booten führen wir erst einmal eine Reset-Sequenz aus um sicher zu sein dass wir wissen in welchem Zustand sich der BNO055 befindet. Das dauert 1200ms. Danach laden wir dann die Kalibrierung falls vorhanden, dann wird die komplette Konfiguration des BNO055 einmal geschrieben und dann werden das erste mal die Sensorwerte gelesen. Also ein bisschen "Bootzeit" benötigt die IMU wirklich, aber ich hätte jetzt gedacht dass wir da trotzdem schneller sind als dein RPi bootet?

There should be no drift(*). How did you connect the encoder and how did you configure the Bricklet? (*): The only way you should be able to introduce drift is if the signal is not unambiguous anymore. For example if the high voltage is normally 24V, but if it starts to bounce back and force with high frequency the high voltage only goes up to 5V or so. In that case it can easily happen that the Bricklet starts to miss transitions.

Firmware: NFC Bricklet Bricklet 2.1.0 NXP NfcLibrary aktualisiert Überschreibefehler beim Input-Buffer behoben Unterstützung für NFC Forum Typ 5 (ISO 15693) hinzugefügt NDEF-Unterstützung für NFC Forum Typ 5 und Mifare Classic hinzugefügt Verbesserte Kartenemulationsunterstützung (funktioniert jetzt richtig zwischen zwei NFC Bricklets und mit Android/iPhone) Unterstützung für benutzerdefinierte Tag-ID im Kartenemulationsmodus hinzugefügt P2P-Unterstützung entfernt Download: NFC Bricklet

Firmware: NFC Bricklet Bricklet 2.1.0 Update NXP NfcLibrary Fix input buffer overwrite bug Add support for NFC Forum Type 5 (ISO 15693) Add NDEF support for NFC Forum Type 5 and Mifare Classic Improve card emulation support (now properly works between two NFC Bricklets and with Android/iPhone) Add support for custom tag ID in cardemu mode Remove P2P support Download: NFC Bricklet

Der Unterschied liegt im Messprinzip. Die EVSE 2.0 und 3.0 haben einen ADC der synchron mit dem PWM 2000x pro Sekunde die Spannung zwischen CP und PE misst (einmal wenn das Signal high ist und einmal wenn es low ist pro PWM-Durchlauf). Da wir das komplett steuern können wir bei einer High-Zeit von x us und einer Low-Zeit von y us (wobei x+y=1ms bei 1kHz PWM) genau bei x/2 und y/2 messen. Dadurch bekommen wir eine sehr gute Messung wo etwaiges "Ringing" o.ä. bei den Flankenübergängen rausgefiltert werden. Zusätzlich mitteln wir über 50 Werte um Glitches rauszuglättern. Mit den Werten können wir den Widerstand den das Auto zwischen CP und PE anlegt sehr exakt bestimmen. Das EVSE 1.0 misst über über die besagten 50ms. D.h. es bildet sozusagen das Integral über 50ms des CP/PE-Signals. Da wir die Pulsweite und die Low-Spannung genau kennen können wir daraus rein theoretisch mathematisch auch den Widerstand bestimmen. In der Praxis hat sich aber herausgestellt dass das Signal was auf CP/PE ist oft stark rauscht und bei manchen Autos treten komische kapazitive(?) Effekte auf, weswegen beim EVSE V1 die Kalbrierung notwendig ist.

Schau mal hier: https://vislog.warp-charger.com/j2ME2bJLYQxZjnrVwNvexa und aktiviere oben den Widerstand CP/PE Man sieht dass die Duty Cycle auf 26.6% springt sobald das Schütz abgeschalten wird (was ein neues Feature ist um eine möglichst gute Messung machen zu können). Der CP/PE Widerstand geht dann bis auf 22k Ohm hoch (der Threshold für den Wechsel des Status auf "getrennt" liegt bei 10k Ohm). Bevor der Wechsel dann aber stattfindet springt der Widerstand runter auf 7k Ohm und bleibt da. Deswegen denkt deine Wallbox das Auto ist noch angeschlossen will aber nicht laden. Dass der Wert da runter springt kann aber nicht an deinen Änderungen liegen oder? Das ist mir nämlich etwas schleierhaft wo der Sprung da auf einmal wegkommt.

Da ist ein N in Richtung Norden auf dem Windrichtungsmesser:

Also rein technisch misst das EVSE die 50Hz zwischen L1 und PE die vor dem Schütz sind. Im Ladeprotokoll kann man sehen dass dort nichts gemessen wird. Da der EVSE gar nicht erst laufen würde wenn kein L1 da ist, gehen wir in diesem Fall davon aus das es ein Problem mit PE ist. Um ganz sicher zu sein dass PE beim EVSE ankommt, könntest du einmal im unbestromten Zustand zwischen der Hutschiene und dem unteren Beinchen des CP/PP-Widerstands messen (roter Pfeil im Bild). In blau hab ich markiert in welchem Stecker PE und L1 beim EVSE ankommen, L1 geht dann über die Sicherung und über ein paar andere Bauteile zu einem Optokoppler und von da direkt zum Mikrocontroller. Wenn die Sicherung i.O. ist und PE definitiv beim EVSE ankommt muss es denke ich ein Hardwaredefekt beim EVSE sein. Eventuell ist der Optokoppler oder eines der Bauteile zwischen Eingangsstecker und Optokoppler defekt. In dem Fall sehe ich zwei Möglichkeiten: Du schickst die Box ein, wir reparieren sie und schicken sie zurück oder wir schicken dir ein neues EVSE und du müsstest das dann selber einbauen oder einbauen lassen. Ersteres hat den Vorteil dass du dir 100% sicher sein kannst eine heile Wallbox zurück zu bekommen, auch wenn es vielleicht doch nicht am EVSE liegt. Schreib dazu einmal eine Email an sales@tinkerforge.com mit Hinweis auf diesen Thread dann können wir den Rückversand oder Versand eines EVSE in die Wege leiten.

Kannst du einmal unter Wallbox -> Ladestatus -> Ladeprotokoll -> Start und dann zwei Minuten später Stop+Downlaod ein Ladeprotokoll erstellen und hier anhängen? Muss kein Auto angeschlossen sein o.ä., in dem Ladeprotokoll sind auch die Inputs mit drin die bei der Schützprüfung verwendet werden, das wäre hier interessant zu sehen wie die sich verhalten.