borg

Der Master Brick 3.1 hat leider einen Hardware-Bug auf Grund dessen er nicht mit den RS485 Extenions funktioniert: https://www.tinkerforge.com/de/doc/Hardware/Bricks/Master_Brick.html#errata-hardware-version-3-1 In der nächsten Fertigung von Master Bricks ist das gefixt. In der Zwischenzeit haben wir da leider sonst keine direkte Lösung um das mit der RS485 Extension zum Laufen zu bekommen. Ihr könntet vielleicht je ein ESP32 Brick + Sensor nehmen und das dann über WLAN verbinden. Das wäre preislich nicht teurer als Master Brick + RS485 Extension.

The _*_low_level_* functions are used internally to implement the public streaming-functions like tf_sound_pressure_level_get_spectrum and the callback for SOUND_PRESSURE_LEVEL_CALLBACK_SPECTRUM. So please use either tf_sound_pressure_level_get_spectrum or sound_pressure_level_set_spectrum_callback_configuration together with the SOUND_PRESSURE_LEVEL_CALLBACK_SPECTRUM. You can use the decibel callback and the spectrum callback at the same time. The decibel value is not directly included in the spectrum (it can in theory be calculated from the spectrum though: https://github.com/Tinkerforge/sound-pressure-level-bricklet/blob/master/software/src/pcm.c#L122).

Wir gehen aktuell von 249€ brutto aus (ohne Gewähr).

EVCC hat Unterstützung für unsere WARP Charger, ja: https://www.warp-charger.com/evcc.html Ansonsten arbeiten wir auch gerade an einem Energiemanager mit dem man PV-Überschussladen realisieren kann. Der Energiemanager kann auch zwischen 1-phasig/3-phasig umschalten wodurch man mit geringerer Leistung laden kann.

Für IEC61851 State C (Das Auto lädt, Schütz ist geschaltet) akzeptieren wir Widerstände zwischen 300 und 1790 Ohm. Der Widerstandsmessung bleibt auch wenn sich der Strom ändert definitiv hinreichend stabil (880 wäre optimal): In deiner zweiten Messung wird am Anfang bevor das Auto lädt 2350 Ohm gemessen (das ist OK). Im Fehlerfall springt CP/PE dann aber auf einmal zwischen 1750 und 1880 hin und her: Das ist natürlich Murks. Der Standard sieht hier 2700 Ohm vor wenn das Auto noch dran ist aber nicht laden will. Anbei eine Kalibrierung die alle Werte ein bisschen hoch zieht, so dass die 880 Ohm genauer erreicht werden sollten und wir auch im unteren Fall weit über 1790 bleiben. calibration.json

Das Protokoll dieser "Standard-Wetterstationen" nutzt eine CRC: https://github.com/Tinkerforge/outdoor-weather-bricklet/blob/master/software/src/rfm210.c#L84 Ein Bitfehler als Fehlerquelle ist also eher unwahrscheinlich. Es gibt allerdings andere ähnliche Wetterstationen welche die gleiche CRC aber einen anderen Payload nutzen... Ich weiß von mindestens drei unterschiedlichen Protokollen die gleich aufgebaut sind und anderen Inhalt haben. Das hier ein anderes System stört halte ich für wahrscheinlicher.

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