ADS1115 mist metingen

Hmm dit zijn van die lastig probleempjes waar je uren mee zoet kan zijn...

gewoon wat vragen.. om het plaatje comleet te krijgen en misschien helpt het..

Wat heb je als Full Scale Range? 4.096V ? Welke Data Rate?

Heb je een ingangsfilter bij de ADC?

Werk in je in Continuous Conversion of Single Shot mode?

In geval het laatste, wordt er gepold of de ADC klaar is voordt de data wordt uitgelezen?

Heb je de beschikking over iets van een Logic Analuzer om de data op de lijn te bekijken?

grtz,
cor

Tja, als software man zou ik direct de library funktie ads.readADC() verdenken. Zo een ADC1115 geeft normaal gesproken toch altijd wel een goed resultaat in mijn beleving.

Waar heb je die library vandaan?

met 47/2K en een max van 5,5V dat in de ADS mag, zou ik in principe tot 129V kunnen meten. de tester gaat tot 60V (48V ebike batterijen). de test loopt nu op max 4V dus

geen filters, de ADS hangt met een spannignsdeler van 47K/2K aan de accu
ook alles default van de settings.
had vroeger dit staan, maar had continue ellende omdat ik geen meting kreeg. dus alles uitgeschakelt behalve de ads.begin. dit was ook zo in 1 van de examples van de library (ADS1x15.h)

  ads.begin();
  //  ads.setGain(0);      
  //  ads.setDataRate(7);  //  0 = slow   4 = medium   7 = fast
  //  ads.setMode(0);      //  continuous mode
  //  ads.readADC(0);      //  first read to trigger

op het werk is alles beperkt tot een multimeter.
volgens mij is die -101 een foutcode. ik vind wel op google over error codes 101 van die ADS maar dit dan in combinatie met een adafruit library die een bug had. ik heb niet de adafruit code.

momenteel draait de code dus, waarbij ik alles wat negatief is aan de spanning, eruit gooi.
ik heb gemerkt dat de stroommeting wel correct gaat.
spanning geeft -101, stroom zegt 197.
197 x 1.8 / 1000 = 354mA en dat klopt ongeveer

3.53-7.05-10.58-14.10-17.61-21.12-24.64-28.15-31.67-35.18-885;3.52;0.33;1.18;0.08;0.29;
3.53-7.05-10.56-14.08-17.59-21.11-24.62-28.14-31.66-35.17-890;3.52;0.34;1.18;0.08;0.29;
3.54-7.05-10.57-14.08-17.59-21.11-24.62-28.14-31.65-35.18-895;3.52;0.34;1.18;0.08;0.29;
3.53-7.04-10.56-14.07-17.59-21.10-#
-101
197
24.61-28.12-31.64-35.15-900;3.52;0.34;1.18;0.08;0.30;
3.53-7.05-10.56-14.09-17.61-21.12-24.63-28.14-31.66-35.17-905;3.52;0.33;1.18;0.08;0.30;
3.53-7.06-10.59-14.12-17.64-21.16-24.67-28.19-31.72-35.23-910;3.52;0.34;1.19;0.08;0.30;
3.53-7.06-10.58-14.09-17.60-21.11-24.62-28.13-31.65-35.16-915;3.52;0.34;1.18;0.08;0.30;
3.53-7.04-10.55-14.07-17.58-21.09-24.60-28.11-31.63-#
-101
197
35.15-920;3.52;0.33;1.18;0.08;0.30;
3.53-7.04-10.55-14.07-17.58-21.09-24.61-28.12-31.63-35.15-925;3.51;0.33;1.17;0.09;0.30;
3.53-7.04-10.55-14.07-17.59-21.10-24.62-28.13-31.64-35.15-930;3.51;0.33;1.18;0.09;0.31;
3.53-#
-101
197
7.06-10.58-14.09-17.60-21.11-24.62-28.13-31.64-35.15-935;3.52;0.33;1.18;0.09;0.31;

