----------------------------------- jimao22 11 Aug 2013 15:22 Automatizare observator - consideratii personale ----------------------------------- Am pornit la drum cu acest topic, nestiind precis unde sa-l incadrez mai bine. Ar fi mers foarte bine la "Monturi / trepiede" de exemplu, asa cum am facut cu topicul ASCOM. Ar fi mers foarte bine de asemenea si la "Soft pentru astronomie" fiindca consideratiile ce se vor face pe marginea acestui subiect se leaga foarte mult de partea de programare si softuri cu legaturi imbricate. Am preferat totusi sa-l pun aici, fiindca rezultatul final pe care-l astept este legat de un sistem fizic ce il doresc functional la sfarsit si care este (sau ar trebui sa devina) telul final al zbaterilor mele din ultimii 2-3 ani. Dorinta mea de cand astronomia a inceput sa ma preocupe a fost sa pot avea acces la mai mult decat se poate vedea cu ochiul liber, constient fiind ca doar astrofotografia este raspunsul la aceasta. Doar ca astrofotografia este un domeniu cu multe restrictii si am sa enumar doar cateva: - dificultatea de abordare materiala - necesita scule si echipamente mult peste media celor folosite la observatiile vizuale - dificultate de abordare tehnica - chiar daca primul obstacol (cel de mai sus) este depasit, a face un astfel de sistem sa devina functional - nu neaparat automatizat sau controlat remote (doua chestii diferite si nu neaparat conectate) - necesita pregatire tehnica si studiu serios in ceea ce priveste achizitia de date corecta si in egala masura prelucrarea acestora. Lucrul acesta nu este usor si necesita mult timp si dedicatie pentru a putea fi rezolvat - dificultate in relatiile cu familia - nu radeti, este foarte reala si sunt convins ca toti aveti mai mult sau mai putin astfel de episoade, generate de frustrarile la care supunem familia cand stam noaptea pana tarziu afara, cand cheltuim banii de concediu, cand cadem rupti de oboseala in serile noroase, s.a.m.d. - dificultatile de ordin personal - si aici ma refer (facand o analiza a ceea ce mi se intampla mie) legate de lipsa cronica a timpului - in general - care se acutizeaza si devine chiar periculoasa atunci cand o astfel de pasiune incepe sa ocupe si putinul timp de odihna ce ramane disponibil - pierderile de oportunitati generate de lipsa timpului alocat observatiilor - multe nopti sunt bune pentru astronomie dar fie suntem ocupati cu altele, fie suntem obositi, fie niste nori trecatori ne strica cheful de poze si intram in casa si apoi toata noaptea e senin sticla, s.a.m.d. Ca sa nu mai vorbim de faptul ca noaptea are in medie pe an (fara crepuscul) 10 ore/24 din care noi stam la observatii/pozat doar cateva la inceput sau spre dimineata, fiindca ma trebuie sa si dormim, nu? Dar fiindca suntem oameni si problemele sunt ale oamenilor si trebuie rezolvate tot de oameni, am hotarat (in ceea ce ma priveste) sa rezolv toate astea, pentru a ajunge la scopul final - sa fac astrofotografie fara sa-mi distrug viata si sanatatea. Am avut toate astea clare in minte in momentul in care am inceput acum cativa ani in urma sa destelenesc drumul asta, fiindca solutia era clara si simpla - un observator astronomic automatizat si eventual comandat remote. Acestea sunt premizele de la care voi pleca cu desfasurarea acestui topic, unde voi incerca sa explic si celor care stiu (si eventual ma pot ajuta) si celor care nu stiu (dar ar vrea sa incerce ceva macar partial) ce am facut eu pana aici si ce urmeaza sa fac in continuare, care sunt problemele pe care le-am depasit si care sunt problemele curente precum si desfasurarea lor. Numai bine. ----------------------------------- jimao22 11 Aug 2013 15:44 ----------------------------------- Pentru a ajunge la final, trebuiau rezolvate problemele pe rand. Partea materiala a fost un razboi neintrerupt cu familia (nu va ganditi la lucruri prea grave insa), dar si cu mine insumi. Sotia era exasperata de faptul ca intotdeauna imi mai trebuia ceva. Si nu as zice ca nu avea dreptate. D-asta o iubesc eu, fiindca pana la urma a inteles toata nebunia asta a mea si in final chiar m-a sprijinit. Nu o sa va vina sa credeti, dar cand mi-am cumparat camera ATIK, mi-a sugerat sa o iau noua desi gasisem una second hand, iar diferenta de pret era semnificativa. Batalia mai grea , insa, a fost cea cu mine, fiindca asa cum stiti si voi, odata intrat in pasiunea asta cu toata fiinta, intri si intr-un fel de cursa a "inarmarii" cu ce e mai bun si intotdeuna ce ai cumparat ieri, azi pare ca nu mai e suficient, fiindca ai vazut ceva mai bun dar nu ti l-ai putut permite ieri, nu-i asa? Ca sa nu mai vorbim de faptul ca fiind o pasiune cu un numar nu foarte generos de membrii "cotizanti", experientele personale relativ la diferite dispozitive sau instrumente sunt reduse si fiecare experimenteaza pe cont propriu si pe buzunarul propriu si invata din propriile greseli. Asa ca a ajunge la set-up-ul "perfect" (de fapt cel care se pliaza cel mai bine pe dorintele si cerintele personale ale fiecaruia) este o actiune riscanta si mare consumatoare de resurse. In ceea ce ma priveste, dupa aproape 5 ani de experimentari in acest sens, simt ca m-am apropiat de linia de finish. Nu vreau sa mai continui fiindca criza este o prezenta universala (1) si cred ca nu am folosit ABSOLUT niciodata un set-up la intreaga lui putere si valoare (2), asa ca a continua pe calea asta este o prostie, care nu ar face dacat sa mascheze neputinta mea de a folosi la intregul potential ceea ce am acum. ----------------------------------- jimao22 11 Aug 2013 16:02 ----------------------------------- Dificultatile de abordare tehnica sunt diferite. Aici fiecare se descurca dupa abilitatile ce le are si dupa dedicatia ce o acorda rezolvarii problemelor tehnice. La momentul respectiv, am deschis topicul "ASCOM" de la "Monturi si trepiede", unde am intrat in intuneric total, fara sa am nici cel mai mic habar despre ce era vorba. ASCOM era insa cheia care deschidea calea pe care eu vroiam sa merg asa ca am pornit la drum voios. Emil Kolbert s-a dovedit unul din cei mai capabili membrii ai forumului (in ceea ce priveste partea asta, desigur) si unul din cei mai dornici de a ajuta. Imi pare nespus de rau ca prezenta lui aici a devenit o raritate, dar ne delectam cu diletantii si cu scandalagii de pe forum, nu-i asa? In fine, asta e off-topic si nu vreau sa intru in polemica cu nimeni pe tema asta aici. Trebuie subliniat un lucru, care la mine era cam varza in cap la un moment dat: automatizarea si controlul la distanta sunt probleme total diferite. Ele pot merge in paralel, desigur, dar se poate face si asa: - un observator automatizat complet, dar care sa necesite la inceput de sesiune prezenta unui om pentru a porni calculatorul, a deschide acoperisul, a face programarea sesiunii de observatii, etc. - un observator neautomatizat, dar controlat remote (din casa) - asta fiind util cand e frig iarna, cand e cald si zapuseala si tantari vara - o treaba relativ simpla, ce necesita minime dotari si softuri de control. Cam asa a functionat la mine treaba pana sa-mi termin observatorul (cladirea). - un observator automatizat si controlat remote - ei da, despre asta o sa incercam sa vorbim ----------------------------------- jimao22 12 Aug 2013 12:10 ----------------------------------- Un prim aspect de care vreau sa vorbesc azi este ghidajul. Asa cum se stie, ghidajul este o treaba sensibila in astrofotografie. Un ghidaj bun corecteaza eroarea periodica (care este specifica miscarii pe ascensie) sau driftul (care se vede in special pe declinatie) dar poate genera la randul sau erori specifice - flexura diferentiala. Cu cat erorile enumerate mai sus sunt mai mici, cu atat guidingul isi face mai bine treaba. Un ghidaj devine din ce in ce mai bun cu cat lungimea expunerilor camerei de ghidaj devine mai mare. Ideal, o expunere de 5 secunde la camera de guiding ar trebui sa asigure un ghidaj lin si foarte bun. Conditia este ca erorile de drift si de perioada sa fie suficient de mici incat sa nu forteze o corectie mare, data de un timp de expunere la ghidaj mare. Flexura diferentiala apare cand elementele ghidajului (luneta de ghidaj si luneta de ghidaj) au un mic joc fata de elementele componente ale partii de achizitie (telescopul principal cu camera de achizitie). Jocul respectiv poate sa nici nu existe, sa existe doar o miscare generata de elasticitatea elementelor de legatura intre cele doua. Fiindca se lucreaza cu marimi extrem de mici (1 pixel la mine inseamna 1.34 secunde de arc), o deformatie din aceasta de oridinul icronilor, genereaza aceasta flexura. Aste este motivul pentru care am spus la un moment dat ca imi voi face un Off-axis-guider. Acest element optic, spliteaza raza de lumina care vine de la obiectivul telescopului si o particica din ea o duce catre camera de ghidaj. Nu mai e nevoie de luneta de ghidaj (1), greutatea ansamblului e mai mica (2), dispare flexura diferentiala (3). Deci numai avantaje. Numai ca exista si un "dar". Un OAG deviaza putina lumina in lateral pentru camera de ghidaj si pozitia in care este asezat permite gasirea unei stele de ghidaj intr-o zona limitata de cer. Chiar foarte limitata. Pentru a elimina oarecum acest deficit, OAG-ul ar trebui asezat pe un derotator - un echipament ce se utilizeaza indeobste la sistemele astrofotografice asezate pe o montura alt-azimutala, unde urmarirea unei portiuni de cer timp indelungat duce la rotatia campului. Un derotator este o piesa de echipament scumpa, care ingreuneaza la loc set-up-ul si care trebuie el insusi inclus in schema de automatizare, fiind necesara si comandarea lui in timpul sesiunilor astrofoto. Eu aproape am terminat OAG-ul meu, dar in lumina noilor experiente, este foarte probabil ca set-up-ul meu automatizat sa se rezume la clasica luneta de ghidaj pe mai departe. Mai jos este aratata flexura actuala a sistemului meu, de care trebuie sa scap intr-un fel pana incep automatizarea. ----------------------------------- achy1978 12 Aug 2013 17:18 ----------------------------------- Salut Cristi si sa sti ca in mare parte ai dreptate. Totusi, acolo sunt expuneri dintr-o singura noapte sau mai multe integrate? .... pentru ca este ceva care imi scapa, in sensul ca acolo ai expuneri din cel putin 2 nopti ... cel putin asa vad (sau ai un meridian flip) ----------------------------------- dragos.n 12 Aug 2013 20:26 ----------------------------------- O buna automatizare, trebuie obligatoriu sa ia in calcul posibilitatea aparitiei erorilor in sistem, a suprasarcinilor electrice, interferentelor, si mai ales, trebuie sa prevada dublarea comenzilor automate cu unele manuale pentru partile esentiale, cum ar fi parcarea instrumentului, inchiderea capacului observatorului. Nu trebuie ignorata nici facilitarea interventiilor care pot fi necesare la un moment dat. ----------------------------------- achy1978 12 Aug 2013 20:43 ----------------------------------- O buna automatizare, trebuie obligatoriu sa ia in calcul posibilitatea aparitiei erorilor in sistem, a suprasarcinilor electrice, interferentelor, si mai ales, trebuie sa prevada dublarea comenzilor automate cu unele manuale pentru partile esentiale, cum ar fi parcarea instrumentului, inchiderea capacului observatorului. Nu trebuie ignorata nici facilitarea interventiilor care pot fi necesare la un moment dat. Aici am avut eu cel mai mult de munca ... la redundanta partilor din automatizare si sper ca evenimentele sa nu ma gaseasca descoperit ... pentru ca nu exista a 2-a sansa ... din pacate :(. Referitor la poza: 1. De flexura nu vei scapa in veci (cam asa imi spunea prietenul Emil Kolbert) ... insa vei invata sa o administrezi (adica o sa incerci sa te incadrezi in timpul maxim de expunere unde flexura este sub limita seeing-ului), astfel incat profilul stelei sa nu fie afectat. 2. La prima interpretare am gresit ceva ... acolo ai o reflexie multipla ... acea multitudine de stelute duble separate foarte frumos :). ----------------------------------- jimao22 13 Aug 2013 07:18 ----------------------------------- @achy - expunerile sunt dintr-o singura noapte (sau s-ar putea sa fie din doua nopti - nu mai tin minte), fara meridian flip (nebuloasa trecea la meridian pe la 5 dimineata.) Stacarea fara aliniere a facut-o auriga, care mi-a trimis inapoi rezultatul si nu mai stiu daca i-am dat toate expunerile sau doar primele din ele. @dragos.n - o sa ajungem si acolo, unde o sa povestim despre UPS-uri, baterii si scheme care sa le cuprinda. Momentan am un UPS cu baterie externa de 55Ah cu gel, pe care-l folosesc ca sa uniformizez varfurile si caderile de tensiune din retea (sunt destul de dese), urmand ca sa-l folosesc la inchiderea de urgenta a acoperisului cand cade curentul. ----------------------------------- achy1978 13 Aug 2013 09:27 ----------------------------------- Atunci, nu prea inteleg lipsa de simetrie intre stelele propriu-zise si reflexiile aparute ?!? ----------------------------------- jimao22 13 Aug 2013 10:02 ----------------------------------- Daca vrei, iti trimit pozele si tie, poate te dumiresti. ----------------------------------- jimao22 19 Aug 2013 22:09 ----------------------------------- Am o problema descoperita de curand. Faptul ca m-am asezat la "observatorul meu" m-a facut sa folosesc fiecare seara disponibila pentru achizitii de imagini, ca sa ma razbun pentru timpul nefolosit in acest scop din ultimele luni. Totusi, fiindca iarna cea necrutatoare o sa vina curand si pana atunci sper sa fac ceva cu automatizarea, mi-am sacrificat o seara saptamana trecuta facand doar teste tehnice, software, cu MaximDL + ACP + TheSky + EQMOD + ACP Planner. Problema rezida in folosirea functiei SYNC (sincronizarea cerului real cu cel virtual din calculatorul de control), ce se poate face - am descoperit - in doua feluri antagonice. Am sa explic pe scurt despre ce e vorba si sper sa fie cineva in masura sa ma lamureasca pana nu-mi explodeaza neuronul. Varianta 1 - este cea pe care o foloseam pana acum si despre care am crezut ca e singura disponibila. Deci, punem telescopul in statie, cat mai bine aliniat polar si apoi, cu TheSky pornit si cu EQMOD conectat (deci telescopul vizibil pe cerul din TheSky), dam drumul telescopului catre o stea mai mare din planetariu, dupa care verificam fizic cu finderul / laserul / telescopul daca respectiva stea este in centrul campului vizual din telescop. Daca nu, cu ajutorul comenzilor din EQMOD, miscam telescopul pe ascensie si declinatie pana ce steaua este fix in centrul campului din telescop, dupa care din fereastra Object Information si tab-ul Telescope, apasam SYNC. In acest moment, reticolul virtual din planetariul TheSky se repozitioneaza pe steaua unde am miscat telescopul initial (prin manevrele facute urmarind steua de pe cer sa fie in campul telescopului, reticolul din planetariu s-a miscat si el de pe stea unde era initial). Manevra este valabila folosind orice planetariu (TheSky, Carte du Ciel, Hello Northern Sky, Starry Night si chiar Stellarium impreuna cu Stellarium Scope) si se repeta de cateva ori in zona de cer ce se doreste explorata in seara respectiva, fiecare manevra de acest gen ducand la o precizie tot mai sporita a pozitionarilor ulterioare. In pozele de mai jos explic vizual ce am explicat verbal mai inainte. ----------------------------------- jimao22 20 Aug 2013 00:44 ----------------------------------- Varianta 2 - este mai elaborata dar totusi mai simpla, utilizand mult mai mult resursele calculatorului in loc de cele ale operatorului uman. Pentru asta nu e nevoie de vreun planetariu dedicat ci este suficient MaximDL cu PinPoint Astrometry pentru rezolvarea placii astrometrice (am sa explic imediat ce inseamna asta pentru cei ce nu stiu). Deci se porneste maximDL si se cupleaza telecopul la el via EQMOD. Din micutul planetariu propriu al lui Maxim, se conecteaza telescopul la calculator via EQMOD si apoi se da orientare (slew) telescop spre steaua noastra pe care vrem sa sincronizam (tot Errai). Facem o poza a zonei de cer unde este pozitionat telescopul nostru real si apoi in TAB-ul Analize -> PinPoint Astrometry, apasam butonul Process. Calculatorul va compara stelele din poza noastra cu cele din catalogul stelar accesat de PinPoint si comparandu-le, va vedea unde se afla de fapt telescopul nostru pe harta cerului si apoi ne va spune si cat de departe e de zona care ne intereseaza pe noi. Mai mult, poza noastra o va aseza exact unde trebuie pe harta cerului din memoria sa (overlay) si astfel putem vedea exact eroarea de pozitionare. Mergand apoi in TAB-ul Telescope, apasand butonul SYNC, telescopul virtual se va duce pe centrul pozei noastre, unde este pozitionat de fapt telescopul real - asa incat cele doua pozitii se vor sincroniza. ----------------------------------- cmatei 20 Aug 2013 01:20 ----------------------------------- Am o problema descoperita de curand. N-am inteles totusi, care e problema... :-) Iti spun cum fac eu, e posibil sa fie aplicabil si cu eqmod/maxim/etc pe care eu nu le folosesc. Pozitia raportata de synscan (deci nu eqmod, ala ar trebui sa fie mai precis dar in esenta functioneaza la fel) are o eroare de pana la 10-20 arcmin fata de pozitia reala pe cer. Functia sync calculeaza un offset intre pozitia reala (cunoscuta de exemplu prin centrarea unei stele) si pozitia pe care encoderele virtuale - din synscan sau eqmod - o "stiu". Apoi la orice goto aplica acel offset la coordonatele pe care le-ai dat tu si respectiv scade acel offset cand raporteaza pozitia. Daca esti aproape de coordonatele la care ai facut sync, pozitia reala si pozitia raportata o sa fie practic identice, o sa ai in planetariu cruciulita exact in pozitia de pe cer. Functia asta se poate implementa oriunde, fie in synscan - nu e cazul, nu stie de sync, in eqmod, in software-ul de control (maxim?) sau chiar in planetariu, e acelasi lucru. Poti sa lasi in pace (fara sync adica) montura/eqmod si sa-ti faci centrarea la achizitie, cum fac eu. Goto din planetariu, o sa ma puna relativ aproape. Fac un 5-10 secunde L caruia ii gasesc solutia astrometrica. Offset-ul intre pozitia calculata si cea raportata il adaug la coordonate si trimit un nou goto. In 1-2 astfel de iteratii ajung la mai putin de 5-10" de target - ceea ce e fantastic la poze in nopti diferite, sunt doar cativa pixeli diferenta. Nu e asa deranjant ca n-ai pointerul in planetariu exact acolo... Sunt aproape sigur ca poti face acelasi lucru (complet automat) in maxim cu pinpoint. Ar trebui sa fie mai precis decat un simplu SYNC pe stea. EDIT: intre timp, ai postat varianta 2, care e aproximativ ce sugeram si eu aici.... ----------------------------------- jimao22 20 Aug 2013 08:07 ----------------------------------- N-am inteles totusi, care e problema... Pai n-am mai apucat sa enunt problema ca era tarziu si incepusem sa fac niste poze. Dar ti-o zic numaidecat. Problema apare la meridian flip (saltul peste meridian). Cu prima metoda, saltul peste meridian este o chestie care-mi da un pic peste sincronizarea, dar nu mult (probabil ca depinde de numarul de stele luate in calcul). Cu metoda 2, care este foarte frumoasa si de mare acuratete, saltul peste meridian este un dezastru. Asta e problema! Voi cum ati rezolvat sincronizarea si gestiunea meridian-flip-ului? Si are legatura cu automatizarea fiindca se presupune ca nu e nimeni langa telescop la meridian flip ca sa vada cat de raue data peste cap pozitionarea. Trebuie ca totul sa mearga automat, nu uita... ----------------------------------- cmatei 20 Aug 2013 11:25 ----------------------------------- Cu metoda 2, care este foarte frumoasa si de mare acuratete, saltul peste meridian este un dezastru. In ce sens ? Goto cu salt peste meridian intr-adevar nu te pune exact in aceeasi pozitie (neortogonalitate, flexura, etc), dar poti aplica din nou metoda 2 pentru re-centrare. Mai complicat (la eq6) mi se pare sa fii foarte sigur pe care parte a meridianului esti. Din perspectiva automatizarii, cu asta as avea un stres. ----------------------------------- jimao22 20 Aug 2013 17:01 ----------------------------------- jimao22 a scris: Cu metoda 2, care este foarte frumoasa si de mare acuratete, saltul peste meridian este un dezastru. In ce sens ? In sensul ca diferenta intre pozitia unde ar trebui sa fie dupa meridian-flip si unde se afla de fapt dupa acest pas, este uriasa (chiar si 5-10 grade). Iar cand ai 5-10 grade diferente de la pozitia reala, rezolvarea placii astrometrice poate sa nu se faca deloc sau sa dureze 1 ora sau mai multe. Ca sa explic un pic de ce am spus mai sus ca cele doua metode sunt antagonice: - cu prima metoda, aliniem telescopul real la cerul virtual din masina (planetariu) - cu a doua metoda, cerul din planetariu gliseaza pe pozitia reala a telescopului ----------------------------------- cmatei 20 Aug 2013 18:56 ----------------------------------- In sensul ca diferenta intre pozitia unde ar trebui sa fie dupa meridian-flip si unde se afla de fapt dupa acest pas, este uriasa (chiar si 5-10 grade). Nu stiu sa-ti spun ce, dar ceva e foarte in neregula aici. La mine dupa flip eroarea de pozitie e de cateva minute de arc. ----------------------------------- Emil 20 Aug 2013 21:42 ----------------------------------- Ceea ce faci tu acum este din punctul meu de vedere semi-automatizare. Consider automatizare situatia in care eroarea de repozitionare dupa meridian-flip este determinata si corectata exclusiv software fara interventie umana. Revenind la eroarea de dupa meridian-flip, cate puncte de align ai, ai facut doar pe o parte a meridianului sau complet? Eu nu pornesc o sesiune foto atat timp cat nu am cel putin 20 de puncte de aliniament distribuite cat de cat uniform pe intreaga zona pe care telescopul o poate "ataca". Flexura poate sa apara la partea optica (oglinda de exemplu), sistemul optic pe ansamblu (ansamblul telescop camera CCD) cat si in montura propriu-zisa fiind proportionala cu nivelul de incarcare a monturii. In principiu eu folosesc doar solutii astrometrice, este mult mai usor sa stabilesc eroarea de pozitionare printr-o solutie astrometrica mai ales ca max-ul poate sa afiseze in planetariu imaginea capturata prin CCD (insa doar daca solutia astrometrica a fost efectuata cu succes). La eroarea pe care o ai eu as verifica la singe inca o data intregul sistem, undeva ceva nu este in regula. @cmate "Mai complicat (la eq6) mi se pare sa fii foarte sigur pe care parte a meridianului esti. Din perspectiva automatizarii, cu asta as avea un stres." Este usor rezolvata printr-o interogare ASCOM "pier side" sau "Side of Pier" nu mai stiu exact numele comenzii asta daca am inteles corect ce anume ai vrut tu sa spu. ----------------------------------- jimao22 20 Aug 2013 22:34 ----------------------------------- Multumesc, Emil pentru interventie. Credeam ca nu o sa mai apari 8). Momentan, ce am eu nu e nici o automatizare. Doar imi exprim dorinta de a face o automatizare. - cum faci tu automat corectia dupa meridian flip - software? - cand faceam sincronizare in TheSky, faceam pe minim 20 de stele si eu. Am setat de asemenea in EQMOD la Alignment/Sync sa se introduca punctele de corectie la sincronizarile facute in alte soft-uri (append on sync). Daca aceasta baza de date se salveaza la parcare si inchiderea telescopului/EQMOD-ului, la urmatoarea pornire mai trebuie facut vreun sync? ----------------------------------- Procyon 21 Aug 2013 00:54 ----------------------------------- Din cate stiu eu, daca tubul optic nu a fost miscat dupa oprirea setupului, atunci sinctonizarile ramase sunt valide si la urmatoarea sesiune. ----------------------------------- Emil 27 Aug 2013 09:03 ----------------------------------- Procyon are dreptate. Referitor la meridian flip, dupa cum stii folosesc CCDAP 5 pentru automatizare. Dupa ce flip-ul a fost efectuat, el - software-ul - efectueaza pana la 3 solutii astrometrice pentru a aduce obiectul in limitele de eroare stebilite de catre utilizator, daca, dupa aceste 3 solutii eroarea este mai mare decat limita determinata de catre utilizator, atunci sesiunea foto ste continuata cu eroarea minima pe care a fost capabil sa o atinga. In general, chiar daca nu reuseste sa ajunga la aceasta limita, eroarea este neglijabila. Poate daca arunci o privire pe manualul soft-ului vei gasi ceva raspunsuri la problemele tale http://www.ccdware.com/help/ccdap5/ccdap5.html iar la link-ul urator ai prezentarea soft-ului http://www.ccdware.com/products/ccdap5/presentation/ap5.html Emil ----------------------------------- Vlad 27 Aug 2013 11:46 ----------------------------------- Nu am observator, insa fac toate sesiunile "remote" de pe canpaea ca sa nu mai ies afara. Dupa schimbul de meridian, intotdeauna este destula diferenta, iar uneori prea mare pentru MaximDL. Maxim DL, daca nu esti deja destul de aproape, mie cel putin nu imi functioneaza. L-am lasat odata si 5 minute sa calculeze dar pana la urma l-am oprit pentru ca nu mai aveam rabdare. Asa ca folosesc Astrotortilla cand schimb meridianul. Programul folosestte motorul astrometry.net pentru solutii astrometrice si merge mult mai bine decat MaximDl, atunci cand este mai departe de (cate grade - oricate) de tinta. Si mie mi se intampla uneori sa nu coincida chiar pana la ultima secunda , asa ca m-am obisnuit dupa ce sunt deja aproape in aceeasi pozitie sa sterg toate punctele de sincronizare anterioare (in special cele ramase de pe partea cealalta a meridianului) si atunci in general ma aduce la 2"-3" de imaginea originala (560mm focala, rezolutie 2.37"/pixel) ----------------------------------- jimao22 27 Aug 2013 12:35 ----------------------------------- Da. Experienta lui Vlad este mult mai aproape de a mea. Din testele facute pana acum cu sincronizarile facute in TheSky (sau mai nou Maxim) si adugate automat in EQMOD, de la o seara la alta nu imi ramaneau valabile. Pot pune asta si pe seama faptului ca plimbandu-ma pe langa telescop in timpul zilei il mai atingeam din greseala si posibil il miscam din pozitia sa. Dupa ce dezbatem un pic problema asta si ajungem la o concluzie, as vrea sa revenim (dupa ce fac cateva teste si incercari) la partea cu flexura precum si la cea cu focalizarea automata (discutata si la http://www.astronomy.ro/forum/viewtopic.php?p=118247#118247 ). Focalizarea automata exclude masca Bahtinov si Bahtinov grabber, astea merg doar ca si "double check" in teste, atat. ----------------------------------- Emil 27 Aug 2013 13:41 ----------------------------------- Eroarea de meridian flip este influentata de precizia cu care sa efectuat punerea in pol in primul rand si apoi de catre erorile mecanice ale componentelor telescopului in mod singular cat si ca ansamblu. Ai incercat Maxpoint-ul? http://www.cyanogen.com/point_main.php Apropos: ce eroare ai dupa meridian flip? La mine se mentine in limite rezonabile. Vlad ai incercat sa limitezi numarul de stele utilizate pentru solutia astrometrica? La mine, limitarea a insemnat trecerea de la o solutie astrometrica obtinuta in decursul unor minute la sub 30 secunde. EDIT inca ceva daca eroarea este prea mare pentru a fi determinata printr-o solutie astrometrica clasica - sa zic asa, se poate folosi Sky Solve care este conceput pentru a determina pozitia actuala a telescopului in cazul in care a fost pierduta pozitia de home (ca exemplu, domeniul de aplicatie este ceva mai mare) http://winfij.homeip.net/development/SkySolve/index.html ATENTIE pentru baza de date necesare calculatorul trebuie sa genereze intregul set de date, si in functie de procesor aceasta actiune poate sa dureze mult, pe un Quad-core de la intel a durat la mine aproape 10 ore. ----------------------------------- Vlad 27 Aug 2013 14:01 ----------------------------------- Astrotortilla indeplineste acelasi rol ca si SkySolve, numai ca nu are nevoie de catalog de stele si nici sa genereze bazele de date de referinta. Il instalezi si gata. Astrometry.net furnizeaza deja imaginile pentru diferite fov-uri, iar solutia astrometrica este in general gata pentru orice fov, oriunde pe cer in cateva minute. Iar daca stie macar aproximat in ce zona se afla telescopul, mult mai repede. Programul se conecteaza la Maxim pt a face expunerea si la telescop prin Ascom pentru sincroniza si face un re-slew pe pozitia dorita, utilizatorul trebuie doar sa-i dea "start" ----------------------------------- jimao22 27 Aug 2013 23:08 ----------------------------------- Ai incercat Maxpoint-ul? http://www.cyanogen.com/point_main.php Nu, e pe bani si nu putini. Am alte prioritati ca sa termin observatorul anul asta. ce eroare ai dupa meridian flip? Mare... Ti-as da niste cifre dar de cateva zile e vreme rea si nu pot face teste ca sa va spun ce am descoperit in continuare. Programul se conecteaza la Maxim pt a face expunerea si la telescop prin Ascom pentru sincroniza si face un re-slew pe pozitia dorita, utilizatorul trebuie doar sa-i dea "start" Ideea e - Astrotortilla si astrometry.net pot fi apelate de un program de automatizare ca CCDAP sau CCDCommander sau ACP ?... Ca automatizarea presupune lipsa operatorului uman dupa ce i-ai dat start. ----------------------------------- Vlad 28 Aug 2013 00:11 ----------------------------------- in cazul meu, operatorul uman este musai. Nu stiu daca poate sa fie apelat de ccd autopilot... Insa daca programele acestea nu pot apela decat PinPoint in MaxDL, atunci poate fi o mare problema caci la cateva grade eroare...MaximDL se cam da de pereti si nu izbuteste sa rezolve. ----------------------------------- jimao22 06 Oct 2013 00:19 ----------------------------------- Am reinceput testele la observator pentru a incepe implementarea sistemelor automate. Deocamdata am instalat sistemul de alarma si linia de internet prin cablu (pana acum foloseam un modem wireless pentru comunicarea locala master-slave si modemul wireless din casa (care nu prea facea treaba din cauza peretilor metalici ai observatorului) pentru comunicarea cu internetul. Problemele vechi insa au ramas de rezolvat. Am un raspuns pentru Emil - am masurat eroarea dupa un meridian-flip si este in jur de 3 grade. Asta in conditiile in care de aceeasi parte a meridinului, practic erorile sunt infime (am aproape punct ochit-punct lovit). O alta observatie asupra comportamentului ciudat al softului (Maxim) in timpul achizitiilor: desi telescopul merge pe guiding si ramane practic "lipit" de steaua-ghid, pozitia telescopului din planetariul Maxim-ului pare ca are un drift usor. Nu e mare acest drift, dar practic intr-o jumatate de ora telescopul pare a iesi din cadrul pozei care apare pe planetariu dupa ultima sincronizare facuta. Asa incat ca sa-l aduc la ordine, mai fac din cand in cand cate o sincronizare noua. Nu stiu ce efect ar avea chestia asta lasata de capul ei pe termen lung. ----------------------------------- Vlad 06 Oct 2013 00:48 ----------------------------------- O alta observatie asupra comportamentului ciudat al softului (Maxim) in timpul achizitiilor: desi telescopul merge pe guiding si ramane practic "lipit" de steaua-ghid, pozitia telescopului din planetariul Maxim-ului pare ca are un drift usor. Nu e mare acest drift, dar practic intr-o jumatate de ora telescopul pare a iesi din cadrul pozei care apare pe planetariu dupa ultima sincronizare facuta. . Asta este destul de normal, si eu il vad la fel in CdC. Programul nu stie de eroarea ta de pol, stie doar ca pe masura ce ghidezi, tot misti axul DEC intr-o directie ceea pe care el o arata pe planetariu. Asta din cate stiu eu se intampla numai cand ghidezi prin Ascom, nu prin st4 - din cate am inteles (inca nu am verificat), cand ghidezi prin st4, EQMOD nu inregistreaza miscarile motorului - insa aici nu bag mana in foc ca e asa. ----------------------------------- Emil 06 Oct 2013 10:54 ----------------------------------- O varianta low-cost pentru un sensor de precipitatie. http://www.rainsensors.com/ ----------------------------------- achy1978 06 Oct 2013 10:59 ----------------------------------- In mod normal exista o eroare dupa meridian flip, insa nu de ordinul gradelor, ci mai repede de ordinul minutelor, care se reduc exponential dupa rezolvarea astrometrica. La mine eroarea dupa meridian flip nu depaseste 20 minute, ceea ce ma face sa cred ca exista probleme la sincronizarea pe stele intre planetariu si Eqmod. ----------------------------------- Vlad 06 Oct 2013 11:11 ----------------------------------- Proiectul SGL face atat focuserul (pe care l-am construit pentru mine) cat si un senzor de ploaie - din cate am inteles, integrat in ASCOM, ca sa poata fi folosit cu aplicatiile de rigoare ----------------------------------- jimao22 06 Oct 2013 13:41 ----------------------------------- O varianta low-cost pentru un sensor de precipitatie. http://www.rainsensors.com/ Multumesc frumos, Emil. Chiar ma gandesc serios ca trebuie sa incep sa strang echipment pentro o mica statie meteo (obligatorie). @achy - pana la urma ai folosit camera planetara (DFK-ul) ca si camera all-sky? Ce lentila ai folosit? De unde ai luat-o. Ma gandesc sa fac si eu ceva asemanator dar sa fie o chestie foarte usor reversibila (sau transformabila) astfel incat sa pot scoate usor camera planetara din dispozitiv si sa o pot folosi la poze planetare iar in restul timpului sa faca survey la cer. Ce soft de captura folosesti in acest caz? Despre eroarea de la meridian-flip vorbim mai pe larg la Lisa, cu montura si telescopul in fata, ca sa-ti arat cum fac eu sincronizarea pe stele. Cred si eu ca de aici apare eroarea... @Vlad - nu am vazut nimic despre vreun senzor de ploaie pe proiectul SGL. Imi poti arata mai exact unde e? ----------------------------------- mcuzic2002 06 Oct 2013 14:08 ----------------------------------- Apropo de " dificultate in relatiile cu familia ",aici cred cã fiecare dintre noi ne regãsim 8)...unele fraze le aud mereu,cum ar fi " la ora asta mergi singur in afara orasului ?!? " sau " cum naiba poate costa 1000 de ron un singur ocular? "...din 2008 sunt inscris pe lista de asteptare pt. un Astro-Physics 130mm EDF,o "jucãrie" de 6300 $...incã mai am mult de adunat in pusculitzã...cred cã pretul real al lunetei va rãmane "top secret" pt. familie,altfel risc sã dorm in cusca cainelui o perioadã bunã de timp :mrgreen: ----------------------------------- Emil 06 Oct 2013 16:22 ----------------------------------- Intr-un "mediu" automatizat, prezenta unei statii meteo este - dupa parerea mea - recomandata insa nu obligatorie. Obligatorie insa este prezenta unui element care poate detecta in timpul cel mai scurt posibil precipitatia indiferent ca este in forma solida sau lichida. De asemenea consider recomandata insa nu obligatorie citirea in domeniul IR al cerului pentru a determina gradul de acoperire. N.B. Orice sistem automatizat (indiferent ca vorbim de CCDAP, CCDCmd, MaxPilote) determina statutul "safe-unsafe" al observatorului prin stabilirea vlarii de acoperire a cerului. Inchiderea de urgenta se face atunci cand sensorul raporteaza prezenta umiditatii pe suprafata lui insa aici as atrage atentia asupra intarzierii rezultate deoarece pana la inchiderea totala a acoperisului pot aparea decalaje destul de mari (in functie de viteza de deplasare a acoperisului) iar, cand ne gandim la ploi torentiale care sunt frecvente pe perioada de vara, in acest caz cantitatea de precipitatie care "patrunde" in incinta poate fi destul de mare. Pentru a ma repeta putin (!) un senzor de precipitatie este obligatoriu insa ideal ar fi un senzor combinat precum cel de la Lunatico Astronomia sau SPACE Instruments care sunt cat de cat mai ieftine in caport cu cel de la Cyanogen de exemplu. ----------------------------------- nobody 06 Oct 2013 22:01 ----------------------------------- Ploile torentiale de vara sunt, in general, efecte ale cumulizarii rapide a umiditatii in nori cumulonimbus. Un fenomen violent care da nastere unei furtuni locale cu fulgerere de rigoare. Cred ca un sistem de detectie a fulgerelor poate da un avertisment preliminar ploii torentiale. Un senzor ieftin: http://www.tautic.com/as3935-lightning-sensor-development-boards-september-21-update ce se poate lega la Arduino: http://www.designspark.com/blog/detecting-lightning-with-an-arduino ----------------------------------- jimao22 06 Oct 2013 23:00 ----------------------------------- Super, nobody!. Merci frumos. ----------------------------------- nobody 07 Oct 2013 00:09 ----------------------------------- Cu placere. Doar o precizare: acest senzor nu inlocuieste ce a zis Emil Kolbert, ci il completeaza in sensul ca nu orice ploaie este neaparat insotita de descarcari electrice. ----------------------------------- achy1978 07 Oct 2013 09:12 ----------------------------------- Ca sa sustin ce a zis si Emil ... un senzor de precipitatii la un moment dat poate da gres ... din varii motive. Din punctul meu de vedere, dat fiind faptul ca sunt la o distanta de 40 km de observator, este obligatoriu o "statie meteo" care sa citeasca temperatura cerului in IR si poate crea o reactie inainte de aparitia precipitatie (poate crea status-ul de unsafe doar daca gradul de acoperire cu nori pe cer depaseste o anumita valoare). In plus ... procesul de automatizare este mult mai complex decat la prima vedere ... detalii la Lisa :) ----------------------------------- jimao22 19 Oct 2013 09:20 ----------------------------------- Sambata la ora 15, la Columna TV, o sa vedeti prezentarea lui Marian Achim (achy1978) despre automatizarea si controlul remote al observatorului si al telescopului sau. Este un bun punct de pornire pentru cei ce doresc sa faca asa ceva. Dupa ce o sa fie emisiunea, o sa facem cateva comentarii pe marginea celor vazute si a celor discutate in direct cu Marian la Lisa. ----------------------------------- jimao22 18 Noi 2013 23:08 ----------------------------------- Desi nu am mai postat de mult aici, am inceput sa lucrez la partea de automatizare plecand de la un mare ZERO in ceea ce priveste cunostiintele mele in domeniu. O mare importanta a avut intalnirea de la Lisa din toamna, unde intalnirea cu Marian a fost epica. In cateva zile am sa pun si un link aici (cum spuneam si in postarea anterioara) cu prezentarea lui Marian. El a reusit sa faca astfel incat lucrurile sa functioneze si nu pot decat sa-l felicit din toata inima pentru aceasta realizare. Am inteles abia acum cat de greu si important a fost pasul pe care l-a facut. Plecand de pe pozitii diferite (datorita lipsei de fonduri in ceea ce ma priveste), am fost nevoit sa gandesc schema automatizarii un pic diferit fata de Marian. Exista insa niste elemente de baza care trebuie sa (co)existe in cadrul acestei scheme:  Un computer, care este “creierul” intregului sistem – EXISTA  O sursa neintreruptibila de curent (UPS) care sa asigure supravietuirea sistemului in caz de avarie la sistemul de alimentare cu energie din exterior – EXISTA  Un alimentator stabilizat la 12 V cc pentru alimentarea majoritatii elementelor electronice ale sistemului astro (camere, montura, filtre, router, etc.) – EXISTA  Un MAIN controller care sa poata sa fie controlat via internet (fara a fi necesar un calculator deschis local pentru asta) si care sa controleze in principal cateva relee. Acesta controler este in cazul meu (dar si a lui Marian) un SELETEK Platypus - EXISTA  Cutia cu relee FIREFLY. Aici apar diferentele intre mine si Marian – el a avut la dispozitie un alt device de la LUNATICO ASTRONOMIA, care se cheama FIREFLY si care este de fapt o cutie cu 8 relee si cu niste intrari de la anumiti senzori ce se pot lega prin el, ce se poate controla cu SELETEK-ul printr-o interfata soft care se integreaza cu soft-ul SELETEK-ului. In cazul meu, folosesc o alta solutie: Platypus-ul are trei porturi seriale de iesire, numite MAIN, EXP si THIRD. Portul MAIN este folosit exclusiv de catre focuserul motorizat, dar celelelate porturi seriale pot fi folosite cu o schema simpla (aratata in atasament) sa actioneze pana la 3 relee fiecare – NU EXISTA  Montura telescopului (dar in subsidiar si celelalte dispozitive ale sistemului astro propriu-zis) – EXISTA  Motorul acoperisului – EXISTA  Un router pentru comunicatii externe via o retea ETERNET sau prin INTERNET – EXISTA  O statie meteo care sa dea semnalul de alarma in caz ca vremea se schimba pe parcursul unei sesiuni de observare/fotografiere – NU EXISTA ----------------------------------- jimao22 18 Noi 2013 23:23 ----------------------------------- Deci in lipsa unei statii meteo (care este circa 330 euro + 128 euro anemometrul pt. vant - la LUNATICO) si a FIREFLY-ului (care este si el 250 euro) a trebuit sa ma gandesc la o solutie alternativa. Si singura care mi-a venit in minte a fost cea care are la baza controlerele ARDUINO. Sistemul meu va ingloba doua astfel de controlere. Unul va fi nucleul unei statii meteo HOME-MADE, statie care va avea grija ca sistemul astronomic sa fie ferit de probleme in cazul schimbarii conditiilor atmosferice. Celalalt va controla tensiunea din retea si va verifica pozitia capacului de la acoperis, astfel incat acesta va avea grija ca sistemul astronomic sa fie ferit de probleme in cazul in care cade tensiunea de alimentare externa. Ambele controlere vor da comanda de inchidere a capacului observatorului (1), parcarea telescopului (2) si inchiderea calculatorului (3). ----------------------------------- jimao22 18 Noi 2013 23:28 ----------------------------------- O mica descriere in cuvinte a schemei-bloc, asa cum am gandit-o eu, este facuta in continuare. Tin sa subliniez ca totul este la nivel de draft si ca orice sugestie si idée este binevenita, intrucat cunostiintele mele in domeniu sunt minime (electronica / ARDUINO / automatizari / retelistica). Statia meteo bazata pe ARDUINO se bazeaza pe cativa senzori, figurati in desen.  - Cel mai important dintre ei (in opinia mea) este MLX 90614 ( http://www.melexis.com/Infrared-Thermometer-Sensors/Infrared-Thermometer-Sensors/MLX90614-615.aspx ) – un senzor de temperatura in IR, care va masura TEMPERATURA CERULUI (care nu este totuna cu temperatura ambianta). Am sa revin la acest sensor imediat.  - Al doilea sensor, aproape la fel de important ca si primul este chiar senzorul de temperatura, ca va masura TEMPERATURA AMBIANTA. Este vorba de un sensor combinat – DHT 22 ( http://www.robofun.ro/senzori/vreme/senzor_umiditate_temperatura_dht22 )  - Senzorul de lumina va sti cand este noapte sau zi si cand lumina Lunii este suficient de puternica incat sa nu poata fi facute poze in Luminanta de exemplu ( http://www.robofun.ro/senzori/lumina/senzor-lumina-precis-TSL235R )  - Senzorul de umiditate DHT 22 – este necesar pentru a calcula impreuna cu cel de temperatura aparitia punctului de roua,a stfel incat sa intre in functiune DEW-HEATERELE  - Senzorul de ploaie – este mai mult pentru a inregistra statistic perioadele ploioase – nu este de folos ca sa detecteze ploaia cand sistemul astronomic functioneaza – deja poate fi prea tarziu ca sa mai se salveze ceva intr-un asemenea caz (!!) Cum spuneam, senzorul IR masoara temperature cerului. Aceasta este INTOTDEAUNA negativa cand este senin, indiferent de temperatura ambianta. Am masurat cu o camera IR temperatura cerului SENIN intr-o noapte de iarna nu foarte friguroasa si am vazut ca era -60 grade C. Am mai discutat despre fenomenul asta aici pe forum, pentru cine vrea o mica introducere in problema. Daca cerul este innorat, temperatura cerului este foarte apropiata de cea a mediului. Depinzand de rezolutia si scara senzorului IR, se poate face evaluarea starii de nebulozitate a cerului fie masurand direct temparatura lui, fie facand diferenta intre temapratura cerului si cea a mediului ambiant. Al doilea controler ARDUINO are doi senzori magnetici, care detecteaza prezenta acoperisului rulant la unul din cele doua capete de cursa (e necesar lucrul asta in evaluarea ulterioara a starii sistemului – o sa vedeti de ce) si o alta intrare de semnal de la un releu alimentat direct de la retea (prin intermediul unui transformator, desigur) care sa ne dea starea alimentarii generale cu curent a intregului sistem. ----------------------------------- jimao22 18 Noi 2013 23:40 ----------------------------------- FUNCTIONAREA SISTEMULUI Pornite in permanenta vor fi UPS-ul, router-ul si SELETEK-ul. SELETEK-ul Platypus (spre deosebire de Armadillo) are o intrare de retea ETERNET si i se poate aloca o adresa in baza careia SELETEK-ul sa fie controlat de la distanta fara a fi necesara existenta vreunui calculator pornit local. Asta inseamna ca pot actiona de la distanta (via internet de exemplu) unul din releele legate la porturile EXP sau THIRD si care sa-mi porneasca calculatorul. Deci in acest fel pot porni de la distanta calculatorul si nu sunt nevoit sa il tin deschis tot timpul. Statia meteo (ARDUINO_1): - daca lumina > prag_1 - daca temp_IR > prag_2 - sau daca temp_IR - temp_amb. INCHIDE ACOPERIS - daca punctul de roua (dew-point) detectat } actioneaza RL-3 => PORNESTE DEW HEATER - daca statia meteo nu mai functioneaza (se verifica asta prin PING de cateva ori de la calculator catre ARDUINO – nu raspunde, inseamna ca statia nu mai merge) } actioneaza RL-2 => INCHIDE ACOPERIS ARDUINO_2: - verifica pozitie acoperis OPEN/CLOSE - daca pica curentul (semnal de la RL-4) si e OPEN } trimite info in calculator -> SELETEK-ul comanda RL-1 => INCHIDE ACOPERIS - daca pica curentul (semnal de la RL-4) si e CLOSE } porneste rutina care sa nu dea voie altui program sa deschida accidental acoperisul Mai trebuie luat in calcul un scenariu de WINDOWS cazut (calculator inghetat), caz in care am prevazut un alt releu conectat la butonul de reset al calculatorului si care trebuie sa fie actionat de catre SELETEK, inca nu stiu cum. In principiu, cam asta as vrea sa fac, cu posibile dezvoltari viitoare, functie de ce probleme mai gasesc pe parcurs. Am facut un curs de ARDUINO la Bucuresti acum o luna, ca sa inteleg un pic cu ce se mananca asta si mi-am luat deja un ARDUINO UNO/R3 si senzorii de care va spuneam deja, dar nu e suficient ca sa fac un sistem operational. Am multe de invatat si de experimentat si iarna o sa-mi dea putine sanse sa avansez in acest sens fiindca e greu de lucrat pe frig la electronica din observator. In fine, cam asta e. Sper ca nu am plictisit prea multa lume cu peroratia mea vis-a-vis de proiectul acesta si sper de asemenea sa si reusesc sa-l duc la bun sfarsit fiindca nu prea stiu cum sa-l incep... ----------------------------------- cmatei 19 Noi 2013 00:30 ----------------------------------- Daca-mi permiti o sugestie, pentru senzorul de lumina cauta TSL237, e mult mai sensibil (acelasi senzor e folosit si in SQM). Pentru scopul tau imediat probabil 235 e bun, dar cu senzorul mai sensibil ai putea evalua si callitatea cerului cand e intuneric de tot. Cam acelasi lucru am si eu in constructie, in mare aceiasi senzori (mai poti lega si unul de presiune atmosferica). Pentru detectia norilor pe langa senzorul IR o sa mai am si [url=http://www.noao.edu/staff/gillespie/projects/cloud-detector.html]un element peltier. Cum pari mai avansat decat mine, te rog sa dai detalii daca gasesti o solutie pentru montarea senzorului IR. Nu e foarte evident daca poate fi montat direct afara (daca e etans), si daca ii pui o fereastra risti sa masori temperatura ei nu a cerului. De asemenea, vezi ca sunt mai multe variante, cu FOV diferit - cel pe care-l gasesti la robofun e bun (90 grade, o singura zona, 3.3V, pentru ca ei nu zic). ----------------------------------- achy1978 19 Noi 2013 08:21 ----------------------------------- Bravo Cristi, Partea cu releul ce actioneaza butonul de reset al PC-ului cred ca o pot rezolva eu. Sa-mi spui care dintre relee il folosesti si de pe ce port. Mai trebuie sa imi spui timpul de asteptare al raspunsului de la PC inainte sa se inchida releul (cam minim 2 minute minim) Spor la treaba! ----------------------------------- jimao22 19 Noi 2013 09:36 ----------------------------------- Multumesc Marian, sunt sigur ca o sa ma ajuti cand o sa am nevoie. Nu am vrut sa te mai bat la cap in ultima vreme ca sa nu fiu agasant. Trebuie sa-mi gasesc si singur raspunsuri la niste intrebari ca altfel mor prost. Matei, uite aici o statie meteo cu senzorul asta, functionala - http://www.weather-above.com/skyirtemp.html . Cred ca si statia de la LUNATICO foloseste acelasi senzor. E sigurul senzor de acest tip pe care l-am gasit in cautarile mele, deci nu cred ca exista optiuni prea multe. Restul senzorilor sunt mari si extrem de scumpi, cu fereastra de germaniu (care e mai scump decat aurul) deci nu reprezinta o optiune. Fereastra cred ca se poate face (trebuie doar experimentat) din folie de solar sau din stretch - ambele sunt transparente pentru IR. Acum nu stiu CAT de transparente sunt, probabil ca o parte din spectru il filtreaza cumva. Pe de alta parte, nu cred ca sunt avansat in vreun fel - ma simt foarte neajutorat la momentul asta. ----------------------------------- Procyon 19 Noi 2013 10:12 ----------------------------------- De ce nu luati in considerare si o statie meteo INDI + Arduino ? http://indiduino.wordpress.com/2013/02/02/meteostation/ ----------------------------------- jimao22 19 Noi 2013 10:33 ----------------------------------- Foarte buna interventia ta, merci mult. Nu stiam de INDUINO asta. O sa-l studiez cu atentie. Ce imi trebuie si nu stiu cum sa fac este interfata (monitorul) grafica a statiei meteo - aici trebuie un programator care sa stie VB sau C++ sau alt limbaj d-asta obscen. Aceasta interfata trebuie nu numai sa-mi arate ce se intampla ci sa-mi permita sa dau si comenzi manuale daca vreau sa intervin peste programarea automata - de exemplu sa actionez releele manual, sau sa setez manual parametrii de lucru ai statiei meteo. De exemplu, (asa cum am vazut ca merge statia LUNATICO) exista niste "butoane" virtuale care permit selectarea anumitor parametrii de lucru. Poate ca vrei ca lumina excesiva sa nu fie un parametru care sa nu permita functionarea observatorului in regim automat fiindca vrei in acea zi sa faci teste pe timp de zi, deci dezactivezi manual senzorul de lumina si pragul sau nu mai este relavant pentru intreg sistemul. Ceva de genul asta... ----------------------------------- Procyon 19 Noi 2013 10:49 ----------------------------------- Pai, ca sa existe o interfata intre cele 2 trebuie sa foloseasca acelasi "limbaj". In primul rand trebuie modificat codul Arduino incat sa formeze o interfata cu un program VB.NET sau C++ care trebuie conceput de la 0. ----------------------------------- Emil 19 Noi 2013 12:28 ----------------------------------- Ca tot vorbiti de senzori, arduino si alte similare pun un link catre o pagina care o consider eu interesanta. http://www.phidgets.com/ Desigur exista foarte multe asemenea pagini (poate nu ar fi rau daca ati posta si voi furnizorii preferati). Emil ----------------------------------- CUBIX 22 Noi 2013 23:45 ----------------------------------- Cristi, ce zici de Rasberry PI + Arduino, pentru interfata web? http://www.makeuseof.com/tag/how-to-build-home-automation-system-raspberry-pi-and-arduino/ https://www.google.ro/search?q=raspberry+pi+arduino+web+interface Nu stiu daca se 'pupa' cu ce mai ai tu p-acolo, dar merita cercetat. Imi pare mai simplu decat, varianta cu programator si alte alea... Spor si cer senin, Vinturis G. ----------------------------------- Procyon 23 Noi 2013 02:38 ----------------------------------- CUBIX, in tutorialul pe care l-am precizat eu scria si de rPI pentru interfata, si totul fara programator and lalala... ----------------------------------- nobody 23 Noi 2013 11:37 ----------------------------------- Citez: The Arduino must have this code uploaded – I suggest you copy and paste to install this from a different computer. It’s essentially a listener program that responds to serial commands from the Pi, but there’s nothing to stop you extending it with your own features. Si, oricum, trebuie sa "programezi" si Raspberry Pi. Adica sa compilezi (cross compiling pentru platforma ARM), sa instalezi, sa configurezi Linux-ul de pe el si, eventual, sa modifici interfata web. Mai precis, mai lalalala decat lalala ... Avantajul unui microcontroler este fiabilitatea. Iar sistemul de protectie trebuie sa functioneze si daca pusca Windows-ul ori Linux-ul (da, crapa si asta, mai rar, dar cand o da in Kernel Panic, e pe bune). So, welcome to the LaLaLand ! ----------------------------------- Procyon 23 Noi 2013 12:21 ----------------------------------- Da nobody, dar codul sursa este pus pe tutorial si nu implica ca tu sa codezi ceva, ei bine poate doar sa instalezi linuxul pe rPI ----------------------------------- cmatei 23 Noi 2013 13:47 ----------------------------------- rpi-ul are doua probleme: una ca e prea lent ca sa se ocupe de tot, in special camere, deci tot ai nevoie de un PC, si a doua ca daca te atingi de GPU cam crapa (nu cu panic, dar suficient cat sa fie nevoie de reset). In fine ar mai fi si o a treia, viteza cu care broadcom repara bubele din mizeria de firmware pentru GPU (nedocumentat) tinde catre zero. Desi altfel e foarte stabil (l-am folosit la un prieten pentru controlul unei instalatii de incalzire cu panouri solare, etc), eu sunt mai ranchiunos si la controlul observatorului meu am sa zic pas la rpi. Nu vreau sa descurajez pe nimeni, rpi-ul e o chestie excelenta mai ales la banii aia, dar uneori lucrurile arata mai bine pe hartie decat in realitate. ----------------------------------- jimao22 14 Dec 2013 19:47 ----------------------------------- Intrucat sfarsitul de an a fost extraordinar de dur pentru mine pe plan profesional si nu mi-a mai ramas mult timp pentru alte lucruri, nu am mai evoluat deloc in sensul automatizarii efective, dar am facut totusi niste studii care pot fi utile unora, privind regimul termic al echipamentelor astronomice din observator pe timp de iarna, cu temperaturi mai mici de zero grade Celsius. Observatiile imi vor fi si mie de folos la momentul automatizarii fiindca o parte din echipamente vor trebui sa fie incalzite in mod automat la depasirea anumitor praguri de referinta, pentru a evita aparitia condensului pe celula corectoare/obiective pe de-o parte si pentru a evita defectiunile echipamentelor datorate frigului excesiv si al umiditatii pe de alta parte. Pentru a realiza aceasta, am folosit camera de termoviziune in infrarosu pe care o am (un FLIR Thermacam) ca sa fac cateva imagini cu echipamentul astronomic functionand in regim de lucru pe timp de iarna. Am avut la un moment dat un topic in care am aratat cum am rezolvat problema incalzirii unui laser verde ce are rol de finder pus pe telescopul meu, folosind o rezistenta de nichelina de resou si niste tub termocontractil - http://www.astronomy.ro/forum/viewtopic.php?p=105467#105467 . Folosind aceeasi idée, am facut elemente de incalzire pentru obiectivul lunetei de ghidaj si pentru celula corectoare a telescopului. Roua (si mai ales bruma) mi-au dat mult de furca in perioada asta, pierzand nopti bune de pozat cand era senin si eram si eu oarecum odihnit, asa ca am hotarat sa vad ce se intampla. ----------------------------------- jimao22 14 Dec 2013 19:50 ----------------------------------- Dar inainte de a va explica ce este in pozele astea, ar trebui sa va fac o mica introducere teoretica, pentru a intelege ca temperaturile indicate de camera nu sunt intotdeauna cele din realitate. Acest lucru se obtine facand o “procesare” a imaginilor avand in vedere o proprietate fizica a corpurilor (solide sau lichide) si care se cheama EMISIVITATE. Pe foarte scurt, orice corp expus radiatiei termice se supune unei ecuatii de echilibru termic, in care energia termica pe care corpul o primeste este egala cu suma energiei reflectate de corp impreuna cu cea emisa de corp in urma incalzirii sale. Ecuatia este ceva de genul 100% = x% + y%, x si y fiind coeficientii pentru energia reflectata si cea emisa. De exemplu, cu cat un corp este mai lucios (sa zicem o bucata de otel cromata) are primul coeficient mai mare (reflecta foarte mult din energia primita) si are al doilea coeficient mic, ceea ce face ca temperatura indicata de camera sa fie mult diferita de cea din realitate. Pe de alta parte, un corp “negru”, care absoarbe toata radiatia incidenta, fara sa reflecte nimic, are al doilea coeficient egal cu 1 (100%) iar in cazul sau, temperatura indicata de camera este exact cea reala. De aceea, in pozele de mai jos, anumite corpuri par a fi extreme de reci desi nu este asa. Suruburile cromate de la inelele de prindere ale telescopului, tubul telescopului (care este vopsit lucios) sau inelele de fixare ale finder-guider-ului care sunt din aluminiu nevopsit si destul de lucios, sunt astfel de corpuri, care apar mai reci decat sunt ele in realitate. Pe de alta parte, cablurile, tubul termocontractil sau motorul pas-cu-pas (care are o camasa de plastic negru deasupra) au temeratura indicata de camera exact ca cea din realitate (am mers cu coeficientul de emisivitate setat pe camera la 95%), acesta fiind si motivul pentru care am luat temperatura pe acest gen de corpuri. ----------------------------------- jimao22 14 Dec 2013 20:03 ----------------------------------- Am pozat tubului optic cu incalzitoarele aferente (a), monitorul cu cristale lichide al calculatorului din observator (b), UPS-ul (c), routerul wireless (d), montura in zona electronicii si a motoarelor (e), camera CCD (f), cerul (!!! – o sa explic un pic mai pe larg chestia asta - g), motorul acoperisului (h) si intreg ansamblul pilon-montura-tub optic (i). (a) – asa cum se vede din poze, desi am folosit aceleasi materiale pentru incalzitoarele de pe tubul optic, rezultatele sunt diferite, fiindca rezistentele respective incalzesc suprafete diferite ca extindere, astfel ca densitatea caldurii cedata de rezistenta per unitatea de suprafata este diferita. Asta este si motivul pentru care (desi diferentele de temperatura par neglijabile) nu am avut niciodata bruma sau roua pe finder-guider in schimb ce la corectorul newtonianului nu am scapat niciodata de acest fenomen daca acesta s-a produs. Despre laser am povestit totul in link-ul de mai sus asa ca cine vrea sa stie mai multe poate gasi informatiile acolo. (b) – monitorului i-am facut o “carcasa” din polistiren expandat (scartaietoare) care sa-l pazeasca de umiditatea ce cade in noptile umede si de lumina puternica ziua cand voi face observatii sau foto la soare. De asemenea, are rol de “caciulita” fiindca in spate am pus o rezistenta de 10W cu termostat, ce porneste cand temperatura scade sub 0 grade Celsius. Efectul se vede si cred ca e suficient sa asigure o functionare fara probleme in timp. (c) – UPS-ul are ventilator care porneste des vara si acum am inteles mai bine de ce. Chiar si iarna acesta porneste, deci nu am nevoie aici de incalzire suplimentara, singurul pericol aparent fiind cred umiditatea in exces. (d) – routerul merge non-stop si dupa cum se vede inauntrul sau se creaza un microclimat care sper sa nu duca la probleme legate de frig in timp. (e) – montura este facuta sa mearga la frig si se vede ca inauntru este caldut si bine, deci nu imi fac probleme aici (f) – camera CCD trebuie sa mearga la frig ca sa aiba zgomotul termic cat mai mic si e facuta sa mearga bine asa. Am facut poza doar ca sa vedeti cat de multa caldura este eliminata de elementul Peltier in timpul functionarii. (g) – cerul l-am pozat aici ca sa va arat ce am explicat si cu alte ocazii pe forum. In noptile senine, desi temperatura ambianta poate fi chiar pozitiva, temperatura cerului este MULT sub zero. Camera mea indica mai putin de -40 grade Celsius (asta fiind limita inferioara pentru ea) dar stiu de la altii cu camere mai performante ca temperatura cerului ajunge la -60…-65 grade. Asta e motivul pentru care obiectele expuse cerului liber face ca umezeala din aer sa condenseze pe ele. Roua sau bruma nu “cade” deci, ci este un efect colateral datorat radiatiei pierdute de corpurile respective in mod preferential catre zona cerului, care este mult mai rece decat alte zone inconjuratoare. Tot din acest motiv, se poate determina daca cerul este senin sau nu, prin calcularea diferentei intre temperatura ambianta si temperatura cerului (1) sau prin verificarea direct a temperaturii cerului, care trebuie sa fie muuuult sub zero grade. (h) – motorul este expus la frig si cred totusi ca un element de incalzire acolo i-ar face bine si lui dar probabil ca il voi monta la primavara sau la vara, cand ziua mai lunga o sa-mi permita interventii pe care sa le si termin pe parcursul unei zile. (i) – ultima poza este o poza de ansamblu, doar asa, de amorul artei, sa vad intreaga imagine de ansamblu in infrarosu. ----------------------------------- Erwin 14 Dec 2013 23:00 ----------------------------------- Foarte tare camera asta de termoviziune! :) Pentru a evita radiația către cer poți pune folie de polistiren subțire acoperit cu aluminiu pe părțile expuse la cer. Am găsit așa ceva la rolă de 0.5m lățime, (vândută pentru a izola pereții din spatele caloriferului ca să radieze căldura în cameră) și am făcut dew-shield din ea. ----------------------------------- H.E.Retic 16 Dec 2013 02:58 ----------------------------------- 'Neata, felicitari pentru constructie. Nice job :) Daca mai ai nevoie de statie meteo pe baza de arduino: http://sourceforge.net/projects/arduinoweather/files/ ar putea fi interesanta. Are cam toti senzori (nu are cloud detector) de care ai nevoie + logger. Are interfata in VB, la care exista sursa pentru eventuale modificari. Stii ce nu am vazut in schema de principiu prezentata? guider-ul... E off axis sau ai un guiding scope separat? Daca e off axis cum ai rezolvat problema cu meridian-flip-ul? C. ----------------------------------- jimao22 16 Dec 2013 11:02 ----------------------------------- In schema apare si guiderul, numai ca el nu are nimic de-a face cu automatizarea. Sistemul de autoghidaj este un sistem inchis, aparte de automatizarea observatorului si nu are nimic de-a face cu ea. Cand porneste calculatorul, camera de ghidaj porneste automat, deci nu trebuie sa-i fac nimic ca sa o introduc in sistem. Nu inteleg care este legatura intre off-axis-guider si meridian-flip... Daca ar fi o problema legata de meridian-flip (pe care insa am rezolvat-o) nu are legatura cu faptul ca guiderul e off-axis sau luneta de ghidaj. Din pozele atasate se vede ca e luneta de ghidaj (finder transformat in guider). Am si specificat pe undeva prin comentariile mele acest lucru, uita-te cu atentie. Multam pentru link, o sa ma uit cu atentie in minivacanta asta de iarna si poate o sa reusesc pana la sfarsit sa va arat ceva facut in acest sens. ----------------------------------- H.E.Retic 16 Dec 2013 11:28 ----------------------------------- La oag, cand faci meridian flip steaua de ghidaj se afla diametral opus, binenteles si directia DEC-ului. Ori se roteste guider-ul ori se cauta alta stea. Si, in functie de focala, e posibil sa nu gasesti o stea in campul respectiv. Daca e guider scope nu e nici o problema. Am vazut cautatorul, dar fara camera la capatul lui nu stiam daca e doar cautator sau guiding scope mai ales ca stiam ca lucrezi la un OAG. Mie mi s-a parut relevant, cand faci astfel de automatizari "the devil sits in the details". C. ----------------------------------- jimao22 16 Dec 2013 19:37 ----------------------------------- Da, acum inteleg. Asa e, detaliile fac diferenta, intr-adevar. Partea cu regasirea stelei de ghidaj ii va reveni programului de automatizare (in cazul meu - ACP, in cazul lui Marian Achim - MaxPilote). Nu am inceput sa fac teste cu ACP-ul din diverse motive, cum de asemenea nu am inceput sa fac teste cu FocusMax-ul in varianta automata, in care face singur focus pe o stea data din afara campului (facand pentru asta plate-solve). Am avut foarte putin timp la dispozitie si testele mananca mult timp si multa rabdare. ----------------------------------- jimao22 23 Dec 2013 21:36 ----------------------------------- L-am rugat pe Vali Grigore sa puna in arhiva Columna TV emisiunea in care Marian Achim (achy1978) a prezentat observatorul sau cu automatizarea facuta de el. Link-ul il aveti aici: http://www.columnatv.ro/tv/noi-si-cerul-19102013/ Va recomand (celor ce doresc sa isi automatizeze observatorul) sa va uitati la filmuletul asta cap-coada, este extraordinar de interesant ce a reusit Marian. Meritul lui este foarte mare, tinand cont de timpul scurt in care a facut tot si in care a reusit sa invete o multime de lucruri absolut noi, ca sa poata duce la bun sfarsit acest proiect. Nu pot decat sa-l felicit inca odata si pe calea asta! ----------------------------------- achy1978 24 Dec 2013 13:58 ----------------------------------- Multumesc Cristi pentru apreciere! ... sunt convins ca si tu o sa ajungi cel putin la acelasi rezultat :). Succes! ----------------------------------- jimao22 17 Ian 2014 02:29 ----------------------------------- Desi nu am mai scris demult ceva aici, lucrurile au evoluat, mai ales dupa Anul Nou. Am scris deja cata ceva pe blogul meu din semnatura de mai jos, dar am sa ma repet si aici, cumva ca sa fie informatia corecta si completa intr-un singur loc. Ajutorul lui Marian (achy1978) a fost esential, datorita lui fiind capabil sa ma folosesc de intreaga capabilitate a SELETEK-ului PLATYPUS in ce priveste adresabilitatea sa peste Ethernet. Intr-o sesiune remote de acum cateva zile, am reusit sa configuram IP-ul acestuia precum si routerele care formeaza reteaua mea locala, astfel incat sa pot accesa SELTEK-ul de la distanta (de pe orice calculator din reteaua locala momentan) si prin intermediul sau (el fiind un controler) sa actionez prin functia Pin-by-Pin, pana la 8 relee. Am zis ca momentan nu pot sa fac asta decat din reteaua locala fiindca felul in care sunt puse cele 2 routere nu permite maparea adresei de IP de la SELETEK peste primul router (in primul rand nu am IP fix acasa si in al doilea rand WAN-ul (world area network) nu e conectat direct la routerul din observator. Am facut 2 scheme ca sa intelegeti cum e acum si cum va trebui sa fie dupa ce fac si IP-ul fix de la furnizorul de internet. ----------------------------------- jimao22 17 Ian 2014 02:34 ----------------------------------- Cele 8 relee de care vorbeam mai devreme vor fi conectate la urmatoarele echipamente: - intrerupator general motor acoperis - comutator in impuls pentru deschidere acoperis - POWER calculator - RESTART calculator - o yala electromecanica pentru acoperis - panoul de flat-field - ventilator telescop - un releu (inca) liber Acestea sunt releele conectate la SELETEK. Nu trebuie uitate cele ce vor fi actionate de statia meteo si care au fost figurate in schema bloc a automatizarii cateva pagini mai inainte. Ce am mai facut cu ajutorul lui Marian, a fost ca el sa-mi scrie 2 scripturi in Visual Basic, ce pot fi mai apoi integrate in automatizarea ce are la baza SELETEK-ul. (1) Primul din ele imi produce secventa de deschidere a acoperisului – imi inchide un buton virtual din Pin-by-Pin (pinul 2) care actioneaza un releu ce da voie curentului sa ajunga la motorul acoperisului dupa care imi inchide in mod “impuls” un al doilea pin (pinul 3) care da semnalul de deschidere a acoperisului catre motorul de poarta de garaj. (2) Al doilea script face ceva in plus – in momentul apelarii sale (care acum se face prin dublu-clic, dar ulterior se va integra in sistemul care-l va apela automat in caz de necesitate) face prima data parcarea telescopului, asteapta 30 sec. ca acesta sa ajunga la locul de parcare, da impuls la pinul 3 sa inchida acoperisul, asteapta 35 de sec ca acesta sa se inchida si apoi inchide pinul 2 care e contactul general. Prin acest dublu-control se evita deschiderea accidentala a acoperisului atunci cand nu trebuie. In felul acesta, am ajuns foarte aproape de un punct important – actionarea acoperisului remote si controlul sau in caz de urgenta. Ce am facut azi a fost sa creez fizic primul grup de 4 relee pe care le-am introdus intr-o cutie, le-am legat la o mufa DB9 si apoi le-am legat la SELETEK, unde mai apoi le-am si probat – merg perfect (a) si am re-facut conexiunile de la motor astfel incat sa am posibilitatea sa deschid acoperisul si in mod manual, apasand pe butoane, faca ca SELETEK-ul sa fie activ sau pornit, atunci cand vreau sa fac teste sau atunci cand vreau sa deschid acoperisul fara ca sistemul sa fie pornit. Maine voi face legaturile intre relee si motorul acoperisului si practic partea asta va fi incheiata. Ramane sa cumpar relee si pentru al treilea port de comanda al SELETEK-ului (primul e folosit exclusiv pentru actionarea focuserului) si sa trag firele pana la dispozitivele enumerate inainte. ----------------------------------- jimao22 17 Ian 2014 02:36 ----------------------------------- Initializarea sistemului meu facuta de la distanta ar trebui sa mearga asa: (1) ma conectez la SELETEK remote prin reteaua locala (deocamdata) accesandu-i IP-ul; (2) din tabloul de comanda PinbyPin al SELETEK-ului pot actiona prin butoanele de pe ecran pana la 4 relee/port de iesire, deci in principiu 8 relee in total pentru cele doua porturi libere (al treilea fiind destinat exclusiv actionarii focuserului motorizat); (3) apas butonul virtual din PinbyPin care imi deschide acoperisul; (4) apas butonul virtual care-mi porneste calculatorul; (5) odata pornit calculatorul din observator, ma conectez la el via TeamViewer si pornesc MaxPilot-ul care imi comanda la randul sau toata suita de programe de achizitie/ orientare/ focusare pe cer (MaximDL, TheSky, FocusMax); (6) sistemul e complet functional si incep pozele, fara sa ma fi apropiat de el. ----------------------------------- jimao22 17 Ian 2014 02:38 ----------------------------------- Ce ramane de facut in continuare este statia meteo, unde pana acum nu am facut nimic mai mult decat aprovizionarea cu piese. Si nu din lene am stagnat ci fiindca imi era sila sa ma apuc sa invat limbajul de programare pentru ARDUINO (un fel de C++) fara sa am la dispozitie o lista clara de instructiuni, sintaxa limbajului, bibliotecile sale si altele. Sigur, ele exista pe net, dar ca sa scriu un program intr-un limbaj necunoscut si sa stau sa caut la fiecare virgula daca am facut bine sau nu, era demotivant pentru mine. Nu mai sunt tanar si nu mai am rabdare in primul rand sa fac asta, asa cum vad ca face de exemplu un nepot de-al meu care a ajuns un mic vrajitor in ARDUINO (si de care am sa ma folosesc la vremea potrivita). Numai ca acum am gasit solutia si aici – ATMEL Studio ( http://www.atmel.com/microsite/atmel_studio6 ) , un program free, caruia i se adauga ca si plug-in un alt program - ARDUINO IDE for Visual Studio ( http://www.visualmicro.com ). Este ceva ca de exemplu saltul de la MS-DOS la WINDOWS. Programele au la baza VISUAL STUDIO dar spre deosebire de acela, astea sunt gratuite (ambele) si reprezinta solutia la programare pentru mine. Programul pentru ARDUINO se editeaza in ATMEL iar toata baza de comenzi si biblioteci este in program. Daca incepi sa scri un cod, e suficient sa scri 2-3 litere si un pop-up menu iti indica ce variante ai, scrise corect si fara greseli de sintaxa (paranteze, virgule, etc). In plus, daca vrei sa schimbi numele unei variabile, o schimbi undeva si ea se modifica in tot programul. Daca o variabila o subliniezi cu mouse-ul, ai toate informatiile despre ea – unde a fost declarata, ce reprezinta, ce valori are, unde aste apelata – asa incat devine o joaca sa programez pentru ARDUINO. Sunt extrem de multe facilitati si acum sunt chiar foarte motivat sa incep sa lucrez. Aici ( http://www.youtube.com/playlist?list=PLFHYM4q-bAPEkuvRfzylO3BLUy5iCM15O ) sunt niste tutoriale foarte interesante pentru ce am povestit pana acum. ----------------------------------- Erwin 17 Ian 2014 02:44 ----------------------------------- Routerul din observator văd că este pus în LAN, trebuie configurat ca repeater ca să ai aceeași clasă de IP în amândouă. Nu știu dacă ai nevoie neapărat de IP static dela ISP (e scump), poți merge și pe dinamic, dacă router-ul tău din casă legat la WAN îl programezi să facă port forwarding (adresele pc-ului și seletek-ului le poți pune în DMZ). Toate routerele noi au posibilitatea de administrare dela distanță prin internet și dacă știi adresa IP e simplu de modificat când este cazul. Cel mai bine e să faci rost de un Linksys și să instalezi un firmware Tomato (e bazat pe linux) care îți permite configurarea routerului cum dorești. Dacă vin cei de la Romtelecom cu IP static îți bagă pe gât router-ul lor Cisco. ----------------------------------- CUBIX 17 Ian 2014 04:27 ----------------------------------- Felicitari pentru progrese! Nu stiu ce port foloseste SELETEK, dar sunt sigur ca vei avea ip-ul vizibil pe internet si unu singur, static sau dinamic. Iarasi daca in afara de tine mai trebuie sa stie vre-un soft/script ip-ul... La Romtelecom, era 1-2 euro/luna ip-u' static. Mai poti incerca noip.com, dyn.com/dns, etc... Ce fac astea? Iti ofera un subdomeniu, sau domeniu (daca doresti sa dai bani pe unu), 'legat' de ip-ul tau. Practic cu ajutorul unui program, ce verifica din pc-ul tau daca s-a schimbat ip-ul, si face propagarea DNS instant (aproape). In loc de ip, poti accesa observatorul print-un subdomeniu, ex: sfgeorgeobservatory.ddns.org:port_catre_SELETEK . Dezavantajul este ca trebuie sa ai un pc pornit si programul instalat, ca sa actualizezi ip-ul, nu tot timpul, dar cand nu merge stii ce sa faci... :D Spor! ----------------------------------- H.E.Retic 17 Ian 2014 10:57 ----------------------------------- Salut Cristi, cea de a doua schema poate sa-ti creeze neplaceri daca seletek-ul nu are nici un fel de securitate. In functie de primul ruter ai putea sa faci un VPN pe el si apoi sa actionezi ce vrei tu la nivel hardware. In felul asta scapi si de vizitatori nepoftiti si iti maresti si posibilitatea de a actiona remote diverse dispozitive atat din observator cat si din casa. Mai mult daca IP-ul este dinamic te poti folosi de un Dynamic DNS si ai scapat de orice problema de IP fix. Oricum nu conteaza provider-ul prea mult ci echipamentul cu care te conectezi la ei. In ceea ce priveste Arduino, exista un modul de ethernet care se potriveste atat la duo cat si la mega cu care poti inlocui inclusiv seletek-ul daca ii adaugi i extensie de relee. Ce spune Cubix nu e intru-totul adevarat in sensul faptului ca nu e nevoie de un calculator pornit. Routerele moderne stiu singure sa faca acest lucru. Daca te hotarasti la VPN iti recomand cu caldura Cisco RV120W. Encriptie/VPN/accelerator hardware IPsec/Firewall. Daca vrei mai multe detalii despre VPN spune-mi. @Erwin: Orice pui in DMZ trebuie sa aibe protectie pentru ca e expus direct in internet. Din punctul meu de vedere nu exista nimic mai bun decat un nat pentru protectie din exterior. C. PS: excelenta realizare! ----------------------------------- Erwin 17 Ian 2014 11:05 ----------------------------------- Da, ai dreptate, nu prea am folosit NAT, dar asta era la ce mă gândisem de fapt. ----------------------------------- jimao22 17 Ian 2014 11:25 ----------------------------------- Dragii mei, va multumesc pentru raspunsuri. Oricum, sugestiile voastre trebuiesc analizate de Marian care s-a ocupat de ce inseamna configurari la reteaua mea (eu sunt novice in domeniul asta). Stiu de modulele de ethernet pentru ARDUINO dar nu are nici un rost sa inlocuiesc SELETEK-ul cu ARDUINO cata vreme primul merge perfect, are interfata potrivita pentru comenzile si treaba pe care trebuie sa o faca si e un drum batatorit deja. Daca as fi plecat de la zero cu automatizarea (fara SELETEK) si as fi avut mai multa idee despre programari (VB, C++, d-astea), automatizari si retelistica, probabil asa as fi facut. Trebuie sa tineti cont insa ca la toate cele trei domenii de mai inainte am plecat de la linia de start si tot ce fac acum este sa invat din mers. Am pus aici toate ideile si pasii urmati fiindca sunt problemele cu care m-am intalnit eu in calitate de incepator si poate fi util si altora care vor sa faca ceva similar. Trebuie tinut cont de un lucru insa: fiecare proiect de acest gen este unic si problemele sunt diferite de la caz la caz. Fiecare are anumite componente hard, anumite cerinte, anumite restrictii si nu o sa intalnim 2 proiecte identice. ----------------------------------- Erwin 17 Ian 2014 11:36 ----------------------------------- Așa este, Cristi! Noi putem să chibițăm pe margine, fiecare cu experiența lui. Merci pentru link-urile cu Arduino, nici eu n-am făcut încă nimic cu el deși am instalat deja un IDE de programare free cu zeci de exemple... :) ----------------------------------- H.E.Retic 17 Ian 2014 11:44 ----------------------------------- Normal ca nu schimbi nimic acum, era doar o varianta de a mai adauga relee in plus pe partea de automatizare in functie de anumiti parametri. De ex sa inchida automat observatorul daca sesizeaza o temperatura mai mare a cerului (masurata de arduino) sau daca exista prezenta in zona (cu un PIR). Cerul e limita in ceea ce priveste posibilitatea de automatizare cu Arduino. C. ----------------------------------- jimao22 17 Ian 2014 12:17 ----------------------------------- Pai asta va face statia meteo, care are relee ce vor actiona la randul lor motorul acoperisului (sau probabil, mai bine cred - va apela rutina de inchidere de urgenta facuta de Marian). Vezidin nou schema de automatizare din pagina 3 a topicului. Cand am inceput treaba nu prea aveam idee cum o sa fac. Insa pe masura ce avansez, calea mi se deschide ca si cum as avea niste faruri in intuneric (ca sa folosesc o metafora). D-asta postez aici cam tot ce fac - sa am un jurnal al ideilor si problemelor prin care am trecut, sa fie o biblioteca de folosit si pentru altii si sa va cer sfatul sau sa va ascult opiniile (care sunt foarte bine venite) in incercarea de a gasi cea mai buna solutie. ----------------------------------- H.E.Retic 17 Ian 2014 12:32 ----------------------------------- Stiu, am vazut, eu incercam doar sa te fac sa mergi pe Arduino si sa nu arunci o palarie de bani pe cine stie ce minunatie :) C. ----------------------------------- achy1978 17 Ian 2014 13:14 ----------------------------------- Routerul din observator văd că este pus în LAN, trebuie configurat ca repeater ca să ai aceeași clasă de IP în amândouă. Nu știu dacă ai nevoie neapărat de IP static dela ISP (e scump), poți merge și pe dinamic, dacă router-ul tău din casă legat la WAN îl programezi să facă port forwarding (adresele pc-ului și seletek-ului le poți pune în DMZ). Toate routerele noi au posibilitatea de administrare dela distanță prin internet și dacă știi adresa IP e simplu de modificat când este cazul. Cel mai bine e să faci rost de un Linksys și să instalezi un firmware Tomato (e bazat pe linux) care îți permite configurarea routerului cum dorești. Dacă vin cei de la Romtelecom cu IP static îți bagă pe gât router-ul lor Cisco. Din experienta iti pot spune ca nu este asa ... Pe mine ma costa 1,5 EUR in plus pentru IP fix si merg cu acelasi router. In rest, nu este o optiune foarte buna utilizarea DMZ-ului pentru ca trebuie facut forwarding spre mai multe device-uri in functie de portul apelat. ----------------------------------- nobody 17 Ian 2014 17:50 ----------------------------------- Stati un pic, a doua schema nu are cum sa functioneze. De la provider primesti o singura adresa IP publica din clasa lui, indiferent ca-i statica sau dinamica. Nu mai poti folosi local alta adresa din acea clasa/bloc ci trebuie sa folosesti NAT intre LAN (privat) > WAN (public). Port forwarding este tot NAT dar pe destinatie si in sens invers WAN > LAN. Pentru DMZ ai nevoie de mai multe adrese publice, fapt care nu cred ca intra in discutie. NAT-ul normal asigura un anumit grad de protectie dinspre exterior, dar in caz de port forwarding sau chiar NAT pe UDP, s-a cam dus protectia. Cel mai bine este sa nu expui la Internet ceea ce nu este nevoie. O solutie de VPN se pote face cu OpenVPN care merge si pe Linksys. ----------------------------------- jimao22 17 Ian 2014 18:53 ----------------------------------- nobody are dreptate, am gresit un pic la schema a doua si abia acum am vazut si eu - linia de internet vine in WAN in routerul de la observator nu in LAN1. Am modificat schema si am uitat sa schimb si acolo. Scuze!... Edit: vad ca toti ati remarcat asta si eu nu am observat! Nu am cum sa modific schema azi ca programelul de grafica pe care-l folosesc are o cheie hard ce nu e la mine azi, dar o sa fac modificarea ulterior cand o sa mai pun cate ceva aici. Deci in principiu a inteles toata lumea - in a doua schema internetul intra in WAN-ul de la routerul din observator. ----------------------------------- achy1978 17 Ian 2014 20:00 ----------------------------------- @nobody - Asa este ... NAT este solutia de apelare diferentiata a device-urilor din WAN in LAN ----------------------------------- Erwin 17 Ian 2014 22:09 ----------------------------------- Am revenit și eu asupra DMZ mai sus, confundasem cu NAT-ul. Tomato pus pe Linksys e destul de simplu de utilizat și configurat, dar nu am făcut decât o singură dată chestia asta la un server și de atunci am uitat-o. Ăsta-i dezavantajul la Linux, merg prea mult timp fără să pui mâna pe ele și uiți... :) ----------------------------------- jimao22 17 Ian 2014 23:28 ----------------------------------- In seara asta, neavand pe nimeni prin preajma, am dat noroc cu mine insumi (stanga cu dreapta si dreapta cu stanga) pentru ca am facut si legaturile la motorul acoperisului de la cutia cu relee si totul a functionat perfect, conform planului. Mai mult, Marian mi-a facut configurarile in firewall si in router ca sa pot folosi Wake-on-Lan si acum pot porni si calculatorul prin retea, fara sa mai implic (deocamdata) si SELETEK-ul pentru asta. Asta inseamna ca teoretic pot porni totul fara sa am nevoie de SELETEK. Doar ca in astfel de automatizare, SELETEK-ul este cheia sigurantei, fiindca scriptul de inchidere automata merge prin el, chiar daca pornirea o fac mai domestic, prin Wake-on-Lan. Oricum, incepand de acum, am un sistem automat, chiar daca inca rudimentar. Va tin la curent... ----------------------------------- Erwin 18 Ian 2014 00:14 ----------------------------------- Bravo! Spor pe mai departe! Se pare că vremea caldă mai ține. Cer senin! ----------------------------------- jimao22 18 Ian 2014 15:39 ----------------------------------- Am patit o chestie despre care Marian m-a avertizat: dupa o perioada de 5-10 minute de la oprirea calculatorului comanda de WakeOnLan data prin retea nu mai merge. Am citit pe diverse forumuri (in scurtul timp avut la dispozitie) ca e chestie care se intampla destul de des numai ca nu am aflat si cauza/rezolvarea. Initial am crezut ca e din cauza ca s-au racit lampile din calculator, dar se pare ca trebuie sa umblu pe la niste setari (incerc sa ma dumiresc care). Dupa ce rezolv si asta, singura problema majora ramasa este statia meteo, catre care am sa ma concentrez cu toata forta in perioada care vine. ----------------------------------- nobody 18 Ian 2014 17:32 ----------------------------------- Cu ce metoda trimiteti pachetul de WoL ? Dupa simptome, pare a fi problema ca expira ARP cache (5-10 min pe Linux) iar pachetul (magic packet) nu este trimis pe broadcast, ci pe adresa calculatorului. In acest caz trebuie schimbat scriptul de pe router. ----------------------------------- jimao22 18 Ian 2014 18:24 ----------------------------------- Nu stiu ce se intelege prin "metoda", imi cer scuze pentru ignoranta. Fiindca eu ma simt de multe ori ignorant in anumite domenii pe care nu le stapanesc, atunci cand aflu o solutie, incerc sa explic altora cum as fi vrut sa-mi explice si mie cineva - ca la prosti. Ca practic asta suntem cu toti in anumite domenii pe care nu le stapanim (fara sa se supere nimeni, sper !). Deci, daca tot incercam cu totii sa lamurim subiectul "automatizare pentru toti", mi-ar place ca explicatiile si intrebarile sa fie pe intelesul tuturor, fara sa cadem in derizoriu, desigur. Deci, ca sa revin: am instalat pe telefonul cu Android WOL, am umblat in BIOS si am schimbat o setare intr-un TAB (ar trebui sa refac pasii ca sa spun exact care, fiindca nu-mi aduc aminte - oricum, am inteles ca diverse calculatoare au denumiri diferite pentru setarea respectiva, al meu nu facea referire la Wake on Lan in mod explicit in acea setare si am schimbat-o mai mult la plesneala), iar Marian a umblat la setarile firewal-ului si a routerului (cred), asa cum am mai spus. Cred ca el e in masura sa explice mai bine in acest caz. Dupa asta, am pus adresa MAC a calculatorului in WOL din Android, portul de acces si adresa IP si cam asta e. Apoi "click" pe WOL si se trimite Magic Packet. Cum se trimite, habar n-am. Pe cai numai de el stiute... ----------------------------------- nobody 18 Ian 2014 20:35 ----------------------------------- Daca ai pus adresa IP a calculatorului la setarile WoL atunci aia este problema. Adresa trebuie sa fie de cea de broadcast, altfel nu mai functioneaza dupa ce expira ARP cache, adica 5-10 minute. In cazul in care magic packet-ul se trimite indirect, adica nu de pe ruterul la care este legat calculatorul, mai trebuie facut un workaround deoarece broadcastul (directed broadcast) nu se ruteaza. Daca exista interes, pot intra in detalii. Dar explicatii simple la probleme complexe, mi-e teama ca nu exista decat eventual gresite. ----------------------------------- jimao22 18 Ian 2014 23:38 ----------------------------------- Interes exista, mult chiar. Lasa-ma sa ma dumiresc un pic si eu si o sa revin asupra subiectului. Acum am adresa fixa de IP (prima problema rezolvata), costa 1 euro+TVA/luna si se pare ca o sa schimb routerul primit gratis de la ROMTELECOM cu altul care sa poata fi configurat cum trebuie. Evident, totul in a doua schema (corectata) de legare a routerelor la net. Multumesc tuturor pentru suport si interes. ----------------------------------- H.E.Retic 19 Ian 2014 12:17 ----------------------------------- Nobody are dreptate! Wol functiuneaza la nivel de Layer2 din modelul OSI. Adica nu implica in nici un fel IP-ul echipamentului. Fiecare switch tine minte si invata unde se afla fiecare echipament atat timp cat acestea trimit frame-uri Layer2 (arp). Dupa ce aceasta inregistrare expira, packetul trebuie trimis numai pe broadcast. O parte mica din placa de retea sta si "asculta" packetele de broadcast-ul Layer2 din retea. Daca unul din packete ii este destinat(MAC-ului propriu) impreuna cu payload-ul necesar, placa porneste calculatorul. Daca packetul e trimis din interior-ul lan-ului atunci nu e nevoie de IP. Un workaround pentru trezirea din afara retelei este ca port-urile 7 si 9 udp sa fie forwardate catre broacast-ul clasei locale. Acum cand ai sa trimiti packet-ul trebuie sa pui ip-ul exterior si mac-ul pc-ul din interior. In felul asta packet-ul va fi "transformat" in broadcast de catre router pornind astfel calculatorul. Dar atentie WOL nu are nici un fel de autentificare, si creezi probleme in sistem. Scuze daca sunt putin paranoic in ceea ce priveste securitatea, dar in meseria mea lucrurile de genul asta sunt problematice. C. ----------------------------------- nobody 23 Ian 2014 04:04 ----------------------------------- Un curs despre "IP ARP, MAC Address Flooding & Learning" http://www.ine.com/all-access-pass/training/playlist/ccna-routing-switching-exam-course/ip-arp-mac-address-10022022.html ----------------------------------- jimao22 26 Feb 2014 22:36 ----------------------------------- Un mic update al incercarii mele de a automatiza un observator astronomic si a-l face accesibil remote. Problema Wake-on-Lan fiind pusa in stand-by pana o sa schimb routerele intre ele si o sa fac conexiunile cum se cuvine, am hotarat sa folosesc o metoda paralela de a porni calculatorul remote. Una din conditiile esential necesare ca sa initializez tot sistemul este ca si calculatorul sa fie pornit, asa ca am obtinut pornirea calculatorului punand un releu in paralel cu butonul de start al calculatorului. Releul este actionat de SELETEK, care asa cum am zis, are adresa de IP si poate fi actionat remote prin ethernet fara ca si calculatorul la care e conectat sa fie necesar a fi pornit. Un alt lucru facut a fost sa pornesc sursa de alimentare de 12V la care sunt conectate toate dispozitivele astro (montura, camera, roata de filtre, panoul de flat-field, sistemul anti-roua, etc) tot de la distanta, printr-un al patrulea releu. Lucrurile astea doua sunt teoretic simplu de facut, numai ca fiecare in parte mi-a luat efectiv o zi de munca. La sfarsitul acestora, am reusit sa pornesc calculatorul remote (1), sa deschid acoperisul (2) si sa pornesc toate dispozitivele electrice astronomice (3) fara sa ma misc din casa. Cu calculatorul deschis, ma conectez apoi cu TeamViewer si pornesc toata suita de softuri astro care-mi pune in miscare instalatia. La sfarsit opresc calculatorul din observator cu Shut-down tot din TeamViewer si inchid acoperisul si sursa de curent cu SELETEK-ul, tot asa cum le-am pornit. Desigur, una din conditiile necesare este ca SELETEK-ul sa fie alimentat separat in permanenta (dar tot prin UPS) si pentru asta am avut nevoie de un alimentator separat de 12V pentru el. Router-ul este de asemenea alimentat in permanenta, tot via UPS. Un mare castig pe care l-am descoperit la SELETEK PLATYPUS a fost ca pe langa faptul ca are adresa IP si un port in plus, portul THIRD permite conctarea a altor 4 pini ca si pini de INPUT (!). Acest lucru a facut ca al doilea ARDUINO din schema bloc originala sa devina de prisos, asa ca si schema bloc s-a schimbat dramatic. Schemele de conectare la pinii SELETEK si schema bloc a automatizarii s-au schimbat asa cum se vede in poza de mai jos.