photron

pluto, das ist viel schwerer als du dir das vorstellst und von der Komplexität nicht vergleichbar mit den Bindings-Generatoren. Du schlägst im Prinzip vor C/C++, C#, Delphi, Java, Perl, PHP, Python, Ruby, Shell und VB.NET Compiler zu schreiben die Code erzeugen, der auf dem Brick direkt ausgeführt werden kann. Die technischen Details der exakten Ausführung diese Unterfangens sollen hier mal unter den Tisch fallen. Für C gibt es das schon, so schreiben wir ja die Firmwares, aber für alle anderen Sprachen ist das sehr sehr viel Aufwand, wenn es überhaupt sinnvoll möglich ist. Da ist es viel einfacher und überschaubarer ein RED Brick nach jetzigem Plan zu machen, auf dem man dann all die existierende Infrastruktur für alle unterstützten Sprachen einfach weiter nutzen kann.

Authentication The original plan for authentication in Protocol 2.0 was to have a pre-shared key that the user and the Brick know. This would be used to sign all messages send between Brick and user. Both sides verify that the messages are correctly signed. This way an attacker can neither claim to be a user nor to be a Brick. The problem with this plan is the complexity it adds to the Brick. Due to the way it works it would have to be directly integrated in the already very complex WIFI Extension logic. That's why we didn't do this yet. A simpler option would be to do authentication per-connection, were the user has to prove that he knows the pre-shared key. There are basically two options how to do this: Only for WebSockets The user's pre-shared key is send to the WebSocket server (Ethernet/WIFI Extension or Brick Daemon) as part of the WebSocket handshake during the connection process. Then the WebSocket server can compare it to its stored pre-shared key. If it matches then the connection attempt is accepted and the connection is authenticated. Otherwise the connection attempt is aborted. Before WebSockets can be used the user has to configure the pre-shared key of the WebSocket server. And in the JavaScript bindings the connect() function gets a third parameter that takes the pre-shared key to be include in the WebSocket handshake. For all communication By default authentication would be disabled to be compatible with the current system. If authentication is enabled then all TCP/IP connections to the TCP/IP server (Ethernet/WIFI Extension or Brick Daemon) start in unauthenticated state and all incoming and outgoing messages are thrown away until the user authenticates. For this the IPConnection of all bindings will get a authenticate() function that takes the pre-shared key, does the authentication process and proves to the TCP/IP server that the user knows the pre-shared key. This is done using a signing mechanism that avoids sending the pre-shared key over the wire. After this the connection is in authenticated state and all messages on this connection are handled as they are now. Because this type of authentication would be disabled by default WebSockets would also be disabled by default as we don't want to release something that is easily attacked by a malicious website in the default configuration. Any opinions, suggestions, questions?

It'll just connect to localhost:4280 to connect to the brickd on your PC. And even if you change the port then it can just probe all ports.

Not any browser running anywhere, but YOUR browser running on YOUR PC. I could make you open a website that I control and have it mess with your stack connected to your PC. I don't need external access to your network I just need you to open my website. In fact we will do exactly that. We plan to create an online version of Brick Viewer. You will be able to open brickv.com and it will be able to access your stack connected to your PC and provide the same features a locally installed Brick Viewer has. All this without installing any files to your PC, you just loaded a website with some JavaScript code that is executed in your browser.

Equinox, your browser is executing the JavaScript code. Your browser has access to your local network and any brickd running there. No direct connection from the Internet to your local 4280 port necessary.

No. An external party/attacker cannot access your stack, assuming you didn't expose port 4223 to the Internet. But with WebSocket support in brickd any website you open in your browser can access your stack via the brickd WebSocket, even if the WebSocket is only reachable from your PC. So any website out there that you open in your browser can access your stack, even if you didn't expose port 4280 to the Internet. The problem here is that you're basically running untrusted code from external sources in your browser. That's why there is so much sand-boxing in modern browsers. That's also the reason why WebSockets in the browser cannot connect to normal sockets. Otherwise any website could access all services on your local network via your browser. So, a malicious webserver cannot attack your stack directly, but it can deliver you a website that can do this.

Loetkolben, the new requirement for pm-utils is intended. It's part of the fix for the problem that brickd fails to talk to USB devices after a suspend on Linux and Mac OS X. There is a thread about this in the German board: http://www.tinkerunity.org/forum/index.php/topic,2169.0.html

Im englischen Thread gibt es jetzt einen brickd mit WebSocket Support und eine aktualisierte Version der Bindings die auch im Browser funktionieren.

Here's Brick Daemon 2.1.0 RC1 that accepts WebSocket connections on port 4280: Windows, Linux (amd64, i386, armhf), Mac OS X And here's also an updated version of the JavaScript bindings that includes the browser version of the bindings and examples for them. tinkerforge_javascript_bindings_2_0_0_rc1.zip Just put an example HTML file and the Tinkerforge.js file from the browser subdirectory in the ZIP in the same directory and open the HTML file in your browser. This was tested and works in the latest versions of Chrome/Chromium, Firefox and Internet Explorer. Other browsers that support the current WebSocket version should work as well.

Ah, the documentation of the Servo Brick is outdated in that point, sorry. The minimum limit used to be 2000µs, but it was lowered to 1µs quite a while ago. Seems that we missed to update the documentation about this. I fixed this now, thanks for finding this one. About modifying the firmware: You can certainly modify the firmware to bit-bang a PWM signal on any pin of an I/O Bricklet. But that's no that easy to do, because things like this don't match well with the internal task scheduling of the Bricks. In this system you cannot have an endless loop that just sits there and generates a PWM signal, assuming you want the rest of the system to work as before, such as other Bricklets on the same Brick, stack and USB communication etc. In contrast the Servo Brick is designed for this and uses dedicated hardware units for PWM signal generation. That allows to integrate the signal generation nicely with the task scheduling system.

