Ankündigung

Einklappen
Keine Ankündigung bisher.

eKey Fingerscanner per RS485 auslesen: Protokollanalyse

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Ohne angegebene Log-Konfiguration wird nur das Info-Log geschrieben. Interessant wäre das Debug-Log.

    log.properties:
    Code:
    ############################################################
    #      Default Logging Configuration File
    #
    # You can use a different file by specifying a filename
    # with the java.util.logging.config.file system property.  
    # For example java -Djava.util.logging.config.file=myfile
    ############################################################
    
    ############################################################
    #      Global properties
    ############################################################
    
    # "handlers" specifies a comma separated list of log Handler 
    # classes.  These handlers will be installed during VM startup.
    # Note that these classes must be on the system classpath.
    # By default we only configure a ConsoleHandler, which will only
    # show messages at the INFO and above levels.
    # handlers= java.util.logging.ConsoleHandler
    
    # To also add the FileHandler, use the following line instead.
    handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
    
    # Default global logging level.
    # This specifies which kinds of events are logged across
    # all loggers.  For any given facility this global level
    # can be overriden by a facility specific level
    # Note that the ConsoleHandler also has a separate level
    # setting to limit messages printed to the console.
    .level= ALL
    
    ############################################################
    # Handler specific properties.
    # Describes specific configuration info for Handlers.
    
    #  A pattern consists of a string that includes the following 
    #  special components that will be replaced at runtime:
    #
    #    * "/" the local pathname separator
    #    * "%t" the system temporary directory
    #    * "%h" the value of the "user.home" system property
    #    * "%g" the generation number to distinguish ;eosrotated logs
    #    * "%u" a unique number to resolve conflicts
    #    * "%%" translates to a single percent sign "%" 
    ############################################################
    
    # default file output is in user's home directory.
    #java.util.logging.FileHandler.pattern = %h/java%u.log
    java.util.logging.FileHandler.pattern = ekeydecoder.log
    # 100MB
    java.util.logging.FileHandler.limit = 100000000
    java.util.logging.FileHandler.count = 50
    java.util.logging.FileHandler.level = ALL
    java.util.logging.FileHandler.formatter = de.root1.ekeydecoder.LogFormatter
    
    # Limit the message that are printed on the console to INFO and above.
    # This limit can be overridden by facility specific properties, so that the log
    # is being processed, but the output is suppressed!
    java.util.logging.ConsoleHandler.level = INFO
    java.util.logging.ConsoleHandler.formatter = de.root1.ekeydecoder.LogFormatter
    
    
    ############################################################
    # Facility specific properties.
    # Provides extra control for each logger.
    ############################################################
    
    # For example, set the com.xyz.foo logger to only log SEVERE
    # messages:
    # com.xyz.foo.level = ALL
    # de.root1.simon.experiments.LogTester.level = ALL
    de.root1.level = ALL
    Java dann mit einem weiteren Parameter starten:

    Code:
    -Djava.util.logging.config.file=log.properties
    Den solltest du am besten ganz vorne angeben. Es wird dann im aktuellen Verzeichnis eine ekeydecoder.log Datei geschrieben die deutlich mehr Informationen drin hat, mit deren Hilfe ich dir sagen könnte wo der Fehler liegt, oder zumindest die Ursache suchen könnte. Gruß Alex
    Zuletzt geändert von tuxedo; 30.06.2015, 13:35.

    Kommentar


      Hi Tuxedo und Co!

      Danke für die Hilfe.. ich hab das Gefühl, dass es nach dem einen oder anderen Update des Systems, etc. stabil funktioniert, mache jetzt aber trotzdem mal sicherheitshalber einen Neustart jeden Morgen

      Jetzt aber ein ganz anderes Problem: verschiedene Finger erhalten offenbar den gleichen Hash! Ich habe es mit 2 verschiedenen Personen gecheckt. Die gleichen Hashes kommen wie folgt:
      Person 1 Mittelfinger rechts = gleicher Hash wie Person 2 Zeigefinger rechts (0xf2)
      Person 1 Zeigefinger rechts = gleicher Hash wie Person 2 Mittelfinger rechts (0x9f)
      Und das gleich Spiel noch bei der anderen Hand.

      Ich habe bei beiden Personen alle 10 Finger gescannt, wobei jeweils 4 Finger je ein unterschiedliches Relais schalten, und die beiden Daumen beide Relais gleichzeitig.
      Wär sehr froh, wenn mir wer helfen könnte. Danke!!!

      Kommentar


        Danke für die Hilfe.. ich hab das Gefühl, dass es nach dem einen oder anderen Update des Systems, etc. stabil funktioniert, mache jetzt aber trotzdem mal sicherheitshalber einen Neustart jeden Morgen
        Das hilft leider absolut nicht das System noch stabiler zu machen, da so Fehler u.U. gar nicht zu Tage treten und ich so keine Chance habe etwas zu verbessern, falls etwas im argen liegt.

        Jetzt aber ein ganz anderes Problem: verschiedene Finger erhalten offenbar den gleichen Hash! Ich habe es mit 2 verschiedenen Personen gecheckt. Die gleichen Hashes kommen wie folgt:
        Person 1 Mittelfinger rechts = gleicher Hash wie Person 2 Zeigefinger rechts (0xf2)
        Person 1 Zeigefinger rechts = gleicher Hash wie Person 2 Mittelfinger rechts (0x9f)
        Und das gleich Spiel noch bei der anderen Hand.
        Puuh, da bin ich etwas überfragt. Du kannst mal testweise versuchen Person 1 und Person 2 im Speicher weiter voneinander zu trennen: Person 1 <-> Person 10
        Vielleicht liegen die Hash-Werte dann besser?

        Gruß
        Alex

        Kommentar


          Hi Alex!

          Vielen Dank für den Tipp mit dem "weiter auseinander legen". Jetzt gibt es keine Überschneidungen mehr.. Klappt!
          Was mein Problem anlangt, werde ich jetzt nochmals brav loggen.

          Was ich jetzt schon ab und an hatte, war folgender Fehler - auch direkt nach dem erneuten Start des Loggers. Verbindung wird aber gleich wieder hergestellt. Im Debuglog steht genau das Gleiche..
          Code:
          2015-07-30 13:40:36.363 INFO [main] de.root1.ekeydecoder.Ekey.main: Running ...
          2015-07-30 13:40:37.959 INFO [main] de.root1.ekeydecoder.Ekey.main: Configdir: .
          2015-07-30 13:40:37.986 INFO [main] de.root1.ekeydecoder.Ekey.main: Config: type='SOCKET'
          2015-07-30 13:40:38.007 INFO [main] de.root1.ekeydecoder.Ekey.main: Config: setting='10.0.0.152:4001'
          2015-07-30 13:40:38.031 INFO [main] de.root1.ekeydecoder.Ekey.main: Using Socket-Mode: '10.0.0.152:4001'
          2015-07-30 13:43:40.302 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.run: Stream finished
          2015-07-30 13:43:40.316 WARNING [main] de.root1.ekeydecoder.Ekey.work: decoder terminated. Stream closed.
          2015-07-30 13:43:40.337 INFO [main] de.root1.ekeydecoder.Ekey.main: Trying to get connection back online in 5sec...
          Oder vorhin mit dieser Meldung direkt nach dem Start von ekeydecoder:
          Code:
          Please specify logfile by passing '-Djava.util.logging.config.file=<logconfig-file>' to JVM to get advanced log possibilities.
          2015-07-30 14:00:00.713 INFO [main] de.root1.ekeydecoder.Ekey.main: Running ...
          2015-07-30 14:00:00.857 INFO [main] de.root1.ekeydecoder.Ekey.main: Configdir: .
          2015-07-30 14:00:00.865 INFO [main] de.root1.ekeydecoder.Ekey.main: Config: type='SOCKET'
          2015-07-30 14:00:00.870 INFO [main] de.root1.ekeydecoder.Ekey.main: Config: setting='10.0.0.152:4001'
          2015-07-30 14:00:00.875 INFO [main] de.root1.ekeydecoder.Ekey.main: Using Socket-Mode: '10.0.0.152:4001'
          Exception in thread "EkeyDecoder" java.lang.ArrayIndexOutOfBoundsException: 1024
                  at de.root1.ekeydecoder.EkeyDecoder.byteReceived(EkeyDecoder.java:208)
                  at de.root1.ekeydecoder.EkeyDecoder.run(EkeyDecoder.java:270)
                  at java.lang.Thread.run(Thread.java:745)
          2015-07-30 14:00:05.297 WARNING [main] de.root1.ekeydecoder.Ekey.work: decoder terminated. Stream closed.
          2015-07-30 14:00:05.335 INFO [main] de.root1.ekeydecoder.Ekey.main: Trying to get connection back online in 5sec...
          2015-07-30 14:00:10.343 INFO [main] de.root1.ekeydecoder.Ekey.main: Config: type='SOCKET'
          2015-07-30 14:00:10.348 INFO [main] de.root1.ekeydecoder.Ekey.main: Config: setting='10.0.0.152:4001'
          2015-07-30 14:00:10.353 INFO [main] de.root1.ekeydecoder.Ekey.main: Using Socket-Mode: '10.0.0.152:4001'
          Irgendwo hapert es teils wohl einfach bei der Übertragung, obwohl angeblich eine Verbindung hergestellt ist.
          Ich habe zB beim Raspi, wo der ekey dran hängt testhalbe das ser2net neu gestartet. Starte ich dann den ekeydecoder am anderen Rechner auch noch neu, scheint die Verbindung sauber hergestellt zu sein. Allerdings kommen keine Signale vom ekey an bzw. werden sie vermutlich erst gar nicht gesendet. Nach einem Neustart des Raspi, an dem der ekey dran hängt, klappt jetzt alles ganz normal.

          Blöderweise ist das nicht immer reproduzierbar. Manchmal ist ein Stoppen und - auch verzögertes - Starten von ser2net kein Problem. Keine Ahnung, ob man daraus irgendwelche Schlüsse ziehen kann Im Debuglog steht leider auch nichts drin, eben weil wohl gar nichts ankommt. Ich werde weiterhin beobachten und was melden, sofern ich das kann.

          Dankeschön!

          Kommentar


            2015-07-30 13:43:40.302 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.run: Stream finished
            2015-07-30 13:43:40.316 WARNING [main] de.root1.ekeydecoder.Ekey.work: decoder terminated. Stream closed.
            Heisst so viel wie: Es konnte nichts vom vom Socket gelesen werden. Der read() Befehl liefert hierzu -1 gelesene Bytes zurück (indikator für Stream zuende). Das Programm merkt das und baut die Verbindung dann wieder auf:

            2015-07-30 13:43:40.337 INFO [main] de.root1.ekeydecoder.Ekey.main: Trying to get connection back online in 5sec...
            Mögliche Auslöser:
            * USB-Stecker kurz abgezogen
            * ser2net neu gestartet
            * Netzwerkverbindung zwischen dem Programm und ser2net unterbrochen (was schwer wird wenn alles auf einer Kuste/Pi läuft)

            Wenn mehr als nur der USB-RS485 Dongle am Pi steckt: Probier's mal mit einem aktiven USB Hub. Vielleicht reicht ab und an der Saft nicht mehr aus. Dann solltest du aber mit "dmesg" auch sehen dass der Stick neu gefunden wird...

            2015-07-30 14:00:00.875 INFO [main] de.root1.ekeydecoder.Ekey.main: Using Socket-Mode: '10.0.0.152:4001'
            Exception in thread "EkeyDecoder" java.lang.ArrayIndexOutOfBoundsException: 1024
            at de.root1.ekeydecoder.EkeyDecoder.byteReceived(Ekey Decoder.java:208)
            at de.root1.ekeydecoder.EkeyDecoder.run(EkeyDecoder.j ava:270)
            at java.lang.Thread.run(Thread.java:745)
            2015-07-30 14:00:05.297 WARNING [main] de.root1.ekeydecoder.Ekey.work: decoder terminated. Stream closed.
            2015-07-30 14:00:05.335 INFO [main] de.root1.ekeydecoder.Ekey.main: Trying to get connection back online in 5sec...
            Das ist ein Fehler mit dem ich schon mehr anfangen kann. Betreffende Code-Zeile schreibt die gedroppten bytes in ein Array um später zu loggen was gedropped wurde. Ich hab hier etwas nachlässig implementiert und keinen Pufferüberlauf berücksichtigt. In diesem Fall gab es nun tatsächlich mehr als 1kilobytes an gedroppten Daten ohne dass eine korrekte Nachricht dazwischen empfangen wurde.

            Habe soeben den Fehler behoben (betrifft ja nur das DEBUG-Log). Build läuft gleich ...

            Ich habe zB beim Raspi, wo der ekey dran hängt testhalbe das ser2net neu gestartet.
            ser2net Neustart bringt ersten oben genannten Fehler. Das ist by-design so ...

            Allerdings kommen keine Signale vom ekey an bzw. werden sie vermutlich erst gar nicht gesendet. Nach einem Neustart des Raspi, an dem der ekey dran hängt, klappt jetzt alles ganz normal.
            Probier mal die Sache mit dem aktiven USB-Hub oder ggf. mit einem stärkeren Netzteil für den Pi. Klingt nach zu wenig Saft... Da fängt der Pi an sich "seltsam" zu verhalten.


            Im Debuglog steht leider auch nichts drin, eben weil wohl gar nichts ankommt.
            Die geposteten Log-Abschnitte sind das "normale" Log das auf der Konsole erscheint wenn man ekey-decoder startet. Sieht man an den Log-Leveln nach dem Zeitstempel:
            *INFO
            *WARNING

            Um das Debug-Log zu erhalten muss man dem Java-Aufruf noch folgenden Parameter (vorne) in den Aufrufargumenten mitgeben:

            Code:
            -Djava.util.logging.config.file=log.properties
            wobei log.properties die entsprechende Log-Konfiguration ist

            Kommentar


              He Alex!

              Vielen Dank für die rasche und ausführliche Antwort! Ich hab das Konsolenlog kopiert, da dort fast mehr drin stand als im Debug Log. Das log.properties hab ich von dir übernommen, das File wird auch brav geschrieben (also ich lasse ein extra File anlegen).
              Meist stand da weniger drin als im Konsolelog, doch interessanterweise geht es jetzt grad wild ab. Die Datei ist innerhalb einer Minute 10 MB groß, pro Sekunde werden etliche Einträge geschrieben. Ist vermutlich auch nicht Sinn der Sache. Soll ich hier das DEBUG Level nicht doch ein wenig runter schrauben, um hoffentlich brauchbare Infos zu bekommen?

              Code:
              2015-07-31 12:01:57.356 INFO [main] de.root1.ekeydecoder.Ekey.main: Running ...
              2015-07-31 12:01:58.613 FINE [main] de.root1.ekeydecoder.Ekey.main: Args (2): [-confdir, /usr/smarthome/ekey]
              2015-07-31 12:01:58.683 INFO [main] de.root1.ekeydecoder.Ekey.main: Configdir: /usr/smarthome/ekey
              2015-07-31 12:01:58.705 INFO [main] de.root1.ekeydecoder.Ekey.main: Config: type='SOCKET'
              2015-07-31 12:01:58.717 INFO [main] de.root1.ekeydecoder.Ekey.main: Config: setting='10.0.0.152:4001'
              2015-07-31 12:01:58.727 INFO [main] de.root1.ekeydecoder.Ekey.main: Using Socket-Mode: '10.0.0.152:4001'
              2015-07-31 12:02:00.312 FINE [main] de.root1.slicknx.Knx.<init>: Connected to knx via /224.0.23.12:3671 and individualaddress null
              2015-07-31 12:02:00.375 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for length
              2015-07-31 12:02:00.391 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for LengthExtension
              2015-07-31 12:02:00.395 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: frame has 30 Bytes
              2015-07-31 12:02:00.400 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Frame complete
              2015-07-31 12:02:00.451 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 9b 0f 00 22 5e d3 dc 2e 55 e2 ee ce 00 03
              2015-07-31 12:02:00.460 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for length
              2015-07-31 12:02:00.470 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for LengthExtension
              2015-07-31 12:02:00.477 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: 2nd lengthbyte -> +64
              2015-07-31 12:02:00.493 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: frame has 108 Bytes
              2015-07-31 12:02:00.501 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Frame complete
              2015-07-31 12:02:00.510 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: tail wrong
              2015-07-31 12:02:00.594 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [106]: 02 ab 03 32 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 3f 93 00 22 0b 92 d7 2b ba 31 ff 7b 00 03 00 02 75 20 82 81 80 ad b3 81 c4 22 c0 80 d5 72 78 3f 0e 94 c9 d2 df de d9 9f db da d5 d4 03 00 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 40 30 00 22 4f 91 ff 6a b1 5b b7 5e 00 03 00 02 39 20 82 e0 80 ad b3 81 c4 22 c0 80
              2015-07-31 12:02:00.608 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [3]: 72 03 00
              2015-07-31 12:02:00.612 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for length
              2015-07-31 12:02:00.615 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for LengthExtension
              2015-07-31 12:02:00.619 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: frame has 31 Bytes
              2015-07-31 12:02:00.624 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Frame complete
              2015-07-31 12:02:00.643 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 75 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 41 74 00 22 7d 3f ff 79 a0 35 ff 6d 00 03
              2015-07-31 12:02:00.648 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for length
              2015-07-31 12:02:00.652 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for LengthExtension
              2015-07-31 12:02:00.657 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: frame has 16 Bytes
              2015-07-31 12:02:00.661 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Frame complete
              2
              
              usw.

              Der USB Stick hängt bereits an nem Hub mit eigener Stromzufuhr. Allerdings ist das Kabel länger als 5m (hat aber auch nen Verstärker drin). Oki, ich werde jetzt mal längere Zeit das DEBUG Log mitlaufen lassen und auch checken, ob über dmesg was zu erkennen ist.

              Per dmesg beim anderen Pi konnte ich bis dato keinen Dropout des USB-Sticks verzeichnen. Hmmm...

              Problem bei mir war ja primär, dass nach 6 Stunden ausgeschaltetem Rapi (mit dem USB Adapter) das Reconnect irgendwie nicht mehr gefunzt hat... Ich melde mich. Merci!

              Zuletzt geändert von Onkelandy; 31.07.2015, 11:06. Grund: Einige Änderungen bezügl. Logfile..

              Kommentar


                Nein, die dritte Spalte im Log (Egal ob Konsole oder File) zeigt das Log-Level an.

                INFO, FINE, FINER, FINEST, WARNING, ERROR ... sind die möglichen Loglevels.


                Problem bei mir war ja primär, dass nach 6 Stunden ausgeschaltetem Rapi (mit dem USB Adapter) das Reconnect irgendwie nicht mehr gefunzt hat...
                Wieso schaltest du 6h lang den Raspi mit dem USB-Adapter ab? Stromsparen? Das ist jetzt nicht dein ernst. Hast du mal geschaut was der an Strom braucht?
                Dennoch sollte der Reconnect nach 6h klappen, und bis dahin wird er dir das Log mit regelmäßigen Meldungen vollmüllen die besagen, dass er die Verbindung nicht aufbauen kann.


                Kommentar


                  Hehe, wie schon erwähnt gehabt hängt der Raspi halt an der gleichen Steckdose wie der Router, Verstärker, etc.
                  Ich beobachte das jetzt heute Nacht nochmals und melde mich, wenn ich was Brauchbares finde. Wie gesagt, ich kann das Problem natürlich beheben, indem ich den Raspi umhänge oder dein Tool neu starte. Bis dann!

                  Kommentar


                    [QUOTE=Onkelandy;n849967]
                    Hallo,
                    der Trace verrät ja schon 'was:

                    Code:
                    Raw Frame [106]: 02 ab 03 32 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 3f 93 00 22 0b 92 d7 2b ba 31 ff 7b 00 03 00 02 75 20 82 81 80 ad b3 81 c4 22 c0 80 d5 72 78 3f 0e 94 c9 d2 df de d9 9f db da d5 d4 03 00 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 40 30 00 22 4f 91 ff 6a b1 5b b7 5e 00 03 00 02 39 20 82 e0 80 ad b3 81 c4 22 c0 80
                    Durch den unglücklich verschluckten Anfang wird die erwartete Länge falsch ermittelt, so dass mehrere kurze Frames als ein langer interpretiert werden.
                    Ich löse den mal mittels der Anfangs-Ende-Bytes auf:
                    02 ... ab .... 03 <--- hier wurden zwischen Beginn und Ende offenbar mehrere Bytes verschluckt.
                    .... 32 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 3f 93 00 22 0b 92 d7 2b ba 31 ff 7b 00 03 <--- hier fehlt der Anfang
                    00 <-- zwischen den Frames herrscht physikalisch Busruhe. Wenn hier eine 00 (oder was auch immer) steht, ist das Bias-Netzwerk unzureichend.
                    02 75 20 82 81 80 ad b3 81 c4 22 c0 80 d5 72 78 3f 0e 94 c9 d2 df de d9 9f db da d5 d4 03 <-- sieht (grob) ok aus.
                    00 <-- wieder das Phantom-Zwischenbyte.
                    02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 40 30 00 22 4f 91 ff 6a b1 5b b7 5e 00 03 <-- sieht (grob) ok aus.
                    00 <-- wieder das Phantom-Zwischenbyte.
                    02 39 20 82 e0 80 ad b3 81 c4 22 c0 80 .... <-- kann der normale Anfang des nächsten Frames sein, Ende fehlt halt.

                    Ich schlage vor:
                    - Erweiterung des Decoders mit einer Warn-Message, falls innerhalb eines Frames 02 oder 03 auftauchen (vor dem unstuffing natürlich). Das weist auf Datensalat hin (z.B. falsch verstandene Länge wie im Beispiel oben).
                    - Hardware: Bias-Netzwerk (ich weiß, ich wiederhol mich ;-) Damit verschwinden mindestens die Phantom-Zwischenbytes.
                    - Die "Verschlucker" sind damit allerdings nicht erklär-/lösbar. Um einzugrenzen, ob die schon in der Erfassung oder auf dem Weg verloren gehen, könnte man vielleicht mit Wireshark mal den Netzwerktraffic des ser-to-net aufzeichnen und schauen, ob dort die RS485-Pakete vollständig sind.
                    Zuletzt geändert von UweH; 01.08.2015, 22:20.

                    Kommentar


                      Hi nochmals!

                      Also ich habe hier nochmals einen Ausschnitt aus dem Logfile und beim letzten "tail wrong" auch einen Wireshark-Mitschnitt. Hoffe, das bringt hier irgendwas, hab das noch nie gemacht

                      Code:
                      2015-08-01 16:20:48.045 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Fingerhash [0x7e] resolves to 'Andy Zeigefinger rechts'
                      2015-08-01 16:20:48.068 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Send string '7eh/Andy Zeige' to 10/0/1
                      2015-08-01 17:52:59.959 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: tail wrong
                      2015-08-01 17:52:59.971 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [66]: 02 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 41 b2 00 22 50 78 b7 ff 55 34 ef 47 00 03 00 02 39 20 82 e0 80 ad b3 81 c4 22 c0 80 d5 72 03 00 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 42
                      2015-08-01 20:24:07.052 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: tail wrong
                      2015-08-01 20:24:07.055 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [5]: 02 10 00 02 71
                      2015-08-01 20:44:25.712 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: tail wrong
                      2015-08-01 20:44:25.720 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [66]: 02 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 6b c5 00 22 4c 72 7b e7 c5 7f 5c ff 00 03 00 02 39 20 82 e0 80 ad b3 81 c4 22 c0 80 d5 72 03 00 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 6c
                      2015-08-01 21:29:37.732 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: tail wrong
                      2015-08-01 21:29:37.740 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [66]: 02 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 8c 76 00 22 22 4b df fa 4a 0d ef fb 00 03 00 02 71 20 82 81 80 ad b3 81 c4 22 c0 80 d5 72 31 8c 0e 2b 21 64 64 65 62 15 60 61 6e 6f 03 00 02 71 20
                      2015-08-02 06:08:15.944 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: tail wrong
                      2015-08-02 06:08:16.032 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [66]: 02 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 ba bf 00 22 f1 e3 7f db 00 78 95 53 00 03 00 02 71 20 82 81 80 ad b3 81 c4 22 c0 80 d5 72 3d ba 0e b9 af c2 ce cf c8 f0 ca cb c4 c5 03 00 02 71 20
                      2015-08-02 10:52:25.027 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: ***** Fingerhash: 0x13
                      2015-08-02 10:52:25.032 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Fingerhash received: 0x13
                      2015-08-02 10:52:25.126 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Sent fingerhash 0x13 to 10/0/0
                      2015-08-02 10:52:25.151 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Fingerhash [0x13] resolves to 'Andy Mittelfinger rechts'
                      2015-08-02 10:52:25.184 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Send string '13h/Andy Mitte' to 10/0/1
                      2015-08-02 11:14:02.486 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: tail wrong
                      2015-08-02 11:14:02.496 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [66]: 02 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 65 31 00 22 fb a1 bb af 64 79 2b 7f 00 03 00 02 39 20 82 e0 80 ad b3 81 c4 22 c0 80 d5 72 03 00 02 71 20 82 c0 c0 ad c0 80 d5 72 b3 81 c4 22 00 66
                      Irgendwie wird über Wireshark unglaublich viel mitgeschnitten, ich überblick das nicht.. Wage es daher, einfach mal das File hier bereitzustellen Hoffe, es ist irgendwie hilfreich? Merci!
                      Wireshark Mitschnitt Dropbox


                      Kommentar


                        Hallo Uwe,

                        Erweiterung des Decoders mit einer Warn-Message, falls innerhalb eines Frames 02 oder 03 auftauchen
                        Klingt gut, werde ich mal einbauen.

                        - Hardware: Bias-Netzwerk (ich weiß, ich wiederhol mich ;-) Damit verschwinden mindestens die Phantom-Zwischenbytes.
                        Der von uns verwendete Adapter ...

                        $_35.JPG
                        ... lässt nicht keine Modifikation zu ohne dass man den Adapter gehäuselos benutzt (oder sich einzelne SMD Widerstände organisiert und die dann einlötet). War schon auf der Suche nach einem besseren/größeren Adapter. Aber bisher erfolglos. Meist waren die Adapter unverschämt teuer (>50EUR).
                        Du hast nicht zufällig einen heißen Tipp (außer selbst bauen)?

                        Die "Verschlucker" sind damit allerdings nicht erklär-/lösbar. Um einzugrenzen, ob die schon in der Erfassung oder auf dem Weg verloren gehen
                        Hatte selbst noch keine Zeit in den Wireshark-Dump rein zu schauebnn. Aber ser2net ist eigentlich äußerst robust (hat in den vergangenen 5 Jahren noch keine Schwierigkeiten gemacht, auch nciht auf dem Pi). Ich tippe mal blind auf auf den günstigen USB Stick oder eine mangelhafte Verkabelung. Wobei letzteres bei der robustheit von RS485 schon sehr merkwürdig wäre.

                        Kommentar


                          Das Teil hier soll angeblich (http://forums.parallax.com/discussio...byte-to-appear) einen RS485 Treiber IC mit "true fail safe" drin haben (sollte...): http://de.rs-online.com/web/p/kvm-ka...niert/6877834/

                          Damit wäre das Bias-Thema auf jeden Fall erschlagen. Kostet halt auch 10x so viel. Wobei 30EUR gerade noch so okay wären für "auspacken, anschließen, funktioniert out-of-the-box".
                          Zuletzt geändert von tuxedo; 03.08.2015, 08:27.

                          Kommentar


                            Hi zusammen,
                            ich bin ebenfalls grad dabei das hier zur Verfügung gestellte Tool zu testen. Hierzu hab ich mir diesen Adapter hier zugelegt. Ich kann zwar Daten damit empfangen, allerdings "droppt" das Tool alle Datenpakete.
                            Vermutlich ist dieser Adapter nicht kompatibel. Ich muss dazu sagen, dass ich ihn direkt mit dem Tool betreibe (ohne ser2net).

                            Evtl Probier ich mal den zuletzt von tuxedo vorgeschlagenen Adapter aus...

                            Kommentar


                              Heho fuppy, hast du's mal mit dem socket-Parameter probiert (ser2net auf Linux)? Hatte nämlich auch Probleme beim "direkten" Abfragen über die serielle Schnittstelle. Hängt vermutl. vom OS ab, aber vielleicht kannst du das mal probieren?

                              Kommentar


                                Hi Onkelandy,
                                hab ich noch nicht probiert. Werd ich heut Abend dann aber mal testen. Schlechter kann es ja nicht werden ;-)
                                Fand die direkte Anbindung halt "schicker", da nicht noch ne Komponente dazwischen ist, welche ausfallen könnte...

                                Ich werd dann wieder berichten. Evtl. taugt der von mir verwendete Adapter ja doch was ;-)

                                Nur der Vollständigkeit halber: Bei mir läuft das Ganze unter Debian Wheezy auf einem Beaglebone Black...

                                Kommentar

                                Lädt...
                                X