DS18B20 verrauschtes Signal [ATTINY85/R-PI]

[Ercksen (Gast)]

Guten Abend zusammen,

auch wenn es hier wohl schon zig tausend Beiträge zum DS18B20 und den 
damit verbundenen Problemen gibt, muss ich euch mal um Rat fragen.

Grober Aufbau meines Projektes: Mehrere 100W-LEDs sollen individuell 
dimmbar sein und kontinuierlich temperaturüberwacht werden. Da es noch 
viele weitere Funktionen inkl. eines Webservers etc. gibt, habe ich mich 
für den Einsatz eines Raspberry PIs entschieden. Ich hatte in einem 
Prototypen des öfteren Probleme mit Systemabstürzen und Fehlfunktionen 
in der Software (die dann aber auch meist durch mich verschuldet waren), 
die die Kühlkörper in den dreistelligen Celsiusbereich getrieben haben 
und das Ende einer LED besiegelt haben. In erster Linie ist es aber 
natürlich verdammt gefährlich aus brandschutztechnischer Sicht.

Nun sieht es wie folgt aus: Das Netzteil (HP PS-3701-1C) wird über eine 
Reihenschaltung von zwei Transistoren eingeschaltet. Es muss also

1) der PI sein "ja" geben
2) ein zusätzlicher µC (ATTINY85) sein "ja" geben.

Beide Prozessoren verfügen über einen separaten One-Wire-Bus und analog 
dazu hat jeder LED-Kühlkörper zwei DS18B20s verbaut.

Die LEDs werden mittels PWM gedimmt und alle Kabel, und zwar 
LED-Stromversorgung, 4-Pin-Lüfter-Kabel, 2x3-Pin DS18B20-Kabel 
(verdrillt), gehen dann nach einer gemeinsamen Strecke von 
durchschnittlich 50cm auf das Mainboard.


Nun zum Problem:

Während der PI die Temperaturen meist ohne Probleme lesen kann 
(Fehlerrate < 0.1%, was durch erneutes lesen leicht auszubessern ist), 
hat der ATTINY ab einem Duty-Cycle von >20% erhebliche Probleme die 
Temperatur zu lesen, da die CRC-Prüfsumme falsch ist. Die Fehlerrate 
liegt da je nach Duty-Cycle zwischen 10% und 100% (irgendwann schaltet 
er dann aus Sicherheitsgründen das Netzteil aus, LEDs gehen aus und 
keine zwei Sekunden später liest er wieder richtige Ergebnisse...).

Ich konnte die Fehlerrate meiner Ansicht nach etwas reduzieren, indem 
ich das Thermometerkabel vom Stromkabel der LED weg verlegt habe. Hier 
fließen schließlich die größten Störströme. Allerdings noch weit 
entfernt von brauchbar!

Bei einer PWM-Frequenz von 100 Hz tritt das Problem merkbar seltener auf 
als bei der Betriebsfrequenz von 650 Hz.

In meinen Augen muss es sich hierbei um Störsignale handeln. Aber wieso 
in aller Welt hat der PI keine Probleme die Temperatur auszulesen? Sind 
es vielleicht andere Timings? Beim PI benutze ich die native 
Schnittstelle und folgender Code (aus einer Lib im Netz) ist zum 
senden/empfangen auf dem µC verantwortlich:

uint8_t onewireWriteBit( volatile uint8_t *port, volatile uint8_t *direction, volatile uint8_t *portin, uint8_t mask, uint8_t bit )
{
  uint8_t sreg = SREG;

  #ifdef ONEWIRE_AUTO_CLI
    cli( );
  #endif

  *port |= mask; //Write 1 to output
  *direction |= mask;
  *port &= ~mask; //Write 0 to output

  if ( bit != 0 ) _delay_us( 8 );
  else _delay_us( 80 );

  *port |= mask;

  if ( bit != 0 ) _delay_us( 80 );
  else _delay_us( 2 );

  SREG = sreg;

  return bit != 0;
}

uint8_t onewireRead( volatile uint8_t *port, volatile uint8_t *direction, volatile uint8_t *portin, uint8_t mask )
{
  uint8_t sreg = SREG; //Store status register
  uint8_t data = 0;
  uint8_t i = 0;

  #ifdef ONEWIRE_AUTO_CLI
    cli( );
  #endif

  for ( i = 1; i != 0; i <<= 1 ) //Read byte in 8 single bit reads
    data |= onewireReadBit( port, direction, portin, mask ) * i;

  SREG = sreg;

  return data;
}

Ich bin für jede Hilfe dankbar! Falls Fragen offen geblieben sind, 
meldet euch gerne :).

Danke. Viele Grüße

Ercksen

[Einhart P. (einhart)]

Welche Pull-Up-Widerstände am Bus sind verbaut?

[Ercksen (Gast)]

Für beide Busse wird jeweils ein 4.7 kOhm verwendet. Hab auch testweise 
durch Parallelschaltung mit einem anderen Widerstand (da schon fest 
verlötet) den Widerstand etwas abgesenkt aber scheint nicht geholfen zu 
haben.

[Zeno (Gast)]

Alle Timings richtig?
Kann man aus dem geposteten Code nicht erkennen.

Nach dem Anstoßen der AD-Wandlung mußt Du mindestens 750ms warten bevor 
Du die Temperatur auslesen kannst. Vor jedem Zyklus ist ein 1-Wire-Reset 
erforderlich. Hast Du das alles beachtet.

[Wilke (Gast)]

Wie wird das PWM Steuersignal erzeugt, Raspi, Tiny, andere Hardware?

Wie wird der Attiny versorgt? Spannung? Vom Raspi genommen oder separat?

Ansonsten GND Verbindungen auf unerwünschte Schleifen kontrollieren.

[neuer PIC Freund (Gast)]

>Nach dem Anstoßen der AD-Wandlung mußt Du mindestens 750ms

Maximal 750ms. Meine melden sich nach ca. 660ms nicht mehr busy.

Anscheinend liest deine Bit-Routine den Pin gar nicht aus. Bei mir:

    if (value)
    {
        ow_low();
        _delay_us(4);
        ow_high();
        _delay_us(12);
        if ((PINB & (1 << PB1)) == (1 << PB1))
        {
            rv = 1;
        }
        else
        {
            rv = 0;
        }
        _delay_us(74);
    }
    else
    {
        ow_low();
        _delay_us(90);
        ow_high();
    }
    
    return rv;

wobei ich die delay-Zeiten mit dem Oszi ermittelt habe, wegen dem realen 
Aufbau.

[Zeno (Gast)]

neuer PIC Freund schrieb im Beitrag #6168367:
> Maximal 750ms.

Nö! Du darfst auch länger warten. Der Chip braucht lt. Spezifikation 
max. 750ms zur Konvertierung. Heißt im Umkehrschluß es kann auch 
schneller gehen. Ist halt blöd wenn man 700ms programmiert hat aber Chip 
720ms braucht, dann wird es halt nix.
Also programmiert man lieber 800ms und ist auf der sicheren Seite. Ich 
habe das genau so gemacht und keinerlei Probleme.

[Zeno (Gast)]

neuer PIC Freund schrieb im Beitrag #6168367:
> wobei ich die delay-Zeiten mit dem Oszi ermittelt habe, wegen dem realen
> Aufbau.

Da muß man gar nichts ermitteln. Wenn man sich an die Spezifikationen 
von Maxim hält, funktioniert das einwandfrei.

[Wolfgang (Gast)]

Ercksen schrieb:
> Für beide Busse wird jeweils ein 4.7 kOhm verwendet.

Und mit welcher Spannung läuft der Bus beim Raspberry Pi und beim 
ATtiny?

[neuer PIC Freund (Gast)]

>Ist halt blöd wenn man 700ms programmiert hat aber Chip 720ms braucht, dann wird 
es halt nix.

Yep. Ich polle den Sensor ob fertig und verwerfe das Ergebnis, wenn es 
länger als 750ms dauert. Das garantiert mir Maxim. Mit einfach nur 
Warten sind natürlich die 750ms als Untergrenze aufzufassen.

Mit dem Oszi schau ich mir die ersten 30us an. Insbesonders, ob der 
PullUp genügend steigende Flanke generiert, was zu den Wartezeiten 
passen muss. Bei langen Kabeln durchaus interessant.

[Sensor-Versteher (Gast)]

neuer PIC Freund schrieb im Beitrag #6168457:
>>Ist halt blöd wenn man 700ms programmiert hat aber Chip 720ms braucht, dann wird
> es halt nix.
>
> Yep. Ich polle den Sensor ob fertig und verwerfe das Ergebnis, wenn es
> länger als 750ms dauert. Das garantiert mir Maxim. Mit einfach nur
> Warten sind natürlich die 750ms als Untergrenze aufzufassen.

So ein Sensor ist auch nur ein Mensch. Wenn man den ständig fragt: "Bist 
Du fertig? Wie lange dauert es denn noch?" dann stellt der sich stur und 
labert Dich mit 16 Bit langen Worten zu, die aber nichts aussagen.

Laß ihn doch in Ruhe die Bits austellen und dann mit der Stange 
herausschieben.

[Peter D. (peda)]

Solange die Wandlung nicht fertig ist, wird einfach der vorherige Wert 
gelesen bzw. 85°C nach Einschalten.
Bei parasite Power darf man natürlich nicht vorzeitig lesen.

[Ercksen (Gast)]

Danke für die vielen Antworten!

> Nach dem Anstoßen der AD-Wandlung mußt Du mindestens 750ms warten

Ich warte eine ganze Sekunde.

> Maximal 750ms. Meine melden sich nach ca. 660ms nicht mehr busy.

... und eine Sekunde ist vielleicht zu viel? Ich werde es gleich mal mit 
weniger ausprobieren, sprich 750ms und 600ms.

> Anscheinend liest deine Bit-Routine den Pin gar nicht aus

Geschieht in

onewireReadBit()

. Hab leider, wie ich gerade sehe, die falsche Funktion gezeigt.

> Wie wird das PWM Steuersignal erzeugt, Raspi, Tiny, andere Hardware?

Mittels PCA9685, der über den Pi angesteuert wird. Schaltet dann das 
Gate eines IRLZ34N. Das Signal hat eine Spannung von ca. 34 V bei 3 A.

> Wie wird der Attiny versorgt? Spannung? Vom Raspi genommen oder separat?

> Und mit welcher Spannung läuft der Bus beim Raspberry Pi und beim ATtiny?

Wird über die 3.3 V vom Pi versorgt. Mit einem Multimeter gemessen 
scheinen sie sehr stabil zu sein. Die Stromversorgung lässt sich mittels 
Jumper auf 5V vom USB umstellen (inklusive One-Wire-Bus), das ändert 
aber gar nichts.

[Ercksen (Gast)]

Ich werde den Bus gleich mal an den ADC meines Projektes anschließen, wo 
noch ein Kanal frei ist und mal ein kleines Oszi bauen. Vielleicht hilft 
das ja weiter...

[Ercksen (Gast)]

> Ansonsten GND Verbindungen auf unerwünschte Schleifen kontrollieren.

Wie ist das zu verstehen? Netzteil-GND und Logik-GND sind 
zusammengeführt und eigentlich liegen überall GND-Kabel "rum". Könnte 
das zu so erheblichen Problemen führen oder habe ich das falsch 
verstanden?

[Ercksen (Gast)]

Habe mir nun die Signale angeschaut. Es fällt auf, dass bei den 
verrauschten Übertragungen einige Low-Peaks auftreten, die mir so nicht 
richtig erscheinen.

Leider ist die Samplingrate inkonsistent, weswegen die 
X-Achsenbeschriftung nicht wirklich aussagekräftig ist. Aber bis auf das 
zweite Rauschbeispiel sieht das doch noch recht "normal" aus, oder?

Vielleicht fällt ja jemandem von euch was auf.

[Wolfgang (Gast)]

Ercksen schrieb:
> Netzteil-GND und Logik-GND sind zusammengeführt ...
Wo? Hoffentlich direkt am Netzteil.

> ... und eigentlich liegen überall GND-Kabel "rum". Könnte
> das zu so erheblichen Problemen führen oder habe ich das falsch
> verstanden?

Wenn der DS18B20 den Spannungsabfall auf Grund des geschalteten 
LED-Stromes sieht, sind Probleme vorprogrammiert.

[Ercksen (Gast)]

> Wo? Hoffentlich direkt am Netzteil.

Jap.

> Wenn der DS18B20 den Spannungsabfall auf Grund des geschalteten
> LED-Stromes sieht, sind Probleme vorprogrammiert.

Verständlich. Die Logikspannung kommt jedoch von einem gesonderten 
Netzteil (Original RPi Netzteil mit 5.1V) und muss lediglich mit 650 Hz 
das Gate des FETs füttern - wenn dadurch ein solcher Spannungsabfall 
entsteht, fänd ich das schon merkwürdig. Zumal die 3.3 V ja zusätzlich 
nochmal geregelt sind auf dem Pi...



Besonders fragwürdig finde ich die Tatsache, dass es am Pi selber 
tadellos klappt. Ich tausche mal die Thermometer der beiden Busse, 
vielleicht hat ja einer einen Schlag.

[Ercksen (Gast)]

Es scheint übrigens keine Störung in den Kabeln zu sein.

Wenn nur eine LED leuchtet, hat auch ein komplett anderes Thermometer an 
diesem Bus Probleme, auch wenn die Kabel in die ganz andere Richtung 
gehen...

[Ercksen (Gast)]

Ok bitte VERGESST den vorherigen Beitrag. Es ist ja schließlich ein 
1-Wire-Bus. Die Daten fließen also natürlich in jedes Kabel und können 
demnach auch überall gestört werden...

[Ercksen (Gast)]

Problem gelöst!

Ich habe testweise die Sensoren beider Busse vertauscht und siehe da, 
einer hat sich als defekt erwiesen. Die Symptome haben sich genau 
getauscht - der Pi kriegt bei eingeschalteter LED keine Temperatur mehr 
und der Tiny läuft ohne Probleme.

Danke für all die Hilfe, hätte ich das mal früher gewusst...

[Zeno (Gast)]

neuer PIC Freund schrieb im Beitrag #6168457:
> Yep. Ich polle den Sensor ob fertig und verwerfe das Ergebnis, wenn es
> länger als 750ms dauert. Das garantiert mir Maxim. Mit einfach nur
> Warten sind natürlich die 750ms als Untergrenze aufzufassen.

Das kannste machen wenn Du nur einen Sensor hast. Bei 10 und mehr 
Sensoren stößt man die Wandlung für alle Sensoren an, dann hat man 750ms 
Zeit andere Dinge zu erledigen und danach fragt man nacheinander alle 
Sensoren. Da Schafft man es das man alle 1s einen neuen Wert hat was bei 
Temperaturen allemal ausreicht. Schneller muß es nicht sein, weil sich 
Temperaturen auch nicht so schnell ändern.
Pollen macht an dieser Stelle überhaupt keinen Sinn.

[Wilke (Gast)]

Ercksen schrieb:
> Problem gelöst!
>
> Ich habe testweise die Sensoren beider Busse vertauscht und siehe da,
> einer hat sich als defekt erwiesen. Die Symptome haben sich genau
> getauscht - der Pi kriegt bei eingeschalteter LED keine Temperatur mehr
> und der Tiny läuft ohne Probleme.
>
> Danke für all die Hilfe, hätte ich das mal früher gewusst...

Das ist aber seltsam, da du ja eingangs geschrieben hast, dass bei 
ausgeschalteter LED beide Sensoren korrekte Temperaturen zeigen. Das 
spricht ja weniger für einen defekten Sensor. Funktioniert jetzt nach 
Austausch des "defekten" Sensors gegen einen dritten neuen Sensor alles 
wie gewünscht?

Hast du auch einen zweiten Crosscheck gemacht? Nicht nur die Busse 
vertauscht, sondern auch mal die beiden Sensoren komplett getauscht 
(Befestigung, Leitungsführung)?

[Ercksen (Gast)]

> Das ist aber seltsam, da du ja eingangs geschrieben hast, dass bei
> ausgeschalteter LED beide Sensoren korrekte Temperaturen zeigen

Ich muss mich getäuscht haben. Ich weiß nicht, ob es ein dummer Zufall 
war und es nur deshalb geklappt hat, aber heute war das Problem nach 
Sensortausch wieder da.

Allerdings ist mir aufgefallen, dass es auch wirklich IMMER dieser 
eine Sensor ist, der unzuverlässig funktioniert. Also habe ich ihn 
abgeschraubt und ein bisschen experimentiert.

Dazu muss man wissen: Der GND vom DS18B20 ist (aus Stabilitätsgründen) 
mit der Öse zum befestigen am Kühlkörper verlötet. Wenn ich den Sensor 
abschraube und ihn nicht berühre, läuft alles. Sobald die Öse den 
Heatsink berührt, ist Schluss. Aber nur bei diesem Sensor! Bei allen 
anderen ist es baugleich und läuft super. Der Heatsink ist nicht weiter 
geerdet/an GND, außer halt durch den zweiten DS18B20.

[Wilke (Gast)]

Ercksen schrieb:

> Dazu muss man wissen: Der GND vom DS18B20 ist (aus Stabilitätsgründen)
> mit der Öse zum befestigen am Kühlkörper verlötet. Wenn ich den Sensor
> abschraube und ihn nicht berühre, läuft alles. Sobald die Öse den
> Heatsink berührt, ist Schluss. Aber nur bei diesem Sensor! Bei allen
> anderen ist es baugleich und läuft super. Der Heatsink ist nicht weiter
> geerdet/an GND, außer halt durch den zweiten DS18B20.

Und du bist sicher, daß die LED keine leitende Verbindung zum Heatsink 
hat?

Aber was solls, wenn du weitere baugleiche Aufbauten hast die 
funktionieren, dann wirf doch einfach den seltsamen Sensor raus und 
ersetze ihn durch einen anderen.

Zeige doch mal ein Bild von diesem Sensor, würde mich einfach 
interessieren wie das Ding ausschaut.

[Ercksen (Gast)]

> Und du bist sicher, daß die LED keine leitende Verbindung zum Heatsink
> hat?

Ja. Ist geprüft.

Ich habe nun die Sensoröse mittels Wärmeleitpad (isolierend) am Heatsink 
befestigt und nun läuft alles klasse. Komisch, dass es bei den anderen 
fünf auch so funktioniert.

Hab dir mal ein Bild von den Sensoren angehängt. Ist in so einem 
0815-Kabelschuh der Farbe Gelb eingecrimpt. Kann ich übrigens nur 
empfehlen, sehr stabil und die einzig mir bekannte Möglichkeit, ein 
TO-92 Gehäuse gescheit zu befestigen...