Ballonmission: Mission Control und Bodenmannschaft

Moin! Nachdem der Ballon langsam Form annimmt, wird es auch Zeit, sich um die Bodenmannschaft zu kümmern, damit wir das Ding dieses Mal auch finden, verdammtnocheins.

Hierfür schlage ich vor:
a) Mission Control.
Wichtigstes Feature: ein Feldtelefon, damit man sich mit "Mission Control" melden kann. Hat außerdem noch wer nen GSM-Totschläger, den man nebendran stellen kann?
Ansonsten sollte dort jemand mit ner amtlichen CB-Funke sitzen. Zweckmäßig wäre m.E. Mission Control auf den Berg zu verlagern, und mit einem Rengdengdeng zu versorgen, um eine weitreichende Abdeckung der Umgebung zu ermöglichen. Hier würde sich ein Anhänger mit entsprechenden Einbauten eignen. Lars kann vielleicht was zu den geographischen (und rechtlichen) Gegebenheiten sagen.
Weiterhin sollte an Mission Control ein weltherrschaftlicher Rechner stehen. Das Grundgerüst steht hier bereits und ist mit 9 Monitorausgängen bestückt. Darauf soll laufen:
- Xastir mit 2 Funken, 1x APRS auf CB RX/TX, 1x APRS auf 2m nur RX (mangels Lizenzen macht TX hier wenig sinn). Vllt bekommt man digipeaten hin, dass die Pakete vom Ballon auch auf CB erscheinen. Wenn die z.B. über Harrys Funke geblasen werden, dann weiß wenigstens jeder, wo der Ballon gerade ist.

- Mein noch fertigzustellendes SSTV-RX-Tool. Zur Zeit sieht man die Bilder nicht, während sie ankommen.

- Diverse Telemetrie vom Ballon

- Browser mit Inet zwecks Kommunikation mit Funkbasis etc.

- Empfang von 23cm-Video, falls vorhanden

b) Bodenmannschaft.
Mein Auto hat wieder TÜV, steht damit auch wieder zur Verfügung, den Rechner gibts auch wieder (der ist dann hoffentlich auch halbwegs entstört).
Die Ausrüstung der Fahrzeuge und Handfunken mit CB-APRS wird bereits vom Frickelkommando Rhein-Main vorangetrieben. Die Sonstige Ausrüstung fürs Auto steht noch nicht wirklich fest, irgendwelche Peilausrüstung wäre wohl ganz gut. Xastir zu betreiben ist natürlich cool, aber relativ schwer aufzusetzen und bringt potentielle EMV-Katastrophen mit sich.
Schön fände ich, wenn ein weiteres Fahrzeug mit CB und APRS zur Verfügung stünde, Geräte hätten wir über (glaube ich).

c) Personelles und Organisatorisches.

Vorschlag zur Personalplaung:
- 2 Mann Mission Control.
- Je Fahrzeug Fahrer, Funker, Peiler, macht 3 Mann.

Ich bin dafür, dass das komplette Rückholkommando sich vor dem Treffen darauf einigt, wer was tut und wir uns mit dem Equipment vor dem Start vertraut machen. Ich will natürlich wieder überall sein und alles machen...

Das hier ist ein Vorschlag. Gerne können Teile davon weggestrichen werden oder weitere Vorschläge gemacht werden. Aber ich wollte man den Denkprozeß in Gang bringen.

Grüße für die Weltherrschaft,

Ferdinand

DAS Problem kenne ich gut

----

Was der Rechner mit den 9 Ausgängen auf jedenfall braucht: Audioaufzeichnung vom 27Mhz CB-Funk und gleichzeitig müssen die Audiodaten nach digitalen Datenpaketen gescannt werden. Die gewonnen Daten (VBat, Innen/Außentemperatur, Druck, Höhe, GPS-Koordinaten) werden dann auf einem der Monitore angezeigt. Darum werde ich mich kümmern (Vermutlich ein kleines Java-Programm)

Aber bei deiner Liste fällt mir was auf: Was soll denn alles als Payload mit?! Ich zähle:
* APRS im 2m-Band
* APRS im CB-Band
* CB-Sprachfunkte
* SSTV
* 23cm Video

