I dati dei sensori di StratoSpera 4

Cediamo di seguito la parola a Francesco Sacchi per presentare e commentare i dati dei sensori di bordo di StratoSpera 4 nel volo del 26 maggio 2012.

Dati dei sensori di bordo di StratoSpera 4

StratoSpera 4: a successful failure

Dopo il recupero del payload di StratoSpera 4, come di consueto siamo tornati sfiniti ma contenti alle nostre attività quotidiane.

Il volo era andato bene, il payload era stato recuperato e ci avviavamo a quella che orami sembrava una normale verifica di routine dei dati di telemetria raccolti dal computer di bordo. C’erano stati alcuni imprevisti, in effetti il payload era atterrato lontano dal punto di atterraggio calcolato e con un po’ di ritardo rispetto al previsto. Non pensavamo però di scoprire che il volo non era stato affatto nominale e che il recupero era avvenuto solo dopo una lunga serie di eventi potenzialmente catastrofici.

Ma andiamo con ordine.

Eravamo sul campo, durante gli ultimi momenti prima del lancio, e, al momento dell’aggancio del payload ai palloni, inizia a suonare il beeper di segnalazione per l’atterraggio. Quando la scheda BSM-2, grazie ai dati raccolti dai sensori, valuta che è in procinto di atterrare, attiva un segnalatore, un beeper dal tono molto acuto, udibile a diversa distanza. Il suo scopo è quello di permettere la localizzazione del payload anche in mezzo a terreni non proprio ospitali. L’attivazione del beeper al momento del lancio è quindi una cosa non nominale. Non potendo interrompere la “sequenza di lancio” per un controllo approfondito, abbiamo semplicemente dato alla scheda un nuovo comando di start missione tramite il bottone sul pannello esterno. Il comando di start reinizializza tutti i processi, compreso quello che attiva il beeper, che si è quindi spento.

Dopo pochi istanti è avvenuto il lancio, i palloni hanno iniziato a salire regolarmente e dopo poco abbiamo smesso di ricevere gli SMS dal GPS tracker presente a bordo a causa dell’aumento dell’altitudine. Dopo un po’ di tempo passato a congratularsi e rilassarsi dopo il lancio, siamo partiti alla volta del punto di atterraggio previsto.

Ci siamo diretti verso Radicondoli (PI) e ci siamo messi in attesa. L’ora di atterraggio prevista era intorno le 9:30 (7:30 UTC), invece il primo SMS è stato ricevuto intorno le 11:00 (9:00 UTC), ben un’ora e mezzo dopo! Inoltre le coordinate dell’atterraggio erano molto più a sud del previsto: davano il payload vicino Paganico (GR), a 50 km dal punto di atterraggio previsto. Dopo aver raggiunto in auto un punto il più possibile vicino alle coordinate dell’atterraggio, abbiamo proseguito a piedi e verso le 14:30 (12:30 UTC) abbiamo ritrovato il payload.

Ecco una parte del percorso seguito da StratoSpera4:

I fatti strani continuano: come nel primo lancio, i brandelli dei palloni erano rimasti attaccati al payload. Addirittura uno dei tre palloni era rimasto quasi integro. Era evidente che era scoppiato al momento dell’atterraggio, a causa dei rami di un albero. Abbiamo infatti ritrovato gran parte del lattice sull’albero, con il collo del pallone ancora collegato ai cavi di connessione del payload. Sempre parlando dei cavi di collegamento, erano tutti e 3 tagliati dai rispettivi cutoff ma purtroppo completamente intrecciati con il paracadute, a valle del taglio. Anche se il cavo era tagliato, a causa dell’intreccio i palloni non potevano staccarsi.

Per continuare con le stranezza, la scheda BSM-2 non aveva attivato il beeper di atterraggio. Visto che il volo era durato quasi 5 ore, sul momento abbiamo pensato che le batterie si fossero scaricate.