het is ook nooit de eerste meting, maar telkens ergens midden van de loop.
hierboven dus 7de, 10de en 2de meting

Op woensdag 16 oktober 2024 10:29:38 schreef deKees:
Tja, als software man zou ik direct de library funktie ads.readADC() verdenken. Zo een ADC1115 geeft normaal gesproken toch altijd wel een goed resultaat in mijn beleving.

Waar heb je die library vandaan?

via dit (geeft fout bij popup blokker, maar bij F5 te drukken kan je steeds verder omlaag scrollen) https://how2electronics.com/how-to-use-ads1115-16-bit-adc-module-with-…
naar
https://github.com/RobTillaart/ADS1X15

[Bericht gewijzigd door fcapri op woensdag 16 oktober 2024 10:44:16 (10%)]

Is het deze library? https://github.com/RobTillaart/ADS1X15

Lees de readme over hoe die te gebruiken en kijk of je iets afwijkends doet.

EDIT: Het staat trouwens letterlijk in de header file:

#define ADS1X15_ERROR_TIMEOUT             -101

[Bericht gewijzigd door Benadski op woensdag 16 oktober 2024 10:44:57 (30%)]

ja, idd, moest even gaan zoeken in google history waar ik de boel gevonden had
is ook pas in een edit van start topic dat ik die -101 had gevonden.
die melding kreeg ik een paar dagen geleden ook altijd, vandaar dat al die opties werden afgezet want 1 van die examples werkte wel gewoon (dus hardware was ok)

Hi fcapri,

Wat tips...
Eerst het probleem uitzoeken, dan oplossen, geen plakbandjes gebruiken. (het oplossen in de code, als dit de oorzaak zou zijn)

Begin hiermee.
Goed ontkoppelen, bij je ADS1115 printje dus de voedingspanning.
Geef je Microcontroler ook een goede elco voor de voeding ontkoppeling.

Alle ingangen van de ADS1115 ontkoppelen, dit is een ADC voor b.v. metingen die jij ook doet, deze zijn "langzaam" dit t.o.v. b.v. audio.

Dus het is vrij makkelijk een RC aan de ingangen te zetten die de meeste EMC voor je filtert.
Je spanningsdeler heeft maar een condensator nodig over de 2K weerstand.

Gebruik de ADS1115 op een zo laag mogelijke sample rate, dat wordt de middeling al in de ADC gedaan.
Ik heb met de ADS1115 eigenlijk nog nooit problemen gehad, maar ik hou altijd rekening met het gene wat ik hierboven beschrijf

Oja, deze vergeet ik nog, de ADS1115 wordt uit 3.3V gevoed, dat houd in dat je nooit iets aan kan bieden aan de ingangen dat in de buurt komt van deze 3.3V
In de software kan je een bereik kiezen dat als ik het goed heb uit mijn hooft +-6V is, dat dynamisch bereik is niet volledig te geruiken omdat de voeding dus 3.3V is.

Je Microcontroler is een WiFi model denk ik, hou dus rekening met instraling op de andere elektronica.
Denken, het ging bij project "x" ook goed, heeft bij vele al voor grijze haren gezorgd.

Succes,
Bram

Ik gok ook op de library, mocht je nog wat inspiratie op willen doen heb ik ook een lithium tester gemaakt die o.a. ook de ESR meet:

https://github.com/Perr/Battery-meter/blob/master/Battery-meter.ino

ik heb eigenlijk al een ebike tester gebouwd, maar dan met een arduino. doet het prima, alleen moet er dan een pc aan blijven staan voor de serial output te hebben.

dus ben ik over gegaan naar een esp. serial naar HTML software gemaakt die het PRIMA doet.

dus sinds deze week begonnen om ook de testhardware aan te sluiten aan de ESP, en tot de conclusie gekomen dat er maar 1 analoge ingang op zit (moet spanning EN stroom meten).
in de garage nog een ADS1115 gevonden van een eerder project dat nu van pas komt. heb er eigenlijk nooit goed mee gewerkt, en alle libraries die ik had heb ik niet meer.

