eKey Fingerscanner per RS485 auslesen: Protokollanalyse

[tuxedo]

Das mit dem Sniffen hatte ich nur vorgeschlagen, falls Uwe noch Material zum CRC-Rumrechnen braucht

Ich glaube er hat da noch mehrere Tage Dump-Daten auf Vorrat ;-)
Werde aber ggf. in einem Update des Tools noch einen Dump-Logger einbauen, so dass automatisch ein Dump mitgeloggt wird (wenn man es denn einschaltet). Damit wäre dann die Basis für die weitere Forschung gegeben.
Aber so finde ich, funktioniert das schon recht gut. Und gerade die Lern-Funktion (die noch fehlt) sollte das System recht einfach in der Handhabung machen.

Freue mich über Feedback.

Gruß
Alex

[tuxedo]

Hab eben feststellen müssen, dass mein Tool (mal wieder) hängen geblieben ist. Ist also noch nicht ganz Fehlerfrei, aber auf dem besten Weg dahin...
Werde den Fehler mal suchen gehen...

[update]

So wirklich hängen geblieben ist das Tool doch nicht. Es läuft und läuft und liest fleissig Frames... Aber einen Finger hat es angeblich seit Tagen nicht mehr gescanned/gefunden. Das Log füllt schnell im Debug einige hundert MB. Werde wohl öfters da rein schauen müssen damit da nix ungesehen aus dem Log rotiert.

[tuxedo]

Hab den Source mal nach Github geschoben:

https://github.com/tuxedo0801/ekeydecoder

Lizenz: GPL

Habs aber noch nicht weiter dokumentiert.

Bzgl. den aktuellen Erkennungsproblem:

Es werden nach wie vor die 30 und 31byte langen Frames erkannt. Aber die 47bytes langen Fingerhash-Frames tauchen nicht mehr auf. --> Äußerst seltsam.

UweH
Hattest du das bei dir auch schon? Startest du deinen AVR regelmäßig neu oder machst du ab und an mal einen Reset?

Ab und an hab ich Fehler in den Frames. In solchen Fällen stimmt meist das letzte Byte im Frame nicht (0x03 muss es ja sein). Hab mir die Sache noch nicht genauer angeschaut.
Dachte erst dass der korrekte Frame-Anfang in der Erkennung irgendwie "verrutscht" sei. Aber als noch Finger korrekt erkannt wurden gab es ja auch schon 30 und 31 byte lange Frames. Die gibt es jetzt immer noch. Wenn - aus welchen Gründen auch immer - der Anfang an einer falschen Stelle erkannt werden würde, dann gäbe es doch nicht nach wie vor 30 und 31 byte lange Frames?!

Gruß
Alex

[tuxedo]

*Hiiilfe*

Mein ekey spinnt ...

Hab jetzt mal den Laptop neben die Haustür gestellt:

Finger scannen liefert keinerlei "spezielle" 47 Bytes-Lange Nachricht mehr.

Anwendung neu starten bringt keine Besserung.
ekey kurz stromlos machen (--> Reset) bringt kurzzeitig teilweise Besserung: Ich seh nur Finger-Hash-Frames für einen meiner beiden Zeigefinger. Die Tür öffnet aber jedesmal. Quittierungs-LED wird auch grün. Zwischen zwei resets wird nur einer der beiden Zeigefinger erkannt. Aber wenn, dann nur der eine. Aber nicht bei jedem mal. Nach 2-4mal erkanntem Finger wird dann kein Finger mehr erkannt.

Ich steh total auf dem Schlauch... Mein ekey wird wohl nicht immun gegen das Auslesen des Fingerhashs werden?!

Was mir aber noch aufgefallen ist: Während im Betrieb nur die 30, 31 und 16 byte, sowie die Fingerhash-Frames mit 47 byte langen Frames kommen, kommt kurz nach den Power-Reset auch eine 54 byte lange Nachricht.
Ggf. ist das Teil der "Schlüsselbekanntgabe"?

Aber zurück zum Thema: HILFE!

Hat jemand ne Idee was ich noch probieren könnte oder sogar was die Ursache sein könnte?

Gruß
Alex

[UweH]

Hab den Source mal nach Github geschoben:

https://github.com/tuxedo0801/ekeydecoder

Bzgl. den aktuellen Erkennungsproblem:

Es werden nach wie vor die 30 und 31byte langen Frames erkannt. Aber die 47bytes langen Fingerhash-Frames tauchen nicht mehr auf. --> Äußerst seltsam.

UweH
Hattest du das bei dir auch schon? Startest du deinen AVR regelmäßig neu oder machst du ab und an mal einen Reset?

Ab und an hab ich Fehler in den Frames. In solchen Fällen stimmt meist das letzte Byte im Frame nicht (0x03 muss es ja sein). Hab mir die Sache noch nicht genauer angeschaut.

:-) Nein, ich starte keine AVRs neu, und sie starten sich auch nicht selber neu. Ich schätze Stabilität sehr, und wenn nicht durch irgendwelche Umbau- oder Hochflash-Aktionen ein Neustart passiert, laufen die über Jahre ohne Reset. Ganz im Gegensatz zum Raspberry, der alle paar Wochen mal in den Watchdog läuft.

Ich hatte ein ähnliches Erkennungsproblem: mehr oder weniger sporadisch wurden die langen Frames nicht richtig dekodiert. Vier Dinge fallen mir ein:
- die Sache mit dem Ruhepegel: 0 Volt Differenzspannung zwischen den Leitungen sind ein undefinierter Zustand. Scheint ekey-intern kein Problem zu sein, weil keine großen Störpegel zu erwarten sind. Aber wenn andere Teilnehmer und/oder lange, störeinkopplungsempfindliche Leitungen dazu kommen, kann da schon mal Müll rauskommen: Empfänger verliert die Synchronisation, interpretiert Daten falsch. Abhilfe: Bias-Netzwerk (siehe Wikipedia RS485).
- Die Bitrate: Wie schon weiter oben beschrieben, verwendet ekey für den Scanner und die Zentraleinheit leicht unterschiedliche Baudraten, nicht genau die 115k. Wenn der PC-Dongle nun auch irgendwo daneben liegt, könnte die Erkennung grenzwertig sein. Schwierig zu debuggen; was mir einfiel ist mal mit dem Dongle z.B. eine 0x55 zu senden (ohne ekey-Verbindung natürlich), und mit dem Oszi rauszumessen.
- Extrem-Masseversatz: Wenn PC und ekey keine gemeinsame Masse haben, können die Cs im Netzteil einen Masseversatz bewirken. Die RS485 ist zwar dafür ausgelegt, damit umgehen zu können, aber irgendwo ist ja eine Grenze. Hatte in einem ähnlichen Fall schon mal 125V AC!
- Echtzeit-Performance des Auswerters: Hatte in meinem AVR am Anfang noch einen laaaangsamen Software-SPI-Treiber für den CAN-Baustein, der hat den RS485-Empfang ab und zu blockiert, so dass ein oder zwei Bytes verloren gingen, besonders bei den längeren Frames. Daher hab ich in dem Auswerter Zähler eingebaut, die solche Främelängen-Abweichungen von 1 Byte sichtbar machen. Das wäre auch mein Ansatz für Dein Problem: Wenn die Frame-Ende-Kennung nicht an der erwarteten Position steht, könnte sich ja 1, 2, 3, .. Positionen davor auftauchen. Das wäre dann der Beweis, dass Bytes verloren gegangen sind.

Zu den 30/31 Byte: Die Främelängen variieren wegen des Byte-Stuffings: Wenn z.B. eine 02 in den Daten enthalten ist, muss diese expandiert werden (--> Frame wird ein Byte länger). Das kann mehrfach oder auch gar nicht der Fall sein. Die absolute Länge jittert also, und ist eigentlich uninteressant. Interessant ist, ob die Längeninfo am Beginn des Frames und die Position des 03er Endebyte zusammen passen. Das sollte immer der Fall sein, egal wie lang der Frame ist. Wenn das nicht passt, ist die Ursache in Hardware- oder Low-Level-Software versteckt.

Viel Erfolg bei der Suche,
Uwe

[tuxedo]

:-) Nein, ich starte keine AVRs neu, und sie starten sich auch nicht selber neu. Ich schätze Stabilität sehr, und wenn nicht durch irgendwelche Umbau- oder Hochflash-Aktionen ein Neustart passiert, laufen die über Jahre ohne Reset. Ganz im Gegensatz zum Raspberry, der alle paar Wochen mal in den Watchdog läuft.

