Kosmonautika (úvodní strana)
Kosmonautika@kosmo.cz
  Nepřihlášen (přihlásit)
  Hledat:   
Aktuality Základy Rakety Kosmodromy Tělesa Sondy Pilotované lety V Česku Zájmy Diskuse Odkazy

Obsah > Diskuse > XForum

Fórum
Nejste přihlášen

< Předchozí téma   Další téma ><<  1    2    3    4    5    6  >>
Téma: konstrukce satelitu
25.7.2005 - 22:53 - 
V zásadě by to mělo fungovat, alespoň mi to tak připadá. Ovšem až se to postaví, určitě se objeví mouchy. Nedokážu posoudit kolik času bude potřeba na vychytání much, ale jste-li schopný a trpělivý konstruktér, s chutí do toho. 
30.7.2005 - 18:45 - 
quote:
V zásadě by to mělo fungovat, alespoň mi to tak připadá. Ovšem až se to postaví, určitě se objeví mouchy. Nedokážu posoudit kolik času bude potřeba na vychytání much, ale jste-li schopný a trpělivý konstruktér, s chutí do toho.

OK pustim se do toho. Jen vyrobni termin je tak 1-2mesice. Mam celkem plno...
 
01.8.2005 - 14:50 - 
quote:
Nad urcenim drahy dost premyslim. Myslim, ze v zasade pujde odvodit polohu druzice z mereni mag. pole, ale je tam jeste stale hodne nejistot, proto se snazim zjistit o co vsechno se lze jeste oprit.

Pokud jde o určení polohy družice, jsou na netu ke stažení kepleriány aktuálně letících družic, našel jsem i několik cubesatů. Vhodný program, do nějž se pak tyto zadají, umí k dané družici vypočítat, alespoň z mého pohledu, všechny myslitelné aktuální údaje, včetně průletových oken k zadanému místu na zemi. Navíc přímo přes port řídí rotátory pro směrování antén.
 
02.8.2005 - 15:41 - 
Nebyl jsem tu nějakou dobu, takže si dovolím se vyjádřit až ex-post:

a) akcelerometr. Většina akcelerometrů,které jsou prodávány, jsou v podstatě piezotenzometry. Proto Vám při volném pádu nenaměří nic, tj. žádné zrychlení. Nedá se tedy jimi ani určovat zrychlení či zpomalení na eliptické dráze. Jsou maximálně použitelné pro měření rychlé rotace v ot/s.

b) navrhovaný systém s cívkami, kde chvíli měřím a chvíli reguluji ... jsem proti, spojovat tuto funkci do jedné civky. Na Mimoze došlo právě k poruše přepínacího členu, Proto doporučuji dodělat tam ještě jednu měřící cívku (resp. pár zavitů navíc). Významně se tím sníží riziko poruchy stabilizace družice.
Jinak na nCube používali meděný vodič jako cívku:
http://128.39.102.180/documents/masterthesis/svartveit03.pdf

c) určení polohy z kepleriánů ... ano, to je možné, ale nevím, jak rychle zařadí NORAD těleso do výpisu a jak by se s ním dalo předběžně dohodnout na zasílání údajů přímo nám. Dále je problém (ne velký), že bude najednou vypuštěno několik satelitů, takže který z nich je ten náš?

d) A pak poloha ještě sama o sobě neurčí orientaci (natočení satelitu). Myslím, že to jsem chtěli řešit telemetrií napětí solárních článků v majáku. Resp. jsme se kdysi bavili o zasílání napětí článků pro rotace řádově desítky sekund a výše a napětí na akcelerometrech umístěních v rozích soustavy pro rotaci v řádech 0.1 Hz a výš. Koncepce radiomajáku je opuštěná?

e) dále mám otázku. Jak moc můžeme definovat dráhu našeho CubeSatu? Pokud bude létat přes póly, máme problém, ale pokud by létal s malým sklonem, stačí pro stabilizaci "kousek" supravodivého materiálu. Alespoň takhle chtějí stabilizovat jednu družici ...
Dále proč se upustilo od gravitační stabilizace družice? (tj. vysunutím nějaké části družice ven z těla?) Nejlépe, ať je to rovnou anténa?

e1) našel jsem text, kde se píše, že úhlová rychlost objektů po vypuštění z PPOD je pod 20st/s, tj. max. cca. 4 ot/min !!
link na zdroj: http://cubesat.calpoly.edu/_new/dnepr2004/ppod_icd_excerpt.pdf str.63

f) s určením polohy a kepleriánů by mohlo pomoci, pokud by družice vysílala na amatérském pásmu, neb tak bychom měli spousty "sledovacích" stanic po celém světě a dráha by se dala vyprecizovat během pár obletů.

Ještě zajímavý odkaz s tímto nepřímo souvisejících:
O tethru na mikrosatu http://www.tethers.com/microPET.html
 
02.8.2005 - 21:47 - 
quote:
určení polohy z kepleriánů ... ano, to je možné, ale nevím, jak rychle zařadí NORAD těleso do výpisu a jak by se s ním dalo předběžně dohodnout na zasílání údajů přímo nám. Dále je problém (ne velký), že bude najednou vypuštěno několik satelitů, takže který z nich je ten náš?

... do vysunutí pohonu bude dráha našeho satelitu shodná s ostaními současně vypuštěnými družicemi. Po vysunutí pohonu, když jej "uděláme dostatečně velký a jasný" tedy o celkové ploše asi 1m2 nebo větší, může být jasnost našeho Cubesatu na mezi viditelnosti pouhým okem nebo lepší, čili je to rutinná záležitost určit dráhu pro amatéry astronomy, jak na tomto fóru již bylo zmiňováno před pár týdny.


(quote) d) A pak poloha ještě sama o sobě neurčí orientaci (natočení satelitu). Myslím, že to jsem chtěli řešit telemetrií napětí solárních článků v majáku. Resp. jsme se kdysi bavili o zasílání napětí článků pro rotace řádově desítky sekund a výše a napětí na akcelerometrech umístěních v rozích soustavy pro rotaci v řádech 0.1 Hz a výš. Koncepce radiomajáku je opuštěná?

... s radiomajákem(ky) se samozřejmě počítá


(quote) e) dále mám otázku. Jak moc můžeme definovat dráhu našeho CubeSatu? Pokud bude létat přes póly, máme problém, ale pokud by létal s malým sklonem, stačí pro stabilizaci "kousek" supravodivého materiálu. Alespoň takhle chtějí stabilizovat jednu družici ...
Dále proč se upustilo od gravitační stabilizace družice? (tj. vysunutím nějaké části družice ven z těla?) Nejlépe, ať je to rovnou anténa?

... se supravodičem se sice počítá, ale otázka je zda se jej podaří uchladit na takovou teplotu aby byl opravdu supravodivý. Počítám totiž s pasivním chlazením pouze radiací a stíněním.
Gravitační stabilizace ... anténa sama o sobě nemá žádné tlumení, viz rozbor v souboru dampers.doc na projektu. Proto se od toho upustilo. Stejně tak když vysuneme cokoliv jiného bude problém s tlumením. Nikoliv však v případě cívek které mají výborné tlumicí účinky vlivem indukovaných proudů. I tether s procházejícím proudem by měl do určité míry tlumit kyvy popř. rotaci (při jeho vhodném tvaru). Jinak po vysunutí tetheru se počítá s jeho stabilizací i s pomocí gravit. gradientu


(quote)e1) našel jsem text, kde se píše, že úhlová rychlost objektů po vypuštění z PPOD je pod 20st/s, tj. max. cca. 4 ot/min !!
link na zdroj: http://cubesat.calpoly.edu/_new/dnepr2004/ppod_icd_excerpt.pdf str.63

... výborně, to se zásadně neliší od námi odhadovaných max. 6-10sec. na jednu otočku


(quote) f) s určením polohy a kepleriánů by mohlo pomoci, pokud by družice vysílala na amatérském pásmu, neb tak bychom měli spousty "sledovacích" stanic po celém světě a dráha by se dala vyprecizovat během pár obletů.

... s amatérským pásmem počítáme, Pavel Mochura připravuje přihlášku


(quote)Ještě zajímavý odkaz s tímto nepřímo souvisejících:
O tethru na mikrosatu http://www.tethers.com/microPET.html



