Spanningsbron met "Erg" hoge resolutie

Hi Bram,

Daar klopt iets niet. Die string funkties zijn wel niet erg snel, maar moeten toch wel binnen 10 microseconden klaar zijn. 64 milliseconden is dus een factor 6000 te groot.

Je kunt wel de getalswaarde vergelijken, maar ook dat heeft zijn problemen met doubles. Dan kan het zomaar zijn dat je afrond problemen krijgt dus dat de getallen eigenlijk gelijk zijn maar in werkelijkheid een fraktie verschillen. Dus bijvoorbeeld 3.6 != 3.599999999999999. Na conversie naar string worden allebei afgerond naar 3.6 en dus gelijk, maar de werkelijke waarde is niet gelijk.

Maar dan krijg je dus iets als:

code:


char ADC_Buffer[10];  // Make "char" variable ADC_Buffer for formatting ADC value
static double ADC_Old;
double ADC_New;

ADC_New = 1.0F * ads.readADC_SingleEnded_V(0);
if(abs(ADC_New - ADC_Old) > 0.00005)
{  dtostrf(ADC_New, 6, 4, ADC_Buffer);
   ucg.print(ADC_Buffer);                              // Place measured output voltage on display if it is different from the last conversion
   ADC_Old = ADC_New;                               // Update delta_adc
}

Je moet trouwens wel oppassen met variabelen binnen een funktie. Die bestaan namelijk niet meer zodra de funktie afgelopen is, en worden opnieuw aangemaakt als de funktie opnieuw aangeroepen wordt. En ADC_Old moet zijn waarde bewaren voor de volgende loop. Dat kun je doen door ofwel de variabele buiten de loop te zetten, ofwel de variabele static te maken zoals hierboven.

dtostrf() en ucg.print() zijn allebei 'dure' funkties, die kosten veel cpu-tijd.

Aangezien de resolutie van micros(); niet goed genoeg is even een andere aanpak gedaan.

c code:

void setup() {
 pinMode(2, OUTPUT);
}

void loop() {

int foo = 100;
int bar = 110;

PIND = PIND | 0b00000100; // toggle D2
if (foo == bar) {
   }
PIND = PIND | 0b00000100; // toggle D2

char ADC_Old[] = "ADC_Old12345";
char ADC_New[] = "ADC_New12345";

PIND = PIND | 0b00000100; // toggle D2
if(strncmp(ADC_Old, ADC_New, sizeof(ADC_Old)) != 0)
   { 
    // This code will execute...
   }
PIND = PIND | 0b00000100; // toggle D2

delay(1000);
}

Dit geeft op de logic analyser het volgende resultaat:

Eerste blok is de INT (83,3 ns), dan vullen ADC_ strings en vervolgens de strncmp (0.167 us). Deze metingen bevestigen de opmerkingen van deKees, jouw meting van 64ms voor de stringfuncties klopt niet.

It's the rule that you live by and die for It's the one thing you can't deny Even though you don't know what the price is. It is justified.
blackdog

Golden Member

Hi deKees,

Je hebt waarschijnlijk het probleem waar ik al een tijdje mee aan het stoeien ben, opgelost denk ik.

Ik ga gewoon even verder met het stukje code dat simpel is maar ik niet werkend krijg.
Heel simpel aan het einde van de loop doe ik de onderstaande code.
Mijn Serial monitor maakt de actuele waarde zichtbaar, ondanks dat dit steeds de zelfde waarde is.
Ik zou zoals ik het mij voorgesteld heb voortdurend te tekst "Geen Screen Update Actie ADC" in de monitor moeten geven.
En alleen als ik de potmeter draai die in ingangsspanning van de ADC verander moet hij de ADC waarde in het beeld geven.

Maak ik hier dus de fout dat de variabelen zich niet binnen de vergelijking vinden?

c code:


/ ADC measure input and place value on display
  float ADC_Buffer;                                // Make "char" variable ADC_Buffer for formatting ADC value
  float ADC_Old;                                   // Make "char" variable ADC_Old[10] for comparing old and new ADC value
 
  ADC_Buffer = ads.readADC_SingleEnded_V(0);       // Load RAW ADC value in ADC_Buffer variable
    if (ADC_Buffer != ADC_Old)                     // Doe een "niet gelijk aan" vergelijking en plaatst dan de nieuwe waarde in de serial monitor
    {
     Serial.println(ADC_Buffer, 4);                // Maakt waarde van de ADC_Buffer zichtbaar in de Serial monitor als de nieuwe en de oude waarde niet gelijk zijn 
     ADC_Old = ADC_Buffer;                         // Maakt ADC_Old gelijk aan ADC_Buffer 
    }
    else
    {
    Serial.println("Geen Screen Update Actie ADC"); // maakt deze tekst in de serial monitor zichtbaar als de oude en nieuwe waarde gelijk zijn
    }

delay(200);

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
blackdog

Golden Member

Hi Roland,

Dat er hier iets niet klopt dat is duidelijk! :-)
Ik doe mijn best uit te zoeken/begrijpen wat de rede is van de waarde die ik voorbij zie komen.
Het vreemde is dat het niet continu is, ik onderzoek even verder en probeer eerst de eenvoudig vergelijking te laten werken.

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
blackdog

Golden Member

Hi,

Ik heb de variabelen aangepast zoals deKees dat heeft gedaan in zijn laatste voorbeeld code en wat denken jullie... dat werkt!

c code:


