Ich arbeite daran, eine Punkt-zu-Punkt-Kommunikationsverbindung für einen Cubesat zu entwerfen . Ich möchte nur etwas von meinem Verständnis bestätigen.
Meiner Meinung nach ist es nur notwendig, die Funktionalität der physikalischen Schicht und der Sicherungsschicht zu haben. Warum brauchen wir eine IP-Adresse oder eine Transportschicht für eine einzelne Punkt-zu-Punkt-Verbindung? Aber vielleicht gibt es Probleme, die ich nicht kenne. Ich verstehe, dass wir in der Lage sein müssen, Pakete zu verfolgen, die nicht in der richtigen Reihenfolge ankommen oder überhaupt nicht ankommen. Dies ist offensichtlich ein äußerst herausforderndes Problem für ein großes Netzwerk wie das Internet, aber für eine einzelne Punkt-zu-Punkt-Verbindung erscheint es vernünftig, ein einfaches Paket-Wiederzusammensetzungsschema für uns selbst zu implementieren.
Unsere Mission ist die Überwachung des arktischen Meereises mithilfe von GNSS-Reflektometriedaten aus GPS-Signalen, die von der Erdoberfläche reflektiert werden. Je mehr Daten wir downlinken können, desto besser. Daher sind wir motiviert, Protokolle mit möglichst wenig Overhead zu verwenden.
Unser Transceiver ist ein Microhard n290 Transceiver , der in der Vergangenheit auf Satelliten geflogen wurde. Es ist nicht mit bestehenden Amateur-Satellitenstationen kompatibel, wir hatten nicht die Absicht, eine Schnittstelle mit diesen bestehenden Netzwerken herzustellen. Es bietet FEC in der Hardware und eine Rate von bis zu 1,2 Mbps Uplink oder Downlink.
Wir wissen, dass wir ein Protokoll brauchen, das uns eine „Paketschnittstelle“ offenlegt. Das heißt, wir brauchen ein Link-Layer-Protokoll, um den seriellen Datenstrom zu paketieren.
Da wir kein Netzwerk haben, brauchen wir keinen IP-Layer. Was eine Transportschicht betrifft, so müssen wir in der Lage sein, die Datenpakete in der richtigen Reihenfolge wieder zusammenzusetzen und Neuübertragungen anzufordern. Ist es möglich, so etwas wie TCP direkt auf die Verbindungsschicht zu legen und IP auszuschalten? Das scheint mir aber immer noch übertrieben zu sein. Unsere Telemetrie- und Statusdaten passen in ein einziges Paket. Was die Nutzlastdaten betrifft, müssen wir sie bei AFAICT nur aufteilen, die Daten kennzeichnen und ein Auftragsfeld bereitstellen. Gibt es einen Grund, dies nicht selbst zu tun? Es scheint keine schwierige Aufgabe zu sein. Ich habe es in Python mit Google-Protokollpuffern gemacht - ich kann eine Datei serialisieren, die Reihenfolge mischen und sie dann wieder zusammensetzen. Ich müsste Wiederholungsanfragen obendrauf setzen, aber alles andere sollte von der Verbindungsschicht gehandhabt werden.
Ich habe mir das Saratoga-Protokoll ( http://saratoga.sourceforge.net/ ) angesehen , aber es ist eine Transportschicht. Scheint also keine gute Wahl zu sein.
Das Punkt-zu-Punkt-Protokoll ( https://en.wikipedia.org/wiki/Point-to-Point_Protocol ) scheint der sinnvollste Weg zu sein. Rechts? Es ist so leicht wie es nur geht.
Danke für jede Anleitung :)
Warum beabsichtigen Sie nicht , ein vorhandenes Protokoll zu verwenden?
AFAICT, es gibt bereits eine Reihe von Protokollen, die über viele Jahre entwickelt wurden und viele der Probleme gelöst haben, basierend auf Forschung und Erfahrung. Also würde ich etwas verwenden, das funktioniert und debuggt wurde, es sei denn, Sie recherchieren. Wenn es sich um Forschung handelt, müssen Sie den vollständigen Anwendungsfall beschreiben und nicht nur einige spezifische Merkmale des Anwendungsfalls.
Alte Protokolle können überleben, einfach weil die Technologie in Satelliten nicht nur funktionieren muss, sondern auch getestet, charakterisiert und „zertifiziert“ werden muss, um im Weltraum zu funktionieren. Das ist ein teurer, spezialisierter und langsamer Prozess. Es ist also noch sinnvoller, Kosten und Zeit zu sparen, indem man etwas verwendet, von dem bereits bekannt ist, dass es zuverlässig funktioniert, als die üblichen erdgebundenen Ingenieurprojekte.
Handelt es sich um ein kommerzielles, Forschungs- oder Amateurprojekt?
Ich weiß, dass die Amateure das Äquivalent eines globalen Netzwerks von Bodenstationen aufgebaut haben, die an die nächste Station übergeben, wenn die Satelliten umkreisen (ein bisschen wie das Bodenstationsnetzwerk der NASA oder anderer Weltraumagenturen, aber unter Verwendung von Ausrüstung, die für verfügbar gemacht wird Teile eines Tages [die Besitzer der Geräte nutzen sie auch selbst für ihre Zwecke] durch begeisterte Laien). Versuchen Sie, dieses Problem zu lösen?
In diesem Fall handelt es sich möglicherweise nicht um eine einzelne Punkt-zu-Punkt-Kommunikation. Es können mehrere erdbasierte Stationen sein, die jeweils versuchen, mit demselben Satelliten zu sprechen. Oder es können mehrere erdgestützte Stationen sein, die versuchen, mit mehreren Satelliten zu sprechen.
Wenn es sich um ein Amateurprojekt handelt, wenden Sie sich direkt an die Gruppen. Die britische Amateursatellitengruppe ist befreundet, und ihre Mitglieder haben mit Kollegen in AMSAT-NL bei der Erstellung der Software und des Netzwerks für das auf Amateurfunk basierende internationale Netzwerk von Bodenstationen zusammengearbeitet. Sie bauten auch die kostengünstige Funkhardware, die zur Verfolgung ihres FUNCube CubeSat verwendet wurde.
Eines der frühesten drahtlosen Paketnetzwerke, ALOHnet , beeinflusste später Ethernet und Inmarsat. So können beispielsweise einige der erfolgreichen Ideen aus dieser Arbeit übernommen werden. Solange es funktioniert, keine nennenswerten Nachteile hat, nachweislich im Weltraum funktioniert und Hardware verfügbar ist, die getestet und weltraumzertifiziert ist, welche Motivation besteht, sich zu ändern?
Bearbeiten:
Es gibt einige Artikel zu hoher Latenz und sogar eine Stackoverflow-Frage zu Netzwerken mit extrem hoher Latenz , die einige Inspiration geben könnte.
Es gibt alte Protokolle mit debuggten Implementierungen. Diese haben den Vorteil, dass sie so alt sind, dass die Maschinen, auf denen sie ausgeführt wurden, nur über wenige Ressourcen verfügten und daher für Ihre Anwendung gut geeignet sein könnten.
Zum Beispiel das Kermit-Protokoll . In diesem Wikipedia-Artikel heißt es: "Kermit-Software wurde für Aufgaben verwendet, die von einfachen Schüleraufgaben bis zur Lösung von Kompatibilitätsproblemen an Bord der Internationalen Raumstation reichen." Es hat also einen nützlichen Stammbaum :-)
Es unterstützt ein " Sliding Window Protocol ", das eine selektive Neuübertragung unterstützt. Das sollte helfen, sich von Fehlern zu erholen und beschädigte Datenströme wieder zusammenzusetzen.
Es ist Open Source und hatte C-Implementierungen. Sie können also möglicherweise die Quelle abrufen und portieren. Kermit lief auf Rechnern mit weniger als 64k Adressraum. Es könnte also auf Ihre Hardware passen.
Selbst wenn Kermit nicht gut passt, würde ich empfehlen, sich alte Protokolle und Implementierungen (ca. 1980) anzusehen, da die Einschränkungen der Maschine mit den Einschränkungen Ihrer Bordhardware vergleichbar sein können. Selbst wenn Ihre Hardware weniger eingeschränkt ist als in den 1980er Jahren, könnte Ihr Energiebudget durch eine Protokollimplementierung mit geringen Ressourcen verbessert werden.
Sie haben ein Netzwerk, ob Sie es anerkennen oder nicht. Ihr CubeSat wird nicht der einzige im Orbit sein, noch ist es wahrscheinlich der einzige auf Ihrem zugewiesenen Kanal. Irgendwie müssen die Nachrichten Ihres CubeSats von anderen identifizierbar sein, und sich auf Ephemeridendaten zu verlassen (Ihre sollten über ... jetzt ... liegen) ist zerbrechlich.
Dito die Bodenstation. Insbesondere wenn Sie große Datenmengen verarbeiten möchten, benötigen Sie mehr als eine Bodenstation. Cubesats verwenden oft ein Netzwerk von Amateur-Bodenstationen, und wenn irgendein Typ in Woomera oder Jakutsk die Pakete abholt, die Sie aufgrund von Fading verloren haben, großartig! Aber Sie möchten wahrscheinlich nur, dass Ihre eigene Bodenstation den Satelliten steuert, also müssen Sie sowohl Bodenstationen als auch Satelliten identifizieren.
Sie können all diese Probleme lösen, indem Sie Ihr eigenes Protokoll erstellen ... mit einem eigenen Adressierungssystem ... aber die Wiederverwendung eines Protokolls ist wahrscheinlich weniger Arbeit und erhöht die Zusammenarbeit mit anderen.
Ich denke, Sie brauchen mehr als PPP - vielleicht wäre TCP (ohne IP) ein guter Kandidat.
tftp? - klein, leicht und bekannt.
(Einfache) Komprimierungstechniken können eine ausreichende Paketlänge einsparen, um IP realisierbar zu machen, und es Ihnen ermöglichen, Arbeitskräfte für interessantere Teile des Projekts neu zuzuweisen.
Kehren Sie zur IP-Entfernung zurück, sobald das Protokoll, das Gerät und die Anwendung funktionieren und vollständig mit vorhandenen Stacks getestet wurden.
Stefan Merfu
RJTK
Oldtimer
Oldtimer
gbulmer