eKey Fingerscanner per RS485 auslesen: Protokollanalyse

[tuxedo]

So, das Beste was in den Bereich von 100Ohm - 1kOhm passt und in meiner Bastelkiste verfügbar war, sind 620Ohm.

Am Verhalten hat sich aber nix geändert :-( Aber nach deiner Ausführung dass der Abschlusswiderstand nicht sooo die Rolle spielt, war das ja zu erwarten.

Nur zum Verständnis:

Wenn die Widerstände gegen Vcc und Gnd "okay" sind, dann dürfte ich, wenn ich die Datenleitungen zum ekey weglasse, doch kein einziges Byte empfangen, oder?

Hab jetzt den Abschlusswiderstand und die Leitungen zum ekey weggelassen. Kommt kein einziges Byte. Dann wäre ja alles im Lot, oder?

Könnte es sein dass irgendwas unterwegs vom ekey zum USB-Adapter das Signal - meist beim Frame-Start - beeeinflusst? Aber was könnte das sein?


[update]
Ich kann auch 2m lose Leitung an den USB-Adapter anschließen. Auch damit gibt's keiner 0x00 bytes. Auch nix anderes. Absolute Stille.

Wenn wenigstens durchgehend das Start-Byte fehlen würde, dann könnte ich programmatisch darauf reagieren. Ich hab mir deshalb nochmal die gedroppten Bytes angeschaut während ich einen Finger scanne. Das ist teils so zerhackt, dass sich da nix brauchbares extrahieren lässt.

RS485 ist doch was die Leitung angeht nicht sooo anspruchsvoll, oder? Hab ein "normales Telefonkabel", Typ JY(ST)Y gelegt. Die Leitung hat, hab's eben nochmal gecheckt, keine 10m. Dürften ca. 7-8m sein.

Wenn die 0-Pegel sauber passen, dann dürften es ja nur noch Reflektionen sein, oder? Ich werde mal versuchen 120Ohm hinzubiegen... 5x620Ohm parallel und ich bin bei immerhin 124 Ohm.... Vielleicht hilft das ja.

[update2]
Interessant... Mit den 5x620Ohm parallel = 124Ohm als Abschlusswiderstand am USB-RS485 Adapter bekomm ich gar kein Frame mehr hin....

Hier ein exemplarischer Logabschnitt:

2015-06-02 20:05:24.796 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [6]: 00 00 00 00 00 00
2015-06-02 20:05:25.116 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [5]: 00 00 00 00 00
2015-06-02 20:05:25.436 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [1]: 00
2015-06-02 20:05:25.757 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [8]: 00 00 00 00 00 00 00 00
2015-06-02 20:05:26.396 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [9]: 00 00 00 00 00 00 00 00 00
2015-06-02 20:05:26.568 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [1]: 00
2015-06-02 20:05:27.556 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [8]: 00 00 00 00 00 00 00 00
2015-06-02 20:05:27.880 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [4]: 00 00 00 00
2015-06-02 20:05:28.196 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [12]: 00 00 00 00 00 00 00 00 00 00 00 00
2015-06-02 20:05:28.840 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [12]: 00 00 00 00 00 00 00 00 00 00 00 00
2015-06-02 20:05:29.328 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [5]: 00 00 00 00 00
2015-06-02 20:05:29.648 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [3]: 00 00 00
2015-06-02 20:05:30.288 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [17]: e0 ce 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03 00
2015-06-02 20:05:30.640 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [1]: 00
2015-06-02 20:05:30.960 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [9]: 00 00 00 00 00 00 00 00 00
2015-06-02 20:05:31.768 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [17]: e0 ce 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03 00
2015-06-02 20:05:32.087 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [5]: 00 00 00 00 00
2015-06-02 20:05:32.408 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [2]: 00 00
2015-06-02 20:05:33.048 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [7]: 00 00 00 00 00 00 00
2015-06-02 20:05:33.372 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [1]: 00
2015-06-02 20:05:33.720 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [2]: 00 00
2015-06-02 20:05:34.208 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [4]: 00 00 00 00
2015-06-02 20:05:34.848 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [12]: 00 00 00 00 00 00 00 00 00 00 00 00
2015-06-02 20:05:35.172 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [5]: 00 00 00 00 00 8

[update]


???? Ich hab seit meinem letzten Update nix geändert, und auf einmal kommen die Daten wieder beinahe ohne "dropped data" an...?! Jetzt wurden auch wieder Finger erkannt. Ich werd' noch verrückt.... Weiter testen....


[update]
Ah, jetzt. Hatte im letzten Logmitschnitt nach "Dropped data" ge'grep'ed.
Scheinbar sind die 120Ohm Abschlusswiderstand tatsächlich des Rätsels Lösung. Offenbar hab ich, wieso auch immer, Reflektionen die nun weitgehend ausradiert werden. Die meisten fehlerhaften Bytes sind nun tatsächlich, wenn dann 0x00. Nur noch ab und an sind andere Bytes mit drin. Das könnte aber noch an meinem "ungeraden 120Ohm" liegen. Muss mir mal glatte 120Ohm Widerstände zulegen.

Ich teste weiter ....


[update]

Widerstände sind bestellt (ebay als "Apotheke" was Elektronik-Bauteile betrifft ist billiger als Reichelt?). Das mit den 5-Widerständen passt nicht in den Adapter und sieht doof aus.
Mit den 5x620Ohm parallel ist das ganze aber schon recht stabil. Hab bis jetzt noch keinen Nicht-Erkannten Finger-Frame hin bekommen....

Vielleicht gieße ich das ganze irgendwann in einen Arduino-Sketch und verheirate das direkt mit KNX. Aber dann bräuchte ich zwei serielle Schnittstellen am Arduino: Eine zum Lesen des RS485 ICs und eine zum Senden per TpUart auf den KNX-Bus ... Wenn das mal nicht zu viel (Timingmäßig) für den Arduino ist... Mal schauen.

[UweH]

Nur zum Verständnis:

Wenn die Widerstände gegen Vcc und Gnd "okay" sind, dann dürfte ich, wenn ich die Datenleitungen zum ekey weglasse, doch kein einziges Byte empfangen, oder?

Hab jetzt den Abschlusswiderstand und die Leitungen zum ekey weggelassen. Kommt kein einziges Byte. Dann wäre ja alles im Lot, oder?

"Kein einziges Byte" heisst nur, dass der Komparator im MAX485 nicht umgeschaltet hat, weil die 0.2V nicht über/unterschritten wurde. Es heißt nicht, dass in rauher Umgebung alles funktionieren wird. Messtechnisch würde man zum Test mal 1V Wechselspannung kapazitiv einkoppeln. Eine richtig ausgelegte RS485 bringt das nicht aus der Ruhe, eine ohne Bias dagegen schon.

Du bringst mich auf eine Idee: Lass mal die Datenleitungen zum ekey weg und miss mit einem Multimeter am USB-Dongle die Spannung zwischen den RS485-Klemmen. Wenn ein Bias-Netzwerk drin wäre, wären das irgendwas zwischen 0.5 und 3 Volt, schätz ich.

Ohne Datenleitungen herrscht Stille - ja. Auch mit 2m Kabel wird sich daran nicht viel ändern. Der MAX485 braucht +/- 0.2V bevor er an seinem Ausgang 'was ändert.
An sich ist die RS485 sehr robust ausgelegt und nimmt Störspannungen nicht krumm, weil mit mehreren Volt und differenziell gearbeitet wird. Ungenaue Abschlüsse und Kabeltypen spielen nur eine Rolle, wenn die Ausbreitungszeit ansatzweise in die Größenordnung der Bitzeit kommt. Aber bei 115k = ca. 3km Wellenlänge ist das in unserer Anwendung völlig im grünen Bereich.

Eine 0x00 entsteht bei der seriellen Übertragung, wenn der Pegel von "passiv"(entspricht 1) auf "aktiv"(entspricht 0) wechselt und dort bleibt: Der Wechsel wird als Startbit interpretiert, dann alle Datenbits 0. Das Stop-Bit wird mit 1 erwartet, und je nach Konfiguration würde der Receiver das Byte daher auch verwerfen oder zumindest einen Frame-Error werfen. Weiß nicht, wie die Implementierung ist, aber kann ja sein, dass die Dauer-0 als Folge von 0x00 in der Software ankommt. Test dazu: Eine 1.5V-Batterie an den Bus halten (beide Richtungen probieren). In einer Richtung kommen keine Daten, da nur der Ruhezustand "stabilisiert" wird, in der anderen kommen vermutlich die 0x00er.

Das könnte aber noch an meinem "ungeraden 120Ohm" liegen. Muss mir mal glatte 120Ohm Widerstände zulegen.

Jetzt wirds aber zu esotherisch ;-) Glaub mir: Den Unterschied zwischen 100, 120, 200 Ohm wird man nicht messen können.
Wenn man in die Richtung gehen will, dann bitte 120 Ohm an beiden Enden der Leitung (und NUR da). Damit könnte man dann auch 10 Megabit/s übertragen. Und Ruhepegel mittels Bias-Netzwerk einstellen. (Ich weiß, ich wiederhol mich ;-)

[tuxedo]

"Kein einziges Byte" heisst nur, dass der Komparator im MAX485 nicht umgeschaltet hat, weil die 0.2V nicht über/unterschritten wurde. Es heißt nicht, dass in rauher Umgebung alles funktionieren wird. Messtechnisch würde man zum Test mal 1V Wechselspannung kapazitiv einkoppeln. Eine richtig ausgelegte RS485 bringt das nicht aus der Ruhe, eine ohne Bias dagegen schon.

Wechselspannung von 1V kapazitiv einkoppeln: Das gibt meine Bastelecke nicht her :-(

Du bringst mich auf eine Idee: Lass mal die Datenleitungen zum ekey weg und miss mit einem Multimeter am USB-Dongle die Spannung zwischen den RS485-Klemmen. Wenn ein Bias-Netzwerk drin wäre, wären das irgendwas zwischen 0.5 und 3 Volt, schätz ich.

Das ist in der Tat eine gute Idee. Auch wenn es aktuell zu funktionieren scheint: Ich werde das heute Abend mal testen. Bzgl. des Bereichs 0,5..3V ... Wichtig wäre da doch nur, dass dieser sich hinreichend gut von 0.2V nach oben hin abgrenzt, richtig?

Ohne Datenleitungen herrscht Stille - ja. Auch mit 2m Kabel wird sich daran nicht viel ändern. Der MAX485 braucht +/- 0.2V bevor er an seinem Ausgang 'was ändert.
An sich ist die RS485 sehr robust ausgelegt und nimmt Störspannungen nicht krumm, weil mit mehreren Volt und differenziell gearbeitet wird. Ungenaue Abschlüsse und Kabeltypen spielen nur eine Rolle, wenn die Ausbreitungszeit ansatzweise in die Größenordnung der Bitzeit kommt. Aber bei 115k = ca. 3km Wellenlänge ist das in unserer Anwendung völlig im grünen Bereich.

Das würde aber heissen, dass bei meinen ca. 7-8m theoretisch kein wirklicher Abschlusswiderstand nötig ist? Faktisch scheint er aber nötig zu sein.
Da mein RS485 USB Adapter, wie ich schon schrieb, 2kOhm Widerstände gegen Vcc und Gnd hat (und somit ein Bias gegeben sein sollte, was ich aber nochmal nachmessen werde), ist es doch eher unwahrscheinlich dass die Störungen von zu ungenauen Referenzspannungen durch fehlende Widerstände kommen.
Bleitb doch eigentlich nur noch STörungen durch Reflektion die durch fehlende Abschlusswiderstände unschädlich gemacht werden, oder?

Eine 0x00 entsteht bei der seriellen Übertragung, wenn der Pegel von "passiv"(entspricht 1) auf "aktiv"(entspricht 0) wechselt und dort bleibt: Der Wechsel wird als Startbit interpretiert, dann alle Datenbits 0. Das Stop-Bit wird mit 1 erwartet, und je nach Konfiguration würde der Receiver das Byte daher auch verwerfen oder zumindest einen Frame-Error werfen. Weiß nicht, wie die Implementierung ist, aber kann ja sein, dass die Dauer-0 als Folge von 0x00 in der Software ankommt.

Die Daten des RS485-USB-Adapters nimmt erstmal "ser2net" entgegen und stellt diese via Socketserver im Netzwerk bereit. Meine Java-Anwendung verbindet sich dann per Netzwerk mit diesem Socketserver und nimmt die Daten in Empfang. Ich bezweifle dass ser2netz oder auch Java eine dauerhafte 0 als viele 0x00 Bytes ausspuckt. Das wird wenn, dann irgendwo im Kernel passieren. Aber da hab ich keinen Einfluss drauf. Aber wenn ich mir meine zwei anderen RS485 Projekte so anschaue und da vergleiche, dann bezweifle ich dass dem tatsächlich so ist. Ich vermute eher, dass das vorhandene Bias-Netz nicht optimal dimensioniert ist. Aber das kann ich ja mal nachmessen.

Test dazu: Eine 1.5V-Batterie an den Bus halten (beide Richtungen probieren). In einer Richtung kommen keine Daten, da nur der Ruhezustand "stabilisiert" wird, in der anderen kommen vermutlich die 0x00er.

Werde ich testen.

Jetzt wirds aber zu esotherisch ;-) Glaub mir: Den Unterschied zwischen 100, 120, 200 Ohm wird man nicht messen können.
Wenn man in die Richtung gehen will, dann bitte 120 Ohm an beiden Enden der Leitung (und NUR da). Damit könnte man dann auch 10 Megabit/s übertragen. Und Ruhepegel mittels Bias-Netzwerk einstellen. (Ich weiß, ich wiederhol mich ;-)