// ADC measure input and place value on display
double ADC_Buffer;                                 // de Kees aanpassing = Make "double" variable ADC_Buffer for formatting ADC value
static double ADC_Old;                             // de Kees aanpassing = Make "static double" variable ADC_Old[10] for comparing old and new ADC value
 
  ADC_Buffer = ads.readADC_SingleEnded_V(0);       // Load RAW ADC value in ADC_Buffer variable
    if (ADC_Buffer != ADC_Old)                     // Doe een "niet gelijk aan" vergelijking en plaatst dan de nieuwe waarde in de serial monitor
    {
     Serial.println(ADC_Buffer, 4);                // Maakt waarde van de ADC_Buffer zichtbaar in de Serial monitor als de nieuwe en de oude waarde niet gelijk zijn 
     ADC_Old = ADC_Buffer;                         // Maakt ADC_Old gelijk aan ADC_Buffer 
    }
    else
    {
    Serial.println("Geen Screen Update Actie ADC"); // maakt deze tekst in de serial monitor zichtbaar als de oude en nieuwe waarde gelijk zijn
    }

delay(200);

Deze code werkt nu zoals ik het wil, zie de screenshot hieronder.

http://www.bramcam.nl/NA/LowCostCal/LowCostCal-86.png

Als ik met mijn tengels van de testsetup afblijf, krijg ik alleen maar Geen Screen Update Actie ADC in beeld.
De variatie in de waarden hieronder, is al ik aan de tienslagen potmeter draai.
Ik ga dit nu zo in de eigenlijke code plakken om te zien og dit daar da nook werkt.

Groet,
Blackdog

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.

Klopt. ADC_Old wordt telkens opnieuw aangemaakt en de waarde gaat dan verloren. Dus die moet je static maken om dat te voorkomen:

code:


static float ADC_Old;    

PS:
float en double zijn exact hetzelfde in avr-gcc. Eigenlijk moet double nauwkeuriger zijn, maar op een 8-bit processortje is dat niet erg zinvol.

[Bericht gewijzigd door deKees op maandag 1 januari 2018 18:26:12 (30%)

benleentje

Golden Member

Waarom niet gewoon
compare = ADCold - ADCnew
If compare = 0 :geen verandering

Of is dat weer te simpel?

Mensen zijn soms net als een gelijkrichter, ze willen graag hun gelijk hebben.

@benleentje
Kan ook. Maakt niet zoveel uit. Maar je wilt weten of de getallen verschillend zijn, en niet of het verschil gelijk is aan nul, ook al komt dat op hetzelfde neer.

Dus ik zou de voorkeur geven aan

code:


   if(Adc_Old != AdcNew)

en niet

code:


   if((Adc_Old - Adc_New) != 0)
blackdog

Golden Member

Hi,

Ik zal nog naar de code voorbeelden kijken die jullie gisteren hebben gegeven.
Ondertussen ben ik denk ik bijna klaar omdat ik het voor nu bijna goed genoeg vind.

Maar, door de scoop aan de testsetup te hangen kwam ik er achter dat er constand naar het scherm geschreven wordt...
Doe ik zo mijn best na te denken over de i2c bus, en het schrijven van alleen de veranderde waarde,
en dan zie ik gewoon niet dat ik bij iedere looprun de tekst schrijf van de Output: ON! of OFF!

Toch wel handig zo'n 4 kanaals scoop zodat je diverse signalen tegelijk kan zien :-)

Hier is 1,2 seconde data te zien, kanaal-1 welke geel is betreft het SDA aansluiting
Het tweede kanaal welke licht blauw is, betreft het SCL signaal.
Kaneel 3 en 4 zijn twee datalijnen van het SPI display.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-88.png

Dan kunen jullie hier in de derde divisie een smalle negatieve data burst zien van het i2c signaal, dat is de temperatuur meting.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-87.png

Dit is ingezoomd op deze databurst, het duurt ongeveer 300usec hierna, voor het display gaat rammelen.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-89.png

De volgende stap is nu deze code: Enable/Disable button ook uit te rusten met een extra vergelijking zodat niet onnodig naar het display geschreven wordt.

Misschien vanavond meer hierover.

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
blackdog

Golden Member

Hi,

Ik heb wat af gepruts vandaag en loop goed vast, net als de code *grin*

Dit is een hard leerproces voor mij tekstfoten niet zien dat er een leesteken mist enz, dyslectie horror...
En niet te vergeten een autodidact probleem, je hebt alleen kennis van wat je op een bepaald moment nodig had.
Dus beteffende de code ken ik allerlij uitzonderingen niet die je bij school of curses wel bij je naar binnen gestampt wordt.
2018 sucks! *Grin*

Ok zeer veel gesleuteld aan de code om toch nog ene keer het volgende te bereiken:
Er wordt een timer gestart voor de ADC conversie, deze staat in de code hieronder om 500mSec.
Als er meer dan 500mSec is gewacht wordt er een conversie gedaan om te kijken wat de actuele waarde is.
Deze waarde wordt vergeleken met de conversie waarde van de vorige test die dus minimaal 500mSec oud.

Als de nieuwe conversie gelijk is aan de vorige waarde wordt het stukje code dat de nieuwe data naar het scherm schrijft niet uitgevoerd.
De loop gaat verder met zijn werk, in mijn code is de loop aan zijn eind en er staan wat regels om de looptijd te updaten en een regel met =================
zodat het een en ander beter te zien is op de seriele monitor.

Deze code staat nog boven de void setup()

c code:


// Setup variable for ADC conversion
unsigned long loopTime_Conv;
unsigned long currentTime;

Ditis het stukje code die de vergelijkingen doet voor de ADC conversie

c code:


// ADC measure input and place value on display

static float adc0;
static float adc_old;

    currentTime = millis();
    if (currentTime >= (loopTime_Conv + 500)){          // Every 1/4 second ADC sample
    adc0 = (1000.0F*ads.readADC_SingleEnded_V(0));      // Load ADC value in ADC_Buffer variable
    }
    if (adc0 != adc_old) {                              // compare old and new ADC value and write data to screen if different
      
Serial.print("adc0: "); Serial.println(adc0);
Serial.println("----------");

    ucg.setFont(ucg_font_profont22_mr);                 // Set font type
    ucg.setColor(0, 0, 255, 0);                         // Set font color
    ucg.setColor(1, 0, 0, 0);                           // Set font background to black
    ucg.setPrintPos(13,69);                             // Set font position
    char ADC_Buffer[10];                                // Make "char" variable ADC_Buffer for formatting ADC value
    dtostrf(1.0F * ads.readADC_SingleEnded_V(0), 6, 4, ADC_Buffer);
    ucg.print(ADC_Buffer);                              // Place measured output voltage on display
    loopTime_Conv = currentTime;                        // Update loopTimer
    adc_old = adc0;                                     // Update adc_old
    }

Serial.print("================");                       // Scheidings lijntje


    unsigned long end = millis();                       // Stukje code om de looptijd te meten
    unsigned long delta = end - start_loop;
Serial.println(delta);


}

Ik heb nu nog wat vreemd gedrag dat echt in deze code zit, de andere code staat bijna allemaal uit en alleen de korte burst van 1x per 10 seconde op de i2c bus is dan te zien van de temp sensor meting.
Er is dan ook geen data zichtbaar op de aansluitingen van het display.

Hier is goed te zien dat er 4 seconde geen verandering was, maar dat de i2c bus constant bezet was.
Dat zou niet moeten daar er iedere 500mSec een meten kan worden gedaan. (als ik het goed gecodeerd zou hebben)
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-90.png

Met de code zoals hierboven afgebeeld lijkt het er op dat het goed werkt en ik krijg veel regels achterelkaar met ==============2, ==============1, en soms ==============126
en dan komt er een adc0 waarde al dan niet gelijk aan de vorige waarde.
Dit lijkt allemaal goed, maar wat er nu ook gebeurd is dit, de i2c bus is nu constand aan het werk, behalve als er iets naar het display geschreven wordt!

Oja, ik weet dat ik 2x een ADC conversie doe, de eerste oproep van de ADC waarde kost niet zoveel tijd en dit is voor mij makkelijker te begrijpen, zie het begin van deze post waarom.
Levert dit toch problemen op, dan hoor ik dit natuurlijk graag! :-)

Zou het probleem te maken kunnen hebben met de geneste "if" opdracht in dit stukje code?

Gaarne hoor ik jullie opmerkingen.

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.

Bij mij werkt jouw code in de if prima:

c code:

currentTime = millis();
  if (currentTime >= (loopTime_Conv + 250)){          // Every 1/4 second ADC sample

Waarbij ik de unsigned long loopTime_Conv; & unsigned long currentTime; boven setup() heb staan, dus global zijn. Staan ze bij jouw in een functie ?

It's the rule that you live by and die for It's the one thing you can't deny Even though you don't know what the price is. It is justified.
blackdog

Golden Member

Hi Roland,

Dat stukje code voor de 500msec die ik gebruk en de 250 van jou werkt bij mij ook goed, en daar zit vrijwel zeker niet het probleem...
Het gaat daarna mis denk ik, bij de tweede if statement.

Ik had boven de code in de vorige post van de vergelijking al laten zien dat deze waarde globaal zijn.

c code:


// Setup variable for ADC conversion
unsigned long loopTime_Conv;
unsigned long currentTime;

Het lijkt er op dat het oproepen van data uit de ADC continu gebeurd...

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.

code:


   loopTime_Conv = currentTime;    

De update van loopTime_Conv doe je nu alleen als de ADC waarde verschillend zijn. Maar dat moet je doen bij elke meting dus binnen de eerste if()

En ook de test op 500ms is niet helemaal goed.

code:


   if (currentTime >= (loopTime_Conv + 500)) // Every 1/4 second ADC sample

Dat werkt wel bijna altijd, maar niet na een overrun in de time counter (na 49 dagen). Zo werkt het wel altijd:

code:


   if ((currentTime - loopTime_Conv) > 500) // Every 1/4 second ADC sample

En door telkens een vast getal op te tellen bij loopTime_conv heb je geen last meer van de extra tijd die je verspeelt bij het berekenen van de nieuwe waarde.

Zo krijg je intervallen van 500 milliseconden:

code:


   loopTime_Conv += 500;                        // Update 

Zo krijg je intervallen van 500 milliseconden plus de tijd die je nodig hebt om alles te verwerken doordat millis() in de tussentijd weer een paar ticks verder is. Al zal dat hier weinig verschil maken.

code:


   loopTime_Conv = millis();                        // Update 

En je hebt de nieuwe adc waarde al binnen in adc0, dus die hoef je bij dtostrf() niet opnieuw uit de adc te gaan halen:

code:


      dtostrf(adc0, 6, 4, ADC_Buffer);

En testen van adc waarden hoef je alleen te doen als je een nieuwe ADC waarde hebt gelezen.

De code wordt dan zoiets:

code:


   currentTime = millis();
   if ((currentTime - loopTime_Conv) > 500)
   {          // Every 1/4 second ADC sample
      loopTime_Conv += 500;                        // Update loopTimer

      adc0 = (1000.0F*ads.readADC_SingleEnded_V(0));      // Load ADC value in ADC_Buffer variable

      if (adc0 != adc_old) 
      {   // compare old and new ADC value and write data to screen if different
 
Serial.print("adc0: "); Serial.println(adc0);
Serial.println("----------");
          adc_old = adc0;                                     // Update adc_old
 
          ucg.setFont(ucg_font_profont22_mr);                 // Set font type
          ucg.setColor(0, 0, 255, 0);                         // Set font color
          ucg.setColor(1, 0, 0, 0);                           // Set font background to black
          ucg.setPrintPos(13,69);                             // Set font position
          char ADC_Buffer[10];                                // Make "char" variable ADC_Buffer for formatting ADC value
          dtostrf(adc0, 6, 4, ADC_Buffer);
          ucg.print(ADC_Buffer);                              // Place measured output voltage on display
       }
   }

blackdog

Golden Member

Hi,

deKees, even snel de code er ingeplakt en je wist het waarschijnlijk al, het werkt :-) :-) :-)

Als ik morgen nog wat tijd heb, pas ik de rest van de code ook aan op de manier zoals je wvoorstelde.
DANK!

Je begrijpt natuurlijk wel dat ik een beetje jaloers ben op je programmeer kunde en het rustige uitleggen!
Ben je leraar geweest of nog steeds?

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.

Ha nee, ben geen leraar of zo.

Maar voor mij is dit wel dagelijkse kost, met 40+ jaar ervaring. Mijn eerste "computer" was een MEK6800DII, in 1976 met 256 bytes geheugen.

blackdog

Golden Member

Hi,

Weer een beetje tijd gehad, en deze keer even een zijsprongetje, maar wel voor het zelfde project.
Om de ruimte in te delen op het front van het kastje moest ik gaan bepalen welke schakelaar ik zou gaan gebruiken.
Ook de knopgrote voor de 10 slagen potmeters houden hier verband mee, dit zijn nu spantang knoppen geworden van Rittal en ze zijn 21mm in het rond.

Dat ook dit weer niet een makkelijke keus was wordt wel duidelijk, als ik uitleg waar ik ondermeer rekening mee heb gehouden.
En dat is de temperatuur stabiliteit van de draadgewonden potmeters...
Door wat aanpassingen is dit voor kortere tijd stabieler te krijgen, dit ga ik proberen op te lossen door de potmeters in een dik aluminium U profiel te plaatsen,
dit U profiliel heeft een wanddikte van 4mm.
De potmeters komen als het goed gaat, hier strak in te zitten en ook leg ik een dun laagje koper on de potmeters heen.
Dit alles zal de thermische massa van de potmeters verhogen en door deze maatregelen zal de temperatuurdrift van de potmeters lager worden binnen een bepaald tijdsbestek.

Als alle mechanische materialen binnen zijn, zal het wat duidelijker worden hoe ik mijn optimalisatie denk toe te gaan passen.
Nop geen oventjes, alleen meer massa aanbrengen zodat de drift over een langer termijn uitgesmeerd wordt en je er hierdoor minder last van zal hebben.

Maar vandaag heb ik metingen gedaan aan zeven verschillende puls schakelaars.
Dit heb ik als volg opgelost, één van mijn TEK DDM's heb ik op de diode stand gezet (De HP en de Keysight meters zijn weg voor kalibratie :-) )
Deze diode teststand genereerd een spanning van iets meer dan 10V en een stroom van rond de 1mA.
Dat is prachting voor de metingen die ik wou doen aan deze schakelaars.
Ik heb deze keer de Rigol DS1104 scoop genomen dit i.v.m. de 24MB buffermemory, als ik 1 kanaal in gebruikt heb.
Voor deze scoop heb ik deze week ook 4 Testec probes binnen gekregen, de TT-MF 312-2-7.
Zoals bekend zijn de bijgeleverde probes van Rigol niet veel soeps en nu voor rond de 100 Euro vier probes die goed zijn en bruikbaar tot tot 250MHz.

Mooi, iedere schakelaar staat met zijn NO contacten gewoon over de rode en zwarte meetpen van de DMM geschakeld, samen met de scoop probe op de 1:10 stand, het kan niet simpeler...
Iedere schakelaar test ik een paar keer en daarna gaat de tijdbasis op de 10mSec stand en de scoop in de Single Shot mode, dit levert dan de onderstaande plaatjes op.
In de foto's van de puls weergave zie je de desbetreffende geteste schakelaar staan.

Dit zijn de schakelaars die ik vandaag getest heb.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-100.png

De bagger schakelaar *grin* veel verkocht maar een horror model, dit is als eerste bij een tijdbasis van 20mSec, lijkt toch goed...
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-110.png

We kijken nu bij een tijdbasis van 500uSec en er is na de neergaande flank aardig wat "gras" aanwezig.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-111.png

Dit is voor de opgaande flank, dit is problematisch als je er niets aan doet.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-112.png

Dit is geen tumbler maar een echte pulsdrukker, hij veert terug, goed gebouwd maar met raar gedrag.
Bij 10mSec tijdbasis is er al een dender signaal zichtbaar.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-115.png

De tijdbasis is nu 500uSec Holy Moly... was is dat!
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-116.png

Dit kan zo het stedelijk museum in als moderne kunst *grin*
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-117.png

Een fragiele maar zeer goede pulsdrukker (in ieder geval in de nieuw staat, zoals deze)
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-120.png

Het ringen dat zichtbaar is, komt door de bekabeling en de probe capaciteit en niet door de schakelaar.
Maar twee plaatjes van deze schakelaar, waarom? er valt niets anders te zien dan perfect gedrag.
Dit zowel voor de neergaande als de opgaande flank.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-121.png

Dit is een mini pulsdrukker, geen idee of het een APM is (goed merk) of iets anders.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-125.png

Bij 200uSec tijdbasis is wat gras zichtbaar aan de bovenzijde van het signaal.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-126.png

Het rammelt een beetje bij de opgaande flank.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-127.png

De volgende schakelaar in de 10mSec stand, hier is niets bijzonders te zien.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-130.png

Als we echter naar een tijdbasis stand gaan van 50uSec, kan je er aardig hout mee zagen...
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-131.png

Ik heb nog een plaatje geschoten bij deze tijdbasis stand, het wordt er niet vrolijker op.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-132.png

Dit is een China schakelaar, overal volop te koop en waarschijn door vele fabrikanten gemaakt.
Hier een aantal plaatjes van de door mij geteste schakelaar.
Hou krijg ik het voor elkaar, de schakelaar precies 80mSec in te drukken :-)
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-135.png

Dit is erg ver ingezoomd 20nSec/Div, het slingeren is weer het gevolg van de testsetup.
Wat ik wou laten zien dat aan de bovenzijde hij even rammelde voor hij definitief naar beneden ging.
Er waren ook bij deze low cost schakelaar erg weinig abberaties zichtbaar.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-136.png

Dit is de schakelaar die ik ga gebruiken voor dit project, ik heb mijn best gedaan de puls zo kort mogelijk te laten duren om rariteiten (abberaties) op te wekken.
De schakelaar is 12mSec ingedrukt geweest, ziet er zo goed uit.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-140.png

De neergaande flank is ook erg netjes.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-141.png

De opgaande flank is minder strak, maar dit is bij de 10uSec/div stand.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-142.png

Nu de schakelaar nog een keer bedient, met een nog kortere mechanische puls (was lastig om te doen)
Dit leverde een prachtige dender op.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-143.png

Bij 10uSec tijdbasis is het nog wat beter te zien.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-144.png

Deze metigen zijn gedaan om een indruk te krijgen hoeveel dender er aanwezig is, bij de schakelaars die ik tot mijn beschikking heb.
De derde en de vierde van links zijn in nieuwe conditie vrijwel perfect, vooral de gene met het grijze toetsje, ik heb er na vele testen geen dender uit gekregen.

In dit meetinstrument ga ik dus de meest rechtse schakelaar gebruiken, deze is niet dender vrij, maar dit is niet zo van belang, hij is goed genoeg met wat ontdendering,
Met een simpel RC netwerkje is de dender al vrijwel geheel weg te werken.
De rest doe ik dan in de software en de tijd voor de dender onderdrukking kan in de software dan ook flink veel korter gekozen worden.
Ik ben van mening dat bij kleine series (en nog andere afwegingen hier niet van toepassing) je beter voor een zo goed mogelijke oplossing kan kiezen,
die paar extra onderdelen zijn de kosten niet.
De beste oplossing in mijn ogen is dan "analoog" het meeste "gras" weg te halen en het laaste stukje met de software te doen, hierdoor kan je een zo snel mogelijk reageerend systeem krijgen.

Dit weekeinde aan de uitbreiding van de ADC conversie doen in de code, er zijn namelijk drie bereiken en die moet ik samen met drie ingangen en spanningsdelers nog goed uitrekenen.
En nog wat andere afwegingen die ik moet doen...
De lastigste was het 20mV bereik, dat kan ik met de ADS1115 niet goed schalen, ondanks dat de PGA in die chip (PGA = Programmable Gain Amplifier) een groot bereik heeft.
Een opamp er voor die ongeveer 100x versterk is niet makkelijk door technische beperkingen die er zijn, b.v. maar een enkel voeding.
Een mooie zero drift opamp met een RR in en RR uitgang is de LTC2057, dit is nog een van de beste betreffende de uitgangs commonmode,
maar geeft bij kleine uitgangsspaningen toch nog zo'n 1mV als fout marge zonder belasting.

Dus ik heb maar besloten niet direct aan de 20mV uitgang te meten maar aan de spanningsdeler er voor, daar staat i.p.v. 0 tot 20mV, 0 tot 2V, en dan hoef ik verder geen lastige trucs uit te halen.
De meter voor de uitgangsspanning in dit meetinstrument is een leuke toevoeging, maar dit meetinstrument is bedoeld om te gebruiken samen met een goede multimeter.

Laters meer!

Groet,
Blackdog

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
benleentje

Golden Member

Gelijk aan de 2V meten lijkt me hier ook het schoonste resultaat. Als je de spanning 20mV eerst hebt gedeeld door 100 en daarna met 100x vermenigvuldigd dan is dat toch weer hetzelfde als je gelijk de 2.000V meet? En door de extra versterker trap introduceer je altijd wel iets van verslechtering.

Even alvast tussen door. Ik heb even gekeken naar je gebruikte opamp en daar heb je blijkbaar nog verschillende versie's in. Van niet al te duur tot erg duur. Wat zijn door de onderlinge verschillen dan weer in?

Mensen zijn soms net als een gelijkrichter, ze willen graag hun gelijk hebben.
miedema

Golden Member

Op 5 januari 2018 16:58:42 schreef blackdog:
....(De HP en de Keysight meters zijn weg voor kalibratie :-) )....

:-) :-) Dus toch maar gedaan... Ben beniewd! :-) :-)

Je scope plaatjes zouden verplichte kost moeten zijn voor iedereen die ontdenderen overbodig vindt!
(Het zou ook een interessante test zijn of je na je standaard ontdendering nog verschillen tussen de schakelaars kunt meten...)

groet, Gertjan.

blackdog

Golden Member

Hi benleentje,

Het commonmode probleem zou ik nog kunnen omzijlen door de extra opamp bij de ander LTC2057 op de print te zetten.
Daar heb ik dan de -2,1V aanwezig en dat lost die problemen allemaal weer op.
Dan blijft het nog zo dat je toch er goed moet opletten met bedrading en opbouw door de zeer kleine signalen.
Voor de zelfde range van de ADC moet ik rond de 100x versterken endat is het laatste digit 1uV,
uit ervaring weet ik dat dit toch wel erg moeilijk zinnig weer te geven is.

Dus, dat plan is afgeschoten door ook de rede die ik in mijn vorige post gaf.
Het nadeel van het meten aan de bovenzijde van R12, dus het maximale +2V is dat je niet ziet als de belasting varieerd.
De Ri is daar dus iets kleiner dan 10Ω en als je die in verhouding zwaar belast dan zie je dat niet op de ingebouwde meter.

Nog een puntje, ook de stroom indicatie gaat daar niet werken, omdat je in het 20mV bereik kan kortsluiten wat je wilt,
maar je komt niet boven de 2mA maximale stroom uit door de 1K serie weerstand R12.

Dit kan ik in het onderste segment weergeven op het display waar nu nog "To Sine or not to Sine" staat.
Voor het 20mV bereik kan er dan zoiets neerzetten als "No Max Current detection"

Wat betreft de gebruikte opamp de LTC2057 die is er dus ook in de HV versie, deze kan tot 60V voedingspanning aan,
maar is in deze schakeling niet nodig, daar het totaal rond de 30 a 32 V zal liggen dat de opamp aangeboven zal krijgen tussen de voedings pinnen.
Op het ogenblik sleutel ik aan het schema rond de LT5400 weerstadns netwerk om een foutje er uit te halen en de enable schakeling beter te maken.

Ik heb het nu zo opgelost dat het 10V referentie ICeigenlijk altijd de zelfde belasting ziet, de enable contacten zitten nu aan de ingang van de opamp.
het is zo opgelost dat bij het omschakelen van de contacten er altijd een RC tijd aanwezig is en de schakeling mooi in en uit schakeld.
Verder blijft het opgenomen vermogen door de potmeters gelijk, of de schakeling nu enabled is of niet, de potmeters staan altijd onderspanning.
Dit komt de stabiliteit tijdens het gebruik ten goede, er is dan minder opwarm en afkoel drift in de potmeters.

Over de uitgangs sectie heb ik ook nog wat meer nagedacht, er komen waarschijnlijk twee BC337-40 transistoren in of een soort BD139-16 of beter.
Dit om het vermogen tijdens mishandeling beter te verdelen, daar de transistor tot 300mW meot gaan dissiperen en hij is maar 600mW bij < 25C.
Ook is nu in het schema te zien dat de relais aan de uitgang, transistoren en de stroombron niet meer bij de referentie sectie op het printje komen.
In dit stukje wordt het meeste vermogen opgewekt (ook al is dit weinig) en door de referentie, het weerstandsnetwerk en de opamp in een apart doosje te zetten,
maak ik het geheel weer wat stabieler voor korte termijn.
Ook de 78L15 zal niet bij de referentie komen, maar op het voedings printje, dat scheeld weer ruim 30mW die niet bij de referenite in de buurt zit.

De opamp zal volgens de specs minder dan 1mA verbruiken, het vermogen dat dit IC opneemt zal rond de 30mW zijn, ook deze opamp krijgt van mij een DIL8 koelertje op zijn dak :-)
De relais verbruiken bijna niets, daar ze bistabiel zijn en de puls om ze om te schakelen rond de 5 a 10mSec zal duren.

Gertjan
Jep, vandaag zijn ze opgehaald kan tot twee weken duren voor ze terug zijn.

Ik zal een paar schakelaars meten zoals ze meestal aan een Arduino hangen met een pullup weerstand.
Daar had ik al wat van laten zien hier op CO, maar was even kwijt welk topic, ik post te veel *grin*

Groet,
Blackdog

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
benleentje

Golden Member

Ik had laats ook even snel gemeten rond een arduino pin met mijn schakelaar. Ik zag toen zelfs een negatieve spanning van 2V, maar mogelijk heb ik toen een meetfout gemaakt.

Mensen zijn soms net als een gelijkrichter, ze willen graag hun gelijk hebben.
blackdog

Golden Member

Hi,

Op verzoek van Gertjan en ter lering en vermaak nog wat plaatjes betreffende debounch van schakelaars.

Voor het beste effect ben ik begonnen met iets wat ik eigenlijk niet echt een schakelaar kan noemen en dat is de gene met het oranje knopje.
Een tiental van deze schakelaars gaan zo de vuilnisbak in.
Je kan naturlijk zowel analoge filtering gebruiken en in verhouding lange software debounche time, maar het blijft een erg slechte schakelaar!
Wil je jezelf ongelukkig maken, koop dan vooral deze troep omdat het zo lekker goedkoop is :-)

De setup is nu iets anders, er wordt een LAB voeding gebruikt ingesteld op 5V.
De schakelaarstroom stel ik meestal in op rond de 1mA als dit voor de schakeling niet uit maakt (stroomverbruik)
Dit houd de contacten een beetje "schoon".
Hierna komt een simpel "low pass" filter dat is bedoeld voor het aansturen van CMOS ingangen zoals moderne microcontrolers.
Ben je met "Old School" digitale electronica bezig, pas dan de componenten waarden aan die passen bij de gebruikte logica.
De gele trace is direct over de schakelaar en de blauwe trace is over de condensator.
Voor de gene die opmerken dat de blauwe trace niet precies 5V aangeeft, dat klopt.
Dit heeft twee oorzaken, de eerste is dat de scoop nog niet helemaal warm was toen ik de 0 van beide tracen instelde.
En in serie met de blauwe probe ingangs weerstand van 10M, staat ook R1 en R2 en daardoor heb je een extra spanningsval.

Hier is zichtbaar dat met gebruikt van een kantelpunt van rond de 350Hz (R2 van 47K en 10nF) het meeste HF gras is verdwenen.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-145.png

De neergaande flank, de blauwe trace is mooi schoon.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-146.png

Dit is de opgaande flank, het filter doet goed zijn werk.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-147.png

Nu met een grotere condensator en een nieuwe meting, het kantelpuntis nu rond de 35Hz.
Prachtige denderpuls in het midden van het plaatje.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-155.png

Ingezoomd, het filter onderdrukt netjes de puls.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-156.png

Het leek één puls, maar het zijn er meerdere...
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-157.png

Deze schakelaar deed in de vorige metingen ook een beetje vreemd, bij deze tijdbasis instelling ziet het er zo goed uit.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-160.png

Het rammelt net als bij de vorige metingen flink direct op de schakelaar, maar met 10nF goed gefilterd.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-161.png

Hier is te zien dat bij deze schakelaar meer marge nodig is om de dender goed te dempen, 47nF of zelfs 100nF maakt het filter voor deze schakelaar bomproef.
Dit als je dan niet in de knoei komt met je reactie snelheid, zelf bepalen wat je uiteindelijk nodig hebt in jouw toepassing.
http://www.bramcam.nl/NA/LowCostCal/LowCostCal-162.png

Wat bij software ontdendering vaak wordt aangehouden, tussen de 50 en 200mSec is begrijpelijk als je zelfs de zeer slechte schakelaars zou willen ontdenderen.
Dit gaat nogal ten koste van de respons tijd van je schakeling, denk maar aan de vele apparaten om je heen waarbij je vaak lang/onzeker moet drukken op een schakelaar voor deze reageert zoals je dit graag zou willen hebben.
Denk maar aan de vele rotary encoders die zo traag reageren als een slak op een teerton.

Het gaat er niet om dat analoge filtering beter is dan software filtering, maar dat je een goed reagerende schakeling krijgt.
Dit begint bij een schakelaar (rotary encoder in low cost uitvoering, is ook een schakelaar) die van goed kwalitijd is.
Niet alleen bij 100x keer gebruikt te hebben maar ook bij veelvouden hiervan.
De schakelaars die ik hier liet zien zijn van verschillende merken en zelfs een schakelaar van C&K valt redelijk door de mand i.v.m zijn denderend gedrag.
De pulsdrukker met het grijze knopje is mijn beste pulsdrukker, ik heb nu een merk kunnen achterhalen en hij is van ALPS.
Deze schakelaar is in zijn nieuw stand zo goed dat hij geen debounce nodig zou hebben, maar ik zou altijd wat debounce toepassen dit i.v.m. slijtage.
Ik heb wat rondgezocht bij ALPS om gegevens van deze schakelaar te vinden, deze heb ik niet kunen vinden.
Wel gelijksoortige schakelaars in de 12x122mm uitvoering, de levensduur afhankelijk van het type is van 100.000 tot ruim 1 miljoen keer, lijkt bij een betrouwbaar modelletje :-)

Moraal
Kijk niet alleen naar het model, maar test de schakelaar die je wilt gebruiken, liefst een paar stuks, met mijn simpele testsetup en een digitale scoop.
Met het voorwerk dat je dan gedaan hebt krijg je meestal een sneller reagerende schakeling die ook nog eens betrouwbaar werk en blijft werken, als je het analoge filter en je software debounce goed insteld.

Geloof je het allemaal wel omdat je die en die schakelaar wilt gebruiken omdat het kwijl uit je bek loopt zo mooi vind je hem, of je wilt b.v. geen geld uitgeven... we blijven Nederlanders :-)
Dan zit je dus vaak opgescheept met een traag reagerende schakeling, en dat mag van mij, het is jullie feestje :-)

Dan nog dit, schuifschakelaars kunnen een heel ander dendergedrag hebben, nogmaals! ga meten aan de schakelaar die je wilt gaan gebruiken en pas aan waar nodig!

Mooi, verder met andere zaken, ik hoop dat jullie dit informatief vonden!

Groet,
Blackdog

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.

Mooie metingen en mooi gepresenteerd zo met die plaatjes erin hoef je niks te scrollen.
Zelf doe ik meestal alleen softwarematig ontdenderen met een timer op de voor- of achterflank in een interruptroutine hoe vaker hij dendert des te langer wordt de ontdendertijd.

blackdog

Golden Member

Hi rwk, :-)

Dat is een intelligente manier van software debouncing...

Algemeen
Wat ik voor stel met extra analoge filtering heeft meerdere voordelen, dat heb je al kunnen zien aan de plaatjes.
Dit wordt extra belanrijk als de schakelaars de buitenwereld gaan zien, dit i.v.m. het oppikken van het EM veld door de bedrading.
Dit kan trouwens ook gebeuren binnen één instrument.

Zoals altijd, doe onderzoek en pas toe wat nodig is :-)

Ik had ook nog wat testen gedaan met een diode over de 47K weerstand, dit om de opgaande flank te versnellen.
Je het dan eigenlijk twee kantelpunten, één met een lange tijd dat is in mijn testschakeling de neergaande flank.
Die tijd wordt bepaald door de 47K en de condensator.
Bij het loslaten wordt de laadtijd van de condensator grotendeels bepaald door de weerstand R1 van 4K7 en de condensator.
Hou er echter rekening mee dat die diode grote EM signalen kan gelijkrichten waardoor je weer ongewenste effecten kan krijgen.
Pas ook dit weer toe als het voor jouw schakeling zinning is.

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
miedema

Golden Member

Ha Blackdog,

Wat leuk dat je het effect van je hardware-debounce meteen maar gemeten hebt! Was nog een flinke klus, om de resultaten zo netjes te laten zien.
Maar zeer de moeite waard! Goed om te zien hoeveel verbetering een simpel RC filtertje geeft... Eigenlijk is zelfs het oranje rampenschakelaartje met 10nF al goed bruikbaar. En die 3ms vertraging van het filter zou toch geen probleem moeten zijn.

Natuurlijk ben ik het helemaal met je eens dat het vééél beter is om met een fatsoenlijke schakelaar te beginnen :-).

je EMI opmerkingen snijden ook hout. Een onderschat probleem, dat door het filtertje heel elegant meteen ook geminimaliseerd is.

groet! Gertjan.

blackdog

Golden Member

Morge Gertjan, :-)

Het is zelfs nog erger gesteld met sommige schakelaars...
De gene met het oranje knopje werkt soms wel en dan weer niet als je er op drukt.
Ook het zwarte RAFI drukknopje(niet laten zien in dit topic) is bij mij berucht,
deze bestaat uit open contacten waar een wigje tussen zit die de twee contacten dan verbind als je op de schakelaar drukt.

Beide schakelaar zijn bijna niet te debouncen doordat als je drukactie zeg 1 seconde beslaat, hij binnen die 1 seconde voortdurend bounced.
Zoals ik al eerder aangaf is het in mijn ogen onzinnig iets proberen werkbaar te maken als het gewoon rot is :-)

Bij mij is standaard bij hoog Ohmige ingangen dus de 1mA door de contacten en dan 47K a 100K richting de ingang en dan meestal 47nF of 100nF als condensator.
De diode over de 47K of 100K heb ik zelf eigenlijk nooit toegepast.
Het mooiste is als de digitale ingang een Schmitt Trigger functie heeft, dan wordt het echt bomvast.

Ook bij het zeer mooie schakel materiaal van EAO waar ik veel ervaring mee heb opgedaan ging het af en toe mis.
Dit was dan meestal een geval van slijtage door zeg vaak meer dan 100x per dag de schakelaar in te drukken.
Dit b.v. bij de 01-121 series, dat kon je dan voorkomen door een nog degelijker model te kiezen, maar dat moest dan wel in het paneel passen :-)

Zo simpel, een schakelaar... zo ongelovelijk veel storingen heb ik daar aan opgelost in de 25 jaar dat ik voor een bedrijf werkte.
Zo vervelend als je voor het eerste muziekstuk tijdens een aula dienst, de muziek niet wil starten of vrijwel direct weer stopte door het bouncen.
Daarom heb ik redelijk wat ervaring en zal ik misschien in andermans ogen, iets te veel aandacht hieraan besteden.

Ik denk dat Gertjan er over kan meespreken hoe belangrijk het is dat iets ook echt gaat werken als je een knop indrukt zoals jij dat wilt
en dit bijna niet afhankelijk hoe lang of kort je drukt.

Voorbeeld
Als ik in de Ridderzaal stond tijdens Prinsjesdag, dan moest de microfoon van de aankondiger en de Koninging aan staan, als ik op die knop drukte!
(de NOS had voor de radio en de TV hun eigen systemen)
Twee dagen van te voren deed ik een uitgebreide test op de hele installatie, verstekers, luidsprekers enz, en ook de schakelaars die ik moest bedienen.
Natuurlijk kreeg ik de opmerkingen als de NOS weer eens aan het knoeien was, ik deed toch het geluid!
Het is echt een stress situatie zoals in de Ridderzaal dat je zeg 4 microfoons moet bedienen en dan ook nog moet anticiperen wanneer er iemand gaat spreken.
(ik heb aardig wat ervaring opgedaan in het lezen van lichaamstaal tijdens dit soort klusssen, heb ik nog steeds plezier van!)
En dan gaan er natuurlijk allerlij personen voor je neus staan als jij het overzicht nodig hebt hiervoor.
Ben ik te laat met indrukken, krijg ik een baal gezeik over mij heen, ben ik te vroeg, tja wat denken jullie :-)

Zoals ik al eerder zij, het is aan jullie hoe belangrijk je de schakelaar functie vind, ik hou er van dat hij doet wat ik wil op dat moment.

Gegroet,
Blackdog

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.