Output del Compustar per automatizzare la cupola

10 Dicembre 2019: Aggiornato per il firmware 1.90!

Attenzione! Questo post è piuttosto tecnico, perché le informazioni riportate qui servono a chiunque voglia realizzare un sistema automatico di puntamento cupola per il Compustar. Cioè, non servono a nessuno, temo…

I firmware da 64Kb del Compustar che ho realizzato, a partire dalla versione 1.80, trasmettono un pacchetto dati che può essere utilizzato per calcolare dove sta puntando il telescopio e quindi essere usato per automatizzare il posizionamento della cupola.

A causa delle limitate risorse disponibili nel microprocessore del Compustar, il pacchetto dati trasmesso non segue nessuno standard in particolare e di conseguenza richiede una specifica implementazione e/o uno specifico hardware esterno per movimentare la cupola.

Per questa ragione, sto sviluppando un controller realizzato ad hoc per l'”Osservatorio Città di Legnano” che documenterò l’anno prossimo in un articolo dedicato.

Il pacchetto dati viene trasmesso sul pin 12 del connettore DB-25 che collega il Compustar alla “Power box”. Questo pin non viene utilizzato dai firmware normali ed è connesso all’interno del Compustar a una porta di sola uscita del microprocessore.
I dati sono trasmessi come una normale seriale asincrona a livelli TTL di sola trasmissione.

Il firmware versione 1.80 trasmetti i dati alla velocità (non standard) di 1709bps, con 8 bit di dati, nessuna parità e parecchi bit di stop (il che vuol dire che c’è un lungo intervallo tra i caratteri).

Il firmware versione 1.90 trasmette i dati a 854bps, parità PARI, per migliorare l’affidabilità della trasmissione (dal momento che gli interrupt dei motori avrebbero potuto distorcere i bit della trasmissione a 1709bps un po’ troppo per essere ricevuti correttamente). Inoltre, i dati sono trasmessi con una sequenza non standard: invece di <Start><Bit 0>…<Bit 7><Parità><Stop>, i bit sono trasmessi <Start><Parità><Bit 0>…<Bit 7><Stop>. Per ricostruire il byte ricevuto, usate la tabella riportata qui sotto.

Se vi domandate perché 1709/854bps, è perché l’implementazione di questa seriale di sola trasmissione è software e trasmette un bit ogni ciclo / due cicli di refresh del display (che avviene, per l’appunto, a 1709 Hz).

Il pacchetto dati

Formato e contenuto (firmware 1.80):

Formato e contenuto (firmware 1.90):

OffsetCampoNote
0Sincronizzazione #10xF9, valore fisso
1Sincronizzazione #20xFB, valore fisso
2Sincronizzazione #30xFD, valore fisso
3AnnoDal 1900, quindi 118 vuol dire 2018
4Mese1 = Gennaio
5GiornoGiorno del mese
6Ora del giorno (Bit 7..0)A partire da mezzanotte, in 0.1s, UT
7Ora del giorno (Bit 15..8)
8Ora del giorno (Bit 23..16)
9Ascensione retta (Bit 7..0)Questo è un valore a 3 byte. Diviso per 3200 dà l'ascensione retta in minuti.
10Ascensione retta (Bit 15..8)
11Ascensione retta (Bit 23..16)
12Declinazione (Bit 7..0)Questo è un valore a 3 byte. Diviso per 128 dà la declinazione in primi.
13Declinazione (Bit 15..8)
14Declinazione (Bit 23..16)
15Flag #1Bit 7: Forza riallineamento cupola (SLEW/ALIGN)
Bit 6: Segno della declinazione. 1=Negativa
Bit 5: Coordinate non valide: se a 1, indica che le coordinate in questo frame non sono valide e devono essere ignorate
Bit 4: Il display è spento (SET/SCOPE/DISP/ALL)
Bit 3: OPT-8-3
Bit 2: OPT-8-2
Bit 1: 1=Il telescopio si sta muovendo in declinazione, che quindi è quella dell'oggetto
Bit 0: 1=Il telescopio si sta muovendo in ascensione retta, che quindi è quella dell'oggetto
16Latitudine (Bit 7..0)Latitudine del sito, in primi. Il bit 15 è il segno, 1 = negativo
17Latitudine (Bit 15..8)
18Flag #2Bit 7: Non usato
Bit 6: Non usato
Bit 5: Non usato
Bit 4: Non usato
Bit 3: Sincronizzazione attiva (OPT-7)
Bit 2: Ridotta luminosità sul display
Bit 1: In parcheggio/parcheggiato
Bit 0: 1=Il movimento in corso è fatto manualmente.
19Longitudine (Bit 7..0)Longitudine del sito in primi. È lo stesso numero che si immette nel Compustar (0-359°)
20Longitudine (Bit 15..8)

Sincronizzazione

  • È necessario sincronizzare la ricezione del pacchetto utilizzando i byte di sincronizzazione.
    Questo può venire fatto in due modi diversi:
    1) Cercare 3 byte consecutivi con 0xF nel nibble più significativo.
    2) Cercare direttamente i 3 byte di sincronizzazione (0xF9,0xFB,0xFD).
    Il metodo 1) è preferibile perché mi permetterebbe, nel caso si rendesse necessario, di utilizzare il nibble meno significativo dei byte di sincronizzazione per trasmettere ulteriori dati senza dover cambiare la lunghezza del frame (che è un’altra cosa che non posso fare facilmente).
  • È necessario che la sincronizzazione sia sempre attiva, e che ci si risincronizzi ogni pacchetto.
    Questo perché ogni 3 pacchetti (per un problema di allieamento interno) verrà trasmesso un byte aggiuntivo tra la fine di un pacchetto e prima dei byte di sincronizzazione del pacchetto successivo. Se ci si risincronizza ogni pacchetto, questo byte “spurio” non causerà nessun problema. Il valore di questo byte “extra” non è definito, ma non ha 0xF nel nibble più significativo.

Convalida del pacchetto dati

Viste le ridottissime risorse disponibili nel microprocessore del Compustar per la generazione di questo pacchetto dati, praticamente nessun dato viene bufferizzato prima della trasmissione. Questo comporterà che, talvolta, alcuni dati nel frame non saranno corretti. Queste sono le regole consigliate per riconoscere (e ignorare) i dati non validi.

  • RA/DEC: Versione breve: se il bit di “Coordinate non valide” è 0, sono entrambe validi.
    Spiegazione dettagliata:
    RA/DEC sono le coordinate dell’oggetto quando il telescopio sta eseguendo un “goto” (quando uno dei flag “il telescopio si sta muovendo in…” sono a 1), altrimenti sono le coordinate correnti del telescopio. Quando un goto inizia o finisce, avviene un cambio dalle coordinate dell’oggetto a quelle del telescopio o viceversa. Questo cambio non è sincronizzato con la trasmissione del pacchetto dati, per cui è possibile che i byte ricevuti siano un mix tra le coordinate dell’oggetto e quelle del telescopio. Onde evitare problemi, nel frame in cui avviene questo cambio, le coordinate sono marcate “non valide”.
    Notate che le coordinate RA e DEC sono separate, quindi è possibile ricevere le coordinate del telescopio per una delle due e le coordinate dell’oggetto per l’altra. Se volete gestirle separatamente (anche se non vedo la necessità), usate i flag “il telescopio si sta muovendo in…”.
  • Ora: è valida se la differenza tra il valore del pacchetto corrente e il valore del pacchetto precedente è minore di 5 6 (che sarebbero 0.5s 0.6s). Va ignorata altrimenti.
  • Data: è valida se il valore letto nel pacchetto corrente è uguale al valore letto nel pacchetto precedente E l’ora nel pacchetto corrente è valida (secondo la regola sopra). Va ignorata altrimenti.
  • Latitudine del sito: è valida il se il valore nel pacchetto corrente è uguale al valore nel pacchetto precedente. Va ignorata altrimenti.
  • Longitudine del sito: è valida il se il valore nel pacchetto corrente è uguale al valore nel pacchetto precedente. Va ignorata altrimenti.
  • Longitudine del sito (Bits 15..8): se il nibble alto è 0xF, l’intero frame va scartato perché qualche byte è andato perso e non è quindi affidabile (Nota: questo vale per entrambe le versioni firmware)

Note aggiuntive

  • Durante un goto, il pacchetto dati contiene le coordinate dell’oggetto a cui si sta andando invece delle coordinate del telescopio.
    Questo era più semplice da implementare, ma è anche più utile, perché permette alla cupola di muoversi direttamente verso lo stesso oggetto puntato dal telescopio invece di semplicemente inseguirlo.
  • OPT-8-3, OPT-8-2 sono due opzioni del Compustar che sono semplicemente trasmesse alla cupola. Il loro significato è lasciato all’implementazione del controller della cupola.
  • Non c’è nessun metodo per verificare che la Longitudine e la Latitudine siano una coppia di valori corretti: se l’utente sta inserendo le coordinate dell’osservatorio nel Compustar, il pacchetto dati ad un certo punto conterrà una logitudine valida e aggiornata assieme ad una latitudine valida ma non ancora aggiornata. Questo non dovrebbe comportare problemi perché il Compustar si avvierà sempre con l’opzione di sincronizzazione cupola (OPT-7) disattivata, e ci si aspetta che le coordinate dell’osservatorio siano aggiornate PRIMA di attivare questa sincronizzazione. Questo viene automaticamente garantito se si utilizza l’attivazione automatica della sincronizzazione – OPT-8-4.
  • Questa è la tabella per convertire i byte ricevuti nel corretto byte (ripristinando la corretta sequenza dei bit). La tabella contiene 256 valori. Usate il byte ricevuto come indice per leggere il byte corretto.
    0x00,0x80,0x81,0x01,0x82,0x02,0x03,0x83,0x84,0x04,0x05,0x85,0x06,0x86,0x87,0x07,
    0x88,0x08,0x09,0x89,0x0A,0x8A,0x8B,0x0B,0x0C,0x8C,0x8D,0x0D,0x8E,0x0E,0x0F,0x8F,
    0x90,0x10,0x11,0x91,0x12,0x92,0x93,0x13,0x14,0x94,0x95,0x15,0x96,0x16,0x17,0x97,
    0x18,0x98,0x99,0x19,0x9A,0x1A,0x1B,0x9B,0x9C,0x1C,0x1D,0x9D,0x1E,0x9E,0x9F,0x1F,
    0xA0,0x20,0x21,0xA1,0x22,0xA2,0xA3,0x23,0x24,0xA4,0xA5,0x25,0xA6,0x26,0x27,0xA7,
    0x28,0xA8,0xA9,0x29,0xAA,0x2A,0x2B,0xAB,0xAC,0x2C,0x2D,0xAD,0x2E,0xAE,0xAF,0x2F,
    0x30,0xB0,0xB1,0x31,0xB2,0x32,0x33,0xB3,0xB4,0x34,0x35,0xB5,0x36,0xB6,0xB7,0x37,
    0xB8,0x38,0x39,0xB9,0x3A,0xBA,0xBB,0x3B,0x3C,0xBC,0xBD,0x3D,0xBE,0x3E,0x3F,0xBF,
    0xC0,0x40,0x41,0xC1,0x42,0xC2,0xC3,0x43,0x44,0xC4,0xC5,0x45,0xC6,0x46,0x47,0xC7,
    0x48,0xC8,0xC9,0x49,0xCA,0x4A,0x4B,0xCB,0xCC,0x4C,0x4D,0xCD,0x4E,0xCE,0xCF,0x4F,
    0x50,0xD0,0xD1,0x51,0xD2,0x52,0x53,0xD3,0xD4,0x54,0x55,0xD5,0x56,0xD6,0xD7,0x57,
    0xD8,0x58,0x59,0xD9,0x5A,0xDA,0xDB,0x5B,0x5C,0xDC,0xDD,0x5D,0xDE,0x5E,0x5F,0xDF,
    0x60,0xE0,0xE1,0x61,0xE2,0x62,0x63,0xE3,0xE4,0x64,0x65,0xE5,0x66,0xE6,0xE7,0x67,
    0xE8,0x68,0x69,0xE9,0x6A,0xEA,0xEB,0x6B,0x6C,0xEC,0xED,0x6D,0xEE,0x6E,0x6F,0xEF,
    0xF0,0x70,0x71,0xF1,0x72,0xF2,0xF3,0x73,0x74,0xF4,0xF5,0x75,0xF6,0x76,0x77,0xF7,
    0x78,0xF8,0xF9,0x79,0xFA,0x7A,0x7B,0xFB,0xFC,0x7C,0x7D,0xFD,0x7E,0xFE,0xFF,0x7F

 

Leave a Reply

Your email address will not be published.