Mars-robots krijgen eenvoudigere taken nu zon in de weg zit

De op Mars rondrijdende robots kunnen het in de komende weken wat rustiger aan doen. Door de komende conjunctie, waarbij de zon precies tussen de aarde en Mars in zit, kunnen radiosignalen vanaf de aarde verstoord raken. Daarom krijgen de robots een simpelere takenlijst.

"Het is weer die tijd", zei Roy Gladden, NASA's manager voor het Mars Relay Network. "Onze technici hebben onze ruimtevaartuigen al maandenlang op de conjunctie voorbereid. Ze verzamelen nog steeds wetenschappelijke data op Mars en sommige zullen proberen die data terug naar de aarde te sturen. Maar we proberen niet om commando's naar de robots te sturen, uit angst dat ze gaan handelen op een corrupt commando", aldus Gladden. Dat kan leiden tot onvoorspelbaar gedrag van de robots en daarom wordt dus een commandomoratorium ingesteld.

De zon-Marsconjunctie, waarbij Mars en de aarde zich aan tegengestelde kanten van de zon bevinden, begint woensdag en loopt tot 7 september. De zon spuwt heet, geïoniseerd gas vanuit de corona ver de ruimte in en tijdens de conjunctie kan dat gas de radiosignalen verstoren. Ter voorbereiding op deze periode worden sommige instrumenten uitgeschakeld, wordt nog snel data binnengehaald of wordt data opgeslagen. In de afgelopen twee weken zijn veel laatste instructies naar de robots gestuurd.

De aanpassingen verschillen per robot. Curiosity zal bijvoorbeeld niet langer vrolijk rondrijden, terwijl de eind november vorig jaar op Mars gearriveerde lander InSight zijn arm niet meer zal bewegen. De boven Mars vliegende Odyssey en Mars Reconnaissance Orbiter blijven nog wel data van Curiosity en InSight binnenhalen.

Dit alles betekent dat er voorlopig een pauze is aangebroken in de stroom ruw beeldmateriaal van de robots en andere Marsmissies. Zodra de conjunctie voorbij is, zullen de ruimtevaartuigen de verzamelde data naar het Deep Space Network van de NASA sturen. Technici zullen dan een volle week nodig hebben om alle data te downloaden, voordat de ruimtevaartuigen terug naar hun normale status kunnen. Als wordt vastgesteld dat er corrupte data tussen zit, kan die data doorgaans na 7 september nogmaals worden verzonden.

Lees meer

IT Banen

Deel je skills voor jouw droombaan Meld je aan!

IT trainingen bij Computrain

Reacties (60)

Apen-nootjes
28 augustus 2019 16:58

Typisch gevalletje van het two-generals problem:
https://youtu.be/IP-rGJKSZ3s

Niet zomaar op te lossen met encryptie enzo

TimoDimo
28 augustus 2019 15:25

"we proberen niet om commando's naar de robots te sturen, uit angst dat ze gaan handelen op een foutief, corrupt commando"

Corrupte dataverzending, dat kan toch niet meer tegenwoordig, waarbij alles digitaal gaat? Ik neem aan dat er een vorm van cryptologische validatie plaatsvindt. Het komt óf ongeschonden aan en komt door de foutcorrectie heen, óf het verzenden faalt? Of bedoelen ze iets anders?

Byron010
@TimoDimo • 28 augustus 2019 15:29

Dit staat letterlijk in de tekst:

De zon spuwt heet, geïoniseerd gas vanuit de corona ver de ruimte in en tijdens de conjunctie kan dat gas de radiosignalen verstoren.

Dat kan dus de data corrupt maken.

GoodspeeD
@Byron010 • 28 augustus 2019 15:43

Volgens mij is de oorzaak en de grootte van datacorruptie niet waar @TimoDimo het over heeft. Ongeacht de oorzaak en de grootte van corruptie, bestaan er manieren voor ontvangers (en verzenders) om zeker te zijn dat de data intact is. Dus of er komt data aan, je valideert dat die intact is en daar kun je dan iets mee. Of er komt corrupte data aan en die moet je negeren.

Zou het niet meer gaan gaan over het feit dat de kans groot is dat bijna alle data die aankomt corrupt is en het zinloos is om überhaupt commando's te sturen?

jvdmeer
@GoodspeeD • 28 augustus 2019 21:39

