|
citace:
Takže je potřebné mít na družici radiačně odolné součástky nebo není?
No kedze sa chcem pustit do postavenia riadiaceho pocitaca z beznych suciastok, tak si myslim, ze nemusia byt radiacne odolne. Ale na druhej strane si myslim, ze budeme mat vatsiu poruchovost najma pamati, ale to je riesitelny problem a pomerne lacno oproti RH/RT.
Na druhej strane nikto necaka od amaterskej druzice spolahlivost navigacneho systemu nuklearnych zbrani, vsak ze  .
Podla obrazku v http://www.atmel.com/dyn/resources/prod_documents/doc4172.pdf by konvencne CMOS mali zvladnut az takmer 40krad co sa mi zda nejak vela .
Pokial 1mm vrstva hliniku spravi z konvencnej suciastky odolnejsiu suciastku ako RH, tak potom nechapem ten extremny cenovy rozdiel medzi konvencnymi a RT/RH suciastkami a vobec zmysel ich vyroby. Preco potom konvencny procesor vyde $5 a prestne ten isty procesor v prevedeni RT $5000  a to sa bavime o najlacnejsom 8bit. procesore. Taky 32bit RAD750 je cenovo uplne niekde inde.
Osobne si myslim, ze ani cisto RT/RH bez odtienenia by nebolo pouzitelne. Pokial som mal moznost vydiet RT pocitac s RT procesorom na baze PPC, tak bol v dost masivnom kovovom obale (urcite hrubsom ako 1mm) aj napriek tomu, ze bol z RT suciastok a v oblasti pamati mal este zvlast dalsie kovove krytie.
V konecnom dosledku je to vec rozhodnutia a financii. Ako som uz povedal, pokial ma ist len o technologicke testy pohonov, tak naco riskovat? Postavme to z RT/RH suciastok, sponzori sa urcite najdu a v pripade uspechu to bude mat pre sponzorov aj zaujimavu medialnu pozornost.
Ale pokial (a to by som bol radsej) by malo ist o vyvinutie "stavebnice" amaterskej druzice a polozenie zakladov nejakych "standardov" pre zbernicu, komunikacny a riadiaci system, ktory by ostani amateri mohli rozsirovat, tak na RT/RH suciastky zabudnime a najdime kompromis medzi cenou, hmotnostou, velkostou, vykonom, fukcionalitou a spolahlivostou beznych suciastok. A ci to bude fungovat nam otestuju v CERNe. Financne urcite znesiem znicenie 10ks prototypov z konvencnych procesorov a pamati pri testoch, narozdiel od nakupu jedneho RT procesoru bez pamate . |
|
To jcz: Hurá, konečně někdo, kdo má výraznější zkušenosti s radioam. provozem družicí i s kmitočtovými příděly Já jsem už byl na dně se svými znalostmi
To wintermute:
Pro paměť se dají ještě použít i jiné součástky a to FRAM (ferro RAM). Mají výhodu, že vydrží i bez napájení (takže není nutná záloha paměti) - garantují až dva roky zádrž bez napájení. A co jsem se bavil s dodavatelem, tak jsou právě pro tuto aplikaci vhodné. Nevýhodou je trochu větší spotřeba pro zápis. A druhou nevýhodou (ale diskutabilní, uvažujeme-li o vlastním vývoji ŘS) je jejich velikost. Nyní se dodávají max. 256Kbit jako seriovou paměť (snad 1Mbit se připravuje). a mají už 64KByte paměti. Ale ty jsou už z podstaty RT. Více na http://www.citworld.com/index.php?page=Y3ovd3d3L3Byb2R1Y3RzL21lbW9yaWVzL2ZyYW0uaHRtbA==&PHPSESSID=547d1b775fa2118c42a241985bd92b85 s těmi jsem o tom mluvil.
Resp. na http://www.ramtron.com/doc/AboutFRAM/technology.asp . [Upraveno 30.4.2004 poslal mikes] |
|
| Jen pro jistotu ještě jednou připomínám, že mě osobně jde především o vývoj "stavebnice" družice (to je pro mne hlavní cíl našeho prvního, technologického exempláře). Dá se to vyvíjet "od píky" (to nedokážu a spoléhám na Mariana, wintermuta a další), ale možná by se dalo experimentovat i s úpravami už hotových (koupitelných) celých dílů (o to se asi pokusím sám). Zajímá mě prostě cokoliv, co dokáže "pořízení" družice přiblížit amatérům a vůbec "obyčejným lidem" :-) |
|
citace:
[
Pokial 1mm vrstva hliniku spravi z konvencnej suciastky odolnejsiu suciastku ako RH, tak potom nechapem ten extremny cenovy rozdiel medzi konvencnymi a RT/RH suciastkami a vobec zmysel ich vyroby. Preco potom konvencny procesor vyde $5 a prestne ten isty procesor v prevedeni RT $5000 a to sa bavime o najlacnejsom 8bit. procesore. Taky 32bit RAD750 je cenovo uplne niekde inde. "
To je přesně to co mě vrtá hlavou. Limit LET je pro vrstvu hliníku 0,1 až 0,2 mm silnou takový jako pro Rad Hard součástku neodstíněnou.
Proč se vlastně vyrábějí Rad Hard součástky když je možné běžné součástky odstínit - v tom nemám zatím jasno ale vysvětluji si to tak že LET limit je jakási střední hodnota energie všech částic dopadlých na 1 centimetr čtverčný kterou by součástka měla vydržet funkční. Problém asi je když se ve spektru dopadlých částic vyskytne třeba jedna jediná s energií výrazně vyšší než je průměrná energie ostatních částic. Taková částice již projde kovovým krytem a může zničit určitou omezenou oblast na čipu. Zřejmě jsou Rad Hard součástky vyrobeny tak že již na čipu jsou mnohé obvody (registry, paměti,..) znásobeny takže při zničení určité části jsou k dispozici obvody náhradní (?). To by pak, s ohledem i na asi daleko nižší sériovost výroby, vysvětlovalo ten rozdíl cen. Takže při dostatečné redundanci obvodů na čipu Rad Hard součástka bez kovového krytu může mít výrazně nižší statistickou pravděpodobnost zničení než komerční součástka s krytem (?).
Zajímavé je že v kosmu, resp. v okolí Země až po geostacionární dráhu nemá příliš význam stínění polovodičů vrstvou hliníku silnější než 6 mm. To proto že radiační dávka při silnějším stínění klesá lineárně a dosti pozvolna, zato při slabším stínění vzrůstá radiační dávka velmi rychle. |
|
citace:
Je třeba se ale dohodnout, v jakém vztahu by byla zařízení, postavená EMP-Centauri a wintermutem. Možná by mohla dohromady tvořit "tvrdé jádro" (protože by byla redundantní), nebo by jeden z nich mohl být už považován za "experiment" (technologický).
Já myslím že když to (myslím řídící systém a komunikační část) pan Wintermute nebo někdo jiný postaví z RT součástek, bude logické použít na družici tuto konstrukci. Bude zajímavé porovnat na radiačních testech vliv stínění na běžné komerční součástky a na RT součástky.
Zkusím ověřit u výrobce jak jsou na tom s radiační odolností obvody nRF, jedná se o technologii CMOS 0.12um. |
|
citace:
Jen pro jistotu ještě jednou připomínám, že mě osobně jde především o vývoj "stavebnice" družice (to je pro mne hlavní cíl našeho prvního, technologického exempláře). Dá se to vyvíjet "od píky" (to nedokážu a spoléhám na Mariana, wintermuta a další), ale možná by se dalo experimentovat i s úpravami už hotových (koupitelných) celých dílů (o to se asi pokusím sám). Zajímá mě prostě cokoliv, co dokáže "pořízení" družice přiblížit amatérům a vůbec "obyčejným lidem" :-)
Podotýkam, že jsem z nezávislého zdroje slyšel, že na jednom z prvních českých Magionů (bylo jich nakonec víc, ne ?) byly použity normální baterie Varta koupené v obchodě - a prý fungovaly bezchybně.
Takže stavebnicové řešení je běžné i u "seriózního" kosmického výzkumu.
|
|
citace:
Já myslím že když to (myslím řídící systém a komunikační část) pan Wintermute nebo někdo jiný postaví z RT součástek, bude logické použít na družici tuto konstrukci.
No komunikacnu cast nepostavim , lebo to neviem . Ja a analogova technika (zosilovace, modulatori, anteny ... ) niesme moc kompatibilny. A keby sa mi to nahodou aj podarilo, tak by som to v ziadnom pripade neodporucal dat na druzicu)).
Co sa tyka riadiacej casti, po zisteni ceny RT suciastok nevidim realne, aby druzicu z takymto systemom postavil amater. Pokusim sa ale zohnat sponzora, ktory by zaplatil RT suciastky v pripade, ze by sa takyto system pouzil ako zalozny a kontrolny pre ten amatersky.
Co sa tyka vztahu k EMP-Centauri, mal som dojem, ze oni chcu postavit komunikacny system. V takom pripade by tie systemi spolupracovali spolu a neboli by konkurencne. Ak teda budu stavat aj komunikacny aj riadiaci system, tak by vznikli dva navrhy riadiaceho systemu. A asi najlepsim riesenim by potom bolo zhodnotit vlastnosti jedneho aj druheho a v konecnom rieseni urobit system, ktory z tychto navrhov zoberie to najlepsie (koncepcne). |
|
Souhlasím s wintermutem v tom, že by bylo velmi vhodné navrhnout více možných řešení jednotlivých dílů (např. řídicího systému) a pak společně vybrat to nejlepší (nejperspektivnější).
Nechcete něco takového připravit už před KNP 2004 a diskutovat to tam? |
|
[quote)
Co sa tyka vztahu k EMP-Centauri, mal som dojem, ze oni chcu postavit komunikacny system. V takom pripade by tie systemi spolupracovali spolu a neboli by konkurencne. Ak teda budu stavat aj komunikacny aj riadiaci system, tak by vznikli dva navrhy riadiaceho systemu. A asi najlepsim riesenim by potom bolo zhodnotit vlastnosti jedneho aj druheho a v konecnom rieseni urobit system, ktory z tychto navrhov zoberie to najlepsie (koncepcne).
My budeme stavět komunikační systém. Ovšem komunikační systém na bázi obvodů nRF znamená že je již k dispozici i část řídícího systému (zdokonalené jádro 8051, A/D převodníky, UART, ...) - tyto části obvodů by bylo škoda nevyužít. Proto by byla vhodná velmi těsná spolupráce mezi tvůrci komunikačního a řídícího systému. Ta bude ostatně nutná i s ostatními členy týmu. U takhle malé družice si nedokážu představit komunikační a řídící a datovou část jinak než na jedné desce s plošnými spoji.
Také je možné, že se ještě poohlédneme po jiných obvodech než nRF. U obvodů nRF nemá výrobce k dispozici žádné údaje ohledně jejich odolnosti vůči radiaci. |
|
citace:
Ovšem komunikační systém na bázi obvodů nRF znamená že je již k dispozici i část řídícího systému (zdokonalené jádro 8051, A/D převodníky, UART, ...
Po 1.6 poslem presnejsiu predstavu (blokovu schemu) ako by mohol riadiaci a komunikacny system spolu fungovat.
Komunikacna cast by modla mojej predstavy mala pozostavat z dvoch casti.
1, Pomalej (ale realativne velmi spolahlivej) casti, pracovne by som to nazval servisny kanal. Podla mna by nemala obsahovat procesor. Nanajvys automat zalozeny na PROM. Mala by byt schopna na zaklade prikazu zo zeme resetovat riadiaci pocitac a umoznit s nim pred "nabootovanim" z eeprom komunikovat pomocou servisneho kanalu (napr. nahrat novy firmware do eeprom).Vyrazom "pred nabootovanim" som myslel start z PROM pamate, v ktorej by bol nejaky "loader", ktory by vedel spustit SW z EEPROM alebo vyhodnocovat urcitu sadu servisnych prikazov zo servisneho kanalu. Rychlost by nebola kriticka a drzal by som ju radsej nizsie (100 - 500 bps)
2, Rychlej (moze byt ich aj viac, nielen jedna), ktora by mohla komunikovat priamo aj s inymi castami systemu nezavysle na riadiacom pocitaci (napr. s fotografickou castou, pripadne komunikacia priamo s pamatou riadiaceho pocitaca). Komunikacia z rychlej komunikacnej jednotky by mala prebiehat pomocou nejakej inteligentnejsej seriovej zbernice (pripadne aj zalohovanej). Takato jednotka by mala obsahovat procesor. Rychlost sa moze pohybovat v radovo v desiatkach az stovkach kbps.
Zatial tolko moj nazor.
|
|
citace:
Pomalej (ale realativne velmi spolahlivej) casti, pracovne by som to nazval servisny kanal. Podla mna by nemala obsahovat procesor. Nanajvys automat zalozeny na PROM. Mala by byt schopna na zaklade prikazu zo zeme resetovat riadiaci pocitac a umoznit s nim pred "nabootovanim" z eeprom komunikovat pomocou servisneho kanalu (napr. nahrat novy firmware do eeprom).Vyrazom "pred nabootovanim" som myslel start z PROM pamate, v ktorej by bol nejaky "loader", ktory by vedel spustit SW z EEPROM alebo vyhodnocovat urcitu sadu servisnych prikazov zo servisneho kanalu. Rychlost by nebola kriticka a drzal by som ju radsej nizsie (100 - 500 bps)
Pri obehu ve vysce 600-800 km je doba obehu zhruba 5800 sekund, takze
v dosahu nejakych 1000 km pro rozumny radiovy kontakt bude nejvyse par minut, pritom se jeste zemni antena bude muset celkem svizne otacet. Pri 500 b/s pri to je syrovych 30000 bit/min tedy cca 4kB/min.
Samozrejme zpetna potvrzeni, zdrzeni a podobne, ja (na zaklade zkusenosti) odhaduji max. 2kB/min, to jest za casove okno budeme schopni downloadovat neco kolem 10 kB, to neni mnoho (ale muze stacit ;-). Dale, souvislost rotace Zeme a obehu (porad redpokladam prakticky kruhovou polarni drahu) nam da (z jednoho mista) sanci komunikovat zhruba dvakrat denne, a to v postupne ruzne denni casy, takze predem rozvrzeny kalendar sluzeb u pozemni stanice ;-)
Jinak se chci omluvit, ze moc neprispivam do diskuse ani nepracuji na simulatoru, dvojcata mi skutecne nedavaji moc prostoru |
|
Dal jsem nějaké výpočty ohledně zdrojové části a komunikační části družice na PHP projekt. V nejbližší době se chci ještě pustit do termoregulace a pohonu.
K výpočtům pana Filipa Zalio na PHP projektu - vida, skutečný to profesionál mezi námi.
Pro Wartex: blahopřeji k dvojčatům. Mě čeká další potomek až v červenci. |
|
citace:
Samozrejme zpetna potvrzeni, zdrzeni a podobne, ja (na zaklade zkusenosti) odhaduji max. 2kB/min, to jest za casove okno budeme schopni downloadovat neco kolem 10 kB, to neni mnoho (ale muze stacit ;-).
Mne islo o to aby existoval kanal (relativne spolahlivy), ktory umozni komunikaciu s druzicou v pripade nejakych technickych problemov. Servisny kanal by nemal sluzit na nejake caste a velke nahravanie dat. Hlavne by mal (relativne) velmi spolahlivo prijimat nejaku sadu servisnych prikazov. Jednym z najhlavnejsich by mal byt prikaz na reset, ten by mala vyhodnotit este kokmunikacna jednotka a vykonat pomocou nejakeho automatu zalozeneho na PROM. (Pravdaze toto by nemalo nahradzat watchdog)
Dakujem za vypocet. Mylim, ze tie hodnoty su vzhladom na funkciu v prijatelnom rozsahu. |
|
Mít jeden pomalejší a jeden rychlejší kanál vypadá rozumně.
V podstatě při přenosu dat z družice na Zemi (downlink), pokud se při přenosu ztratí občas jeden bit není to taková tragédie. Horší je když pošleme uplinkem příkaz ze Země na družici, pak může ztráta jediného bitu v příkazu vážně ohrozit celou družici.
V návrhu komunikační části na PHP projektu bylo v podstatě myšleno použít kanál v pásmu 2.4-2.45 GHz pro rychlé downlink přenosy např. snímků z kamery nebo dat z vědeckého experimentu, případně toto pásmo použít pro radioamatéry.
Kanál v pásmu 430 až 440 MHz pak využít spíše jako rezervu a pro downlink přenos informací o technickém stavu družice a pohonné jednotky, zde již není tak vysoká rychlost přenosu dat potřebná.
Třetí kanál by byl uplink kanál v pásmu 430-440MHz na stejném kmitočtu jako downlink, ale s výrazně nižší rychlostí přenosu dat, např. 100-500bps jak navrhuje Wintermute. Byl by určen pro posílání příkazů na družici.
|
|
Přesto si myslím že by stálo za uvážení mít možnost rychlost pro příkazový uplink kanál zvýšit v kritických situacích až několikanásobně. Například zrovna v případě nějaké poruchy kdy je zapotřebí třeba ze Země přeprogramovat paměti řídící jednotky, což zabere jistý čas.
|
|
Keby bol pomaly kanal len na prikazy a pre download dat by sa vyuzil rychly kanal? Pravdaze v najhorsom by sa cez neho dali poslat aj nejake tie data.
V modulaciach sa moc nevyznam, ale neslo by pouzit nejaku redundantnu, alebo co najviac odolnu voci ruseniu? Kedze by neslo velmi o rychlost tak dokonca nejaku kde by sa baudova rychlost rovnala bitovej, pripadne bitova by bola nizsia? (stale mam na mysli sevisny kanal).
Pokial ide o preprogramovanie riadiacej jednotky, tak som uvazoval o tom, ze riadiaca jednotka by "bootovala" z PROM a obsahovala nejaky zakladny SW (vratane komunikacneho). Ak by prisiel zo servisneho kanala prikaz RESET tak by, doslo k resetu riadiacej jednoty, nabootovaniu z PROM, skontrolovaniu obsahu EEPROM a k vykonaniu kodu v EEPROM. Ale mohol by prist aj specialny RESET, ktory by znamenal nabootovat z PROM a cakat na dalsie prikazy. Dalsie prikazy by mohli znamenat napr. pokyn na download bloku dat cez rychly kanal a ulozenie tychto dat do EEPROM? Pravdaze oznamenie o uspesnosti downloadu by prisielo cez servisny kanal, vratane testu na kontrolny sucet. Ak by to prebehlo v poriadku tak by sa vyslal "obycajny" RESET a vykonal by sa downloadnuty kod.
|
|
Dobrý den,
pro komunikační část uvažujeme, jak již bylo dříve zmíněno panem Váňou, použít obvod nRF9E5, případně nRF24E1, které kromě transceiveru obsahují též vylepšený microcontroller 8051. Tento by nakonec mohl zastat i funkce řídící jednotky družice. Tyto obvody pracují tak, že po resetu (uživatelem, watchdogem), spustí bootovací sekvenci, která připojí externí paměť SPI, z ní nahrají program do paměti procesoru a tento spustí. Zatím uvažujeme namapovat tyto paměti 2 přes sebe s tím, že jedna by byla např. PROM, s ověřeným programem především pro zajištění komunikace, a z níž by se bootovalo například při jakékoli kolizi systému. Druhá EEPROM, programovatelná ze země upload linkou, by byla použita pro změny programu. Mapování EEPROM, by bylo též řízeno příkazem ze země, ale časově omezené,(monostabilním obvodem na dobu nezbytně nutnou pro bootování), mapování PROM, by bylo imlicitní. Pokud by byl požadavek oddělit transceiver od řídící části, nabízí se varianta obvodů nRF: nRF905, nRF2405, které procesor neobsahují. Kladou ovšem trochu větší nároky na řízení. |
|
citace:
V modulaciach sa moc nevyznam, ale neslo by pouzit nejaku redundantnu, alebo co najviac odolnu voci ruseniu? Kedze by neslo velmi o rychlost tak dokonca nejaku kde by sa baudova rychlost rovnala bitovej, pripadne bitova by bola nizsia? (stale mam na mysli sevisny kanal).
Při použití dvouúrovňové modulace Manchester II, kterou používají obvody nRF, je modulační rychlost dvojnásobná obroti bitové. Tato modulace by měla být sama o sobě dostatečně odolná proti rušení. Dal jsem k tomu nějaké grafy na PHP projekt.
Dále jsem tam dal přehled funkčních požadavků jaké by měla obecně splňovat řídící jednotka družice.
Také jsem tam dal soubor druzice-rozprac.txt, kde je uveden seznam započatých prací na družici o kterých vím a objednaného materiálu. Prosím o doplnění tohoto souboru pokusd někdo má něco rozpracováno. Je to hlavně z důvodu aby se zbytečně některé práce a materiál nedublovali. Je ale samozřejmě možné (a vhodné) aby na některých částech družice pracovalo více jednotlivců nebo týmů.
|
|
Ospravedlnujem sa za odmlku (ako som si vsimol mali ste tu veselo anonymove gule ). V praci som vytazeny viac ako som predpokladal, takze to z mojej strany pojde trosku pomalsie. Na PHP projekt som dal blokovu schemu mojej predstavy ako by mal vyzerat riadiaci system. Na scheme nieje zakreslena napajacia cast. PHP projekt znacne orezal moj komentar, takze skusim ten navrh vysvetlit tu.
Jednou z klucovych casti je radic zbernice. Mal by umoznovat redundantnu "autonomnu" komunikaciu jednotlivych casti. "Autonomnou" myslim to, ze ktore kolvek zariadenie na zbernici moze iniciovat komunikaciu s ktorym kolvek, bez toho aby rusili ostatne.
Napr. obrazova jednotka by mohla zapisovat data priamo do FRAM Disku. Komunikacna jednotka moze priamo prenasat data z alebo do FRAM Disku bez ucasti riadiacej jednotky.
Takato distribuovana koncepcia by mala vyhodu redundancie. V pripade zlyhania napr. riadiacej jednotky moze jej funkciu prebrat napr. komunikacna alebo obrazova jednotka. V pripade znicenia casti elektorniky by sme mohli mat k dispozcii stale nejaky ten "riadiaci" system.
|
|
citace:
Na PHP projekt som dal blokovu schemu mojej predstavy ako by mal vyzerat riadiaci system.
Nějak to nemůžu na Projektu najít. Kde to tam je? |
|
Blokova schema2.png
Som si nevsimol, ze to neoznacuje kto to tam dal, aj komentar mi to orezalo, nabuduce to dam do jedneho dokumentu. |
|
| Stejně to tam nemám, nebo jsem slepý. Nezadal jste při uploadu souboru Přístup jen pro sebe ("já") místo "group"? |
|
| No ja som dal "stejně jako adresář" teraz som to zmenil na group, tak skuste. |
|
Teď už je to v pořádku. Chtěl bych se ohledně toho schématu zeptat možná trochu hloupě na pár věcí, resp. není nám úplně jasné co znamenají ty vstupní/výstupní porty. Na ně jsou napojena čidla (např. napětí, teploty,...)? Jsou to nějaké převodníky (A/D, D/D)?
FRAM - jedná se o feroelektrickou paměť? Jaké to potřebuje napájecí napětí a jaký to má zhruba odběr (příkon)?
Řídící jednotka ... její jádro tvoří zřejmě nějaký procesor, jaký předpokládáte? (80C32?). Jaké řadiče sběrnice myslíte použít?
Jaké sběrnice zamýšlíte použít, něco jako 1553? Může to fungovat při napětí maximálně 3 až 4 Volt?
Do jakých částí z toho schématu se hodláte pustit, tedy je postavit.
Kolegové v práci teď zkoušejí nějaké bezdrátové přenosy pomocí obvodů nRF, zatím z PC do PC. Vypadá to že při použití těchto obvodů a při použití ochranného kódu CRC je už zbytečné (nadbytečné) používat ještě protokol AX.25. Chybovost přenosu (BER) to prakticky neovlivní.
Jinak , po nedávných konzultacích a doporučení ČTÚ, předpokládám použití následujících kmitočtů na družici:
-Radiomaják (downlink): 137-138MHz, nebo 143.6-143.65 MHz, šířka pásma do několika kHz
-Povelová komunikační jednotka (uplink): 449.75-450.25MHz, šířka pásma do několika kHz
- Datová komunikační jednotka (downlink): 2170-2300MHz, šířka pásma do asi 1MHz
Chtěl bych žádost o kmitočty poslat na ČTÚ už teď, tedy v nejbližších dnech, maximálně týdnech. Jinak se totiž , bez znalosti přidělených kmitočtů, s rádiem dále nehnem. Nebo je to špatně? |
|
citace:
Teď už je to v pořádku. Chtěl bych se ohledně toho schématu zeptat možná trochu hloupě na pár věcí, resp. není nám úplně jasné co znamenají ty vstupní/výstupní porty. Na ně jsou napojena čidla (např. napětí, teploty,...)? Jsou to nějaké převodníky (A/D, D/D)?
Preco hlupo? No je to hruba blokova schema takze k tym otazkam tak trochu evokuje.
Pod riadiacou jednotkou som mal na mysli cast, ktora bude riadit samotnu sondu (navigacia, riadenia plachty, alebo co to tam bude , prepocty drahy alebo co vsetko bude treba na to aby to letelo tam kam budeme chciet ... ) z "matematickej casti" a samotne ovladanie by riadiaca jednotka vykonavala cez V/V cast. Meranie napati a teploty by skor mala mat na starosti telemetria. Pravdaze cez zbernicu si tieto udaje moze od telemetrie zistit aj riadiaca jednotka. Otazne je ci aj na V/V nepristupovat cez zalohovanu zbernicu. Malo by to tu vyhodu, ze v pripade zlyhania (znicenia) riadiacej jednotky, mozeme ako nahradnu "riadiacu jednotku" pouzit komunikacnu alebo obrazovu jednotku.
citace:
FRAM - jedná se o feroelektrickou paměť? Jaké to potřebuje napájecí napětí a jaký to má zhruba odběr (příkon)?
Ano FRAM je feroelektricka pamat (parametre http://www.ramtron.com/doc/Products/Products_detail.asp?ID=31&FamID=1), myslim by by nam mohla stacit seriova (SPI) pre FRAM disk. Z 32ks by sa dal vyskladat 1MB (ale predpokladam, ze sa sa objavia aj vatsie kapacity). Navyse jednotlive pamate by stacilo zapinat pri zapise a citani, v dobe keby nemala ziadna cast systemu poziadavku na FRAM disk, tak by mohli byt vypnute.
Pre riadiacu a obrazovu jednotku by sa mohla pouzit paralelna (http://www.ramtron.com/doc/Products/Products_detail.asp?ID=13&FamID=3) FRAM.
citace:
Řídící jednotka ... její jádro tvoří zřejmě nějaký procesor, jaký předpokládáte? (80C32?)
V principe nim moze byt lubovolny jednocip. Podla mna by bolo ale mozno rozumne pouzit 80C32 a to z toho dovodu, ze ked sa najde sponzor, tak ju mozeme vymenit za 80C32E.
citace:
Jaké sběrnice zamýšlíte použít, něco jako 1553? Může to fungovat při napětí maximálně 3 až 4 Volt?
Nic vhodne som spravene nenasiel. Radice pre 1553 som ine ako RAD HARD/TOLERANT tiez nenasiel. Myslim ze pre amatersku druzicu by 1553 bola ako raketomet na bazanty. Myslel som, ze by sme si navrhli svoju. Bud by sme na to pouzili ASIC, alebo nejaky jednoduchy jendocip s PROM. S cim by som pri nej ale potreboval pomoct je fyzicka vrstva. Analogova tachnika a vedenia nieje prave to v com by som bol doma. Zbernica by podla mna mala byt odolna voci porucham jednotlivych jej casti. Napr ked dojde k zniceniu niektoreho radica, tak by to nemalo mat vliv na zvysne radice na tej istej zbernici. Takze fyzicka vrstva nemoze byt len obycajny digitalny dvojurovnovy signal. Skor by mohlo ist o nieco co by bolo oddelene od radica nejakym filtrom, a v tomto momente sa to pre mna stava spanielskou dedinou. Ale dufam, ze nejaky odbornik sa najde a pomoze. Zvysnu cast radica by som mohol navrhnut.
Co sa tyka napatia 3 až 4 Volt by to nemal byt problem, vzhladom na to ze predpokladam vlemi kratke vzdialenosti (zas do kocky 10x10x10cm moc dlhy kabel nenapchame ).
citace:
Do jakých částí z toho schématu se hodláte pustit, tedy je postavit.
No zavisi od toho ci sa zhodneme na takejto koncepcii elektronickej casti (modulova so zalohovanou zbernicou), alebo nie. Ak ano, tak najskor by som zacal s tym radicom. Lebo, ked bude ten dobre navrhnuty a vyspecifikovany protokol, tak sa daju zacat zvysne casti robit samostatne a nezavysle. Po radici by som sa mohol pustit do tych casti, na ktore by sa nenasiel niekto iny. Taky povelovy automat by ma mohol celkom bavit . Ale v principe do ktorej kolvek digitalnej casti (cim vylucujem komunikacne jednotky a ATV, na tie ale zaujemci su takze to by na mna chvalabohu ani nezostalo ).
citace:
Chtěl bych žádost o kmitočty poslat na ČTÚ už teď, tedy v nejbližších dnech, maximálně týdnech. Jinak se totiž , bez znalosti přidělených kmitočtů, s rádiem dále nehnem. Nebo je to špatně?
No znie to rozumne, aj ked neviem nakolko by boli jednotlive casti preladitelne (napr. pokial by sa postavila dalsia druzica, na kolko by sa dal pouzit uz navrhnuty komunikacny modul a "preladit" ho na pridelenu frekvenciu?
|
|
| Systém dvou sběrnic považuji za dobrý nápad, jen je třeba rozhodnout, jaký protokol bude použit. Fram disk je možná trochu luxus, obzvláště pro ukládání obrazů, kde na nějaké chybě nezáleží. Dále mi není jasná funkce povelového automatu, předpokládám-li, že výstupem z komunikační jednotky je již logická úroveň, a řídící jednotkou je uPC |
|
citace:
Systém dvou sběrnic považuji za dobrý nápad, jen je třeba rozhodnout, jaký protokol bude použit. Fram disk je možná trochu luxus, obzvláště pro ukládání obrazů, kde na nějaké chybě nezáleží. Dále mi není jasná funkce povelového automatu, předpokládám-li, že výstupem z komunikační jednotky je již logická úroveň, a řídící jednotkou je uPC
No FRAM disk nemusi sluzit len na ukladanie obrazkov. Podla debaty, ktora tu bola pred casom, som usudzoval ze FRAM by bola odolnejsia ako EEPROM.
Co sa tyka poveloveho automatu, tak:
Povelova komunikacna jednotka by podla mna nemala obsahovat procesor. Mala by byt co najjednoduchsia podla moznosti s co najnizsim stupnom integracie (ziadne IO s vysokou integraciou), ide o to aby bola co najodolnejsia voci prostrediu tam hore.
Povelovy automat by mal dekodovat prikazy, ktore komunikacna jednotka prijala (malo by ist o velmi jednoduchy datovy ramec). Na zaklade tohoto prikazu by povelovy automat vykonal prislusnu akciu, napr. resetol riadiaciu jednotku, alebo by jej vypol napanie, pripadne vygeneroval prerusenie, zalezalo by od prijateho prikazu. Povelovy automat by mala byt v podstate pamat PROM + zopar registrov. Pracovna frekvencia par Hz, maximalne KHz. Takze by to mohlo vykazovat omnoho vatsiu odolnost ako uP.
Teoreticky by povelovy automat mohol dostat prikaz aj na prenos niekolkych desiatok bytes do riadiacej jednoky, pripadne z nej, a tak vyuzit povelovy kanal v pripade nudze ako velmi pomaly datovy kanal, v pripade zlyhania komunikacnych jednotiek. Zalezi od toho ake vsetky funkcie poveloheho automatu si vyspecifikujeme.
|
|
citace:
Zalezi od toho ake vsetky funkcie poveloheho automatu si vyspecifikujeme.
Tato diskuse by se mela presunout do threadu Tvrde jadro.
Povelovy automat se podoba myslence "startovaciho sekvenceru" v mem
prapuvodnim schematu se dvema CPU a nekolika pametmi.
Myslel jsem to tehdy tak, ze stavovy automat v PROM bude realizovat sekvenci zapinani procesoru a mapovani jednotlivych pameti ve spolupraci s obema WatchDogy tak, aby se maximalizovala sance, ze srdce satelitu obzivne.
Tedy: aktivovat prvni CPU a namapovat prvni RAM, pak druhou RAM, atd.,
pak druhy CPU, ruzne kombinace postupne PROM s firmware pro CPU, zalozni PROM s firmware ... atd. Kdyby vse selhalo, prejit do stavu "vysilam majakem SOS" a pokusy automaticky po nejakem case opakovat.
Myslim, ze napojeni tohoto "radice" na prijimaci UART by bylo pomerne
komplikovane (povely napr. jako bajty), umel bych si to predstavit jako kodovani pulsy ruznych delek (jednotka delky napr. 100-200ms) v presnem sledu, pokud bude z prijimace pristupny i fyzicky binarni signal priimaci linky. To by mohlo byt celkem spolehlive, v idealnim pripade pro toto dekodovani mit dalsi jednoucelovy dekoder (slo by to, Mariane?).
|
|
| Jaka rychlost na sbernici se predpoklada. Premyslim nad ni jak ji udelat aby byla "nezranitelna". Pro navrh potrebuji znat rychlost. Budou data seriova nebo paralelni?. Nebo jinak - kolik dratu a co po nich pude? Paxe da neco navrhnout. |
|
citace:
Jaka rychlost na sbernici se predpoklada. Premyslim nad ni jak ji udelat aby byla "nezranitelna". Pro navrh potrebuji znat rychlost. Budou data seriova nebo paralelni?. Nebo jinak - kolik dratu a co po nich pude? Paxe da neco navrhnout.
Na tej blokovej scheme je uvedene:
Hlavna seriova zbernica (1Mbps - 2Mbps)
Zalozna seriova zbernica (1Mbps - 2Mbps)
Alebo ste mali na mysli inu zbernicu? |
|
