borg

Am einfachsten mit einem USB Hub und mehreren Stapeln aus Master Bricks.

6A ist der geringste maximale Ladestrom den der Standard erlaubt.

Wobei die Wallbox immer den maximalen Ladestrom vorgibt, das Auto darf dann selbst entscheiden wieviel es zieht, in deinem Fall dann aber maximal 6A.

Sprich wenn du den Golf auf 5A einstellen kannst dann darf er sich natürlich auf 5A begrenzen.

Warum der Golf nur 3,5A zieht (2400W) weiß ich nicht. Eventuell fährt er eine bestimmte Ladekurve ab um den Akku zu schonen und er zieht erst später mehr. Oder der Akku ist zu kalt für höhere Ströme o.ä.

Wie gesagt: Die Wallbox gibt den maximalen Strom vor den das Auto nutzen darf und das Auto entscheidet dann selbst wieviel es davon zieht.

Wenn du eine spezifische Anwendung hast die größere Stückzahlen benötigt frag einfach per Email an (mit der Stückzahl und was genau du an Features benötigst auf dem HAT), ab einer gewissen Stückzahl können wir natürlich auch Custom-Bricks/Bricklets machen.

1) nein

2) nein, leider auch nicht.

Very sorry for the long delays. I did take a look last month, but we didn't have any relevant changes regarding the P2P code in the last firmware versions.

The P2P code was always a bit finicky to be honest... Internally we use the official library that NXP provides. Unfortunately this has been unmaintained from NXP for many years now and there are no updates available.

I did put it on my TODO list to add some debug and find out where exactly we get an error during the NCI-Interface communication, but i haven't found time to do this yet. This is unfortunately a big effort because of the complexity of this protocol.

I will add an update if i have any news.

Das hat definitiv nichts mit der RS485-Kommunikation zu tun, die funktioniert und ist auch auch per Checksumme abgesichert.

Die Logik für "Aktive Phasen" ist einfach nur Strom >0.01A (pro Phase). Da der Stromzähler einen kleinen Strom misst werden die Phasen als aktiv angezeigt.

Warum der Stromzähler hier einen kleinen Strom misst ist jetzt die Frage.

Ich vermute dass der Strom hier auf Grund irgendwelcher Induktiven Effekte auf der Länge des Kabels eingespeist wird.

Wir haben das jetzt schon bei mehreren Kunden gesehen, es tritt allerdings nicht bei allen Autos auf.

Ich diskutiere nochmal intern ob wir vielleicht einfach den Grenzwert zur Erkennung einer aktiven Phase etwas hochsetzen um hier Verwirrung zu vermeiden.

Es gibt jetzt einen Stromlaufplan auf warp-charer.com:

https://www.warp-charger.com/documents/WARP2_Stromlaufplan.pdf

Ja das sieht gut aus, besten Dank für die Hilfe!

Nur um sicher zu gehen das wir jetzt eine komplett funktionierende Konfiguration gefunden haben:

Wenn du auf das Display geschrieben hast und dann den Strom abziehst, bleibt das Bild dann 100% korrekt stehen?

Oder "fadet" es ein bisschen aus und verliert an Kontrast?

Das Bild sollte komplett unverändert bleiben.

Kannst du nochmal die Firmware im Anhang testen?

(Diesmal wirklich im Anhang)

e-paper-296x128-bricklet-firmware-2.0.6-beta1.zbin

Oh, ich hab ausversehen die Master Brick Firmware hier hochgeladen und auf den Server als E-Paper Bricklet Firmware...

Bitte nochmal probieren, hab das gerade korrigiert. Der Bug hier hat nichts mit dem Master Brick zu tun, bin da anscheinend vollkommen durcheinander gekommen mit den Firmwares.

Um sicher zu gehen hab ich gerade in den Low-Level Code vom EVSE geschaut und dort ist es wie folgt definiert:

typedef enum {
    CONTACTOR_CHECK_STATE_AC1_NLIVE_AC2_NLIVE = 0,
    CONTACTOR_CHECK_STATE_AC1_LIVE_AC2_NLIVE  = 1,
    CONTACTOR_CHECK_STATE_AC1_NLIVE_AC2_LIVE  = 2,
    CONTACTOR_CHECK_STATE_AC1_LIVE_AC2_LIVE   = 3,
} ContactorCheckState;

(AC1 ist vor und AC2 nach dem Schütz)

Ich würde also sagen 1 und 2 sind vertauscht in der Doku. Ich fixe das gleich.

Der Hersteller des Displays hatte uns gesagt das wir für den neuen Treiberchip nur die Initialisierung ändern müssen und der Rest ist gleich.

Nach genauerem Vergleichen der Datenblätter hat sich jetzt herausgestellt dass die LUT zwischen den beiden Chips eine andere Definition hat.

Ich hab das jetzt so angepasst dass der neue Treiber das Verhalten vom alten 1:1 simuliert und werde das gleich auch erst so veröffentlichen nachdem ich noch ein paar Sachen teste: https://github.com/Tinkerforge/e-paper-296x128-bricklet/commit/2970dc3db212401249e1a460370054082f2f1ad2

Auf Dauer können wir das vielleicht noch verbessern, da der neue Treiber viel mehr Konfigurationsmöglichkeiten hat.

So sieht das jetzt aus bei mir: https://imgur.com/0vFcxVc

Welche Firmware-Version hat das Bricklet?

Hab gerade ins Changelog geschaut und vor Version 2.0.3 gab es einen Bug mit der FillDisplay-Funktion im Deltamodus.