Okay, okay. Ich seh's ja ein. Rechnerisch liege ich ja auch nur 4 Ohm daneben. Allein schon die Toleranz (auf dem Papier) der Widerstände beträgt (in meiner Bastelkiste zumindest) 1,2Ohm. Verbleiben lächerliche 2,8 Ohm...

Nichts desto trotz: Ein 120Ohm Widerstand ist sauberer/besser als 5x620Ohm parallel an den Adapter gebastelt ;-) Werde dann mal oben genannte Tipps zum messen ausprobieren und wieder berichten. Wäre ja super wenn ich mit etwas Feintuning die Stör-Bytes (nahezu) ganz weg bekomme.

[Onkelandy]

Hallo zusammen!

Wäre jemand so lieb und würd mir beim Anschluss des USB Adapters helfen? Ich habe einen ekey Home und den China USB adapter:
http://www.ebay.at/itm/PL2303HX-Chip...item19f8a87d33

Wenn ich jetzt gelb und grün vom ekey zum Adapter anschließe, findet der ekey keinen Fingerscan. Ich vermute, dass die Kabel vom Scanner zuerst in den Adapter müssen und von dort weiter in den ekey home? Möchte das aber nicht einfach so ausprobieren bzw. ist auch unklar, ob nun grün oder gelb ins D+ sollte

