domenica 15 marzo 2026

Cosmo - Le forze violente in gioco

Riflessioni · Il cosmo e noi

Non posso sentire il suono
di quell’esplosione.

Fuori piove. Sono alla mia scrivania, sto pubblicando gli articoli scritti in questi mesi — la mia guida personale all’astronomia, quella che condivido qui. E mentre sistemo i file, aggiungo i link, controllo i dettagli tecnici, mi viene un pensiero che non riesce a starsene fermo: posso osservare il cosmo, posso studiarlo, posso costruire strumenti sempre più raffinati per guardarlo. Ma non potrò mai sentire il suono di un’esplosione avvenuta a milioni di anni luce da qui.


Gli strumenti che costruiamo

Tutta la storia dell’astronomia è la storia di protesi. Occhi più grandi, più sensibili, capaci di vedere quello che l’occhio nudo non vede. Il telescopio di Galileo era una protesi. Il radiotelescopio di Jansky era una protesi. Il Vera Rubin Observatory — con il suo specchio da 8,4 metri e la camera da 3,2 gigapixel — è la più sofisticata protesi sensoriale che l’umanità abbia mai costruito per guardare il cielo.

E anche il mio piccolo setup — il 102 mm sul treppiede, la camera QHY, il Raspberry Pi che girerà KStars di notte — è una protesi. Piccola, umile, personale. Ma è della stessa famiglia del Vera Rubin. Appartiene allo stesso impulso: voglio vedere più lontano di quanto i miei occhi mi permettano.

Quello che questi strumenti hanno in comune è anche ciò che li limita tutti: raccolgono luce. Fotoni. Onde elettromagnetiche. Una piccola porzione dello spettro di ciò che l’universo emette. Il resto — la gravità, le onde gravitazionali, le particelle, l’energia oscura, la materia oscura — attraversa ogni strumento che abbiamo senza fermarsi, invisibile, irreggistrata, indifferente.


La violenza che non possiamo comprendere

Leggo di pulsar — stelle di neutroni che ruotano centinaia di volte al secondo, emettendo fasci di radiazione con la precisione di un orologio atomico impazzito. Alcune di queste stelle, per una questione di geometria cosmica del tutto casuale, puntano il loro fascio esattamente nella direzione della Terra. Noi le rileviamo come lampi regolari nel cielo radio. Li chiamiamo “segnali”, li misuriamo, li cataloghiamo.

Ma quella radiazione che FAST riceve e converte in un grafico su uno schermo — quella cosa tranquilla, quella curva su un monitor in un laboratorio nel Guizhou — è il residuo di un’esplosione che ha rilasciato più energia in pochi secondi di quanta il Sole ne emetterà in tutta la sua vita. La supernova che ha creato quella pulsar ha strappato via gli strati esterni della stella con velocità di decine di migliaia di chilometri al secondo. Ha illuminato la galassia. Ha fuso elementi che non esistevano prima. Ha creato condizioni di temperatura e pressione che non hanno equivalenti nella fisica quotidiana.

E noi la vediamo come un punto che lampeggia. La misuriamo. La classifichiamo. E pensiamo di capirla.


Le grandezze fisiche che sfuggono all’intuizione

Il problema non è la conoscenza. Il problema è la scala. L’universo è strutturato su grandezze fisiche che il cervello umano non riesce a interiorizzare davvero — può imparare a manipolarle matematicamente, ma non a sentirle.

Un raggio cosmico ultraenergetico — una singola particella subatomica che arriva dall’esterno della galassia con un’energia cinetica di decine di Joule — trasporta più energia di una palla da tennis lanciata a 100 km/h. Un’unica particella. Invisibile. Che attraversa la nostra atmosfera, che attraversa il tuo corpo in questo momento, che continua il suo viaggio senza che tu lo sappia o lo senta. Non sappiamo con certezza da dove venga. Non sappiamo cosa la abbia accelerata a quelle velocità.

Penso ai pianeti erranti — quei mondi espulsi dal loro sistema solare da qualche incontro gravitazionale catastrofico, che ora vagano nello spazio interstellare senza una stella. Masse paragonabili alla Terra o a Giove, che si muovono nell’oscurità assoluta, senza calore, senza luce. Quanti ce ne sono? Le stime dicono che potrebbero essere più numerosi delle stelle nella galassia. Mondi interi, nell’oscurità. E noi ne conosciamo pochissimi, scoperti per caso, per brevissime finestre osservative.

Penso alle stelle orfane — espulse dalle galassie dalle interazioni gravitazionali, che ora viaggiano nello spazio intergalattico a centinaia di chilometri al secondo. Penso agli oggetti interstellari che attraversano il sistema solare: ‘Oumuamua, Borisov. Due, in tutta la storia dell’astronomia moderna. Quanti altri sono passati senza che li vedessimo? Quanti passano adesso, troppo lontani, troppo bui, troppo veloci?


La roulette che non vediamo girare

Gli esperti dicono che le possibilità catastrofiche sono remote. “Remoto” è una parola che suona rassicurante finché non ci si ferma a pensare cosa significa nella scala temporale del cosmo. Remoto su scala umana è cent’anni. Remoto su scala geologica è un milione di anni. Su scala cosmica, “remoto” può significare un miliardo di anni. E in un miliardo di anni, le probabilità remote diventano certezze statistiche.

Un asteroide di grandi dimensioni si muove in orbita che sembra stabile. Ma la gravità di Giove, di Saturno, di piccoli corpi che si avvicinano in modo imprevisto può modificare quella traiettoria in secoli, in millenni. La roulette gravitazionale del sistema solare gira continuamente. ATLAS e Pan-STARRS ci danno qualche settimana di preavviso sugli impatti imminenti. Sul lungo periodo, siamo ancora fondamentalmente ciechi.

E poi ci sono le cose che non sappiamo di non sapere. Un oggetto massiccio che si avvicina dal piano galattico, troppo debole per essere rilevato finché non è già dentro il sistema solare. Una stella di neutroni solitaria — silenziosa, fredda, senza emissione radio — che si muove nella nostra direzione senza che nessuno strumento la veda arrivare. Non sono fantascienza: sono scenari fisicamente possibili, semplicemente improbabili su scala umana.

Quello che non possiamo vedere

La materia oscura costituisce circa il 27% dell’universo. L’energia oscura circa il 68%. Tutto ciò che osserviamo — stelle, galassie, nebulose, pianeti, noi stessi — è il 5% rimanente. Costruiamo strumenti sempre più sofisticati per guardare il cosmo, e guardiamo il 5% di quello che c’è. Del resto non sappiamo quasi nulla, tranne che esiste e che domina la dinamica di tutto ciò che vediamo.


Siamo certi di conoscere tutto? Di vedere tutto?

No. E chi dice il contrario non conosce la storia della scienza.

Ogni generazione di scienziati ha creduto di essere vicina a una comprensione completa. Alla fine del XIX secolo, la fisica sembrava quasi conclusa — mancavano solo “piccoli dettagli”. Quei piccoli dettagli erano la relatività e la meccanica quantistica. A metà del XX secolo, sembrava che la struttura fondamentale della materia fosse compresa. Poi arrivó la materia oscura. Poi l’energia oscura. Poi le onde gravitazionali — una forma di “suono” del cosmo che nessuno aveva mai rilevato direttamente prima del 2015.

Ogni volta che costruiamo uno strumento capace di vedere in un modo nuovo, troviamo qualcosa che non sapevamo che esistesse. Il cielo radio era sconosciuto prima degli anni ’30. I raggi X cosmici prima degli anni ’60. I gamma-ray burst prima degli anni ’70. I Fast Radio Burst — lampi radio extragalattici di energia enorme e origine ancora misteriosa — sono stati scoperti nel 2007 analizzando dati di archivio. Erano lì da sempre. Nessuno li aveva cercati perché nessuno immaginava che potessero esistere.

Cosa non stiamo cercando adesso, semplicemente perché non immaginiamo che esista?


L’insignificanza come punto di partenza

Fuori piove ancora. Sul tavolo ho il manuale del mio telescopio, i cavi del Raspberry Pi, le note su come configurare PHD2. Tra qualche mese avrò la montatura, e potrò finalmente uscire la notte e puntare verso Saturno, verso Giove, verso la Nebulosa di Orione.

E mentre costruisco questo piccolo setup, mentre scrivo queste guide, mentre imparo ogni dettaglio tecnico di ogni singolo componente — sono profondamente consapevole di quanto sia piccolo tutto questo. Non nel senso che sia inutile. Nel senso esatto: piccolo. Una persona, un telescopio, un angolo di cielo.

L’universo ha 13,8 miliardi di anni (forse). Contiene almeno due trilioni di galassie. La Via Lattea da sola contiene tra 100 e 400 miliardi di stelle. Il Sole è una stella di media dimensione, a metà del suo ciclo di vita, in un braccio spirale periferico di una galassia ordinaria. La Terra è il terzo pianeta di questa stella ordinaria. Io sono uno degli otto miliardi di esseri umani che abitano questo pianeta in questo preciso momento della sua storia.

Questa non è una considerazione deprimente. È la premessa più onesta da cui partire.


Il significato nel mezzo del mistero

Non posso sentire il suono di quell’esplosione. Non posso percepire l’energia di un raggio cosmico ultraenergetico che mi attraversa. Non posso immaginare davvero cosa significhi una pulsar che ruota 700 volte al secondo, o una stella di neutroni dove un cucchiaino di materia pesa miliardi di tonnellate, o un buco nero dove il tempo si ferma.

Ma posso raccogliere la luce. Posso misurare la posizione di una stella con una precisione di frazioni di arcosecondo. Posso fotografare una galassia a 50 milioni di anni luce e vedere, nei pixel di quella immagine, i bracci a spirale formati da miliardi di stelle. Posso capire — almeno in parte, almeno per il tempo che ho — come funziona questo universo che non può fermarsi a spiegarsi.

Il cosmo è violento, indifferente, stupefacente. È pieno di cose che non sappiamo, di scale che non riusciamo a sentire, di eventi che nessuno vedrà mai. Ma è anche leggibile — almeno in parte, almeno attraverso gli strumenti fragili che riusciamo a costruire. E quella leggibilità parziale, quella finestra aperta sul mistero, è tutto ciò che abbiamo.

E in un pomeriggio di pioggia, alla scrivania, mentre pubblico articoli tecnici su oculari e motori passo-passo e sensori CMOS — mi sembra abbastanza.


Un blog che guarda in su

Deep Sky Lab è una guida tecnica all’astronomia amatoriale. Ma è anche questo: il tentativo di una persona di trovare il suo posto in qualcosa di enormemente più grande. Le guide sugli oculari e le tabelle dei sensori e i tutorial su PHD2 non sono fini a se stesse. Sono il modo concreto, pratico, imperfetto di avvicinarsi a qualcosa che non si può toccare direttamente.

Se sei arrivato fin qui, probabilmente sai già di cosa sto parlando. Lo sai da quella volta che hai alzato gli occhi e hai visto Saturno per la prima volta in un oculare. Oppure dalla volta che hai finito lo stack di una nebulosa alle tre di notte e hai guardato lo schermo in silenzio per qualche secondo prima di riuscire a dire qualcosa.

Il cosmo non ci aspetta. Ma noi possiamo guardarlo.

GoTo - Confronto tra sistemi

Montature · Confronto sistemi GoTo

Nebula GoTo o SynScan?
Stessa fisica, software diverso — cosa cambia davvero.

Il Bresser EXOS-2 con sistema Nebula GoTo e lo Sky-Watcher HEQ5 Pro con SynScan costano cifre simili, fanno la stessa cosa in apparenza, e usano gli stessi principi fisici. Eppure sono due strumenti profondamente diversi nel modo in cui si usano, si configurano e si integrano con il software. Questo articolo spiega esattamente dove sono uguali — e dove no.


Quello che è identico: la fisica

Partiamo dal fondamento. Entrambi i sistemi risolvono lo stesso problema fisico con gli stessi strumenti: motori passo-passo che muovono la montatura sugli assi RA e DEC, una vite senza fine che trasmette il movimento con alta riduzione, un database di coordinate celesti, una procedura di allineamento su stelle di riferimento. I principi non cambiano.

  • Entrambi usano motori passo-passo ibridi da 1,8 °/passo con microstepping
  • Entrambi richiedono allineamento polare come prerequisito
  • Entrambi eseguono calibrazione su 1, 2 o 3 stelle per costruire il modello di correzione
  • Entrambi contengono un database con Messier, NGC, IC, pianeti, stelle doppie
  • Entrambi supportano autoguida via porta ST-4 o USB
  • Entrambi si connettono a NINA e KStars/EKOS via driver standard

Se impari la logica del GoTo su uno dei due sistemi, la trasferisci all’altro senza difficoltà. La sequenza è sempre la stessa: allineamento polare → calibrazione su stelle → puntamento automatico → tracking.


La differenza fondamentale: il cervello del sistema

Qui i due sistemi divergono in modo sostanziale. È una differenza di architettura, non di prestazioni.

Il SynScan di Sky-Watcher è un sistema chiuso: un controller dedicato con microprocessore proprietario, tastierino fisico, display LCD e firmware aggiornabile tramite Sky-Watcher. Il controller è il cervello e l’interfaccia insieme. Per collegarlo a un PC serve un cavo USB seriale oppure il modulo WiFi esterno SynScan Pro — un accessorio venduto separatamente.

Il Nebula GoTo di Bresser è un sistema aperto: il cervello è un Raspberry Pi integrato nella montatura, con sistema operativo Linux. L’interfaccia è una web application accessibile da qualsiasi browser su qualsiasi dispositivo connesso alla stessa rete. Non esiste un handbox fisico — il controllo avviene sempre via schermo, che sia uno smartphone, un tablet o un PC.

Due filosofie di progetto

Sky-Watcher ha costruito un sistema che funziona in modo autonomo e completo senza dipendere da dispositivi esterni. Bresser ha scelto di integrare un computer general-purpose che delega l’interfaccia a dispositivi già presenti nella borsa di ogni osservatore. Nessuna delle due è migliore in assoluto — dipende da come lavori sul campo.


L’interfaccia utente: handbox vs webapp

In campo, di notte, con guanti e torcia rossa, la differenza tra i due sistemi si sente immediatamente.

SynScan: il controller fisico

Il handbox SynScan ha una tastiera numerica, tasti direzionali, tasti funzione e un display LCD. È autonomo: funziona anche senza smartphone, senza WiFi, senza nessun altro dispositivo. La navigazione nei menu avviene con i tasti fisici — lenta ma affidabile, senza problemi di luminosità dello schermo, senza batteria del telefono da preservare. Per chi preferisce il controllo diretto senza dipendenze tecnologiche, è una comodità reale.

Lo svantaggio: il display è piccolo, i menu sono navigabili solo sequenzialmente, l’aggiornamento del firmware è manuale e richiede un PC con software dedicato. L’app SynScan Pro per smartphone è disponibile gratuitamente ma richiede il modulo WiFi esterno (costo aggiuntivo ~50–80 €).

Nebula GoTo: la webapp nel browser

Il Nebula GoTo crea automaticamente una rete WiFi propria (hotspot) con password predefinita AVgotosys. Qualsiasi dispositivo connesso a quella rete può accedere all’interfaccia digitando 10.0.0.2 nel browser. L’interfaccia è grafica, moderna, navigabile con un dito su schermo touch. È incluso nel prezzo della montatura, senza accessori aggiuntivi.

Lo svantaggio: dipendi da un dispositivo con schermo. Se il telefono ha poca batteria, se lo schermo non si vede bene in certe condizioni di luce, se la connessione WiFi va in timeout, l’interfaccia non è disponibile. In alternativa si può collegare il Nebula GoTo al router di casa via Ethernet — in quel caso il sistema assume un IP fisso (192.168.1.28) accessibile da qualsiasi device sulla rete locale.


La connessione al PC: protocolli e driver

Questo è il punto più rilevante per chi vuole usare NINA o KStars/EKOS per l’astrofotografia automatizzata. Le differenze qui sono concrete e influenzano il tempo di setup.

SynScan: driver maturo, community enorme

Il driver ASCOM SynScan è disponibile da anni, aggiornato regolarmente, testato da decine di migliaia di utenti. Su Windows con NINA funziona out-of-the-box: installi il driver, selezioni SynScan nel menu montatura di NINA, connetti. Su Linux con KStars/EKOS il driver INDI SynScan è incluso nella distribuzione standard di indi-bin. La documentazione è vastissima: qualsiasi problema tu incontri, qualcuno l’ha già risolto su Cloudy Nights, sul forum di Sky-Watcher o su YouTube.

Nebula GoTo: più moderno, meno documentato

Il Nebula GoTo si connette a NINA tramite il driver Avalon UD via protocollo Alpaca. La procedura, come documentata nel supplemento ufficiale Bresser, richiede un passaggio manuale non immediato: bisogna prima selezionare il driver in un software esterno (Stellarium, Carte du Ciel) per renderlo disponibile nell’ASCOM Chooser di NINA. Una volta fatto — anche una sola volta — il driver rimane disponibile nelle sessioni successive.

Con KStars/EKOS il Nebula GoTo si comporta bene grazie all’integrazione INDI nativa del Raspberry Pi. È la combinazione più fluida: entrambi girano su Linux, parlano lo stesso protocollo, e il supplemento ufficiale di Bresser descrive la procedura completa di allineamento polare via EKOS — incluso il metodo a tre rotazioni senza bisogno del cannocchiale polare.

⚠ Primo setup Nebula GoTo con NINA: il passaggio che blocca

Il supplemento ufficiale Bresser avverte esplicitamente: la prima selezione del driver Avalon UD non può essere fatta direttamente da NINA, perché NINA non lancia l’ASCOM Chooser dalla sezione montatura. Bisogna aprire un software esterno (es. Carte du Ciel, Stellarium), abilitare la Alpaca Discovery, aspettare che il driver venga trovato automaticamente, selezionarlo, e poi tornare in NINA dove il driver sarà disponibile. Una volta fatto funziona senza problemi — ma è un passaggio che non è documentato nei tutorial generici di NINA.


Il confronto completo

Aspetto Bresser EXOS-2 Nebula GoTo Sky-Watcher HEQ5 Pro SynScan
Fisica del sistema Identica Identica
Portata fotografica ~6–7 kg (conservativo) ~10–12 kg (conservativo)
Errore periodico dichiarato ±20–30″ ±10″
Controller fisico Non incluso (webapp) Handbox incluso
Interfaccia Web app moderna, touch-friendly Tastierino fisico, display LCD
Autonomia senza dispositivi Dipende da smartphone/tablet Completamente autonomo
Connessione WiFi integrata Sì — inclusa, hotspot nativo No — modulo esterno (~50–80 €)
Driver ASCOM/NINA Avalon UD via Alpaca (setup manuale) Driver diretto, plug&play
Driver INDI/KStars Nativo (entrambi Linux) Driver INDI stabile e documentato
Allineamento polare digitale EKOS 3-stelle senza cannocchiale All-Star via SynScan o EKOS
Community e supporto Limitata, documentazione ridotta Enorme, vent’anni di materiali
Aggiornabilità firmware Flessibile (OS Linux) Dipende da Sky-Watcher
Prezzo indicativo ~850–1.000 € ~1.100–1.300 €

Dove convergono: il livello del software

C’è un punto in cui le differenze quasi scompaiono: quando entrambe le montature sono collegate a NINA o KStars/EKOS. A quel livello, il software non “vede” la differenza tra Nebula GoTo e SynScan — vede una montatura equatoriale che risponde a comandi GOTO, che restituisce la posizione corrente, che accetta correzioni di guida. Le funzionalità avanzate — sequenze automatizzate, meridian flip, plate solving, allineamento polare digitale — sono disponibili su entrambi i sistemi.

Questo è il motivo per cui la scelta tra i due sistemi dipende più da come arrivi a quel livello che da cosa fai quando ci sei arrivato.


Chi dovrebbe scegliere cosa

Profilo Consiglio Perché
Principiante, primo GoTo SynScan Community enorme, problemi già documentati, handbox autonomo
Già usa Linux/Raspberry Pi Nebula GoTo Integrazione naturale, ecosistema coerente, nessun acquisto aggiuntivo
Vuole WiFi senza accessori extra Nebula GoTo WiFi integrato, nessun modulo aggiuntivo da comprare
Vuole usare NINA su Windows SynScan Driver diretto, zero problemi di configurazione
Vuole usare KStars/EKOS su RPi Nebula GoTo Entrambi Linux, integrazione INDI nativa, supplemento ufficiale disponibile
Osservazione visuale pura SynScan Handbox autonomo, nessuna dipendenza da dispositivi aggiuntivi
Budget più contenuto Nebula GoTo WiFi già incluso, prezzo leggermente inferiore
Portata > 8 kg OTA HEQ5 Pro SynScan Portata fotografica superiore, meccanica più robusta
Il caso specifico: EXOS-2 Nebula GoTo + Raspberry Pi 5

Se stai costruendo un setup con Raspberry Pi 5 come cervello di controllo (KStars/EKOS, PHD2, camera guida), il Nebula GoTo è la scelta più coerente. Entrambi i sistemi parlano Linux, il protocollo INDI è nativo su entrambi, e il supplemento ufficiale Bresser documenta esattamente la procedura di connessione e allineamento polare via EKOS. Non devi comprare moduli WiFi aggiuntivi, non devi installare driver ASCOM su Windows, non devi gestire la compatibilità tra sistemi operativi diversi.


Una nota onesta sul Nebula GoTo

Il Nebula GoTo è un sistema più giovane del SynScan. Questo ha conseguenze pratiche: la documentazione è meno abbondante, i tutorial in italiano sono quasi inesistenti, i forum di supporto sono meno frequentati. Bresser ha prodotto una serie di supplementi ufficiali in inglese (connessione PC, NINA, KStars/EKOS, allineamento polare) che sono precisi e ben fatti — ma sono in inglese e non sempre facili da trovare.

Se incontri un problema con il SynScan, ci sono probabilmente 50 thread su Cloudy Nights con la soluzione. Se incontri un problema con il Nebula GoTo, potresti trovarti a dover risolvere da solo. Per chi ha dimestichezza con Linux e preferisce un sistema aperto, è un tradeoff accettabile. Per chi vuole la certezza di trovare aiuto in italiano in cinque minuti, il SynScan è la scelta più sicura.


La risposta alla domanda

Sono uguali nella fisica — motori, vite senza fine, allineamento polare, database, GoTo. Sono diversi nell’interfaccia, nell’architettura software, nella portata e nella community. A livello di software avanzato (NINA, KStars/EKOS) la differenza si riduce quasi a zero.

La scelta giusta dipende dal tuo contesto: se sei già nel mondo Linux e Raspberry Pi, il Nebula GoTo è più coerente. Se vuoi la strada più documentata e la portata maggiore, l’HEQ5 Pro SynScan è lo standard di riferimento.


GoTo!

Montature · Guida tecnica

Premi GO TO e il telescopio si muove.
Ma come fa a sapere dove puntare?

Digiti “M42” sul controller, premi GO TO, e dopo qualche secondo la Nebulosa di Orione appare nel campo visivo. Sembra magia. Non lo è. Dietro quel movimento ci sono motori passo-passo, encoder, un modello matematico della sfera celeste e una procedura di calibrazione che insegna alla montatura dove si trova nel mondo. Capire come funziona davvero — non solo come usarlo — è la differenza tra un operatore e qualcuno che sa cosa sta facendo.


Il problema di base: la Terra gira

Ogni sistema GoTo deve risolvere un problema fondamentale: la Terra ruota su se stessa, e questo fa sembrare che tutto il cielo si muova attorno a noi. Una stella che è a Est all’inizio della notte è a Sud a mezzanotte e tramonta a Ovest all’alba. Per puntare un oggetto celeste, la montatura deve sapere non solo dove si trova quell’oggetto in cielo, ma anche dove si trova adesso — tenendo conto dell’ora, della data e della posizione geografica dell’osservatore.

La soluzione adottata da tutte le montature equatoriali è elegante: allineare l’asse di rotazione principale (asse RA) con l’asse di rotazione della Terra. Quando questo è fatto correttamente, basta ruotare la montatura attorno a quell’asse — alla stessa velocità della Terra ma in senso contrario — per mantenere qualsiasi oggetto fisso nel campo visivo. È il tracking siderale, e è il principio su cui si basa tutto il resto.


I motori passo-passo: il muscolo del sistema

Le montature GoTo amatoriali usano quasi universalmente motori passo-passo ibridi (hybrid stepper motor). A differenza di un motore comune che ruota in modo continuo, un motore passo-passo si muove di angoli precisi e discreti — i “passi” — ogni volta che riceve un impulso elettrico. L’HEQ5-R Pro di Sky-Watcher, per esempio, monta motori passo-passo da 1,8 ° per passo su entrambi gli assi.

Un motore da 1,8 ° per passo ha 200 passi per giro completo (360 ° ÷ 1,8 ° = 200). Ma 200 passi per giro sarebbero troppo grossolani per un’applicazione astronomica. La soluzione è il microstepping: il controller divide ogni passo fisico in frazioni, alimentando i due avvolgimenti del motore con correnti proporzionali. Si ottengono così movimenti di 1/8, 1/16 o 1/256 di passo — una risoluzione angolare molto superiore.

Calcolo della risoluzione angolare — HEQ5-R Pro

L’HEQ5-R Pro usa motori da 1,8 °/passo con riduzione meccanica sul rapporto di ingranaggi della vite senza fine. Con microstepping a 1/16 e il rapporto di riduzione tipico di queste montature (~144:1 in RA), la risoluzione angolare risultante è dell’ordine di 0,1–0,3 arcsec per passo — ben al di sotto del limite imposto dal seeing atmosferico.


L’allineamento polare: fondamento di tutto

Prima ancora di parlare di GoTo, c’è un prerequisito assoluto: l’allineamento polare. L’asse RA della montatura deve puntare il più possibile verso il Polo Nord Celeste. Senza questo allineamento, il tracking è impreciso, il GoTo sbaglia il puntamento e l’autoguida deve compensare errori enormi.

L’allineamento base consiste nel centrare la stella Polare nel cannocchiale polare integrato nella montatura. È sufficiente per l’osservazione visuale e la fotografia a corta focale. Per la fotografia a lunga focale con esposizioni di diversi minuti, serve un allineamento più preciso — perché la Polare non è esattamente sul Polo Nord Celeste, ma dista circa 42 arcominuti da esso.

Il metodo Kochab: precisione senza strumenti aggiuntivi

Il metodo Kochab (documentato da Bresser nei manuali ufficiali) è una tecnica elegante per migliorare l’allineamento polare senza richiedere software o accessori speciali — solo il cannocchiale polare e la conoscenza della posizione di Kochab nel cielo.

Kochab è la seconda stella più brillante dell’Orsa Minore (il “manico” del Piccolo Carro). La sua importanza per l’allineamento deriva da un fatto geometrico: Kochab, il Polo Nord Celeste reale e la Polare sono quasi perfettamente allineati su una retta. Questo significa che Kochab indica sempre la direzione del Polo rispetto alla Polare.

1

Identifica Kochab nel cielo. È la stella brillante all’estremità del “secchio” del Piccolo Carro, quella più lontana dalla Polare. Magnitudine 2,1 — ben visibile anche in città.

2

Nota la direzione di Kochab rispetto alla Polare guardando il cielo a occhio nudo. È a sinistra? In alto? In basso a destra? Questa direzione è la chiave.

3

Ruota l’asse RA (senza muovere la montatura) finché il segno della Polare nel cannocchiale polare si trova sul lato opposto al centro rispetto alla direzione di Kochab nel cielo reale. Nota: il cannocchiale polare inverte l’immagine lateralmente, quindi sinistra e destra sono invertite nel mirino.

4

Regola altitudine e azimut della montatura finché la Polare si trova sul segno corrispondente nel reticolo del cannocchiale. A questo punto il Polo Nord Celeste reale coincide con il centro del reticolo — l’allineamento è preciso.

⚠ Allineamento polare digitale: EKOS e il metodo a 3 scatti

Il supplemento ufficiale Bresser per KStars/EKOS descrive un metodo ancora più preciso: la montatura esegue tre rotazioni sull’asse RA, scattando una foto per ciascuna. Il plate solving calcola la posizione esatta di ogni rotazione, stima l’errore di allineamento e guida l’utente nelle correzioni. Funziona anche in siti dove la Polare non è visibile — un vantaggio reale per chi osserva da posizioni con orizzonte Nord coperto.


L’allineamento su stelle: come il GoTo impara il cielo

Dopo l’allineamento polare, il sistema GoTo deve eseguire una calibrazione su stelle. Questo passaggio è spesso frainteso: non serve a “trovare il Nord” (quello è già fatto con l’allineamento polare), ma a correggere gli errori meccanici residui della montatura — giochi negli ingranaggi, imprecisioni nell’home position, errori di ortogonalитà tra gli assi.

Il principio è semplice: il controller conosce le coordinate celesti di migliaia di stelle nel suo database. Se gli dici “questa stella che vedo nel campo visivo è Vega”, lui sa dove si trovano gli assi in quel momento e può costruire un modello di correzione.

Allineamento a una stella (1-star)

Il metodo più semplice. Il controller porta automaticamente il telescopio verso una stella di riferimento; l’utente la centra nell’oculare e conferma. Il sistema registra la deviazione e la usa come offset di correzione per tutti i puntamenti successivi. Preciso per obiettivi vicini alla stella di calibrazione, meno affidabile lontano da essa.

Allineamento a due stelle (2-star) — il metodo standard

Si ripete il processo su due stelle, preferibilmente lontane tra loro nel cielo. Con due punti di riferimento il controller può calcolare non solo un offset ma anche la rotazione del sistema di riferimento — compensando gli errori di orientamento dell’asse polare. È il metodo predefinito del SynScan di Sky-Watcher e del sistema Nebula GoTo di Bresser.

Allineamento a tre stelle (3-star) e All-Star

Con tre stelle il modello di correzione diventa tridimensionale: offset, rotazione e inclinazione degli assi. La funzione All-Star di SynScan va oltre: usa la posizione di qualsiasi stella brillante per raffinare l’allineamento polare in modo iterativo, senza dover tornare al cannocchiale polare. È la tecnica più precisa disponibile con hardware standard.

Come scegliere le stelle di allineamento

Le stelle scelte per l’allineamento devono essere: ben separate nel cielo (idealmente 90–120 ° di distanza angolare tra loro), ad altitudine superiore a 20–25 ° sull’orizzonte (il seeing è migliore in alto), e riconoscibili facilmente a occhio nudo. Scegliere stelle nello stesso quadrante del cielo è l’errore più comune: riduce drasticamente la precisione del modello di correzione.


Il database interno: cosa c’è davvero nel controller

Il controller di una montatura GoTo amatoriale contiene un database astronomico integrato. Le dimensioni variano tra i sistemi, ma l’ordine di grandezza è simile per tutti i produttori principali:

Catalogo Contenuto Oggetti tipici nel DB
Stelle di navigazione Stelle brillanti per l’allineamento ~200–300 stelle
Messier 110 oggetti del cielo profondo 110 completi
NGC / IC Nebulose, galassie, ammassi 7.000–14.000 oggetti
Pianeti Posizioni calcolate in tempo reale 8 pianeti + Plutone + Luna
Stelle doppie Sistemi doppi selezionati 200–800 sistemi
Stelle variabili Variabili principali ~100 stelle
Comete / asteroidi Orbite aggiornabili via PC Variabile, dipende dal firmware

I pianeti non sono memorizzati come posizioni fisse: il controller calcola la loro posizione in tempo reale a partire dalla data, dall’ora e dalla posizione geografica inserite all’inizio della sessione. Per questo la data e l’ora corrette sono fondamentali: un errore di un’ora nell’orologio si traduce in 15 ° di errore di puntamento sui pianeti.


Bresser Nebula GoTo vs Sky-Watcher SynScan: due filosofie

Il tuo EXOS-2 può essere acquistato in due versioni: con il sistema Nebula GoTo (basato su Raspberry Pi, connettività WiFi/Ethernet, interfaccia web) o con il classico controller a mano. Il SynScan di Sky-Watcher è il sistema di riferimento del mercato. Le differenze sono reali e vale la pena conoscerle.

Caratteristica Bresser Nebula GoTo Sky-Watcher SynScan
Cervello del sistema Raspberry Pi integrato Controller dedicato (handbox)
Interfaccia Web app da browser, nessun handbox necessario Tastierino fisico o app SynScan Pro
Connessione PC WiFi hotspot o Ethernet (IP: 192.168.1.28) USB seriale o WiFi adapter esterno
Compatibilità INDI/ASCOM Driver Avalon UD via Alpaca Discovery Driver SynScan ASCOM, INDI nativo
Integrazione NINA Richiede selezione driver via ASCOM Chooser Driver diretto disponibile
Integrazione KStars/EKOS Supporto INDI nativo, polar alignment tool Driver INDI SynScan ben documentato
Aggiornabilità firmware Più flessibile (OS Linux) Dipende da Sky-Watcher
Community e documentazione Più limitata Enorme, decenni di esperienza
Operatività offline Hotspot autonomo, IP fisso 10.0.0.2 Handbox indipendente
Connessione Nebula GoTo in campo — dal manuale ufficiale

Il Nebula GoTo offre due modalità di connessione. Hotspot diretto: il sistema crea la propria rete WiFi (password predefinita: AVgotosys), e si accede all’interfaccia digitando 10.0.0.2 nel browser. Connessione via router: il Nebula si connette alla rete di casa; per trovare il suo IP si usa un software di scansione della rete o si controlla il router. In alternativa, con un cavo Ethernet e un adattatore USB-Ethernet, il Nebula assume automaticamente l’IP fisso 192.168.1.28 — soluzione affidabile per sessioni fotografiche serie senza dipendenza da WiFi.


Dal GoTo all’automazione: INDI, EKOS e NINA

Il controller a mano è il punto di partenza, non il punto di arrivo. I software di controllo moderni — KStars/EKOS e NINA — usano protocolli standardizzati per parlare direttamente con la montatura, bypassando il controller fisico e aggiungendo funzionalità impensabili con il solo handbox.

Il protocollo INDI

INDI (Instrument-neutral Distributed Interface) è il protocollo open source usato su Linux (e quindi su Raspberry Pi) per controllare qualsiasi strumento astronomico — montature, camere, focheggiatori, ruote portafiltri. Ogni dispositivo ha un driver INDI che espone le sue funzionalità come proprietà modificabili da qualsiasi client compatibile. KStars/EKOS è il client INDI più diffuso su Linux.

Il protocollo ASCOM

Su Windows, il protocollo equivalente si chiama ASCOM (Astronomy Common Object Model). NINA usa ASCOM per comunicare con la montatura. La connessione con il Nebula GoTo avviene tramite il driver Avalon UD, selezionabile nell’ASCOM Chooser dopo aver abilitato la discovery Alpaca — come descritto nel supplemento ufficiale Bresser per NINA.

Cosa aggiunge il software rispetto al GoTo base

  • Sequenze automatizzate — pianifica la sessione in anticipo: quando puntare ogni oggetto, quante esposizioni, quale filtro, quando fare il meridian flip
  • Plate solving — la camera scatta una foto, il software riconosce il campo stellare e corregge automaticamente il puntamento a livello di arcsec
  • Allineamento polare digitale — senza cannocchiale polare, solo con la camera e il plate solving (metodo a 3 scatti di EKOS)
  • Meridian flip automatico — quando l’oggetto supera il meridiano, la montatura si ribalta automaticamente e riprende la sequenza
  • Recovery automatico — se si perde la stella guida o la connessione, il software riprende la sequenza senza intervento umano

L’errore periodico: il limite meccanico che non scompare

Ogni montatura a vite senza fine ha un errore periodico (Periodic Error, PE): una variazione ciclica nella velocità di tracking causata dalle imprecisioni nella lavorazione della vite senza fine e della ruota elicoidale. Il ciclo coincide con un giro completo della vite — tipicamente 8 minuti per le montature amatoriali. L’ampiezza dell’errore periodico è dichiarata in arcsec P-V (picco a valle).

Montatura PE dichiarato PE tipico reale Note
Bresser EXOS-2 GoTo ±20–30" ~20" Accettabile con autoguida
Sky-Watcher HEQ5 Pro ±10" (dichiarato) ~8–15" Ottimo per la categoria
Sky-Watcher EQ6-R ±5" ~5–8" Semi-professionale
iOptron CEM40 ±5" ~5–6" Center-balanced, ottimo PE

Con l’autoguida attiva, l’errore periodico viene quasi completamente corretto in tempo reale da PHD2 o EKOS. La funzione PEC (Periodic Error Correction) disponibile su molte montature registra il profilo dell’errore periodico e lo applica in anticipo come correzione preventiva, riducendo il carico sull’autoguida.


Il meridian flip: la manovra che nessuno spiega mai bene

Una montatura equatoriale tedesca (GEM) ha un limite strutturale: può puntare un oggetto in due configurazioni opposte, e quando l’oggetto attraversa il meridiano (la linea immaginaria che passa dallo Zenit al Nord e al Sud) la montatura deve “ribaltarsi” per seguirlo dall’altra parte. Questo è il meridian flip.

Se non gestito correttamente, il meridian flip durante una sessione fotografica automatizzata causa: interruzione della sequenza, perdita dell’autoguida, cambiamento della composizione dell’inquadratura (la camera ora è orientata di 180 °). NINA e EKOS gestiscono il meridian flip automaticamente: riposizionano la montatura, ri-eseguono il plate solving per verificare il puntamento, riprendono l’autoguida e continuano la sequenza — tutto senza intervento umano.


Per chi è questo articolo

Per chi ha appena acquistato o sta valutando una montatura GoTo e vuole capire cosa succede davvero quando preme quel tasto. Per chi usa il GoTo da mesi ma non ha mai capito perché a volte manca il bersaglio. Per chi sta per collegare la montatura a NINA o KStars/EKOS e vuole capire il protocollo prima di iniziare.

Il GoTo è uno strumento straordinario — ma funziona bene solo se capisci cosa gli stai chiedendo di fare. L’allineamento polare preciso, la scelta corretta delle stelle di calibrazione, la conoscenza del protocollo di comunicazione: queste non sono sottigliezze per esperti. Sono le basi che separano una sessione frustrata da una sessione produttiva.


Guida alle camere dedicate

Camere astronomiche · Guida completa 2026

ZWO, QHY, Player One e gli altri.
Guida alle camere dedicate — tutti i sensori, tutti i brand.

Il mercato delle camere astronomiche dedicate è cresciuto enormemente negli ultimi anni. ZWO ha oltre trenta modelli attivi. QHY ne ha altrettanti. Player One, Altair, Touptek, Omegon si contendono le fasce di prezzo intermedie. Orientarsi è difficile — specialmente perché molti modelli di brand diversi montano lo stesso identico sensore Sony. Questa guida è organizzata per sensore, non per SKU commerciale: quella è la struttura che resiste al tempo e aiuta davvero a scegliere.

⚠ Nota sulla data di verifica

Specifiche e prezzi sono stati verificati a marzo 2026. I prezzi in € sono indicativi e soggetti a variazioni. I sensori cambiano meno spesso dei bundle commerciali: questa guida si aggiorna quando escono nuovi sensori rilevanti, non ad ogni variazione di prezzo o nome modello.


Come leggere questa guida

Come usare questa guida insieme agli altri articoli del blog

Su Deep Sky Lab esistono già articoli monografici dedicati a ogni singolo brand: ZWO, QHY, Player One, Atik, SBIG. Quelli raccontano la storia, il posizionamento e i punti di forza di ogni produttore. Questa guida è complementare, non alternativa: è organizzata per sensore e per use case, e risponde alla domanda “cosa scelgo e perché” invece che “dimmi di quel brand”. Leggi prima questa se non sai da dove partire; poi approfondisci il brand che ti interessa con l’articolo dedicato.

Le camere dedicate si dividono in tre grandi categorie d’uso: planetario (alta velocità di ripresa, pixel piccoli, sensori compatti), deep sky raffreddate (basso rumore termico, lunghe esposizioni, sensori grandi) e guida (economiche, funzionali, spesso riciclate da modelli planetari). Ognuna ha logiche di scelta diverse.

Per ogni sensore indichiamo: il produttore, la diagonale, la dimensione del pixel, la QE di picco, il frame rate massimo, il raffreddamento e i brand che lo montano con il prezzo orientativo. La colonna Uso principale indica il target primario — ma quasi tutti i sensori moderni sono polivalenti.


I brand principali: chi sono e come si posizionano

Brand Sede Posizionamento Punti di forza Limiti
ZWO (ZW Optical) Cina (Suzhou) Leader di mercato Ecosistema ASIAIR, software maturo, gamma completa Servizio post-vendita variabile, lock-in ecosistema
QHYCCD Cina (Pechino) Semi-professionale Raffreddamento profondo (−45°C), True RAW output Software meno intuitivo, prezzi più alti
Player One Cina Emergente premium Buffer DDR3 su tutte le cam, anti-condensa integrato, build quality Gamma più ristretta, meno ecosistema
Altair Astro UK Fascia media Supporto europeo, compatibilità ampia, bundle completi Meno innovazione proprietaria, spesso OEM
Touptek / Omegon Cina / Germania Entry level / rebrand Prezzi accessibili, driver ASCOM stabili Spesso rebrand dello stesso hardware, poca differenziazione
Atik UK Semi-professionale UK Tradizione CCD, mercato club astronomici Gamma CMOS più limitata, meno aggiornamenti
SBIG USA Professionale storico Standard osservatori USA, autoguida integrata Prezzi proibitivi, line-up CMOS in ritardo

Sensori per il planetario: velocità e dettaglio

Le camere planetarie lavorano a frame rate molto alti — da decine a centinaia di fps — per permettere il lucky imaging: acquisire migliaia di frame e selezionare solo quelli catturati nei momenti di seeing migliore. I parametri chiave sono la velocità di lettura, la dimensione del pixel (che determina la scala immagine sulla focale), e la sensibilità nell’infrarosso vicino (dove il seeing è più stabile).

Sensore Formato Pixel Risoluzione QE picco FPS max (full res) BSI Modelli principali Prezzo ~
IMX662 1/2.8" 2,9 µm 1920×1080 (2 MP) ~80% 210 fps ZWO ASI662MC/MM ~280–350 €
IMX462 1/2.8" 2,9 µm 1920×1080 (2 MP) ~80% 120 fps ZWO ASI462MC, QHY5III462C, Player One Neptune-C II ~180–250 €
IMX585 1/1.2" 2,9 µm 3840×2160 (8,3 MP) ~90% 47 fps ZWO ASI585MC/MM, QHY5III585C, Player One Uranus-C ~350–480 €
IMX678 1/1.8" 2,0 µm 3840×2160 (8,3 MP) ~80% 60 fps ZWO ASI678MC, QHY5III678C, Player One Uranus-C II ~300–420 €
IMX664 1/1.8" 2,9 µm 2704×1540 (4,2 MP) ~85% 93 fps ZWO ASI664MC, Player One Neptune-664C ~300–400 €
IMX174 1/1.2" 5,86 µm 1936×1216 (2,4 MP) ~78% 170 fps No (FSI) ZWO ASI174MM/MC, QHY5III174M ~350–500 €
IMX290 1/2.8" 2,9 µm 1936×1096 (2,1 MP) ~77% 170 fps ZWO ASI290MM/MC, QHY5III290C (guidescope inclusi) ~150–220 €
IMX585 — il sensore della QHY 5III 585C

Il Sony IMX585 è attualmente uno dei sensori più capaci per il planetario in fascia amatoriale: QE del ~90%, pixel da 2,9 µm, 8,3 MP e buffer DDR3 da 512 MB che gestisce la trasmissione senza perdere frame. Si trova su ZWO ASI585MC, QHY5III585C e Player One Uranus-C. Stessa fisica, packaging diverso — la scelta tra i tre brand è soprattutto questione di ecosistema software e di preferenze meccaniche.


Sensori per il deep sky raffreddate: fascia entry e media

Le camere raffreddate sono il cuore del deep sky astrofotografico. Il raffreddamento Peltier abbassa la temperatura del sensore di 30–45 °C rispetto all’ambiente, riducendo drasticamente la corrente di buio e permettendo esposizioni di minuti senza saturare il sensore di rumore termico. I parametri chiave sono la dimensione del sensore (più grande = più campo), il read noise (più basso = esposizioni più brevi su cielo luminoso) e il full well (più alto = più gamma dinamica).

Sensore Formato Diag. Pixel MP QE picco Read noise Full well BSI Modelli raffreddate principali Prezzo ~
IMX533 1" quadrato 16 mm 3,76 µm 9 MP ~91% 1,0 e² 51 ke² ZWO ASI533MC Pro, QHY533C, Player One Saturn-C Pro ~700–900 €
IMX585 1/1.2" 12,8 mm 2,9 µm 8,3 MP ~90% 0,7 e² 30 ke² ZWO ASI585MC Pro, QHY miniCAM8 ~800–1.100 €
IMX294 4/3" 23,2 mm 4,63 µm 11,3 MP ~75% 2,3 e² 63 ke² ZWO ASI294MC Pro, QHY294C Pro ~1.100–1.400 €
IMX571 APS-C 28,3 mm 3,76 µm 26 MP ~91% 1,0 e² 51 ke² ZWO ASI2600MC Pro, QHY268C, Player One Apollo-M Pro ~1.600–2.200 €
IMX294 mono 4/3" 23,2 mm 4,63 µm 11,3 MP ~75% 2,3 e² 63 ke² ZWO ASI294MM Pro, QHY294M Pro ~1.400–1.700 €
IMX571 mono APS-C 28,3 mm 3,76 µm 26 MP ~91% 1,0 e² 51 ke² ZWO ASI2600MM Pro, QHY268M, Player One Apollo-M Pro Mono ~1.900–2.600 €
IMX183 1" 15,9 mm 2,4 µm 20 MP ~84% 2,5 e² 15 ke² ZWO ASI183MC Pro, QHY183C ~600–800 €

Sensori per il deep sky raffreddate: fascia alta e full frame

Sensore Formato Diag. Pixel MP QE picco Read noise BSI Modelli principali Prezzo ~
IMX455 Full frame 43,3 mm 3,76 µm 61 MP ~91% 1,0 e² ZWO ASI6200MC/MM Pro, QHY600C/M, Player One Poseidon-C ~3.200–5.000 €
IMX411 Medium format 54,0 mm 3,76 µm 150 MP ~88% ~1,5 e² ZWO ASI411MC, QHY411C ~8.000–12.000 €
IMX492 4/3" (mono) 22,3 mm 4,63 µm 12 MP ~80% ~1,5 e² QHY294 Pro (mono) ~1.700–2.200 €
IMX571 v2 APS-C 28,3 mm 3,76 µm 26 MP ~91% 1,0 e² ZWO ASI2600MC Pro 2025, QHY268C v2 ~1.700–2.200 €
IMX432 4/3" 22,5 mm 9,0 µm 4,2 MP ~80% ~1,0 e² ZWO ASI432MM, QHY432M ~1.800–2.400 €

Camere da guida: le silenziose del setup

La camera guida non produce le immagini finali: serve esclusivamente a inseguire una stella guida e a mandare correzioni alla montatura via PHD2 o EKOS. Non servono grandi sensori, non serve raffreddamento, non servono pixel piccoli. Servono basso read noise per rilevare stelle deboli, frame rate sufficiente (10–30 fps), e USB affidabile. La maggior parte delle camere planetarie entry level funziona benissimo anche come camera guida.

Modello Sensore Formato Pixel Uso doppio Prezzo ~ Note
ZWO ASI120MM Mini AR0130CS 1/3" 3,75 µm Solo guida ~100–130 € Il più diffuso, economico, stabile
ZWO ASI220MM Mini SC2210 1/1.8" 2,0 µm Guida + deep sky leggero ~180–220 € Sensore più grande, ottimo per OAG
ZWO ASI290MM Mini IMX290 1/2.8" 2,9 µm Guida + planetario ~150–190 € Ottima sensibilità NIR, versatile
QHY5III200M IMX200 1/2" 4,0 µm Guida + planetario ~200–260 € Pixel grandi ottimi per guida su stelle deboli
Player One Ceres-C IMX662 1/2.8" 2,9 µm Guida + planetario ~200–260 € Buffer DDR3, anti-amp glow, build premium
Altair GPCAM3 290M IMX290 1/2.8" 2,9 µm Guida + planetario ~160–200 € OEM ZWO, supporto UK incluso

Come scegliere: la mappa decisionale

La scelta della camera dipende da tre variabili fondamentali che vanno definite nell’ordine giusto: prima il target astronomico, poi la strumentazione ottica disponibile (focale e rapporto f/), poi il budget.

Target principale Sensore consigliato Perché Budget ~
Pianeti (Giove, Saturno, Marte) IMX585, IMX678, IMX462 Alta velocità, pixel piccoli per lunga focale, NIR sensibile 300–500 €
Sole (luce bianca) IMX174, IMX585 Global shutter per IMX174 (no rolling shutter), alta velocità 350–500 €
Luna (alta risoluzione) IMX585, IMX678 Alta risoluzione, buon contrasto, frame rate sufficiente 350–480 €
Deep sky broadband (OSC) IMX533, IMX571 Sensore grande, QE alta, read noise basso, raffreddamento 700–2.000 €
Deep sky narrowband (mono) IMX571 mono, IMX455 mono Nessun filtro Bayer, massima sensibilità per Hα e OIII 1.900–5.000 €
Deep sky entry level IMX533, IMX183 Formato 1", raffreddamento, QE alta, prezzo accessibile 600–900 €
Guida autoguida IMX290, AR0130CS, SC2210 Economica, frame rate sufficiente, USB stabile 100–220 €

Colore (OSC) vs monocromatica: la domanda che nessuno vuole affrontare

Una camera OSC (One Shot Color) ha il filtro Bayer applicato direttamente sul sensore: ogni pixel è sensibile a un solo colore. È più semplice da usare, non richiede filtri separati, è la scelta naturale per chi inizia. Una camera monocromatica non ha filtri: ogni pixel riceve tutta la luce. È più sensibile del 30–50% sull’asse singolo, permette di usare filtri Ha, OIII, SII per il narrowband, ma richiede l’acquisizione di almeno tre bande separate (LRGB o narrowband) per produrre un’immagine a colori.

OSC (colore) Monocromatica
Complessità setup Bassa — una camera, un filtro UV/IR cut Alta — ruota portafiltri, almeno 3–5 filtri
Efficienza fotoní ~25% per canale (filtro Bayer) ~100% per canale
Narrowband Possibile con dual-band, non ottimale Eccellente con filtri dedicati
Costo totale Più basso Più alto (camera + filtri + ruota)
Curva di apprendimento Dolce Ripida
Risultati su nebulose emissione Buoni, specie con dual-band Eccellenti con Ha+OIII+SII
Risultati su galassie Ottimi (colore naturale) Eccellenti con LRGB

Regola pratica: inizia con una OSC. Se dopo 12–18 mesi ti accorgi che il 70% delle tue notti le passi a fotografare nebulose di emissione con filtri, valuta il passaggio al monocromatico. Se fotografi principalmente galassie e ammassi, la OSC ti accompagnerà a lungo senza rimpianti.


Una nota sul raffreddamento: ΔT reale vs dichiarato

Quasi tutti i produttori dichiarano un ΔT di raffreddamento rispetto alla temperatura ambiente. ZWO dichiara −35 °C, QHY dichiara −45 °C sui modelli Pro. Questi valori sono teorici e misurati in condizioni ottimali di alimentazione e flusso d’aria.

Nella pratica di campo — alimentazione da batteria, aria ferma intorno alla camera, temperatura ambiente variabile — il ΔT reale è tipicamente il 70–80% del dichiarato. Con temperatura esterna di 15 °C e ZWO dichiarato −35 °C, aspettati di stabilizzarti intorno a −10 /−15 °C. Sufficiente per ridurre drasticamente la corrente di buio, ma non quanto il dato di marketing suggerisce.

⚠ Il punto di rugiada: il vero limite del raffreddamento

Non si può raffreddare il sensore al di sotto del punto di rugiada dell’aria circostante senza incorrere in condensa sul vetro di protezione o sul sensore stesso. Le camere di qualità (ZWO Pro, QHY) hanno un sistema di deumidificazione integrato (essiccante o azoto) per proteggere l’interno. Comunque, è buona pratica non spingere il raffreddamento oltre −5/−10 °C sotto il punto di rugiada della serata.


Per chi è questa guida

Per chi sta valutando il primo acquisto di una camera dedicata e non vuole fare l’errore di scegliere in base al brand invece che al sensore. Per chi ha già una camera e vuole capire dove si colloca nel panorama attuale. Per chi sta costruendo un setup e deve decidere se OSC o monocromatica.

La regola d’oro: scegli prima il sensore, poi il brand. ZWO, QHY e Player One che montano lo stesso IMX585 producono immagini quasi identiche — la differenza è nell’ecosistema software, nella meccanica e nel supporto post-vendita. Non nel cielo che vedi.


Un sistema solare su PC ed una stazione ricevente su Python

Programmazione & Astronomia · Per tutti

Ho messo la gravità dentro un computer.
Un pianeta che orbita — e un Raspberry Pi che lo conta.

Non bisogna saper programmare per capire questa storia. Basta avere un po’ di curiosità e la voglia di immaginare cosa succede quando provi a spiegare a un computer come funziona l’universo. Quello che ne è uscito è qualcosa di piccolo, imperfetto e affascinante — come tutte le cose fatte in casa con le proprie mani.


La domanda di partenza

Tutto è cominciato con una domanda semplice: è possibile fare in modo che il computer capisca perché la Terra orbita attorno al Sole? Non una simulazione già pronta scaricata da internet, non un’app. Qualcosa scritto da zero, dove ogni singola cosa che succede sullo schermo è l’effetto diretto di regole fisiche scritte a mano.

La risposta, sorprendentemente, è sì. E ci vogliono meno righe di codice di quelle che potresti immaginare.


La fisica che sta dietro: una sola regola

Isaac Newton, nel 1687, scrisse una delle frasi più potenti della storia della scienza: ogni corpo nell’universo attrae ogni altro corpo con una forza che dipende dalle loro masse e dalla loro distanza. Più sono massicci, più si attraggono. Più sono lontani, meno si attraggono — e la distanza conta al quadrato, il che significa che raddoppiare la distanza riduce la forza di quattro volte, non di due.

Questa è la legge di gravitazione universale. È la stessa legge che tiene la Luna in orbita, che fa cadere una mela dall’albero, che mantiene i pianeti attorno al Sole da miliardi di anni. Ed è anche l’unica regola di cui ha bisogno la nostra simulazione.

Come funziona la gravità nella simulazione

Immagina di avere il Sole fermo al centro dello schermo. La Terra è a una certa distanza. Ad ogni istante il computer si chiede: quanta forza sta esercitando il Sole sulla Terra in questo momento? La calcola. Poi aggiorna la velocità della Terra di conseguenza. Poi sposta la Terra nella nuova posizione. Poi ricomincia. Mille volte al secondo. Il risultato è un’orbita.


Il problema del computer: il tempo non è continuo

C’è un piccolo problema filosofico da risolvere prima di iniziare. La fisica è continua: la Terra si muove senza interruzioni, la forza gravitazionale cambia istante per istante in modo fluido. Il computer, invece, lavora a passi discreti: fa un calcolo, poi il successivo, poi il successivo ancora. Non esiste il “tra un calcolo e l’altro”.

La soluzione è semplice e geniale allo stesso tempo: si divide il tempo in fettine microscopiche. Ogni fettina è così piccola che, durante quel brevissimo intervallo, si può ragionevolmente assumere che la forza sia costante. Si calcola il movimento per quella fettina, poi per la successiva, poi per la successiva ancora. Se le fettine sono abbastanza piccole, il risultato è indistinguibile dal moto continuo reale.

Questo approccio si chiama integrazione numerica ed è lo stesso usato — in versioni molto più sofisticate — dai simulatori spaziali della NASA per calcolare le traiettorie delle sonde interplanetarie.


Cosa si vede sullo schermo

La simulazione si apre nel browser — sì, nel browser, come una pagina web, perché la libreria grafica usata (VPython) funziona così. Sullo sfondo nero dello spazio appare un sole giallo al centro. Una sfera blu — la Terra — parte da una posizione laterale e inizia a muoversi. Lascia una scia dietro di sé. Nel giro di pochi secondi si vede la prima orbita completarsi.

Nella versione attuale ci sono due pianeti: la Terra e Marte. Orbite diverse, velocità diverse, scie di colori diversi che si intrecciano nello spazio 3D. Si può ruotare la scena trascinando il mouse, fare zoom con la rotella, mettere in pausa, resettare le orbite se un pianeta prende una traiettoria strana.

Sotto la scena ci sono dei controlli: uno slider che regola la velocità della simulazione, dei pulsanti di reset, dei numeri che si aggiornano in tempo reale mostrando quante orbite ha completato ogni pianeta e a che distanza si trova dal Sole in questo momento.


La velocità iniziale: il trucco per non far cadere il pianeta

Una delle cose più belle da capire è perché i pianeti non cadono sul Sole. La gravità li attrae costantemente — allora perché non ci precipitano dentro?

La risposta è la velocità laterale. Un pianeta che si muove abbastanza velocemente “manca” continuamente il Sole: cade verso di lui, ma intanto si è già spostato di lato abbastanza da non centrarlo. Il risultato è un’orbita. È esattamente come lanciare una palla in modo così forte che la curvatura della sua traiettoria segue la curvatura della Terra — non tocca mai il suolo perché il suolo si incurva altrettanto velocemente.

Nella simulazione, la velocità iniziale giusta si calcola con una formula semplice che dipende solo dalla massa del Sole e dalla distanza del pianeta. Sbagliare questa velocità significa vedere il pianeta spiralare verso il Sole oppure schizzare via nello spazio. La prima versione del codice aveva questo problema — e il pulsante “Resetta orbita (usa questo se il pianeta scappa via!)” era l’unica soluzione.

⚠ Quando il pianeta scappa

Se si aumenta troppo la velocità della simulazione, le fettine di tempo diventano troppo grandi e i calcoli perdono precisione. Il pianeta inizia a seguire un’orbita sempre più allargata finché non sfugge completamente all’attrazione del Sole. È un errore del metodo di calcolo, non della fisica. La versione attuale lo riconosce automaticamente e riporta il pianeta all’orbita corretta senza intervento umano.


Il Raspberry Pi che conta i giri

Fin qui è già tutto abbastanza curioso. Ma il dettaglio che rende questo progetto diverso da un semplice esercizio di programmazione è quello che succede ogni volta che la Terra completa un’orbita.

Il computer lo rileva — controlla se il pianeta ha attraversato un certo piano dell’orbita — e in quel momento manda un messaggio via rete a un Raspberry Pi. Un piccolo computer grande quanto un mazzo di carte, collegato allo stesso router di casa, che stava in silenzio ad aspettare.

Il messaggio è semplice ma strutturato: dice quale pianeta ha completato l’orbita, quale numero di giro è e quanto tempo simulato è trascorso. Il Raspberry Pi lo riceve, lo stampa, lo salva su un file di log. È una comunicazione vera, via rete, tra due macchine fisiche reali. La simulazione sul PC e il Raspberry Pi parlano.

Perché questo è interessante

Non serve un supercomputer per fare cose che sembrano complesse. Un PC di casa e un Raspberry Pi da 80 euro riescono a simulare la gravità newtoniana e a comunicare via rete in tempo reale. La fisica degli stessi principi che tengono i pianeti in orbita è accessibile a chiunque abbia un computer e qualche ora di curiosità.


Dove può arrivare questo progetto

Il simulatore che esiste adesso è un punto di partenza. Le direzioni di crescita sono molte e non tutte richiedono di saper programmare in modo avanzato.

Più pianeti

Aggiungere Giove, Saturno, Venere è semplice: basta inserire le loro masse e distanze reali. Con Giove in scena, si potrebbe osservare come la sua enorme massa perturba le orbite degli altri pianeti — esattamente come succede nel sistema solare reale.

Un display fisico sul Raspberry Pi

Il Pi potrebbe collegare un piccolo schermo che mostra in tempo reale il numero di orbite completate, il tempo simulato, la distanza dei pianeti. Un cruscotto fisico per la simulazione virtuale.

Il collegamento con il telescopio

Questo è il salto più ambizioso — e anche il più affascinante. Il Raspberry Pi 5 che controlla il telescopio EXOS-2 usa un protocollo standard chiamato INDI per muovere la montatura. In linea di principio, la simulazione potrebbe calcolare dove si trova Giove questa notte, l’utente clicca sul pianeta nello schermo 3D, e il telescopio si muove verso quella direzione. Il virtuale che controlla il reale. Il software che punta l’hardware verso il cielo.

Non è ancora stato costruito — ma tutti i pezzi esistono. È un progetto per le prossime sessioni.


I limiti onesti: cosa questa simulazione non può fare

Un simulatore scritto a casa con un PC normale ha limiti reali. Vale la pena nominarli, non per sminuire il progetto ma perché capire i limiti è parte della comprensione.

  • Non è precisa come quella della NASA. Il metodo di calcolo usato accumula piccoli errori nel tempo. Su simulazioni molto lunghe, le orbite si deformano lentamente. I simulatori professionali usano metodi matematici molto più sofisticati per evitarlo.
  • Non usa unità reali. Le distanze e le masse nella simulazione sono numeri comodi per la visualizzazione, non i valori reali in chilometri e chilogrammi. Per simulare il sistema solare con proporzioni esatte servirebbe una scala molto diversa.
  • Non include la relatività generale. Per i pianeti del sistema solare la fisica newtoniana è più che sufficiente — ma per i buchi neri, per le onde gravitazionali, per Mercurio vicino al Sole, ci vorrebbero le equazioni di Einstein.
  • Con molti pianeti rallenta. Il PC di casa non è infinitamente veloce. Con decine di corpi il calcolo diventa lento. Per simulare migliaia di asteroidi servirebbero ottimizzazioni più serie.

Questi limiti esistono anche nei simulatori che costano milioni di euro — semplicemente sono stati spinti molto più in là. Il principio di base è lo stesso.


Come provarlo: istruzioni per chi vuole partire

1

Installa Python. Se non ce l’hai già, scaricalo da python.org. È gratuito, gira su Windows, Mac e Linux. La versione 3.10 o superiore va benissimo.

2

Installa VPython. Apri il terminale (su Windows: cerca “cmd” o “PowerShell”) e scrivi: pip install vpython. Premi invio e aspetta. Scarica automaticamente tutto il necessario.

3

Scarica il codice. Trovi il file del simulatore in fondo a questo articolo. Salvalo in una cartella sul desktop.

4

Apri il file. Se non hai un Raspberry Pi, apri il file con un editor di testo e cerca la riga INVIO_ABILITATO: cambia il valore da True a False. Questo disabilita la comunicazione di rete e la simulazione gira in autonomia.

5

Avvia. Dal terminale, vai nella cartella dove hai salvato il file e scrivi: python universo_3d_v2.py. Si apre automaticamente il browser con la simulazione.

⚠ Il browser si apre automaticamente?

VPython usa il browser come schermo 3D. Se si apre una pagina con un campo vuoto e dopo qualche secondo non appare la simulazione, prova a ricaricare la pagina. Su alcuni sistemi serve qualche secondo di avvio del server locale prima che la scena sia pronta.


Cosa si può imparare guardando girare un pianeta

C’è una cosa curiosa che succede quando passi un po’ di tempo davanti a questa simulazione. Inizi a vedere cose che prima sapevi solo in astratto.

Vedi che Marte è più lento della Terra — non perché qualcuno te lo ha detto, ma perché la scia di Marte avanza più lentamente di quella della Terra davanti ai tuoi occhi. Capisci visceralmente perché un anno su Marte dura quasi due anni terrestri: non sono le orbite più lunghe, ma anche le velocità più basse.

Se aumenti la massa del Sole con lo slider, vedi le orbite stringersi. Se la diminuisci, i pianeti si allontanano. Se dai a un pianeta troppa velocità iniziale, lo vedi sfuggire e non tornare. Sono le stesse cose che i libri di fisica descrivono con formule — ma qui le guardi succedere.

E c’è una soddisfazione strana e difficile da spiegare nel sapere che quelle orbite non vengono da un database, non sono un’animazione pre-registrata. Sono il risultato di una sola equazione applicata migliaia di volte al secondo. La gravità che funziona, dentro il computer.


Non serve saper programmare per iniziare

Il codice è già scritto. Basta installare Python, scaricare il file e avviarlo. La simulazione gira, i pianeti orbitano, e se hai un Raspberry Pi in un cassetto puoi collegarlo e vederlo ricevere i messaggi in tempo reale.

Se poi la curiosità porta a voler capire come funziona il codice — a cambiare qualcosa, ad aggiungere un pianeta, a vedere cosa succede se la gravità scalasse con il cubo della distanza invece del quadrato — l’articolo tecnico completo è disponibile con tutto il codice commentato e spiegato passo per passo.

L’universo è simulabile. E costa meno di un oculare.