In deel 1 hebben we kennis gemaakt met het INDI platform en deze geïnstalleerd. In deel 2 gaan we uit van deze eerdere setup en leren we het platform gebruiken in de praktijk.
De situatie: montering met de Raspberry PI en alle randapparatuur buitenshuis, controle middels KStars op de PC binnen.
Connecties
Middels KRDC kan verbinding worden gelegd met de Raspberry PI, hiervoor is uiteraard het IP-adres van de PI nodig welke je al hebt genoteerd alvorens alles op te zetten of welke je kan vinden via je router. KRDC start een kleine versie van de desktop van de PI op waarin vervolgens te werken is. Ik kies hier voor een remote desktop oplossing, omdat dit voor de meeste mensen wat duidelijker en dus eenvoudiger is. Er zijn echter snellere en meer directe manieren mogelijk om een PI te benaderen, hier ga ik nu echter niet op in.
KRDC start een desktop van de PI op waar een terminal al meteen beschikbaar is. Deze terminal gebruiken we om de INDI server te starten, commando’s hiervoor zijn te vinden in het eerste deel van deze reeks. De Pi heeft nu een connectie met alle randapparatuur en wacht op commando’s vanuit de INDI-client, in dit geval KStars op de PC binnen. In KStars kunnen we nu een aantal zaken gaan instellen.
Instellingen
De meeste instellingen hier zou ik laten voor wat ze zijn. De poort-nummers zijn de standaard nummers die, wanneer je ze niet ergens hebt aangepast, voor PHD 4400 en voor INDI zelf 7624 zijn. In mijn werkwijze gebruik ik PHD altijd op zichzelf staand voor drift-alignment, om dan met EKOS op de interne guiding verder te gaan. Dit doe ik omdat de interne guider mooi in het overzicht van de EKOS interface te zien is en vrijwel altijd volstaat.
Aan de slag
We starten EKOS op door op het icoontje hiervoor in de menu-bar te klikken en zien een eerste start-window.
In het plaatje staat het “simulator” profiel geselecteert, deze is bedoelt voor het testen van zaken wanneer je het geheel niet opgezet hebt, maar voor het echte remote werk selecteer je het “remote” profiel. In deze profielen staan de verschillende apparaten die je hebt gekoppelt en ook het IP-adres van de Raspberry. Door op het knopje links van het rode verwijder-icoontje te klikken kan je deze profielen inzien en aanpassen en met het plusje, je raadt het al, een nieuw profiel aanmaken. Als dit alles in orde is klik je op “Start INDI” en wordt de Raspberry PI benadert, waarna deze het INDI controle-paneel doorgeeft. Dit is iets om je altijd goed te realiseren, dit controle-paneel wordt opgemaakt door de Raspberry en diens INDI-server, niet door KStars zelf. Veranderingen die je dus hierin doorvoert, zijn veranderingen welke meteen in de Raspberry PI zelf (en de montering en randapparatuur) worden doorgevoerd.
Dit controle-paneel gebruik je om alle apparaten juist in te stellen. Wanneer deze instellingen goed staan, klik je op “Save” onder de “Options” tab van ieder apparaat. Zodoende kan je een volgende keer in het EKOS start-window op “Connect” klikken en worden alle apparaten met diens bewaarde instellingen meteen geladen. In de volgende voorbeelden gebruik ik een aantal simulators als apparaten, echter is het principe hetzelfde voor het echte werk.
In het CCD window (of GPhoto CCD voor DSLR’s) is het van belang de juiste resolutie instellingen aan te geven. In een normaal profiel staan hier ook nog zaken als pixel-grootte, ook dit is van belang goed te zetten aangezien deze waarden gebruikt zullen worden voor plate-solving. Nogmaals, klik op “Save” in het “Options” tabje om deze op te slaan.
In het Telescope window geef je zaken aan als aperture en focal length van de telescoop en die van de guider.
En zo ga je alle apparaten af welke in jouw setup aanwezig zijn.
Let goed op
Mijn setup kan soms last hebben van miscommunicatie tussen de PC binnen en de montering zelf. Soms gaat er tijdens het starten van INDI vanuit de PC iets niet helemaal goed en is opnieuw instellen nodig. Ik heb gemerkt dat in dat soort gevallen het beter is alles even te herstarten en ook de montering uit en weer aan te zetten (dit zorgt ervoor dat eventuele verkeerde instellingen gewist worden). De Pi is in de terminal te herstarten door het commando “sudo shutdown -r now“.
De montering moet uiteraard weten waar deze staat en dit check ik altijd door in KStars te kijken waar het rode kruisje naartoe wijst, de lokatie van dit kruisje is afkomstig van de montering en dus een goede indicator hiervoor. Het kruisje moet normaliter op de NCP (dichtbij Polaris) staan. Mocht dit kruisje ergens anders staan, wat mij ooit is overkomen, dan betekent dit dat de montering geen flauw idee heeft van de daadwerkelijke fysieke lokatie en kan zomaar ergens naartoe gaan bewegen met alle risico’s van dien. Als vervolgens alles goed staat en test-foto’s, volgen van een object e.d. geven geen problemen, dan blijft dit ook de hele nacht stabiel.
Ook van belang is de lokatie van de zogenaamde Park Position. Na een sessie plaats ik de montering terug in de beginstand, echter is het ook hier van belang dat de montering goed weet welke stand dat precies is. Ik neem altijd het zekere voor het onzekere en stel deze voor iedere sessie altijd in. Je unparked de montering en gaat via de tab “Site Management” naar “Park Options” en selecteert achtereenvolgens “Current” en “Write Data”.
Tijd voor imaging
Na ik met PHD een drift alignment heb uitgevoerd, ga ik over op het EKOS paneel in KStars. Om te beginnen met het focus gedeelte, hiervoor zet ik de telescoop op een heldere ster, stel ik een opname in van zo’n 10 seconden en klik ik op “Capture”. Nu is dit natuurlijk alleen nodig wanneer je arme sloeber als ik bent en manueel moet focussen, voor motor-focusers is het achterover leunen geblazen. Wanneer je manueel doorgaat dan krijg je een eerste foto te zien van de stand van zaken, je klikt heel precies op het midden van de uit focus zijnde ster en je doet een manuele aanpassing van de focus. Je neemt weer een foto, etc. Ik kijk altijd naar de “HFR” waarde en breng deze tot een zo klein mogelijk waarde, ook controleer ik (door flink in te zoomen op de ster) of ik spikes zie en of deze in focus zijn.
Vervolgens kies ik mijn object uit in KStars en selecteer ik deze met de rechter-muisknop, scroll naar beneden om de montering te kiezen en klik op “Track”. Hierna ga ik meteen terug naar het EKOS paneel en diens montering-overzicht met de muis op de “Abort” knop, mocht ik buiten iets fout zien gaan.
De montering is nu in de buurt van het object, maar niet precies en dus gaan we over op plate-solving. Dit doen we in het “alignment” overzicht van EKOS.
Hier gebruik ik voor mijn DSLR ook weer een opname van 10 seconden voor op ISO1600 en ik gebruik altijd de “Offline” solver zoals we die in deel 1 hebben ingesteld middels Astrometry. De online optie faalt voor mij 9 vd 10 keer omdat de server er nogal vaak uit ligt. Offline werkt uitstekend en wanneer je een aantal waarden in de “Options” aanpast, kan dit een solve geven binnen de 20 seconden. Doe je dit niet, dan moet je voor een eerste solve rekenen op zeker een minuut. Hierop volgende solves zullen vervolgens veel sneller gaan. Het solven stopt pas tot het object binnen de nauwkeurigheid valt welke je kan opgeven onder “Accuracy”.
We staan op het object, we zijn aan het tracken, tijd om de guiding in te schakelen.
Hier kies ik altijd voor een opnametijd van 3 seconden. Dit om storende elementen die de meting kunnen beinvloeden (zoals seeing) te verminderen. Ook zet ik “Binning” op 2. Wanneer je alles verder op “Auto” hebt staan, zal EKOS aan de hand van de foto een ster kiezen en hier meteen een kalibratie op beginnen. Hierna schakel je over op de “Guiding” tab en selecteer je “Start Autoguiding”. Meestal staan alle andere opties al goed, gaat het guiden hier volledig de mist in, dan is er een ander probleem (veel wind, probleem met montering etc.) welke meestal niet echt te beinvloeden is met de andere opties, die zijn er meer voor echte fine-tuning.
Wil je beginnen met de opnames, dan ga je naar het foto overzicht en stel je hier de nodige parameters in. Meestal maak ik eerst een test-foto van een 5 minuten om te bepalen of ik minder of meer tijd per sub nodig heb. Dit controleer ik dan meestal tussentijds even in PixInsight. Je stelt de naam in, hoeveel je er wilt maken en of het gaat om een “Light”, “Dark”, “Flat”, etc. Ik stel ook altijd een kleine “Delay” tijd in, dit omdat het vaak bleek dat na dithering, mijn DSLR al een foto begon te maken terwijl de montering nog net een kleine beweging maakte. Om dat soort eigenaardigheden op te vangen is die tijd heel fijn. Je klikt nog op de optie om de montering terug te zetten naar de Park positie (of niet, jouw keus) en klikt op het plusje. De “Job” is nu klaar voor de start.
Dit was een vrij eenvoudige manier van werken, in een volgend deel zal ik ingaan op het gebruik van de “Scheduler” welke veel zaken kan automatiseren tijdens een flinke nacht van activiteit terwijl je ligt te slapen en ook op de mogelijkheid tot het maken van automatische mozaieken.
Copyright © Vincent Groenewold (auteur) & © starry-night.nl 2016
Mooi artikel Vincent!
Mooie artikelen, Vincent. Het begint meteen te jeuken. Maar ik zou eigenlijk willen wachten tot de PI een USB 3.0 en een 1Gb netwerk interface krijgt voor respectievelijk camera en data transport. Indat geval zou ik er ook een willen inzetten als fileserver. Nu is dat veel te traag. Helaas heb ik begrepen dat die USB 3 er voorlopig zeker niet in zal zitten in verband met de kosten en moet ik een te zware server cintinue laten draaien voor file, web, time, mediastreamen etc.
maar, om te spelen en wat experimenteren moet ik er toch maar eens een aanschaffen….
Jos.
Dank je Jos! Klopt, dat is een nadeel van de PI. Het is natuurlijk ook een computertje welke voor educatie in de markt is gezet, kinderen die er meteen mee aan de slag kunnen en het ook nog eens van het eigen zakgeld kunnen betalen. Maar de technologie is de laatste jaren zo snel gegaan, dat voor deze lage prijs er toch nog heel wat rekenkracht uit te persen is en dus ook voor dit soort toepassingen best aantrekkelijk is. Snelheid, dat is iets waar ik nog geen aandacht aan heb besteed thuis, ik ben al wat blij dat ik overnacht sessies kan draaien zonder problemen (en voor nauwelijks, in verhouding tot ander spul, extra kosten). Voor deepsky opnames is ook niet zoveel nodig, enige puntje is dat ik na iedere opname van een aantal minuten, een seconde of 30 moet wachten tot deze op de PC binnen is. Ik zit dus al te denken aan een LAN verbinding ipv WiFi. Maar het werkt op zich allemaal heel mooi.
Overigens is een PI niet een vereiste, INDI draait ook op andere boards prima alleen heb ik daar geen ervaring mee.
Heb ooit eens aan kickstarter project Pine64 meegedaan, en nu bijna een jaar later heb ik voor de Fun eens Kstars geïnstalleerd, wat tot mijn verbazing vrij vlot liep (behalve gsc, dat heb ik manueel moeten doen want package klaagt over een issue met armhf en kreeg ik niet opgelost … ma goed)
Heb wat gespeeld met de simulator en vind het toch niet zo intuïtief … zeker het feit dat Sheduler met object los staat van de sequence, ik begrijp dat dat voor remote operation wel beter werkt qua planning, maar voor adhoc instellingen wijzigen tijdens dat opname loopt zit ik toch beetje gewrongen en denk ik dat het overall wel bij SGP ga houden (te meer dat ik nog geen driver heb gevonden voor 1 van mijn USB focussers …)
Maar het blijft kicken dat je op een quadcore 2 GB geheugen voor 29 dollar alles hebt draaien incluis platesolving …
Nu heb ik ook een Lattepanda 4GB (heeft USB3 met W10 er kan ook wel Linux op dacht ik), daar heb ik SGP op lopen, werkt wel maar vrees voor performance onder W10 dus toch ook maar eens een Voyo V1 met de nieuwe Apollo op de kop getikt, ik blijf steeds op zoek naar een mini/micro PC, voor de dag dat Laptop de geest geeft …
/Yves
Hoi Yves,
Dank voor je reactie! Het is inderdaad zo dat drivers e.d. nog lang niet kompleet genoeg zijn om ASCOM qua ondersteuning te benaderen. Je zal dus vantevoren moeten kijken of het uberhaupt wilt werken. SGP is voorlopig ook niet te verslaan, ik heb dit nu allebei als mogelijkheid draaien (2 virtuele machines met Windows en Linux). Dat is dus allemaal waar, echter blijkt Linux en KStars in mijn situatie (Wifi connectie, Raspberry) veel stabieler te werken. Met Windows heb ik veel meer problemen gehad, het werkt allemaal wel, maar het is duidelijk (ASCOM ook met name) niet gemaakt voor remote werk. Het gebruik van een simpele INDI server op de PI en de rest binnen is nog nooit vastgelopen of wat dan ook.
Dat gezegd hebbende, ik ben nu mijn hele netwerk aan het upgraden met gigabit ethernet. Een aansluting hiervoor komt ook buiten het huis. Het netwerk binnen is af en al meteen veel stabieler en sneller dan Wifi. Ik denk dus dat dit flink gaat helpen om SGP en Windows straks ook beter te laten lopen. Met behulp van een ander bordje (geen raspberry meer) kan ik ook veel meer, lokaal draaien van SGP of KStars is zelfs mogelijk. Het zal dus gaan afhangen van de ervaring gedurende een paar sessies. Mocht de stabiliteit en update-kuren van Windows toch frustreren, of alles is nog steeds niet stabiel genoeg, dan blijf ik bij Linux. SGP kan veel meer, maar de beste sessies tot nu toe waren met het eenvoudigere KStars. Overigens zit dit nog steeds in een flinke ontwikkeling, ik verwacht wel dat SGP in de toekomst benadert gaat worden.