borg

Kannst du einmal ein Ladeprotokoll starten (unter Ladecontroller -> Ladeprotokoll) und dann eine Ladung starten und diese wenn es geht von 16A in Schritten auf 6A verringern? Dann das Ladeprotokoll stoppen, runterladen und hier hochladen. Dann kann ich schauen ob vielleicht die Kalibrierung die wir in WARP1 für den ADC für die Widerstandserkennung haben nicht OK ist. Optimalerweise würde dann am Ende natürlich das Problem auch auftreten, ist aber auch OK wenn es nicht auftritt.

Ich vermute das Bricklet ist einfach nicht geflasht. Wenn du einen Linux-PC und ein Master Brick 3.1 zur Hand hast kannst du den Bootloader über das "write_bootloader_to_comcu_bricklet.sh"-Script aus diesem git https://github.com/Tinkerforge/flash-test drauf flashen. Wenn der Bootloader drauf ist kannst du über den Brick Viewer ganz normal die Firmware flashen. Ansonsten müsstest du das Bricklet einschicken, wir flashen es und schicken es zurück. Entschuldigung für die Probleme!

Oh man, da hast wirklich einen Bug gefunden. Das Boot-Pad (mit dem man das Bricklet beim Booten in den Bootloader bringen kann) war auf den falschen Pin gelegt: https://github.com/Tinkerforge/hall-effect-v2-bricklet/commit/c4be413bc61e2102778f16002d40f57f9c0e7f6e Das Problem ist, den Bootloader (und damit diese Änderung) kannst du mit dem Brick Viewer nicht überschreiben. Falls du in deinem Aufbau nicht vermeiden kannst den Magnet beim Booten in der nähe zu haben müsstet du das Bricklet einmal einschicken und wir flashen dass dann neu. Alternativ würdest du einen Master Brick 3.1 benötigen und einen Linux Rechner auf dem du aus diesem git https://github.com/Tinkerforge/flash-test das Script write_bootloader_to_comcu_bricklet.sh ausführst.

It is fixed now. There was a bit too much copy+paste from GPS V2 documentation.

Now available: https://www.tinkerforge.com/en/shop/gps-v3-bricklet.html 🙂

@rtrbtschickt dir gleiche eine Firmware zum Testen. Wir haben in der Zwischenzeit überlegt woran es mechanisch liegen könnte. Die Schützüberwachung betrifft eigentlich nur ganz wenige Leitungen. Du könntest einmal beim Schütz A1, A2 und 1 nachziehen (vielleicht sogar einmal kurz lösen und wieder fest ziehen) damit 100%ig sicher gestellt ist das wir da keinen Wackelkontakt o.ä. haben. Zusätzlich einmal das PE ganz links an der Klemme lösen und neu reinmachen.

Das ist OK, das ist wirklich der Low-Level-Zustand des Pins, d.h. der geht mit 50hz zwischen low und high hin und her falls Strom angeschlossen ist. Wir haben uns deine Ladelogs angeschaut und tatsächlich eine Idee die wir testen können, wir machen morgen eine Testfirmware dafür fertig.

Die Änderung hat es leider nicht in das neue Bindings-Release geschafft, für das Beta-Release müsstest du einmal wieder downgraden auf die C#-Bindings aus dem Thread den du verlinkt hast.

Wir können tatsächlich reproduzieren das wir über den "Start"-Button eine Ladung starten können wenn der Schlüsselschalter auf aus steht bei WARP1. Das ist so natürlich nicht gedacht, da haben wir uns einen Bug reingeholt als wir die "Charging Slots" eingeführt haben. Wir fixen das am Montag.

There is actually a small SPITFP protocol definition in the SPITFP implementation of the XMC Bootloader firmware source as a comment. Take a look here: https://github.com/Tinkerforge/brickletboot_xmc/blob/master/software/src/bootloader_spitfp.c

Ah, das es ein V1 ist wusste ich nicht. Das Isolator Bricklet ist nicht kompatibel zu den alten V1 Bricklets! Das Isolator Bricklet würde also nur zusammen mit einem Voltage/Current Bricklet 2.0 Sinn machen.

Uns sind da aktuelle keine Stabilitätsprobleme mit dem Voltage Current Bricklet 2.0 bekannt. Wenn du sagst es hilft den Master Brick zu resetten: Reicht da wirklich ein Reset oder müsst ihr das Master Brick vom Strom trennen? Falls ein Reset reicht: Reicht es auch das Voltage Current Bricklet 2.0 neuzustarten über die API? Worauf ich hinaus will: Wenn ein Reset wirklich reicht dann muss meiner Meinung nach irgendein Fehlerfall nicht korrekt abgefangen werden von uns in der Firmware, da wir ja alles was bei einem Reset passiert auch im laufenden Betrieb machen können in Theorie.

Mh, mir sind da aktuell keine generellen Probleme bekannt. Ist das Display in einem Gehäuse verbaut oder liegt das frei auf einem Tisch? Oder ist neben dem Display vielleicht irgendwas anderes Verbaut was irgendwie zu Störungen führen könnte o.ä.?

I am out of ideas. We will ship you a new CO2 Bricklet 2.0. You will get an acknowledgement email, please check if the address is correct. Very sorry for the trouble!

Rein technisch kann WARP2 die CP-Verbindung zum Auto trennen und somit das Kabel aus Sicht des Autos "abstecken". Per Default wird das allerdings aktuell noch nicht gemacht.

Firmware: PTC Bricklet 2.0 2.0.4, Industrial PTC Bricklet 2.0.2 Improve MAX31865/SPI error handling Download: PTC Bricklet 2.0, Industrial PTC Bricklet

Firmware: PTC Bricklet 2.0 2.0.4, Industrial PTC Bricklet 2.0.2 Improve MAX31865/SPI error handling Download: PTC Bricklet 2.0, Industrial PTC Bricklet

Firmware: CO2 Bricklet 2.0 2.0.3 Make sure ASC is enabled on each startup Download: CO2 Bricklet 2.0

Firmware: CO2 Bricklet 2.0 2.0.3 Make sure ASC is enabled on each startup Download: CO2 Bricklet 2.0

Now, this is rather embarrassing, but i think you are onto something. The enabling is supposed to happen during the flash/test processes, but i don't think it is done properly 😯. I read the ASC configuration back on a sensor that has gone through the flash/test process and it was not enabled. I just released firmware version 2.0.3. It enables ASC on each startup (https://github.com/Tinkerforge/co2-v2-bricklet/commit/9a688c7b36326f0ab17b64a99df94bc330140709). According to the interface documentation we should wait 7 days to see if it works:

Anbei eine angepasste Kalibrierung. Bitte einmal einspielen. Falls es damit noch nicht funktioniert bis auf 6A runter mach bitte noch ein debug log. Am besten fängst du bei 16A und regelst dann Stück für Stück runter. Dann kann ich am besten approximieren wie wir die Kalibrierung anpassen muss. Die Kalibrierung bleibt auch zwischen Versionswechseln bestehen, also du kannst danach dann auch ruhig weiter aktualisieren! calibration_new.json

Das ist wirklich seltsam. Das letzte Update hat nichts am eigentlichen Ladeverhalten geändert. Damit wir das debuggen können wäre es am besten wenn du einmal den "Debug-Report + Ereignis-Log" runterlädst (unter System -> Ereignis-Log). Zusätzlich am besten einmal ein Ladeprotokoll erstellen während du von einem Ladestrom bei dem das Fahrzeug lädt den Strom verringerst bis es zum Fehlerfall kommt. Dazu musst du zuerst das Protokoll starten (unter Ladecontroller -> Low-Level), dann den Fehlerfall erzeugen dann das Ladeprotokoll stoppen und runterladen. Mit den beiden Dateien können wir dann exakt nachvollziehen in welchem Zustand der WARP Charger und das Auto ist im Fehlerfall.

Solange autostart aktiviert ist, wird nach dem Stromausfall die Ladung wieder erneut gestartet!

Firmware: Silent Stepper Bricklet 2.0 2.0.3 Fix bug in AllData-Callback period handling Download: Silent Stepper Bricklet 2.0

Firmware: Silent Stepper Bricklet 2.0 2.0.3 Fix bug in AllData-Callback period handling Download: Silent Stepper Bricklet 2.0