Je zou denken dat de maximale temperatuur wordt gemeten. Ik weet niet of dat bij 0V of 5V gebeurt.

Mijn eerste gedachte is dat u mogelijk een andere, actuelere variant van de sensor voorhanden heeft, zoals de bekendere ds18B20.

[offtopic]
Tenzij u specifiek technisch inhoudelijke belangstelling heeft voor PIC/PICBASIC zou ik iets populairs pakken dat op een "normale" manier werkt, dus met zichtbare libraries, pin definities, foutmeldingen en OneWire adressen. Dit zonder het A-woord te gebruiken, het gaat mij er expliciet niet om een discussie uit te lokken.

255 is de waarde die je krijgt als er geen sensor is aangesloten.

Volgens de datasheet moet er eerst een ROM commando gestuurd worden om de sensor te adresseren. Daarna inderdaad een "convert" commando gevolgd door een "read scratch"commando.
DE sensor reageert met 9 bytes. De eerste twee zijn de lsb en msb van de temperatuur. Daarna volgen 6 bytes die je denkelijk niet nodig hebt en als laatste een CRC byte. Uiteraard kun je de laatste 7 bytes gewoon negeren.

Op donderdag 12 februari 2026 10:53:22 schreef Sine:
@Kees,
Beide niet, die sensor is digitaal.

De output wel ja. Maar de te meten temperatuur kan een oneindig aantal mogelijkheden hebben. Hoe werkt dat dan bij deze digitale sensor (anders dan dat het bereik tussen laag en hoog wordt vertaald naar een spanning tussen 0 en 5V en dat dan weer wordt omgezet naar een digitale waarde)?

DE DS18B20 heeft een bereik van -55 tot +125 graden. Dus dat zal het probleem niet zijn.

Ik verwacht meerdere problemen:
1) je wacht na start conversie niet totdat de uitlezing klaar is. Voeg eens een PAUSE 750 toe vlak voor het OREAD commando
2) er kunnen 'resets' nodig zijn na de commando's, en daarvoor kan je beter OWIN gebruiken dan OREAD.
3) je krijgt twee bytes terug voor de temperatuur, en die stop je in de variabele TEMPERATUUR, die kennelijk slechts 1 byte lang is. Lijkt me niet OK. Probeer eens iets als OWIN DQ,0,[ TempLSB, TempMSB ].
4) de berekening zou dan zijn (RawTemp en TempC zijn type WORD) :
RawTemp = TempMSB
RawTemp = RawTemp << 8
RawTemp = RawTemp + TempLSB
TempC = RawTemp >> 4 ' integer temperatuur in °C
5) ben niet zo'n PICBASIC kenner, maar de I/O pin moet bij Onewire wisselen tussen input / output functie. Iets met TRIS... commando voor de WHILE lus?

Als het niet helpt dan ook even met een scope checken of er uberhaupt data verkeer is met de sensor.

Als je allemaal binair 1 ontvangt lijkt me dat de device niet reageerd. (even aangenomen dat het allemaal goed is aangesloten)

Moet je deze ook niet eerst 'selecteren' ik dacht dat daar iets mee was omdat je meer devices parallel kan zetten op onewire.

Op donderdag 12 februari 2026 11:48:21 schreef Leo-Bolier:
Volgens de datasheet moet er eerst een ROM commando gestuurd worden om de sensor te adresseren. Daarna inderdaad een "convert" commando gevolgd door een "read scratch"commando.
DE sensor reageert met 9 bytes. De eerste twee zijn de lsb en msb van de temperatuur. Daarna volgen 6 bytes die je denkelijk niet nodig hebt en als laatste een CRC byte. Uiteraard kun je de laatste 7 bytes gewoon negeren.

Het adres van de DS18(B)20 zit ingebakken in de sensor. Kan je best opvragen bij de setup sequentie. In picbasic ken ik de juiste handelswijze niet maar in arduino omgeving krijg je na oneWire.search(array); een array met alle adressen. Je kan dan deze array gebruiken om de gegevens op te vragen. In de Arduino library zit er standaard een wachttijd in nadat je een conversie doet. Is dat ook zo bij picbasic? Ik zet het normaal uit, laat het programma verder doen en x tijd later vraag ik de temperatuur dan op. Je blokkeert zo het programma niet.

Bedankt voor de vele reacties. Ik denk met name de reactie van Kojazz relevant is. Die ga ik uitproberen.
Alvast bedankt.

Het lijkt niet zo waarschijnlijk dat men een niet-werkend voorbeeld geeft.
Het komt overigens van deze pagina:
https://www.picbasic.nl/frameload.htm?https://www.picbasic.nl/electro_…

Ik gebruik er een drietal in parallel met een Arduino. -127 wijst op dat er geen of geen goede communicatie is met de Dallas sensor. Dit komt ook voor als er teveel interferentie is op de signaal/aansluitkabel.

Heb hier zelf ook soms last van over een lengte van c.a. 15 meter kabel. Afgeschermde kabel kan dit helpen voorkomen. bij meerdere sensoren is het altijd even uitzoeken welke sensor het laagste serienummer heeft (Byindex).

[Bericht gewijzigd door Vonkenpromotor op (19%)]

Hangt die 4k7 aan de pic of in de nabijheid van de ds1820 ?
Laat maar, 't zit op een breadboard .

[Bericht gewijzigd door Lead Acid op (25%)]

Ik gebruik 1 DS1820, dus hoef ik niet te adresseren.
Ik maak inderdaad gebruik van de voorbeelden van de website https://www.picbasic.nl (klikken op "projecten" en daarna op "Temperatuursensor DS1820 geeft ......").
Ik heb de schakeling op breadboard gemaakt en het programma van voorbeeld 1 gebruikt (zie ook mijn vorige bijlages). In het programma van voorbeeld 1 heb ik voor de OREAD instructie een pauze van 750 msec ingelast (Delayms 750). Het resultaat blijft hetzelfde (127,5 graad C). Ook verwisselen van de DS1820 geeft geen resultaat. Is de conclusie juist dat de DS1820 niet wordt uitgelezen? Hoe is dit te verhelpen?

Begin eens met het serienummer lezen. Tegen de tijd dat je dat werkend hebt, inclusief kloppende CRC kun je dat ding eens een commando gaan geven, wachten tot-ie klaar is (dat kun je toch ook pollen?) en dan de conversie uitlezen.

Nou ken ik pic-ding-basic niet, maar normaal begin je met een reset puls. Dan komt het device terug met een 'present'. Daarna kun je er tegen kletsen. Wellicht is dat impliciet. Wellicht ook niet.

Verder: kijk eens met een scope of er leven op die pin is.

Op vrijdag 13 februari 2026 14:21:47 schreef henkiepi:
Ik gebruik 1 DS1820, dus hoef ik niet te adresseren.
[...]

Ja en neen. Ja, de DS1820 heeft net zo goed een 64 bit adres als de DS18B20. Wil je meer one wire zaken gebruiken, dan is dit dwingend noodzakelijk wil je weten welke device je aanspreekt of wil aanspreken. Neen, als er maar 1 one wire device aan hangt. Is er geen voorbeeld bij voor meerdere DS18(B)20? Daar zit zeker de adressering in. Is de timing van je PIC correct? Juiste instellingen voor het gebruikte kristal of interne oscillator?

Zoals al enkele keren aangehaald, probeer eens eerst het adres uit te lezen. Lukt dat niet, gaat de rest ook niet lukken. De 4k7 trekt de data lijn naar + (dus 1). Elke one wire device moet de datalijn naar GND trekken om een 0 te 'verzenden'. Dat gaat bij je duidelijk niet goed. Heb je al eens met een Ohm meter gekeken of de verbinding tussen je PIC IO en het data pootje wel degelijk OK is. Een breadboard durft wat dat betreft wel eens moeilijk te doen. De contacten zijn niet altijd even goed.

Op vrijdag 13 februari 2026 14:21:47 schreef henkiepi:
Ik gebruik 1 DS1820, dus hoef ik niet te adresseren.

Die DS1820 die wordt al best wel lang niet meer gemaakt. Er zijn DS18B20 en opvolgers die beter zijn. Het lijkt me dus "raar" dat je nog zo'n oude zou hebben. (kijk, dat ik van 20 jaar geleden nog een ouderwetse 1820 uit de kast trek, /dat/ verbaast me niets... maar jij.... )

Je initiele probleem, dat er 255 gelezen wordt, is een hint dat er "geen communicatie" plaatsvind. Niet dat de chip denkt dat het 127 graden is.

k heb hier een voorbeeld programmaatje voor een Arduino, misschien dat je er wat aan hebt.
*******************************

#include <OneWire.h>

// OneWire DS18S20, DS18B20, DS1822 Temperature Example
//
// http://www.pjrc.com/teensy/td_libs_OneWire.html
//
// The DallasTemperature library can do all this work for you!
// https://github.com/milesburton/Arduino-Temperature-Control-Library

OneWire  ds(10);  // on pin 10 (a 4.7K resistor is necessary)

void setup(void) {
  Serial.begin(9600);
}

void loop(void) {
  byte i;
  byte present = 0;
  byte type_s;
  byte data[9];
  byte addr[8];
  float celsius, fahrenheit;
  
  if ( !ds.search(addr)) {
    Serial.println("No more addresses.");
    Serial.println();
    ds.reset_search();
    delay(250);
    return;
  }
  
  Serial.print("ROM =");
  for( i = 0; i < 8; i++) {
    Serial.write(' ');
    Serial.print(addr[i], HEX);
  }

  if (OneWire::crc8(addr, 7) != addr[7]) {
      Serial.println("CRC is not valid!");
      return;
  }
  Serial.println();
 
  // the first ROM byte indicates which chip
  switch (addr[0]) {
    case 0x10:
      Serial.println("  Chip = DS18S20");  // or old DS1820
      type_s = 1;
      break;
    case 0x28:
      Serial.println("  Chip = DS18B20");
      type_s = 0;
      break;
    case 0x22:
      Serial.println("  Chip = DS1822");
      type_s = 0;
      break;
    default:
      Serial.println("Device is not a DS18x20 family device.");
      return;
  } 

  ds.reset();
  ds.select(addr);
  ds.write(0x44, 1);        // start conversion, with parasite power on at the end
  
  delay(1000);     // maybe 750ms is enough, maybe not
  // we might do a ds.depower() here, but the reset will take care of it.
  
  present = ds.reset();
  ds.select(addr);    
  ds.write(0xBE);         // Read Scratchpad

  Serial.print("  Data = ");
  Serial.print(present, HEX);
  Serial.print(" ");
  for ( i = 0; i < 9; i++) {           // we need 9 bytes
    data[i] = ds.read();
    Serial.print(data[i], HEX);
    Serial.print(" ");
  }
  Serial.print(" CRC=");
  Serial.print(OneWire::crc8(data, 8), HEX);
  Serial.println();

  // Convert the data to actual temperature
  // because the result is a 16 bit signed integer, it should
  // be stored to an "int16_t" type, which is always 16 bits
  // even when compiled on a 32 bit processor.
  int16_t raw = (data[1] << 8) | data[0];
  if (type_s) {
    raw = raw << 3; // 9 bit resolution default
    if (data[7] == 0x10) {
      // "count remain" gives full 12 bit resolution
      raw = (raw & 0xFFF0) + 12 - data[6];
    }
  } else {
    byte cfg = (data[4] & 0x60);
    // at lower res, the low bits are undefined, so let's zero them
    if (cfg == 0x00) raw = raw & ~7;  // 9 bit resolution, 93.75 ms
    else if (cfg == 0x20) raw = raw & ~3; // 10 bit res, 187.5 ms
    else if (cfg == 0x40) raw = raw & ~1; // 11 bit res, 375 ms
    //// default is 12 bit resolution, 750 ms conversion time
  }
  celsius = (float)raw / 16.0;
  fahrenheit = celsius * 1.8 + 32.0;
  Serial.print("  Temperature = ");
  Serial.print(celsius);
  Serial.print(" Celsius, ");
  Serial.print(fahrenheit);
  Serial.println(" Fahrenheit");
}

I

**************************
Succes

Met 1 chip op de bus hoef je in principe niet te adresseren. Een van de rom commando's (skiprom, 0CCH) is dat elk device op de antwoord zal geven. Omdat er maar 1 chip op de lijn zit kun je zo werken. In het voorbeeld dat TS gebruikt en at ook op die bewuste webpage staat wordt dat commando ook gebruikt. Gevolgd door een Convert ( 44h) en een Readscratch (0BEh). Dat voorbeeld lijkt mij helemaal in orde.
Zolang je alleen maar FF als antwoord krijgt is het onzin om het specifieke device adres proberen uit te lezen.
TS zal naar de randvoorwaarden moeten kijken (timing, delays tussen de commando's, pull-up, storingen door gebruik van een breadboard enz).

Zo lang er geen adres uitkomt, zal er ook geen temperatuur verschijnen. De sensor trekt de lijn niet omlaag of het wordt niet vastgesteld binnen de timing. Het is dus eerst zoeken of de connecties allemaal 100% zijn. 100n over de DS1820 voeding kan ook geen kwaad.

Op zaterdag 14 februari 2026 08:16:16 schreef Vonkenpromotor:
Ik heb hier een voorbeeld programmaatje voor een Arduino, misschien dat je er wat aan hebt.
Succes

Prima voorbeeldje. Ik heb het even in mijn Arduino mega 2560 gedumpt en dat werkt perfect. Hierbij ook even de LA opname:

Hier zie je hoe pakket2 waar de rom waarde uitgelezen wordt . In het Arduino project zie je dan de data die via de serial device naar buiten komt:


ROM = 28 FF 64 2 D0 45 A7 10
  Chip = DS18B20
  Data = 1 58 1 55 0 7F FF C 10 FF  CRC=FF
  Temperature = 21.50 Celsius, 70.70 Fahrenheit
No more addresses.

In bijgaand programma heb ik de eerste OWRITE instructie een delay van 750 ms toegevoegd en de klokfrequentie teruggebracht van 20 Mz naar 4 MHz. Nu werkt het wel.
Dit programma is beperkt tot positieve temperaturen met een nauwkeurigheid van +/- 0,5 graad.
In een geavanceerder programma van de site zijn zowel positieve als negatieve temperaturen te meten met een nauwkeurigheid van 0,01 graad (zie bijlage).
Heeft iemand hier ervaring mee?
Waarom wordt er gemanipuleerd met getallen?
Bij mij is het resultaat negatief met een grote negatieve temperatuurwaarde terwijl het reultaat positief moet zijn.

Bijlage listing vb5 is niet meegekomen. Alsnog hierbij.

Zit de fout niet in het gebruik van 2 complement?