Richtung des Datenflusses ermitteln?

[Frank E. (Firma: Q3) (qualidat)]

Ich habe da eine Azeigeeinheit und einen "intelligenten" (mit MC 
ausgestatteten) Sensor. Verbunden sind die über eine Datenleitung, die 
abwechselnd vom Master (Anzeigeinheit) und vom Slave (Sensor) benutzt 
werden.
Das Protokoll ist ganz simpel 9600_8N1 nach RS232-Art, aber eben nur auf 
einem Draht. Mitlesen kann ich inzwischen alles problemlos.

Auch die "Elektrik" hat sich geklärt: Ruhepegel um die 3V (High), kurz 
vor Sendungsbeginn 1 Bitlänge Null (Low), der Rest innerhalb der 
8-Byte-Blöcke ganz normale "positive Logik", 1 Bitlänge nach letztem 
Stopbit wieder Ruhepegel High. SoftSerial vom Arduino hat damit kein 
Problem.

Es bleibt aber ein "Restproblem": Ich bin mir bei einigen Datentransfers 
(8-Byte-Blocks) nicht ganz so sicher, wer der Sender ist, Anzeige oder 
Sensor. Im normalen Messbetrieb ist das inzwischen klar, es kommt eine 
Anforderung von der Anzeige und eine Antwort vom Sensor.

Etwas unübersichtlich wird es in der Initialisierungsphase unmittelbar 
nach dem Einschalten. Da ist relativ viel auf der Leitung los und ich 
weiss nicht, wo was hingehört. Klar ist der erste Block wieder von der 
Anzeige, aber dann wirds undurchsichtig ...

Wie bekomme ich das heraus? Hätte gerne einen möglichst einfachen 
Schaltungstip fürs Steckbrett:-) Danke!

Ideal wäre die Möglichkeit, zwei SoftSerial-Pins oder auch zwei Arduinos 
anzschließen, von denen jeder jeweils einen der Datenströme ausgibt.

[Harald K. (kirnbichler)]

Frank E. schrieb:
> Wie bekomme ich das heraus?

Eventuell:

Oszilloskop und Signalpegel betrachten. Manchmal liefert eine Seite 
einen etwas höheren Pegel als die andere.


Sonst:

Eines der Geräte aufmachen, Schaltung ansehen und Signal vor dem 
verwendetem Treiber abgreifen.

[Timo W. (timo)]

Serienwiderstand zwischen beiden Geräte und pulldown(oder 
Spannungszeiler) an die Geräte. Wenn du dann an einem Gerät misst sollte 
der sendepegel des anderen etwas niedriger sein.

[Rolf M. (rmagnus)]

Eine andere Möglichkeit, falls du die Leitung auftrennen kannst: Einen 
µC mit zwei seriellen Schnittstellen dazwischenschalten und einfach in 
beiden Richtungen alles durchreichen. Dadurch weißt du automatisch, was 
in welche Richtung gesendet wurde.

[Peter D. (peda)]

Das werden einfach nur 2 open-drain Pins mit Pullup sein. Die Richtung 
wird also nur durch das Protokoll festgelegt und läßt sich von außen 
nicht erkennen.
Vermutlich wird das Protokoll so sein, daß der Slave von sich aus nichts 
sendet. Der Master schickt also ein Abfragekommando und der Slave 
antwortet darauf. Genaueres sollte in der Protokollbeschreibung stehen. 
Da wird dann auch stehen, in welchem Zeitfenster der Master eine Antwort 
erwartet, ehe er ein Timeout feststellt.

Man könnte noch einen Widerstand (47R) einschleifen und mit einem 
Komparator die Stromrichtung feststellen.

[Frank E. (Firma: Q3) (qualidat)]

Rolf M. schrieb:
> Eine andere Möglichkeit, falls du die Leitung auftrennen kannst:
> Einen
> µC mit zwei seriellen Schnittstellen dazwischenschalten und einfach in
> beiden Richtungen alles durchreichen. Dadurch weißt du automatisch, was
> in welche Richtung gesendet wurde.

Danke, das ist die Idee, der ich wohl als erstes folgen werde!

Ich habe bereits Code-Beispiele gefunden, in denen eine SoftSerial auf 
einem Pin arbeitet und "on the fly" zwischen Senden und Empfangen 
umschalten kann. Mal sehen, was das wird ... ich berichte.

Das Angucken auf dem Oszi mit verschiedenen Pegeln ist mir auch 
gelungen, aber bei 9600 kann man so schlecht mitschreiben :-)

[Bruno V. (bruno_v)]

2 Dioden antiparallel in die Mitte. Und daran einen differentiellen 
Receiver, der seine umschaltschwelle bei 100..200mV hat.

Für den anderen Zweig einen zweiten, genau andersrum gepolt.

[Frank E. (Firma: Q3) (qualidat)]

Bruno V. schrieb:
> 2 Dioden antiparallel in die Mitte. Und daran einen
> differentiellen
> Receiver, der seine umschaltschwelle bei 100..200mV hat.
>
> Für den anderen Zweig einen zweiten, genau andersrum gepolt.

Ja, so ähnlich hatte ich auch schon gedacht: zwei anti-parallel 
geschaltete Optokoppler in die Leitung. Aber höchst wahrscheinlich 
reicht der Strom nicht und durch die Flussspannung der LEDs wird der 
Pegfel zu niedrig. Ich werde es trotzdem mal probieren, wer weiss ...

[Norbert (der_norbert)]

Kleiner Serienwiderstand. Einen Komparator (oder OpAmp aus der 
Grabbelkiste) drüber. Optional LED ansteuern. Fettich.
Wer nun sendet oder nicht, sagt dir dann das Licht.

