borg

Oh, da ist die Dokumentation in der Tat noch unfertig. Wird gefixt. Bei den neuen Bricklets gibt es "Streaming-Funktionen", diese sind nicht auf 64 Byte Größe beschränkt wie die normalen Funktionen, sondern können beliebige Datenmengen übertragen. Wenn du "Write" aufrufst mit einem char-Array der Größe 128 Byte (z.B.) ruft das intern 2x WriteLowLevel mit je 64 Byte auf. Die LowLevel-Funktionen kannst du ignorieren, die sind eigentlich nur für die interne Nutzung. Die Write/Read-Methoden verwenden ein char-Array und kein String, daher musst du ['t', 'e', 's', 't'] statt 'test' schreiben. Die Daten könnten ja auch Binärdaten sein mit Nullen dazwischen etc, dafür sind Strings nicht gut geeignet. Du kannst aber in deinem Programm mit Strings arbeiten und den String einfach in ein Array umwandeln bevor du die Write-Funktion aufrufst.

Sieht soweit gut aus. Um welchen Servo handelt es sich denn und wie ist er angeschlossen?

Die Methoden werden halt genauso generiert wie alle anderen Methoden auch. Wenn du das angehen möchtest müsstest du die entsprechenden Methoden in der config als "CoProcessorDevice-Function" kennzeichnen und der Generator könnte dann das Interface so bauen.

Ich bin mir nicht sicher ob ich deine Frage richtig verstehe. Du kannst ein Programm für das RED Brick schreiben welches sich Daten vom IMU Brick und GPS Bricklet holt und diese dann über ein RS232 Bricklet wieder ausgibt. Das gleiche Programm kannst du aber auch auf einem PC ausführen.

16 new Bricklets Blog entry

16 neue Bricklets Blogeintrag

Firmware: Humidity Bricklet 2.0 2.0.3 Add support for SetSamplesPerSecond function Download: Humidity Bricklet 2.0

Firmware: Humidity Bricklet 2.0 2.0.3 Unterstützung für SetSamplesPerSecond-Funktion hinzugefügt Download: Humidity Bricklet 2.0

I just released Humidity Bricklet 2.0 Firmware Version 2.0.3. It uses 1 sample per second as default and it has a configuration function for it. Please note that the function will only be available with the next API bindings release. But if you say that the temperature difference is there immediately on startup, i would assume that the new API does not help here. What happens if you run your test for an extended period of time? Do the temperatures converge?

What you are seeing there is very likely self-heating, to quote the datasheet: The new Air Quality Bricklet had the same problem, but more extreme (we measured 4.8°C difference). We had to set the default measurement frequency to 0.3 samples per second to make it acceptable. I also just found the following in the HDC1080 datasheet (Humidity 2.0): The Bricklet currently does not have API to set the measurement frequency, i put it on my TODO list. I will also change the default measurement frequency, since the high frequency is mostly not necessary for humidity/temperature.

Taucht der Master Brick denn prinzipiell auf unter Windows? In der Systemsteuerung o.ä.? Falls nicht, hast du vielleicht ein anderes USB Kabel zum testen da oder eventuell sogar einen anderen PC? (nur um zu schauen ob der Master Brick auftaucht)

Inwiefern springen die Werte denn hin und her? Wenn du im Brick Viewer die 3D-Ansicht anmachst, springt diese auch hin und her?

Wenn du den Master Brick per USB anschließt, leuchtet dann die blaue LED?

I think i misunderstood your problem. I changed something to make sure that the first edge in the edge count is always counted. That has nothing to do with interrupts, there is no edge count interrupt. The normal "value changed interrupt" always uses both edges. Maybe it is a problem with the debounce time? What debounce time are you using?

It looks like the current state of the edge count was not set when the configuration was set. Can you test the attached firmware? bricklet_industrial_digital_in_4_firmware_v2_0_3_beta1.bin

