Archivio

Archivio autore

Dando forma ad un sogno

26 marzo 2009 michael Nessun commento

Ciao a tutti.

Innanzitutto voglio ringraziare coloro i quali, anche grazie a SatExpo, hanno lasciato commenti di supporto e offerte di aiuto. Ci sentiamo meno soli in questa avventura.

Questi sono giorni di svolta. Il progetto StratoSpera ha sonnecchiato nei nostri cassetti, emergendo in chiacchierate notturne, o discussioni davanti ad una pizza nei nostri incontri, ogni volta aggiungendo un pezzetto del puzzle, fino ad ora. Ora i bordi del puzzle sono delineati, le idee vanno schiarendosi e siamo pronti a fissare obiettivi precisi e a cominciare a trasformare in qualcosa di tangibile (hackerabile, toccabile, collegabile, cortocircuitabile, GONFIABILE) quello che fin’ora è stato un sogno.

La scheda è stata sostituita, nel progetto, la radio ha qualche opzione che vogliamo esplorare, l’idea del software prende forma e aspetta solo dell’hardware su cui correre. Tutto sembra piu’ reale che mai. Ed è ora che il vostro supporto (morale, economico, di know how) diventa sempre più prezioso.

Cominciamo ad alzarci dal suolo. Tenete d’occhio queste pagine nel prossimo futuro.

Stay tuned, more to come

Michael Sacchi
Stratospera Payload Specialist

Categorie:Senza categoria Tag:

Prime ipotesi di payload

16 febbraio 2009 michael 7 commenti

Essendo un progetto amatoriale, Stratospera non segue i canoni di progettazione e integrazione tipici di un progetto di ricerca. Le competenze del team non sempre si accompagnano ad un’adeguata esperienza, ed è fisiologico che le ambizioni e gli obiettivi siano fluttuanti e cambino nel tempo.

I punti “fermi” sui quali la discussione sembra essersi stabilizzata sono gli obiettivi minimi del payload, ovvero del carico utile trasportato dal nostro pallone.

  • Fotografia, con particolare obiettivo di rilevare il “nero” del cielo, oltre gli strati piu’ densi dell’atmosfera
  • Rilevazioni atmosferiche di base, come temperatura e pressione (e forse livelli radioattivi)
  • Rilevazione della posizione e trasmissione della stessa a terra per un successivo recupero.

Diverse piattaforme tecnologiche rispondono ai requisiti, alcune più economiche, altre più costose, alcune facili da sviluppare, altre che richiedono studio ed analisi approfonditi.

In via del tutto esplorativa, stiamo valutando di testare la flessibilità di una piattaforma che ha la sua collocazione naturale sulle scrivanie, ovvero una scheda VIA EPIA mini ITX, con processore VIA C7.

La scheda non è dissimile da quella che è contenuta nei vostri personal computer fissi, fatto salvo per un fattore di forma molto contenuto e un consumo energetico ridotto. I punti deboli, ipotizzando il suo uso per la missione, derivano dall’eccessivo calore prodotto dalla CPU, calore che a terra viene allontanato con convezione forzata grazie ad una ventola, ma che si rivela problematico nell’ambiente in cui il nostro carico si troverà a funzionare, ovvero in una sostanziale assenza di atmosfera.

Vi vogliamo rendere partecipi del “resoconto” di una serata di test esplorativi su un esemplare di VIA Epia in nostro possesso, volti a prendere confidenza con il sistema e valutarne l’adeguatezza al volo.

Il tono del resoconto è “scanzonato”, perchè diretta testimonianza delle comunicazioni interne al team.

StratoSpera Test

Ieri sera ho effettuato i primi test su quello che sarà il probabile nucleo del payload, ovvero una scheda madre mini-ITX con un processore VIA C7 da 1,5 GHz.

Gli obiettivi della serata erano tre.

  • Verificare il funzionamento di un alimentatore DC-DC da me acquistato per il progetto (è come l’alimentatore contenuto nel vostro computer fisso, con la differenza che accetta tensioni continue a 12 V in ingresso, invece della normale tensione di rete da 220V, in alternata. E’ necessario per alimentare la scheda con una batteria)
  • Misurare l’assorbimento di corrente del sistema “nudo”, senza ulteriori periferiche.
  • Verificare il funzionamento della scheda e del processore in modalità “fanless”. Ovvero scollegando la ventola che toglie calore al dissipatore metallico montato sopra il processore. A 30 Km di altezza c’e’ poca aria da spostare….

Ho rimesso piede dopo mesi nel mio “laboratorio”, acceso un glorioso FT-100 su Virgin Radio (è come usare una ferrari per andare a fare la spesa, diciamo), e ho sistemato il “necessaire” sul tavolo.
Ho innestato l’alimentatore sulla scheda, ho predisposto l’amperometro in serie al circuito di alimentazione, ho collegato il tutto al mio fido alimentatorino…e dopo un attimo di panico dovuto al fatto che non trovavo i pin da cortocircuitare per l’accensione ( mrgreen) ho dato fuoco alle polveri.

Segue una scena degna di Ken Mattingly nel simulatore del Command Module di Apollo 13: occhio FISSO sull’amperometro. Il mio alimentatore fornisce al massimo 2.5 A (3.5 per BREVISSIMI periodi) prima di soccombere. Un valore superiore ai 2.5 Ampere mi avrebbe indotto a staccare tutto d’urgenza.

Un alimentatore da 25 A era a pochi cm di distanza…ma usarlo avrebbe significato spegnere la musica. Ma “silence is not an option”.

Il consumo raggiunge un picco di 2.5A nelle primissime fasi del boot (che in un esemplare di volo verrebbero svolte con la batteria in carica) mentre si attesta tra 1,6 e 1,8 A durante il funzionamento a regime. Cosa questo significhi, in termini economici e di massa, per la batteria del pallone dipende dalle prestazioni e dai prezzi delle batterie in commercio. Non ho ancora indagato in quella direzione.
La ventola di raffreddamento incide sul consumo per 50mA. Nulla.
La connessione di uno schermo sulla porta VGA della scheda (necessaria per il setup iniziale ma del tutto inutile in seguito) è ininfluente.
L’utilizzo di due memorie flash usb (“chiavette usb”, vedi in seguito) è trascurabile.

Amperometro

La temperatura di esercizio del processore raffreddato dalla ventola è di 38°C (esatto, come gli esseri umani) . Nella utility di monitoraggio, all’interno del menu di setup del BIOS della scheda, ho tenuto sotto controllo il valore a ventola spenta. Molto rapidamente (in quella modalità  il processore gira alla frequenza massima anche se non ha nulla da fare) ha raggiunto i 60°C, temperatura che causa lo spegnimento istantaneo della scheda. Tale limite di sicurezza è innalzabile a 70, 75°C  o disattivabile completamente. Non ho trovato indicazioni sul limite termico di funzionamento del processore cercando su internet. C’è un’impostazione che riduce la velocità  del processore in caso di superamento di una soglia impostabile, ma tale soglia si autoresetta a 70° ogni volta che la cambio e non sono sicuro del funzionamento.

A tal proposito ho chiesto consulenza a un ragazzo del team di pESApod, che montava una scheda molto simile, funzionante in modalità  fanless. (update: il loro processore era un Via Eden, progettato per funzionare in modalità fanless)
Come ultimo test, considerato che erano le due del mattino e mi si stava spegnendo la stufa, ho provato ad avviare una distribuzione linux (Damn Small Linux, contenuta in meno di 50 MB). La chiave usb utilizzata faceva il boot correttamente, ma il kernel non riusciva a montarla in seguito per caricare il resto del sistema. Ho risolto affiancandoci una seconda chiave (quella che mi porto sempre in tasca) con solo il sistema copiato sopra (non avevo voglia di backuppare piu’ di 1 GB di roba per formattarla e renderla avviabile). DSL funziona correttamente ma ho problemi a leggere la temperatura del processore. Ho la sensazione che con il sistema operativo avviato, e i relativi controlli ACPI, scaldi meno, ma non posso averne certezza, in quanto la lettura di temperatura effettuata dalle routine ACPI del sistema operativo è fissa a 40 °C.

