Archivio

Archivio autore

Patch del progetto StratoSpera

4 settembre 2010 amoroso 1 commento

Ecco la patch ufficiale del progetto StratoSpera. Mostra il pallone nella stratosfera con il paracadute (in bianco) e il payload (giallo) ancora agganciati. Sul cielo nero, a sinistra, si vedono alcune stelle. In alto a sinistra c’è il logo dell’Associazione ISAA.

Patch ufficiale del progetto StratoSpera.

Categorie:Senza categoria Tag:

Come seguire online il lancio STSp-1

3 settembre 2010 amoroso Nessun commento

Il 4 settembre 2010, verso le 10:00 circa ora italiana (08:00 UTC), tenteremo il primo lancio sperimentale STSp-1 di StratoSpera. L’orario di lancio potrebbe subire forti variazioni. Per fornire online le ultime informazioni, immagini e video useremo i principali social network, che consentono una maggiore rapidità di aggiornamento e diffusione:

Categorie:Senza categoria Tag:

Simulazioni della missione STSp-1

2 settembre 2010 amoroso 8 commenti

Ecco un paio di immagini di recenti simulazioni di Francesco Bonomi della missione STSp-1 di StratoSpera, il cui lancio avverrà dalla zona del Chianti in Toscana:

Le ha realizzzate Michael Sacchi utilizzando i dati di Francesco.

- Paolo

Categorie:Senza categoria Tag:

@StratoSpera su Twitter

1 settembre 2010 amoroso Nessun commento

Ora siamo anche su Twitter. Seguici su @StratoSpera per aggiornamenti quasi in tempo reale.

- Paolo

Categorie:Senza categoria Tag:

StratoSpera su Facebook

31 agosto 2010 amoroso Nessun commento

Abbiamo creato la pagina StratoSpera su Facebook per permettere anche ai numerosi utenti di questo social network di seguirci.

- Paolo

Categorie:Senza categoria Tag:

Denominazione dei lanci StratoSpera

31 agosto 2010 amoroso 2 commenti

Abbiamo scelto i criteri per le sigle che indicheranno i voli del progetto StratoSpera. Le sigle avranno la forma:

STSp-NNN

In cui NNN è il numero progressivo di missione. STSp, che non ci fa venire in mente altro, sta per STratoSpera. Il primo lancio sperimentale, previsto per il 4 settembre 2010, si chiamerà dunque:

STSp-1

- Paolo

Categorie:Senza categoria Tag:

Payload del primo volo sperimentale di StratoSpera

30 agosto 2010 amoroso 7 commenti

Ecco la strumentazione e le attrezzature che voleranno nel payload del primo lancio sperimentale di StratoSpera:

  • computer di bordo con datalogger per posizione GPS, altitudine, temperatura e pressione
  • tracker GPS indipendente
  • fotocamera digitale programmata per effettuare una ricca sequenza di riprese, soprattutto nelle fasi più interessanti del volo
  • sistema di cutoff automatico del volo (serve per separare il payload dal pallone e iniziare la discesa in situazioni nominali e non nominali)

Il contatore Geiger HADARP volerà in una prossima missione.

- Paolo

Categorie:Senza categoria Tag:

Primo lancio sperimentale di StratoSpera: 4 settembre 2010

29 agosto 2010 amoroso 8 commenti

Si parte per la stratosfera! Poco più di un mese fa abbiamo fissato la data del primo lancio sperimentale di StratoSpera, per il quale avevamo chiesto gli opportuni permessi. Lanceremo il pallone il 4 settembre 2010 dalla Toscana nella zona del Chianti, ribattezzata KSC ((Kianti Stratosphere Center).

Rimangono due incognite. La prima riguarda le condizioni meteo, che devono essere favorevoli per non fare allontanare troppo il punto di atterraggio del payload in luoghi inaccessibili, per esempio in mare. La seconda incognita è che, avendo potuto ordinare il pallone all’estero solo recentemente per la mancata disponibilità dal fornitore, ne stiamo ancora attendendo l’arrivo.

Segui questo blog per gli ultimi aggiornamenti. Il conto alla rovescia è iniziato.

Aggiornamento

31/08/2010 – Questa missione è stata ribattezzata STSp-1 in base alla denominazione dei lanci StratoSpera.

- Paolo

Categorie:Senza categoria Tag:

Il contatore Geiger HADARP

22 luglio 2010 amoroso 5 commenti

Matteo Negri, l’utente AstroTeo di ForumAstronautico.it, ha realizzato HADARP, un contatore Geiger che volerà su StratoSpera. In questo guest post Matteo racconta come lo ha progettato, costruito e testato. Il suo lavoro e il suo impegno seguono lo spirito delle rigorose fasi di realizzazione di un payload per una missione spaziale, anche se i prodotti industriali sono di livello superiore. Ma all’industria spaziale mancano forse l’ambiente della cucina e dell’allegria ferrarese di Matteo.

- Paolo

Ciao a tutti!
Dopo mesi di lavoro il contatore Geiger del progetto Stratospera ha preso finalmente forma!
Ed ecco a voi “HADARP: High Altitude Data Acquisition Radioactivity Probe”!
Questa è la sua storia …
Il progetto ha preso forma nel mio laboratorio-cameradaletto in questi mesi, godendo della mia piccola ma solida esperienza nella costruzione per scopo hobbistico di diversi contatori geiger, alcuni dei quali perfettamente funzionanti, e altri (purtroppo) finiti troppo presto nel bidone del rusco  .

Il contatore Geiger HADARP

Dopo aver realizzato lo schema a blocchi del circuito, sono passato alla scelta dei componenti elettronici. Questa fase mi ha portato via molto tempo, dedicato per lo più allo scartabellando dei vari datasheets, nell’affannosa ricerca di componenti, aventi un ampio range nella temperatura di funzionamento. I problemi più grandi incontrati da un pallone sonda diretto alla stratosfera, infatti, sono dovuti ai rigori di quest’ambiente. La bassa pressione dell’aria e gli sbalzi termici a cui è sottoposto durante l’ascesa, non sono assolutamente da sottovalutare. Ho cercato di scegliere così, circuiti integrati di tipo industriale (Delta T compreso tra: -55 e +125°C), eliminando da subito l’idea d’introdurre sulla board condensatori elettrolitici (soggetti a ribollimenti), sostituendoli prontamente con modelli allo stato solido al Tantalio.
Realizzato uno schema elettrico efficiente sono passato allo sbroglio del circuito stampato, seguito passo passo dall’ordine su internet dei componenti elettronici definiti in fase progettuale come “esotici”; tra questi un tubo Geiger avente la sensibilità opportuna al tipo di radiazioni da rilevare (raggi cosmici per la maggiore). Questo componente ha rappresentato in tutto e per tutto un vero e proprio calvario…

Componenti principali di HADARP

Rivoltomi per “principio” (così non posso “sbagliare” … pensavo!) a una nota casa costruttrice negli USA, ho potuto disporre di un tubo funzionante solo dopo 2 tentativi andati a vuoto! Il primo tubo che mi è stato consegnato dall’oltre oceano è arrivato schiacciato come una sogliola, mentre il secondo privo del gas a causa dell’ampolla di carico rotta nel viaggio!
Dopo varie imprecazioni per email con la casa costruttrice (alcune anche in Atlantideo pre-affondamento dell’isola), sono riuscito finalmente a farmi rimborsare per intero entrambe le spedizioni e ad avere finalmente, al terzo tentativo un tubo perfettamente funzionante, consegnatomi stavolta, “per precauzione”, in un “apposito container di metallo” degno concorrente del rack del payload di uno Space Shuttle! Hanno capito che con Astroteo non si scherza …
Terminato lo sbroglio del circuito stampato e i repentini controlli per verificare l’eventuale presenza di errori o cortocircuiti, il file “gerber” è volato in fabbrica per l’assemblaggio, e dopo due settimane, il circuito era già sul tavolo del mio laboratorio, montato e pronto per la programmazione finale.
La stesura del firmware di HADARP, ha richiesto anche la realizzazione in Visual Basic di un programma per il PC d’appoggio, quest’ultimo necessario per simulare l’unità di controllo principale del pallone. Sarebbe bastato anche il normale “Hyper Terminal” di windows, ma un lavoro titanico, richiedeva un software dedicato e sponsorizzato! E così è stato … dopo un paio d’ore di lavoro è nato “HADARP System Monitor” (vedi foto allegata IMG_3.jpg) che permette di visualizzare il traffico RS232 generato da HADARP e di inoltrargli, con un apposito pulsante, la stringa di richiesta dei dati misurati.

HADARP System Monitor

Il firmware successivamente creato e poi scaricato nel processore, in sostanza fa tre cose fondamentali:
  1. Gestisce l’elettronica per generare l’alta tensione necessaria al tubo geiger (circa 500V), contando successivamente i preziosi impulsi generati da quest’ultimo quando colpito dalla radioattività ambientale;
  2. memorizza i dati della radioattività rilevata in sei sessioni da 10 secondi l’una, registrandoli per sicurezza sulla “Fly Data EEPROM”;
  3. successivamente, quando dall’unità di controllo del pallone, attraverso la presa seriale, arriva il messaggio di richiesta “G1”, legge i dati memorizzati, li elabora e li spedisce all’unità centrale attraverso la presa seriale stessa.
A bordo della scheda HADARP è presente anche un termometro digitale integrato, che provvede a compensare attraverso un apposito algoritmo, le variazioni di tolleranza del tubo Geiger esposto al freddo dell’ascesa. Il circuito funziona con una tensione compresa tra 7 e 18V e assorbe una corrente massima di circa 39 mA. I dati misurati (colpi in 10 secondi di misura) vengono sparati in uscita sulla seriale, quando su essa arriva una stringa di richiesta “G1″, quest’ultima inviata a 9600 bps.
Una volta terminata la stesura del firmware, ho passato HADARP ai rigorosi controlli per l’idoneità al volo. I test eseguiti sono stati i seguenti:
  1. .Stress meccanico;
  2. .Stress termico;
Per il test n°1 ho provveduto ad alimentare il circuito con un pacco-batteria al litio, legando il tutto (Hadarp compreso) al piatto di un vecchio giradischi munito di un apposito contagiri digitale. Dopo averlo centrifugato per più di un’ora alla massima velocità, ho provveduto a controllare il funzionamento del circuito a banco, nonché le misure rilevate, notando che tutto aveva funzionato perfettamente. Successivamente ho provveduto a far cadere solo la board HADARP sul pavimento (il tubo Geiger no, per l’amor di Dio!!!) e ho notato che nessuna saldatura aveva ceduto … risultato test n°1 … ready for launch!
Per il test n°2 ho provveduto a rinchiudere la board HADARP e il tubo Geiger nel congelatore di casa assieme ai gelati e ai salami ferraresi … Dopo due ore a -30°C, HADARP e il suo fedele sensore, funzionava ancora perfettamente, apparendo al primo approccio congelato, come la DeLorean di Ritorno al Futuro, dopo un intrepido viaggio nel tempo. Il circuito era ricoperto di brina, aveva il LED di sistema appannato, ma emanava ancora un rassicurante lampeggio rosso di “Program in progress”! Una volta al banco, valutando i dati memorizzati, ho rilevato (per fortuna) bassi valori di radioattività nei cibi presenti, eccetto un picco anomalo degno di nota, rilevato dopo circa mezz’ora di congelamento (e contrassegnato da me stesso con la scritta: “wow”), sfortunatamente non più ripetutosi per l’intera fase di stoccaggio a -30 … risultato test n°2 … ready for launch!
A questo punto, ho dichiarato HADARP idoneo al volo, dotandolo subito, nelle parti più suscettibili, degli appositi cappucci rossi recanti la scritta: “Remove before fly”.
Resto in attesa delle istruzioni precise per i controlli finali dal resto del team.
A presto!
Astroteo
Teotech Corp. Laboratory
Categorie:Senza categoria Tag:

Test dei sensori di temperatura e pressione e del GPS

17 giugno 2010 amoroso 3 commenti

Il 6 e 7 giugno 2010 Francesco Sacchi ha effettuato una serie di test sulla scheda madre per il primo volo di StratoSpera, in particolare per verificare i sensori di temperatura e pressione e il GPS. In questo guest post racconta come ha individuato e risolto alcuni problemi. Francesco ci aiuta nello sviluppo della scheda madre insieme con Develer s.r.l., la sua società di progettazione hardware e software.

I geek interessati ai dettagli tecnici e al debugging si mettano comodi, lascio la parola a Francesco.
- Paolo
Come accennato in un altro post, eccomi qui a fare un resoconto delle ultime attività svolte a cavallo tra domenica e lunedì scorsi [6 e 7 giugno 2010].
Per prima cosa abbiamo terminato di montare i sensori di temperatura, foto allegata:
Scheda madre di StratoSpera

Scheda madre di StratoSpera

Quel filo nero che termina con un puntolino giallo è il sensore di temperatura esterno di tipo NTC, ecco il datasheet: http://www.meas-spec.com/WorkArea/downloadasset.aspx?id=6047&LangType=1033
Un altro sensore identico è montato direttamente sulla scheda per rilevarere la temperatura interna.
In passato avevo detto che per la temperatura interna potevamo usare un altro tipo di sensore (tmp123 di Texas) che è digitale. Ho optato per usare due sensori identici NTC in modo da avere lo stesso codice che legge la temperatura, usato per entrambi i sensori. Questo è stato un bene, dopo spiego perché.
Abbiamo fatto un po’ di prove sui sensori di temperatura e su quello di pressione, ecco una schermata con il log dei dati:
Log dei sensori di temperatura e pressione

Log dei sensori di temperatura e pressione

Come si vede le due temperature sono pressocché identiche dato che i sensori erano molto vicini.
Per testare le cose per bene, ho simulato che la temperatura fosse molto bassa, intorno a -40°C. Fare questo è molto semplice quando il sensore è una resistenza variabile: ho semplicemente sostituito il trasduttore con una resistenza fissa di valore uguale a quello che le tabelle danno per un sensore di quel tipo a -40°C.
Risultato: la temperatura letta non scendeva sotto -6°C!
Ci abbiamo lavorato un bel po’, poi oggi pomeriggio [9 giugno 2010] abbiamo scoperto che la scheda di sviluppo che utilizziamo aveva un difetto, una specie di incisione che tagliava una pista sul circuito stampato! Una cosa incredibile, mai capitata prima, fatto sta che questa pista portava alimentazione al convertitore ADC interno del microprocessore, e senza alimentazione, i valori acquisiti dai sensori erano completamente sballati quando si andava fuori da un range di valori di metà scala. Una cosa che non ci saremmo mai accorti se non avessimo fatto questi test.
Domenica era una bella giornata, molto soleggiata e un po’ afosa.
Abbiamo deciso di fare una scampagnata e visto che c’eravamo, ci siamo portati dietro la scheda e la radio.
Sabato avevo messo su un firmware in grado di leggere la posizione GPS e inviarla via radio, ogni due minuti.
Ho predisposto anche  una stazione base presso la nostra sede, in modo da ricevere i messaggi inviati dalla scheda.
Ecco una foto del payload collocato sul cruscotto della mia macchina:
Payload sul cruscotto della macchina

Payload sul cruscotto della macchina

Ecco un log di tutti i messaggi ricevuti:
I messaggi seguono il protocollo APRS, però la prova è stata interessante, ecco una mappa con solo due dei punti ricevuti:
E’ interessante notare che appena ho iniziato a salire in altitudine un po’, subito la ricezione radio è migliorata.
Il punto più alto a cui siamo arrivati, era a soli 632m e ha consentito una ricezione pressoché perfetta dei messaggi, anche al punto di massima distanza che era di 8km!
Questa prova ha messo alla luce un altro problema, prontamente risolto.
Il GPS, quando non ha un fix stabile, commette errori di posizionamento, anche sull’altitudine.
Questi errori possono essere anche di qualche centinaio di metri. Se l’altitudine è bassa, (e a Calenzano è di circa 70m) può succedere che con l’errore essa sia anche negativa.
Niente di male, una altitudine negativa ha perfettamente senso, peccato che il nostro codice non fosse pensato per gestirla, con il risultato che non aspettandosi misure negative, i dati andavano in overflow facendo schizzare l’altitudine inviata nei messaggi fino a 65500 metri! Questo comportamento è visibile nei file di log, all’inizio, quando il GPS ha appena preso il fix.
Meno male abbiamo fatto questo test, altrimenti, in caso di fix GPS incerto, avremmo corso il rischio di attivare il cutoff per sbaglio!
Alla fine della giornata, eccoci parcheggiati al fresco in cima ad un monte:
Auto con il payload per i test

Auto con il payload per i test

Per adesso basta così, vi anticipo che in questi giorni lavoreremo al sistema di salvataggio su SD, e contiamo entro fine mese di fare un’altra gita sui monti andando più lontano questa volta.

Alla prossima!
- Francesco Sacchi
Categorie:Senza categoria Tag: