eKey Fingerscanner per RS485 auslesen: Protokollanalyse

[tuxedo]

ser2net ist äußerst stabil. Die RS232 Anbindung an Java direkt geht über eine Bibliothek, die nicht wirklich Bugfrei ist, und seit Jahren nur mäßig bis gar nicht gepflegt wird. Die Socket-Anbindung hingegen ist direkter Bestandteil von Java und kann als Fehlerfrei betrachtet werden.

ser2net hat auch noch den Vorteil, dass man das ganze mit einem BBB oder Raspi ähnlich einem Moxa aufsetzen, und die Software (weil vielleicht mehr zusammen kommt als nur der eKey (bei mir z.B. Heizung, Ekey und Lüftung)) auf einer ganz anderen Kiste laufen lassen kann.

[tuxedo]

fuppy
Eben erst gesehen dass du einen Link zu deinem Adapter gepostet hast.
Dein Adapter sieht ja ganz gut aus. Den kann man per DIP-Schalter noch einstellen. Jeweils 390Ohm gegen Vcc und Masse sind möglich. Auch ein Abschlusswiderstand lässt sich aktivieren. Allerdings hat dieser 220Ohm statt den "üblichen 120Ohm"?!

Hast du mal die DIP-Schaltereinstellung überprüft? Den ersten würde ich abschalten, die restlichen 3 an.

[fuppy]

tuxedo
Genau aus diesem Grund habe ich mich für diesen Stick entschieden. Ich hab auch schon mit verschiedenen "Schalterkombinationen" getestet, allerdings eben mit der direkten Anbindung ohne ser2net.

Werd meinen Test heute Abend mal mit ser2net (+ die von dir vorgeschlagene DIP-Schalterstellungen) wiederholen und prüfen, ob ich weiterhin nur "gedroppte" Pakete erhalte wie bis jetzt.

Vll. noch kurz zu meiner Umgebung:

- ekey Integra 2.0 Bluetooth
- ekey mini Steuereinheit

[Onkelandy]

Ich habe hier grad noch 3 aktuelle Probleminfos aus dem Debug Log. Interessanterweise kommen die ersten zwei Einträge aus dem Nichts - hier wurde der ekey überhaupt nicht genutzt. Der letzte Eintrag müsste ein erfolgter Zugang über ekey sein, wobei hier der Befehl offenbar leider nicht erkannt wurde

Angenommen ich würde auf das Gehäuse des Adapters verzichten, wo genau müsste was geändert werden.. hab zwar im Thread gestöbert, aber so ganz klar ist mir's noch nicht Thanks

2015-08-04 11:37:34.238 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: tail wrong
2015-08-04 11:37:34.248 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 57 94 00 22 09 97 f7 bb 61 ef ef 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 58
2015-08-04 13:07:32.114 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: tail wrong
2015-08-04 13:07:32.155 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 d8 fa 00 22 14 05 cf 7b 95 6e fd cf 00 03 00 02 71 20 82 81 80 ad b3 81 c4 22 c0 80 d5 72 6f d8 0e 6a 3b c1 ce cf c8 b4 ca cb c4 c5 03 00 02 71 20
2015-08-04 15:27:05.327 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: tail wrong
2015-08-04 15:27:05.335 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 75 ac 00 22 96 de 37 fc 0d 06 7f 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 76

[tuxedo]

Du müsstest den Adapter aus dem Gehäuse holen (noch prima machbar) und dann die zwei SMD Widerstände gegen Vcc und Gnd auslöten und durch andere, passende (wobei hier "passend" noch nicht ganz klar ist) ersetzen. Ersetzen heisst: Es gibt da aktuell schon Widerstände die als "bias-netzwerk" fungieren. Wenn ich mich recht erinnere sind das ca. 2kOhm SMD-Widerstände (könnte sein dass ich das schon mal gepostet habe?).

Die Lötpads sind sehr klein und für "normale Widerstände" bei weitem nicht vorgesehen. Mit einem Baumarktlötkolben kommst du da nicht weit.

Hab grad kein Foto da, aber ich kann dir mal bei gelegenheit eins machen und einzeichnen welche Widerstände es zu ersetzen gilt. Oder du bist in Elektronik fit genug und kannst anhand des Datenblatts für den RS485 IC und der vor dir liegenden Platine erkennen wo welche Datenleitung nach Vcc und Gnd geht und so die Widerstände selbst identifizieren.

Daneben brauchst du nach wie vor den 120Ohm Widerstand zwischen den beiden Datenleitungen.

Der Witz an der Sache:

Ich habe den exakt gleichen Adapter noch 2x im Einsatz. Einmal an der Helios Lüftungsanlage und einmal an der Dimplex Wärmepumpe. In diesen beiden Fällen gibt es keinerlei 0-bytes und Fehlstellungen (die Software hierzu stammt ebenfalls von mir). Dort läuft der Betieb Störungsfrei. Das verwendete Kabel zum Gerät ist vom selben Typ mit ähnlicher Leitungslänge.
Am Adapter an sich liegt's nicht. Wenn ich die 3 Adapter durcheinander tausche, dann ist es immer noch der ekey der die Fehl-Bytes hat.

Hab jetzt schon mehrfach gelesen dass man bei langen Leitungslängen und hoen Geschwindigkeiten (haben wir eigentlich beides nicht) auf beiden Seiten einen 120Ohm Abschlusswiderstand einsetzten soll.
Hab noch nicht recherchiert was im ekey eingestellt/verbaut ist und ob dort ein nachträglich eingebauter 120Ohm Widerstand (oder ggf. eine per DIP-Schalter konfigurierbare terminierung) was bringt... oder ob man dort eine Werksseitig eingestellte Terminierung raus nehmen kann/muss/ob's was bringt.

[fuppy]

Hi zusammen,

schlechte Nachrichten. Leider hat die Anbindung über ser2net nichts gebracht. Gleiches Fehlerbild. Auch Änderungen der DIP-Schalterstellungen meines Adapters haben nichts geändert. Irgendwie empfängt der Adapter nur Müll hab ich das Gefühl. Hier mal ein Beispiel:

015-08-04 15:56:30.420 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for length
2015-08-04 15:56:30.422 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for LengthExtension
2015-08-04 15:56:30.424 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: frame has 16 Bytes
2015-08-04 15:56:30.539 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Frame complete
2015-08-04 15:56:30.543 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [16]: 02 39 20 82 e0 80 81 ab 80 b7 23 c6 82 b6 73 03
2015-08-04 15:56:30.547 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [25]: 61 20 82 c0 c0 88 c6 82 b6 73 ab 80 b7 23 00 35 d1 00 22 2c 01 3f 07 00 03
2015-08-04 15:56:30.549 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for length
2015-08-04 15:56:30.551 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for LengthExtension
2015-08-04 15:56:30.553 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: frame has 16 Bytes
2015-08-04 15:56:30.669 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Frame complete
2015-08-04 15:56:30.677 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [16]: 02 39 20 82 e0 80 81 ab 80 b7 23 c6 82 b6 73 03
2015-08-04 15:56:30.691 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [25]: 61 20 82 c0 c0 88 c6 82 b6 73 ab 80 b7 23 00 36 d1 00 22 2c 01 3f 07 00 03
2015-08-04 15:56:30.695 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for length
2015-08-04 15:56:30.697 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for LengthExtension
2015-08-04 15:56:30.699 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: frame has 32 Bytes
2015-08-04 15:56:30.799 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Frame complete
2015-08-04 15:56:30.805 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [30]: 02 79 20 82 81 80 81 ab 80 b7 23 c6 82 b6 73 7a 36 d2 a0 91 09 02 03 04 01 06 07 08 09 03
2015-08-04 15:56:30.808 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [25]: 61 20 82 c0 c0 88 c6 82 b6 73 ab 80 b7 23 00 37 d1 00 22 2c 01 3f 07 00 03
2015-08-04 15:56:30.810 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for length
2015-08-04 15:56:30.812 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for LengthExtension
2015-08-04 15:56:30.814 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: frame has 16 Bytes
2015-08-04 15:56:30.929 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Frame complete
2015-08-04 15:56:30.937 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [16]: 02 39 20 82 e0 80 81 ab 80 b7 23 c6 82 b6 73 03
2015-08-04 15:56:30.941 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [25]: 61 20 82 c0 c0 88 c6 82 b6 73 ab 80 b7 23 00 38 d1 00 22 2c 01 3f 07 00 03

Ich zweifel grad schon, ob ich ihn korrekt angeschlossen hab. Hab am Adapter die Anschlüsse A und B verwendet (siehe Datenblatt)

Naja, dann geht der Adapter postwendend zurück und ich probier mal den von tuxedo vorgeschlagenen. Wenn alles nichts hilft, muss ich wohl doch auf den UDP Convertor zurückgreifen :-(

[tuxedo]

Hi,

dem Log nach zu Urteilen kommen da schon komplette Nachrichten an, z.B.

2015-08-04 15:56:30.543 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [16]: 02 39 20 82 e0 80 81 ab 80 b7 23 c6 82 b6 73 03

Alles was im Log als "Raw Frame" deklariert ist, ist eine komplett empfangene Nachricht. Was dir "fehlt" sind Frames mit der Länge 47 (im Beispiel sind es 16).

Was du offenbar zu genüge hast, sind fehlerhafte Abschnitte (Dropped Data). Da ist immer mal wieder ein "Ende" (03) zu erkennen, aber der Anfang fehlt (02) und dazwischen sind auch immer wieder 00-Bytes.

Bist du dir sicher dass du während dieses Log-Mitschnitts einen Finger gescanned hast?

Der von mir zuletzt erwähnte Adapter soll Gerüchten zufolge vor Jahren ein Revisions-Update bekommen haben, in welchem ein RS485-IC verbaut wurde der "true fail safe" beherrscht. D.h. mit diesem IC sollten keine Fehl-Bytes (z.B. jede Menge 00-bytes wenn gerade Sendepause ist) auftreten. Ein manuelles festlegen des Bias-Netzwerks wird damit überflüssig (so das versprechen). Ob das auch tatsächlich so ist: Keine Ahnung.

Wenn du das ausprobieren willst: Gerne. Ich bin auf deinen Bericht gespannt.

[fuppy]

Hi,

dem Log nach zu Urteilen kommen da schon komplette Nachrichten an, z.B.

2015-08-04 15:56:30.543 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [16]: 02 39 20 82 e0 80 81 ab 80 b7 23 c6 82 b6 73 03

Alles was im Log als "Raw Frame" deklariert ist, ist eine komplett empfangene Nachricht. Was dir "fehlt" sind Frames mit der Länge 47 (im Beispiel sind es 16).

Was du offenbar zu genüge hast, sind fehlerhafte Abschnitte (Dropped Data). Da ist immer mal wieder ein "Ende" (03) zu erkennen, aber der Anfang fehlt (02) und dazwischen sind auch immer wieder 00-Bytes.

Bist du dir sicher dass du während dieses Log-Mitschnitts einen Finger gescanned hast?

Innerhalb des geposteten Mitschnitts habe ich keinen Finger gescanned. Während des gesamten Tests aber schon. Ich hab dann einfach das komplette Log nach "INFO" gegrepped, weil ich davon ausgegangen bin, dass im Log dann ein Eintrag dieser Kategorie erscheint, wenn ein Fingerscan erkannt wurde. Aufgrund der Masse der Daten habe ich nicht jeden Eintrag genau angeschaut.

Wenn ich richtig schlussfolgere, sollte ich den Test nochmals wiederholen, einen Finger scannen und prüfen, ob ich einen Eintrag à la

2015-XX-XX XX:XX:XX.XXX FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [47]: 02 39 20 82 e0 80 81 ab 80 b7 23 c6 82 b6 73 03 ... 47

erhalte?

Wenn das der Fall ist: Was wäre dann der nächste Schritt?

Der von mir zuletzt erwähnte Adapter soll Gerüchten zufolge vor Jahren ein Revisions-Update bekommen haben, in welchem ein RS485-IC verbaut wurde der "true fail safe" beherrscht. D.h. mit diesem IC sollten keine Fehl-Bytes (z.B. jede Menge 00-bytes wenn gerade Sendepause ist) auftreten. Ein manuelles festlegen des Bias-Netzwerks wird damit überflüssig (so das versprechen). Ob das auch tatsächlich so ist: Keine Ahnung.

Wenn du das ausprobieren willst: Gerne. Ich bin auf deinen Bericht gespannt.

Ich hab das Teil gestern bestellt. Sollte Anfang nächster Woche dann hier sein. Kann sein, dass ich dich dann nochmals bzgl. des richtigen Anschlusses brauch. Da sind zu viele Adern dran ;-)

Danke!

[tuxedo]

Ein kompletter Fingerscan schaut im Log so aus:

