borg

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.

Ich bin mir nicht 100%ig sicher ob ich die Frage richtig verstehe. Das Bricklet nutzt einen I2C-IO-Expander. Dieser wird ca. 1000x pro Sekunde per I2C ausgelesen. Falls das Signal deines Encoders eine Frequenz von mehr als 1kHz hat kann das Bricklet keine Callbacks/Interrupts für jeden Flankenwechsel erzeugen leider.

Strange. Have you tried turning it off for a a few hours and then on again?

As far as i understand how the CO2 sensor we use works, it should automatically recalibrate itself to ~400PPM after some time: So when the sensor sees a specific PPM concentration regularly, it will calibrate itself towards this value being 400 PPM.

I did some digging in the source code of the Bricklet and the datasheet of the MAX31856: As far as i can tell the status register is read in a loop and the reading of new temperatures is stopped when there is an error in the status register and started again when the error is gone. So i think the 5 seconds are internally in the MAX31856 (i can not find any data on this in the datasheet though). But i found something else. The chip supports different kinds of open circuit detection: The Bricklet currently always configures this to 01, which has the smallest test time. I made you two firmwares for testing: One has OCFAULT set to 11, which should be more forgiving. The other firmware has the Open-Circuit detection disabled (OCFAULT set to 00). Since you are sure that the open circuit detection is a false positive in your case, maybe it is the easiest to just disable it. If any of the settings helps for you, i can add this setting as a new configuration setter to the API. thermocouple-v2-bricklet-firmware-ocfault-00.zbin thermocouple-v2-bricklet-firmware-ocfault-11.zbin