Probleem is misschien niet de checksum, maar dat een corrupt commando terecht wordt genegeerd, waardoor de rest de mist in gaat. Simplistisch:
Een commando als "Draai naar r3Ch%S" terecht negeren.
En dan het commando "Rijdt 40m vooruit" wel uitvoeren.

Zou wel eens ongewenste resultaten kunnen geven.

twizzle
@jvdmeer • 28 augustus 2019 22:56

Daarvoor hebben we natuurlijk packetnumbers uitgevonden maar goed liever een weekje uit bij de prijzen van die robotjes

TimoDimo
@GoodspeeD • 28 augustus 2019 15:57

Inderdaad, dat is ook de enige verklaring die ik kan bedenken, alle goedbedoelde antwoorden die uitleggen wat een checksum is ten spijt.

Foutcorrectie kan natuurlijk altijd, maar om in dit extreme geval enige effectieve bandbreedte over te houden zal er wellicht altijd een risico overblijven door de validatiemechanismen in te perken.

teek2
@Byron010 • 28 augustus 2019 15:42

Ja maar je voegt toch een checksum toe oid? Ik vind het ook maar een vreemd argument hoor.

mkools24
@teek2 • 28 augustus 2019 15:49

Het is geen TCP he, het zijn radiosignalen.

bwerg
@mkools24 • 28 augustus 2019 15:55

TCP en de fysieke communicatie zitten op heel verschillende niveaus van het netwerkmodel. Je kunt prima TCP over radiosignalen sturen (sterker nog, dat doe je waarschijnlijk de hele dag).

De fysieke laag biedt een onbetrouwbare manier om signalen te sturen, de transportlaag (zoals TCP) kan voor error-correctie zorgen, bijvoorbeeld met checksums, zodat de applicatielaag een betrouwbaar kanaal heeft.

KopjeThee
@bwerg • 29 augustus 2019 07:24

Voor de geinteresseerde lezer, zie bijvoorbeeld: https://nl.m.wikipedia.org/wiki/OSI-model

teek2
@mkools24 • 28 augustus 2019 15:52

Mja, lijkt me toch dat je korte instructies in setjes stuurt en daarover kan je dan toch makkelijk een checksum berekenen en kijken of alles goed is overgekomen? Anders gaat het vast vaker fout, net als UDP, en dat hoeft niet eens naar Mars.

!GN!T!ON
@teek2 • 28 augustus 2019 15:57

UDP zit helemaal geen checksum, error correctie of wat dan ook op, dat wordt gewoon verstuurd en aangenomen dat het is aangekomen.

Maar nee helaas gaat dat niet zo makkelijk, had laatst een yt video gevonden die dit heel netjes en begrijpelijk uitlegt maar ik kan hem 1-2-3 niet terugvinden. Als ik hem vind zal ik hem hier nog toevoegen.

TomWesstein
@!GN!T!ON • 28 augustus 2019 16:06

Op UDP misschien niet, maar de data die je verstuurd kan je eenvoudig voorzien van een checksum.

teek2
@!GN!T!ON • 28 augustus 2019 16:21

Ik zeg ook dat UDP geen checksum heeft en dat het daarom fout gaat.

robvanwijk

Wetenschap
Nasa
Ruimtevaart

@!GN!T!ON • 29 augustus 2019 21:50

UDP zit helemaal geen checksum, error correctie of wat dan ook op, dat wordt gewoon verstuurd en aangenomen dat het is aangekomen.

Je haalt twee dingen door elkaar:

Aan de ontvangende kant controleren óf het bericht goed is aangekomen
Aan de verzendende kant laten weten dát een bericht goed is aangekomen

TCP doet allebei, UDP alleen het eerste. Meer informatie (en linkjes naar de RFCs, als je echt de details wilt weten) op Wikipedia.

Wel moet ik toegeven dat de checksum (alleen error detection, UDP heeft geen enkele vorm van error correction) nogal kort is. Met 16 bits heb je slechts 65.536 mogelijke waarden, dus van elke 65.536 verkeerd ontvangen berichten zal er (simplistisch gezien) eentje alsnog door de check heen komen. Van de andere kant... de checksum in TCP is precies even groot. Als ik de communicatie met Mars zou moeten ontwerpen, dan zou ik in mijn eigen protocol (dus bovenop UDP; ik vermoed dat TCP niet goed overweg zal kunnen met round trip tijden van tientallen minuten) nog een extra, veel grondigere error detection toevoegen (én error correction, zodat je niet bij één omgevallen bitje de data meteen opnieuw moet sturen). Ik heb het vermoeden dat als ik dat kan bedenken, dat er dan bij NASA ook wel iemand rondloopt die dat idee gehad heeft.