2015-08-04 18:22:52.047 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for length
2015-08-04 18:22:52.047 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for LengthExtension
2015-08-04 18:22:52.047 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: frame has 47 Bytes
2015-08-04 18:22:52.062 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Frame complete
2015-08-04 18:22:52.063 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [47]: 02 b5 20 82 81 83 a4 81 83 d6 22 d4 80 d6 72 26 db 85 a9 50 bc 21 d8 e1 01 dd 3c 09 e5 59 71 35 44 b0 21 5d 5a 2f de 6b 6b 95 1c 23 20 1c 03
2015-08-04 18:22:52.063 FINE [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: ***** Fingerhash: 0x85
2015-08-04 18:22:52.063 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Fingerhash received: 0x85
2015-08-04 18:22:52.066 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Sent fingerhash 0x85 to 8/0/0
2015-08-04 18:22:52.066 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Fingerhash [0x85] resolves to 'Isabella'
2015-08-04 18:22:52.067 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Send string '85h/Isabella' to 8/0/1

Vorgehen:

* Tool beenden
* Alle logs löschen
* Tool mit debug-log starten
* Finger scannen so dass er vom Scanner mit "grün" quittiert wird
* Tool beenden
* Log posten

Wichtig: Das Tool kann nur grün-quittierte/erfolgreiche Scans melden. Fehlerhafte Scans oder Finger die erst gar nicht eingelernt wurden tauchen im Log nicht gesondert auf, da das Protokoll an dieser Stelle nicht entschlüsselt ist.

[fuppy]

Ohne jetzt erneut getestet zu haben kann ich schon sagen, dass bis dato kein positiver Fingerscann bei mir von dem Tool registriert wurde, da ich im gesamten Log keine INFO Einträge hatte.

Der Vollständigkeit halber werde ich aber heute Abend nochmals testen :-)

Danke für die Hilfe!

[UweH]

Du hast nicht zufällig einen heißen Tipp (außer selbst bauen)?

Der Adapter ist schon ok, das Bias-Netzwerk muss ja nicht im Adapter sein. Man muss halt irgendwo 5V und Masse haben, und von diesen zwei Widerstände zum Bus hin einbauen. Die Masse und 5V kann man jetzt aus dem Adapter holen (z.B. direkt am USB, da kommt man gut ran), oder vom Raspberry oder vom ekey oder von wo auch immer. Am flexibelsten wäre aus meiner Sicht, die zwei Widerstände in die Schraubklemmen zu klemmen, und mittels Fädeldraht auf die Masse und 5V im Dongle zu führen, dann großzügig Schrumpschlauch drüber - fertig ;-)
Hab's gerade mal bei mir ausprobiert:
dongle_mit_Bias.jpg
Ok, das Gehäuse geht nicht ganz zu, aber da kann der Dremel weiterhelfen ;-)

[UweH]

2015-08-04 15:56:30.549 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for length
2015-08-04 15:56:30.551 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Waiting for LengthExtension
2015-08-04 15:56:30.553 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: frame has 16 Bytes
2015-08-04 15:56:30.669 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Frame complete
2015-08-04 15:56:30.677 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.frameReceived: Raw Frame [16]: 02 39 20 82 e0 80 81 ab 80 b7 23 c6 82 b6 73 03
2015-08-04 15:56:30.691 FINEST [EkeyDecoder] de.root1.ekeydecoder.EkeyDecoder.byteReceived: Dropped data [25]: 61 20 82 c0 c0 88 c6 82 b6 73 ab 80 b7 23 00 36 d1 00 22 2c 01 3f 07 00 03

Ich zweifel grad schon, ob ich ihn korrekt angeschlossen hab. Hab am Adapter die Anschlüsse A und B verwendet (siehe Datenblatt)