Da sollte man vll mal das Wiki up-to-date bringen: http://www.fingers-wiki.de/ballonmission_2013_-_planung_und_vorbereitung
Wie sieht das mit dem Gewicht aus?

Da ich mit digitalkram mehr anfangen kann als mit Analogpeilung würde ich mich einfach mal für Mission Controll bewerben

Was in deiner Liste noch fehlt ist ein CB-Funkgerät für die Kommunikation mit dem Suchtrupp.

lg
Torben

Gibts wirklich CB-APRS aufm Ballon?
Ich hatte daran gedacht, den Suchtrupp mit CB-APRS auszustatten.
Die Decodierung der APRS-Telegramme ist bereits implementiert, das Rauslesen der Telemetriedaten noch nicht. Auf dem Rechner läuft nen Debian, die Decodierung kannst du gerne machen, sag mir dann in welchem Format du die Daten haben willst. Dafür müsste aber auch erstmal das Format der Telemetriedaten des Ballons feststehen.
Zur Vorbereitung könnte ich auch das System zusammen mit nen paar Funken ans Netz hängen, so dass man das Zusammenspiel schon mal üben kann.

Andere Sache: kann man dem APRS-Gedöhns aufm Ballon beibringen, irgendwie aufm UART Temperatur und Position rauszuhauen, damit die dann auch im runtergesendeten Bild erscheinen?

Der Ein oder Andere hat es wohl mitbekommen, dass ich eine kleine Schaltung erstellt habe, um APRS Daten zu generieren. Quasi ein UART -> APRS Umsetzer. Eigentlich war der Einsatz für das CB APRS System, aber man könnte das auch nutzen um die Ballon Position und andere Daten zu übertragen.

Platinen dafür sind momentan auf dem Postweg zu mir.

Ein (oder Zwei) schöne GSM Geräte habe ich auch noch ;-) aber wie letztes Jahr gezeigt hat, würde ich diese neben der Empfangstechnik eher aus lassen.

Achso nein, CB-APRS gibts nicht - ich hatte deine Liste falsch interpretiert. Vergiss es - CB-APRS für den Suchtrupp macht Sinn

Dann brauchen wir eine Livekarte wo Ballon- und Suchtruppposition angegeben ist.
Allerdings hatte Jan ja auch schonmal bezweifelt ob wir überhaupt einen Suchtrupp brauchen?



Den Teil verstehe ich nicht 100%ig bzw ich glaube wir reden an einander vorbei
Es gibt ja zwei digitaldaten sendende Systeme. Einmal Jans APRS und die CB-Sprachbake die auch regelmäßig Digitaldaten sendet.
Ich kenne die Sensorik vom APRS-Sender jetzt nicht, aber soweit ich weiß ist da nur GPS drann.

Zu der Sprachbake: Die könnte die Daten an den SSTV-Sender weiter geben, allerdings ist der UART schon vom GPS belegt. Kann das SSTV-Modul als I2C-Slave arbeiten?

Und was soll der Rechner jetzt alles empfangen? 27Mhz CB-Funk, SSTV, 23cm-Video und was noch?
Sounddaten vom 27Mhz CB-Funk müssten dann an zwei stellen verarbeitet werden, einmal muss das aufgezeichnet werden und ein anderes Programm muss die Pakete dekodieren (vermutlich RTTY).

Wie wärs mit einer kleinen Zeichnung wie du dir das vorstellst?

Jungs, ihr seit Euch bewusst, das der Möller gerne mal 100-150km(luftline) zurrücklegt? (Lässt sich 2 Tage vorher gut vorrausberechnen)

Alternativvorschlag :
Ich spende das APRS-Geraffel. ( Wenn das nämlich klappt, sind das gerade mal so 10-20 Eur Bauteilkosten)
Also wenns so weit ist, dann machen wir das ganze kurzfristig in AFU und CB Foren publik, und der der in der nähe ist, und sich berufen fühlt, geht auf jagt.
Und den rest schickt er dann bitte zurrück.
Die dürfen dann an unserem Spass einfach mal teilhaben..

lg Jan

Aktuelle Planung ist,das ich auf jeden Fall komme. Wenn, was diesmal sehr wahrscheinlich ist, dann mach ich auch den Rückholer, so ist nämlich der offizielle Begriff (aus der Segelflugsprache, weiteste Tour waren 300km Luftlinie, aber das geht auch viel weiter). Mein Auto hat APRS mit 50W und gleiches für 2m /70cm FM, Navi und alles an Board! Sprit wird im Tank sein

