Webbsidan är senast uppdaterad:
Nordic Clima FanControl
Speciella behov utifrån Nordiskt klimat & solenergi
Termohygrostat - klimatstyrning av fläktvarvtal
Kommer uppdatera lite oregelbundet här efterhand som projektet framskrider.
Projekt: Konstruktion av klimatstyrning för varvtalsreglering av 12V PM-ventilationsfläkt.
En mikroprocessorstyrd termohygrostat klimatregulator, främst för att hålla nere temperaturen varma sommardagar i en husvagn som en fusk-AC genom termostatstyrd varvtalsreglering.
Är ett hobbyprojekt utan tidplan, med oregelbunda framsteg.
Köpte de första delarna redan 2014, men så kom flytt och en del annat ivägen och projektet hamnade på undantag samt körde fast lite på att jag inte var nöjd med det Arduino Motor Shield jag köpt samt att det krockade med utgångar till dåvarande LCD-displayen. Så när jag 2020 bestämde mig för att bygga en egen buck converter motordrive började jag aktivera projektet lite igen, och nu är det aktivt på riktigt igen! Fick även en experimentell medicinsk behandlig för min bråkande kropp hösten 2021, vilket gett mig lite mer energi, ork och uthållighet.
Bakgrund funktion:
Det Nordiska klimatet med långa kyliga vintrar då hög luftfuktighet råder gör att mycket fukt buffras upp i allt organiskt material (tyg, trä, etc) inomhus vid kallställda off-grid fritidshus / husvagn. Vid uppvärmning frigörs då mycket fukt som behöver ventileras ut, mest första dygnet och märkbart under tre dygn. För att göra detta så energisnålt som möjligt bör en ventilationsfläkt styras utifrån fukt-temp-givare för inkommande luft samt för rumsluft, så man hela tiden bara ventilerar precis så mycket som behövs för detta. Med fukt-temp-givare kan man räkna ut luftens absoluta fuktinnehåll och daggpunkt för bra styrning av fläktvarvtal, oavsett utetemperatur. Så kan då styra på en kombination av hur mycket högre absoluta fuktighen är inne än ute, daggpunkten inne vs utetemp samt på relativa fuktigheten inomhus. Kanske typ daggpunkt < (Tin - Tout)/2? I husvagn suger fläkten in den svala luften under husvagnen.
På sommaren styrs enheten av temperatur och försöker hålla innetemperaturen på önskad inställd max-temperatur genom att fläkta in så sval luft det går utifrån typ underifrån genom hål i golvet i husvagnen, lite som en sorts fusk-AC. Varvtalstyrs så den fläktar bara precis så mycket som behövs för att hålla önskad temperatur. Kan även styra på relativ fuktighet, då det är aktuellt. Varvtalsstyrning ger strömsnål drift och jämn temperatur.
Via meny kan då även väljas ett lägre max fläktvarvtal för tystare drift när man vistas i husvagnen, samt välja att tillåt max fläkteffekt när man är ute från den för max förmåga att hålla önskad max-temperatur. Kommer även finnas val av ett lägre varvtal konstant på för ventilering.
Även skönt riktigt varma sommardagar, att på kvällen ventilerar då fläkten bara precis så mycket som behövs för att hålla önskad max temperatur (= tyst, strömsnålt) samt stänger av sig framåt natten när temperaturen når under inställd önskad max-temperatur, så man inte får onödigt svalt på natten. Sänker då varvtalet successivt tills den stänger av sig, så blir ingen abrupt förändring i fläktljud som kan störa sömnen.
Vid riktigt liten stuga eller liten husvagn ökar snabbt relativa fuktigheten inne vid matlagning (kokning) och då kan fläkten även få öka i varvtal för att hålla nere den fukthalten på lagom nivå, lite som en automatisk köksfläkt styrd av fukt-temp-givarna. I en husvagn har man oftast så stora ventilationsöppningar i takluckan så där spelar det ingen roll om man blåser in eller suger ut luften, men i stuga bör man vinterhalvåret helst suga ut luften för att inte få övertryck inne som kan tvinga ut fukt i ytterväggar, golv och tak.
Är samma om man torkar hängd tvätt inne eller kommer in med blöta ytterkläder.
Varvtalsstyrd fläktventilering som bara ventilerar precis så mycket som behövs spar energi för uppvärmningen, samt spar ström. En grundventilering behövs dock alltid för bra inomhusluft så inte CO2 nivån blir för hög eller föroreningar i luften, kanske som självdrag då.
Bygger den kring ett Arduino Uno R3 mikrokontrollerkort som kodas i C++ och får utgöra "intelligensen" som styr fläktvarvtalet och läser av givare.
Visar då driften på en liten LCD-skärm, där man även kan göra inställningar.
Så kommer ha ett litet menysystem där man kan välja tyst AC-funktion när man är inne med begränsat max fläktvarvtal, AC-drift där fullt varvtal tillåts när man är ute, ett ventileringläge, etc.
Nytt: 2021-11-29
Display:
Har hittat och utvärderat en bra liten LCD-display med 2x16 teckens visning, med bra tillgänglighet hos flera webbshoppar. Med god läsbarhet vid enbart omgivningsljus samt med bakgrundsbelysning vid behov. Vid lcdSetBlacklight(0) har den fortfarande en mikroskopisk belysning aktiverad, så den går att läsa i nattmörker utan att direkt uppfattas som bakgrundsbelyst.
Olimex Shield-LCD 16x2 med fyra tryckknappar som styrs via I2C-bussen. Har även 10st GPIO på kortet, också åtkomliga via I2C. Samt man kan styra ljusstyrkan via sin kod inom 0-255, där jag nu använder lcdSetBlacklight(85) för lagom bakgrundsbelysning dvs bara 1/3-del av ljusstyrkan.
Har även kodat en skärmsläckare, som släcker bakgrundsbelysningen efter X antal minuter utan knapptryckning.
Har provat både på Arduino Uno R3 och ESP32 Uno, med samma goda resultat. Dock tar I2C kommunikationen en hel del tid, typ drygt 640ms för att skriva alla de 2x16 tecknen vid I2C busshastighet 100kHz som är max den klarar.
Har gått ned till 80kHz, då displayen hängt sig ett par gånger under långvarig drift.
Funderar på att koda en DisplayHandler som bara skickar över de ändrade tecknen av de 2x16st, för att göra det snabbare.
Nytt: 2021-11-29
Komponenter:
- 1st Arduino Uno R3
- 1st Olimex Shield-LCD 16x2 display.
- 2st Temp/fuktsensor – RHT03 / (DHT22) (DHT22 har tydligen problem i minusgrader)
Mätbart område: 0 – 100% RH, Noggrannhet (RH): ±2%, Arbetstemperatur: -40 till +80°C, Noggrannhet (temp): ±0.5°C.
Powerdata: Matning: 3.3-5V, Ström mätning: <1.5mA, Ström standby: <50µA, Avläsningsintervall nya värden: 2s, Kodexekvering nya värden: <4ms, Kodexekvering idle: <1ms. DHT-biblioteket (GitHub) till RHT03 / DHT22 har funktion för "Heat index (HI)", hur temperaturen upplevs vs Rh, så kan styra innetemperatur mot det vid AC-drift! - 1st INA219 High Side DC Current Sensor för mätning av fläktmotorns effektförbrukning. Är mest för att testa / lära inför nästa projekt (Nordisk PWM-solladdregulator).
- Diverse elektronikkomponenter för att bygga själva motorstyrningens kraftelektronik i form av en energieffektiv Buck converter (egenkonstruerad). Finns även färdiga Arduino Motor Shield av lite olika sort för varierande max ström att köpa, men hittade inget jag kände mig nöjd med till min rätt kraftiga fläkt. Körde fast lite där tills jag bestämde mig att konstruera en egen.
Jag är självlärd inom elektronik, så blir som det blir men brukar ändå bli bra. - Motorumsfläkt typ radialfläkt. Radialfläktar påverkas minimalt av turbulent insugningsluft, är ofta tystare samt klarar lite bättre mottryck. Tre bra egenskaper vid min användning!
Data: 12V ca 3A, 2,5m3/min (150m3/hr). Min off-grid husvagn är på ca 11m3, så kommer kunna byta all luft var 5:e minut vid max varvtal. Bör bli en effektiv fusk-AC funktion!
Liknande fläkt: Motorrumsfläkt Roca, Watski . - 1st Adafruit Data Logger Shield för bygge av en temporär datalogger för att logga fukt-temp-beteendet när den buffrade fukten i all inredning torkas ur när den kallställda husvagnen värms upp. Som indata i utvecklingen av algoritmen att styra ventilationen då. Se nedan
- Arduino IDE, gratis programvara att koda Arduino med i datorspråket C++, som inte direkt är ett nybörjarspråk. Men jag är självlärd och gillar C++ :-)
Har nu bytt till lite mer proffsiga PlatformIO, VSCode.
SMPSChart.pdf
Power Topologies Handbook
Synchronous or Nonsynchronous Topology?, Boost System Performance with the Right DC-DC Converter
Controlling switch-node ringing in synchronous buck converters, Texas Instruments TI
Parasitic Oscillation and Ringing of Power MOSFETs, Toshiba
What are Buck Converters - Discontinuous Mode vs. Continuous Mode
The Difference between continuous conduction mode (CCM) and discontinuous conduction mode (DCM) Explained
Buck converter, Discontinuous mode
What is differences between CCM and DCM mode in buck boost converter? How can I choose the right mode?
Buck Converter – Circuit, Design, Operation and Examples, CCM and DCM
IEEE TOPOLOGY REVIEW OF DC/DC CONVERTERS, Texas Instruments, in deep
LMQ61460-Q1 Automotive 3-V to 36-V, 6 A, Low EMI Synchronous Step-Down Converter
AN-1197 Selecting Inductors for Buck Converters
Dual Synchronous Buck Converter
LM62460 6-A Buck Converter Optimized for Power Density and Low EMI
JLCPCB, PCB´s used in the video
Zero crossing detection using comparator circuit
Zero Crossing Detection Circuits Examples
1kW Arduino MPPT Solar Charge Controller (ESP32 + WiFi) Step 7: Solving the Burning Low-Side MOSFET Problem: Caused by the discontinuous conduction mode (DCM) of the Synchronous buck converter. (En väldigt bra inspirationskälla!)
"The second problem stated from the previous step is the infamous low-side burning MOSFET present in almost all DIY synchronous buck MPPT builds. This specific problem of open green energy and mine are exactly the same and was solve through code."
Detta försöker jag istället lösa med zero crossing detection över nedre N-MOSFET och via det styra den till att fungera som en ideal diod som ger samma funktion som dioden i en asynchronous buck converter. Se om det i stycket Synchronous buck converter längre ned.
Krävs nog då jag i framtida projekt vill kunna låta en MPPT buck-converter arbeta med både PWM (Pulse-Width Modulation) och PFM (Pulse-Frequency Modulation) mode för max verkningsgrad över stort effektområde. PFM blir discontinuous conduction mode (DCM).
Bör även finnas IC liknande IR2184 MOSFET driver med den funktionen inbyggd, så kommer då även söka efter det. Men här utforskar jag en egen lösning.
Efficiency in power conversion circuits
Online Calibration of MOSFET On-State Resistance for Precise Current Sensing
Hybrid linjär LDO regulator och DC-DC switchregulator, Adding an LDO for Increased Standby Mode Efficiency Reference Design. För låg strömförbrukning i strömsparläge.
What is the MOSFET body diode? A Schottky diode connected in parallel to the body diode will conduct with a lower forward voltage, preventing the body PN junction from becoming forward biased. The Schottky diode is a majority-carrier device and exhibits no recombination. Be sure to use short, wide traces to connect the Schottky and the MOSFET.
The MOSFET Switch and Diode
EF Series Power MOSFET With Fast Body Diode
Using MOSFETs As General Switches Slow reverse recovery of MOSFET body diode.
Power MOSFET Tutorial
Nytt: 2021-11-30
I2C kommunikationen Arduino Uno => Olimex Shield-LCD 16x2:
När jag skickar 2x15 tecken via I2C vid 100kHz bussklockfrekvens tar det 616ms exekveringstid! Känns långt och rätt extrem.
Gick in och analyserad biblioteket LCD16x2 till Olimex-displayen och hittade då en delay(20) för varje tecken som skickas, vilket ger 2x15x20ms=600ms dvs där är orsaken till det långsamma. Då är frågan varför finns den där? Övrigt tar då ca 0,5ms/tecken.
Ur LCD16x2.cpp:
len = strlen(string);
for(int i = 0; i < len; i++){
Wire.beginTransmission(ADDRESS);
Wire.write(LCD_WR);
Wire.write(y);
Wire.write(x);
Wire.write(string[i]);
Wire.endTransmission();
x++;
if(x > 15){
x = 0;
y++;
if(y > 2)
return;
}
delay(20);
}
Testade med delay(10) men då låser sig display / I2C, så går inte att snabba på så!
Får koda en DisplayHandler som bara skickar över de ändrade tecknen av de 2x16st, för att göra det snabbare. Lite synd den kommunikationen är så seg. I övrigt känns displayen bra.
Kan läsas med släckt bakgrundsbelysning i omgivande ljus, bra kontrast och tydlig, bra läsvinkel samt man kan justera bakgrundsbelysningens ljusstyrka 0-255 innifrån sin egen kod.
Nytt: 2021-12-13
DisplayHandler:
Har nu kodat färdigt en fin liten DisplayHandler i C++ som effektiviserar skrivningen till Olimex Shield-LCD 16x2 displayen. Gör i snitt skrivandet till displayen mycket snabbare.
Då varje skrivet tecken till displayen kräver en delay(20) i drivrutinen, så exekverar programkoden effektivare när bara de förändrade tecknen sedan sist skrivs till displayen.
Dvs bara det som behöver uppdateras skickas via I2C-bussen. Överst i bilden syns att skrivning av alla 2x16 tecken tar 659ms, medan i nedre bilden med DisplayHandler bara de siffror som förändrats skrivs och det då i snitt tar 43ms beroend på hur många siffror som förändrats.
Tiden 44ms där är totala exekveringstiden för hela programmets kod.
Mäter man temperaturen och mätvärdet är 22,4°C och nästa mätvärde blir 22,3°C så blir det bara siffran 3 som skrivs till displayen via I2C med min DisplayHandler. Det frigör även kapacitet på I2C-bussen för avläsning av givare.
Själva DisplayHandler bidrar försumbart till exekveringstiden har jag mätt upp.
Nytt: 2021-12-21
2st RHT03 testade med Arduino Uno R3:
Kopplat upp 2st RHT03 (DHT22) funkt-/temp-givare till mitt Arduino Uno R3 kort nu och det ser jäkla bra ut :-)
Rh skiljer bara 0,5% mellan de två sensorerna och temperaturen 0,1°C! Har två till RHT03 jag ska testa där lite senare.
Är till min termohygrostat jag håller på att utveckla för klimatstyrning av en ventilationsfläkts varvtal i off-grid husvagnen.
Kan även få fram heat index där, vilket är upplevd temperatur i förhållande till Rh, typ vid 30°C är det en jäkla skillnad vid Rh=90% och Rh=50%!
Ska nog styra på det vid AC-fläktdrift i sommarvärmen.
Daggpunkten ska jag troligen styra på då jag kommer till kall husvagn och mycket av den buffrade fukten i trä och tyg torkas ut vid uppvärmning och behöver ventileras ut för att undvika kondens i vinterväder. Jag räknar fram daggpunkten där ur Rh + Temp!
Givarna är fabrikskalibrerade, så tror jag kan lita på deras värden :-)
Värdena stämmer även bra med den termohygrometer av bättre kvalitet jag har på skrivbordet nära dessa vid denna test, som visar för inneluften här.
Kanske verifierar jag dem med en salkalibrering senare.
Funderar på att bygga detta först som en tillfällig mätdator för lite mätdatainsamling i husvagnen hur fukt- och temperatur-förloppet ser ut där nu denna årstiden när jag kommer dit och värmer upp husvagnen från kallställt.
Så får jag lite data för hur jag ska göra själva klimatregleringen för fukten där.
Typ funderar på att styra fläktvarvtalet så daggpunkten inne inte går över medel-temperaturen mellan ute- och inne-temp. Men om det ska vara precis mitt emellan de temperaturerna kunde jag då få bra data på!
Tog mig flera dygn att lösa så Arduino IDE kan kompilera funktionen sprintf() så den fungerar med float-tal, men är nu löst så jag kan formatera texten snyggt på 2x16 LCD-displayen här.
RHT03 datablad
Heat index temperature
Dew point from Rh & temperature
2021-12-22
Fukt-/temp-sensorerna reagerar snabbt även om de bara uppdaterar sina värden 1ggr/2s (som synes), så ska gå bra att styra fläktvarvtalet utifrån dem! Här höll jag mot den ena av de två intill varandra en svagt fuktad tumme utanpå en kort stund med snabb Rh-respons:
Har provat alla mina 4st RHT03 (DHT22) fukt-/temp-sensorerna nu, och de ligger alla väl inom ±0,5% för Rh och ±0,1°C för temp mellan sig, så är riktigt imponerande tycker jag! Blir bra ingångsdata för regleringen! Samt värdena stämmer med en termohygrometer av bra kvalitet jag hade stående precis intill på bordet.
Nytt: 2022-01-02
Data logger shield:
Fått kontakt med SD-kortet på Adafruit Data Logger Shield. Hade ett sådant liggande så bygger nu först en temporär datalogger så jag kan logga fukt-temp-beteendet när den buffrade fukten i all inredning torkas ur när den kallställda husvagnen värms upp. Så jag kan få bra data på hur relativa fuktigheten / daggpunkten inne ska styras med fläktvarvtalet. Skrev lite funderingar kring det i föregående stycke, om dess tänkta algoritm.
Även dess RTC (Real Time Clock) har jag fått att fungera, förutom att dess kommunikation över I2C-bussen stör ut LCD-displayens kommunikation över I2C! Så försöker hitta en lösning...
Mitt data-logger-shield är en äldre version som inte är helt kompatibelt med Arduino Uno R3, så har beställt den nya versionen så får jag se om det funkar direkt med den ihop med LCD-displayen, innan jag gör en djupare felsökning!
2022-01-03
Nu fungerar min Arduino datalogger med att logga temp/fukt-data till SD-kortet!
Kom på att jag behöver inte tidsstämpla med realtid utan räcker med löpande tid bara, så slapp jag konflikten mellan RTC och LCD-display. Skriva till SD-kortet gav ingen konflikt.
Är ett litet detektivarbete att hitta OK bibliotek. Det första SD-biblioteket jag provad tog för mycket SRAM så Arduino låste sig efter ett tag, samt det var långsamt.
Det Adafruit / SdFat bibliotek jag har nu funkar bra och snabbt! Se även Adafruit / SdFat GitHub samt original SdFat (SdFat GitHub).
Här drygt 3hr loggande nu ikväll var 6:e minut. Lade en fuktigt papperstuss intill ena temp/fukt-givaren efter en dryg 1/2-timme, som flyttades mellan dem efter drygt 2,5hr.
Loggat till en CSV-fil som jag sedan tagit in i LibreOffice Calc och gjort diagrammet.
Nästa test är att löda in ett par meter signalkabel till den ena temp/fukt-givaren och se om det funkar OK, sedan lite finputsning i koden så kan jag åka till husvagnen och logga.
Ska bli väldigt intressant att få den datan loggad över förloppet när den buffrade fukten torkas ut vid uppvärmning från kallställt!
Kan driva den från min powerbank i närmre 7 dygn och har tänkt logga 2-3 dygn :-)
2022-01-05
Har nu stoppat hela fukt/temp-dataloggern i frysen och kört en längre stund där för att testa så det fungerar i vinterkyla också. Hann kylas ned till -16°C.
Det fungerade om än med en sirapsseg LCD-display i den kylan, samt beräkningen av daggpunkt fungerade "bara" ned till runt -45°C graders värde sedan spårade den ur matematiskt och blev ej beräkningsbar med de formler jag använder. Men bör ju räcka i praktiken ändå för mitt ändamål. Så får lägga in i koden att det (NaN) detekteras och då sätter daggpunkten till -45°C - så bra utfall från testet. Data samplat 1ggr/60s.
Allt ser bra ut och de båda temp/fukt-mätarna av typ RHT03 följs bra åt, vilket indikerar att de fungerar OK i dessa temperaturer. Värdena ser rimliga ut också och hela Arduino Uno R3 paketet inkl SD-kortet fungerade i kylan, strömförsörjt via min powerbank.
Känns skoj!
Att Rh-värderna stiger successivt under tiden i frysen beror på att sensorn kyls ned under den tiden, och så länge sensorn är varmare än luften i frysen värms luften precis intill den upp vilket ger lägre Rh! Så vid snabba temperaturförändringar finns den fördröjningen helt naturligt.
Vid 0,4hr öppnade jag frysdörren och kollade till dataloggern, vid 0,53hr tog jag ut dataloggern förvarad i en frysask och satte på locket för att undvika kondens, samt vid 0,8hr öppnade jag locket och tog ut dataloggern. Därav de olika påverkan på de loggade värden.
Mellan ca 0,15hr - 0,58hr funkade inte beräkningen för daggpunkt.
Kurvorna DewP... är beräknad daggpunkt.
Kurvorna HeatInd... är beräknad heat-index temperatur.
Bara att löda in den lite längre signalkabeln jag har till den ena RHT03-givaren, så kan jag någon lämplig dag snart åka till husvagnen och logga hela uppvärmningsförloppet där ifrån kallställt. Fungerade bra även med 5m lång 4x0,2mm2 oskärmad signalkabel till ena RHT03!
Nytt: 2022-01-24
Dataloggning av uppvärmning kallställd husvagn:
Behövde mätvärden för daggpunkt och absolut fukt (partiellt ångtryck) i inneluften för att se hur och på vad jag ska reglera fläktvarvtalet avseende fukt under uppvärmningen av kallställd husvagn den kalla årstiden. Så loggade det under 97hr.
Uppvärmd husvagn under 0-47hr, därefter är uppvärmningen avstängd igen.
Mellan 92-97hr är det solvärme som värmer upp lite, samt förändrat väder från ca 87hr.
Vid ca 4hr och 28hr kokar jag mat samt vid ca 43hr kokar jag kaffe, vilka båda tillför fukt till inneluften i min lilla husvagn. Blev lite intressanta diagramkurvor:
Ur mätvärdena kan jag räkna fram vattenångans partialtryck inne och ute, dvs den absoluta fuktmängden. Och räknar ur det fram hur mycket mer fukt det är i inneluften via lite matematik i Arduino C++ koden, där för mitt värde RelPartPressInside(%) 0% då är samma fuktmängd, (-) är mindre fuktmängd inne som ger sorptionsavfuktning samt (+) är mer fukt i luften inne som ofta beror på att buffrad fukt i organiskt material torkas ut av värme.
DewPinside(°C) / DewPoutside(°C)) är framräknad daggpunkt.
För daggpunkten har jag använt formler från abcdef.wiki - Daggpunkt samt fört partiella ångtrycket från energy.lth.se - FUKTIG LUFT för att räkna ut dessa ur mätt temperatur och relativ fuktighet. För en mer kunskapsbaserad beskrivning av fuktbuffring och dessa uppmätta data, se FuktRisk i Husvagn - Uppvärmning kallställd husvagn.
Ser ut som relativt högre partiellt ångtryck inne (RelPartPressInside(%)) är rätt värde att styra fläkvarvtalets reglering från samt ≤+75% ser ut som en första ansats att börja med.
Värdet beräknat som: 100% * (PpartÅngaInne / PpartÅngaUte - 1).
I diagrammet är även Heat Index temperaturerna med, dvs upplevd temperatur med hänsyn till Rh (relativ fuktighet). När jag styr fläktvarvtalet med AC-funktion i sommarvärme har jag tänkt styra på heat-index-temperaturen, då dels det är den temperatruren man upplever, dels att det blir lite mer marginal mot gasolpannans termostatreglerade temperatur vintertid. Kurvorna här ovan visar att det verkar OK. Högt Rh ger en kallar känsla i kyla och en varmare känsla i hetta!
Nytt: 2022-02-02
Loggad data vs driftsfunktion:
Vintertid när jag kommer till min kallställda off-grid husvagn och slår på värmen och all buffrad fukt i inredning då torkas ur vill jag ventilera ut den. Ger så hög fukthalt i inneluften de första dygnen att det kondenserar på de svala punkterna i vagnen. Allra mest första dygnet, sedan sjunker det som man ser i det uppmätta diagrammet, så det fuktstyrda fläktvarvtalet kommer då sänkas automatisk med den uppvärmda tiden. Går ju från +200% till +75% högre fukthalt i inneluften under de första 48hr, och ser ut som omkring +75% är OK som jag upplevde det i husvagnen då efter de två dygns boendet där.
Så vill ha en fuktstyrd ventilationsfläkt då som bara fläktar in precis så mycket uteluft som behövs för att balansera uttorkning så fukthalten håller sig på en sund bra nivå under den uppvärmningsprocessen. För mycket ventilering drar iväg med gasolförbrukningen till uppvärmningen, så vill minimera det.
Sedan i sommarvärme tänker jag styra på innetemperatur och fläkta in den svala luften under husvagnsgolvet så jag försöker att inte få över max önskad temperatur inne, så jag får som en termostatreglering av värmen med hjälp av fläktvarvtalet. Lite som en fusk-AC.
Så blir som en termohygrostat.
Styra på temperaturen är ju rätt fram, men hur fukten beter sig under denna uppvärmningsfas hade jag ingen data på, men skaffade mig det såhär via dataloggning. Så kan jag bättre se hur jag ska styra fläktvarvtalet på den fuktdatan med hjälp av denna loggade datan.
Så ska ha den för att kunna skriva den programkod som ger en smart hygrostat-funktion i Arduino Uno's C++ kod som styr fläktvarvtalet.
Nytt: 2022-02-14
Uppgraderat LCD-display:
Bytt LCD-displayen till OLIMEX Shield-LCD16x2 med mycket bättre kontrast samt betraktelsevinkel, och man kan justera ljusstyrkan 0-255 inne i koden samt även läsa av den i dagsljus utan bakgrundsbelysning. Som en av de sista "gamla synderna" som behövde fixas sedan jag startade projektet första gången för några år sedan. Blev rätt mycket omkodande i programkoden för att få in hur detta shield samverkar med sitt bibliotek via L2C seriell kommunikation. Använder då även den DisplayHandler jag utvecklade till dataloggern ovan.
Nästa steg nu blir att koda ett bra menysystem där jag även kan editera vissa inställningsdata via. Lägger ned rätt mycket tid på menysystemet så det blir skalbart, minnessnålt och kan återanvändas i mina framtida projekt. UX design är ofta en stor del av kodandet i ett projekt!
Nytt: 2022-02-15
PlatformIO IDE i VSCode:
Har bytt från Arduino IDE till PlatformIO IDE i VSCode, som är en lite mer professionell, lättarbetad samt roligare editor att arbeta i. Går snabbare att koda samt är lättare att få bra kodkvalitet. Kan även göra statisk kodanalys för check av OK kod, via Cppcheck och Clang-Tidy.
IDE, Integrated Development Environment.
Nytt: 2022-02-16
Testar Arduino Uno R3 externa Interrupts:
Utvärderar hur snabbt externa interrupt arbetar i Arduino Uno R3 ihop med PWM-pulsutgång, för att se om det är tillräckligt snabbt för att kunna emulera en logisk AND-krets för styrning av zero-cross detection för min synkrona buck-converter styrning.
Krävs för att blockerar omvänd backström när induktansen LX blivit helt urladdad vid buck-converter Discontinuous mode och strömmen börjar vända ifall inte MOSFET Q2 då sätts OFF och blockerar backströmmen som en diod hade gjort där.
Den IR2184 MOSFET-driver jag använder har en ingång (SD) som sätter båda MOSFET Q1+Q2 i OFF, lämplig för detta. Genom zero-cross-detection med en operationsförstärkare / komparator detekteras när spänningen för MOSFET Q2 passerar från (-) till (+) relativt GND, där den då ska inta OFF för att fungera som en ideal diod, via triggning av en interrupt-ingång vars ISR aktiverar IR2184´s SD-ingång! Därefter hålls Q1=Q2=OFF tills PWM-utgången går ON igen, då denna CD-signalen till IR2184 måste plockas bort så att MOSFET Q1 kan inta ON.
Simulerar då om den logiken går att göra kodmässigt i Arduino Uno R3, genom att PWM Pin11 signalen (3921Hz) kopplas till Interrupt Pin2 som triggas på RISING (=zero-cross-detection). När Interrupt Pin2 triggas sätter dess ISR-funktion utgången Pin9 HÖG, vilken är kopplad till Interrupt Pin3 som triggas på RISING (=PWM-puls), vars ISR-funktion direkt sätter utgången Pin9 LÅG igen. På så sätt kan jag på oscilloskop mäta hur snabb denna Interrupt-hantering är!
Det tar 7,0µs (Delay / Latency) innan utgång Pin9=HÖG och ytterligare 9,3µs tills den är LÅG igen (blev 3,2µs resp 5,4µs med direkt portmanipulering)! Känns snabbt för en 16MHz 8-bitars processor och bör kunna fungera som tänkt då. Latencyn 7,0µs har ett jitter inom +1µs som eventuellt kan bero på att i Arduino Uno kan man inte styra att ISR-funktionen ska vara permanent i RAM, så kan vara tiden det tar att läsa från Flash-minnet.
Hos ESP32 finns ett IRAM_ATTR-attribut som styr att en funktion eller variabel ska vara i RAM hela tiden, just för snabba ISR-funktioner! Får lite senare göra samma test på en ESP32 också och jämföra.
Men Latencyn ligger koncentrerad kring 7,0µs sedan en mindre mängd jitter upp till ca 8,0µs.
En Latency på 7,0µs bör vara OK, då induktansen LX är strömtrög och inte hinner uppnå någon backström att tala om på så kort tid som 3,6% av hela pulstiden vid 3.9kHz PWM.
Med direkt portmanipulation i ISR-funktionerna sjönk Latencyn till 3,2µs, vilket känns riktigt bra! Det är då bara 1,2% av av hela pulstiden vid 3.9kHz PWM!
Nu finns det "bara" en störning kvar som lite glest oregelbundet ger en latency på upp till ca 65µs, vilket jag gissar på är DallasTemperature-biblioteket och dess onewire kommunikation. Jag utnyttjar att DS18B20 tempgivarna läses av i bakgrunden, vilket då bör ske via internt interrupt som skulle kunna ge denna störning för mina interrupt. Jag ska ändå byta till RHT03 fukt/temp-givare, vilka hade en mycket effektivare biblioteksfunktion när jag körde dem med dataloggern ovan. Blir intressant att se om det försvinner då! Eller om det är Arduino-ramverkets arbete i bakgrunden som kanske blockerar interrupt vissa stunder, men hoppas inte det?
Som referens verkar ESP32 @ 240MHz ha en motsvarande latency på 1,8µs.
Men bäst är nog att bygga funktionen hårdvarumässigt med en JK Flip Flop ur C-MOS 4000-serien ihop med zero-cross-detection via en OP-förstärkare, för snabb exakt funktion!
Kod för Interrupt-test:
const int pwm_pin = 11;
const int interruptPin2 = 2;
const int interruptPin3 = 3;
volatile const int interruptOutPin9 = 9;
void ISR_FromPWMpin11(){
// digitalWrite(interruptOutPin9, HIGH);
PORTB |= B00000010; // pin/port9, of 13-8
}
void ISR_FromPin9(){
// digitalWrite(interruptOutPin9, LOW);
PORTB &= B11111101; // pin/port9, of 13-8
}
void setup(void){
pinMode(interruptPin2, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(interruptPin2), ISR_FromPWMpin11, RISING);
pinMode(interruptPin3, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(interruptPin3), ISR_FromPin9, RISING);
pinMode(interruptOutPin9, OUTPUT);
digitalWrite(interruptOutPin9, LOW);
TCCR2B = (TCCR2B & B11111000) | B00000010; // PWM frequency of 3921.16 Hz
pinMode(pwm_pin, OUTPUT);
}
void loop(void){
analogWrite(pwm_pin, 191); // 75% Duty-cycle of 255
}
Nytt: 2022-02-17
Nu har jag bytt till RHT03 fukt/temp-givarna så Dallas DS18B20-givarna som kommunicerade via onewire-biblioteket är borta.
Då försvann de stora störningarna på mina interrupt och det kommer bara någon enstaka störning som nu väldigt glest ger en latency upp till ca 20µs, men för det mesta <10µs även det väldigt glest. Bör vara OK i min tillämpning, i vart fall så jag kan börja prova så.
I ISR-funktionerna har jag även bytt till direkt portmanipulering från digitalWrite() när jag växlar pin9 mellan HIGH/LOW, vilket minskade latency från 7,0µs till 3,2µs!
Nytt: 2022-03-07
Menysystemet i Arduino för termohygrostaten:
Har lagt ned rätt mycket energi och tid på att koda ett bra menysystem där jag även kan editera vissa inställningsdata via som sparas i EEPROM. Gav ett menysystemet som är skalbart, minnessnålt, effektivt med tydlig överskådlig lättläst C++ kod, så den kan återanvändas i mina framtida projekt då UX design ofta är en stor del av kodandet i ett projekt!
Alla menyerna ligger organiserade kopplade i en cirkel till varandra, där man kan vandra runt genom dem via knapparna Left / Right. I menyerna med editerbara värden aktiveras edit-mode via knappen Edit visat med E i displayens högra hörn, värdena bläddras upp / ned via knapparna Increase / Decrease och nya värdet sparas via knappen Save, eller editeringen avbryts via knappen Cancel. Vid Save sparas värdet via EEPROM.update() så det bara skrivs till EEPROM om det verkligen har ändrats, för att spara på de begränsade skrivcyklerna EEPROM tål.
Har kodat så att man upplever en momentan reaktion på displayen av en knapptryckning, sedan vid fortsatt nedtryckt knapp så tar koden den 1ggr/s som en ny knapptryckning. Så man kan bläddra runt bland menyerna via nedtryckt knapp, eller stega fram nya värden så automatiskt.
Har även kodat en skärmsläckare i två steg, så efter en viss tid sänks den normala bakgrundsbelysning till 1/3-del av den, som sedan är tänd 3ggr så länge innan den släcks helt. Vid helt släckt bakgrundsbelysning tänds den via någon knapptryckning, utan att den knapptryckningen ger någon annan aktion. Känner mig nöjd med hur jag fått ihop detta :-)
Nästa steg är att ta en INA219 i drift, en ström / spänning / effekt sensor.
Skulle hellre använt en INA260, men nu har jag 1st INA219 så slöseri att inte använda den.
I bilden nedan är det foton från aktiv LCD-skärm i verklig drift.
Nytt: 2022-04-05
INA219 ström-effekt-sensor:
Spänning-ström-effekt-sensorn INA219 ≤+26V ±3.2A är nu tagen i drift: Adafruit_INA219 Class Reference. Fungerar bra efter lite inledande krock på I2C med displayen.
INA219 tar 3250±10µs att läsa av de 4st getShuntVoltage_mV(), getBusVoltage_V(), getCurrent_mA() & getPower_mW() i direkt följd på en Arduino Uno R3.
Att bara läsa av getCurrent_mA() strömvärdet tar 1060±5µs på en Arduino Uno R3. Motsvarar 940ggr/s sampling max!
Uppmätt med Wire.setClock(80000) satt för I2C-kommunikationen, vilket Olimex Shield-LCD 16x2 kräver som max för stabil långvarig drift.
Kan läsa ut matningsspänning, ström, effekt det blir ihop samt spänningsdroppet över strömshuntens motstånd.
Här mäter jag över den gula lysdioden bara som test, men för fläktmotorn ska den mäta upp till ca 35W / 12V, så är ett stort mätområde INA219 har!
När Olimex Shield-LCD 16x2 ska samsas med annan enhet / sensor på I2C kräver den en delay(40) (40ms) mellan den andra I2C-kommunikationen och sin egen I2C-kommunikation för att inte hänga sig, testat mot INA219-strömsensor på ett Arduino Uno R3. Tog ett tag att lista ut, där oscilloskopet var en väldigt god hjälp att visualisera och checka av I2C-kommunikationen och vilka enhets-adresser som var aktiva! Är ändå inget dyrt oscilloskop utan på normal hobbynivå!
Kodade det med en global variabel lastI2CnotDisplay = millis(); för senaste annan I2C-anrop så jag dynamiskt bara ger så mycket delay(x) som behövs för att uppnå 40ms för Olimax LCD!
Mer info om INA260/219/226-sensorerna.
Nytt: 2022-04-16, uppdaterad: 2022-04-25
Synchronous buck converter:
Bygger nu upp och trimmar funktionen hos buck convertern (typ DC-DC omvandlare) som ska styra utspänningen för fläktens varvtalsreglering, där jag använder den mer avancerade utformningen med en asynkron buck converter vars frigångsdiod ersätts av en MOSFET effekttransistor (Q2). Se mer ovan om buck converter.
Blir då två MOSFET (Q1 & Q2) som arbetar som en halvbrygga (1/2 H-brygga, (en)), synkront med varandra omväxlande ON.
För att blockerar omvänd backström när induktansen LX blivit helt urladdad vid buck-converter Discontinuous mode och strömmen vill börjar vända krävs att MOSFET Q2 då sätts OFF och blockerar backströmmen som en frigångsdiod hade gjort där, dvs att MOSFET Q2 arbetar som en ideal diod.
Använder IR2184 half bridge driver för att styra den synkrona driften av de två MOSFET samt för att skapa styrspänningen till den höga MOSFET:en via en charge pump. Har 22ohms motstånd mellan IR2184 och MOSFET-styrena för att dämpa snabbheten något.
Uppkopplingen på kopplingsdäcket med IR2184 PWM-pulsad av Arduino Uno R3 samt de två N-MOSFET (56A / 23milliohm) utan induktorn gick bra direkt och de pulsar perfekt fyrkantvåg med en minimal dödtid mellan deras respektive växlingar för att garantera en synkron funktion utan kortslutning (shoot-through).
2022-04-25
2022-04-26
2022-04-29
Håller på att koda själva temperaturregulatorn i mitt Arduino-projekt "Termohygrostat - klimatstyrning av fläktvarvtal", enligt ovan.
Delar upp regleringen i två loopar, en snabb som reglerar buck-converterns utspänning utifrån börvärde (DC-DC-omvandlare), samt en långsam som utifrån temperaturgivare och önskad temperatur reglerar börvärdet till spänningsregleringen.
Då jag kör buck-convertern även i discontinuous conduction mode (DCM) krävs spänningsregleringen (men gör nog nytta annars också).
Är då helt underbart att koda regulatorn i ett högnivådatorspråk som C/C++ där man kan beskriva parametrar i naturliga termer, som mina förstärkningar för P- resp. I-regleringen:
float P_gain = 0.8; // Volt/Volt regleravvikelse
float I_gain = 2.0; // (Volt/s)/Volt regleravvikelse
Är då drift från 12V blybatterier.
Gissade dessa värden på känsla och de fungerade direkt som en charm, med bra stegsvar och helt stabilt (i vart fall i det lägre spännings-/varvtals-området). Vågar inte köra för fullt för strömmarnas skull (≤3A) nu när allt ännu bara är byggt på kopplingsdäck.
Testar stegsvar genom att hålla för fläktens insug helt, då det tidigare med fast PWM duty-cycle till buck-convertern blev en märkbar förändring i utspänningen, men inte nu längre.
I PWM-spänningsreglerloopen beräknas nya värden ca 1ggr/50ms (20Hz) och då hinner det passera 200 PWM-pulser vid mina 4kHz, vilket gör att det hinner bli en tydligt respons inför varje ny reglerberäkning. I temperaturreglerloopen kommer ny värden beräknas ca 1ggr/s.
Har nu även testat regleringens stegsvar med att broms fläkthjulet med fingret, från 2,1W förbrukning obromsat till 5,5W bromsat, och sedan direkt släppt. Stegsvaret är riktigt snabb och väldigt stabilt utan minsta tendens till svängning, nästan lite förbluffande! Helt nöjd :-)
Även vid start då jag för stunden har fixt börvärde på 25% av 12V (3V) så startar fläkten väldigt distinkt och går direkt upp och får 3V stabil utspänning utan någon märkbar översvängning!
Kommer hantera inverkan från blåst och vindtryck väldigt fint i husvagnen, samt även ge stabil utspänning vid spänningsvariationer som det är i ett 12V solcellssystem, inte minst då kylkompressorn startar och denna enhet kommer vara ansluten mot samma rätt långa kablage!
Har även fixat switch-node ringningen hos buck-converterns MOSFET-halvbrygga så den dämpas och sker med så låg frekvens nu att den inte kan störa något utanför min elektronik.
Så nästa steg är temperatur-reglerloopen.
Ett intressant bifynd blev att störningarna från interna Arduino-interrupt som stör mitt zero crossing detection interrupt en del ökade signifikant när jag la in avläsning av analoga inssignaler i mer frekvent loop. Men genom att öka en delay(6) till delay(40) i min loop så minskade störningen från Arduino-interrupten med en faktor 5-10ggr, och blev mindre än tidigare!!! Så trots vad som brukar sägas, så kan man få nytta exekveringsmässigt av en delay()!
Min funktion att via zero crossing detection interrupt styra nedre N-MOFET till ideal-diod funktion mjukvarumässigt i Arduino Uno R3 fungerar betydligt bättre än jag vågat hoppats på! Men vill man ha än mer tidsmässig precision och repeterbarhet bör man göra det hårdvarumässigt via logikgrindar (J-K master-slave flip-flop, SET and RESET inputs CD4027B?)!
Här är det dock helt OK.
2022-05-06
Nu är även själva temperaturregleringen kodad och fungera bra, med logik för de olika valbara driftsfallen, AC+: ventilering upp till full fläkteffekt, AC: valbart max varvtal för tystare drift, Vent: där fläkten alltid går med ett lägsta valbart varvtal men ökar om varmt / fuktigt.
Har då en PI-reglering, med en långsam I-reglering då jag tror temperaturens respons på fläktande i husvagnen blir rätt långsam. Men får stämmas av och finjusteras väl i drift där:
float P_gainT = 166.7; // PWM ‰12Volt/°C typ 50.0%/3°C, (6V/3°C) - är 12V PM-fläktmotor
float I_gainT = 0.2778; // PWM (‰12Volt/s)/°C typ (50.0%/10min)/3°C, ((6V/10min)/3°C)
Även kodat en övervakning av effekten fläkten drar som stänger av vid onormalt hög effektförbrukning, med adaptiv nivå mot fläktvarvtalet. Så ventilationsfläkten kan lämnas tryggt att köra obemannat under längre tider. Fungera fint.
// Uses 12V^2 instead of 12V^3 for better low fan speed current margins
// 303.65 = (1.25 * (36000mW - 1500mW) + 600mW) / 12V^2, 36000mW = max fan operation power at 12V
// 1500mW = extra permissible power at low speed so as not to stop by a little impact
MaxOkFanPow = 303.65 * sq(U_Fan) + 1500.0 + 600.0;//(mW), 600mW = powerconsumption of electronic
Samt varje gång fläkten stänger av sig oavsett orsak så blockeras ny start i 2 minuter, så man inte får ett eneverande ständigt start/stopp samt att vid övereffekt fläkten ges 5 chanser med 2 minuters mellanrum att starta igen, en räknare som nollställs igen efter 15min med fläkten i drift eller vid reboot.
Har haft igång elektroniken i många timmar och den reagerar verkligen på enstaka 1/10-dels °C för att starta fläkten och reglera varvtalet, till skillnad mot den mekaniska termostat jag har idag till en datorfläkt som har en hysteres på ca ±1,5°C! Är stor skillnad på +24°C eller +27°C!
Med denna Arduino Termohygrostat så när temperaturen vid mitt arbetsbord är precis den inställda temperaturen att reglera på och RHT03 sensorn värma upp ett par 1/10-dels °C från elektroniken så fläkten startar och blåser kylluft mot den, så går fläkten på lågt varvtal en knapp minut och står stilla runt 20 minuter i upprepade sekvenser. Så en fin test på dess väldigt finstämda exakta funktion, vilken jag känner mig väldigt nöjd med i labbmiljön här!
Återstår att koda regleringen för fuktreglering, samt att lägga in ett driftsfall till för fuktkontrollerad grundventilation där det bara fläktventileras så länge absoluta fukthalten i uteluften är lägre än i inneluften, med viss liten marginal. Samt inte minst att få allt på plats i verklig drift i off-grid husvagnen.
Kodning / Firmware klar:
Nu är kodningen klar för fuktregleringen samt driftsfallet för fuktkontrollerad grundventilation där det bara fläktventileras så länge absoluta fukthalten i uteluften är lägre än i inneluften, med viss liten marginal som kan väljas. Så har nu en komplett termohygrostat funktion kodad i C/C++!
Utnyttjar verkligen kapaciteten i Arduino Uno R3 max:
RAM: [=====_____] 46.8% (used 958 bytes from 2048 bytes) (bör hållas <60%, helst <50%)
Flash: [=========_] 86.8% (used 27994 bytes from 32256 bytes)
Har då själv skrivit 1110 kodrader C/C++ för programfunktionaliteten i firmware. Plus 6st installerade kodbibliotek för sensorer, LCD-display och watchdog-funktion.
Programkoden ger 12st olika displayvyer, varav 6st är menyer för olika inställningar och övriga visar typ driftsdata på olika sätt med olika data från sensorerna.
Samt man kan välja 4st olika driftsmoder för olika funktion i fläktventileringen:
- AC: AC-ventilationsdrift, normal för temperatur/fukt.
Försöker hålla max temperatur / fukt nere på inställda värden via varvtalsreglering. Off under vald temperatur / fukt. Max varvtal (volt) som tillåts för fläkten kan ställas in för tyst drift. - AC+: AC-ventilationsdrift, max för temperatur/fukt.
Försöker hålla max temperatur / fukt nere på inställda värden via varvtalsreglering. Off under vald temperatur / fukt. Fläkten tillåts använda max varvtal (full spänning) för max AC-effekt. - Vent: Ventilationsdrift, konstant inkl. temperatur/fukt.
Fläkten går konstant med ett inställt lägsta varvtal (volt). Utöver det försöker den hålla max temperatur / fukt nere på inställda värden via varvtalsreglering om aktuellt. Max varvtal (volt) som tillåts för fläkten kan ställas in för tyst drift. - Rh_V: Fuktkontroll-ventilationsdrift för max torr ouppvärmd (uppvärmd) stuga.
Fläkten går med ett valt lägsta varvtal (volt) så fort inomhusluften är valt antal %-enheter fuktigare än uteluften (absolut fuktmängd), annars är den avstängd. När den går försöker den även hålla max temperatur / fukt nere på inställda värden via varvtalsreglering om aktuellt. Max varvtal (volt) som tillåts för fläkten kan ställas in för tyst drift.
Är tänkt för att hålla en kallställd (ouppvärmd) stuga / husvagn så torr som möjligt inuti, genom att bara ventilera när uteluften är torrare i absolut fuktinnehåll än inneluften!
Krävde inte små många rader kod extra då jag redan har sensorer och deras stöd, så tänkte det kunde vara kul att kunna testa den möjligheten också.
De olika driftsmoderna har testats och provats av genom att emulera / simulera de olika drifterna med påverkan av temp/fukt-sensorerna RHT03 med värme och fukt. Och allt fungerar helt perfekt såhär långt. Hur snabbt temperatur och fukthalt påverkas i husvagnens inneluft av fläktventilering kan jag inte simulera, så det får provas ut på plats att jag valt lagom långsam reglering för stabil drift där. Annars får de två olika värden för det bara justeras lite!
Nu återstår "bara" att löda in all den egenutvecklade elektroniken från kopplingsdäcket på experimentkretskort, bygga in allt i en apparatlåda samt installera i husvagnen.
Är en mer avancerad och komplex konstruktion än en PWM-solladdregulator, både i programkodning och elektronikhårdvara! Så ger bra erfarenhet till nästa projekt: PWM-solladdregulator.
2022-07-30
Inbyggnad i apparatlåda:
Bygger in LCD-display, Arduino Uno R3 samt övrig elektronik. Elektroniken flyttar jag från kopplingsdäcket och löder in på ett "Arduino ProtoShield" samt på ett "Experimentkort breadboard 400 hål" som blir smidigt att flytta över på från kopplingsdäcket. Går lite trögt just nu, tyvärr.
Hade 38-40°C i lägenheten, så fick prioritera att bygga myggnätsdörr med fläktar till balkongdörren för att kunna kyla ned lägenheten nattetid, så lite snarlikt detta projektet. Gick inte att koncentrera sig på elektronik i den värmen!
Men det är klart nu sedan några dagar, så börjat med detta igen, men lite trött efter värmen.
2022-08-04
Fritzing:
Ska flytta över min experimentuppkoppling på breadboard med 840 kopplingspunkter till ett "Experimentkort breadboard 400 hål", så layouten får krympas ned och göras om. Samt lite läggs över på ett Protoshield för Arduino UNO. För att underlätta detta köpte jag Fritzing-programvaran (86kr) som är till för schemaritning på breadboards / kopplingsdäck, för att göra det lättare att pussla in kopplingen på det mindre experimentkort-breadboardet! Känns som det kommer underlätta det arbetet betydligt samt minska risken för kopplingsfel.
Då kan jag utan att röra befintlig koppling på 840-håls breadboardet rita upp kopplingen på en 400-håls breadboard layout, och sedan ha det som underlag när jag ska löda in de flyttade komponenterna! Är nog bristen på det som stoppat upp och gjort mitt arbete trögt.
2022-08-09
Fritzing skiss:
Har nu en skiss färdig för överflyttningen till ett 400 hål breadboard experimentkort. Ska bara dubbelchecka innan jag flyttar komponenterna och löder in dem där. Hittad ett par små fel i mitt KiCad-elschema jag rättade också. RHT03-sensorerna ska inte lödas in direkt där på Arduino Protoshield, utan den som ska vara utanpå lådan med eltrådar direkt och den som ska mäta yttertemperatur via inlödd Stiftlist XH 4-pol kontakt. Sedan är komponentbiblioteket i Fritzing rätt begränsat, så man får använda det som är närmst att symbolisera med.
Utan Fritzing tror jag det är stor risk det hade blivit något fel här.