Okay, dann ist der Code offenbar fehlerfrei. Hätte mich jezt auch gewundert, weil von der Struktur her sieht er weniger danach aus als ob sich da etwas "aufschaukeln" könnte.

Bzgl. Raspi... Naja, wenn man die entsprechend konfiguriert und wo möglich auf read-only setzt, laufen die dauerhaft fehlerlos. Aber für diesen Fall hab ich keinen Raspi am laufen, sondern einen ausgewachsenen Rechner (der noch vieles andere fehlerfrei ausführt). Von daher schließe ich mal einen direkten Hardwarefehler aus.

[/quote]
Ich hatte ein ähnliches Erkennungsproblem: mehr oder weniger sporadisch wurden die langen Frames nicht richtig dekodiert. Vier Dinge fallen mir ein:
- die Sache mit dem Ruhepegel: 0 Volt Differenzspannung zwischen den Leitungen sind ein undefinierter Zustand. Scheint ekey-intern kein Problem zu sein, weil keine großen Störpegel zu erwarten sind. Aber wenn andere Teilnehmer und/oder lange, störeinkopplungsempfindliche Leitungen dazu kommen, kann da schon mal Müll rauskommen: Empfänger verliert die Synchronisation, interpretiert Daten falsch. Abhilfe: Bias-Netzwerk (siehe Wikipedia RS485).
[/quote]

Dann wäre die Symptome doch aber anders? Ich krieg aktuell saubere Frames, mit 30 und 31 byte Länge, sowie auch 16 byte länge. Sieht alles "bekannt" aus und deckt sich mit den Dumps von vor Monaten.

- Die Bitrate: Wie schon weiter oben beschrieben, verwendet ekey für den Scanner und die Zentraleinheit leicht unterschiedliche Baudraten, nicht genau die 115k. Wenn der PC-Dongle nun auch irgendwo daneben liegt, könnte die Erkennung grenzwertig sein. Schwierig zu debuggen; was mir einfiel ist mal mit dem Dongle z.B. eine 0x55 zu senden (ohne ekey-Verbindung natürlich), und mit dem Oszi rauszumessen.

Hab leider kein Oszi zur Verfügung. Wenn die Baudrate ab und an wegen Toleranzen mal nicht passt, dann müsste ich doch "seltsame" frames haben. und vor allem müsste es auch vermehrt fehlerhafte Frames geben, oder?

Das einzig "seltsame" das ich aber sehen kann ist, dass schlicht und einfach keine 47byte langen Frames mehr auftauchen. So als würden gar keine gesendet?

- Echtzeit-Performance des Auswerters: Hatte in meinem AVR am Anfang noch einen laaaangsamen Software-SPI-Treiber für den CAN-Baustein, der hat den RS485-Empfang ab und zu blockiert, so dass ein oder zwei Bytes verloren gingen, besonders bei den längeren Frames. Daher hab ich in dem Auswerter Zähler eingebaut, die solche Främelängen-Abweichungen von 1 Byte sichtbar machen. Das wäre auch mein Ansatz für Dein Problem: Wenn die Frame-Ende-Kennung nicht an der erwarteten Position steht, könnte sich ja 1, 2, 3, .. Positionen davor auftauchen. Das wäre dann der Beweis, dass Bytes verloren gegangen sind.

Naja, mir stehen 1,6Ghz Rechenleistung zur Verfügung. Das sollte allemal ausreichen um die Daten schnell genug zu lesen und zu interpretieren.
Und wie gesagt: Es "fehlen" schlicht und einfach in 80-90% der Fälle die 47byte langen Frames. Stattdessen gibt es auch keinerlei "seltsame" Frames mit unüblichen Längen.

Zu den 30/31 Byte: Die Främelängen variieren wegen des Byte-Stuffings: Wenn z.B. eine 02 in den Daten enthalten ist, muss diese expandiert werden (--> Frame wird ein Byte länger). Das kann mehrfach oder auch gar nicht der Fall sein. Die absolute Länge jittert also, und ist eigentlich uninteressant. Interessant ist, ob die Längeninfo am Beginn des Frames und die Position des 03er Endebyte zusammen passen. Das sollte immer der Fall sein, egal wie lang der Frame ist. Wenn das nicht passt, ist die Ursache in Hardware- oder Low-Level-Software versteckt.

Ja, Byte-Stuffing hab ich ja von dir gelernt... Die Längeninfo am Anfang des Frames passt zum Länge des Frames bis zum 03er Byte.
Nur ab und zu kommt es vor dass am Ende des Frames kein 0x03 steht. Kommt das bei dir auch vor? Oder werden fehlerfrei _immer_ alle Frames korrekt gelesen?
meine bisherige Annahme war, dass das nicht störend ist, weil der Frame dann einfach verworfen wird un der nächste Frame gesucht wird. Und der sieht offenbar wieder okay/bekannt aus.
Auch ist es so, dass wenn der Fehler auftritt, gerade gar kein Finger gescanned wird. Sprich: Wenn ein Finger gescanned wird, sehe ich entweder den 47 byte langen Frame, der ich sehe nur die üblichen 30/31/16 byte langen Frames, aber keinerlei Fehlerframes...

Ist mir echt ein Rätsel. Das mit dem Bias-Netz kann ich noch versuchen. Mich wundert's nur, dass es Tage/Wochenlang zuverlässig lief und jetzt auf einmal zu zicken anfängt.

Gruß
Alex

[UweH]

... Abhilfe: Bias-Netzwerk (siehe Wikipedia RS485).

Dann wäre die Symptome doch aber anders? Ich krieg aktuell saubere Frames, mit 30 und 31 byte Länge, sowie auch 16 byte länge. Sieht alles "bekannt" aus und deckt sich mit den Dumps von vor Monaten.

Du hast mehr oder weniger "sporadische" Frameverluste. Längere Frames haben eine höhere "Verlustrate". Kann also sein, dass einerseits durch den höheren Traffic (kürzere Abstände --> Einschwingproblematik) sich elektrisch 'was verschiebt, andererseits bei längeren Frames die Wahrscheinlichkeit für Störungen einfach höher ist.

Hab leider kein Oszi zur Verfügung. Wenn die Baudrate ab und an wegen Toleranzen mal nicht passt, dann müsste ich doch "seltsame" frames haben. und vor allem müsste es auch vermehrt fehlerhafte Frames geben, oder?

Das einzig "seltsame" das ich aber sehen kann ist, dass schlicht und einfach keine 47byte langen Frames mehr auftauchen. So als würden gar keine gesendet?

Es können ja auch kaputte Frames vorhanden sein, die gar nicht geloggt werden, weil schon die Anfangs-02 kaputt ist. Sieht dann aus wie "nicht gesendet".

Nur ab und zu kommt es vor dass am Ende des Frames kein 0x03 steht. Kommt das bei dir auch vor? Oder werden fehlerfrei _immer_ alle Frames korrekt gelesen?

Gute Frage, das will ich jetzt genau wissen: http://hnng.dd-dns.de:8080/debug2.htm zeigt, dass seit 6.12. keine Fehlerframes mehr auftauchten. Davor hatte ich noch den langsamen SPI-Treiber drin.

Viele Grüße
Uwe

[UweH]

Es können ja auch kaputte Frames vorhanden sein, die gar nicht geloggt werden, weil schon die Anfangs-02 kaputt ist. Sieht dann aus wie "nicht gesendet".

Ich schrieb das unter der Annahme, dass du nur Frames loggst, die den Decoder passiert haben. Wenn du die Empfangsdaten erst mal ungesehen in ein File schreibst, gilt meine Aussage natürlich nicht. Ich würde dann in diesem File aber Indizien erwarten, wie z.B. Ende-Kennung ohne passenden Anfang, oder andersrum.

[tuxedo]

Danke, du hast mich auf eine Idee gebracht wie ich dem Fehler auf die Schliche komme.

Das mit dem Bias-Netzwerk probier ich auf jeden Fall aus.
Und in der Tat werden nur fehlerhafte Frames geloggt, wenn der Anfang erkannt wurde und lediglich das Ende nicht wirklich passt. Die gedroppten Bytes um den Anfang zu finden gehen unter.

[tuxedo]

So, hab meinen Code mal erweitert, so dass ich auch die gedroppten Bytes sehe (hätte ich ja auch alleine drauf kommen können --> BrettVormKopf und so ..).

