Erbitte Hilfe bei der Protokollidentifizierung

[Uwe (Gast)]

Hallo,

ich beschäftige mich schon seit einigen Jahren mit Datenübertragung und 
Microcontrollern (mittlerweile nur noch als Hobby) und wurde von einem 
Bekannten gebeten die interne Kommunikation in einem Modellbahnfahrzeug 
analysieren und ggf. anpassen kann.
Nun kenne ich allerhand Übertragungarten und Protokolle, habe mich auch 
in die Brancenüblichen (DCC, RAILCOM, SUSI eingelesen) bin dabei aber 
auf etwas seltsames gestoßen, das ich auch nach mehrtägigrem Googeln 
nicht identifizieren konnte.

- Kommunikation zwischen einem ATtiny441 und einem ATxmega32A4U
- 3-Leitungen GND/5V/Daten
- keine asysncrone Übertragung
- kein Manchester-Code
- Startbit 40 µs
- kurze Periode ca. 16,9 µs
- lange Periode ca. 27,5 µs
- gemischte Phasenwechsel lang lo - kurz hi - lang lo und umgekehrt
- sehr unterschiedliche Bitanzahl pro Übertragung

Anbei ein Screenshot vom Analysator.

Was könnte das für ein Bus sein ? Oder etwas ganz proprietäres ?
Ich kann mir nicht vorstellen da man hier was ganz eigenes "erfunden" 
hat ...

Bevor ich da Protokoll dekodieren kann müsste ich aber erstmal die 
Übertragung verstehen.
Die Elektronik wegschmeißen und neubauen ist sicher einfacher und 
billiger ..

Ich sehe es eher sportlich und würde gern verstehen was da läuft :-)

Vielen Dank und viele Grüße
Uwe

[Michael B. (laberkopp)]

Uwe schrieb:
> etwas ganz proprietäres ?

Warum nicht.

> Ich kann mir nicht vorstellen da man hier was ganz eigenes "erfunden"
> hat ...

Manchen Leuten fällt Neuerfindung leichter, als seitenlange Doku zu 
lesen und dann doch was zu bekommen, das nicht genau zum Problem passt.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uwe schrieb:
> keine asysncrone Übertragung
Die sieht mir völlig asynchron aus. Denn eine synchrone Übertragung 
brächte ja einen Takt, zu dem sie synchron ist.

> Kommunikation zwischen einem ATtiny441 und einem ATxmega32A4U
Bidirektional?
Das bekommt man raus, indem man einen Widerstand in die Leitung 
einschleift und an beiden Seiten des Widerstands je einen Oszi-Kanal 
anschließt.

> Ich kann mir nicht vorstellen da man hier was ganz eigenes "erfunden"
> hat ...
Ich würde einfach mal diesen Ansatz wagen: die Pegel sind im Grunde 
egal, kurz ist 0 und lang ist 1. Und jetzt müsste man sowas wie ein Poti 
haben, womit man Werte nachvollziehbar ändern kann.

[Anja (Gast)]

Uwe schrieb:
> sehr unterschiedliche Bitanzahl pro Übertragung

ich sehe 32 Bits (kurz oder lang codiert) zwischen Startbit und Stopbit.

Gruß Anja

[Sebastian W. (wangnick)]

Anja schrieb:
> ich sehe 32 Bits (kurz oder lang codiert) zwischen Startbit und Stopbit.

Jetzt sehe ich die auch:
S11110010111100000000000000100101P S1111000011110010...

Oder andersherum ...

LG, Sebastian

[Uwe (Gast)]

Hallo und vielen Dank!

Manchmal sieht man den Wald vor Bäumen nicht. Hatte auch schon in diese 
Richtung gedacht, aber irgendwie zwei Phasenwechsel pro Bit erwartet. 
Und beim Flankenzählen hatte ich mich zu später Stunde einerseits 
verzählt und zum Anderen bin ich über die tatsächlich abweichenden 
Längen (32 und 48 Bit) gestolpert ... :-)

Hier das erste Ergebnis decodiert:

11110010111100000000000000100101                    F2 F0 00 25
111100001111001000110010000000010000001011111100    F0 F2 32 01 02 FC
111100011111000000010010001000000000000100101010    F1 F0 12 20 01 2A
11110001111100000000000011101111                    F1 F0 00 EF
111100001111000100110010000000010000001001100000    F0 F1 32 01 02 60
111100101111000000010010001000000000000101101110    F2 F0 12 20 01 6E

Die ersten Bytes scheinen Quelle/Ziele sein und beim letzten hätte ich 
jetzt eine Prüfsumme/CRC erwartet ... Dem scheint aber nicht so oder ich 
sehe nur die Codierung noch nicht :-(

Viele Grüße
Uwe

[Dergute W. (derguteweka)]

Moin,

reveng meint, es koennte sein, dass das letzte Byte ein CRC ueber alle 
anderen Bytes ist:

width=8  poly=0x31  init=0xff  refin=false  refout=false  xorout=0x00 
check=0xf7  residue=0x00  name="CRC-8/NRSC-5"

Gruss
WK

[Uwe (Gast)]

Vielen Dank. Reveng gestern nicht mehr zum Laufen gebracht. Werde es 
nächste Woche mal näher betrachten ...
VG und ein Schönes WE
Uwe