borg

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

Sehr komisch. Ich verwende das Industrial Dual Analog In Bricklet 2.0 sogar gerade für ein Projekt wo ich länger Messungen mache und ich kann das definitiv nicht reproduzieren. Klingt ja so als würde das Bricklet (oder der ADC auf dem Bricklet) irgendwie seine Einstellung vergessen und dann entsprechend falsche Werte anzeigen die sich durch die Eingangsspannung aber noch beeinflussen lassen. Um zu sehen ob es das ist würde ich eine Firmware bauen die regelmäßig die Konfiguration zurück liest und auf Richtigkeit überprüft. Ich melde mich morgen im Laufe des Tages nochmal mit einer Firmware zum Testen.

Ich befürchte da können wir nichts gegen machen. Schwer zu sagen was da genau in der "Luftschnittstelle" passiert damit der NFC IC erkennt dass der Chip entfernt wurde. Die Erkennung wird auf jeden Fall direkt im IC gemacht und das Bricklet leiten dieses Event einfach nur weiter. Die Lösungsidee da mit einer Art Hysterese zu arbeiten ist wahrscheinlich der Weg.

Kannst du einmal schauen ob im Fehlerfall immer der exakt gleiche Wert übertragen wird und wenn ja welcher das exakt ist? Welche Spannung/welchen Spannungsbereich versuchst du zu messen?

Gibt das Bricklet in dem Fehlerfall genau -45V zurück? Oder irgendetwas krummes nahe an -45V? Ist die Firmware des Bricklets auf dem neuesten Stand? Ich hab gerade kurz in die Firmware geschaut, so auf Anhieb kann ich nichts finden was im Fehlerfall/Overflow o.ä. exakt -45V erzeugen könnte. Welche Spannung liegt denn in Wirklichkeit ca. an?

Werden denn exakt -12V angezeigt? Oder irgendein sich leicht wechselnder negativer Wert? Wenn das Problem das nächste auftritt, kannst du einmal ausprobieren im Brick Viewer das Software-Reset auszuführen? Beim Master-Brick gibt es oben rechts einen "Reset"-Button. Bei den alten Voltage/Current Bricklets kommuniziert der Master Brick ja noch direkt per I2C mit dem ADC auf dem Bricklet. Aktuell würde ich vermuten dass dort irgendwas schief geht oder sich aufhängt o.ä.

Creating a new BrickletThermalImaging object each time is not necessary (and it might slow down your program over time). The problem is that changing the configuration from temperature to high contrast (or back) can take several images. The lepton sensor has a sync mechanism and the Bricklet can not guarantee that it can sync within one image after the image transfer configuration is changed. I think the easiest solution for you would be to just use the temperature image and to create the high contrast image from it yourself. As an initial approximation you can scale the temperatures from temperature min/max in the image to 0-255 and show that (this is what the Brick Viewer does if you choose the temperature image).

Wir setzen bei dem Bricklet auf die "NfcLibrary" von NXP auf und diese unterstützt leider kein Typ 5. Langfristig steht das auf der Agenda, wir haben allerdings aktuell zu viele Projekte offen und leider keine Kapazität dafür über dort entweder auf eine andere Library umzusteigen oder das händisch zu implementieren.

Hard to say why you don't have the deive-tree, the easiest solution is probably to just configure it by hand, see here: https://www.tinkerforge.com/en/doc/Hardware/Bricks/HAT_Zero_Brick.html#compatibility-to-other-boards-and-images Add the lines from the documentation to your /etc/brickd.conf and turn spi interface on with raspi-config. Then the brickd doesn't have to configure anything by reading out the device-tree first and it should just work.

Grundsätzlich sind auf Grund des internen Aufbaus der Software der Bricks nur maximal 1000 Nachrichten pro Sekunde möglich (egal welche Schnittstelle). Zu den Fragen: 1) Der Master Brick muss bei dem Chip auf der Ethernet Extension nach neuen Daten pollen, daher geht da immer Zeit verloren, auch wenn keine Daten über Ethernet übertragen werden. Man müsste das exakte Szenario profilen um zu sehen warum genau 1/4 Datendurchsatz verloren geht in dem Fall. 2 und 3) Wenn die Ethernet Extension auf einem RED Brick sitzt wird diese immer vom Linux Kernel genutzt und nie direkt vom Brick Daemon. Der Durchsatz dabei hängt von vielen Faktoren ab, inkl. der CPU Last und wieviel anderes IO auf dem RED Brick gemacht wird usw. 4) Die meisten Nachrichten bekommst du über einen einzelnen Master Brick der an einen USB 3.0 Port angeschlossen ist.

Wenn du am Ende 12800 Datenpunkte nach einer Sekunde hast sind diese auch Äquidistant gemessen worden. Der KX122 misst nicht mehr als die eingestellte Frequenz und das Bricklet liest nichts doppelt. Wenn da zwischendurch Daten fehlen da diese nicht rechtzeitig verschickt werden konnten gibt es allerdings keine Aussage dazu an welcher Stelle diese genau Fehlen im Datenstrom.

Firmwares: RS232 2.0 Bricklet 2.0.4 Make sure there are no glitches on TX line during configuration change Download: RS232 2.0 Bricklet

Firmwares: RS232 2.0 Bricklet 2.0.4 Stelle sicher dass es keine Glitches auf TX gibt wenn die Konfiguration geändert wird Download: RS232 2.0 Bricklet

Bei mir läuft das Touchscreen immernoch... Vielleicht komme ich hier bei mir auf dem Schreibtisch zu oft dran und "resette" dadurch irgendeinen Zustand im Code oder im Touchscreen-Controller? Wie oft macht du denn etwas mit dem Display? Regelmäßig oder drückst du da nur alle paar Monate einmal drauf und dann hast du den Bug?