die -101 is dus een timeout. waarom die nu wel opduikt met een accu eraan, en 2dagen ervoor niks heeft gedaan terwijl die uren stond te draaien (0V meten), weet ik niet.
gisteren nog een calibratie gedaan zonder problemen.
en vandaag bij de test een 'gemiddelde' ingebouwd en nu heb ik time out fouten. ook met 100ms delay (het is al veel beter nu. krijg om de 4-5minuten nog 1 fout.
elke regel is hier 5seconden... de onderbreking is een timeout dus.

misschien de delay's nog wat verhogen ofzo of met een condensator de boel wat te middelen. nu belast ik met een 10ohm weerstand,
de tester zelf zal met een zonne paneel inverter zijn die met PWM aan de accu zit te rommelen. er zal zowieso veel te 'zien' zijn.

de 3,3V is wel save. ik heb een 25 deler zitten. dus met 60V erop, heb ik nog maar 2,4V aan de ingang. de stroom meting is over een 0,1ohm shunt. met 10A erdoor zit ik binnen de 1V

Op woensdag 16 oktober 2024 11:27:16 schreef Gekke Henkie34:
Ik gok ook op de library, mocht je nog wat inspiratie op willen doen heb ik ook een lithium tester gemaakt die o.a. ook de ESR meet:

https://github.com/Perr/Battery-meter/blob/master/Battery-meter.ino

ik belast de ebike batterijen met een 250W micro omvormer van zonnepanelen.
ik hoef maar 2 dingen te weten van de batterij
1) capaciteit
2) Ri

dat bepaald of een accu nog goed is of niet.
de energie steek ik in mijn huis ipv te verstoken in warmte.

deze hardware ga ik dan ook gebruiken om een grote (315Ah) lifepo aan te hangen.
de esp zal dan bepalen of de accu wordt opgeladen (injectie van zonnestroom) of de accu aan huis levert (hoofdzakelijk snachts dus). hardware is hetzelfde, en deze is ook al uitgerust dat die de lader kan inschakelen of de inverter.
enkel de code verschilt een beetje.

ik ga nog buttons voorzien in de html waarmee ik die dan in 'automode' kan zetten (accu eerst volledig opladen tot de stroom minder dan 10% was en dan de leeglooptest doen)

Onafhankelijk van de interne constructie van de ADC vinden vrijwel alle ADC's het wel fijn als een buffercondensatortje aan de ingang zit, Microchip bijvoorbeeld heeft het in elk geval NODIG om de metingen niet te beïnvloeden...

Jouw probleem lijkt op iets wat wij met de ADC van een LPC1756 hebben gehad: spookmetingen.
Veel metingen waren OK, maar af en toe kwan er een voorbij die veel lager (tot aan 0) of veel hoger (tot aan full scale) was, zelfs op een hard aan Vref gelegde input...
We hebben het opgelost met
* aangepaste sample rate (geen interferentie met andere clocks)
* softwarematig middelen (lopend gemiddelde)
* te sterk afwijkende waardes negeren
* (nog) betere ontkoppeling

Is het zo'n ADS1115 printje van Ali ?

Een losse ADS1115 kost €2,32 @2500 (full reel) bij Mouser
Kortom op zo'n 1€ printje van Ali is de kans klein dat je ADS1115 origineel is.

Ik heb in het verleden "vaag" gedrag gehad met clone MAX7219 die ik destijds nog door een mede CO'er heb laten decappen.

kosten wel wat meer op ali

heb de mijne van 2018 en toen 2€ betaald. weet niet wat de ADs in 2018 bij mouser kostte

Wel een beetje dom van die library. Igv timeout krijg je een error code ipv een ADC waarde, en die error code kun je niet onderscheiden van een echte waarde. Niet zo handig dus. In single-ended mode heb je daar geen last van want dan krijg je nooit zulke grote negatieve getallen.

Maar je kunt dus wel testen op ADS1X15_ERROR_TIMEOUT en die waarde overslaan. Dat is de enige error code die in die funktie zit.

Extra delays toevoegen helpt niet. De timeout zit binnen de ads.readADC() funktie.

Wel kun je de timeout aanpassen als je de sourcecode hebt van de library. Die wordt bepaald op regel 457 :

uint8_t timeOut = (128 >> (_datarate >> 5)) + 1;

Het zou ook kunnen dat de millis() funktie niet goed werkt doordat F_CPU een verkeerde klokfrequentie geeft.

Gebruikt die library de ALERT/RDY pin niet waarmee je kan zie dat een conversie klaar is ?

De library van Rob Tillaart ken die wel via ADS.isReady:

void loop()
  {
    if (ADS.isReady())
    {
      value = ADS.getValue();
      ADS.requestADC(pin);       //  request new conversion
    }
    //  do other things here
  }

https://github.com/RobTillaart/ADS1X15

Andere mogelijkheid: Je draait op een ESP, dus een processor met rtos. De library hanteert erg korte timeouts op hoge datarates.

Dus dan loop je het risico dat er een timeout ontstaat tgv een task-switch. Als je dan een paar milliseconden weg bent kan de library al een timeout teruggeven.

Ik zou zelf niet die readADC() functie gebruiken, maar pollen mbv
ADS.requestADC(pin), ADS.isBusy(), ADS.isReady() en ADS.getValue()

PS: een datarate 7 resulteert in een timeout van 2 milliseconden, wel erg op het randje volgens mij.

[Bericht gewijzigd door deKees op woensdag 16 oktober 2024 13:20:21 (11%)]

Op woensdag 16 oktober 2024 11:52:55 schreef Roland van Leusden:
Een losse ADS1115 kost €2,32 @2500 (full reel) bij Mouser
Kortom op zo'n 1€ printje van Ali is de kans klein dat je ADS1115 origineel is.

Ik heb ervaring met chipjes van TI die bij Mouser en Farnell ongeveer 5x duurder zijn dan wanneer je ze bij TI direct bestelt. LCSC houdt iets in de richting van 10% of 20% marge aan bij sommige producten. Die rekenen 1 dollar bij enkelstuks en 65 cent bij "full reel".

Hmm. TI rekent mij $1.77 als ik er 1000+ zou afnemen. LCSC komt er normaliter eerlijk voor uit als ze een chinese fabrikant voor een bepaald chipje vinden. Kijk naar "LM4781", daar zijn diverse fabrikanten voor die beweren een "redelijk compatible" chipje te maken (door hem dezelfde naam te geven).

Ik zou de seriele output op zo hoog mogelijke baudrate zetten zodat versturen weinig tijd kost. (ik gebruik meestal 115k2)
(ik weet niet of dat versturen in-line of met een interrupt gebeurt)

Voor de A/D moet je ook wel een goede referentie/voeding hebben, niet die van de microcontroller (zit teveel ellende op, dan is 16 bits zinloos)

De ADS heeft een eigen V ref, al weet ik natuurlijk niet hoe deze beinvloed wordt door een slecht voeding.. Ik gebruik hier ook een ADS op een testboardje zonder problemen / onderbrekingen, maar niet rechtstreeks aan een ESP.. Weet je zeker dat die ESP niet het probleem is, ik meen dat de Wifi Stack op een willekeurig moment kan ingrijpen, als er dan net een communicatie loopt met de ADS Als je de luxe hebt zou ik de ADS even aan een arduino hangen ofzo en dedicated monitoren, dan weeet je het snel genoeg of t aan de ADS of ESP ligt ...

Ik heb vanmorgen samen met Rob Tillaart de library gerepareerd.
Dus als je een update binnenhaalt dan zou dit probleem weg moeten zijn.

Oh nee, nog even wachten, of de development branch selecteren.

[Bericht gewijzigd door deKees op donderdag 17 oktober 2024 13:11:42 (19%)]

dat ging snel. de timeout hoger gezet?

ik ontwijk de meting gewoon door te kijken of ik een '-101' krijg en ik skip die meting in mijn loop en doe opnieuw.
de hardware ligt nu thuis, ben op het werk momenteel bezig met de nieuwere versie van de html code te maken (met knoppen op manueel de accu te laten laden, een test te starten, of in automode te werken)

zal de library nog wel eens downloaden zodat ik bij toekomstige versies niet weer in de problemen kom

Er is wel een betere errorcheck die 100% betrouwbaar is dmv getError():

void getvalues() {
  int sample_count = 0;
  int16_t rawV, rawA;
  spanning = stroom = 0;                  // reset all for new measurement
  while (sample_count < NUM_SAMPLES) {                // 10 samples
    rawV = ads.readADC(0);  // read the voltage on channel 0
    delay(100);
    rawA = ads.readADC(1);  // read the voltage on channel 1
    if ( ads.getError() == ADS1X15_OK ) {
      spanning += rawV * 4.185 / 1000;  // convert the raw value to voltage (assuming a gain of 1 and a reference voltage of 3.3V)
      stroom += rawA * 1.695 / 1000;
      sample_count++;
      Serial.print(spanning);
      Serial.print("-");
    } else {
      Serial.print("#");
    }
    delay(100);
  }
  spanning = spanning / NUM_SAMPLES;                    // average of 10 samples
  stroom = stroom / NUM_SAMPLES;
  watt = spanning * stroom;
}

Een enkele getError() is genoeg voor beide readADC() calls want een evt errorcode blijft staan totdat je hem uitleest met getError().

PS : de beide delays kunnen wel weg. Die maken het niet beter.

Inderdaad, de timeout heeft nu minimaal 10 mS speling.
Maar dan kan het altijd nog wel eens een enkele keer fout gaan op een systeem met RTOS dus je kunt beter wel de error-code ophalen.

En dan nog iets:
De sampleCount wordt alleen opgehoogd als je een sample binnenkrijgt. Maar dat betekent dat je in een dooie lus terechtkomt als de verbinding met de ADS1115 wegvalt. Dus daar kun je best een aparte teller voor bijhouden.

void getvalues() {
  int sample_count = 0;
  int error_count = 0;
  int16_t rawV, rawA;
  spanning = stroom = 0;                  // reset all for new measurement
  while (sample_count < NUM_SAMPLES) {                // 10 samples
    rawV = ads.readADC(0);  // read the voltage on channel 0
    rawA = ads.readADC(1);  // read the voltage on channel 1
    if ( ads.getError() == ADS1X15_OK ) {
      spanning += rawV * 4.185 / 1000;  // convert the raw value to voltage (assuming a gain of 1 and a reference voltage of 3.3V)
      stroom += rawA * 1.695 / 1000;
      sample_count++;
      Serial.print(spanning);
      Serial.print("-");
    } else {
      Serial.print("#");

      error_count += 1;
      if (error_count > 10) {
         Serial.print("Serieus probleem met ADS1115");
         break;
      }
    }
  }
  spanning = spanning / NUM_SAMPLES;                    // average of 10 samples
  stroom = stroom / NUM_SAMPLES;
  watt = spanning * stroom;
}

ik doe nu gewoon een check op -101.
zelf zonder ADS aangesloten krijg ik geen fouten of meldingen, staat overal gewoon 0,00

Ja check op -101 kan ook, ook al is dat een geldige A/D waarde.

En dat je geen fout krijgt als er geen verbinding is is eigenlijk ook wel vreemd. Puur mazzel dat de loop niet vast loopt.

Waarschijnlijk geeft getError() wel een foutmelding in dat geval.
Ik zou dat toch opvangen en het zichtbaar maken op een of andere manier.