-         

Ergebnis 1 bis 6 von 6

Thema: Störungssicherheit (EMV) des One Wire Bus

  1. #1
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    25.03.2006
    Ort
    nahe Tulln (Niederösterreich)
    Alter
    26
    Beiträge
    460

    Störungssicherheit (EMV) des One Wire Bus

    Anzeige

    Hallo,

    ich will die Temperatur eines 60V Lipo-Akkus messen, und zwar an 50 Stellen, verteilt über den ganzen Akku.
    Mein Plan ist, dafür DS18S20 Sensoren zu verwenden:
    http://www.reichelt.at/ICs-CA-ISD-/D...6b6af7f5d3f381

    Der Akku ist aber für einen Motor, der über PWM geregelt wird und bei Dauerbelastung 300A zieht. Motor, Regler und Akku sind höchstens 1m voneinander entfernt.

    Jetzt ist meine Frage, wie hoch die Chancen stehen dass der 1-Wire Bus diese Störungen verkraftet?
    Ich hatte schonmal ein Problem mit einem I2C Temperatursensor an einem 1m langen Kabel, das neben einem Kabel geführt wurde, durch das 3A pwm-moduliert geflossen sind... das hat nicht funktioniert.

    Ist der 1-Wire Bus robuster?

    lg Christoph
    Geändert von Christoph2 (26.10.2011 um 17:47 Uhr)

  2. #2
    Erfahrener Benutzer Roboter Genie Avatar von BMS
    Registriert seit
    21.06.2006
    Ort
    TT,KA
    Alter
    26
    Beiträge
    1.192
    Hallo,
    die Störsicherheit dürfte ähnlich sein. Beide Bussysteme sind asymmetrisch (d.h. Spannungspegel sind auf Masse bezogen) und relativ hochohmig ausgelegt (in erster Linie durch Pullup-Widerstand festgelegt).
    Besser wäre es, wenn du geschirmte Leitungen, höhere Spannungspegel oder ein symmetrisches Bussystem (z.B. RS485) verwendest.
    Grüße, Bernhard

    EDIT: Du kannst natürlich auch analoge Temperatursensoren verwenden und diese dann mit Differenzverstärkern auswerten. Da Störungen meist beide Leitungen gleichmäßig beeinflussen, rechnen sich so die Fehler raus. Der Aufwand ist allerdings höher.

  3. #3
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    25.03.2006
    Ort
    nahe Tulln (Niederösterreich)
    Alter
    26
    Beiträge
    460
    Hallo,

    Ja, RS485 wäre besser, aber dafür habe ich keine billigen Sensoren gefunden. Ich brauche ja 50 Sensoren, mehr als 3€ pro Stück dürfen die nicht kosten...

    Der uC, der die Sensordaten verarbeitet, sitzt auf einer Platine direkt beim Akku. Die Kabel zu den Sensoren sind also max. 50cm lang - aber es sind eben 50 Kabel parallel geschalten. Geschirmte Kabeln kann ich verwenden, das ist kein Problem.
    Gibt es eine Möglichkeit, einen "Bustreiber" zwischen uC und Sensoren zu schließen, der quasi als Puffer dient und die Störsicherheit erhöht?
    Wie z.B. der P82B96 für I2C?

    lg Christoph

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.556
    Zitat Zitat von Christoph2 Beitrag anzeigen
    Hallo,

    Ja, RS485 wäre besser, aber dafür habe ich keine billigen Sensoren gefunden. Ich brauche ja 50 Sensoren, mehr als 3€ pro Stück dürfen die nicht kosten...

    Der uC, der die Sensordaten verarbeitet, sitzt auf einer Platine direkt beim Akku. Die Kabel zu den Sensoren sind also max. 50cm lang - aber es sind eben 50 Kabel parallel geschalten. Geschirmte Kabeln kann ich verwenden, das ist kein Problem.
    Gibt es eine Möglichkeit, einen "Bustreiber" zwischen uC und Sensoren zu schließen, der quasi als Puffer dient und die Störsicherheit erhöht?
    Wie z.B. der P82B96 für I2C?

    lg Christoph
    Die RS485 Treiber z.B. SN 75176 (nur mit denen habe (ich) Erfahrung, sind nicht groß oder teuer aber halt nicht bidirektional. Man kann die Datenrichtung umschalten, aber wer soll das machen ohne das es kompliziert oder die Schaltung gleich am Sensor zu "heftig" wird. Im 1 Wire Wiki habe ich gelesen das das ein ziemlich Zeit genaues Signal bedarf wobei der Sensor auch noch seine Betriebsspannung aus den Datenstrom bekommt. Ich befürchte daher das Störsignale nicht gerade Produktiv sind.
    ABER Die Daten LO Aktiv also auf GND gezogen sind dominant und Störsignale durch z.B. Übersprechen auf GND gezogen sind GND = "platt". Positive Signalflanken sollte also eh nicht Stören können, Negative Störsignale können mit einer Diode "gekappt" werden. In diesem Sinne sollte 1 Wiere durchaus einiges verkraften. Ich würde einfach mit einem Sensor bei unterschiedlich langen Leitungen einen 24 h Testlauf "mitschneiden".

    Bei RS485 habe ich das so gemacht. 1200 m Tel Leitung 2x2x06 in Ringen Verdrahtet und in diesen Kabelringen eine alte stark feuernde Bohrmaschine laufen lassen sowie eine Leuchtstoff Röhre drauf gelegt. Dabei habe ich vom PC aus Daten gesendet, gelesen, verglichen und nach 24 h Die Fehler Quote anzeigen lassen.

    Gruß Richard

  5. #5
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    25.03.2006
    Ort
    nahe Tulln (Niederösterreich)
    Alter
    26
    Beiträge
    460
    Danke für eure Antworte, ich werd es mal mit 5 oder 10 Sensoren probieren, und lange Kabel zwischen den Sensoren verwenden. Wenns funktioniert kann ich ja die restlichen Sensoren leicht dazuhängen.

    lg Christoph

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von Vitis
    Registriert seit
    06.01.2005
    Ort
    Südpfalz
    Alter
    43
    Beiträge
    2.240
    wohl eher der falsche Ansatz, die Störungen vermeiden bzw. beseitigen ist die Devise.
    Vor den Erfolg haben die Götter den Schweiß gesetzt

Ähnliche Themen

  1. [ERLEDIGT] CRC von Dallas 1 Wire?
    Von der aller dümmste Anfänge im Forum C - Programmierung (GCC u.a.)
    Antworten: 17
    Letzter Beitrag: 24.05.2011, 19:44
  2. AVR als Slave am 1-Wire
    Von joerg2712 im Forum AVR Hardwarethemen
    Antworten: 1
    Letzter Beitrag: 10.02.2009, 20:31
  3. 2-wire 3-wire protokoll. Hilfe!
    Von schlaflos im Forum Assembler-Programmierung
    Antworten: 3
    Letzter Beitrag: 18.01.2008, 14:53
  4. Wie funktioniert ein 1-Wire bus?
    Von Gerko im Forum Assembler-Programmierung
    Antworten: 12
    Letzter Beitrag: 21.10.2007, 15:00
  5. One Wire / 1 Wire mit PIC ?
    Von DHigh im Forum PIC Controller
    Antworten: 2
    Letzter Beitrag: 24.08.2005, 21:22

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •