Next Ballon - Brainstorming

Die software gibt es schon :
http://www.trackuino.org/

Und was ich daran cool finde : Unter der GPL.. also nix nur für Hams, non commercial.. sondern FREI.

ein gps auszulesen und die daten in ein APRS Frame zu packen ist relativ einfach.. das war beim "Openballon" eine sache von einpaar Zeilen Perl code.. aber toll war, das das ganze AX25 Protokoll + Soundmodem schon im Linux verfügbar war.
Und das ist es beim trackuino auch.
Da nur noch ein paar zeilen code für die TX und QRG umschaltung.. und fertig ist die maus.
Eventuell noch ein paar sensoren dran.. aus die maus.

Das Konzept hat gegenüber den reinrassigen iMX233 konzept folgenden vorteil : Man kann später die Sender und AVR kombi auch für nen kleinen APRS-Tracker ausserhalb von Ballonmissionen nutzen.
Oder aber, mit einer anderen Firmware als 2m-Fuchssender..
Also ein stückchen Hardware für 3 Anwendungen :
APRS-Sender, Ballon-Sender, Fuchsjagtsender.
Wenn irgendeiner dann mal hingeht und das als Bausatz rausbringt, wird das hoffentlich billiger, weil die Hardware in grösseren Stückzahlen produziert werden kann.
Aber durch die GPL wäre gewährleistet, das man es auf eigene Bedürfnisse anpassen kann.
Und machbar ist es, weil man nur ein paar Dinge dazuentwickeln muss.

lg JAn

Hi!

ich werfe hiermit noch einen neuen Prozessor in die Runde: STM32 ARM Cortex M3 oder M4.
ist etwas aufwändiger zu Programmieren als ein Atmel, aber die Lösung, wenn die Rechenleistung zu gering werden sollte.

GPS hab ich iwo noch ne Auslesung in C rumliegen, ist ja nur triggern auf den Teil der Information den man haben will und dann logging.

für die Koordinierung biete sich eine Wikiseite oder ein google Spreadsheet an, es kann von mehreren bearbeitet werden und bleibt auch sicher online.

Mega644 halte ich auch für eine sehr gute Idee, er ist groß, JTAG-Debuggbar und leicht erhältlich, UND mit allen gängigen AVR-Suiten oder einfach Editor+Makefileprogrammierbar, kein teurer Progger wie HV oder PDI nötig.
bei meinem ARM-Vorschlag wäre das deutlich anders, JTAG tut das deutlich not, wenn man nicht den internen (langsamen) UART-Loader verwenden will.
Dafür haben die kleinen ARMs Peripherie wie blöde, mehrere UARTs, CANs, I2C, SPIs.. und und und, manchmal sogar Flash-Interface oder externen RAM (wobei die ARMs mit RAM und flash eh sehr großzügig ausgestattet sind)

Koordiniert will auch die Interruptbehandlung werden, nicht dass ein Interrupt von mehreren Leuten verwendet werden will und sich dann was staut oder verloren geht, es soll ja auch ausfallsicher sein, das Teil.

wer hat schon mal so ein Großprojekt gestartet und am besten durchgezogen? Ich noch nicht^^ (nicht bis zum Ende gekommen^^)

Also ich habe die Erfahrung gemacht, das etwas grosses am besten entsteht, wenn man viele kleine funktionierende Teile in bester Unix Manier zusammenarbeiten lässt.
Deswegen denke ich entweder : ein ARM-Proz auf denen entweder mehrere unabhängige Softwaremodule laufen, oder mehere Prozessoren, wo jeweils eine software läuft. Die aber jeweils richtig.

Mit der Strategie habe ich schon ein grosses ..( sollte man sagen "Expertensystem" ?) Datenbanksystem hochgezogen.
Ausserdem ist das Spassig : Man arbeitet konzentriert am APRS sender... wenn der läuft.. dann am ... xxx-Modul.. wenn der läuft.. usw...

lg JAn

Hm ich glaube nicht das wir an Rechenleistung scheitern werden, eher scheitern wir weil uns das ganze über den Kopf wächst.

Das gleiche gilt auch für ein Linuxbasiertes System, wir brauchen keine zwei Linuxboard am Ballon, meiner Meinung nach.

Es gab auch eine Zeit vor dem Multitasking(Auch wenn ich das außer in AVRs nicht mehr kenne)



Ist nur die Frage: brauchen wir das? Für speicherintensive Tätigkeiten (SSTV...) ist Jans Board dabei, für Datensammeln braucht man eigentlich nicht mehr als einen UART, I2C und SPI, das hat ein kleiner AVR alles on Board.



Dann würde ich zu zwei Controller tendieren:

1. Datensammler (GPS, Höhe, Temperatur, Spannungen, Beschleunigung)

2. Kommunikationsmodul (Sprachgenerierung, Packet Radio)

Das 2. Modul bekommt die Daten vom Datensammler ( über I2C?) und pustet sie in die Atmosphäre.

Das ganze dürfte auf eine Platine passen.

Probiert das Zusammenspiel der einzelnen Teile aber bitte vorher aus.
Nicht das ihr diese Pleite wiederholt.

Lars

Hallo,
ich habe die Befürchtung, dass das ganze in ein Mikrocontroller-(insider)-Projekt mutiert, was am Ende ziemlich kompliziert wird aber trotzdem nichts spektakuläres kann.

Deshalb würde ich vorschlagen, dass wir uns erstmal ein interessantes Missionsziel ausdenken, welches Anforderungen in vielen verschiedenen Disziplinen stellt (Physik, Chemie, Wetterkunde...) und nicht mit einem einzigen Flug abgehakt werden kann.

Ein paar Sachen/Beispiele, die mir spontan dazu einfallen würden:

