Inseguire il sole con i sistemi a fotoresistenza o fotodiodo...funzionano ma hanno dei problemini...specialmente quando passano le nuvole. A cosa può servire l'orologio nel PPTEA (REAL TIME CLOCK)? Visto che sappiamo l'ora e sappiamo anche dove siamo ( posizione geografica sulla terra mediante i navigatori)...possiamo scrivere un algoritmo che ci dica tilt ed azimuth del sole. Questo è un algoritmo di Tracking molto accurato...riporto il codice. Avete capito dove voglio arrivare...basta tradurre questo codice in eabasic ed il gioco è fatto. Bolle
CODICE
// This file is available in electronic form at http://www.psa.es/sdg/sunpos.htm
#ifndef __SUNPOS_H #define __SUNPOS_H
// Declaration of some constants #define pi 3.14159265358979323846 #define twopi (2*pi) #define rad (pi/180) #define dEarthMeanRadius 6371.01 // In km #define dAstronomicalUnit 149597890 // In km
struct cTime { int iYear; int iMonth; int iDay; double dHours; double dMinutes; double dSeconds; };
// Calculate difference in days between the current Julian Day // and JD 2451545.0, which is noon 1 January 2000 Universal Time { double dJulianDate; long int liAux1; long int liAux2; // Calculate time of the day in UT decimal hours dDecimalHours = udtTime.dHours + (udtTime.dMinutes + udtTime.dSeconds / 60.0 ) / 60.0; // Calculate current Julian Day liAux1 =(udtTime.iMonth-14)/12; liAux2=(1461*(udtTime.iYear + 4800 + liAux1))/4 + (367*(udtTime.iMonth - 2-12*liAux1))/12- (3*((udtTime.iYear + 4900 + liAux1)/100))/4+udtTime.iDay-32075; dJulianDate=(double)(liAux2)-0.5+dDecimalHours/24.0; // Calculate difference between current Julian Day and JD 2451545.0 dElapsedJulianDays = dJulianDate-2451545.0; }
// Calculate ecliptic coordinates (ecliptic longitude and obliquity of the // ecliptic in radians but without limiting the angle to be less than 2*Pi // (i.e., the result may be greater than 2*Pi) { double dMeanLongitude; double dMeanAnomaly; double dOmega; dOmega=2.1429-0.0010394594*dElapsedJulianDays; dMeanLongitude = 4.8950630+ 0.017202791698*dElapsedJulianDays; // Radians dMeanAnomaly = 6.2400600+ 0.0172019699*dElapsedJulianDays; dEclipticLongitude = dMeanLongitude + 0.03341607*sin( dMeanAnomaly ) + 0.00034894*sin( 2*dMeanAnomaly )-0.0001134 -0.0000203*sin(dOmega); dEclipticObliquity = 0.4090928 - 6.2140e-9*dElapsedJulianDays +0.0000396*cos(dOmega); }
// Calculate celestial coordinates ( right ascension and declination ) in radians // but without limiting the angle to be less than 2*Pi (i.e., the result may be // greater than 2*Pi) { double dSin_EclipticLongitude; dSin_EclipticLongitude= sin( dEclipticLongitude ); dY = cos( dEclipticObliquity ) * dSin_EclipticLongitude; dX = cos( dEclipticLongitude ); dRightAscension = atan2( dY,dX ); if( dRightAscension < 0.0 ) dRightAscension = dRightAscension + twopi; dDeclination = asin( sin( dEclipticObliquity )*dSin_EclipticLongitude ); }
L'obiettivo dovrebbe essere abbastanza chiaro...e a questo punto della storia si può dire che è alla facile portata del PPTEA configurato con il pluritestato DM1307...il real time clock. Questa funzione viene effettuata con i calcolatori che assorbono centinaia di watt...vediamo come esce da questa storia il PPTEA che assorbe nemmeno 200 milliwatt!!! Realizziamo il primo blocco della funzione SUNPOS...ogni aiuto è ben accetto:
CODICE
1000 ' Calculate difference in days between the current Julian Day 1010 ' and JD 2451545.0, which is noon 1 January 2000 Universal Time 1040 ' Calculate time of the day in UT decimal hours 1045 FDATE=4 1050 dDecimalHours = DATE/3600.0 1053 FDATE=2 1055 GG_MM_AA=DATE 1057 iMonth=mid(GG_MM_AA,4,2) 1060 liAux1 =(iMonth-14)/12 1070 iYear =right(GG_MM_AA,2)+2000 1075 iDay=left(GG_MM_AA,2) 1080 liAux2=(1461*(iYear + 4800 + liAux1))/4 + (367*(iMonth- 2-12*liAux1))/12 1085 liAux2=liAux2 - (3*((iYear + 4900+ liAux1)/100))/iDay-32075 1090 dJulianDate=float(liAux2)-0.5 +dDecimalHours/24.0 1100 ' Calculate difference between current Julian Day and JD 2451545.0 1110 dElapsedJulianDays = dJulianDate-2451545.0 1115 usbout=dElapsedJulianDays&"" 1120 GOTO 1120
Bolle
--------------- Chi sa raccontare bene le bugie ha la verità in pugno (by PinoTux). Un risultato se non è ripetibile non esiste (by qqcreafis).
Grazie Pino! Questa mattina cercansdo di fare il secondo blocco mi sono reso conto di un problema presente nella 2.5 ...porca miseria...l'ho risolto...è talmente sottile che solo con calcoli complessi è saltato fuori...ovviamente nessuno se ne renderà conto...ma la conversione da float a stringa il PPTEA elimina gli zeri prima della virgola...vabbè....risolto ma è già nata la 2.6. Tutto il resto va alla grande...ma porca miseriaaaaaaaaaaaaaaaa Bolle
--------------- Chi sa raccontare bene le bugie ha la verità in pugno (by PinoTux). Un risultato se non è ripetibile non esiste (by qqcreafis).
Ciao Bolle, posso provare a darti una mano anche se come hai visto non sono molto pratico di elettronica...... Per questo progetto verrei montare una nuova basetta in modo da poter lasciare le altre due per il progetto wi-fi che non ho ancora terminato a causa del poco tempo trovato in questa settimana....
PS: quando posso avere anch'io la nuova versione (2.6)? ehehehehehehhe
Ringrazio per la fiducia e per il credo...provo a spiegarvi cosa è accaduto...ma roba da non credere...ho perso tanto di quel tempo per trovare il problema ... il gioco si è fatto talmente duro ...che ho dovuto un varco per infilarmi dentro...poi l'ho prontamente tappato...ma la complessità è tale che sfiora la non comprensione...ma un esempio potrebbe chiarire le cose.
Ovvio che problematiche del genere saltano solo se si fanno cose complesse...ma visto che siamo in corsa...corriamo! Che facciamo non vogliamo mandare il PPTEA nelo spazio?
Facendo eseguire questo calcolo il PPTEA (versione 2.5 e precedenti ) da un valore errato
ha 12 dicfre decimali (troppe per la atof)...se ne levate una cioè eliminate l'otto finale tutto funge perfettamente cioè dobbiamo scrivere 0.01720279169 e ....tutto va senza problemi
Ciao ,qui nevica.Ho gia spalato due volte oggi!Per sapere la propria posizione abbastanza precisamente si può usare anche google earth,A me serviva per stellarium,mi ha dato latitudine longitudine e pure l'altezza slm.Sono pure sulla street view,e credo che un errore di un centinaio di metri sia tollerabile.A proposito i moduli auriel rtx a quanto li avete trovati? Io intorno i 20 euro,è giusto come prezzo?
Si anche Goole Earth va benissimo...occorre trovare il posto mettere il sensore e prendere nota delle coordinate geografiche...questo sistema consigliato lo prenderemo come esempio per inserire nel codice i valori.
Ora faciamo un altro passo avanti. relativo al secondo blocco. Procedo lentamente perchè sto controlando i risultati...infatti misono reso conto che l'anno andava messo senza il 2000...e quindi la linea 170 (rispetto il codice che avevo postato) è cambiata...non ha più la somma. Bole
CODICE
100 'Calcolo posizione Sole FINO AL BLOCCO CON VERSIONE PPTEA 2.6 O SUPERIORE 110 PRAGMA EXTERNAL_EEPROM 1000 ' ----- Calculate difference in days between the current Julian Day 1010 ' and JD 2451545.0, which is noon 1 January 2000 Universal Time ----- 1040 ' Calculate time of the day in UT decimal hours 1045 FDATE=4 1050 dDecimalHours = 35608/3600.0 'DATE/3600.0 1053 FDATE=2 1055 GG_MM_AA="04/02/12" 'DATE 1057 iMonth=mid(GG_MM_AA,4,2) 1060 liAux1 =(iMonth-14)/12 1070 iYear =right(GG_MM_AA,2) 1075 iDay=left(GG_MM_AA,2) 1080 liAux2=((1461*(iYear + 4800 + liAux1))/4) 1081 liAux2+=(367*(iMonth- 2-12*liAux1))/12 1082 liAux2+= -1*(3*((iYear + 4900+ liAux1)/100))/4+iDay-32075 1090 dJulianDate= liAux2 - 0.5 + dDecimalHours/24.0 1100 ' Calculate difference between current Julian Day and JD 2451545.0 1110 dElapsedJulianDays = dJulianDate-2451545.0 1130 ' ----- Calculate ecliptic coordinates ----- 1190 dOmega=2.1429-0.0010394594*dElapsedJulianDays 1200 dMeanLongitude = 4.8950630+ 0.01720279169 * dElapsedJulianDays 'Radians 1210 dMeanAnomaly = 6.2400600+ 0.0172019699 * dElapsedJulianDays 1240 goto 1240
--------------- Chi sa raccontare bene le bugie ha la verità in pugno (by PinoTux). Un risultato se non è ripetibile non esiste (by qqcreafis).
Proseguo con il PPTEA a colcoli astronomici ( in tutti i sensi)... ho aumentato la precisione portando la serie di Taylor al ventesino ordine ....e il PPTEA si difende alla grande...ma nel corso del cammino mi sono reso conto che mi mancava la ATAN2...e che problema c'è mi sono detto...la faccio con l'eabasic...e così ho fatto. Tutto andava alla grande...e mentre stavo finendo il terzo blocco...ho visto una cosa che non volevo vedere: la funzione asin (linea 1640 commentata) ...cioè l'arcoseno....cavoloooooooooooooo! Il PPTEA non ce l'ha...posso svilupparlo con la serie di Taylor in eabsic...ma diventerebbe troppo lento...ci sono due possibilità: 1. faccio lo sviluppo in eabasic 2. nascerà la 2.7 con la funzione arcsin...( e quindi anche arccos...visto che ci siamo).
Questo è il codice...è inutile dirvi che siamo in direttura d'arrivo...anzi senza questo imprevisto...eravamo arrivati...vabbè...le cose facili non ci piacciono! Sono ben accetti suggerimenti! Bolle
CODICE
60 MATH_PRECISION=20 ' AUMENTIAMO LA PRECISIONE DEL PPTEA 100 'Calcolo posizione Sole FINO AL BLOCCO CON VERSIONE PPTEA 2.6 O SUPERIORE 110 PRAGMA EXTERNAL_EEPROM 1000 ' ----- Calculate difference in days between the current Julian Day 1010 ' and JD 2451545.0, which is noon 1 January 2000 Universal Time ----- 1040 ' Calculate time of the day in UT decimal hours 1045 FDATE=4 1050 dDecimalHours = 35608/3600.0 ' DATE ' 1053 FDATE=2 1055 GG_MM_AA="04/02/12" 'DATE ' 1057 iMonth=mid(GG_MM_AA,4,2) 1060 liAux1 =(iMonth-14)/12 1070 iYear =right(GG_MM_AA,2) 1075 iDay=left(GG_MM_AA,2) 1080 liAux2=((1461*(iYear + 4800 + liAux1))/4) 1081 liAux2+=(367*(iMonth- 2-12*liAux1))/12 1082 liAux2+= -1*(3*((iYear + 4900+ liAux1)/100))/4+iDay-32075 1090 dJulianDate= liAux2 - 0.5 + dDecimalHours/24.0 1100 ' Calculate difference between current Julian Day and JD 2451545.0 1110 dElapsedJulianDays = dJulianDate-2451545.0
Ragazzi ci siamo...ho partorito la 2.7 con le due nuove funzioni matematiche ASIN e ACOS e il PPTEA fa calcoli astronomici ... Ho fatto girare l'algoritmo su un orario "scolpito' e posizione geografica fissa (all'incirca Roma) e ho confrontato i valori del PPTEA con un pc compilando il sorgente sunpos.c (presente in testa alla discussione) con il compilatore c++ della Microsoft in doppia precisione e i risultati sono questi:
PPTEA : Azimuth=152.690994 Zenith=62.035507 PC VC++ : Azimuth=152.72910400235 Zenith=61.958506705489 ---------- ------------- Errore in Azimuth=0.038° Errore in Zenith= 0.077°
Possiamo dire che il PPTEA ha un errore trascurabilissimo...qualche centesimo di grado...è una inezia. Per effettuare tutti i conti impiega circa due secondi!! Mi ritengo molto ...molto soddisfatto! Bolle
--------------- Chi sa raccontare bene le bugie ha la verità in pugno (by PinoTux). Un risultato se non è ripetibile non esiste (by qqcreafis).
A questo punto occorre verificare i dati di posizione...ma dovrebbero essere molto precisi:qualcuno ha qualche idea/suggerimento? Ricordo che per l'orario occorre sottrarre un'ora (greenwich) e che l'elevazione è uguale a 90-l'azimuth. Questo è il video ...sono presenti anche i dati per un eventuale contronto.
Un saluto Bolle
--------------- Chi sa raccontare bene le bugie ha la verità in pugno (by PinoTux). Un risultato se non è ripetibile non esiste (by qqcreafis).