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.
Angehängte Dateien:
-
master_slave_onewire.png
8,3 KB
:
Bearbeitet durch User
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.
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.
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.
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.
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 :-)
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.
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 ...
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.
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)
:
Bearbeitet durch User
Angehängte Dateien:
-
one-wire-simu.png
20 KB
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.
:
Bearbeitet durch User
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 ...
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.
:
Bearbeitet durch User
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
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.
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.
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.
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.
Kurzer Zwischenbericht: Wir haben die Variante mit einem ESP8266 (Wemos D1 Mini) und zwei gekoppelten SoftSerials realisiert. Anzeigeeinheit und Sensor kommunizieren völlig ungestört miteinander und wir können alles mitlesen, inklusive Richtung. Wie bereits erwähnt, der eigenetlich Messwert-Transfer ist sehr offensichtlich, allerdings benötigt die Initialiserungsphase noch etwas Aufwand ... wir sind dran.
:
Bearbeitet durch User
Bruno V. schrieb: > Optokoppler brauchen 10fache Spannung und Strom und sind deutlich > zickiger. Photomos sind vielleicht ein bisschen besser. aber zu langsam, sie brauchen zwar weniger IR Strom für mehr Schaltstrom, ABER sie sind zu langsam für PWM und damit auch zur Datenerkennung. Peter D. schrieb: > 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. +1
:
Bearbeitet durch User
Man kann ja jedes Problem beliebig kompliziert lösen. In diesem Fall reicht vermutlich ein Logic Analyzer der die Daten von der Anzeigeeinheit zum Nec 78k im Griff des Sensors mitschneidet (ein Kanal für UART auf einer Leitung). Ein zweiter Kanal des Logic Analyzer schneidet die Daten vom Nec 78k zum eigentlichen Sensor mit (ebenfalls UART auf einer Leitung, das Protokoll ist bekannt). Damit hat man dann alles ohne viel Aufwand. Da der TO aber hier den kompletten Mitschnitt nicht zeigen will kann man nicht beurteilen wie kompliziert es tatsächlich ist. Nachtrag: Da alle Beteiligten (Anzeigeeinheit, Nec 78k und Sensor) unterschiedliche Taktquellen (Quarze) verwenden wird man vermutlich bei entsprechend hoher Abtastrate (z.B. 16 MHz) anhand der minimalen Unterschiede im UART Timing sogar erkennen können wer die Daten gerade sendet.
:
Bearbeitet durch User
Das Problem ist gelöst, wir können nun den Sensor auch initialisieren, ohne das Original-Steuergerät zu verwenden. Speziell in der Init-Phase wissen wir zwar nicht genau, was jedes Byte bedeutet, aber wir konnten eindeutig den jeweiligen Sender idetifizieren und den Sensor mit den aufgezeichneten Sequenzen auch problemlos zum Leben erwecken. Was den Aufwand betrifft: die 30 Zeilen Arduino-Code auf einen ESP zu beamen und die 3 Dupond-Strippen (Data A, Data B, GND), waren am Ende wirklich nicht der Rede wert. Und wir haben uns damit begnügt, lediglich die Signale an den Anschlussbuchsen abzugreifen, im Inneren wollten wir nichts herumlöten. Das Gerät soll noch verwendet werden. Es handelt sich um das (ältere) Baufeuchte-Mess-System auf "Mikrowellen-Basis" von Trotec, bestehend aus der Anzeigeeinheit "T2000S" und dem Sensor "TS350 SDI". Wir sind gerade dabei, unsere Fühler nach dem (optisch identischen) aktuellen Sensor TS610 auszustrecken, aber der ist nicht ganz billig. Warum wir das machen? Wir sollen mehrere Messungen automatisch über löngere Zeit gleichzeitig machen und die Daten in einer Datenbank aufzeichnen. Das kann und will Trotec (nach Anfrage) nicht ...
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.