Here's an example for PWM generation with the Servo Brick: #include <stdio.h> #include "ip_connection.h" #include "brick_servo.h" #define HOST "localhost" #define PORT 4223 #define UID "6dKCNw" // Change to your UID // Due to the internal clock dividing mechanism of the Servo Brick not all // arbitrary PWM frequency values can be achieved. For example, the upper most // three available PWM frequency values are 1MHz, 500kHz and 250kHz. The steps // are coarser on the high frequency end and much finer on the low end. You can // set any value here between 15Hz and 1MHz and the Servo Brick will try to // match it as closely as possible. #define PWM_FREQUENCY 175000 // in Hz [15Hz to 1MHz] #define PWM_DUTY_CYCLE 20 // in % [0% to 100%] int main() { // Create IP connection IPConnection ipcon; ipcon_create(&ipcon); // Create device object Servo servo; servo_create(&servo, UID, &ipcon); // Connect to brickd if(ipcon_connect(&ipcon, HOST, PORT) < 0) { fprintf(stderr, "Could not connect\n"); exit(1); } // Don't use device before ipcon is connected // Set degree range to 0-100, this will allow to // set the PWM duty cycle in 1% steps servo_set_degree(&servo, 0, 0, 100); // Set PWM frequency (1-65535µs == 1MHz-15Hz) int period = 1000000 / PWM_FREQUENCY; if (period < 1) { period = 1; // 1MHz } else if (period > 65535) { period = 65535; // ~15Hz } servo_set_pulse_width(&servo, 0, 0, period); servo_set_period(&servo, 0, period); // Fast acceleration and full speed servo_set_acceleration(&servo, 0, 65535); servo_set_velocity(&servo, 0, 65535); // Set PWM duty cycle (0-100 %) int position = PWM_DUTY_CYCLE; if (position < 0) { position = 0; } else if (position > 100) { position = 100; } servo_set_position(&servo, 0, position); // Enable PWM signal servo_enable(&servo, 0); printf("Press key to exit\n"); getchar(); ipcon_destroy(&ipcon); // Calls ipcon_disconnect internally } The Servo Brick can generate PWM frequencies up to 1MHz. Why do you think it's 500Hz, were did you get that information? Yes, the power for the PWM signal is taken from the USB connection. The black power connector on the Servo Brick is for powering the servo motors. So you don't need it if you just want to use the PWM signal only. Here's and other example of using an IO-4 Bricklet for 3.3V PWM generation. In this example the whole timing is done from the PC and is affected by the jitter of the operating system scheduler and is limited by the USB speed. #include <stdio.h> #include <sys/time.h> #include "ip_connection.h" #include "bricklet_io4.h" #define HOST "localhost" #define PORT 4223 #define UID "hf4" // Change to your UID #define PWM_FREQUENCY 100 // Hz #define PWM_DUTY_CYCLE 20 // 0% to 100% uint64_t microseconds(void) { struct timeval tv; gettimeofday(&tv, NULL); return tv.tv_sec * 1000000 + tv.tv_usec; } // have to use busy waiting here, using usleep() is not accurate enough void delay(uint64_t ms) { uint64_t last = microseconds(); uint64_t now = last; while (now < last + ms) { now = microseconds(); continue; } } int main() { // Create IP connection IPConnection ipcon; ipcon_create(&ipcon); // Create device object IO4 io; io4_create(&io, UID, &ipcon); // Connect to brickd if(ipcon_connect(&ipcon, HOST, PORT) < 0) { fprintf(stderr, "Could not connect\n"); exit(1); } // Don't use device before ipcon is connected // Set pin 0 to output low io4_set_configuration(&io, 1 << 0, 'o', false); int high_time = ((1000000 * PWM_DUTY_CYCLE) / 100) / PWM_FREQUENCY; int low_time = ((1000000 * (100 - PWM_DUTY_CYCLE)) / 100) / PWM_FREQUENCY; for (; { io4_set_value(&io, 1 << 0); delay(high_time); io4_set_value(&io, 0 << 0); delay(low_time); } printf("Press key to exit\n"); getchar(); ipcon_destroy(&ipcon); // Calls ipcon_disconnect internally } I can achieve a somewhat stable PWM signal with up to 100Hz with this. If I go any higher then the duty cycle isn't stable anymore and starts to jump between 10% and 40% for this example. So this approach is limited by the 1000 messages per second USB can transfer to the Brick and the scheduling of the operating system. In contrast the Servo Brick can generate much more stable PWM signals with much higher frequencies because all the timing is done on the Servo Brick and is not affected by USB or the operating system of the controlling PC. Depending on your requirements on frequency and stability of the PWM signal you might be able to use one of the I/O Bricklets. If your PWM frequency should be below 100Hz and doesn't have to be that stable it might work out. Otherwise I still suggest a Servo Brick, even if it's a little bit expensive if you just use it as a single channel PWM generator

Your required PWM signal can very easily be created by a Servo Brick. The PWM signal of the Servo Brick has a fixed output voltage of 5V. If that works for the control interface of your pump then I suggest a Servo Brick for this purpose. Regarding the PWM label on the Breakout Bricklet: This is basically a mislabeling, there is no usable PWM signal on that pin.

Ist jetzt released. Danke für den Hinweis und den Test.

Bindings: PHP 2.0.13 Fix passing $userData parameter to callbacks Download: PHP

Bindings: PHP 2.0.13 Übergabe des $userData Parameters an Callbacks korrigiert Download: PHP

The Servo Brick can generate 7 PWM signals, but you cannot drive a load directly with them, as they are designed as control signals only. The DC Brick can generate 1 PWM signal with enough power to drive a load. The Digital I/O and AnalogOut Bricklets don't have hardware support for generating PWM signals. You could manually generate a PWM signal, but this has some disadvantages compared to the Servo and DC Brick. The Digital I/O and AnalogOut Bricklets are limited in their switching frequency and precision due to the speed and possible jitter in the communication between the PC and the Bricklets. So the correct approach depends on the actual interface of your pump. Can you provide more information about it?