In der Tat wird da so einiges "gedroppt". Neben wirklich vielen 0x00 sind da auch Teile dabei die zu 90% wie "normale Frames" aussehen, aber hier und da eben ne Macke haben.

Bin gespannt ob ich da dann - noch ohne Bias - während eines Fingerscans der nicht erkannt wird, etwas sehe was in Richtung "47 byte langer Frame" geht.

Gruß und nochmal Danke für den Denkanstoß.

- Alex

[tuxedo]

Vielleicht hat der eine oder andere das gleiche Problem.. Deshalb hier mal exemplarisch einige Daten ist gedroppt wurden:

2015-06-01 15:32:14.445 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:14.765 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [16]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03 e0
2015-06-01 15:32:15.085 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:15.405 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:15.725 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:15.893 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 81 80 a4 81 83 d6 22 d4 80 d6 72 70 51 56 70 41 62 64 65 62 69 60 61 6e 6f 03
2015-06-01 15:32:16.213 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:16.537 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:16.885 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 55 ab 00 22 ea ce 00 00 e0 ce ff fb 00 03
2015-06-01 15:32:17.203 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 56 90 00 22 b9 fe 00 00 29 6f ce 77 00 03
2015-06-01 15:32:17.525 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 57 b4 00 22 ea 1c 00 00 bb 2c ef 77 00 03
2015-06-01 15:32:17.846 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 58 38 00 22 78 b8 00 00 0e 06 df 4a 00 03
2015-06-01 15:32:18.166 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 59 b8 00 22 7a 98 00 00 3b 34 cb 7c 00 03
2015-06-01 15:32:18.333 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 5a 10 00 22 b0 57 00 00 a1 15 bd 7c 00 03
2015-06-01 15:32:18.654 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 5b ea 00 22 a2 d1 00 00 57 e3 bf 7f 00 03
2015-06-01 15:32:18.973 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 5c c4 00 22 32 87 00 00 93 96 f7 fb 00 03
2015-06-01 15:32:19.294 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 5d a6 00 22 18 b2 00 00 23 d9 ff 65 00 03
2015-06-01 15:32:19.965 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 84 80 80 80 a0 81 83 d6 22 00 5e b3 00 22 5b 40 00 00 00 f9 49 5f 00 03
2015-06-01 15:32:20.285 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:20.605 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:20.777 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [32]: 7d 20 82 81 80 a4 81 83 d6 22 d4 80 d6 72 7a 61 56 85 b3 0f 3f 41 3f 81 04 3f 81 06 07 08 09 03
2015-06-01 15:32:21.097 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:21.417 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:21.737 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:22.057 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:22.377 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:22.697 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [15]: 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:32:23.046 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [30]: 75 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 69 63 00 22 cb d3 00 00 3f 41 ee ff f2 00 03
2015-06-01 15:32:23.218 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [29]: 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 6a c6 00 22 e8 7f 00 00 3a 08 fb 58 00 03

Zum Vergleich: Ein paar Frames die erfolgreich gelesen wurden:

