AVR/PIC - Digitalt solur - Synka RTC med dagsljus?

[carpelux]

Efter fem år går en 20ppm-kristall 1 timme fel.

och vad kommer en RTC med specen ±3.5ppm from -40°C to +85°C drifta iväg på 5 år då enligt ditt sätt att räkna?

[bearing]

Haha, jag tror nog det är bättre ifall du visar hur man gör istället.

[Icecap]

Det är en del saker i detta.
1: Ett önska om att kolla om det går att skapa en relativ tillförlitlig tid-på-dygnet baserat på en enkel ljusmätning i ett själv-synkroniserande system.
2: Ett önska om att kunde ha en stabil tid att tillgå.

Dessa två önskningar går knappast hand i hand.

Visst går det att hitta "mitt på dagen" med ett rätt placerat system, alltså ingen skuggor som stör. Och att sedan - över några dygn - skapa en dygnsrytm. Och är det bara tid-på-dagen som önskas är det ju OK.

Med en del statistik på ett antal/en del dygn går det faktisk att härleda datum också - med en viss marginal. Det kräver dock en hel del beräkningar.

Jag hade börjat med det praktiska: byggt ett system som loggar ljusintensiteten utomhus. Sättet är i grunden likgiltigt bara förutsättningarna är som det tänkta system kommer att jobba under.

[Nerre]

Ja, att logga data så man har nåt att testa algoritmerna på kan ju vara ett bra första steg.

Då kan man plotta kurvor och se hur det skiljer sig, man kan låta en algoritm "testa" att synka in sig med olika startpunkter etc.

30 min samplingsintervall tror jag kan räcka.

[Gimbal]

Vill man snitsa till det så kan man börja med 30 min intervall som du föreslog, ett par dygn senare när man har en ungefärlig hum om tiden kan man strunta i att sampla på dagen och natten och bara mäta i skymning och gryning. Och då kanske med tätare intervall.

[bearing]

Nattvakten har ingen avancerad teknik, det finns inga antenner eller liknande. Har själv undersökt kretslösningen.

instrålning.png

Gjorde själv något liknande för mer än 10 år sedan, där jag avläser processor-räknaren som slår runt på ca 90 dygn.
Plockar ljuskurvorna för 10 dagar, kasserar de 5 mest avvikande och tar medlet på resten.
Blir felet mindre än 5 minuter eller större än 1 timme jämfört med interna räknaren uppdateras interna räknaren.
Det är klockan tolv man söker, eftersom gryning och skymnings-tid glider för mycket beroende på årstid.
Peak infaller klockan tolv och så mycket som 10 minuter fel har nog inte hänt de senaste 10 åren.
Senaste liknade projektet är en ESP8266 som synkar processor-räknaren mot internet mha ntp en gång i månaden samt vid varje uppstart. Kräver tillgång till trådlöst internet, men det finns ju numera hos de flesta.

Tack för ett bra inlägg. Vad händer om den inte får "Felet mindre än 5 minuter" under några dar p.g.a molnighet e.t.c, och utan ligger t.ex. 10min fel? behöver den då vänta tills felet är över en timme innan den kommer rätt?

Nerre, 30min... Hm, då behöver man ju börja med att skriva en algoritm som gissar peaken på ljuset ur en begränsad mängd data. Om det är lite molnigt runt tolvslaget kan det ju bli fel. Jag skulle nog kört 1min sampling, 1440 punkter per dygn.

[Nerre]

Det är ju inget konstigt, det handlar ju bara om att approximera en sinuskurva utifrån en begränsad mängd punkter.

Och målet är ju (i mina ögon) inte att hitta kurvans "peak" utan att hitta "mittemellan" två punkter på samma nivå. Som det har påpekats tidigare så blir kurvan väldigt flack vid ljusaste tidpunkten på dagen, ska man mäta tider med oscilloskop så mäter man inte från peak till peak utan man försöker mäta t.ex. från flank till flank vid 50% nivå.

[bearing]

Aha, så du tycker det är enkelt=)
Då har du mycket bättre förutsättningar än mig att lösa problemet.

Jag behöver starta helt från noll redan där, och börja klura på hur man kan lösa den biten. Någon sorts minsta kvadrat-metod antar jag.

[Nerre]

Det man gör är ju i princip en lågpassfiltrering, precis på samma sätt som vid A/D-omvandling.

Det svåra är kanske att göra det med enkel heltalsaritmetik, men å andra sidan behöver du ju inte interpolera hela kurvan.

Du behöver bara interpolera stigande och fallande flanken där den är som brantast.

[Gimbal]

Behöver det ens vara så komplicerat?
Räcker det inte att detektera när omslaget mellan natt och dag (samt tvärtom) sker? Mitt emellan de punkterna var det midnatt, eller middag vilket man nu väljer att fokusera på.

[bearing]

Nja, kanske i platt öken eller på ett hav.
Det borde ju vara övre halvan av den inspelade kurvan som är mest pålitligt (som E Kafeman antyder), eftersom att solen är över horisonten med marginal. Det kan ju vara olika höjd på träden i horisonten vid gryning och kväll, för att nämna en sak som ställer till det om man inriktar in sig på gryning och kväll. Dessutom kommer ju solstrålarna med en väldigt dålig vinkel mot sensorn, om vi antar att sensorn ligger horisontellt. Kurvan mellan 45° till 135° borde väl vara bäst, där 90° betyder att solen är som högst.

Kurvan är väl som brantast vid 0 och 180°, men där finns det fortfarande risk för träd. Och på vintern är solen inte ens uppe.

Angående långsam sampling skulle ju en gren från ett träd kunna skugga sensorn just när man samplar. Det vore ju inte bra. Så jag förespråkar fortfarande snabbare sampling.

[bearing]

Och målet är ju (i mina ögon) inte att hitta kurvans "peak" utan att hitta "mittemellan" två punkter på samma nivå.

Det här är ju en bra poäng. Om vi säger att man lägger dessa punkter vid 45°, kanske det går att göra rätt enkelt, utan att få en kurva att passa. Men det kanske var detta du var inne på, som jag inte förstod.

Man behöver nog lägga gränserna ännu högre för att klara vintern. 45°/135° borde ju vara kl 9/15, vilket inte går i december. kl 10/14 går kanske, om träden inte är för höga. D.v.s 60°/120°. Där är derivatan hälften av vad den är vid kl 6/18, så fortfarande ganska brant, vilket ju är bra.

[mrfrenzy]

Jag tror att ni överkomplicerar detta.

Om man bara vill veta när midnatt inträffar borde det räcka med följande två funktioner:
En som varje minut loggar aktuellt luxvärde och sparar dom fem senaste.
Om medelvärdet av dom fem senaste mätningarna <X så ändras status till mörkt och vice versa.

En annan funktion sparar klockslaget för varje ändring dom senaste 7 dagarna.
Mediantidpunkten däremellan blir midnatt.

Förmodligen funkar samma X på alla orter som inte har midnattssol, men vill man lyxa till det kan den ju ändras dynamiskt om det är orimligt kort eller lång tid mellan omslagen (tex om sensorn sitter under tak).

[Gimbal]

Nja, kanske i platt öken eller på ett hav.
Det borde ju vara övre halvan av den inspelade kurvan som är mest pålitligt (som E Kafeman antyder), eftersom att solen är över horisonten med marginal. Det kan ju vara olika höjd på träden i horisonten vid gryning och kväll, för att nämna en sak som ställer till det om man inriktar in sig på gryning och kväll. Dessutom kommer ju solstrålarna med en väldigt dålig vinkel mot sensorn, om vi antar att sensorn ligger horisontellt. Kurvan mellan 45° till 135° borde väl vara bäst, där 90° betyder att solen är som högst.

Samtidigt så är det en väldigt stor skillnad på när solen går under horisonten jämfört med när den bara skuggas av ett träd nära horisonten. I den ena fallet kan man läsa en bok exempelvis, men några minuter efter att solen gott under horisonten blir det plötsligt riktigt svårläst. Det skillnaden borde gå att detektera, lite skugga är fortfarande allt för ljust.

[Icecap]

Jag anser att detta att mäta ljusstyrkan i nivåer är knasigt. Jag hade tagit en sensor och nöjd mig med "dagsljus" eller inte.