Firmwares: Thermocouple Bricklet 2.0 2.0.1, RGB LED Button Bricklet 2.0.1, Industrial Digital In 4 Bricklet 2.0 2.0.1, NFC Bricklet 2.0.2, PTC Bricklet 2.0 2.0.1, Remote Switch Bricklet 2.0 2.0.2, LED Strip Bricklet 2.0 2.0.1, Temperature IR Bricklet 2.0 2.0.2, Solid State Relay Bricklet 2.0 2.0.1, Humidity Bricklet 2.0 2.0.2, Outdoor Weather Bricklet 2.0.1, IO-4 Bricklet 2.0 2.0.1, RS485 Bricklet 2.0.2, Particulate Matter Bricklet 2.0.1, Industrial Quad Relay Bricklet 2.0 2.0.1, GPS Bricklet 2.0 2.0.4, Real-Time Clock Bricklet 2.0 2.0.3, Motion Detector Bricklet 2.0 2.0.1, Analog In Bricklet 3.0 2.0.2, RGB LED Matrix Bricklet 2.0.1, CAN Bricklet 2.0 2.0.1, Sound Pressure Level Bricklet 2.0.2, Industrial Dual Relay Bricklet 2.0.1, Thermal Imaging Bricklet 2.0.2, Voltage/Current Bricklet 2.0 2.0.1, DMX Bricklet 2.0.1, RS232 Bricklet 2.0 2.0.1, Motorized Linear Poti Bricklet 2.0.3, Load Cell Bricklet 2.0 2.0.1, Industrial Counter Bricklet 2.0.1 Fix für Race Condition mit potentiellem Buffer Overflow (über bricklib2) Download: Thermocouple Bricklet 2.0, RGB LED Button Bricklet, Industrial Digital In 4 Bricklet 2.0, NFC Bricklet, PTC Bricklet 2.0, Remote Switch Bricklet 2.0, LED Strip Bricklet 2.0, Temperature IR Bricklet 2.0, Solid State Relay Bricklet 2.0, Humidity Bricklet 2.0, Outdoor Weather Bricklet, IO-4 Bricklet 2.0, RS485 Bricklet, Particulate Matter Bricklet, Industrial Quad Relay Bricklet 2.0, GPS Bricklet 2.0, Real-Time Clock Bricklet 2.0, Motion Detector Bricklet 2.0, Analog In Bricklet 3.0, RGB LED Matrix Bricklet, CAN Bricklet 2.0, Sound Pressure Level Bricklet, Industrial Dual Relay Bricklet, Thermal Imaging Bricklet, Voltage/Current Bricklet 2.0, DMX Bricklet, RS232 Bricklet 2.0, Motorized Linear Poti Bricklet, Load Cell Bricklet 2.0, Industrial Counter Bricklet

Firmwares: Thermocouple Bricklet 2.0 2.0.1, RGB LED Button Bricklet 2.0.1, Industrial Digital In 4 Bricklet 2.0 2.0.1, NFC Bricklet 2.0.2, PTC Bricklet 2.0 2.0.1, Remote Switch Bricklet 2.0 2.0.2, LED Strip Bricklet 2.0 2.0.1, Temperature IR Bricklet 2.0 2.0.2, Solid State Relay Bricklet 2.0 2.0.1, Humidity Bricklet 2.0 2.0.2, Outdoor Weather Bricklet 2.0.1, IO-4 Bricklet 2.0 2.0.1, RS485 Bricklet 2.0.2, Particulate Matter Bricklet 2.0.1, Industrial Quad Relay Bricklet 2.0 2.0.1, GPS Bricklet 2.0 2.0.4, Real-Time Clock Bricklet 2.0 2.0.3, Motion Detector Bricklet 2.0 2.0.1, Analog In Bricklet 3.0 2.0.2, RGB LED Matrix Bricklet 2.0.1, CAN Bricklet 2.0 2.0.1, Sound Pressure Level Bricklet 2.0.2, Industrial Dual Relay Bricklet 2.0.1, Thermal Imaging Bricklet 2.0.2, Voltage/Current Bricklet 2.0 2.0.1, DMX Bricklet 2.0.1, RS232 Bricklet 2.0 2.0.1, Motorized Linear Poti Bricklet 2.0.3, Load Cell Bricklet 2.0 2.0.1, Industrial Counter Bricklet 2.0.1 Fix race condition with potential buffer overflow (through bricklib2) Download: Thermocouple Bricklet 2.0, RGB LED Button Bricklet, Industrial Digital In 4 Bricklet 2.0, NFC Bricklet, PTC Bricklet 2.0, Remote Switch Bricklet 2.0, LED Strip Bricklet 2.0, Temperature IR Bricklet 2.0, Solid State Relay Bricklet 2.0, Humidity Bricklet 2.0, Outdoor Weather Bricklet, IO-4 Bricklet 2.0, RS485 Bricklet, Particulate Matter Bricklet, Industrial Quad Relay Bricklet 2.0, GPS Bricklet 2.0, Real-Time Clock Bricklet 2.0, Motion Detector Bricklet 2.0, Analog In Bricklet 3.0, RGB LED Matrix Bricklet, CAN Bricklet 2.0, Sound Pressure Level Bricklet, Industrial Dual Relay Bricklet, Thermal Imaging Bricklet, Voltage/Current Bricklet 2.0, DMX Bricklet, RS232 Bricklet 2.0, Motorized Linear Poti Bricklet, Load Cell Bricklet 2.0, Industrial Counter Bricklet