Vielen lieben Dank für die Hilfe!

[UweH]

Wenn ich jetzt gelb und grün vom ekey zum Adapter anschließe, findet der ekey keinen Fingerscan. Ich vermute, dass die Kabel vom Scanner zuerst in den Adapter müssen und von dort weiter in den ekey home?

Nein, in welcher Reihenfolge die drei Komponenten (Scanner, Steuerung, Dongle) am Bus angeschlossen sind, spielt keine Rolle. Bei mir sind Scanner und Steuerung original in der Tür verdrahtet, und dann geht das orgininal-8 polige Kabel ca. 5m bis zur "Bastelei".

Möchte das aber nicht einfach so ausprobieren bzw. ist auch unklar, ob nun grün oder gelb ins D+ sollte

Ich denk, mit ausprobieren wird man nichts kaputtmachen. Ggf. klappt die Kommunikation nicht mehr.
Bei mir geht grün auf den Pin 7 vom Max485, gelb auf den Pin 6. An meinem Adapter heißt der Pin 7 dann B und D-, aber ob man sich darauf verlassen kann bei den Chinesen ;-) Einfach mal aufmachen und schaun die Pins 6 und 7 nachverfolgen.

[Onkelandy]

Danke UweH, dann versuch ich es nochmals.. komisch, dass bei mir der Scanner nicht mehr erkannt wurde, sobald die anderen zwei Drähte auch mit im Home ekey angeklemmt waren. Ich meld mich wieder, sobald ich mehr weiß Danke!!!

[tuxedo]

Hatte auch die Belegung ausprobieren müssen, da es bei mir überhaupt nicht vorgesehen war RS485 heraus zu führen.

So, hab nun auch die Messung zwischen den Adern (ohne Abschlusswiderstand und angeschlossene Datenleitungen): +-4,77V

Das klingt, als ob das ganze dann im Betrieb "zu Nahe" am undefinierten Zustand ist, oder? Sind ja nur 0,23V übrig und somit sehr nahe an den vielzitierten 0,2V dran.

Hab ich das korrekt interpretiert?

Zum dranhängen der 1,5V Spannung bin ich noch nicht gekommen.

[UweH]

Bias-Netzwerk-Faktencheck: Mein Dongle hat tatsächlich je 2.2k bestückt von Datenleitung nach Masse bzw. Versorgung. Am Dongle hab ich (ohne Last) 4,9V anliegen. Mit 120 Ohm Last (zwischen A und B) verringert sich die Spannung auf 140mV, was rechnerisch gut passt: Es entsteht an 5V ein Spannungsteiler aus 2k + 120 Ohm + 2k.

Es ist also - entgegen meiner Erwartung - ein Bias-Netzwerk vorhanden. In meiner Konstellation mit Laptop hatte ich trotzdem 0x00 zwischen den Frames, und verlorene Start-Bytes, weil die 140mV eben nicht weit weg von den Schaltpunkten sind. In der jetzigen Konfiguration habe ich 820 Ohm nach Versorgung und Ground, aber keine zusätzliche 120 Ohm. Weiss jetzt nicht mehr genau, aber könnte sein, dass ich den ekey mal stromlos gemessen hatte und dort die 120 Ohm fand, oder 's geht auch ohne.

[UweH]

So, hab nun auch die Messung zwischen den Adern (ohne Abschlusswiderstand und angeschlossene Datenleitungen): +-4,77V

Deckt sich mit meiner Messung.

Das klingt, als ob das ganze dann im Betrieb "zu Nahe" am undefinierten Zustand ist, oder? Sind ja nur 0,23V übrig und somit sehr nahe an den vielzitierten 0,2V dran.

Hab ich das korrekt interpretiert?

Nein. Eine Differenzspannung (zwischen A und B) ist GUT, wenn sie groß ist. Weil im Bereich -0.2 bis +0.2V ist der Emfänger nicht in der Lage, eindeutig zu reagieren. Also sind deine 4.77 eine gute Basis.
[/QUOTE]

[tuxedo]

Deckt sich mit meiner Messung.

Nein. Eine Differenzspannung (zwischen A und B) ist GUT, wenn sie groß ist. Weil im Bereich -0.2 bis +0.2V ist der Emfänger nicht in der Lage, eindeutig zu reagieren. Also sind deine 4.77 eine gute Basis.

Leider zu spät :-( Hab die eingebauten Vorwiderstände (ausgebaut gemessen: 2,4kOhm) ausgebaut und durch 5kOhm ersetzt. jetzt liegt die Spannung bei ca. 3,8V. Die vielen 0x00 sind nun weniger, aber dafür werden andere Pakete wieder nicht sauber erkannt.

Also Kommando wieder zurück und die SMD Dinger wieder reinfummeln ... (hab zum Glück noch einen Ersatz-Empfänger da...)

[UweH]

.. komisch, dass bei mir der Scanner nicht mehr erkannt wurde, sobald die anderen zwei Drähte auch mit im Home ekey angeklemmt waren.

Wenn der Dongle verkehrt herum angeschlossen ist, zieht sein internes Bias-Netzwerk den Buspegel auf "dominant", anstatt das "rezessiv" zu stabilisieren. Die Empfänger finden dann das Startbit nicht mehr. Irgendjemand schrieb mal, dass dann die ekey-Steuerung im Display einen countdown runterzählt und immer wieder neu probiert.

[tuxedo]

Irgendjemand schrieb mal, dass dann die ekey-Steuerung im Display einen countdown runterzählt und immer wieder neu probiert.

Das war ich ;-) Jetzt wo du's sagt erinnerst du mich wieder dran... Wenn man's falsch herum anschließt läuft in der Tat in der Türsteuerung im Türblatt am Display ein Countdown.

[Onkelandy]

Soda, ich hab's jetzt nochmals mit einem zweiten Adapter versucht, baugleich. Leider das gleiche Problem: es wird kein FS gefunden und Countdown. Egal, wie rum ich es anschließe. An den Klemmen liegt's nicht, denn ohne Anschluss am Adapter klappt alles, FS wird nach wenigen Sekunden gefunden.

Irgendwer ne Idee? Ich dachte, dass ich den Adapter geordert hab, der hier mal gepostet wurde.. Merciiii!

[tuxedo]

Mein Adapter sieht aus wie deiner. Wie sieht denn deine Steuereinheit an der Tür aus?

[Onkelandy]

Ich habe den ekey home 2 SE REG und irgendwie blind dem Elektriker vertraut, dass er zumindest die richtige Kabelfarbe nimmt. Tja... War letztlich nur der falsche Pin (3 statt 2). Glück gehabt, dass nix kaputt gegangen ist. Jetzt wird der FS ganz normal gefunden, juhu, Danke für die Ermutigungen
http://www.ekey.net/downloads?downlo...inheit_REG.pdf

Hmmm. allerdings gibts bei meinem Raspi beim Start des hier verlinkten JAR Files einen soliden Fatal Error. Ist die Kiste zu mau dafür ?

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0xac7523a0, pid=18424, tid=3056972912
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b132) (build 1.8.0-b132)
# Java VM: Java HotSpot(TM) Client VM (25.0-b70 mixed mode linux-arm )
# Problematic frame:
# C  [tmp_3843961602216977192_librxtxSerial.so+0x33a0]  _init+0x54f
#
# Core dump written. Default location: /home/pi/core or core.18424
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x004487b8):  JavaThread "main" [_thread_in_native, id=18425, stack(0xb630c000,0xb635c000)]

siginfo:si_signo=SIGILL: si_errno=0, si_code=1 (ILL_ILLOPC), si_addr=0xac7523a0

Registers:
  r0  = 0x00000005
  r1  = 0xbedf7824
  r2  = 0x000001c0
  r3  = 0x00000000
  r4  = 0x00000005
  r5  = 0xbedf7824
  r6  = 0xac6aca30
  r7  = 0x004a8c38
  r8  = 0xbedf7824
  r9  = 0xb6f3a048
  r10 = 0x00000005
  fp  = 0xb63591d4
  r12 = 0xb63593a8
  sp  = 0xb6359118
  lr  = 0xac751e57
  pc  = 0xac7523a0
  cpsr = 0xa0000030

Top of Stack: (sp=0xb6359118)
0xb6359118:   ac751e51 b6f23210 004a8c38 00000001
0xb6359128:   00000000 ac6aca30 004a8c38 bedf7824
0xb6359138:   00000005 b6f2336c ac6aca30 b6f3a560
0xb6359148:   ac6acb8c b6f3a048 00000004 00000004
0xb6359158:   00000001 b6f273b8 00000001 b6f3a094
0xb6359168:   ac6aca30 ac6aca30 80000000 00000000
0xb6359178:   23ed23af 6b0ec313 6e5f4f79 4ce722d7
0xb6359188:   8a21d87b 0671ba46 c826cfa7 b6359170

Instructions: (pc=0xac7523a0)
0xac752380:   e28fc600 e28cca0d e5bcf9f4 e28fc600
0xac752390:   e28cca0d e5bcf9ec 4a044b03 589b447b
0xac7523a0:   f7ffb10b 4770bedf 0000d830 000001c0
0xac7523b0:   b5084a09 4b09447a 447b7812 4a08b95a

Register to memory mapping:

  r0  = 0x00000005
0x00000005 is an unknown value

  r1  = 0xbedf7824
0xbedf7824 is an unknown value

  r2  = 0x000001c0
0x000001c0 is an unknown value

  r3  = 0x00000000
0x00000000 is an unknown value

  r4  = 0x00000005
0x00000005 is an unknown value

  r5  = 0xbedf7824
0xbedf7824 is an unknown value

  r6  = 0xac6aca30
0xac6aca30 is an unknown value

  r7  = 0x004a8c38
0x004a8c38 is an unknown value

  r8  = 0xbedf7824
0xbedf7824 is an unknown value

  r9  = 0xb6f3a048
0xb6f3a048: _rtld_global+0 in /lib/ld-linux-armhf.so.3 at 0xb6f14000

  r10 = 0x00000005
0x00000005 is an unknown value

  fp  = 0xb63591d4
0xb63591d4 is pointing into the stack for thread: 0x004487b8

  r12 = 0xb63593a8
0xb63593a8 is pointing into the stack for thread: 0x004487b8

  sp  = 0xb6359118
0xb6359118 is pointing into the stack for thread: 0x004487b8

  lr  = 0xac751e57
0xac751e57: <offset 0x2e57> in /tmp/rxtx-rebundled-2.1-7r36546552155968785205/tmp_3843961602216977192_librxtxSerial.so at 0xac74f000

  pc  = 0xac7523a0
0xac7523a0: <offset 0x33a0> in /tmp/rxtx-rebundled-2.1-7r36546552155968785205/tmp_3843961602216977192_librxtxSerial.so at 0xac74f000



Stack: [0xb630c000,0xb635c000],  sp=0xb6359118,  free space=308k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [tmp_3843961602216977192_librxtxSerial.so+0x33a0]  _init+0x54f

Unter Windows startet soweit mal alles prima. Allerdings heißt es dann WARNING - Stream finished. Entweder sofort in der ersten Zeile oder nach folgender Meldung (nachdem ich grün und gelb getauscht habe.. interessanterweise hat nun der ekEy beide Anschlussvarianten geschluckt..)

2015-06-06 08:27:30.996 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: tail wrong
2015-06-06 08:27:31.000 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: Raw Frame: 02 46 92 f9 00 3f 63 63 f8 e0 28 21 42 b8 b0 e3 f0 a8 b
0
2015-06-06 08:27:31.075 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: tail wrong
2015-06-06 08:27:31.077 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: Raw Frame: 02 5e 0c 03 13 d4 18 f2 00 3f 63 63 f8 e0 28 21 42 b8 b
0 e3 f0 a8 b0 44 00
2015-06-06 08:27:31.275 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: tail wrong
2015-06-06 08:27:31.276 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: Raw Frame: 02
2015-06-06 08:27:31.476 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: tail wrong
2015-06-06 08:27:31.481 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: Raw Frame: 02 59 0d 44 4a f9 00 3f 63 63 f8 e0 28 21 42 b8 b0 e3 f
0 a8 b0 44 00 3f 47 db fc fc 28 f9 f8 54 6c 32 fa dc ec fe 26 7e bb 92 ab 02 a4
54 a9 50 f2 00 3f 45 63 e8 f8 28 21 42 b8 b0 e3 f0 a8 b0 44 f4 30 c2 3c 54 fc 78
 a1 85 14 57 0a 29 17 2e 7e 3f 45 b3 fe fc 28 f9
2015-06-06 08:27:31.598 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: tail wrong
2015-06-06 08:27:31.599 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: Raw Frame: 02 40 92 8a cc ff f2 00 3f 63 63 f8 e0 28 21 42 b8
2015-06-06 08:27:31.716 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: tail wrong
2015-06-06 08:27:31.719 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.f
rameReceived: Raw Frame: 02 bb 12 1a 23 0c 1f 6a 10 fd f2 00 3f 63 63 f8 e0 28 2
1 42 b8 b0 e3 f0 a8 b0 44 00 bf e4 b3 fe 94 fc fc 54 d8 99 3f 87 b7 0a cc fd 76
4d 3b 29
2015-06-06 08:27:31.796 WARNING [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.r
un: Stream finished