[Bruno V. (bruno_v)]

Optokoppler brauchen 10fache Spannung und Strom und sind deutlich 
zickiger. Photomos sind vielleicht ein bisschen besser. Differenzielle 
Empfänger sind quasi die komparatoren in Norberts Post. Nur dass Du 
direkt am Ausgang mitlesen kannst ( maximal noch je 1 inverter)

[Frank E. (Firma: Q3) (qualidat)]

Habs simuliert, nach dem Prinzip werde ich es nachher mal 
zusammenstecken. Den Ausgang vom OPV lese ich parallel zu den seriellen 
Daten ...

Der Serienwiderstand wird natürlich kleiner als 1k. In der Simu 
funktioniert es bis herab zu 1 Ohm.

[Frank E. (Firma: Q3) (qualidat)]

Also ganz so einfach ist es dann doch nicht, aber das ist eher ein 
Software-Problem:

Die Methode SoftSerial.available() meldet nur dann true bzw. eine Anzahl 
>0 von Bytes, wenn die bereits komplett im Puffer angekommen sind. Dann 
ist das Bit-Gezappel auf der Leitung aber längst vorbei ...

Also muss eine flipflop-artige Struktur, entweder in Hard- oder Software 
her, die den Zustand hält, bis er zurückgesetzt wird, z.B. nach dem 
Lesen eines jeden Bytes. Der Loop läuft sicher schnell genug, so dass 
sich bei 9600 nicht viel im Puffer sammeln sollte, idealerweise immer 
nur 1 Byte.

Aus Gründen des Aufwandes würde ich eine Softwarelösung natürlich 
vorziehen, das muss ich erstmal testen ...

[Bruno V. (bruno_v)]

Frank E. schrieb:
> ist das Bit-Gezappel auf der Leitung aber längst vorbei ...

was spricht denn gegen die Lösung mit 2 differentiellen Receivern?

Bruno V. schrieb:
> Für den anderen Zweig einen zweiten, genau andersrum gepolt.

Der eine sieht die Daten von links nach rechts, der andere von rechts 
nach links. Ich dachte, Du wolltest genau sowas haben.

Frank E. schrieb:
> Ideal wäre die Möglichkeit, zwei SoftSerial-Pins oder auch zwei Arduinos
> anzschließen, von denen jeder jeweils einen der Datenströme ausgibt.

[Frank E. (Firma: Q3) (qualidat)]

Bruno V. schrieb:

> was spricht denn gegen die Lösung mit 2 differentiellen Receivern? Der
> eine sieht die Daten von links, der andere von rechts. Ich dachte, Du
> wolltest genau sowas haben.

ja ... viele Wege führen nach Rom. Am Ende brauche ich das nur genau 
einmal, bis das Protokoll analysiert ist. Diese Methode ist noch nicht 
vom Tisch, aber mit irgendwas muss ich ja anfangen ... mal sehen, was 
zuerst funktioniert

[Norbert (der_norbert)]

Frank E. schrieb:
> ja ... viele Wege führen nach Rom. Am Ende brauche ich das nur genau
> einmal, bis das Protokoll analysiert ist.

Also nimmt man einen PICO bzw. dessen PIO und kodiert das Progrämmchen 
in einer viertel (vielleicht einer halben) Stunde.
Zwei SMs fragen – parallel laufend – einmal den Daten- und einmal den 
Richtungspin ab.

Da ja der OpAmp einen stabilen Zustand hat (entweder immer an in Sende- 
oder Empfangsrichtung) und man zudem nur die Richtung der ›0‹ Bits auf 
der Datenleitung erkennen kann, liest man bei einem übertragenen Byte 
entweder zwei identische Werte aus den SMs, oder nur den Wert der 
(Daten)SM und die (Richtungs)SM bleibt stabil bei alles ›0‹ oder stabil 
bei alles ›1‹

Done.

[Dieter S. (ds1)]

Da es vermutlich immer noch um den Sensor von hier geht:

Beitrag "serielles Sensor-Protokoll erkennen?"

Die Dokumentation für das IPS-149 Binär-Protokoll ist eigentlich 
ziemlich eindeutig: Der Host schickt ein Kommando zum Sensor, dieser 
antwortet darauf (der Sensor beginnt also nicht von selbst etwas zu 
schicken). Die Antwort des Sensors enthält entweder das Kommando-Byte, 
das der Host geschickt hat oder ein ACK bzw. NACK (ACK und NACK schickt 
nur der Sensor). Damit sollte es kein allzu großes Problem sein die 
Datenpakete zuzuordnen.

[Frank E. (Firma: Q3) (qualidat)]

Dieter S. schrieb:
> Da es vermutlich immer noch um den Sensor von hier geht:
>
> Beitrag "serielles Sensor-Protokoll erkennen?"
>
> Die Dokumentation für das IPS-149 Binär-Protokoll ist eigentlich
> ziemlich eindeutig: Der Host schickt ein Kommando zum Sensor, dieser

Mag sein, aber wie ich im Eingangspost schrieb, ist da noch eine Platine 
mit einem Mikroprozessor (im Griff der Sensor-Ei3nheit) dazwischen - es 
wird nicht direkt mit dem Radarsensor kommuniziert.

[Dieter S. (ds1)]

Frank E. schrieb:
>
> Mag sein, aber wie ich im Eingangspost schrieb, ist da noch eine Platine
> mit einem Mikroprozessor (im Griff der Sensor-Ei3nheit) dazwischen - es
> wird nicht direkt mit dem Radarsensor kommuniziert.

Lade halt mal einen kompletten Mitschnitt hier hoch damit man sehen kann 
womit man es zu tun hat.