Sample analog input naar array(15 samples) en selecteer laagste waarde

Hi Heren, Dames ook :-)

Op het ogenblik wat meer tijd voor software ontwikkeling maar ik loop een beetje vast...

Voor mijn CO-2016 Util Display welke ik wil afmaken loop ik een beetje vast hoe het een een ander aan te pakken.

Waar gaat het om, ik wil aan de hand van de bufferelco spanning en de uitgangs spanning van de voeding het relais dat de trafotap bediend, omschakelen.
Waarom geen vaste spanning zoals in de orginele opset van deze voeding, omdat ik het leuk vind om het op een andere manier te doen en ik van dit soort zaken leer.
Ten tweede had ik al vorig jaar aangegeven, dat dit het rendament van de voeding verbeterd.

Het maakt als deze schakeling werkt, niet uit wat de belasting is en ook niet hoeveel de 230V spanning uiteindelijk echt is, er word namelijk alleen gekeken naar de dropout spanning.
Dit is de spanning op de buffer elco en daar vanaf getrokken de uitgangs spanning van de voeding.

Ik denk aan een dropout waarde van ongeveer 2V, dit is afhankelijk van de bufferelco capaciteit en nog wat andere dynamische zaken.
Het dynamisch testen van de voeding gaat de uiteindelijke dropout spanning bepalen die in de code wordt gezet.

Wat heb ik zelf al draaiend, dat is het uitlezen van de twee analoge ingangen en dan dit samen met de omrekening van de twee weerstanden van de spanningsdeler.
De twee ingangen geven de goede DC waarde aan als ik deze test en wordt ook goed op het Nokia display aangegeven en een LEDje veranderd van status als de dropout spanning wordt bereikt.

Ik heb gisterenavond wat testjes gedaan om de analoge ingangen wat stabieler te maken met deze library: AnalogSmooth.h
Deze werkt verder goed maar weet niet of dit nu efficient is om te gebruiken in de uiteindelijke code.

Nu het echte probleem...
De DC spanning op de bufferelco is niet stabiel, deze heeft een rimpel spanning en het gaat natuurlijk om de minimale spanning waarop gereageert moet worden.

Ik dacht aan het volgende om dit op te lossen...
Er wordt een array aangemaakt met zeg 12 waarden.
Door middel van timing wordt er iedere 1mSec (1 periode dubbelfasig gelijkgericht is 10mSec) een sample in de array gepompt.
Omdat ik 12 sampels neem, heb je niet snel de kans dat de sample steeds op het zelfde punt uitkomt.

Als de 12 samples dan in de array zitten, wil ik dan met de: QuickStats.h library de minimale waarde uit de array halen en dan deze gebruiken voor de "drop out" vergelijking.

De analoge ingangen maken gebruik van de spanningsdeler voor de "schaling maar ook om een 1e orde lowpass filter te maken zodat HF storingen geen roet in het eten kunen gooien.(rond de 200Hz.

Verder moet er ook nog een timer komen die voorkomt dat het relais gaat klapperen, dus als de software heeft gededecteerd dat er naar de hoogste trafo tab moet worden omgeschakeld, dan moet dit zo blijven voor de komende 2 tot 5 seconde.
Deze tijd zal bepaald worden door het dynamisch gedrag van de voeding en na deze tijd mag de dropout code weer zijn werk gaan doen.

Misschien is 1 analoge sample te storings gevoelig voor de twee analoge ingangen die ik hiervoor gebruik, en er zijn b.v. 4 of meer nodig(middeling) voor dat deze waarde in de array gedumpt moet worden.

Zover ik weet is de sampletijd van de Arduino Nano die ik gebruik 100uSec en dat zal volgens mij niet echt een belemmering opleveren.

Ik zie uit naar jullie input! ;-)
Shoot!

Groet,
Bram

12 monsters nemen en de laagste uitzoeken, OK.

Ik denk aan iets anders. Menig controller heeft een comparator aan boord. Maak met een DA converter een door de controller te regelen gelijkspanning. Biedt die op een poot van de comparator aan. De andere poot krijgt de elcospanning (een veilig deel ervan ) De output van de comparator staat dan te pulseren als de DA spanning hoger is dan het dal van de brom. De controller regelt automatisch (een keer per 5 s volstaat) de gelijkspanning bij om het gevonden dal te updaten.