Ho chiuso la serata con un tentativo di misurazione “creativo” della temperatura del processore sotto sforzo, col sistema operativo attivato.
Ho tenuto il processore al 100% (“ls -alR /”, non mi veniva in mente altro!) per un po’ di tempo, poi ho resettato la scheda leggendo la temperatura nella prima schermata dell’avvio. 66°C (avevo tolto il limite). Se fosse indicativo, sarebbe un valore tollerabile.

Devo riflettere su questi dati, ma volevo rendervene partecipi.

Nota di colore: mentre effetuavo i test, lo Unix time ha raggiunto il valore di 1234567890. Sono felice di aver trascorso quel momento, insignificante per i più, ma “divertente” per una ristretta cerchia di “geek”, svolgendo un’attività particolarmente “nerd”.

UnixTime
Michael Sacchi
StratoSpera Payload Specialist.

Categorie:Senza categoria Tag:

Payload, ovvero “si, ma lassù che cosa volete fare?”

22 novembre 2008 michael 3 commenti

Ok, ma una volta che siamo a 30 km di altezza, cosa facciamo?

L’ambizioso progetto di lanciare un pallone stratosferico apre il campo a mille possibilità, ed è difficile scegliere cosa è alla nostra portata, tecnologicamente e economicamente.

Ci stiamo ispirando al payload delle missioni che ci hanno dato la spinta per intraprendere questo progetto e abbiamo stabilito una serie di caratteristiche e obiettivi, in ordine di “desiderabilità”, che il nostro payload dovrà avere:

  1. Supporto al tracking (e recupero) del payload- Siamo orientati al tracking tramite GPS e APRS su frequenze radioamatoriali (banda dei 144Mhz)
  2. Raccolta immagini dell’orizzonte, con l’obiettivo di rilevare la curvatura della terra e il “nero” dello spazio, eventualmente georeferenziate.
  3. Raccolta di dati sulla temperatura in funzione dell’altitudine
  4. Raccolta di dati sulla pressione in funzione dell’altitudine
  5. Raccolta di dati sulla radiazione in funzione dell’altitudine
  6. Raccolta immagini del pallone, per verificare le dimensioni in quota (il pallone, lanciato con un diametro di 2 metri, raggiunge i 13)
  7. Registrazione dei “suoni” percepiti dal payload (promesso: non faremo un episodio di Astronauticast  con 2 ore di “vento” da ascoltare, per quanto sarebbe ottimo per l’insonnia! :-) )
  8. Trasmissione di immagini in tempo reale o mediante SSTV (in una futura versione del payload)

Il sistema di tracking è pressochè definito, e consterà di un trasmettitore FSK Byonics da 300mW, unito ad un GPS distribuito dalla stessa compagnia. L’indipendenza dal resto del payload permette di avere meno “incertezze” e, anche in caso di guasto del computer ad esempio, possiamo recuperare il nostro hardware.

Per le immagini e il resto stiamo esplorando diverse alternative tecnologiche, tenendo conto di vincoli di peso, di costo, e soprattutto energetici. Anche la scelta del pacco batterie sarà effettuata con i medesimi criteri, e le due cose sono, ovviamente collegate.

Nelle prossime settimane comincerò a fare qualche misurazione di consumo per una scheda madre mini-itx già in nostro possesso, che è una buona candidata per essere il “cervello” del nostro payload. Per i più geek tra di voi, tempo permettendo, documenterò le mie fatiche.

Altre opzioni in considerazione vanno dall’uso di un router wifi con supporto usb, opportunamente modificato per permettere l’esecuzione di codice scritto da noi, a un computer “gumstix” grosso quanto un pacchetto di gomme da masticare.

Qualsiasi suggerimento, riguardo il payload, è bene accetto! Lo spazio per i commenti qui sotto è a vostra disposizione.

Stay tuned, more to come!
Michael Sacchi, pallone gonfiato, payload specialist.

Categorie:Senza categoria Tag: