borg

Das Signal vom OBD2-Stecker kann man abgreifen und mit dem CAN Bricklet auslesen. Die Protokolle die von den Herstellern gesprochen werden dort sind aber natürlich je nach Hersteller unterschiedlich und man findet mal mehr und mal weniger Informationen dazu. https://wiki.muc.ccc.de/_media/asm:16:workshops:kfz_diagnoseprotokolle.pdf

This is unfortunately how these sharp sensors work. They output an analog voltage, but the voltage gets updated in "steps", as you see in the chart above. You can increase the moving average to get a bit of a measurement in-between if it oscillates between two of the steps.

zu 1) Soweit ich weiß verhalten sich die Renault Zoes genauso (mit denen wir viel testen) und damit klappt das schlafen und wieder aufwachen gut. zu 2) Das hängt ein bisschen davon ab was das Auto genau macht. Rein technisch legt das Auto einen Widerstand zwischen CP und PE an, wenn das Auto diesen einmal trennt fängt der WARP Charger auch wieder an zu laden. Ansonsten kann man die Ladung aber auch über die Webseite des WARP Chargers übers Handy wieder starten. Das wäre aber auch ein einfaches Feature welches wir noch hinzufügen könnten. Ich stelle mir gerade vor dass man auf der Webseite einstellen kann nach wie vielen Sekunden Ladeabbruch das Laden wieder gestartet wird und die Standardeinstellung ist 0 (nie). Wir sind da was solche Features angeht definitiv für Feedback offen und haben vor die WARP Charger langfristig weiterzuentwickeln!

Mh, in der Tat. Sieht im Code so aus als würden wir bei der 6x8 Schriftgröße oben links starten und dann von da skalieren. Was natürlich nicht besonders intuitiv ist. void gui_draw_text_horizontal(const uint16_t column, const uint16_t row, const uint8_t text_length, const char *text, const uint8_t col_mul, const uint8_t row_mul, const uint8_t color) { for(uint8_t i = 0; i < text_length; i++) { for(uint8_t j = 0; j < 6; j++) { const uint8_t data = ((j == 5) ? 0 : font[(uint8_t)text[i]*5 + j]); for(uint8_t k = 0; k < 8; k++) { if(data & (1 << k)) { const uint16_t pixel_column = j*col_mul + column + i*6*col_mul; const uint16_t pixel_row = k*row_mul+row; if((row_mul == 1) && (col_mul == 1)) { gui_set_pixel_color(pixel_column, pixel_row, color); } else { const int16_t x_end = pixel_column+col_mul-1; const int16_t y_end = pixel_row-row_mul+1; if((x_end < 0) || (y_end < 0)) { continue; } gui_draw_box(pixel_column, pixel_row, x_end, y_end, true, color); } } } } } } Ist echt blöd, wenn ich das jetzt ändere bricht das natürlich bestehenden Code. Ich habs mir aufgeschrieben mir das nächstes Jahr anzugucken. Ich gehe dann durch und schaue auch ob wir woanders das gleiche Problem noch haben. Jetzt vor den Feiertagen schaffe ich es nicht mehr.

Nach unseren Informationen gilt eine Wallbox mit CEE-Stecker als mobile Wallbox und ist nicht förderfähig 🙁. Bei der 11kW Variante muss der Elektriker nichts bestätigen (es sollte halt auf der Rechnung stehen dass er eine 11kW Box angebracht hat, mit dem exakten Namen am besten damit die das zuordnen können), aber er muss trotzdem einmal die Box aufschrauben und den Schiebeschalter korrekt auf 11kW einstellen (passend für die Zuleitung, könnte ja weniger als 11kW sein die Zuleitung). Mag beides ein bisschen albern klingen, aber so sind die Spielregeln für die Förderung. Falls da jemand andere Informationen hat bitte melden. Aber sonst ja. Mal abgesehen von der Förderfähigkeit kannst du einfach eine Wallbox mit CEE Stecker kaufen, den Schiebeschalter passend einstellen, dann einstecken und sofort anfangen zu laden.

Wir lassen aktuell noch eine Charge von den alten Master Bricks fertigen. Ab der nächsten Produktion wird es die neuen geben mit dem 7-Pol-Stecker. Einen exakten Termin haben wir dafür aber leider noch nicht. Im ersten Quartal 2021 aber auf jeden Fall!

Um wirklich sicher zu gehen dass der Lepton-Sensor richtig in seinem Sockel sitzt: Kannst du den Sensor einmal aus dem Sockel entfernen und ihn wieder reinstecken? Rein vom Fehlerverhalten sieht es so aus als könnte das Bricklet nicht mit dem Sensor kommunizieren. Ansonsten müsstest du das Bricklet einschicken, dann tauschen wir es aus.

Du meinst wahrscheinlich einen 16A/11kW Anschluss der gegen einen 32A/22kW-Anschluss getauscht werden soll? Grundsätzlich kann der 32A WARP Charger auf 16A oder weniger runter-geregelt werden während der 16A WARP Charger natürlich nur maximal 16A unterstützt. Inwiefern die Nebenverbraucher parallel verwendet werden können (oder ob die Wallbox vielleicht auf 10A oder eingestellt werden muss) muss ein Elektriker vor Ort entscheiden. Das hängt davon wie genau die Garage abgesichert ist und wieviel "Puffer" noch da ist.

Bisher konnte ich es leider nicht reproduzieren. Ich hab meinen Kollegen der für das Hardwaredesign zuständig ist mal auf diesen Thread aufmerksam gemacht, eventuell hat er ja eine Idee ob man das anders verdrahten kann o.ä.

Da wir diese Anfrage jetzt schon mehrfach bekommen haben werden wir auf Dauer höchstwahrscheinlich auch längere Kabel anbieten. Allerdings werden wir wenn die Produktion im Januar anläuft erst nur Wallboxen mit 5m angeschlagenem Kabel anbieten können. Wir bekommen die Kabel aktuell fertig inklusive Type 2 Stecker und 5m Kabel angeliefert. Ich melde mich nochmal wenn wir festgelegt haben wie wir unterschiedliche Kabellängen genau unterstützen und wann dies möglich sein wird.

Ist per Schiebeschalter umschaltbar. Das wird in der offiziellen KfW Liste auch noch angepasst, so dass die 22kW Boxen dort auch explizit aufgeführt werden. Der Schiebeschalter muss aber von einem Elektriker/Fachbetrieb eingestellt werden und der Elektriker muss dafür unterschreiben dass er es auf exakt 11kW eingestellt hat (nicht mehr und nicht weniger). Per Software kann die Ladeleistung danach noch verändert/verringert werden, allerdings natürlich nicht über die vom Elektriker eingestellte Schiebeschalter-Stellung.

Hi, Wie ihr vielleicht schon gesehen habt gibt es jetzt eine "WARP"-Kategorie bei uns im Shop. Dabei handelt es sich um die Kategorie für unsere neuen WARP Charger (Wall Attached Recharge Point) und dazu passendes Zubehör. Beim WARP Charger handelt es sich um eine von Tinkerforge entwickelte Open Source KfW 440 förderfähige Wallbox! Details dazu könnt ihr im Blog nachlesen: https://www.tinkerforge.com/de/blog/warp-charger/ Da wir in der offiziellen KfW-Förderliste bereits mit aufgeführt sind, wurden wir tatsächlich von einer regelrechten Anfragenwelle überrascht. Wir haben uns daraufhin entschieden etwas überhastet den WARP Charger bereits im Shop zu veröffentlichen und zur Vorbestellung anzubieten. An dieser Stelle sei darauf hingewiesen dass ein Teil der Dokumentation (und auch die Betriebsanleitung) noch nicht komplett fertig gestellt sind. Auch einige der Bilder sind nur als Platzhalter anzusehen und werden noch durch professionelle Bilder ausgetauscht. Einen Überblick darüber was genau die WARP Charger können könnt ihr in der Broschüre und dem Datenblatt bekommen: https://github.com/Tinkerforge/warp-charger/raw/master/documents/WARP_Broschuere_low.pdf https://github.com/Tinkerforge/warp-charger/raw/master/documents/WARP_Datenblatt_low.pdf Unsere kleine Firmenflotte von fünf Elektrofirmenfahrzeugen laden wir übrigens schon seit gut einem Jahr mit dem WARP Charger und den ersten Prototypen davon. Neben den bereits Dokumentierten Features die wir bis zum Januar finalisieren werden könnt ihr euch in Zukunft auf stetige Erweiterungen der WARP Charger freuen. Zu den neuen Features wird sicherlich sowas wie Lademanagement (Verknüpfung mehrerer WARP Charger) gehören und einer Landing-Page und Online-Dokumentation unter warp-charger.com/de. Aber besonders freuen wir uns auf euer Feedback zum vorantreiben der Weiterentwicklung!

