borg

As far as i understand it you have to rename the ".c" files to ".cpp" with VS, otherwise VS will interpret them as C89 files. Did you do that? http://www.tinkerforge.com/en/doc/Software/API_Bindings_C.html#visual-studio

Entschuldige für die späte Antwort! Wenn du etwas implementieren möchtest was über die Nagios-Unterstützung im Brick Viewer hinaus geht ist es vermutlich am einfachsten das direkt über eine eigene Nagios-Konfiguration zu machen. Ich würde die check_tinkerforge.py kopieren und darauf aufbauen. Deine eigene Konfiguration und die Einstellungen im Brick Viewer können ja Problemlos parallel laufen. Eine parametrisierte Programmierung über den Brick Viewer wäre natürlich hübsch, stelle ich mir aber sehr Aufwändig vor. Dies direkt über eine .cfg und eine kleine .py zu machen ist mit Hilfe der Beispiele die dafür bereits existieren vergleichsweise einfach machbar .

Es liegt zwar keine SPI-Hardwareeinheit auf den Bricklet-Anschlüssen, es stehen aber genügend digitale Datenleitungen zur Verfügung um SPI zu "bitbangen". Bricklets die SPI nutzen: * Industrial Analog Out Bricklet * Industrial Dual Analog In Bricklet * NFC/RFID Bricklet * PTC Bricklet * Remote Switch Bricklet Da sollte also genug Beispielcode vorhanden sein auf dem man aufsetzen kann. Siehe z.B. hier https://github.com/Tinkerforge/industrial-analog-out-bricklet/blob/master/software/src/analog-out.c die Funktionen * spibb_transceive_byte * dac7760_read_register * dac7760_write_register

Das kommt ganz drauf an. Möchtest du eine Funkstrecke zwischen zwei Stacks aufbauen (wie damals mit der Chibi Extension)? In dem Fall müsstest du eine Master Extension bauen. Ansonsten kannst du ein Brick oder Bricklet machen. Die Frage ist dann: Passt die Firmware dafür in 4kb Flash mit 256 byte RAM? Falls ja wäre ein Bricklet das richtige. Falls nein muss es ein Brick werden . SPI/I2C Kommunikation mit einem Bricklet ist kein Problem, das machen die meisten unserer Bricklets. Ich hab gerade ganz kurz ins Datenblatt geguckt: Das sieht definitiv so aus als könnte man es per Bricklet steuern. Darf ich fragen was der eigentliche Anwendungszweck ist? RFID?

Wir arbeiten gerade noch ein einem anderen kleinen Bugfix in der SPI-Kommunikation den ich in das Release mit reinmachen möchte. Wenn das komplett durchgetestet ist gibt es das 2.3.2 Release .

Die aktuelle Master Brick Firmware unterstützt kein Hotplug, siehe diesen Thread hier für mehr Infos dazu: http://www.tinkerunity.org/forum/index.php/topic,2580.0.html Im selben Thread gibt es auch eine master-brick-2.3.2-beta2.bin Firmware (hier: http://www.tinkerunity.org/forum/index.php/topic,2580.msg18819.html#msg18819). Damit sollte Hotplug wieder gehen . Die Firmware wird in den nächsten paar Tagen auch offiziell veröffentlicht.

Was hast du denn für einen Aufbau? Den gleichen wie in dem anderen Thread? Falls ja probier es mal mit nur einem Master Brick und dem NFC/RFID Bricklet, nicht das es auch mit der Spannungsversorgung zusammenhängt. Du könntest auch überprüfen ob evtl einer der Pinne im Bricklet Stecker (vom Bricklet oder vom Master) krumm ist und dadurch ein Kurzschluss o.ä. entsteht? Ansonsten definiert der NFC Standard eine maximale Reichweite von 10cm. Die Antenne ist dafür ausgelegt diese exakt zu erreichen. Bei unseren Tests mit den Karten und Schlüsselanhängern funktioniert das auch mit 9cm Entfernung noch. Bitte schreibe eine Email mit der Bestellnummer an info@tinkerforge.com falls die beiden Vorschläge oben keine Verbesserung bringen. Wir tauschen das Bricklet dann aus.

So, hab das gerade implementiert: https://github.com/Tinkerforge/imu-brick/commit/566014f24c835517b469dd8fa4d10f44bbfcf022 Bitte einmal die Firmware im Anhang testen . Die "Acceleration Range" hat die möglichen Parameter * 0 = +-2G * 1 = +-4G * 2 = +-8G imu_brick_2_3_1_beta1.bin

Das ist komisch. Kannst du überprüfen ob die Firmwares der Bricks alle aktuell sind?

Wenn der Stack über USB versorgt wird, sind Stack Voltage und Stack Current 0. Diese Anzeige bezieht sich nur auf die Versorgung über eine Step-Down Power Supply. Wir haben dort zwar einen geringen Pull-Down in der Leitung, da die Pinne allerdings ansonsten "Floating" sind, kannst du da leider immer etwas mehr oder weniger beliebiges angezeigt bekommen (die Wahrscheinlichkeit wird größer, desto größer dein Stapel ist). Das ist definitiv nicht schön, war aber schon immer so und hat nichts mit dem Brick Viewer zu tun .

Die genaueste Ausgabe dafür würde das Industrial Dual 0-20mA Bricklet liefern (für den 4-20mA Ausgang). Damit solltest du bei 18-Bit Auflösung eine Genauigkeit von ~0,15% erreichen. Strommessungen sind Grundsätzlich sowieso genauer, da es keinen Spannungsabfall aufgrund von Leitungslänge oder Übergangswiderständen o.ä. gibt.

Das Dust Detector Bricklet gibt die Staubdichte in µg/m³ zurück. Es misst dabei Partikel >= ~0.5µm. Dazu zählt z.B. Zigarettenrauch, Smog, Hausstaub, Blütenstaub usw. Einen genauen Termin für die neuen Bricklets haben wir noch nicht, das hängt auch davon ab wieviele Prototypen wir noch brauchen. Wir sind noch nicht zu 100% mit der Hardware der neuen Bricklets zufrieden .

Was genau möchtest du denn mit 1ms Genauigkeit messen? Ein Linux mit PREEMPT_RT Patch kann auch keine Wunder vollbringen. Was du damit machen kannst ist sowas wie: "Setze einen Timer der in exakt 100ms eine Funktion aufruft." Ein Aufruf von "get_voltage" (o.ä.) wird dadurch nicht auf einmal Realzeitfähig, dazu müsste alles was durch den Aufruf ausgelöst wird eine definierte Ausführungszeit haben (die Bindings, der SPI Kernel Treiber, der Brick Code).

Diese Funktionalität ist in der Tat noch nicht implementiert, hatte ich gar nicht mehr auf dem Schirm. Ich hab es mir auf die TODO-Liste geschrieben, komme da aber frühestens am Ende der Woche zu das implementieren. Melde mich dann hier mit einer Beta-Firmware .

Mh, TextBox scheint mit mono unter ARM wirklich Probleme zu machen, siehe z.B. hier: https://www.raspberrypi.org/forums/viewtopic.php?t=11634&p=478459 Wenn ich das da im Thread richtig sehe sind die Probleme in der letzten GIT Version von mono gefixt, d.h. das Problem wird wahrscheinlich verschwinden wenn es davon ein Release gibt und wir mono aktualisieren auf dem RED Brick.

Ich würde erwarten das die C#/VB.NET Bindings einfach funktionieren unter Windows 10 IOT. Wie wir den brickd drauf bekommen ist eine gute Frage . Den werden wir mit Visual Studio neu kompilieren müssen für Windows 10 IOT: https://ms-iot.github.io/content/win10/SetupPC.htm Aktuell haben wir noch keines von den neuen RPis hier, ich werde aber mal eins bestellen. Dann können wir uns das angucken.

I don't think that this stack should make any problems regarding throughput. But it depends on the programs you intend to run with it, of course.

Ist vielleicht ein Pin krumm im Bricklet-Stecker (des Master Bricks oder des LCD Bricklets) und macht einen Kurzschluss sobald du das Bricklet anschließt?

Wo benutzt du das Modul? Im Zweifelsfall würde ich erstmal probieren an ein Fenster zu gehen um sicherzustellen das nicht einfach die Signalstärke nicht ausreicht.

brickv nutzt auch nur die Python Bindings, es gibt also kein Grundsätzliches Problem. Kannst du dein komplettes Programm hier posten? Hast du die UID angepasst? Anhand der Fehlermeldungen würde ich sagen du bekommst Parameter zurück die nicht zum Funktionsaufruf passen. Hast du vielleicht die UID des Master Bricks für die Bricklets genutzt? Die UID der Bricklets vertauscht?

Did you include the kicad-libraries git into the project? See the hardware paragraph here: https://github.com/Tinkerforge/industrial-dual-0-20ma-bricklet Every Bricklet has a hardware section with the KiCAD files for the Bricklet. But there is also a kicad-libraries git which contains all of the footprints and so on that are shared between Bricklets.

Der Client läuft lokal im selben Netzwerk? Oder soll die Verbindung übers Internet gehen? Wenn es im gleichen Netzwerk läuft sollte das Problemlos funktionieren. Falls es über das Internet geht musst du den Port 1099 auf deinem Router (Fritz Box?) zum RED Brick weiterleiten.

Right, there is no brickd to brickd protocol, you need to open a IPConnection per Ethernet Extension. The third connection is for GND, it will likely not work well if you don't connect GND.

Yes, exactly! With the Ethernet Extension you need 0 external instances of brickd. In case of Ethernet you connect directly to the IP of the Ethernet Extension. The Ethernet Extension itself provides brickd. No, you need 3 wires.

Wir haben noch ein paar alte Debug Bricks hier, wer unbedingt an rx/tx muss kann sich diesbezüglich bei uns melden. Jemand der einen 0-Ohm Widerstand runterlöten würde um ein Kabel anzulöten kann aber natürlich auch das Kabel direkt an einen Platine-zu-Platine Stecker löten (https://www.tinkerforge.com/de/shop/accessories/30-pin-btb-bottom-485.html). Ist dann auch günstiger als das Debug Brick . Den Schaltplan gibt es als PDF bei jedem Produkt in der Dokumentation unter Resources: https://github.com/Tinkerforge/debug-brick/raw/master/hardware/debug-schematic.pdf Das Layout selbst als PDF macht glaube ich keinen Sinn, dafür haben die Bricks zuviele Lagen. Da wir das Layout mit KiCad machen ist das aber kein Problem, das ist schließlich Freie Software: http://www.kicad-pcb.org/ API Dokumentation zu alten Hardware Versionen steht definitiv noch zur Verfügung, da haben wir noch nie etwas entfernt. Bilder zu alten Versionen (vor allem wenn sich die Funktionalität nicht geändert hat) würde ich nicht mit auf die Doku-Seite packen, das verwirrt eher. Da bei uns aber alles unter Versionskontrolle steht und öffentlich ist, sind alle Fotos usw. aber natürlich Verfügbar bei Bedarf: https://github.com/Tinkerforge/doc/tree/master/en/source/Images Produkte die neue Funktionalität bieten (wie z.B. das Analog Out 2.0 was es mit den neuen Bricklets gibt) bekommen sowieso eine komplett neue Produktseite.