Also die 100km Luftlinie sind ja erstmal kein grundsätzlich großes Problem, und lass uns doch mal spielen ;-) Ob wir dann noch CB Kontakt haben, wird sich zeigen müssen, ich melde aber Zweifel an. Ob wir wirklich so weit kommen, wissen wir aber auch gar nicht, der letzte Ballon kam ja zumindest nach Track auch nicht so weit.

ääähm... ich habe den SSTV-Sender noch garnicht fertig... also kann ich das Datenformat noch quasi beliebig wählen... Kann der atmega64 als i2c-Slave arbeiten?

Zeichnung der Anordnung folgt noch, ist auch bestimmt noch Subject to change. Jetzt gehe ich aber erstmal schlafen, die vollnächtliche Diskussion über Ethik in der Forschung war etwas hart...

Gute Nacht,

Ferdinand

Theoretisch kann der Hardware-I2C auch als Slave arbeiten, allerdings müsste der dann immer zwischen Master und Slave umschalten um die I2C-Sensoren zu bedienen. Multimaster-Betrieb würde ich gerne vermeiden weil ich es auch noch nie gemacht habe.

Ich glaube es ist so gedacht:
Ein Controller als I²C Master, der Sensoren ausließt, GPS Strings verarbeitet, Sprachansagen macht, evtl. APRS Meldungen sendet und auch per I²C mit dem SSTV Sender kommuniziert und Texte einblendet.

So ähnlich meinte ich das

Der Mega64 im AVR sammelt die Daten, sendet Sprachpakete und gibt gleichzeitig die Daten per I2C an den SSTV-Sender weiter.
Aber ferdimh hatte vorgeschlagen den SSTV-Sender zum I2C-Master zu machen, worauf sich mein Einwand bezog.

Ich habe das so verstanden, dass er den Atmega auf dem SSTV Sender als Slave laufen lassen will. Er wird sich ja dazu äußern, wenn er das hier sieht ;-)

Ich sehe den Slave-Betrieb auch sehr Problematisch.
Während der Ansage oder der Sensorkommunikation wäre sowiso kein Interrupt möglich.

Wie wäre es denn mit einem zusätzlichem Attiny85 o.ä. für die Kommunikation, der grundsätzlich als TWI/I²C-Slave arbeitet.

Der Sprachteil und evtl. auch der APRS-Teil würden dann die Daten zu beliebigen Zeitpunkten als Meister auf dem Attiny aktualisieren und der Videosender könnte die Daten zu beliebiger Zeit ebenfalls als Master abrufen.

---

Gibt der Hardware-TWI bei einer (seltenen) Multimaster-Kollision eigentlich irgendwo eine Fehlermeldung aus ?
Dann könnte man die Empfangenen Daten einfach ersatzlos verwerfen, andernfalls würde der Videosender für einen Aktualisierungszyklus nur Datenmüll anzeigen.

Wichtig wäre nur, dass die Master ein ungerades Timing haben, damit sich die Kollisionen nicht widerholen (z.B. Master1 wird alle 60s aktiv, Master2 alle 61s, Master3 alle 63s usw.).

Gruß,
Gerald

Ich habe mir das grade nochmal durchgelesen und jetzt kann man es auch so Interpretieren das ein ATmega64 im SSTV sitzt und ferdimh gefragt hat ob der Mega64 überhaupt Slave sein kann -> Ja.
Und jetzt werde ich warten was ferdimh dazu etwas sagt

Genau so meinte ich es. Problematisch ist, dass auf dem SSTV-AVR während des Sendens 60000 Interrupts pro Sekunde einschlagen. Da hat man wenig Zeit, noch Daten einzusammeln. Idealerweise würde man die Daten während der Synchronisation einfangen.
Mein Gedanke sah so aus, die Daten mit einer so geringen Baudrate zu versenden, dass es ausreicht, nach jeder Zeile maximal ein Byte da ist, dass ich während des "Rücklaufs" problemlos abfragen kann.
Davon abgesehen fällt mir auf, dass das Senderkonzept noch nicht steht... wird langsam Zeit, das zu ändern...
Mission Control Diagramm mal ich noch...