Jump to content

photron

Administrators
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    3.054

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    39

 Inhaltstyp 

Posts erstellt von photron

    GPS Bricklet will nicht

    in Hardware

    Geschrieben

    Hmmh, bei der Implementation ist mir aufgefallen, dass ich schon vor dem ersten Fix Koordinaten (GetCoordinates) bekomme, allerdings wird das m.E. nicht im Viewer dargestellt. Der zeigt zu Beginn nur die Uhrzeit, aber keine Koordinaten.

     

    GetCoordinates gibt immer etwas zurück, die Daten sind allerdings nur dann richtig/gültig, wenn GetStatus einen 2D oder 3D Fix anzeigt. Das war leider so noch nicht dokumentiert, ich verbessere das gerade.

     

    Ich habe ans Bricklet extern eine typische GPS-Antenne angeschlossen, die Knopfzelle ist permanent an der Platine. Antenne hängt aus dem Fenster Richtung Süden ohne Hindernisse, so bleibt das Bricklet testweise erstmal trocken ;D. Sat.Viewed: 10-12; Used:6-8; Epe:1,4-2,5m (aber erst nach ein paar Min.)

    Ein Kaltstart (nach PC hochfahren, Stack connectieren etc.) von App.start bis ersten Fix komme ich nie auf 2-3.

     

    Ich hab's gerade noch mal getestet. Nach einem Kaltstart (Strom war weg und Batterie raus) dauert es so 4-5 Minuten bis zum ersten Fix, diese Zeit hängt nicht von der Verwendung der Batterie ab.

     

    Dass der EPE dann nach und nach geringer wird ist denke ich normal, das Modul wird sich über die Zeit sicherer darüber wo es genau ist.

     

    Wenn ich dann den Aufbau vom Strom trennen (Batterie aber drin lasse) einen Moment warte und dann wieder anschließe dauert es 2-3 Sekunden bis zum Fix. Dabei liegt das Bricklet aber auch direkt an einem Fenster mit Blick auf eine Wiese. Wenn ich es jetzt ca. 1m weit vom Fenster weg lege vor meine Tastatur, dann dauert es schon 9-10 Sekunden bis zum Fix. Und ich habe auch gerade kurzzeitig den Fix verloren, als ich beim Tippen das Bricklet mit meinen Armen abgedeckt hatte.

     

    Ich denke, dass es also durchaus normal ist wenn es 10 Sekunden dauert, je nachdem was da so den GPS Empfang in deiner Umgebung stört.

    GPS Bricklet will nicht

    in Hardware

    Geschrieben

    Wenn das GPS Bricklet einen Fix hat und du es dann vom Strom trennst, dann stützt die Batterie die interne Datenhaltung des Moduls über Satelliten in View und die aktuelle Uhrzeit. Ohne Batterie gehen diese Daten verloren, wenn das Bricklet nicht mehr vom Brick mit Strom versorgt wird.

     

    Wenn dann wieder Strom angeschlossen wird dauert es bis zum neuen Fix typischerweise nur ein paar Sekunden, wenn eine Batterie zur Datenhaltung eingelegt ist. 10sec ist da eigentlich schon lange. Im Test hier waren das eher so 2-3sec, wobei das GPS Modul durchschnittlich 10 Satelliten in View hatte und am Fenster lag.

     

    Der erste Fix, wenn das Modul noch keine Satelliten in View hat kann länger dauern, zwischen 30sec und ein paar Minuten je nach Sicht.

    GPS Bricklet will nicht

    in Hardware

    Geschrieben

    Funktioniert der Master Brick ohne GPS Bricklet?

     

    Hast du Master Brick und GPS Bricklet neu geflashed? Falls das GPS Bricklet nicht geflashed ist, dann er klärt das diesen Effekt. In diesem Fall erst den Master an USB anschließen und dann erst das Bricklet, so kannst du es wieder flashen.

     

    Und nein, der Master bootet natürlich auch schon bevor das GPS Bricklet eine Positionsbestimmung hat.

    [Delphi] Utf16ToKS0066U-Funktion

    in Software, Programmierung und externe Tools

    Geschrieben

    Das steht noch auf der TODO Liste. IIRC hatte ich mich damals davon überzeugt, dass es zur Unicodebehandlung unter Delphi und Free Pascal nichts Einheitliches gab. Hab' da gerade noch mal gegooglet und UnicodeString (was es aber wohl erst ab Delphi 2009 gibt) und WideString gefunden. Keine Ahnung warum ich mich damals vom Gegenteil überzeugt hatte. Damit ist das auf der TODO Liste nach oben gerückt.

    TF Protocol 2.0 Beta

    in Allgemeine Diskussionen

    Geschrieben

    Dyld Error Message:

      Library not loaded: @executable_path/libusb-1.0.0.dylib

      Referenced from: /usr/libexec/brickd.app/Contents/MacOS/brickd

      Reason: Incompatible library version: brickd requires version 2.0.0 or later, but libusb-1.0.0.dylib provides version 1.0.0

     

    Das da steht brickd würde libusb 2.0.0 benötigen verwundert mich, es gibt keine libusb 2.0.0.

    TF Protocol 2.0 Beta

    in Allgemeine Diskussionen

    Geschrieben

    Hier ist ein weiterer Beta-Tester :D...

    Was auch noch dringend fehlt ist ein "Wie porte ich meinen Code vom alten auf das neue Protokoll"-Tutorial. Ich denke, dass ich dies vor Weihnachten noch verfasse.

    Müssen bei der Migration auf das neue Protokoll im eigenen Code Anpassungen vorgenommen werden ?

     

    Ja. Das betrifft hauptsächlich die IPConnection und die Signatur von Callbacks. Vergleiche v1 mit v2 des Temperature Bricklet Callback Beispiels.

     

    Wo liegt unter Win das Log-File des BrickD-Treibers ? Lässt sich der Log-Level einstellen ? Bzw. ist das nötig ?

     

    Standardmässig schreibt brickd unter Windows kein Logfile, sondern wird Errors und Warnings ins Event Log schreiben. "wird" weil die aktuelle Beta das noch nicht tut. Wird brickd allerdings mit --debug Option gestartet dann schreibt er ein Logfile mit vollem Debug Level in eine brickd.log Datei ins gleiche Verzeichnis in der auch brickd.exe liegt.

     

    Um brickd mit --debug Option zu starten muss er über die Computerverwaltung beendet, als Startparameter --debug angegeben und wieder gestartete werden.

     

    Es wird dann auch noch die Möglichkeit geben, das Logging genauer über eine Konfigurationsdatei einzustellen. Im Moment kann das nur über die --debug Option gesteuert werden.

    TF Protocol 2.0 Beta

    in Allgemeine Diskussionen

    Geschrieben

    Also ich konnte den Fehler wieder beobachten. Das ganze passiert wenn mein Programm läuft und man den Master per Reset neustartet. Dann geht die CPU-Last hoch und das Log wird innerhalb von Sekunden extrem groß(1GB).

     

    Ich benutze die Java Bindings mit Callbacks (Temperatur)

    Plattform ist 64 Bit

     

    Hier mal das LOG

    2012-12-22 16:33:18.958975 <I> <main_linux.c:275> Brick Daemon 2.0.0 started (daemonized)
2012-12-22 16:33:19.193359 <I> <usb.c:137> Added USB device (bus: 2, device: 6) at index 0: Master Brick [67N4R3]
2012-12-22 16:34:14.630459 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:35:20.991206 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:35:27.535909 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:35:36.839606 <I> <client.c:61> Socket (handle: 18) disconnected by client
2012-12-22 16:35:39.685049 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:35:44.676683 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:35:48.520440 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:36:02.533402 <I> <client.c:61> Socket (handle: 18) disconnected by client
2012-12-22 16:36:03.983742 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:36:09.237350 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:36:14.174956 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:36:18.364469 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:36:59.951934 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:37:02.877460 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:37:10.114530 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:37:15.943577 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:37:49.366481 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:38:25.558476 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:38:27.828234 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:39:14.282072 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:39:20.523027 <W> <transfer.c:60> Read transfer 0x18d9d40 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523162 <W> <transfer.c:60> Read transfer 0x18d9db8 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523524 <W> <transfer.c:60> Read transfer 0x18d9e30 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523737 <W> <transfer.c:60> Read transfer 0x18d9c50 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.524057 <W> <transfer.c:60> Read transfer 0x18d9cc8 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.565888 <I> <usb.c:262> Removing USB device (bus: 2, device: 6) at index 0: Master Brick [67N4R3]
2012-12-22 16:39:20.569079 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569109 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569129 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569139 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569152 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569161 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569172 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569182 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569194 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569203 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569214 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569223 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569234 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569244 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569270 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569279 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569290 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569298 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569308 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)

     

    Das Log reicht mir schon, kein weiteres mit LOG_LEVEL_DEBUG bzw --debug nötig.

     

    Das Problem tritt nur auf, wenn mehreren Clients gleichzeitig eine Verbindung zu brickd haben. Dabei kann es passieren, dass die Clients in einer anderen zeitlichen Reihenfolge die Verbindung trennen verglichen mit der Reihenfolge des Verbindungsaufbaus. Das passiert in deinem Fall. Warum dass gerade mit dem Reset des Master Bricks zusammen fällt ist mir nicht klar.

     

    Dadurch kommt die Datenhaltung in brickd durcheinander. brickd fällt in eine Schleife in der er versucht einen Client aus der Liste der verbundenen Client zu entfernen, scheitert aber durch den Fehler in der Datenhaltung. Diesen Bug habe ich gerade behoben. Auf github findet sich jetzt die korrigierte Version.

     

    Zum Testen hab ich ein Debian AMD64 Package angehängt. Um Windows und Mac OS X Installer neuzubauen habe ich gerade nicht die dafür eingerichteten PCs zur Hand.

    brickd-2.0.0_eda6a29a188cd8ce667afa9cdabbdef47f75f27b_amd64.deb

    Temperatur Bricklet defekt?

    in Hardware

    Geschrieben

    Mac ist hier die wichtige Information. Brick Viewer 1.1.17 für Mac OS X kommt jetzt mit einer älteren Qt Version (4.7). Die neuere Qt Version (4.8) hat ein Problem, dass dazu führt, dass die Graphen nicht dargestellt werden. Mit Qt 4.7 tritt diese Problem nicht auf und die Graphen funktionieren.

     

    Die UIDs sind Base58 enkodiert, eine "1" entspricht dezimal 0 und wenn der Brick eine 0 als UID vom Bricklet EEPROM liest kann er nicht unterscheiden, ob an dem Bricklet Port jetzt wirklich ein Bricklet mit UID 0 steckt oder kein Bricklet abgeschlossen ist. Denn wenn der Brick versucht ein nicht existentes Bricklet auszulesen bekommt er auch eine 0 als UID zurück. Daher nimmt der Brick an, dass an Ports wo er UID "1" liest kein Bricklet angeschlossen ist und daher taucht ein Bricklet mit UID "1" nicht im Brick Viewer auf.

     

    Eigentlich liefern wir alle Bricklets mit einer voreingestellten UID ungleich "1" aus. Wie da bei dir eine "1" reingekommen ist ist mir unklar.

    Wattmesser

    in Hardware

    Geschrieben

    Bei dem IO16-Bricklet sind GND und der „output only“ Minuspol gleichbedeutend, oder?

     

    Ja.

     

    Wenn ich einen digitalen Eingang mit GND bzw. dem Minuspol verbinde, wird er automatisch zu einem Pluspol, oder?

     

    Mir ist die Frage nicht klar.

     

    Wenn du einen auf Eingang gestellten Pin mit GND/"-" verbindest ziehst du den Eingang auf Low und löst einen Interrupt aus, wenn der Pin dafür konfiguriert ist.

    Servo Brick max. Kabellänge zu Servo

    in Allgemeine Diskussionen

    Geschrieben

    -Wenn ich das Servo Brick über USB an meinen PC anschliesse, benötige ich doch kein Step-Down Power Supply Brick, da das Servo Brick über USB mit Strom versogt wird?

     

    Der Servo Brick selbst ist dann über USB versorgt. Die Servo Motoren müssen entweder über den schwarzen Eingang auf dem Servo Brick versorgt werden, oder über eine Step-Down Power Supply. Die Step-Down Power Supply speist 5V und die extern angelegte Spannung in den Stack ein. Diese extern angelegte Spannung wird vom Servo Brick für die Servo Motoren verwendet, wenn keine Spannung am schwarzen Eingang des Servo Bricks selbst anliegt.

     

    -Ein Master Brick benötige ich auch nicht, da ich direkt mit dem Servo Brick kommuniziere?

     

    Richtig, alle Bricks können für sich über USB verwendet werden. Einen Master Brick brauchst du nur, wenn du einen Stack baust, oder Extensions (RS485, WIFI, etc) verwenden willst. Die Step-Down Power Supply ist hier speziell, die funktioniert mit jedem Brick auch einzeln.

    Bricklets und Bricks werden nicht in Brick Viewer angezeigt

    in Anfängerfragen und FAQ

    Geschrieben

    Hört sich alles soweit richtig an. Brick scheint grundsätzlich zu funktionieren (LED und Lauflicht leuchten), Brick Daemon scheint so weit zu funktionieren, da sich der Brick Viewer connecten kann.

     

    Brickd meldet Errors und Warnings im Application Event Log, das befindet sich in der Computer Verwaltung (da wo auch die Services aufgelistet sind) und dann unter "System Tools > Event Viewer > Application". Stehen dort Einträge mit Source Brickd? Wenn ja, was stehen da für Fehlermeldungen?

×
×
  • Neu erstellen...