Ich kann das leider nicht reproduzieren. Hab alle möglichen Firmwares getestet, inklusive der aktuellen Master Brick Firmware 2.4.9 (mit Barometer Firmware 2.0.2). Hast du bereits überprüft ob vielleicht ein Pin im Bricklet Stecker krumm ist oder ähnliches?

Eine Kurze Erklärung des SPITFP (Tinkerforge Protocol over SPI) findest du hier: https://github.com/Tinkerforge/brickletboot_xmc/blob/master/software/src/bootloader_spitfp.c Der Payload der Pakete ist der gleiche wie bei TCP/IP, siehe hier: https://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html Funktionen des Sound Pressure Level Bricklets im Protokoll gibt es hier: https://www.tinkerforge.com/de/doc/Software/Bricklets/SoundPressureLevel_Bricklet_TCPIP.html

Das ist leider nicht möglich. Bricks wissen nicht welche Bricklets angeschlossen sind. Die Daten werden lediglich zum PC weitergeleitet.

Das muss ich ausprobieren, es gibt auf jeden Fall keinen Grund dafür warum das nicht funktionieren sollte.

Das war im Prinzip meine Frage. In diesem Fall würde ich empfehlen ein Bricklet daraus zu machen. Die neuen Bricklets haben ja alle Co-Prozessoren und könnten entsprechend die Vorverarbeitung machen. Die Möglichkeit größere Datenmengen verarbeiten zu können war ein Grund des Umstiegs von EEPROMs auf Co-Prozessoren.

Die 1000 Nachrichten pro Sekunde kommen ursprünglich durch die USB-Kommunikation. Der USB-Host pollt 1000x pro Sekunde. Das ganze System ist allerdings darauf ausgelegt mit internen Ticks die 1x pro ms laufen etc. Die 64 Byte entsprichen der maximalen Payload-Größe unseres Protokolls: https://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html Die WIFI Extension wird vermutlich keine 1000 Pakete pro Sekunde übertragen können, die Ethernet Extension schon eher.

Die maximale Datenmenge die du mit unserem System übertragen kannst ist 1000 Nachrichten pro Sekunde mit jeweils 64 Byte. Das gilt eigentlich sowohl für Bricklets als auch für Extensions. Kannst du die Daten denn direkt schon auf dem Brick/Bricklet irgendwie verarbeiten und dann weniger übertragen?

In your stack the Master Brick needs to be at the bottom and the Master Brick needs to be connected via USB. The Bricklets can be connected to any of the Bricks. If this doesn't work i have three ideas: 1. Is the firmware on all of the Bricks and Bricklets up-to-date? If not please update and try again. 2. Can you check if maybe on of the pins in the Bricklet connector of the Stepper Brick is bend? This could explain why there is no connection. 3. The Bricklets are not hotplug capable. So you have to connect them to the Bricks first and then connect the Brick via USB.