Naja, dann geht der Adapter postwendend zurück und ich probier mal den von tuxedo vorgeschlagenen. Wenn alles nichts hilft, muss ich wohl doch auf den UDP Convertor zurückgreifen :-(

Stop, den Adapter brauchst du nicht zurückschicken. Die kurzen Frames kommen korrekt an. Und bei der zweiten Zeile ist nur der Anfang falsch, die Sender- und Emfängeradresse passen zueinander, man sieht, dass sich da zwei miteinander unterhalten:
[16]: 02 39 20 82 e0 80 81 ab 80 b7 23 c6 82 b6 73 03
[25]: 61 20 82 c0 c0 88 c6 82 b6 73 ab 80 b7 23 00 36 d1
--> Der Dongle ist korrekt gepolt angeschlossen.
--> Aber mit dem ersten Byte nach Busruhe gibt's ein Problem. Klingt für mich wieder nach Bias-Beschaltung. Hast du Zugriff auf ein Zweikanal-Oszi? Wäre interessant, die Pegel der Busleitungen zu sehen.

[UweH]

Ich habe hier grad noch 3 aktuelle Probleminfos aus dem Debug Log. Interessanterweise kommen die ersten zwei Einträge aus dem Nichts - hier wurde der ekey überhaupt nicht genutzt.

"Aus dem Nichts" ist nicht ganz richtig. Der Datenverkehr läuft ständig, auch wenn kein Finger gescannt wird. Ca. 3 Frage-Antwort-Spiele pro Sekunde. Das bringt mich auf eine Idee: Der Decoder könnte ja die korrekten und die nicht korrekten Frames mitzählen und die Zählerstände jede Minute ins Log schreiben. Im Idealfall müsste der Gut-Zähler ca. 180 pro Minute raufzählen, der Schlecht-Zähler auf 0 stehen bleiben. Damit könnte man leicht die Verbindungsqualität beurteilen.

[UweH]

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

Spannende Geschichte, da muss ich doch gleich mal das File ins WireShark laden...
Erste Entdeckung: Wow, es ist wirklich nur der benötigte Traffic drin, also schon mal auf den richtigen Port gefiltert - Klasse!
Zweite Entdeckung: Die Übertragung der RS232-Daten scheint 1:1 als Daten im Paket drin zu sein - das macht die Analyse leicht.
Dritte Entdeckung: Der Trace deckt sich mit der Ausgabe von Tuxedos Decoder. Der Müll entsteht also irgendwo beim RS485-Dongle oder dem Pi, der den auswertet. Wobei das konkrete Beispiel wieder nur die schon bekannten "Phantom-Bytes" zwischen den Frames enthält, also ein eher rein elektrisches Problem ist:
Phantombytes_Wireshark.jpg

[tuxedo]

Der Adapter ist schon ok, das Bias-Netzwerk muss ja nicht im Adapter sein. Man muss halt irgendwo 5V und Masse haben, und von diesen zwei Widerstände zum Bus hin einbauen. Die Masse und 5V kann man jetzt aus dem Adapter holen (z.B. direkt am USB, da kommt man gut ran), oder vom Raspberry oder vom ekey oder von wo auch immer. Am flexibelsten wäre aus meiner Sicht, die zwei Widerstände in die Schraubklemmen zu klemmen, und mittels Fädeldraht auf die Masse und 5V im Dongle zu führen, dann großzügig Schrumpschlauch drüber - fertig ;-)
Hab's gerade mal bei mir ausprobiert:
[ATTACH=CONFIG]n850982[/ATTACH]
Ok, das Gehäuse geht nicht ganz zu, aber da kann der Dremel weiterhelfen ;-)

Okay, so geht's natürlich auch. Dann laufen die zusätzlichen Widerstände zu den existierenden eben parallel.
Mit einem Dremel lässt sich das auch gut "verstecken".
Ausgehend von 2,4kOhm SMD Widerständen im Dongle (gemessen im ausgelöteten Zustand) und deiner 820Ohm Zusatzbeschaltung, reduziert sich der Widerstand auf rund 610 Ohm.
Du hattest geschrieben dass du ohne die Zusatzwiderstände 4,9V hattest. Wo liegst du denn jetzt? Und hast du es mal mit 120Ohm Abschlusswiderstand + 820 Ohmbeschaltung gleichzeitig versucht?
Ich hatte ohne Zusatzwiderstände bereits 4,77V. Wenn ich die vielen Beiträge jetzt nicht durcheinander bringe, dann ist das Ziel möglichst nahe an 5V zu kommen, richtig?

Ergo ist es egal ob man nun 820Ohm aus der Bastelkiste nimmt (und damit mit diesem Dongle bei 610 Ohm landet), oder 620 Ohm zuschaltet (weil sonst nix anderes in diesem Wertebereich in der Bastelkiste liegt) und so bei ca. 490Ohm landet, richtig?

Nur zu klein sollte der Widerstand wohl nicht werden...

Der Decoder könnte ja die korrekten und die nicht korrekten Frames mitzählen und die Zählerstände jede Minute ins Log schreiben. Im Idealfall müsste der Gut-Zähler ca. 180 pro Minute raufzählen, der Schlecht-Zähler auf 0 stehen bleiben. Damit könnte man leicht die Verbindungsqualität beurteilen.

Ich nehm das mal auf die ToDo Liste mit auf.

Zweite Entdeckung: Die Übertragung der RS232-Daten scheint 1:1 als Daten im Paket drin zu sein - das macht die Analyse leicht.

War nicht anders zu erwarten. Genau das macht ser2net. Und das sehr zuverlässig.

Dritte Entdeckung: Der Trace deckt sich mit der Ausgabe von Tuxedos Decoder.

Logo ;-)

Der Müll entsteht also irgendwo beim RS485-Dongle oder dem Pi, der den auswertet.

Der Pi wertet da selbst nichts aus. Die Daten werden direkt von der seriellen Schnittstelle von ser2net gelesen und auf den Socket geschoben. 1:1. Wenn es da schon einen Fehler gäbe, dann wäre wohl das Linux fehlerhaft, oder der Pi hätte einen Hardware-Fehler.

Wir sind damit also immer noch beim Dongle...

Ich probier das mit dem Zusatzwiderstand mal aus... Hab ja noch ausreichend Dongles hier liegen zum testen.