Iniziando ad analizzare i dati la questione si è via via chiarita.

Altitudine

Ecco il grafico dell’altitudine, si vedono diverse cose.

Salta subito all’occhio che il grafico è incompleto, la parte finale termina a ~16.000 metri, manca quindi tutta la discesa fino all’atterraggio. Per qualche motivo, che per adesso possiamo solo ipotizzare, il computer di bordo ha smesso di acquisire dati intorno le 9:52 (7:52 UTC), ecco perché il percorso mostrato prima è solo parziale.

La scheda BSM-2 a bordo era programmata per attivare i cutoff a 33.000 metri, mentre dal grafico si nota che la quota massima è stata di circa 36 km (nostro secondo record).

Si nota inoltre che sia la salita che la discesa sono a velocità costanti e molto simili. Durante la discesa, di solito il payload dovrebbe raggiungere velocità di discesa molto elevate nel primo tratto (>300 km/h). Nel nostro caso invece, la velocità rimane intorno i 18-20 km/h per tutta la discesa.

Abbiamo quindi la conferma che StratoSpera 4 è disceso molto più lentamente del previsto a causa dell’ultimo pallone rimasto. Questo spiega l’allungamento del tempo di missione e la maggior distanza percorsa.

La configurazione a 3 palloni che avevamo pensato non si è rivelata quindi molto affidabile. Grazie alle foto di Polifemo, sappiamo che i palloni si sono intrecciati quasi subito, e nonostante il cutoff abbia tagliato i cavi, essi non si sono mai separati dal payload.

Analizzando il log degli eventi del computer di bordo, si vede infatti che esso ha provato più volte a tagliare i cavi una volta superati i 33 km, ma il payload ha continuato a salire.

La fortuna ha voluto che dopo 11 minuti dal primo cutoff i palloni di prua siano scoppiati, entrambi. Se ne fosse scoppiato uno solo, il payload non avrebbe avuto una velocità di discesa sufficiente, e con ogni probabilità sarebbe finito in mare, tra l’Isola d’Elba e la Corsica.

Pressione

Ecco che anche i dati raccolti dal sensore di pressione ci rivelano delle sorprese:

Oltre all’ormai noto problema della mancanza dei dati della fase finale del volo, si vede che il grafico è fortemente “rumoroso” per una prima parte, poi, intorno le 8:45 (6:45 UTC) c’è un grosso scalino di 30 mBar che lo fa tornare a valori nominali. Cosa è accaduto? E’ chiaro che la prima parte dei dati non rappresenta l’andamento reale della pressione (nei primi momenti ci sono dei picchi enormi, anche di 60 mBar tra due letture consecutive!).

Dopo un po’ di prove, possiamo dire con certezza che si tratta di disturbi elettromagnetici radiati e condotti captati dal circuito di amplificazione del sensore di pressione. Già nei lanci passati questo circuito si era rivelato troppo suscettibile, ma stavolta questo problema ha quasi compromesso la missione. Questo stadio andrà di sicuro rivisto, ma nelle altre missioni tutto era andato bene. Da dove provengono i disturbi rilevati questa volta?

Tutta l’elettronica del payload era stata testata ed integrata con largo anticipo e non era stato trovato nessun problema. Solo un componente non è stato integrato fino all’ultimo: Polifemo.

Purtroppo, per cause contingenti, siamo riusciti a fare un test solo il giorno prima del lancio. Con il poco tempo a disposizione, i test che abbiamo fatto sono stati evidentemente insufficienti e non hanno messo in luce questo problema di compatibilità elettromagnetica tra la scheda BSM-2 e la board di Polifemo.

I disturbi registrati spiegano l’accensione del beeper di atterraggio alla partenza: la scheda usa il sensore di pressione per valutare l’altitudine a bassa quota, perché è molto più preciso per valutare la velocità ascensionale e quindi rilevare i momenti di decollo e atterraggio. Con questi sbalzi nelle misure, la scheda ha creduto di salire e scendere più volte di diversi metri. Ha creduto cioè di stare atterrando quando in realtà era ancora ferma a terra, avviando quindi per sicurezza il beeper di atterraggio.

