Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in /var/www/html/dtusat1/includes/header.inc.php on line 28
DTUsat-1: Radio - Minutes
DTUsat logo
DTUsat sites
DTUsat Project
» DTUsat-1




Radio


Date: 5-9-2001 By: Niels Holmgård Andersen
Hej allesammen

Her er på stikordsform de opgaver og løsningsmuligheder vi diskuterede i
går.
Tag det her som et RFC-dokument - det er der først og fremmest for at
gøre det nemmere at diskutere.

Købe/bygge:
Vi var rørende enige om at det *&%& må kunne lade sig gøre at bygge en
radio fra bunden på et teknisk universitet. Vi vil i hvert fald have lov
til at brække halsen på det før vi køber en kommerciel radio.


Krav:
Radiosystemet skal gøre det muligt at kommunikere med satellitten.
Båndbredden skal være tilstrækkelig til at få de data ned som
satellitten genererer.
Båndbredden skal mindst være tilstrækkelig til telekommandoer - og det
vil være rart at have kapacitet til at uploade ny software, hvis
on-board computeren har mulighed for det.
Radioen skal autonomt udsende et beacon-signal, så vi kan høre at
satellitten er kommet op - selv om computeren ikke skulle være det.
Effekt- og pladsforbrug må ikke være ret stort - max 2-3W når der
sendes, langt mindre i standby. Max et 10x10 cm printkort.
Hele modulet skal være tilpas robust overfor temperatursving, fremmed
radiotrafik, stråling, latch-up etc.


Overslag over båndbreddekrav fra satellit - housekeeping og payload:
Afhænger naturligvis i høj grad af payloaden.
Housekeeping: ca. 100 bytes/minut i 100 minutter = 10k/omløb
Mulighed for at sende ca. 10 ? minutter hvert 5 ? omløb -> 83 bytes/s
Korrigerende koder, handshaking etc +150% -> 1,7 kbps
Evt. kamera: min. 10k/billede
Uplink: modul udskiftes på et pass: 32k + handshaking - ca. det samme

Alt det her skal drøftes igennem med system engineering for at få
antallet af ubekendte ned, men umiddelbart leder dette frem til at 2400
bps vil være nødvendigt medmindre datamængderne er væsentlig mindre
eller vi kan leve med at tabe gamle data - eller vi kan gøre det muligt
at bruge flere jordstationer, fx ved at bruge amatørradionettet.

En af de andre ting er hvorvidt vi skal lade et autonomt beacon have en
separat antenne, men der var enighed om at lade beaconsignalet overtage
hovedsenderen og antennen når denne ikke er i brug til kommunikation.
Det giver mindre redundans, men også meget mindre designarbejde og
mindre mekanik. Beaconen kunne fx være et PWM temperatursignal med
ekstremt lille dutycycle, fx 1 us/K med 1/60 Hz repetition. Dette kunne
samtidig være lyttetiderne for radioen, så en bærebølge fra jorden
bliver opfanget.


Frekvenser og sendetilladelser:
Det vil sandsynligvis være nemmest for os at få en tilladelse i
amatørbåndene - det vil i praksis sige 70 cm eller 2 m båndet. Ved
meget højere frekvenser bliver der for meget sort magi i hardwaren til
at vi kan regne med at få det til at lykkes uden erfaring, ved lavere
frekvenser bliver antennerne meget hurtigt store. Vi kan ikke regne med
at få tildelt en eksklusiv plads i spektret, så vi bliver nødt til at
sikre informationen op og ned på en eller anden måde. Muligvis er
fejlkorrigerende kodning i sig selv nok til at validere korrekt
afsender.

Spørgsmålet er også hvad vi kan modtage - hvad kan IKT? Hvad kan vi få
EMI's parabol til at kunne? Hvad har vi overhovedet råd til?

Dette vil kræve noget arbejde, men skal helst afklares hurtigt for at vi
kan gå i gang.


Jordstation:
Se ovenfor. EMI? IKT?


Interfaces:
OBC<->kommunikationssoftware er endnu uafklaret.
Softwaregruppen modtager data fra OBC på en eller anden måde, pakker
den ind i koder og sender og modtager en rå bitstrøm i CMOS-niveau uden
handshaking til/fra radiohardwaren
Radiohardwaren sender og modtager HF med 50 ohm impedans mod antennen
Antennen gør hvad antenner nu gør med HF med den rigtige frekvens

Et af de uafklarede punkter er hvorvidt radioen skal have sin egen
processor og kommunikere over en bus eller om hovedprocessoren skal
generere og læse bitstrømmene direkte med et portben. Det afhænger i høj
grad af hvad hovedprocessorens opgaver og arbejdsbelastning bliver.


Antenne:
En stor del af beslutningen om hvordan den ser ud/polariseres/vender
afhænger af hvad vi kan tage for givet om attituden. Det bør være muligt
at få kontakt med satellitten uanset om en evt. attituderegulering
kommer til at fungere. En måde at løse dette på er at stabilisere
satellitten passivt magnetisk og lade en dipol sidde på magnetens nord-
og sydpol. Polarisationsretningen vil kunne bestemmes på jordstationen
ved hjælp af et kompas. På den måde vil rotation omkring den sidste akse
ikke være noget problem. Den passive regulering kunne laves svag nok til
at den aktive kan overtage kontrollen, men stærk nok til at stabilisere
satelitten nok til at vi kan kommunikere med den i løbet af et par dage
hvis det skulle gå galt.


Hardware:
Efter mødet har vi i hardwaregruppen undersøgt de løsninger der er
beskrevet i papers fra andre CubeSats nøjere. Vi har fundet datablade og
referencedesigns på de chips der er brugt, hvilket bør kunne sætte os i
stand til at bygge noget.


Kommende møder:
Hele gruppen: Fredag 14/9, frokostpausen, kantinen i 342.
Vejledermøde: Onsdag 19/9, frokostpausen, mødelokaet i 326(?) <- Jeg
reserverer det hvis det er ledigt. Ellers er gruppelokalerne i 327 en
mulighed.
Antenne: Mødes naturligt tirsdag formiddag
Hardware: Tirsdag eftermiddag, IAU
System eng.: Mandag 10/9 1300, 326 1.sal


Det var alt hvad jeg kunne trække ud af mine papirer og hukommelse - der
er sikkert mere.

Vi tales ved,

/Niels