2015-06-01 15:33:00.871 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 e6 52 00 22 c1 cc 00 00 85 2c df fb 00 03
2015-06-01 15:33:01.192 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 e7 04 00 22 d8 6b 00 00 0d 06 d5 5c 00 03
2015-06-01 15:33:01.512 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 e8 cf 00 22 13 ea 00 00 7c 35 37 9f 00 03
2015-06-01 15:33:01.832 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 e9 c0 00 22 b2 50 00 00 f0 0e b3 41 00 03
2015-06-01 15:33:02.351 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 75 20 82 c0 c0 84 80 80 80 a0 81 83 d6 22 00 ea 62 00 22 70 4d 00 00 1e be 7b 3f 00 03
2015-06-01 15:33:02.499 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 eb 21 00 22 60 66 00 00 b2 fc bf 7c 00 03
2015-06-01 15:33:02.819 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 ec c0 00 22 f8 81 00 00 7d a8 53 dd 00 03
2015-06-01 15:33:03.145 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 ed 2a 00 22 ca 28 00 00 64 6c 45 5b 00 03
2015-06-01 15:33:03.311 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 ee a1 00 22 99 6f 00 00 a8 a9 5e f7 00 03
2015-06-01 15:33:03.631 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 ef bd 00 22 d2 0c 00 00 fb 85 6d ef 00 03
2015-06-01 15:33:03.951 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 f0 ef 00 22 cb 13 00 00 28 7e f3 fb 00 03
2015-06-01 15:33:04.275 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 f1 2e 00 22 5a ba 00 00 da b2 88 a5 00 03
2015-06-01 15:33:04.299 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [16]: 02 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03
2015-06-01 15:33:04.592 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 f2 08 00 22 91 69 00 00 c0 98 fd ee 00 03
2015-06-01 15:33:04.912 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 f3 8c 00 22 a0 b1 00 00 00 e8 77 df 00 03
2015-06-01 15:33:05.543 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 84 80 80 80 a0 81 83 d6 22 00 f4 90 00 22 41 fc 00 00 4e db 3e 6d 00 03
2015-06-01 15:33:05.583 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 f5 d1 00 22 ea 22 00 00 f8 94 f8 4e 00 03
2015-06-01 15:33:05.587 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 81 80 a4 81 83 d6 22 d4 80 d6 72 06 f5 56 67 91 22 20 21 26 25 24 25 2a 2b 03
2015-06-01 15:33:05.752 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 71 20 82 c0 c0 a4 d4 80 d6 72 81 83 d6 22 00 f6 4e 00 22 a8 c2 00 00 06 da 6d f3 00 03
2015-06-01 15:33:05.759 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [16]: 02 39 20 82 e0 80 a4 81 83 d6 22 d4 80 d6 72 03

Man sieht schön, dass im "dropped data" Fall vor den vielen "71 20 82 ..." jeweils ein einfacges "02" fehlt. Sprich: Da wurde der Anfang nicht erkannt, des Rest sieht wieder okay aus. Witzigerweise schwankt das vorkommen von vielen "00" bytes massiv. Heute vormittag waren die "dropped data" array gut und gerne mal 150 bytes lang, wovon nur ca. 30 (fehlender start) "sinnvoll" gefüllt waren und der Rest dann mit vielen 00en aufgefüllt war. Jetzt ist davon nichts mehr zu sehen.

Hab zum Thema Bias Netzwerk jetzt einiges gelesen. Die meisten schreiben was von 680Ohm gegen +5V und Gnd und 120Ohm zwischen den Datenleitungen. Abdere haben Werte von 620Ohm/100 Ohm, die nächsten haben 580Ohm/100Ohm ... Geht wild durcheinander. Aber das meiste ist doch 680/120 Ohm. Muss mal schauen was meine Bastelkiste her gibt und ggf. mal experimentieren.

Einen USB-RS485 Adapter zu finden der schon in den Daten was vom Bias-Netzwerk stehen hat ist fast unmöglich. Was aber hin und wieder auftaucht ist "true failsafe", was wohl soviel bedeutet wie: Im RS485 Decoder IC ist das schon alles eingebaut. Leider sind diese Adapter dann meist >50..150EUR teuer.
Da kann man es auch auf den 3EUR Ebayversuch mit 3 Widerständen ankommen lassen...

[UweH]

Na wunderbar, das sieht nach meinem bekannten Bias-Problem aus: wenn während der Pause zwischen zwei Frames, also Ruhepegel auf dem Bus, ein winziger Differenz-Peak von 0.2V den Zustand des Schmitt-Triggers kippt, sieht der Empfänger "aktiv", bis endlich das erste rezessive Bit des 02er Startbyte kommt. Das Startbit des 02 ist damit auf jeden Fall verloren, die 02 wird nicht erkannt. Die nachfolgenden dann schon, weil keine Zeit war, sich noch mal eine solche Störung einzufangen.
Die genauen Widerstandswerte sind Wurscht. Irgendwas zwischen 100 Ohm und 1k zwischen die Adern, und irgendwas zwischen einem halben und 5kOhm von Ader zu Versorgung bzw. Ader zu Masse. Genauer muss es nur sein, um bei ewig langen Leitungen und hoher Baudrate möglichst wenig Reflexionen zu haben. Bei 10Meter scheint's ja sogar ohne jeden Abschluss (oft ;-) zu funktionieren.

[tuxedo]

Na wunderbar, das sieht nach meinem bekannten Bias-Problem aus: wenn während der Pause zwischen zwei Frames, also Ruhepegel auf dem Bus, ein winziger Differenz-Peak von 0.2V den Zustand des Schmitt-Triggers kippt, sieht der Empfänger "aktiv", bis endlich das erste rezessive Bit des 02er Startbyte kommt. Das Startbit des 02 ist damit auf jeden Fall verloren, die 02 wird nicht erkannt. Die nachfolgenden dann schon, weil keine Zeit war, sich noch mal eine solche Störung einzufangen.

Ja, so hat es für mich auch ausgesehen. Wenn mal kurz "Ruhe ist" fängt es an zu spinnen, bis wieder eine Nachricht an die andere gereiht eintrifft.

Die genauen Widerstandswerte sind Wurscht. Irgendwas zwischen 100 Ohm und 1k zwischen die Adern, und irgendwas zwischen einem halben und 5kOhm von Ader zu Versorgung bzw. Ader zu Masse. Genauer muss es nur sein, um bei ewig langen Leitungen und hoher Baudrate möglichst wenig Reflexionen zu haben. Bei 10Meter scheint's ja sogar ohne jeden Abschluss (oft ;-) zu funktionieren.

Hab den RS485 Adapter gestern mal geöffnet und geschaut was drinnen steckt:

Ein unbenannter RS232-Pegelwandler. Da der IC keinerlei Beschriftung aufweist, kein ftdi. Laut Kernel-Ausgabe ist es ein China-Klon (ch341). Das ist weniger spektakulär und eher erwartet. Daneben gibts dann noch den bekannten MAX485 ESA. Ein paar Widerstände finden sich zwischen dem IC und dem RS485 Eingang dann auch noch. Gemessen (ja, ich weiß. Widerstände IN einer Schaltung messen ist nicht so der knüller. Aber SMD Widerstände zum messen mal auslöten ist auch nicht der brüller) habe ich ca. 2kOhm zwischen den beiden Datenleitungen zu Vcc und Gnd. Zwischen den Datenleitungen ist ein Widerstand vorgesehen, aber nicht eingebaut.
Hatte gestern leider keine Zeit mehr die Bastelkiste zu durchforsten. Werde dann aber heute Abend mal schauen dass ich da nen Widerstand dazwischen klemme.

Die Sache mit den 10m ... Lüftungsanlage und Heizungsanlage sind ebenfalls über RS485 angeschlossen, teilw. mit selbem Adapter. Da ist die Leitung 4-6m lang. Keinerlei Probleme bisher.
Die Haustür wird auf ca. 10-11m kommen. Anfangs fehlerfrei, nun mit besagten Problemen.

[UweH]

Ja, auch mein USB-Adapter hat die Bestück-Option für einen Widerstand zwischen den Adern. Aber keine für die Widerstände nach VCC und Ground. Genau diese beiden sind aber entscheidend, nicht der eine zwischen den Adern. Ziel ist einfach, dass, solange keiner der Treiber eine Spannung auf die Leitungen legt, die Leitungen über die Widerstände eine eindeutige Differenzspannung (0,5..5V) bekommen anstatt der undefinierten 0V. Wäre interessant, ob deine Heizung/Lüftung das intern schon richtig machen, aber ohne 2-Kanal-Oszi wird das schwierig.

[tuxedo]

Ja, auch mein USB-Adapter hat die Bestück-Option für einen Widerstand zwischen den Adern. Aber keine für die Widerstände nach VCC und Ground. Genau diese beiden sind aber entscheidend, nicht der eine zwischen den Adern. Ziel ist einfach, dass, solange keiner der Treiber eine Spannung auf die Leitungen legt, die Leitungen über die Widerstände eine eindeutige Differenzspannung (0,5..5V) bekommen anstatt der undefinierten 0V.

Hmm, wenn ich hier jeweils 2kOhm schon die ganze Zeit drin habe: Wieso zickt es dann so extrem wenn der "Abschlusswiederstand" zwischen den Adern nicht so wichtig ist?

Wäre interessant, ob deine Heizung/Lüftung das intern schon richtig machen, aber ohne 2-Kanal-Oszi wird das schwierig.

Puuh, kann ich dir nicht sagen. Das Modbus-Modul der Heizung kann ich mal rausziehen und auf die Platine schauen. Bei der Lüftung wird's schwer, da alles "intern gut versteckt". Da müsste ich mehr als nur den Anschlusskasten zerlegen.