... tento typ tetheru se hodí spíše pro rovníkovou dráhu, pro polární dráhu by příliš účinný nebyl vzhledem k jeho vertikální stabilizaci. Dále je navržen (jestli se nepletu) pro družice o hmotnosti nad 100kg. Dále má pasivní kontaktory, čili může fungovat do maximálně asi 1000km výšky.
 
04.8.2005 - 13:48 - 
Ahoj Mariane, Aleši a další,

děkuji za odpovědi, ale chci se zeptat na jinou věc. Loni jsme se účastnili Holického setkání radioamatérů. Zařizoval jsem to a byl tam velký ohlas. Přesněji lidi byli rádi, že se něco děje.
Chcete (chceme) se letos také zúčastnit? Ukázat vývoj, který se za ten rok udál a opublikovat pár článků ve sborníku? To vše by bylo v našich možnostech.
Jediná věc je, že Holice se konají 26. - 27. 8. 2005, což, alespoň myslím koliduje s pražským setkáním KK. Jak to tedy, Mariane a další, vidíte?
Další věc je, že nemohu zaručit, že se mi to ještě narychlo povede dohodnout, jsou to přeci jenom tři týdny. Bohužel jsem letos neměl tolik času (ačkoliv loni jsem to zařizoval o týden dříve)
Véna
P.S.: Koneckonců by to mohla být už oficiální akce i KK a možnost jej tam prezentovat ... Co Ty na to Martine?
 
13.9.2005 - 11:01 - 
Do projektu jsem poslal prvni verzi popisu komunikacni sbernice satelitu, zatim jen fyzicka vrstva, co nevidet bude rozsireno o linkovou a transportni vrstvu.

Elektronici muzou nakreslit popsanou elektroniku ve skutecne podobe, s jednim pouzdrem to asi nepujde, alespon jsem nic nenasel, leda by to byl rychly PIC. Bylo by dobre, kdyby ty MKO a hradla pokud mozno mely minimalni spotrebu.
 
13.9.2005 - 18:30 - 
Kde to tam je? Nic tam nevidím. 
14.9.2005 - 07:27 - 
quote:
Kde to tam je? Nic tam nevidím.


Moje chyba, zapomnel jsem zaskrtnout access jako GROUP, bylo to default personal, takze se to mozna nezobrazilo.

Nazev je Komunikacni_sbernice_1_0.doc ze 13.9.2005
 
14.9.2005 - 12:52 - 
Komunikacni_sbernice_2_0.doc je nahrana na projektu.
Tentokrat ma pristup GROUP.
Jdu implementovat :-)
 
14.9.2005 - 15:25 - 
K fyzické vrstvě

Má externí watchdog nějaký zásadní význam? Nestačí použití jen dvou MKO? Zacyklení může přeci hlídat i interní watchdog. Externí by měl význam snad jen při nějaké hardwarové poruše, kdy odejde čítač který interní watchdog používá, nebo když odejde krystal. Pak ale zrácí význam i samotný reset, protože je procesor pravděpodobně v háji.
Ale možná jsem něco přehlédl.
 
15.9.2005 - 07:54 - 
quote:
Má externí watchdog nějaký zásadní význam? Nestačí použití jen dvou MKO? Zacyklení může přeci hlídat i interní watchdog. Externí by měl význam snad jen při nějaké hardwarové poruše, kdy odejde čítač který interní watchdog používá, nebo když odejde krystal. Pak ale zrácí význam i samotný reset, protože je procesor pravděpodobně v háji.
Ale možná jsem něco přehlédl.


Navrhuji na zaklade zkusenosti. Interni WD se inicializuje, zapina i vypina instrukcemi CPU v nejakych ridicich registrech, nelze vyloucit pri nahodne poruse (vykyv napeti, energeticka castice), ze jej program v CPU nevedomky deaktivuje. Pak by jedinou zachranou na restart tohoto modulu bylo vypnuti a zapnuti napajeni ze strany Power Modulu. A jsou samozrejme poruchy, ktere RESET nevyleci. Ale je jich malo, nesetkavame se.

Vsechna nase prumyslova zarizeni vybavujeme externim WD. Neni to neco, bez ceho by to nemohlo fungovat, ale je to dalsi bezpecnostni bariera a tedy dalsi radove zvyseni spolehlivosti jednotliveho modulu. Navic funkce WD, hlidace VCC apod. jsou integrovane v supervizor obvodech, ktery by tam (uz z duvodu hlidani napeti na palubni siti), napr. MAX691, mel byt.

Pro funkci sbernice nema valny vyznam, kreslil jsem to tam jen proto, abych zduraznil to, ze ovladaci signal tohoto WD muze byt sprazen s ovladanim MKO-1.
 
15.9.2005 - 08:19 - 
[quoteMá externí watchdog nějaký zásadní význam? .

Urcite ma. Mam taky zkusenosti z praxe a ty rikaji ze interni WD se celkem bez problemu kousne u jakehokoliv procesoru. Externi WD resim zpravidla vlastnim zapojenim na bazi hradel. Prumyslove obvody WD me zrovna nenadchly cenou a parametry. Posledni kde sem pouzil svuj WD byl spinany zdroj pro zabezpecovacku kde spinani tranzistoru ridi primo procesor. V pripade kousnuti je WD schopen resetovat driv nez by hrozilo zniceni zdroje. Pri internim WD by to zhorelo vse vcetne pripojenych zarizeni. Pouzivam jednoduche zapojeni, ktere ma ale vysokou spolelivost - da se vyradit snad jen kladivem... Ale to jen jako zajimavost.
Martalien
 
15.9.2005 - 08:42 - 
Tak jo. Přesvědčili jste mě. Dal jsem na PHP návrh hradla. Je to pro ilustaci podepřeno diskrétními MKO. je to soubor hradlo.jpg. Jde v podstatě jen o jeden tranzistor dva odpory a diodu. MKO jsou připojeny přes diody, aby se navzájem neovlivňovali. Dioda D1 do pinu procesoru slouží k přizvednutí napětí Ube pro tranzistor. Ve stabilním stavu MKO vnucují bázi tranzistoru T1 nulu. Procesor tak stažením pinu (emitoru) do nuly tranzistor neotevře. Log 1 nemá vliv. Pokud procesor našlápne některý z MKO stažením do nuly, jsou MKO odpojeny přes D2 a D3. Na bázi T1 vnutí R1 napětí a procesor je připojen. Pro připojení dvou MKO to tedy dělá tři diody, tranzistor a dva odpory. Pokud procesor resetuje, jsou nastaveny piny procesoru jako vstupní, maj vysokou impedanci popř. log 1 a proto nedojde při resetu k připojení procesoru na sběrnici. Pokud procesor přijde o napájení, je tranzistor opět uzavřen. Myslím, že v diskrétní podobě to snad nějaká ta částice hned tak neodstřelí. Ještě to musím prakticky vyzkoušet. Michal Pokorný navrhuje postavit sběrnici z několika procesorů, třeba 2051, a odzkoušet protokol, i hardware. Ale stejně z takto navržené sběrnice neni nadšenej.  
15.9.2005 - 09:04 - 
Ona ta sbernice neni zadny vykonnostni ideal :-)

Ale je to jednoduche na implementaci a data to prenese, pri 10 adresach a zadnych datovych prenosech by to melo udelat cca nekolik desitek cyklu za sekundu. Sem tam (par za sekundu) nejaka kratka datova zprava (napr. 30B) nema prakticky vliv.

Intenzivni datovy prenos mezi dvema adresami (vlastne jen prenos fotky z experimentu FOTAK do modulu VYSILAC-A, ostatni data jsou drobky) se zpravami rekneme 200B prenese tak 10-15 zprav/s takze 2-3KB/s efektivni rychlost. Do presnych vypoctu se poustet nebudu, stejne to bude potom ovlivneno i tim, jak rychle dokaze hlavni task prislusneho modulu zpravu pripravit k odeslani ... uvidime v praxi.

Postavit demonstrator z 2051 je dobry napad, ale poznamka:
- implementace do x51 bez xdata pameti (2051 ma jen 128B interni RAM) bude omezena, kratke zpravy, jen jedna zprava, zadna fronta zprav => nizsi celkovy vykon prenosu
 
15.9.2005 - 09:40 - 
Nic tam nevidim ... ze by zase GROUP ?

Halo, pane spravce ... nedalo by se to v tom PHP skriptu prosim default vypnout ? Uz si na to nabehlo dost lidi :-)
 
15.9.2005 - 09:48 - 
Co teď? Snad to už to tam je. Je to moje chyba. Obrázek jsem měl pracovně pojmenovaný fff.bmp a vrazil jsem ho tam. Teď se už jmenuje hradlo a mohl by být vidět.  
15.9.2005 - 09:53 - 
2051 jsem placnul jen tak od boku. Velikost RAM jsem vubec neuvazoval.  
15.9.2005 - 10:15 - 
quote:
2051 jsem placnul jen tak od boku. Velikost RAM jsem vubec neuvazoval.


Stejne asi zjednodusena implementace na jednu zpravu bude potreba, je asi zbytecne cpat do vsech modulu externi pameti. Aspon myslim.
 
15.9.2005 - 10:19 - 
Budto mam vlci mhu, nebo to tam stale neni ...
Prestava me to s tim PHP projektem bavit ... :-(
 
15.9.2005 - 10:59 - 
Poslal jsem ti to emajlem.  
15.9.2005 - 11:46 - 
quote:
Poslal jsem ti to emajlem.


Dik. Konstrukter tvrdi, ze to fungovat bude :-)
Tak, ted to zbastlit v nekolika exeplarich a postavit demonstrator.
 
15.9.2005 - 14:52 - 
Tak se nám (Petr Desort a já) konečně podařilo domluvit setkání členů Kosmo Klubu v klubovně Pražského Planetária na čtvrtek 22. září, začátek v 17:50. Mohl by přijít někdo, kdo by nám řekl jak je na tom teď CubeSat, co se chystá a v čem bychom mohli pomoct ? 
20.10.2005 - 12:26 - 
quote:
Ona ta sbernice neni zadny vykonnostni ideal :-)

Dival sem se jeste jednou na specifikaci a navrh zberice a myslim si ze pokud budou MKO rizeny procesorem muze dojid pri poruse krystalu procesoru k nekontrolovatelnemu trvalemu zaruseni zbernice a kompletni ztrate druzice. Poskodit krystal se da treba jen otresy pri startu. Dal bych prednost externimu rizeni MKO pomoci multiplexeru rizeneho signalem generovanym RC clankem.
 
21.10.2005 - 08:46 - 
Mate pravdu. Slabe misto neni ani snad to, ze procesor "zabloudi", s tim by se mohl vyporadat externi WD, ale v tom, ze krystal zmeni frekvenci, tim pujde do haje casovani.

Ovsem chyba krystalu znamena chybu delice UART, tim prestane SW prijimac prijimat "zdrave" bajty, budou v nem nastavat chyby a casovac bude stale nahazovan na dobu celeho cyklu. Tento typ poruchy by se mel efektivne jevit jako "zmrtveni" jedne ze stanic, z jejiho pohledu se to bude jevit jako porucha prijimace.

Samozrejme si dovedu predstavit i poruchu, ktera bude mit komplikovanejsi chovani, napr. zmena frekvence bude nepravidelna a nestala, bude treba preskakovat mezi nejakymi podobnymi hodnotami. Riziko to samozrejme je.
 
21.10.2005 - 11:57 - 
quote:
Ovsem chyba krystalu znamena chybu delice UART, tim prestane SW prijimac prijimat "zdrave" bajty,

Ja si myslim ze problem by mohl byt v tom, ze se procesor splasi a bude neustale nahazovat MKO a vysilat nesmysli na sbernici a tim ji totalne vyrusi. A taky si myslim ze je to nejpravdepodobnejsi zavada pri startu rakety.
 
21.10.2005 - 12:07 - 
quote:
Ovsem chyba krystalu znamena chybu delice UART, tim prestane SW prijimac prijimat "zdrave" bajty,

Ja si myslim ze problem by mohl byt v tom, ze se procesor splasi a bude neustale nahazovat MKO a vysilat nesmysli na sbernici a tim ji totalne vyrusi. A taky si myslim ze je to nejpravdepodobnejsi zavada pri startu rakety.
 
21.10.2005 - 12:55 - 
Na to, aby sbernici totalne vyrusil, by muset neustale nahazovat oba dva MKO.

Kdyz se procesor "splasi" a zacne vykonavat nedefinovany kod, muze se samozrejme stat, ze se v nedefinovanem kodu vyskytne instrukce, ktera nahodi MKO-1, nebo MKO-2. Instrukce, ktere nahodi oba dva (a jeste navic neco provedou s UARTEM nebo TX pinem, aby bylo vysilani), uz jsou podstatne mene pravdepodobne. Z tohoto duvodu je zadouci, aby rizeni MKO-1 a MKO-2 (a idealne i WD) bylo na jinych portech, aby se nedaly spolecne aktivovat jednou instrukci.

I kdyby toto nastalo (nedefinovanym kodem), pak je zde jeste externi WD, ktery by mel do relativne kratke doby zasahnout a prislusny procesor zresetovat.

Definovanym kodem toto nastane velmi obtizne, MKO-1 se nahazuje v jednom miste v celem programu, ve hlavni smycce, MKO-2 v jednom miste, v rutine odesilajici bajt v preruseni.

Nejvetsi problem je asi bud zminovana porucha krystalu (ale IMHO je pravdepodobnejsi, ze vibrace pretrhnou nejaky spoj) anebo to, ze odejde prijimac (kompletne). Pak bude procesor prijimat ticho a jednou za nejakou relativne dlouhou dobu odesle jeden ramec.

Tento stav, ze velmi dlouho nebylo prijato VUBEC NIC, by mel byt osetren nezavisle a pripadne vyvolat auto-reset.
 
21.10.2005 - 15:17 - 
quote:
Na to, aby sbernici totalne vyrusil, by muset neustale nahazovat oba dva MKO. Kdyz se procesor "splasi" a zacne vykonavat nedefinovany kod

Ja mluvim ze skusenosti. Kdyz se pocesor splasi diky krystalu, tak v praxi jsem zaznamenal dva tri stavy. Nejcasteji klekne krystal uplne - tj procesor vubec nejede. Druhy nejcastejsi je zmena frekvence krystalu - nejcasteji zvyseni ale i snizeni. Tady se bud zacne vykonavat program rychleji ci pomaleji ale vetsinou sem se setkal a to je treti pripad, ze oscilator kmita tak rychle ze procesor cte nesmysli a porty nesmyslne spinaji - zadny vykonavani instrukci. Proste nejradeji bych vydel externi HW spinani tech MKO bez krystalu. Delam servis zabezpecovacky a pri tisicich kusech vidim co vsechno se muze stat. Taky sem modelaril a vim jak krystaly zrovna nemilujou otresy. No a raketa se pri startu trese hodne. Leda ze by ty sbernice byly alespon dve a kdyz se pripoji zarizeni na jednu zbernici na dobu urcenou MKO tak tu druhou necha volnou ostatnim. Tim by se eliminoval splasenej procesor. Sice by padla rychlost ale alespon castecne by to zilo.
 
21.10.2005 - 15:35 - 
Kdyz se tu resi sbernice, pripomnelo mi to par otazek, ktere me napadly pri cteni toho shrnujiciho dokumentu. (nejsem elektrotechnik, tak jsou asi nektere otazky nesmyslne
- Co se stane pri fyzickem preruseni sbernice v jednom nebo dvou mistech? Pokud chapu dobre, jedno preruseni nevadi, dve a vice ano?
- Ta "bezpecnostni oddelovaci logika" - bude to jen logicke oddeleni nebo i galvanicke (optoclen)?
- Co se stane, pokud se procesor zblazni a po restartu od watchdogu se bude vzdy znovu a znovu dostavat do tohoto stavu? Nezarusi to sbernici tak jako tak, krome pauz, nez procesor po restartu nabehne?
- Jak se o poruse jednoho modulu dozvi jine zarizeni? Z tabule?
- Jak velke je riziko, ze selze MKO1 nebo MKO2 a tim zabrani v praci jinak funkcnimu modulu? (podobne watchdog)
- Je bezpecne propojit RX vstup galvanicky primo na "drat" sbernice?
- Ocekava se ze "vyskyt chyb prenosu bude minimalni". Pipadne obcasne chyby detekuje tedy kazdy modul sam?
 
<<  1    2    3    4    5    6  >>  


Stránka byla vygenerována za 0.190593 vteřiny.