Dat gezegd hebbende, waarom zou je het risico nemen? De kans dat pakketjes succesvol arriveren is klein, de kans dat alle pakketjes die samen een commando vormen allemaal aankomen is miniem. Je zult er dus toch al rekening mee moeten houden dat het niet lukt. Als je dat weet, waarom zou je het dan proberen? Hoe klein het risico ook is, we hebben het wel over het risico om de sonde permanent te beschadigen; waarom zou je het erop wagen als je in feite niets te winnen hebt en alles te verliezen?

[Reactie gewijzigd door robvanwijk op 29 augustus 2019 21:51]

3raser
@mkools24 • 28 augustus 2019 16:06

TCP gaat uiteindelijk ook over radiosignalen. Of dat nu is via de fysieke netwerkkabel of via wifi, beide werken met radiosignalen. De enige uitzondering is als je hele netwerk uit glasvezel bestaat. Dan zijn het lichtsignalen.

De reden waarom NASA waarschijnlijk niet zoveel heeft aan checksums is dat een pakketje niet zomaar opnieuw kan worden verzonden. Een round-trip time naar Mars is nog relatief klein maar het Deep Space Network stuurt bijvoorbeeld ook data naar Voyager 1. Die data doet er volgens mij zo'n 20 uur over. Als je een datapakket ontvangt waarvan de checksum niet klopt dan zou je dat door moeten geven aan de verzender. Dat betekend dat je na 40 uur pas weet of de data goed is aangekomen. Op die manier wordt het versturen van veel data vrijwel onmogelijk.

Om precies te weten hoe het werkt zul je de details over het Deep Space Network moeten lezen.

Chinco
@3raser • 28 augustus 2019 19:04

Een checksum kun je toch ook alleen gebruiken om te valideren of de opdracht volledig en goed is aangekomen? Zendt het bericht x keer uit en als ze allemaal corrupt overkomen, doe niks.

Een corrupt bericht als oorzaak voor ongewenst handelen klinkt niet logisch. Of er moeten andere redenen voor zijn.

robvanwijk

Wetenschap
Nasa
Ruimtevaart

@Chinco • 29 augustus 2019 22:21

Een corrupt bericht als oorzaak voor ongewenst handelen klinkt niet logisch. Of er moeten andere redenen voor zijn.

Lees de reacties onder dit bericht en je hebt die "andere reden" te pakken; zelfs op T.net (met toch redelijk wat mensen met veel relevante kennis) kost het moeite om het correct uit te leggen en worden er alsnog details door elkaar gehaald. NASA moet communiceren naar "het grote publiek", waaronder een heleboel mensen die niet of nauwelijks kennis hebben van netwerkprotocollen (let op: ik noem niemand dom; "kennis" en "intelligentie" zijn twee heel verschillende dingen). Ze kunnen het natuurlijk niet maken om ronduit te liegen, maar "een sterk vereenvoudigde weergave van de feiten" gebruiken in je persbericht kan wel. Je wilt een kindje van acht die foto's van Mars super gaaf vindt niet vervelen met berekeningen over de netto-bandbreedte gegeven de hoek Mars-Zon-Aarde; die wil je gewoon geruststellen "we liggen nu een weekje stil, maar we zijn natuurlijk heel voorzichtig met die robot die jij zo geweldig vindt, dus over twee weken gaan we weer verder!".

dgompie

@3raser • 28 augustus 2019 16:12

Elektriciteit is voor zover ik weet geen radiosignaal, licht dan eigenlijk weer wel (zowel licht als radiosignalen zijn elektromagnetische signalen)

Weer wat bij geleerd!

[Reactie gewijzigd door dgompie op 29 augustus 2019 11:39]

pe1pme
@dgompie • 28 augustus 2019 18:13

Elektriciteit, mits we het over AC hebben, zijn absoluut/gedragen zich zeker als radio signalen en wel met een zeer lange golflengte. Dat gaat zelfs zover dat de hoogspanningskabels die overal in het land bovengronds hangen "getwist" zijn zodat op 1/3 en 2/3 van een trace de fases van plek verwisselen om de LC invloeden ten opzichte van elkaar en van aarde te compenseren.