Die dokumentierte und implementierte Signatur ist schon diese: void BrickletIO16::registerCallback(int $id, callable $callback, mixed $userData=NULL) Allerdings fehlte beim Aufruf des eigentlichen Callbacks die Übergabe des $userData Parameters, so dass bei deiner cb_io1 Funktion dann kein $userData Parameter ankommt. Das ist jetzt korrigiert. Angehängt die korrigierte Version zum Testen. tinkerforge_php_bindings_2_0_13_rc1.zip

Das Analog In Bricklet ist für Gleichspannung gemacht. Von deinem Bild her sieht das nach einer typischen Klingel mit 12V Wechselspannung aus. Bei der negativen Halbwelle verpolst du dann die Eingänge des Bricklet was erklären kann warum der Master Brick aus dem Takt kommt. Du kannst eine Diode zwischen Klingel und Bricklet setzen, so dass nur noch die positive Halbwelle durchkommt und das Bricklet nicht mehr verpolt wird.

Hört sich immer noch nach Wackelkontakt/Hardwaredefekt an Melde dich mit deiner Bestellnummer bei info@tinkerforge.com. Wir tauschen den Master Brick dann aus.

Kann ich hier nicht reproduzieren. Ein brick Neustart kann/sollte sich nicht auf die Hardware auswirken, da diese das gar nicht mitbekommen kann. Bist du sicher, dass du da nicht noch irgendwas im Hintergrund laufen hast, dass durch einen brickd Neustart (den es mittels Disconnected/Connected Callback mitbekommt) an der IO-16 herumstellt?

Hört sich nach einem Wackelkontakt in der Mini-USB Buchse des Bricks an, bzw. der Lötkontakte der Buchse zur Platine hin. Kannst du mal versuchen den Mini-USB Stecker etwas nach oben/unten/links/rechts auf Spannung zu setzen und zu halten, um zu sehen ob dann eine Verbindung zustande kommt?

Hast du mal ein anderes USB Kabel getestet? Es sieht mit so aus als wäre die USB Kommunikation unterbrochen bzw. gestört. Du kannst auch mal den USB Hub weglassen, wenn du den am PC noch dazwischen hast und auch mal einen anderen USB Port am PC testen.

Das ist komisch. Versuch mal bitte den Master Brick zu zu flashen: http://www.tinkerforge.com/de/doc/Software/Brickv.html#brick-firmware-flashing

Okay, dann mal zu den grundsätzlicheren Dingen Wenn du den Master Brick an USB anschließt leuchtet dann die blauen LEDs auf? Falls nicht, tun sie es wenn er Master Brick alleine ist, also nicht im Stack mit anderen Bricks und ohne Bricklets? Wenn die LEDs leuchten, dann sollte der Master Brick funktionieren. Was passiert wenn du den Master Brick an USB anschließt? Taucht de im Geräte Manager als Master Brick bzw. Tinkerforge Brick auf?

Broken_Mind, wenn du den Brick also am PC anschließt wird er erkannt und alles funktioniert wie es soll. Am Raspberry Pi war das auch mal so, wenn du dort aber jetzt den Brick per USB anschließt dann tauch er nicht im brickv auf? Dass heißt also, dass das Problem mit dem Raspberry Pi zusammenhängt, weil der Brick auch weiterhin am PC funktioniert aber nicht mehr am Raspberry Pi. brickd läuft aber noch auf dem Raspberry Pi und brickv kann auch einer Verbindung herstellen? Was sagt lsusb auf dem Raspberry Pi? Bricks sollten dort als MCS oder GrauTec Geräte mit der ID 16d0:063d aufgeführt werden. Hast du vielleicht einfach ein Stromversorgungsproblem am Raspberry Pi, dessen USB Stromversorgung nicht die beste ist? Schließt du nur einen Brick, oder einen Stack von mehreren Bricks an? Kannst du mal mit einem einzelnen Brick testen? Oder einen aktiven USB Hub zwischen schalten, falls einer zur Hand ist? Oder eine Step-Down Power Supply verwenden, falls einer zur Hand ist?