Účast: David Kučera, David Holas, Jaroslav Kousal, Marian Váňa, Michal Pokorný, Václav Turjanica, Petr Piksa, Jan Doležal, Aleš Holub

Hlavní závěry:
- potvrzena koncepce družice složené ze sběrnicí propojených inteligentních samostatných modulů
- návrh sběrnice Davida H. byl přijat pro implementaci do prototypů jednotlivých modulů
- musíme definovat typy zpráv, pomocí kterých budou moduly vzájemně komunikovat
- jednotlivé moduly budou "garanti" vyvíjet samostatně (splnění potřebných parametrů, komunikace)
- zkusíme využít Honzových zkušeností a dále postupovat podle ověřených projektových metodik

Stav vývoje dílů (uvažovaných v současné sestavě družice [v hranaté závorce jsou "garanti"]):
- přijímač a vysílač A [EMP]:
--- snaha o integraci antény do konstrukce družice (specialistou na antény je Petr)
--- orientace na pásmo 2,4 GHz a výš (dobrý průchod atmosférou, malá a pevná anténa)
--- anténa pro pásmo 2,4 GHz může být na spodní stěně družice (zisk snad až 10 dB, úhel cca 50°)
--- jeden experiment bude s obvody nRFE bez zabezpečení (P.Mochura)
--- druhý experiment bude s procesorem a zabezpečeným kódováním (M.Pokorný)
- přijímač a vysílač B (radiomaják)[Robert (nebyl přítomen)]:
--- čekalo se na schválení sběrnice
--- dotaz od M.Váni: Je možno využít pásmo 2,4 GHz? (kvůli jednotné anténě bez rozvinování)
- solární články [EMP]:
--- pro omezení pnutí bude vyzkoušen pružný plošný spoj (podklad pod články)
--- články budou jen na bočních stěnách družice (horní stěna bude pro pohon [tether/plachta])
- pasivní stabilizace [Marian]:
--- podle propočtů stačí malý permanentní magnet a indukované proudy v konstrukci družice
--- k rozumnému ustálení by mělo dojít během několika týdnů (max.)
--- předběžně dohodnuto, že pasivní stabilizace (magnet nebo stále pracující elektromagnet) na družici bude
- aktivní stabilizace (a orientace) [Jarda, David H.]:
--- lze využít teorie z CubeSatu nCube (dobrá dokumentace, ale v kosmu neověřeno)
--- podle Jardy je aktivní stabilizace tak účinná, že může zastavit rotaci do půl oběhu kolem Země
--- měl by k tomu stačit příkon cca 100 mW po dobu několika minut (s vyššími špičkami) a následné průběžné korekce (průměrný příkon <1mW)
--- je to výpočetně dost náročná záležitost (pokud se použijí Kálmanovy filtry jako na nCube), ale pro naše účely půjde zřejmě zjednodušit
--- základ stabilizačního algoritmu byl navržen a počítačove simulován (Jarda)
--- David H. připravil použitelný numerický model mg. pole Země
--- je třeba zjistit okamžitý vektor mg. pole Země (magnetometry, to stačí na základní stabilizaci)
--- úplná trojrozměrná stabilizace vyžaduje i zjistit polohu Slunce (měřením proudů ze sol.čl.) a/nebo průběžné dodávání keplerovských elementů dráhy ze země na družici
--- Jarda s Davidem budou pokračovat pokusem o počítačovou simulaci chování systému i družice
- napájecí zdroj [David K.]:
--- prototyp je hotov, ale není zatím k dispozici
--- David deklaroval ochotu ho zafinancovat a popsal jeho konstrukci
--- zdroj je velmi pokročilý a umí řídit dodávku energie podle stavu sol. článků a akumulátorů
--- umožňuje realizovat solidní nabíjecí automatiku pro akumulátory
--- rozlišuje několik energetických stavů (dostatek, mírný nedostatek, kritický nedostatek)
--- umožňuje měření napětí a proudů v hlavních uzlech (použitelné k orientaci podle Slunce)
--- dává napětí 2,8 V, 3,3 V a 5 V
--- podle experimentů ve vakuu (Marian), bude třeba věnovat pozornost vakuové kompatibilitě akumulátorů (Li-Pol)
- kamera/foťák [David K.]:
--- část prototypu je hotova, ale není zatím k dispozici
--- David deklaroval ochotu ho zafinancovat a popsal jeho konstrukci
--- jde o speciální snímací čip a speciální optiku
--- zpracování signálu ze snímacího čipu bude v připojeném procesoru (to zatím nerealizováno)
--- je třeba zvážit ochranu čipu před dlouhodobějším vystavením přímému pohledu do slunce
- tether [Marian]:
--- probíhají experimenty s rozvíjením, je třeba další vývoj a ověřování
- plachta [Radovan, Aleš]:
--- zatím bez pokroku
--- zatím akceptován předpoklad vlastního procesoru pro ovládání plachty
- komunikační sběrnice [David H.]:
--- David vysvětlil principy jím navržené sběrnice
--- každý modul má pevně přidělenou adresu, která určuje jeho logické pořadí při komunikaci
--- přidělené adresy tvoří logický kruh, protokol je typu multimaster-token ring
--- David funkčnost sběrnice ukázal na systému s šesti procesory a docela mohutnou komunikací
--- experiment prokázal dobrou použitelnost pro naše potřeby (propustnost přes 100kB/min.)
--- tato sběrnice byla schválena pro implementaci do prototypů dílů (základní SW je hotov)
--- David aktualizuje dokumentaci sběrnice a dá ji na http://projekt.kosmo.cz/

Obecně:
- ze sestavy základních dílů vypadl modul "Měření" a "Hlavní počítač"
- každý modul bude samostatně "chytrý" (s procesorem), takže "řídicí centrum" není třeba
- jednotlivé moduly budou mít pokud možno vlastní senzory (které potřebují k funkci)
- podle potřeby a možností moduly využijí data z jiných modulů pomocí hlavní sběrnice
- některá data mohou moduly na sběrnici posílat periodicky bez vyžádání (stav, senzory)
- speciální data mohou být mezi moduly posílána pomocí definovaných zpráv (nutno definovat)
- je třeba přesněji definovat parametry, funkce a služby jednotlivých modulů
- nejprve zkusíme systém rozchodit "na stole" a teprve pak ho "kosmicky" testovat (vakuum, teplo, vibrace)
- testování hardware (snadno dostupné možnosti)
--- vakuová komora (2Pa) - EMP Centauri
--- teplotní komora (-75 až +180°C) - EMP Centauri, (-? az +?°C) - Cybertex
--- vibrační stolice (20G) - Cybertex
- rádia musí komunikovat na vzdálenost 1000 km (při pozemních testech alespoň na 100 km)
- opakovaně byla zmíněna možnost využití diplomových prací na VŠ k řešení některých problémů
- Honza využije svých zkušeností a zavede do naší spolupráce standardní projektové metodiky
- vyměníme si detailnější kontakty (např. telefony a ICQ)
- budeme zaznamenávat všechny dílčí výsledky (na webu)
- prověříme možnost využití jiného groupware

Další činnost:
- příští schůzka bude 14.1.2005 na stejném místě (opět u Davida Kučery v Praze, Cybertex)
- musíme přesněji definovat parametry, funkce a služby (data) jednotlivých modulů
- musíme definovat typy zpráv, pomocí kterých budou moduly vzájemně komunikovat
- jednotlivé moduly budou "garanti" vyvíjet samostatně (splnění potřebných parametrů, sběrnice)
- zkusíme využít Honzových zkušeností a dále postupovat podle ověřených projektových metodik

Zapsal Aleš Holub