batjes

Nasa

@dgompie • 28 augustus 2019 23:44

Het zit in het woord ;-)

TimoDimo
@3raser • 28 augustus 2019 16:28

In dit geval maakt het dus weinig uit aangezien de afstand maar een paar lichtminuten is. En Curiosity en zijn metgezellen kunnen lange tijd volledig autonoom functioneren. Ze ontvangen programma's die ze uitvoeren en waarmee ze naar ik vermoed weer uren vooruit kunnen. Even terugmelden als er een deel van een programma niet goed aangekomen is, ondanks de foutcorrectie, lijkt me dus geen enkel probleem.

En de Voyagers krijgen nagenoeg geen commando's meer, het gaat voornamelijk om het terugzenden van data. Wat vertraging in de commando's of terugmelding van foute berichten is dus ook geen probleem.

Mushroomician
@mkools24 • 28 augustus 2019 19:00

Je kunt TCP zelfs over een waterleiding kloppen of via rooksignalen sturen, al is dat niet echt snel en handig.
Het medium staat los van het protocol.

Je kunt het zien als een soort morse-code met uitgebreide grammaticaregels en zinsopbouw voor internetapparatuur. Een taal dus.

[Reactie gewijzigd door Mushroomician op 29 augustus 2019 03:32]

robvanwijk

Wetenschap
Nasa
Ruimtevaart

@Mushroomician • 29 augustus 2019 22:00

Je kunt TCP zelfs over een waterleiding kloppen of via rooksignalen sturen, al is dat niet echt snel en handig.

Goed punt. Heel goed punt. Maar echt helemaal het verkeerde voorbeeld; je had moeten zeggen dat je IP pakketjes ook via postduiven kunt versturen.

TimoDimo
@Byron010 • 28 augustus 2019 15:50

Ik weet niet waar je op doelt, volgens mij staat dat niet in de tekst

. Mijn vraag was namelijk waarom dit de data dan corrupt kan maken, in de aanwezigheid van validatie middels controlegetallen en foutcorrectie.

ThaStealth
@TimoDimo • 28 augustus 2019 16:01

Zoals je thuis op je TV ook wel eens hebt met digitale TV krijg je soms artifacts (die blokken). Dat komt omdat er een paar bits 'omvallen' (je denkt dat het een 0 is, maar in werkelijkheid is het een 1). Foutcorrectie en checksums werken maar tot op zekere hoogte, als een maar message bytes en net de goede checksum bit(s) omvallen krijg je dus een corrupt bericht wat wel als geldig word gevalideerd.

Pliskin
@ThaStealth • 28 augustus 2019 23:22

De kans dat én een aantal bits zo wordt aangepast dat het een logisch commando is én op een of andere manier de CRC ook nog klopt is gigantisch klein, maar: ik snap wel waarom ze 0 risico willen lopen.

Byron010
@TimoDimo • 28 augustus 2019 15:57

Ik zal jouw vraag wel wat anders lezen; Het laat namelijk ruimte over voor een optie 3: "De data wordt wel goed verzonden maar onderweg beschadigt het zodanig dat het niet door de foutcorrectie komt.

Waarom exact het gas van de zon de radio signalen aantast kan ik inderdaad geen antwoord op geven

Edit: Doelend op jouw gequote stukje heb je wel een punt, werken op een foutief commando zou niet moeten kunnen als het toch niet door de foutcorrectie komt.

[Reactie gewijzigd door Byron010 op 28 augustus 2019 15:59]

rjkers
@TimoDimo • 28 augustus 2019 15:41

correctie:

Het hangt sterk af hoe het communicatie systeem gedesigned is. Hier onder hoe het misschien fout zou kunnen gaan.

---------------

Er kan altijd alsnog misgaan, echter is de kans zo ontzetten klein, dat het in het dagelijks leven word verwaarloosd.

Vaak word data gecheckt met een checksum of CRC. Dus ipv alleen data versturen zend je wat extra bytes mee om de verzonden data mee te valideren. Aan de ontvangende kant word de data door een speciale functie gegooid, met als resultaat een hash. Deze hash moet gelijk zijn aan de meegestuurde CRC. Is dat niet t geval dan is de data corrupt. Als dat wel het geval is word er van uit gegaan dat er geen fouten zijn.

Echter kan je data EN je CRC zo veranderen dat je wel corrupte data hebt, maar de CRC check aan de ontvangende kant toch hetzelfde is.

https://www.sciencedirect...%20cannot%20be%20detected.

https://nl.wikipedia.org/wiki/Cyclic_redundancy_check

[Reactie gewijzigd door rjkers op 28 augustus 2019 15:43]

SubSpace

@rjkers • 28 augustus 2019 16:06

Zelfs bij een CRC32 is die kans 1 op 4.2 miljard. Bij iets moderns als SHA256 is die kans nog vele ordes van grootte kleiner, dus dat is echt geen argument als je het over verstoring van een signaal hebt 🙂

MrDayOff

@TimoDimo • 28 augustus 2019 15:39

Als de commando's één voor één binnen komen, en de laatste is rij vooruit en stop komt niet aan blijft ie dus alsmaar rijden. Maar dit is ook maar een 'wild guess'.

SubSpace

@MrDayOff • 28 augustus 2019 15:53

Dat zou echt een heel naïeve implementatie zijn. Het is logischer om een batch commando's te sturen, die in zijn geheel wordt uitgevoerd, of niet. Een soort mini-programma à la https://codecombat.com/ 🙂

steveman
@TimoDimo • 28 augustus 2019 15:38

Foutcorrectie werkt ook maar tot zekere hoogte. Zeker met zo'n gigantische stoorzender als de zon er tussen lijkt me dit een verstandig besluit.

Byron010 heeft dan ook volkomen gelijk.

Stevie-P
@steveman • 28 augustus 2019 15:44

Maar storing is random, hierdoor kan je dus een berekening doen om te valideren of je ontvangen commando intact is. Dit is tegenwoordig triviaal om te doen.
Je zou zelfs met een beetje overhead je commando's repareren indien ze niet intact over komen. Denk aan Parchive.

Mars is tussen de 4 en 20 lichtminuten van de aarde af. Dus als je 40 minuten de tijd hebt kan je ook wachten met een volgend commando versturen tot je de 'correct ontvangen' ping binnen hebt.

steveman
@Stevie-P • 28 augustus 2019 16:03

Ja storing is willekeurig, maar of het storing is met een p van 0.0001 of 0.50 (ik noem maar wat) maakt nogal veel uit. Als je signaal maar genoeg naar de gallemiezen is geholpen ben je gewoon screwed en mag je gaan herhalen.

Dus dan kun je wel elke keer 40 minuten gaan zitten op een nieuwe poging... of je geeft de units wat te doen in tussentijd.

Nou doe dat laatste maar dan.

Zenomyscus

@TimoDimo • 28 augustus 2019 15:39

Nu weet ik niet hoe het systeem is ontworpen, maar wanneer je een veelvoud aan commands hebt die erg op elkaar lijken dan is het nog steeds een risico. Foutcorrectie zou kunnen, maar kan ook mis gaan als je een update doet om de snelheid te wijzigen.

Als voorbeeld: Voor het gemak kunnen we de snelheid wijzigen van 0-100. Als een waarde "wefwefs" binnenkomt, dan is dat duidelijk een fout. Dit zou je kunnen negeren. De waarde "-2" zou je kunnen corrigeren naar "0" (of dat wenselijk is weet ik niet). Maar wat als je de waarde "10" stuurt en de zon maakt er perongeluk "100" van? Dan heb je een probleem.

Goed, die kans lijkt me zeer klein. Ik geef ook een erg simpel voorbeeld. Maar ook met foutcorrectie zullen zij het risico te groot vinden.

[Reactie gewijzigd door Zenomyscus op 28 augustus 2019 15:40]

Cio
@TimoDimo • 28 augustus 2019 15:45

Niks is onfeilbaar en capaciteiten zijn beperkt, iedere gram telt en dan ga je geen extra stroom, koeling en cpu power meenemen.

Ik weet het niet zeker, maar gezien dit bericht is er gekozen op correctie/validatie te besparen.

Toettoetdaan
@TimoDimo • 28 augustus 2019 16:03

Dat hangt af van de implementatie, misschien sturen ze per acht bits twee bits extra ter validatie. Dat is voor veel toepassingen al voldoende en kost weinig overhead op hardware en de al erg dunne verbinding.

Maar als er genoeg bitjes 'omvallen' en/of je extra bitjes ook 'omvallen', dan kun je eindigen met een valide commando. (Alleen niet hetgeen je hebt gestuurd)

Let op, de commands naar deze apparaten zijn behoorlijk low level, dus de meeste commando's is een directe aansturing.

Waarschijnlijk is de kans heel klein dat het fout gaat, maar willen ze voor de zekerheid het risico niet nemen.

Rob

@Toettoetdaan • 28 augustus 2019 16:14

Let op, de commands naar deze apparaten zijn behoorlijk low level, dus de meeste commando's is een directe aansturing.

Ik mag hopen dat dit niet het geval is met de latency op de communicatie

batjes

Nasa

@Rob • 29 augustus 2019 00:02

De Mars rovers worden wel in low level aangesproken en commando's worden 'direct' uitgevoerd. Er zit geen scripting laag tussen oid en error checking doen ze hier op aarde in de Rover Sequence Editor. De aansturing is low level want C, je spreekt zonder tussenlaag tegen de modules aan en direct als in, het doet exact wat het toegestuurd krijgt.

mjz2cool
@TimoDimo • 28 augustus 2019 15:42

Er is dan een 3e mogelijkheid: het verzenden faalt niet, maar komt ook niet ongeschonden aan. Er zal vast één en ander gecheckt worden na het ontvangen van een commando, maar je wilt niet het risico lopen dat corrupte commando's door die checks heen komen.

bwerg
@mjz2cool • 28 augustus 2019 16:03

Dat is gewoon een kwestie van kansberekening. Hoge kans op corruptie, dan ook veel error-correctie.

Let wel: zelfs bij communicatie op aarde, zoals je dat elke dag gebruikt (bijvoorbeeld om dit te posten), is er altijd een minieme kans dat corrupte data alsnog geaccepteerd wordt. Voor de mars-rover zal dat sneller gebeuren dan op een vast netwerk op aarde, dus hier zullen ze toch al de nodige statistiek voor uit de kast trekken.

Sorki
@TimoDimo • 28 augustus 2019 15:48

Heel veel 0-votes op je reactie maar ik vind je reactie juist heel terecht.

Ik kan me ook niet voorstellen dat je een robot op mars aanstuurt zonder cryptologische validatie van je commandos. Matched het niet, doet hij niets.

bwerg
@TimoDimo • 28 augustus 2019 15:50

"tegenwoordig" hebben we ook zodanig veel bandbreedte dat wat extra data voor error-correctie niet zo'n probleem is.

Dan nog zou je denken dat je de sterkte van de error-correctie instelbaar kan maken, en zodanig dat je weinig overhead hebt als error-correctie niet nodig is, en wat meer als het wel nodig is. Misschien is dit te complex, al is het programmeer-technisch nou niet zo heftig. Of de corruptie is zodanig heftig dat het uren zou duren om überhaupt een commando door te krijgen, zodat het de moeite niet meer waard is.

[Reactie gewijzigd door bwerg op 28 augustus 2019 15:57]

Rob

@TimoDimo • 28 augustus 2019 15:52

We gaan er vanuit dat deze robots redelijk op zichzelf kunnen werken, want in het gunstige geval duurt een antwoord van een robot op een commando 6 minuten.
Omdat commando's duur zijn is een check op de commando's ook gewenst zijn. Laten we er nu vanuit gaan dat er een md5 overheen gaat.

In het geval dat er weinig storingen zijn, zou je de robot het commando kunnen geven: pak de steentjes op positie A, B en C en plaats deze in container D.

De kans dat dit bericht aankomt is groot en je zal er een bevestiging van krijgen na 6 minuten. Beide kanten netjes met de md5 check.

Nu zit de zon met zijn ruis ervoor. Je stuurt hetzelfde commando naar de robot maar je krijgt na 42 minuten (21 minuten heen en terug) nog geen antwoord. Je hebt er ook geen idee van of de robot het ontvangen heeft of dat jij het antwoord niet ontvangen hebt.
Dan is het veiliger om kleine, simpele taken te sturen die niet van groot belang te zijn.

TomWesstein
28 augustus 2019 15:21

Hadden we nu maar een comm-sat hangen op Lagrangepunt 4 of 5