Dopo il comando di re-start dato manualmente, le misure sono rimaste per un po’ stabili, ma poco dopo il lancio, a poche decine di metri di altezza, ci sono stati altri picchi che hanno fatto credere alla scheda di stare cadendo invece di salire.

In questo breve momento ha riattivato il beeper di atterraggio, che quindi è rimasto acceso per tutta la durata del volo, contribuendo al consumo delle batterie.

Se le letture falsate si fossero protratte per più tempo, ci sarebbe stato il rischio di attivazione del cutoff. Tra le altre cose, infatti, la scheda è programmata per attivare il meccanismo di cutoff non appena viene rilevato che i palloni sono esplosi e il payload sta cadendo. Onde evitare di tagliare i cavi per colpi di vento, il sistema è tarato per riconoscere una discesa continuativa di altitudine per almeno 30 secondi. Per fortuna, sebbene i dati dal sensore fossero molto instabili, non è mai stato raggiunto questo limite.

A 1.500 metri di quota poi il sistema inizia ad utilizzare l’altitudine GPS per il controllo del cutoff perché la precisione del sensore di pressione non è più necessaria, quindi il rischio è rientrato.

Rimane da spiegare perché ad un certo punto il rumore sia cessato e le misure siano ritornate nella norma. Lasciamo un attimo da parte questo piccolo enigma e diamo un’occhiata alle misure di temperatura.

Temperatura

Tanto per cambiare, anche i dati di temperatura hanno un andamento non nominale, vediamo in dettaglio cosa è accaduto:

Durante la salita, come di consueto e come previsto, la temperatura è scesa, fino a raggiungere un minimo di circa -42° C a 10.000 m di altitudine.

A quella quota non saremmo ancora in stratosfera, e la temperatura sarebbe dovuta scendere ulteriormente e salire successivamente. Invece la ripresa è stata repentina, fino a che, a circa 33.000 m di quota, è tornata sopra lo zero.

I due sensori di temperatura esterna, posti in posizioni diverse ma sempre in prossimità del payload, a questo punto hanno iniziato a rilevare temperature sensibilmente diverse tra loro, tanto che pochi minuti dopo la differenza tra le due sonde ha raggiunto alcune decine di gradi. La temperatura massima registrata in stratosfera è stata di ben +14° C, la più alta mai registrata nei nostri lanci!

Cosa è successo? Come sono spiegabili queste temperature insolitamente alte e la differenza misurata tra due sensori sostanzialmente nello stesso punto?

La spiegazione è piuttosto semplice: stavolta il polistirolo del payload era di colore nero. Complice il vuoto stratosferico, il calore assorbito dal sole per irraggiamento era superiore rispetto agli scorsi lanci e questo ha causato l’aumento di temperatura registrato. Ma perché la differenza tra i due sensori?

Come vedremo successivamente dai grafici di accelerazione, il momento di temperatura più alta coincide con lo scoppio dei palloni di prua. In quel frangente, il volo è stato particolarmente tranquillo e stabile; tanto stabile che il payload è rimasto orientato nella stessa posizione per quasi 15 minuti! Il sole ha riscaldato quindi molto di più alcune parti del payload rispetto ad altre e questo spiega la differenza riscontrata tra i due sensori, uno dei quali era magari meno illuminato.

Ma c’è di più: il payload è rimasto così stabile che il sole ha fuso parzialmente la parte che era illuminata:

Ultima nota: tutto questo calore in fin dei conti non è stato una cosa negativa: la temperatura interna (linea gialla) è scesa pericolosamente durante la salita, tanto da toccare i -10° C all’ingresso nella stratosfera. Negli altri lanci temperature interne così basse sono state registrate durante la caduta libera, segno quindi che l’isolamento stavolta non era ottimale.

Grazie al riscaldamento anomalo, la temperatura interna è però risalita velocemente, tanto da raggiungere e superare i 30° C a 30.000 m di quota.

Umidità

Ecco i dati provenienti dall’igrometro:

Stavolta, il sensore era stato compensato in temperatura e calibrato con ragionevole precisione.

Nei primi minuti l’umidità relativa è al di sopra del 100% (108% per la precisione), a causa del fatto che c’era condensa sul sensore (rugiada).

Con la salita l’umidità relativa è scesa e risalita più volte, a seconda dei vari strati nuvolosi incontrati, ma non è mai risalita perché, come abbiamo visto, i dati raccolti si interrompono a metà della discesa.

Accelerazione

I dati di accelerazione sono molto interessanti:

Per gran parte della salita il volo è stato molto turbolento, con il payload come di consueto inclinato con la fotocamera leggermente puntata verso il basso (assi Y e Z).

Ad un certo punto, intorno alle 6:38 UTC (8:38 ora locale), c’è un momento di calma pressoché totale. Controllando i log degli eventi della scheda BSM-2, si vede che quello è il momento in cui si è attivato il cutoff la prima volta. Come sappiamo i palloni sono rimasti intrecciati, ma il cavo di collegamento è stato tagliato, e questo ha fatto sì che il payload si disponesse in una posizione diversa da quella assunta durante la salita.

I tre palloni erano ancorati come in figura:

Dopo il taglio dei cavi effettuato nei punti indicati come Cutoff1 e Cutoff2, a causa dell’intreccio dei cavi di collegamento, il payload ha continuato a salire in questa configurazione:

I tre palloni ravvicinati, ancorati praticamente in un solo punto, hanno fatto sì che il volo fosse molto stabile e tranquillo. Poco dopo, i palloni che erano collegati al filo verde sono esplosi entrambi e si nota infatti un picco nel grafico dell’accelerazione intorno alle 6:54 UTC (8:54 ora locale). Da qui inizia una lenta discesa, che, rientrando in strati via via più densi dell’atmosfera, fa registrare delle leggere turbolenze.

Contatore Geiger HADARP

In questo lancio, HADARP ha funzionato in modo impeccabile riportando i livelli di radiazione al variare della quota.

Il software di volo era stato modificato per compensare il dead time del tubo, quindi i valori riportati sono già corretti.

I dati sono in buon accordo con le aspettative: si nota subito come all’aumentare dell’altitudine aumenti anche il livello di radiazioni. Questo perché le particelle ionizzanti nell’atmosfera sono generate dai raggi cosmici: più saliamo in quota e meno è l’atmosfera presente per schermarli. Però ad un certo punto troviamo un massimo (a 17.000 m con un livello di radiazioni che è 60 volte più elevato di quello al suolo) , e con il salire di quota la misura di radiazione scende: come mai?

Il motivo è semplice: quando le particelle dei raggi cosmici arrivano dallo spazio a contatto con l’atmosfera, generano a cascata uno sciame di particelle ionizzate chiamate raggi cosmici secondari. Questi raggi cosmici secondari sono assorbiti dall’atmosfera, quindi più si sale in quota più la radiazione aumenta. Ma se saliamo oltre la quota a cui si formano, il livello di radiazioni non può fare altro che scendere, ed è quello che abbiamo registrato nel nostro grafico.

Per un’analisi più approfondita rimando a Matteo Negri, il progettista di HADARP.

Da notare che il grafico si interrompe bruscamente intorno alle intorno alle 8:45, molto prima della fine della registrazione dei dati del computer di bordo. I dati si interrompono proprio allo stesso istante in cui è presente lo scalino nei dati del sensore di pressione. I due eventi sono quindi collegati, analizzando i dati di housekeeping del computer di bordo è possibile risolvere questo enigma.

Telemetria tecnica di bordo

Come descritto nei paragrafi precedenti, ci sono stati diversi eventi che hanno fatto sì che questa missione possa essere considerata non nominale dal punto di vista del computer di bordo.

Prima di analizzare le varie cause, vediamo i dati di tensione e corrente acquisiti:

Sulla scala di sinistra, in Volt, sono presenti le tre tensioni acquisite dalla scheda: tensione batterie, +5V e +3.3V (linee blu, rossa e gialla). Sulla scala di destra, in milliAmpere, viene rappresentata la corrente assorbita dalle batterie (linea verde).

Si nota subito che il livello di corrente assorbito è piuttosto elevato rispetto agli altri lanci, tra 400 e 450 mA (negli altri lanci era meno della metà). Questo è dovuto all’hardware aggiuntivo di Polifemo.

Si nota che la tensione delle batterie (che dovrebbe essere 6V) è scesa di molto durante il volo, tanto da compromettere la generazione della tensione a +5V stabilizzata. La discesa è continuata fino alle fatidiche 8:45 in cui l’assorbimento di corrente è calato bruscamente e la tensione è risalita leggermente. Cosa è accaduto in quell’istante?

Dai log degli eventi si scopre che il software di volo, accorgendosi che i comandi di cutoff non avevano avuto effetto, è andato in modalità fail-safe. Ha cioè disattivato l’alimentazione a tutti i carichi ausiliari per consentire una maggiore durata delle batterie. Questo spiega l’interruzione delle misure di HADARP e la scomparsa del rumore captato dal sensore di pressione: sia HADARP che Polifemo sono stati spenti in quell’istante.

Rimane da spiegare perché il computer di bordo abbia fallito completamente alle 7:52 UTC (9:52 locali), interrompendo l’acquisizione dei dati telemetrici.

Abbiamo alcuni indizi che ci fanno ipotizzare quello che sia accaduto dopo, ma non abbiamo prove certe.

La prima ipotesi è che si fossero scaricate le batterie. Dai dati raccolti però è possibile stimare che abbiamo estratto circa metà dell’energia presente nelle stesse, quindi il motivo doveva essere un altro.

Analizzando la scheda SD su cui vengono salvati i dati, ci siamo accorti che conteneva circa 160 file di log diversi. Il computer di bordo crea un nuovo file di log ogni volta che si riavvia, quindi significa che si era riavviato almeno 160 volte. Provando ad inserire l’SD in un PC, ci siamo accorti che il filesystem era corrotto: sebbene la SD contenesse solo 5 MB su 2 GB di capienza, non era possibile creare altri file.

Dovete anche sapere che il computer di bordo, al riavvio, non è più in modalità fail-safe e ricollega l’alimentazione ai carichi ausiliari.

Mettendo tutto insieme, ecco la sequenza di eventi più probabile:

• Alle 7:52 UTC, per qualche motivo ignoto, presumibilmente a causa di danni al filesystem dell’SD, il computer di bordo si è resettato. Altre cause di reset sono ipotizzabili ma poco probabili perché il computer è programmato per loggare su SD il motivo del riavvio, tranne il caso in cui esso è causato dall’impossibilità di scrivere sull’SD stessa.
• Al riavvio ha creato un nuovo file di log, e pochi istanti dopo ha riattivato l’alimentazione ai carichi ausiliari.
• Alla riattivazione dei carichi, le batterie con metà carica hanno subito un repentino abbassamento di tensione, che ha fatto resettare nuovamente la scheda.
• Il ciclo di reset è andato avanti per 160 volte, dopodiché, a causa degli errori sul filesystem, non è stato possibile creare altri file.

In definitiva questo lancio, che avrebbe potuto portare alla perdita del payload, ci ha graziato e ci ha dato quindi modo di imparare dagli errori commessi.

Per il futuro, è in programma di riprogettare il payload e la scheda BSM-2 per ovviare ai problemi riscontrati.