Ich lasse mal einen Langzeittest mit den Sensoren laufen die ich hier hab, mal schauen ob ich es reproduzieren kann.

Danke für den Code. Ich hab da jetzt keine Ideen mehr, ich müsste dann versuchen das Problem hier zu reproduzieren. Du weißt nicht zufällig ob das Problem bei dir auch mit nur einem Temperatursensor auftritt? Ich hab nur einen hier, ich würde jetzt sonst erst 16stk bestellen um zu versuchen das zu reproduzieren. Welche Sensoren verwendest du genau? In der Zwischenzeit als Workaround kannst du aber im Code auch wenn das Problem auftritt einmal reset() auf dem Bricklet aufrufen (das geht nicht nur im Brick Viewer). Edit: Und ja, die CRC brauchst du eigentlich gar nicht mehr überprüfen, da wir sowieso nur Daten mit überprüfter CRC übertragen.

Die CRC-Berechnung ist schon korrekt, sonst würde das Bricklet auch gar nicht funktionieren. Wir nutzen die original Lookup-Table von Maxim von hier: https://www.maximintegrated.com/en/design/technical-documents/app-notes/2/27.html Ich hab gerade hier https://www.maximintegrated.com/en/design/technical-documents/app-notes/4/4600.html auch eine Excel-Datei von Maxim gefunden mit der man die CRC überprüfen kann und da mal die Daten aus dem Brick Viewer Screenshot eingetragen: Da muss irgendwo etwas anders sein bei 1-Wire-CRC im Vergleich zur Standard-CRC-Berechnung. Daher passt es bei der CRC-Seite nicht. Das Polynom (x⁸+x⁵+x⁴+1) ist eigentlich korrekt. Warum ein Software-Reset hilft um das Problem zu beheben ist mir aktuell noch schleierhaft. Das Reset startet den Micrcontroller neu, aber ich finde da jetzt nichts in der Initialisierung vom Bricklet was dazu führen könnte ein Problem mit den angeschlossenen Sensoren zu beheben. Hast du schon ausprobiert "reset_bus" aufzurufen wenn das Problem auftritt? Hilft das?

Die CRC wird nicht berechnet vom Brick Viewer, den Anzeigecode kannst du hier finden: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/one_wire/one_wire.py#L91 Das Bricklet selbst überprüft allerdings die CRC: https://github.com/Tinkerforge/one-wire-bricklet/blob/master/software/src/one_wire.c#L291 Dementsprechend sollten da sowieso nie unkorrekte CRCs im Brick Viewer auftauchen. Das bedeutet aber auch, dass wenn du die fehlerhaften Werte (-0.1°) bekommst diese wirklich von den 1-Wire-Sensoren verschickt werden (oder die CRC passt nur zufällig). Sehr seltsam. Wenn du sagst ein "Reset" hilft, meinst du dann ein Reset per Software?

Ist der Screenshot von einer Situation wo die Werte nicht OK sind? In der Liste ist bei der ID die führende 0 nicht mit angegeben, sprich der zu überprüfende HEX-String für "Search Bus(0)" ist 280218607460ff, was aber wenn ich das richtig sehe eine CRC von 0xBC ergeben sollte.

Ich hab keine Ideen mehr, ich vermute der CO2 Sensor selbst ist defekt. Bitte schreib eine Email an info@tinkerforge.com mit einem Hinweis auf diesen Thread und der Bestellnummer, wir tauschen das defekte Bricklet dann aus. Entschuldigung für die Probleme!

Anderen Port und anderes Bricklet-Kabel (tauschen mit einem der Kabel der funktionierenden Bricklets) hast du schon probiert?

Es gibt soweit ich weiß keine allgemeinen Probleme zwischen HAT und CO2 Bricklet 2.0. Laufen im Brick Viewer denn Timeouts hoch? Sind die Firmwares alle auf dem neusten Stand (HAT und CO2 2.0)?

Ein paar Fragen dazu: Kannst du einmal ein Foto von deinem Aufbau machen? Sind die Firmwares alle aktuell? Wie lange laufen die Sensoren schon? Und auf welche Sampling Rate sind die Humidity Bricklets konfiguriert? Ich nehme an auch auf 1 SPS? Generell für die bestmögliche Genauigkeit: Alle Humidity Bricklet 2.0 auf den neuesten Firmware-Stand bringen Sample Rate auf SPS_01 (5) konfigurieren. Aufbau für einen längeren Zeitraum laufen lassen

I wrote a small test program (in Python) to try this out and i can't reproduce it. There is no magnetometer data in the "SENSOR_FUSION_ON_WITHOUT_MAGNETOMETER"-mode (mode 2). Which is expected. With all other modes there is magnetometer data. #!/usr/bin/env python3 # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "6KSLMN" import time from tinkerforge.ip_connection import IPConnection from tinkerforge.brick_imu_v2 import BrickIMUV2 def cb_all_data(acceleration, magnetic_field, angular_velocity, euler_angle, quaternion, linear_acceleration, gravity_vector, temperature, calibration_status): print("Magnetic Field [X]: " + str(magnetic_field[0]/16.0) + " µT") print("Magnetic Field [Y]: " + str(magnetic_field[1]/16.0) + " µT") print("Magnetic Field [Z]: " + str(magnetic_field[2]/16.0) + " µT") print("") if __name__ == "__main__": ipcon = IPConnection() imu = BrickIMUV2(UID, ipcon) ipcon.connect(HOST, PORT) imu.register_callback(imu.CALLBACK_ALL_DATA, cb_all_data) imu.set_all_data_period(250) imu.set_sensor_fusion_mode(imu.SENSOR_FUSION_OFF) print('Sensor Fusion Mode: SENSOR_FUSION_OFF') time.sleep(1) imu.set_sensor_fusion_mode(imu.SENSOR_FUSION_ON) print('Sensor Fusion Mode: SENSOR_FUSION_ON') time.sleep(1) imu.set_sensor_fusion_mode(imu.SENSOR_FUSION_ON_WITHOUT_MAGNETOMETER) print('Sensor Fusion Mode: SENSOR_FUSION_ON_WITHOUT_MAGNETOMETER') time.sleep(1) imu.set_sensor_fusion_mode(imu.SENSOR_FUSION_ON_WITHOUT_FAST_MAGNETOMETER_CALIBRATION) print('Sensor Fusion Mode: SENSOR_FUSION_ON_WITHOUT_FAST_MAGNETOMETER_CALIBRATION') time.sleep(1) ipcon.disconnect() Output: Can you post a small example program that we can use to reproduce the problem?

Ich hab jetzt einen Aufbau mit folgendem Testcode hier laufen (5V an Kanal 0 und 12V an Kanal 1 angeschlossen): #!/usr/bin/env python3 # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "Mj8" from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_industrial_dual_analog_in_v2 import BrickletIndustrialDualAnalogInV2 import time if __name__ == "__main__": ipcon = IPConnection() idai = BrickletIndustrialDualAnalogInV2(UID, ipcon) ipcon.connect(HOST, PORT) idai.set_sample_rate(idai.SAMPLE_RATE_4_SPS) while True: v1 = idai.get_voltage(0) v2 = idai.get_voltage(1) if not (4950 < v1 < 5500): print(f"V1: {v1}") if not (11900 < v2 < 12100): print(f"V2: {v2}") time.sleep(0.25) ipcon.disconnect() Ich lasse das jetzt erstmal ein paar Tage laufen um zu sehen ob ich es nicht doch irgendwie reproduzieren kann. Wenn du irgendeine bestimmte Einstellung oder Abfragerate oder so hast mit dem das Problem öfter auftritt sag Bescheid.

Echt komisch. Das wechseln auf 2Hz ruft die "SetSampleRate"-Funktion auf. Diese speichert die neue Sample Rate und setzt einen bool Wert auf true. Beim nächsten "Tick-Durchlauf" wird das erkannt und die neue Sample Rate wird auf dem ADC konfiguriert. Ich hatte jetzt eingebaut dass das Bricklet regelmäßig die konfigurierte Sample Rate vom ADC ausliest und diese mit der zwischengespeicherten vergleicht um diese neu zu schreiben falls notwendig (setzt auch einfach den bool Wert auf true, um sicher zu stellen dass es sich genauso verhält). Das deutet für mich jetzt darauf hin dass der ADC zwar noch die korrekte Konfiguration hat, allerdings irgendwie anders aus dem Tritt kommt. Das neu setzen der Sample Rate führt dann aber wieder zur Besserung. Ich mache mir nochmal Gedanken, leider kann ich das überhaupt nicht reproduzieren hier 😐.

Anbei die Firmware zum Testen. Ich bin gespannt ob das jetzt einen Unterschied macht! industrial-dual-analog-in-v2-bricklet-firmware-2.0.6-beta.zbin