[Reactie gewijzigd door TomWesstein op 28 augustus 2019 15:22]

The P Man
@TomWesstein • 28 augustus 2019 15:48

Waarom hebben we die nog niet? Volgens mij schieten we jaarlijks genoeg satellieten de ruimte in (wel tot een bepaalde hoogte dan).

TomWesstein
@The P Man • 28 augustus 2019 16:08

Omdat het om maximaal enkele weken per jaar gaat dat dit voorkomt. En een satelliet naar L4 of L5 schieten kost wel een stuk meer dan de lage banen waar 90% van de huidige lanceringen naar toe gaat.

Simpelweg kosten vs. baten verhaal.

Sme4gle
@TomWesstein • 28 augustus 2019 16:09

dit is dus exact wat ik zat te bedenken!

Anoniem: 1092407
@TomWesstein • 28 augustus 2019 18:09

Had SpaceX maar een kleine satelliet ipv een Tesla in een baan om de zon geschoten. Dan hadden we nu altijd een kunstplaneet gehad als relay.

mbb
@TomWesstein • 5 september 2019 10:40

Daar zat ik ook aan te denken.
Waarschijnlijk omdat tot recent er geen behoefte aan was omdat er zo weinig data geproduceerd werd dat het makkelijk gebufferd kon worden. En dus geen goede kosten/baten verantwoording zou hebben.
Echter door toename aan missies en meer/betere sensors lopen we binnenkort tegen de bandbreedte beperkingen van het (NASA) Deep space Network aan.
Om dan alle Mars data een paar weken op te slaan en in een keer doorsturen zal dan lastiger worden.
Ook zou je het Mars netwerk van radio naar laser signalen kunnen laten overstappen, waardoor de bandbreedte toeneemt en het een eigen netwerk kan krijgen.

Dat lijkt een goed moment om zo'n satelliet te bouwen, eventueel door een NASA partner die zich daarmee 'inkoopt'.

CAP-Team

28 augustus 2019 15:38

Tot september volgend jaar? Lijkt me stug..

Auteur+1

Koekiemonsterr
@CAP-Team • 28 augustus 2019 15:49

Ja dat is ook stug, gebrek aan koffie zal ik maar zeggen. Op de een of andere manier had ik 2019 in me hoofd vertaald naar volgend jaar....Anyway, aangepast

0vestel0
@CAP-Team • 28 augustus 2019 15:42

Je hebt gelijk. In het originele bericht staat

The daily chatter between antennas here on Earth and those on NASA spacecraft at Mars is about to get much quieter for a few weeks.

...will run from Aug. 28 to Sept. 7, 2019

Edit --> Had een paar typo's in de reactie. Vandaar de wijziging

[Reactie gewijzigd door 0vestel0 op 28 augustus 2019 15:43]

kippy
@CAP-Team • 28 augustus 2019 15:42

Is ook dit jaar, niet volgende jaar.
https://mars.nasa.gov/all...ht-sky/solar-conjunction/

Foutje kan gebeuren. Maar dan nog 2 weken per jaar is wel iets om rekening mee te houden.

Striker_zelf
28 augustus 2019 15:45

Tot September volgend jaar ? Lijkt me heel sterk dat Mars meer dan een jaar achter de zon staat...

Zo lang duurt het dan ook niet, in het originele artikel staat: "will run from Aug. 28 to Sept. 7, 2019"

PureTryOut
@Striker_zelf • 28 augustus 2019 16:10

Het artikel is intussen bijgewerkt, er staat niet meer dat het tot september volgend jaar duurt. Gewoon "begint woensdag en loopt tot 7 september."

Plainside
28 augustus 2019 15:36

Als onderzoeker zou ik gestoord worden, heel jaar wachten voordat er weer commando's weggestuurd kunnen worden. Wie weet wat er in de tussentijd kan gebeuren.

Misschien dat toch de groene mannetjes naar buiten komen /s ?

Rabb
@Plainside • 29 augustus 2019 01:50

Was een typo, het duurt maar tot 7 september dit jaar. Dus 1,5 week.

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

Mars-robots krijgen eenvoudigere taken nu zon in de weg zit

Wat vind je van dit artikel?

Lees meer

Mission to Mars: de Curiosity-rover

IT Banen

IT trainingen bij Computrain

Reacties (60)

Sorteer op:

Weergave: