lapawa

Die ungenaue Frequenzmessung kann ich bestätigen. Ich bekommen immer einen Wert von um die 49.6Hz. Ein weiterer Grund für ein Redesign des Energy Monitor Bricklets. Habe in diesem Thread von Problemen mit dem Bricklet berichtet die ein Reset des Stapels verursachen.

Das ist nicht mehr nötig. Danke jedoch für das Angebot. Ich habe das Energy Monitor Bricklet nun vor den EPN510 angeklemmt. Damit wird dessen Spannung nicht mehr abrupt weggenommen und der Stapel läuft stabil. Was ich mir aber wünschen würde, wäre ein überarbeitetes Energy Monitor Bricklet was besser geschützt bzw. isoliert ist. Denn wenn man sich den Schaltplan so anschaut, sieht es so aus, als dass der Transformator für die Spannungsmessung direkt über die Widerstände R7,9,&11 an dem Operationsverstärker vorbei auf den analogen Eingang des Controller geht. Gruß

Die Preisfrage lautet nun: Wie bekomme ich das Energy Monitor Bricklet geschützt? Ich habe an den Eingang für den Spannungstransformator eine Suppressordiode vom Typ BZW06-13B angebracht. Hilft aber leider auch nicht. @photron Irgendeine Idee? Kannst Du das Problem nachstellen?

Der Spannungstransformator ist 'hinter' dem EPN510 und wird daher mit abgeschaltet. Dies induziert wie bei jeder Spule eine hohe Spannung und legt den Stapel lahm.

In der Zwischenzeit habe ich das Dual Relay Bricklet gegen ein Industrial Dual AC Relay Bricklet getauscht. Das ist ja genau für diese Aufgabe gemacht. Damit bekomme ich jedoch das gleiche Verhalten. Dennoch konnte ich das Problem an einer anderen Stelle weiter einkreisen. Wenn ich vom Energy Monitor Bricklet den Spannungstransformator entferne tritt das Problem nicht mehr auf. Also wird meiner Meinung nach eine zu hohe Spannung vom Transformator in dessen Bricklet gestreut und damit der gesamte Stapel gestört. Ich werde eine Schutzbeschaltung mit Varistor vorschalten und berichten.

* Es tritt nur auf wenn der EPN510 angeschlossen ist. Habe noch folgendes ausprobiert: * Verkabelung strickt getrennt. * Wechsel vom 24V Netzteil, welches neben dem EPN510 am der selben Phase hängt, zu USB Versorgung vom Notebook Hat alles nicht geholfen. Das Problem muss bein Einschalten passieren. Denn selbst der Monoflop von 250ms wird teilweise nicht zurückgenommen! Ich gehe auch von einem EMV Problem bein Einschalten aus.

Hallo ich verwende eine Dual Relay Bricklet um 230 VAC zu schalten. Der Verbraucher ist eine hager EPN510. https://hager.com/de/katalog/produkt/epn510-fernschalter-1s-230v-ac-16a Mein Stapel wird von einem 24Volt DC Netzteil per Step-Down Power Supply versorgt. Dies sollte somit stabil sein und keine Probleme verursachen. Kommuniziert wird per Ethernet Master Extension. Kann mir jemand erklären warum der Stapel immer bei einem Monoflop von 250ms in den Reset geht? Hier noch eine Auflistung meines Stapels von oben nach unten: Ethernet Extension Energy Monitor Bricklet Dual Relay Bricklet Master Brick 2.1 Bricklet Segment Display 4x7 Bricklet IO-4 Bricklet 2.0 Segment Display 4x7 Bricklet Industrial Digital out 4 Bricklet 2.0 Master Brick 2.1 Step-Down Power Supply Vielen Dank lapawa

Hallo, ich werde die beiden Bricklets Industrial Digital Out 4 Bricklet 2.0 und Industrial Quad Relay Bricklet 2.0 verwenden um mit 24V DC das Eltako Relais ESR12Z-4DX-UC (pdf) zu schalten. Welche Schutzmaßnahmen sollte ich ergreifen um die Bricklets vor der induzierten Spannung beim Öffnen der Kontakte zu schützen? Ich dachte hier an eine Zenerdiode als Schutzdiode (wikipedia) pro Ausgang. Was empfiehlt Tinkerforge an dieser Stelle? Gruß und Danke schonmal Lapawa

Hallo, sieht nach einem sehr interessantem Projekt aus. Ich verfolge deine Bemühung schon eine Weile. Eine Idee hätte ich dazu auch noch. Die neuen 7poligen Bricklets bieten per API die Möglichkeit Kommunikationsfehler zu erfragen. Vielleicht kannst Du das 'Sterben' eines Bricklets darüber vorzeitig erkennen. BrickletOneWire.get_spitfp_error_count() Gruß

Ok. Danke für die Ausführung. So etwas hatte ich schon vermutet. Des weiteren könnte das Timing ein Problem sein. Ich weiß nicht, ob die vier Ausgänge exakt zum selben Zeitpunkt geschaltet werden. Und damit wäre auch der Einschaltstrom nicht auf alle vier Ausgängen aufgeteilt. Ist schon richtig. Das Ganze wäre zu sehr auf 'Kante genäht'. Entweder ich finde einen passenderen Verbraucher oder ich wechseln auf das 'Industrial Quad Relay Bricklet 2.0' Bricklet.

Verwendest Du evtl. Bricklets mit dem 10poligen Stecker am HAT? Das wäre nämlich nicht zu einander kompatibel.

Ok. Danke für die Antworten. Für Ersteres werde ich den Stack dann kurz stromlos schalten.

Finally solved! Es war ein reines Problem mit der Hardware. Hier wurde mit zu viel Lötzinn gearbeitet. Durch das ETH/USB HAT wurde ausgerechnet Pin 17+21 also SPI-MISO und SPI-MOSI gebrückt! Siehe Bild: Also Klecks entfernt und alles ist wieder gut! Danke für die rege Teilnahme an der Problemlösung. Endlich kann es mit dem Projekt weitergehen. Ich freue mich auf einen Master Brick mit 7poligem Stecker. Die sind wenigstens auf Funktion geprüft und ersparen mir zeitraubenden Fehlersuchen dieser Art.

Hallo, ich verwende das HAT Brick am Raspberry Pi und lasse ihn regelmäßig für eine halbe Stunde im Sleep Modus verweilen. Danach wacht er auf, sammelt ein paar Messwerte verschickt diese und legt sich wieder schlafen. a) Ist es möglich diesen Sleepmodus per Taster/Pin frühzeitig zu beenden? Ich möchte den Stack manuell bei Bedarf aufwecken. Eine zweite Frage die ich zum HAT habe b) Wieso habt ihr die erzeugte 5,3 Volt Spannung nicht herausgeführt? Das wäre sehr praktisch, sie wie bei dem Step Down Power Supply zur Verfügung zu haben. Gruss

Hallo, ich habe ganz ähnliche Probleme mit dem HAT Zero. Welche Meldungen siehts Du denn im log file vom brickd daemon brickd? Zu finden unter /var/log/brickd.log Du kannst den daemon per Eintrag in der Konfigurationsdatei /etc/brickd.log in den Debug Mode versetzen. Den Daemon anschliessend per 'sudo systemct restart brickd.service' neu starten. Das ergibt dann noch mehr Details im Log file. Gruß EDIT: Das Problem hat sich bei mir gelöst. Ein weiteres HAT hatte auf den SPI Leitungen einen Kurzschluss verursacht. https://www.tinkerunity.org/topic/5985-brickd-liefert-fehlermeldungen-am-laufenden-band/

Nochmal einen Schritt zurück bitte. Als Referenzaufbau habe ich einen RPiZero WLAN mit Zero HAT und regulärem Raspbian 10 und brickd-2.4.3 aus dem deb Paket verwendet. Also der einfachste denkbare Aufbau, ohne USB/Ethernet HAT zwischen Zero HAT und Raspberry Pi. Komplett andere Hardware. Sogar ein zweites Zero HAT. Konzentrieren wir uns besser auf diesen Aufbau. Hier bekomme ich nämlich die selben Fehlermeldungen. Details vom Raspbian: brickd.log: Und nochmal mit brickd im debug logging: Die ca. 1000 Frame Error Meldungen scheinen nur nach eine Kaltstart aufzutauchen. Wenn ich nur das Raspbian oder den brickd neu starte bleiben sie aus. ABER: brickv zeigt die Komponenten an!

Ich habe es mal umformuliert: "Ein Stapel gleicher Art funktioniert in einem anderen Projekt ganz prima." Die Stromvesorgung ist es nicht. Testweise versorge ich den Stapel mit einem kurzen Kabel (10cm) am 5V Ausgang eines Step-Down Power Supply. Dieser meldet mir per brickv eine Stromaufnahme von 230mA. Die USB/Eth Adapterplatine funktioniert sogar ohne RPi Header. Ich habe sie testweise nur mit einem USB Kabel verbunden und weit weg vom RPi betrieben. USB Hub und Ethernet funktionieren bei diesem Aufbau. Das Zero HAT jedoch nicht! Die Fehlemeldungen vom brickd variieren auch. Ein paar Beispiele:

Besten Dank für deine Ausführungen. Du hast mich mit dem Hinweis auf die Hardware auf die Lösung gebracht! Auch mit einem auf einer anderen Hardware (RPi Zero W + Zero HAT )funktionierendem Raspbian Linux bekomme ich keine Bricklets angezeigt. Also muss es an der Hardware liegen. Mein Ethernet Adapter scheint das Problem zu verursachen. Ich verwende dieses Modell: https://www.waveshare.com/wiki/ETH/USB_HUB_HAT Schematics: https://www.waveshare.com/w/upload/0/08/ETH_USB_HUB_HAT.pdf Und obwohl das Platinchen einen USB Hub besitzt an dem auch der Ethernet Chip hängt, macht es mir Probleme mit den SPI Leitungen. Denn wenn ich den Layer entferne und einen anderen Ethernet USB Adapter anschließe funktioniert der brickd wie erwartet! Mein Stapel sieht so wie auf dem Bild aus. Das ist meine interim Lösung bis der 7polige Stecker am Master Brick verfügbar ist. Ein Stapel gleicher Art funktioniert in einem anderen Projekt ganz prima.

Hallo, ich möchte einen 24Volt Verbraucher mit 100mA schalten. Da ein einzelner Ausgang des Industrial Digital Out 4 Bricklet 2.0 Bricklets nur 25mA abgeben kann, frage ich mich, ob ich diese zusammenschalten darf und sich die möglichen Ströme dabei addieren. Gruss Tim

Ein Wechsel auf 250MHz Core Frequenz hat bei beiden brickd ( v2.4.1 & v.2.4.3 ) nicht geholfen!

Ich habe noch ein paar Angaben zu den Taktfrequenzen des RPi Zero gesammelt: vcgencmd vchiq_test vcmailbox vconfig vcsmem # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1000000 # vcgencmd measure_clock arm frequency(48)=1000104000 # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance # vcgencmd measure_clock core frequency(1)=400000000

Die version 2.4.1 hat mir nur ein Stückchen weitergeholfen. Die Fehlermeldungen sind weg. Eine Verbindung per brickv funktioniert. Jedoch werden weder brick noch bricklets im brickv angezeigt. Diesmal habe ich zusätzlich zum Debug Log noch eine Strace Auszug erstelt. Was mir auffällt ist, dass brickd ständig write Zugriffe auf libusb ausführt. Und dies obwohl das HAT per SPI mit den Bricklets kommuniziert. dass die GPIO Exports beim Beenden von brickd nicht wieder beim Kernel abgemeldet werden. Zugriff auf die Zeitzonen datei /etc/localtime funktioniert nicht. Da sie nicht existiert. openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Ist dies ein Problem für brickd? Das HAT wird erkannt: openat(AT_FDCWD, "/proc/device-tree/hat/product_id", O_RDONLY) = 17 read(17, "0x085d", 6) = 6 close(17) 2021-01-04 18:35:46.490397 <D> <bricklet.c:182> Found product_id "0x085d" in device tree, using pre-configured HAT Zero Brick setup Die GPIOs für die Chip Select Signale der einzelnen Parts A-E werden beim Kernel als export angemeldet openat(AT_FDCWD, "/sys/class/gpio/export", O_WRONLY) = 18 write(18, "27", 2) = 2 close(18) = 0 openat(AT_FDCWD, "/sys/class/gpio/gpio27/direction", O_WRONLY) = 18 write(18, "out", 3) = 3 close(18) = 0 openat(AT_FDCWD, "/sys/class/gpio/gpio27/value", O_WRONLY) = 18 write(18, "1", 1) = 1 close(18) = 0 openat(AT_FDCWD, "/sys/class/gpio/gpio27/value", O_WRONLY) = 18 Meine Frage hierzu: Kann der Kernel SPI Treiber das CS Timing nicht besser selbst erledigen? Clock und MasterOut kommt ja auch von dort, oder? Debug Log: Log bei einer Verbindung vom brickv: strace:

Ich hatte mal die selbe Frage gestellt... Zur Überbrückung der Wartezeit bis die Bricks mit neuen Stecker verfügbar sind, habe ich mich für eine RaspberryPi Zero Lösung mit HAT Zero Brick entschieden. Kleines Linux, Ethernet per USB oder WLAN inklusive. Variante Ethernet: RPi Zero (ohne WLAN/BT) 5EUR Ethernet HAT 10 EUR HAT Zero Brick 15EUR Variante WLAN: RPI Zero W 11 EUR HAT Zero Brick 15 EUR Dieser Stack liefert zu einem attraktiven Preis vier Bricklet Ports im lokalen Netzwerk.

Hallo, derzeit bin ich dabei per buildroot (https://buildroot.org/) ein Embedded Linux Image für den Raspberry Pi Zero zu bauen. Das Image wird sehr minimalistisch und erstmal nur brickd beinhalten. Die eigentliche Applikation wird remote gestartet. Für die Anschlüsse der Bricklets verwende ich Tinkerforge HAT Zero 1.0 und einen RPi Zero mit USB Ethernet Schnittstelle. Wenn ich brickd starte, bekomme ich in einer rasenden Geschwindigkeit immer wieder diese Fehlermeldung: Wie kommt es zu diesen Meldungen? Was kann ich tun? Ist Port E der Port vom HAT selbst? Denn Bricklet Anschlüsse hat das HAT Zero nur vier, also bis Port D. Besten Gruß und vielen Dank für jegliche Hilfe. So sieht die brickd.conf aus (grep -v \# /etc/brickd.conf|sort): Und die Ausgaben von brickd --debug:

Hallo, für ein 'Dual Relay Bricklet' bräuchte ich einen Default Zustand, der wieder eingenommen wird sobald das Steuerprogramm abbricht, oder die Kommunikation zum brickd unterbrochen wird. Mein Problem ist, dass die Relais im letzten Zustand bleiben, auch wenn das überwachende Programm nicht mehr funktioniert. Vielleicht könnt ihr die Firmware um eine solche Funktion erweitern. Ich denke dass hier ein Watchdog ausreichen würde um die Relais wieder in den Ruhezustand zu bringen. Ich habe gesehen, dass das HAT Brick so eine Funktion mitbringt. Eine Integration in ein Master Brick käme mir aber deutlich entgegen.. Besten Gruß Tim