Aanvulling: dat kan bijvoorbeeld door de outputpulsen van de comparator een interrupt te laten genereren, en in de interruptafhandelingsroutine wordt dan de DAC waarde wat verlaagd. Dat houdt dan vanzelf op als de pulsen net verdwenen zijn en gaat dus volautomatisch.

[Bericht gewijzigd door Dr Blan op (21%)]

Als het goed is beschik je over een min(x,y) functie. Als je deze gebruikt heb je maar 1 variabele nodig en hoef je geen array te vullen, sorteren, uitlezen, opruimen.
Ik veronderstel dat je eoa loop hebt waarin je 12x sampled. Elk sample kan je met de min() functie tegen de variabele houden: 

x = min(x, sample);

Aan het einde houd je de laagst gemeten sample waarde over in x.

Hi,

Dr Blan en LetterHenk,
Dank voor de input, het heeft me aan het denken gezet en ik kan het niet zo uitvoeren zoals ik het in mijn hoofd had...

En dan doel ik op het volgende, het timen en het selecteren van de laagste waarde gaat wel lukken,
maar er moet nog meer code worden uitgevoerd in de loop en deze code bevat 3 a 4 DS18B20 temperatuur sensoren.

Deze 4 sensoren staan dan wel ingesteld op de laagste resolutie van 9 bits, maar dat kost dan nog bijna 0,1seconde om hem uit te lezen.
Tijdens dit uitlees proces is er dus geen detectie van de dropout spanning...

De temperatuur hoeft natuurlijk niet iedere loop te worden gemeten, het gaat om de trafo en de transistor temperaturen, 1x per 2 seonde is dan genoeg.
Ik wil echter niet rekening houden met de tegelijktijdigheid van het inzakken van de bufferelco spanning en het uilezen van de temperatuur sensoren.

Ik denk er nu aan, om de droppout spanningsregeling buiten de processor om te doen met wat transistoren.
Dat maakt het voeden van mijn Arduino en het meten aan de U en I potmeters ook een stuk makkelijker.
Ook is het dan makkelijker het geleverde vermogen op het Util display weer te geven.

Een andere optie is analoge sensoren te gebruiken, dan gaat het uitlezen sneller, daar was ik trouwens mee begonnen toen ik dit projectje starte :-)

Beide gedachten van jullie sla ik op, misschien handig voor latere code.

Nu eerst de getimde code testen en de dropout schakeling verder af ontwikkelen.
Deze zal bestaan uit en transistor die over de powertransitoren staat en als de spanning over de Powertransistor buiten de ingestelde waarde komt en via een Schmittrigger voor de Hysteresis het trafo relais stuurd.

Laters meer hierover
Groet,
Bram

Dat is natuurlijk grote onzin, die 0.1s is het gevolg van brakke software engineering.

Ja, de conversie duurt bijna 0.1s, maar dat betekend niet dat je processor uit zijn virtuele neus moet vreten terwijl hij daarop wacht! Dat is het equivalent van een online bestelling versturen en echt helemaal niets meer doen totdat je dat pakketje in huis hebt.

Je kunt gewoon de conversie starten en andere nuttige dingen gaan doen terwijl die loopt. Dit kun je bereiken met timer interrupts, of je kunt simpelweg de conversie starten, in een loop je overige taken blijven uitvoeren, en aan het eind van die loop checken of de conversietijd al verstreken is. Als alternatief kun je aan het eind van die loop steeds aan je temperatuur sensor vragen of hij al klaar is met de conversie.

Dit soort problemen komt voort uit het gebruiken van brakke libraries, waar de Arduino wereld vol mee zit. Net zoals jij anderen op het gebied van analoge elektronica de do's en don't haarfijn kunt uitleggen, zul je de correcte werkwijze op "ons" vakgebied moeten leren, als je daar ooit iets zinnigs wilt presteren. Een controller ophangen terwijl je zit te wachten op een externe event is niet bepaald de correcte werkwijze.

Hi SparkyGSX,

Ik ben al sinds het op de markt komen van de XT computer op de hoogte van IRQs.
Ook wat je omschrijft hoe het zou moeten worden uitgevoerd in efficiënte code, is mij bekend.

Het gaat hier om een eenmalig project voor één van mijn voedingen, hiermee hoop ik wat meer te leren programmeren met Arduino, Teensy enz.
Mijn doel is niet een professionele embedded programmeur te worden,
daar heb ik de tijd niet voor en mijn dyslexie zit mij wat dat betreft, ook te veel in de weg.

Maar ik ben nu al zover dat ik mijn meetapparaatjes kan opleuken wat bediening en extra functies betreft.
Natuurlijk loop ik tegen problemen aan die professionals ook hebben en daarom stel ik hier af en toe vragen over op dit forum en hoop dan op wat hulp.
Een aantal van mijn problemen zal niet goed kunnen worden opgelost bij het gebruik maken van Arduino's en soorgelijke microcontrolers, het zij zo...

Resumé
Dus ik vraag hier wat hulp voor de spullen die ik hier beschikbaar heb en dat ik dit project eind juni af kan hebben.
Ik ga dus geen C of zijn familie leren en ook geen assembler, ik blijf het gewoon met de in jouw ogen brakke Arduino IDE doen.
En pas als het moet, gewoon twee of meer Arduino's toe als dit een snelle en goed werkzame oplossing blijkt, ze kosten namewlijk geen drol ;-)

Groet,
Bram

Je hebt toch geen array nodig daarvoor? Gewoon kijken of het nieuwe sample lager is. Pseudocode:


If Sample < OldSample Then OldSample = Sample

Inderdaad, je kunt bij het binnen komen van elk sample kijken of het kleiner is dan het kleinste sample tot dusver.

@blackdog: als je dat allemaal weet, waarom doe je het dan niet? In plaats daarvan beweer je dat het allemaal onmogelijk is en val je terug op je gebruikelijke hamer: analoge elektronica. Iets met oude honden en nieuwe trucjes?

Hi,

SparkyGSX, het communiceert een stuk vriendelijker als je niet in de vechtmode gaat staan... :-)
.
Dat ik weet wat IRQ's zijn betekend nog niet dat ik een programmeur ben van proffessie.
Dat ik weet dat als een electron van een hogere naar een lagere band gaat en dat er dan een foton wordt uitgestoten en b.v. dat in de quantum mechanica een deeltje tegelijkertijd zowel linksom als rechtsom spint, betekend niet dat ik Richard Feynman ben.

Mijn vragen betreffende dit topic komen voort uit mijn onwetendheid betreffende het programmeren van de functies die ik graag zou heben.
Verder vraag ik niet naar zaken waarvan ik al kennis heb, wat is het rendament hiervan?
Ik ben een beginner wat programmeren betreft, maar wel één met 50 jaar electronica ervaring.
Dus mag je aannemen dat ik wel iets weet van digitale electronica.

Arco, LetterHenk en Dr. Blan hebben mij allen oplossingen aan de hand gedaan die ik kan gaan proberen.
Als ik wat programmeren betreft vast ga lopen en daardoor te veel tijd verlies, dat heb je dus grote kans dat ik dit weer "analoog" ga oplossen en daar is helemaal niets mis mee in mijn ogen.
Meestal is digitaal is niet beter of slechter dan analoog, zoals bij bijna alle dingen hangt dit van de toepassing en omstandigheden af.

Het leuke is, dat ik door dit topic ideeen heb opgedaan voor een ander project :-)

Maar weer terug on topic, vanochtend dacht ik er aan een micro Arduino te gaan gebruiken voor het dedecteren van de dropout.
En als het dan niet te lastig voor mij, wordt deze optisch (i.v.m. commonmode signalen) te koppelen aan de Arduino Nano die het display en andere zaken regelt.

Dus nog steeds volop in de ontwikkel modes... :-)

Groet,
Bram

Ha Bram,

Vanochtend kwam bij mij onmiddellijk de gedachte van analog-computing op. Ik durfde er echter niet over te beginnen, omdat het zo ontzettend jaren 60 is. Nu kom je er zelf zo'n beetje mee op de proppen. Doet m'n ego goed! :-)
Hoe is natuurlijk een volkomen andere zaak. Beschouw het maar als een mogelijke hint, meer niet.

P.S.: Houd je ook een beetje vacantie ?

Groet,

T.A.

Ik vertel je hoe een embedded systems engineer (zoals ondergetekende) dat naar mijn idee zou oplossen, wat je afdoet als iets wat je al wist toen deze snotneus nog op de basisschool zat, om vervolgens, in nota bene hetzelfde bericht, dat af te doen als "dat is toch allemaal veel te ingewikkeld en dat snap ik toch allemaal niet". Dit is niet de eerste keer dat je zo om "hulp" vraagt.

Roepen dat je het allemaal al weet en dat het rendement van iets vertellen wat je al beweert te weten laag is, terwijl je met de meest banale dingen nog moeite hebt, is ook niet bijzonder productief.

Op deze manier ga je het nooit leren, maar ik krijg ook steeds minder de indruk dat je de intentie hebt om ooit nog iets te leren over embedded software.

Ik ben er klaar mee; ik steek mijn tijd voortaan wel in het helpen van degenen die wel daadwerkelijk nog iets willen leren.

Hi Ton,

Is verder alles goed met je?

Groet,
Bram.

Jawel hoor, verder alles prima, maar op één of andere manier weet jij toch altijd de draak in mij even naar boven te halen.

Het is ook onzin dat alleen professionals interrupts kunnen gebruiken; dat kunnen de meeste amateurs die voorbij de basis van de Arduino zijn gekomen ook. Het is ook niet dat het je ontbreekt aan intelligentie om het te kunnen leren, je bent gewoon te koppig.

[Bericht gewijzigd door SparkyGSX op (52%)]

Interrupts heb je al gauw nodig. Anders blijf je steken bij vrij basale (en niet erg effectieve) programma's...

Als ik zo ff snel door die datasheet scan lijkt het mij toe dat je die DS18B20's gewoon kunt pollen. Op het gevaar af een open deur in te trappen: je zegt het ding iets te doen en vraagt vervolgens periodiek of-ie er mee klaar is, waarna je het resultaat opvraagt.

De opdracht verstrekken kost 82 bits, het opvragen 91.
Met een bittijd van 100µs ben je dus maximaal 9.1ms per sensor per keer bezig, met de minimale bittijd van 60µs nog geen 5.5ms...
Ik heb geen kennis van de Arduino of de IDE, dus die timing kan nog behoorlijk afwijken. Meten is weten.

Door de temperatuurmetingen af te wisselen met de spanningsmetingen kun je alles nog een beetje onder controle houden, bijvoorbeeld:

  1. start temp meting 1
  2. sample spanning
  3. start temp meting 2
  4. sample spanning
  5. start temp meting 3
  6. sample spanning
  7. start temp meting 4
  8. sample spanning
  9. vraag resultaat 1
  10. sample spanning
  11. vraag resultaat 2
  12. sample spanning
  13. vraag resultaat 3
  14. sample spanning
  15. vraag resultaat 4
  16. sample spanning

Zolang je geen resultaat hebt ga je terug naar 9, als alle resultaten binnen zijn ga je terug naar 1.
Berekeningen kunnen naar believen worden tussengevoegd, die kosten nou niet bepaald veel tijd...
Als de timing van de spanningsmetingen echt kritisch is, kun je die beter laten uitvoeren door een aparte Arduino.

Maarrr... als een A/D conversie zo snel is, waarom dan geen analoge temperatuur sensors gebruiken? Dat maakt het programma een stuk overzichtelijker.
Enneuh... Analoge signalen laten zich óók multiplexen (voor het geval je A/D inputs te kort komt). De eventueel daardoor geïntroduceerde fouten zullen voor de temperatuurmeting van een koelplaat niet significant zijn, zonodig kunnen ze zelfs worden weggecalibreerd.

Als je *iets* met controllers wilt, dan ontkom je al heel snel niet aan interrupts. Blijkbaar zie je er nogal tegen op. Ik snap niet waarom - tenzijn dat Arduino-taaltje het erg moeilijk maakt. En dat geloof ik niet.

Dingen in een array mikken is leuk voor post-processing. Maar voor jouw doel niet nodig. Neem 12 samples en bewaar elke keer alleen de laagste. Uiteraard je variable vooraf op de hoogste waarde die die kan bevatten initialiseren.

*Ik* zou een timer interrupt hebben die flags zet. Daarnaast een ADC interrupt die dat ook doet. Je main loop rent rond als een malle en kijkt alleen maar naar de flags om te zien of-ie wat moet doen.
Dat 'rennen als een malle' beperk je vervolgens indien gewenst met een 'sleep' met een 'wake on interrupt'. En uiteraard is alles wat je doet non-blocking. Dus als je een sensor wilt uitlezen, dan roep je 'doe maar conversion' en dan kom je later wel eens ophalen wat de waarde was.
Vergeet niet die flags 'volatile' te maken. Dat heeft niks met interrupts te maken, wel met de optimizer die in de default settings van de gemiddelde C compiler zichzelf het bos in optimized als hje het niet doet.

Ik begrijp dat dat voor een hardware boer wellicht wat bedreigend is, maar interrupts niet willen gebruiken komt een beetje over als met een in de eerste versnelling naar de supermarkt rijden, omdat je nooit hebt leren schakelen, het kunstje 'eerste versnelling' kent en zo kom je er ook.

Ik kan meegaan met BD, als je geen doorwinterde programmeur bent dan liever 2 controllers gebruiken van een paar euro dan uren, dagen of weken zitten debuggen.
Hij zal geen uitzondering zijn, ook commerciële producten doen dat al zoals je kunt zien op deze print, een Atmel en PIC naast elkaar. sorry, dat is geen 12Fxxx pic maar een pwm chip.
Waarmee ik niet wil zeggen dat ze daar geen interrupts hebben gebruikt.
De prijs van de chips is laag genoeg om dit te verantwoorden.

Als je een hardware man bent dan is software een noodzakelijk kwaad en dat moet zo rap mogelijk van de baan.

NB. en ik ben ook geen fan van de hardware aanpak van BD moest dat zo overkomen, veel te veel puntjes op de i, gelukkig maakt hij mooie foto's :p

Ik kan meegaan met BD, als je geen doorwinterde programmeur bent dan liever 2 controllers gebruiken van een paar euro dan uren, dagen of weken zitten debuggen.

Gebruik van interrupts heeft niks met 'doorgewinterd' te maken - je hoeft ook geen 'doorgewinterd' chauffeur te zijn om de 2de versnelling te vinden :)
Als ik zo zie wat BD allemaal maakt en dan ook nog aan begrip erachter heeft zitten, dan zijn er genoeg werkende grijze cellen beschikbaar om - zeker in een hogere programmeertaal dan assembly - interrupts te kunnen begrijpen.
Ik weet alleen niet hoe dat Arduino gedoe ermee omgaat. 'Libraries' zijn daar heilig ofzo en als een bestaande lib het niet kan (omdat de gebruiker het niet nodig had), dan wordt het wat complexer. Dat zit dan niet in de interrupts, maar meer in een lib die nou net niet doet wat je wilt...

Maar he... 2 chippies en dan dat nog asynchroon met elkaar laten babbelen... Dat maakt het eh... niet echt eenvoudiger :)

Overigens zou voor mij de uitdaging nou weer liggen in dit hardwarematig goed werkend krijgen - voorkomen dat de boel gaat staan klapperen en toch op het juiste punt schakelen en dat in combinatie met die rimpel. :)

Als je een hardware man bent dan is software een noodzakelijk kwaad

Alles wat je in software douwt, dat KUN je ook in hardware maken. Zou er een reden zijn waarom het in software gedaan wordt?

Op 15 mei 2017 09:29:16 schreef EricP:
[...]Gebruik van interrupts heeft niks met 'doorgewinterd' te maken - je hoeft ook geen 'doorgewinterd' chauffeur te zijn om de 2de versnelling te vinden :)

Je maakt het u wel erg makkelijk hé om uw gelijk te willen aantonen ;)
Ik zou eerder de vergelijking maken tussen een autorijder en autorijder met een slipcursus ervaring.

Het is een kwestie hoeveel interesse je hebt en hoeveel tijd en geld je erin wilt steken.

Edit:

Op 15 mei 2017 09:29:16 schreef EricP:
Alles wat je in software douwt, dat KUN je ook in hardware maken. Zou er een reden zijn waarom het in software gedaan wordt?

Daarin heb je gelijk, verleden week een pic gebruikt om een LM555 schakeling te maken, dat bespaart u enkele randcomponenten.

[Bericht gewijzigd door MGP op (26%)]

State machine gebruiken:

https://forums.adafruit.com/viewtopic.php?f=25&t=74701

Je maakt het u wel erg makkelijk hé om uw gelijk te willen aantonen ;)
Ik zou eerder de vergelijking maken tussen een autorijder en autorijder met een slipcursus ervaring.

Neu. Interrupts zijn basis. Net zo basis als de 2de versnelling.

Als je nou gaat kijken naar bitbanged timing goed krijgen (er vanuit gaande dat die essentieel is) in iets wat interrupt driven is dan komt die slipcursus om de hoek kijken - daar moet je toch wel ff over nadenken en verdomd goed weten hoe zowel die controller als de compiler in elkaar zitten...

Het is een kwestie hoeveel interesse je hebt en hoeveel tijd en geld je erin wilt steken.

Voor die auto gaat het op. Daar kost rijden geld. De aanschaf... maakt niet uit. Die andere versnellingen zitten er echt in! :+ . Voor een Arduino... ach, wat kost het aan geld? Beetje stroom? Tijd zal de beperkende factor zijn. En zoals met alles wat je leert: als je het snap, dan vraag je je af waar je nou zo moeilijk over gedaan hebt. En hoeveel makkelijker het leven daarna wordt (tot je tegen het volgende leertraject aan loopt, dat duurt vast niet lang! :) ).

Meerdere gekoppelde MCU's gebruiken is bijna altijd een slecht idee. (behalve als je echt processing power tekort komt)
Het maakt de boel nodeloos gecompliceerd (met grotere kans op fouten) door de bijkomende communicatie tussen de processoren, en firmware updates worden complexer.

Ik heb er ook wel een paar keer aan gedacht om het zo te doen in sommige situaties, maar de nadelen wonnen het steeds van de voordelen... ;)

Jij bent dan ook een doorwinterde programmeur maar de situatie van BD is heel anders.

Als hobbyist heb ik daar geen problemen mee om 2 of 3 pic's te gebruiken, ik vind dat soms veel eenvoudiger maar ik ben dan ook geen professioneel.
Met de tijd zal hij ook beter worden en nood hebben aan betere en complexere programma's, maar dat wordt ervaring genoemd, denk aan jullie begintijd.

Als hobbyist heb ik daar geen problemen mee om 2 of 3 pic's te gebruiken, ik vind dat soms veel eenvoudiger maar ik ben dan ook geen professioneel.

Ik heb zoveel moeite met het gebruiken van 1 pic-ding dat ik er maar helemaal mee gestopt ben :)

Ik zie nog steeds niet hoe meerdere controllers iets 'eenvoudiger' zouden kunnen maken. Ik zie alleen een hoop zinloos toegevoegde complexiteit - terwijl het tot op heden altijd een goed idee lijkt te zijn om dingen juist simpel te houden - en zoveel mogelijke complexiteit te vermijden!

[edit]OK, als ze niks met elkaar te maken hebben en dus niet met elkaar hoeven te kletsen, dan heb je een punt. Als je 5 onafhankelijke 555-jes moet hebben, dan zou dat zomaar kunnen. Waarbij 5 losse controllers nog het voordeel zouden hebben dat de boel ook wat uit sync raakt, net zoals 'echte' 555s dat zouden doen - wat ook weer een nadeel zou kunnen zijn...

[Bericht gewijzigd door EricP op (25%)]

Als het meerdere stand-alone MCU's zijn, kan het simpeler zijn in sommige gevallen.
Zogauw ze intensief samen moeten werking wordt het al gauw een drama qua communicatie en timing onderling.