borg

Wie sehen denn die Bibliotheken genau aus? rufen die sowas wie send/recv auf und du kannst das send/recv selbst implementieren oder nutzen sie direkt /dev/ttyXXX vom Linux? Ersteres sollte sich relativ einfach mit einem Wrapper auf die TF API umbiegen lassen. Falls es letzteres ist müsstest du ein Script schreiben welches so eine serielle Schnittstelle simuliert und nach hinten raus mit dem Bricklet spricht. In fertig haben wir sowas aktuell leider nicht, wäre aber eine coole Sache .

Die Niederschlags-Angabe in mm bezieht sich auf die Zeit seitdem die Batterie drin ist. Um den Niederschlag im Zeitraum eine Stunde zu bestimmen nimmst du den aktuellen Wert und speicherst ihn, holst dir dann eine Stunde später einen neuen Wert und ziehst den gespeicherten davon ab. Das Ergebnis ist der Niederschlag in der letzten Stunde. So kannst du Problemlos den Niederschlag in beliebigen Zeiträumen bestimmen. Die Windgeschwindigkeit ist die aktuelle Windgeschwindigkeit wenn das Datenpaket verschickt wird und die Windböengeschwindigkeit ist die maximale Windgeschwindigkeit seit dem letzten Datenpaket (es wird ca. 1x pro Minute ein Paket verschickt).

Well, if no tag is there you will get into the state STATE_REQUEST_TAG_ID_ERROR and you have to run requestTagID from there again. I attached a working program that runs in a loop. Please note: All of the steps can create an error. For example: What happens if someone removes the card after the authentication but before the page was read? In this case you probably want to scan for a tag again. You have to handle all of these states if you want it to be robust. ExampleScanForTags.java

See attachment. Edit: Dont forget to change the UID back to yours. ExampleScanForTags.java

Hi, it works after a few tweaks: olaf@pc2:~/build20/java$ javac -cp Tinkerforge.jar:. ExampleScanForTags.java olaf@pc2:~/build20/java$ java -cp Tinkerforge.jar:. ExampleScanForTags Press key to exit Found tag of type 0 with ID [6d b8 97 f7] Ready page ready [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] The Problem with your code is that you call "nr.requestTagID(currentTagType);" every time that the Bricklet is in idle state. But it goes into idle state after it reaches any of the new states. So you call requestTagID in a loop. For me it started to work immediately after i commented out the if(idle) {...} block.

Wir ersetzen ja aktuell alle Bricklets durch neue Varianten (Umstellung von EEPROM auf Co-Prozessor). Die neuen Bricklets werden alle die neue API bekommen. Das dauert also noch ein wenig bis alles umgestellt ist (ungefähr bis Ende des Jahres).

Looking at your code, you do: nr.authenticateMifareClassicPage(5, (short) 0,keys); nr.requestPage(5); short[] data=nr.getPage(); System.out.println(Arrays.toString(data)); I think you should first call nr.authenticateMifareClassicPage(5, (short) 0,keys); then in the state STATE_AUTHENTICATING_MIFARE_CLASSIC_PAGE_READY call nr.requestPage(5); and then in the state STATE_REQUEST_PAGE_READY call short[] data=nr.getPage(); System.out.println(Arrays.toString(data)); Does it work when you do that?

Also die Funktion sollte auf jeden Fall aufgerufen werden. Wenn du zum Testen ein print in die "cb_rotary2_press"-Funktion machst, kommt diese print wenn du den Knopf drückst oder nicht?

Strange, do you now what kind of mifare classic tag you have? Is it something special? Do you have a second one you could test with?

Wenn du den Knopf drückst sollte per Callback die Funktion "cb_rotary2_press" aufgerufen werden. Wird die nicht aufgerufen? Die Funktion ist nicht im Code.

If you comment in the "//System.out.println(state);", do you get any new state after you call authenticateMifareClassicPage()? Or no new state at all?

I think if you call getPage you will get the page from the last successful read. So if you call getPage in the REQUEST_TAG_ID_READY state, you will not actually read a new page. You have to first authenticate, then request the page and then you can call getPage.

That depends on the specific tag that you are using. There are tags that have a read-only flag and if you set it the tag is not writeable anymore.

Das sieht soweit alles gut aus! Eventuell noch ein Montageplatte und Befestigungskits wenn der Brick, das Bricklet und das RPi irgendwo verbaut werden sollen?

Firmwares: DC Brick 2.3.8, IMU Brick 2.3.8, Master Brick 2.4.9, Servo Brick 2.3.7, Silent Stepper Brick 2.0.7, Stepper Brick 2.3.9 Unterstützung für Isolator Bricklet hinzugefügt Co-MCU Bricklet Error-Behandlung verbessert Download: DC Brick, IMU Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick

Firmwares: DC Brick 2.3.8, IMU Brick 2.3.8, Master Brick 2.4.9, Servo Brick 2.3.7, Silent Stepper Brick 2.0.7, Stepper Brick 2.3.9 Add support for Isolator Bricklet Improve Co-MCU Bricklet error handling Download: DC Brick, IMU Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick

You can use the Silent Stepper Brick. With regards to the resolution: I am not sure. I think that 0.1mm is a bit too small. There will always be some slackness and backlash in the cart and also the belt has some play etc. I don't think you will be able to drive with 0.1mm accuracy. Maybe you can find some sturdy pre-build linear rail with a stepper motor attached. Something like this: http://www.haydonkerk.de/184/Produkte/Linearschienen,-Fuehrungen-und-Splines/Motorisierte-RGS-RGW/RGW06-Size-17.htm (there is no price, so probably super expensive). Maybe you can find something comparable on aliexpress or similar.

Kurz in den Source Code geschaut: response->min = callback_value->threshold_min_user; response->max = callback_value->threshold_min_user; Jep, offensichtlich... Danke für den Hinweis, ist gefixt: https://github.com/Tinkerforge/bricklib2/commit/701696f0ddc435d30751382ecef112517ebe9119 Ich werde im Laufe der Woche die neuen Firmwares veröffentlichen, das betrifft jetzt natürlich alle Firmwares mit den neuen Standard-Callbacks .

It is not restricted to anything, you can calibrate it with any unit you want. During calibration when you put 100g on it, just tell it that you put 1000g on it. Now the unit is 1/10g. But there is a lot of noise in the 24 bits, so you will have to average for some period to get a stable value.

Das ist echt zum Kotzen mit diesen Funksteckdosen-Anbietern. Wir hatten ursprünglich bei uns im Shop die ELRO 440. Dann waren die auf einmal oft nicht verfügbar und wir haben stattdessen die (damals baugleichen) mumbi m-FS300 verkauft. Da wir die in den letzten Monaten schwer bekommen konnten, verkaufen wir jetzt "PFS" (Eigenmarke von Pollin). ELRO hat damals die neuen Funksteckdosen wenigstens unter einem anderen Namen verkauft, mumbi scheint jetzt einfach unter gleichem Namen die Steckdosen ausgetauscht zu haben... ELRO 440, (alte) m-FS300 und PFS sind übrigens alle vom gleichen OEM Hersteller in China... Die nutzen die gleiche Form und die gleiche Leiterplatte etc. Es wird immer nur hinten das "Namensschild" ausgetauscht. Da gibt es also keine Qualitätsunterschiede.

What exactly do you mean by "interrupt from any of the inputs"? There should be no functionality lost with the new API. If you call set_all_input_value_callback_configuration with period = 1ms and value_has_to_change=True, the CALLBACK_ALL_INPUT_VALUE will be called any time that there is any change on one of the inputs. If you only want this for one channel you can use set_input_value_callback_configuration.

Mh, hab gerade kurz online geschaut. Sieht deine Fernbedienung so aus wie in dem ersten Bild oder so wie in dem zweiten? Für mich sieht das so aus als würde mumbi jetzt eine andere Funksteckdosen unter dem gleichen Namen (m-FS300) verkaufen... Hast du hinten einen DIP-Switch drin zum einstellen oder ist das selbstlernend laut Anleitung?

I just released IMU Brick V2 firmware 2.0.13 with the new parameter. Call set_sensor_fusion_mode with 3. The new constant will be available with the next Bindings release. Changes: https://github.com/Tinkerforge/imu-v2-brick/commit/cb5d24238a7e403ba1cb981c574e093d63176ebd https://github.com/Tinkerforge/imu-v2-brick/commit/2d1e81f59339a4ea83eb09d3fe3dbc0a8b822366 https://github.com/Tinkerforge/generators/commit/f4f2a0d3b1660fb45aaf19d65b9bf1a51a7dfbe9 I tested with this small script and played around in Brick Viewer. I think i can see the difference between the two modes. #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "6xEivJ" # Change to your UID from tinkerforge.ip_connection import IPConnection from tinkerforge.brick_imu_v2 import BrickIMUV2 if __name__ == "__main__": ipcon = IPConnection() # Create IP connection imu = BrickIMUV2(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd imu.set_sensor_fusion_mode(3) print(imu.get_sensor_fusion_mode())

Firmware: IMU Brick 2.0 2.0.13 Add support for fusion mode without fast magnetometer calibration Download: IMU Brick 2.0

Firmware: IMU Brick 2.0 2.0.13 Unterstützung für Fusion-Modus ohne schnelle Magnetometer-Kalibrierung hinzugefügt Download: IMU Brick 2.0