Kontrollierte Flugbahn / Erreichen eines Streckenrekords:
Der Ballon wird so gebaut, dass die Höhe gesteuert werden kann (z.B Silica-Gel, welches durch die Luftfeuchtigkeit kontinuierlich schwerer wird + Flasche mit Spiritus, wo kontrolliert (tröpchenweise) etwas abgelassen werden kann.
Bei einer guten Steuerung würden tatsächlich wenige Tropfen reichen, um die Höhe zu verändern.
Das erforderliche Flugzeit-Höhen-Profil müsste dann aus der Wettervorhersage am Vortag berechnet werden, evtl. ließe sich das Ding bei Kursabweichung per Funk korrigieren.

Wer weiß, vllt. wird es irgendwann möglich ein, den Ballon im Jetstream auf Weltreise zu schicken , ein starker Sender (~2 Watt) sollte doch 1000 km und weiter reichen ?

Durch diese Steuerung ist es evtl. auch möglich einen (Rettungsfolien-)Ballon lange (Tage ???) durch das Steuern in versch. Windschichten an einer Position zu halten.

Um eines dieser Ziele zu erreichen wären etliche Flüge mit ungewissem Ausgang nötig, es wird also einige Jahre dauern, bis das Ziel erreicht wird und durch unerwartete Probleme im Flug, die sich am Boden nicht simulierenn lassen, wird es nie langweilig.

1.Flug: Messung nowendiger Parameter für die Steuerung (z.B. Erwärmung des Balloninneren durch Sonneneinstrahlung)
2.Flug: Test einer Höhenregelung per Fernsteuerung (z.B. mit Silica-Gel (s.o.)).
3.Flug: Test einer anderen Höhenreglung (z.B. Kühlung des Ballongases... wie auch immer)
4.Flug: ...

Lasst euch was einfallen...

Gruß,
Gerald

Es besteht vielleicht auch die Möglichkeit, durch gezieltes Verdampfen des Wassers im mitgeführten Autoakku eine Feintrimmung durchzuführen...

Auf Grund des Verdachts, daß der gleichzeitige Ausfall der beiden autarken Nutzlasten tatsächlich durch ESD verursacht worden sein könnte, bestehe ich darauf, daß die (scheinbar wenig) bekannten Vorkehrungen getroffen werden müssen. Einfügen von Vorwiderständen in die Stromversorgungsleitungen aller CMOS-Chips, der Widerstand muß den Strom auf einen Wert unterhalb des Latch-Up-Stroms begrenzen (und darf im Notfall auch durchbrennen), verhindert fatale Auswirkungen auf das restliche System.

Am Modulationseingang der Baken sollte jeweils eine Signalüberwachung stattfinden, die im Fehlerfall stromsparende Peilsignale einspeist. Ein Tiny10 (wer überwacht den?) + 2 Widerstände und 1 Kondensator lassen sich auf jeden Fall unterbringen, eine reine Hardwarelösung wäre mir allerdings viel lieber.

Naja... ich wäre nicht unbedingt dafür, den Ballon unnötig kompliziert zu machen - zumindest nicht, bevor wichtige Systeme einwandfrei funktionieren.

Auch die Steuerung sollte nicht unnötig kompliziert gestaltet werden. Wenns ein AVR auch tut, warum nicht? Ein Linuxboard, z.b. ein raspberrypi wäre denkbar, um gute (HD) Videoaufnahmen zu machen und zu speichern. Oder auch, wenn man mit dem Ballon kommunizieren möchte, wobei man sich in dem Fall überlegen müsste, was man mit dem Ballon bequatschen will.

Meine Idee um Baumlandungen während des Startes zu verhindern wäre, dass die lange Leine am Ballon erst in ner Höhe von z.b. 100m abgewickelt wird und beim Start die Nutzlast direkt unterm Ballon baumelt. Wird meines Erachtens auch bei professionellen Ballons so gemacht.

Gruß,
Ludwig

Coole Idee !
Theoretisch könnte man sogar den Sender überwachen, in dem man einen einfachen demodulator davor setzt.. das ganze mit eigener Knopfzelle..
Baschtel : Das ist jetzt DEIN Projekt ! Herzlichen Glückwunsch ! *grins*

lg JAn
(Der jetzt 4 itrax02 GPS-Empfänger sein eigen nennt.. )

Das Beispiel mit der Höhensteuerung wäre natürlich sehr aufwendig, aber es wäre doch schön, wenn das Ding etwas könnte, was nicht jeder Wetterballon von der Stange auch schon macht.

Es wäre sicher auch interessant einen Ballon in den Jetstream aufsteigen zu lassen (Wettervorhersage) und zu sehen, wie weit er kommt. Alles was man dazu bräuchte wäre ein stärkerer Sender, der richtige Startzeitpunkt und etwas Glück.

Gruß,
Gerald

*hust*
*totlach*

"Woher hast du die denn?" "Ach die sind vom Himmel gefallen..."

Was ist den bei APRS überhaupt die nötige Modulationsart ?

Bei AM oder FM würd ich nen 558 dran stricken der nach einer gewissen Zeit ohne Signal vom Controller selber eins erzeugt und einspeist. Das geht bestimmt auch zu Fuß mit ner Hand voll Transistoren. Wär die Frage was kleiner ist.

Dann gibts zwar nur *Piep, Piep* ist aber ortbar.

Zumindest für den CB-Sender sollte das so gehen.

Lars

Das ist AFSK mit 1200 Baud

Nö... nur die richtige Frequenz !
z.B. der Ballon der von Californien bis zum Mittelmeer geflogen ist (link grad nicht zur Hand) hat seine position via 20m mitgeteilt.. und der hatte auch nur ein paar milliwatt..
Das 20m oder 30m weltweit funktioniert, hat immer irgendjemand das empfangen. Auch als er gerade übern Teich wanderte..


Nee... leider nicht.. so gut sind wir noch nicht.. ;-)
Nein... aber da her !
Aber bevor man bestellt, sollte man sich das Datenblatt anschauen : Da gibts noch ne menge zu tun :
http://www.ebay.de/itm/Fastrax-iTrax02-08-GPS-Module-with-connector-/130767774816?pt=LH_DefaultDomain_3&hash=item1e725de460

lg JAn

Aber wie wird das Audiosignal auf die HF moduliert ?

Edit:
Habs rausgefunden. Das geht per FM. Also könnte man das Audiosignal überwachen. Wenn für länger als 5 Minuten oder mehr Stille herrscht, gibts Notbetrieb.

Lars