Grundsätzlich ist es ja so, dass das Auto über den Typ2-Stecker per AC den Strom bezieht und intern einen Wechselrichter hat der in DC umwandelt. In der Batterie wird dann auch "als DC gespeichert". Wenn jetzt zurück gespeist werden soll müsste das Auto auch noch einen Wechselrichter haben der von DC wieder in AC wandelt und wenn dann in das Stromnetz eingespeist werden soll müsste das Auto auch noch Netzsynchronisation machen.

Spannung als DC zurück zu speisen ist über den Typ2-Stecker nicht vorgesehen.

Die Insellösungen die es aktuell von einigen Herstellern gibt haben entweder intern einen Wechselrichter und man kann ein 230VAC-Gerät direkt ans Auto anschließen (keine Netzsynchronisation notwendig) oder die Rückspeisung findet per DC statt über einen proprietären Stecker oder über den CCS-Stecker und die Wandlung DC->AC und Netzsynchronisation findet über einen teuren externen Wechselrichter statt.

Letzteres können die "normalen" Wallboxen die einen Typ2-Stecker haben ja gar nicht machen.

Dazu dann die ganzen rechtlichen und steuerrechtlichen Probleme (was passiert steuerlich wenn ich bei meinem Arbeitgeber lade und dann zuhause wieder einspeise?)

Ich befürchte kurzfristig wird es da keine einfache Lösung geben die alle Wallboxen und alle Autos unterstützen können und rechtlich dürfen 🙁.

It is currently still running without problems, i will leave it running for now.

Is there anything else you guys are doing besides having a magnet permanently close to the Bricklet?

The chip temperature is given in 1/10 °C.

However, while looking up if 1/10 °C is correct i discovered that the SAM3 microcontrollers use a different formula for the internal chip temperature compared to the SAM4 microcontrollers. For the Master Bricks we switch back and forth between the two types (they both have the same pinout and hardware units) depending on availability.

I attached a firmware that differentiates between the two formulas depending on what microcontroller your Master Brick has.

One more thing: The accuracy is given as +-13°C full-scale and an additional +-7% error per degree change. So if it shows 10° while the processor is at 25° this is within spec.

The chip temperature should however increase and decrease with the actual temperature (with a relative error of at most 7%).

master-brick-2.5.1-beta.bin

DC-Schutzmodul-Fehler wäre Nummer 3 oder nicht?

Ich glaube die Schiebeschalter zum einstellen des maximalen Ladestroms stehen auf "Deaktiviert" bei dir.

Siehe Seite 7 in der Betriebsanleitung: https://www.warp-charger.com/documents/WARP2_Betriebsanleitung.pdf

Im Fehlerfall sollte der WARP Charger auch einen Blinkcode ausgeben, die sind auf Seite 19 in der Anleitung beschrieben (der Error-State entspricht der Anzahl der "Error-Blinkvorgänge").

To make sure that the Master Brick is in bootloader mode you can press the erase button while you plug USB in.

If that doesn't help, can you run

ioreg -p IOUSB

in the console and post it here?

Very strange, i can't explain how or why this could possibly happen.

I will try to reproduce it. Currently i started a Hall Effect Bricklet 2.0 and just put a powerful magnet on top. Nothing has happened yet, i will wait a few hours now.

This is very strange. There are a few ways a Bricklet can enter the bootloader mode:

• No firmware was flashed yet
• A new firmware flashing process is started
• The flashed firmware is wrong (wrong checksum, firmware of other Bricklet flashed or similar)
• The bootloader pad on the PCB is shorted

The bootloader pad is the gold pad above the ".com" in this picture:

Can you check that the pad is not shorted? Is it possible that there is some process running in the background that tries to flash a new firmware?

vor 5 Stunden schrieb floho:

Ich habe hierzu noch ein wenig nachgelesen. Es ist wohl so, dass die Verriegelung mechanisch oder elektrisch gemacht werden muss. Sprich, die Wallbox, wenn nicht mechanisch verriegelt wird, muss das Abziehen durch den nachgeführten CP Kontakt erkennen und daraufhin den Schütz innerhalb einer vorgegebenen Zeit abschalten. Inwieweit das eine sicherheitsrelevante Bewertung braucht, weiß ich nicht. Ob die WARP das (spezifikationstechnisch ausreichend) tut weiß ich natürlich auch nicht.

Der WARP Charger schaltet das Schütz innerhalb von höchstens 100ms ab wenn der Stecker während einer Ladung gezogen wird. Die 100ms sind im IEC 61851-1 Standard als "t_ACoff" vorgeschrieben. Das ist auch im Test den wir für jeden EVSE durchführen: https://github.com/Tinkerforge/evse-v2-bricklet/blob/master/tests/full_test.py#L308

Soweit ich weiß ist eine mechanische Verriegelung der Dose in DE aber trotzdem vorgeschrieben.

Does this work with firmware 2.0.5?

Das Energy Monitor Bricklet hat keine Real-Time Clock. Es nutzt den internen Oszillator vom Microcontroller. Dadurch hat es bei der Zeitmessung leider keine hohe Genauigkeit. Ich vermute die Diskrepanz kommt dadurch zustande.

Between 2.0.6 and 2.0.5 we added new API functions and we changed the optimization level of the compiler for some functions because we didn't have enough firmware space left otherwise.

I will have to look into this, maybe this somehow changed the timing a little bit and that breaks something?