Halte ich für eine etwas gewagte Konstruktion, ehrlich gesagt. Sich anzeigen zu lassen, wo man ist- ok. Aber gleich den ganzen Flieger danach fliegen zu lassen ? Und wenn Du den AP brauchst weil du hohe Arbeitsbelastung hast, und dann steigt dir das ipad aus ? Ist das GPS im ipad wirklich präzise genug ?

Eine gewagte Konstruktion ist es auf jeden Fall. Es gibt schon gute Gründe warum so ein mega-Theater bei der Softwareentwicklung für Avionik gemacht wird (und nicht nur bei der Softwareentwicklung).

Die Genauigkeit des GPS ist nicht das Thema; die Zuverlässigkeit der Software und der ganzen Zwischenkomponenten ist das Problem.

Mir ging's nur um die Machbarkeit als Bastel-Projekt.

"Es gibt schon gute Gründe warum so ein mega-Theater bei der Softwareentwicklung für Avionik gemacht wird (und nicht nur bei der Softwareentwicklung)."

Also wenn ich mir die analogen Autopiloten (inkl. deren Elektromechanik) anschaue, mit der die meisten hier rumfliegen, dann hat das im schlechtesten Fall Bastelniveau, im besten Fall ist es einigermassen zuverlaessig. Lies mal durch's Forum. Die Century Autopiloten sind aus der Techniksteinzeit der spaeten 70er. Kurz: um's iPad als Fehlerquelle wuerde ich mir die wenigsten Sorgen machen. der Centuy IIb in der Archer ist mir schon dutzendfach ausgestiegen, mein iPad noch nie.

Gruesse, Thomas

>"Es gibt schon gute Gründe warum so ein mega-Theater bei der Softwareentwicklung für Avionik gemacht wird >(und nicht nur bei der Softwareentwicklung)."

Also wenn ich mir die analogen Autopiloten (inkl. deren Elektromechanik) anschaue, mit der die meisten hier rumfliegen, dann hat das im schlechtesten Fall Bastelniveau, im besten Fall ist es einigermassen zuverlaessig. Lies mal durch's Forum. Die Century Autopiloten sind aus der Techniksteinzeit der spaeten 70er. Kurz: um's iPad als Fehlerquelle wuerde ich mir die wenigsten Sorgen machen. der Centuy IIb in der Archer ist mir schon dutzendfach ausgestiegen, mein iPad noch nie.

Mir ist schon klar, daß die alten Analog-Autopiloten sehr einfach aufgebaut sind. Die sind ja auch in einer ganz anderen Zeit entworfen und zertifiziert worden. Vieles, was vor 40 Jahren zulassungsfähig war, ist es heute nicht mehr.

Dein iPad ist Dir noch nie ausgestiegen, weil die Software mehrere Jahre (teilweise Jahrzehnte) auf dem Buckel und schon längst ihre Kinderkrankheiten durchlaufen hat. Zudem gibt es auch keine Echtzeitanforderungen beim iPad und auch keine Direktprogrammierung der Hardware: es wird alles schön komfortabel vom Betriebssystem gemanagt.

Entwickel mal ein paar Hundert Zeilen echtzeitfähigen Embedded-Code. Du wirst Dich wundern, wie viele Fehler da entstehen.

Naja, die Timinganforderungen an einen virtuellen Headingbug, den man sonst von Hand drehen würde, sind schon sehr überschaubar.

"Entwickel mal ein paar Hundert Zeilen echtzeitfähigen Embedded-Code. Du wirst Dich wundern, wie viele Fehler da entstehen."

Hab ich schon. In C und Assembler, fuer Herzschrittmacher - noch Fragen ;-) ?

"Zudem gibt es auch keine Echtzeitanforderungen beim iPad und auch keine Direktprogrammierung der Hardware"

Wer in einem Embedded-System, das Echtzeitanforderungen erfuellen soll, direkt auf die HW programmiert ohne wenigstens ein primitiven Task-Scheduler oder ein kleines Betriebssystem dazischenzulegen, ist selber Schuld. Ja ich kenn die Helden, die glauben ihren Code zu ueberblicken und darauf verzichten zu koennen. Oftmals gescheiterte Helden. Aber das ist eine voellig andere Geschichte und gehoert eher in HW/SW-Forum.

Gruss, Thomas

"Entwickel mal ein paar Hundert Zeilen echtzeitfähigen Embedded-Code. Du wirst Dich wundern, wie viele Fehler da entstehen."

Hab ich schon. In C und Assembler, fuer Herzschrittmacher - noch Fragen ;-) ?

Ja, Thomas, ich hätte da noch eine Frage. Hat Dein Herzschrittmacher auf Anhieb perfekt funktioniert?

"Zudem gibt es auch keine Echtzeitanforderungen beim iPad und auch keine Direktprogrammierung der Hardware"

Wer in einem Embedded-System, das Echtzeitanforderungen erfuellen soll, direkt auf die HW programmiert ohne wenigstens ein primitiven Task-Scheduler oder ein kleines Betriebssystem dazischenzulegen, ist selber Schuld. Ja ich kenn die Helden, die glauben ihren Code zu ueberblicken und darauf verzichten zu koennen. Oftmals gescheiterte Helden. Aber das ist eine voellig andere Geschichte und gehoert eher in HW/SW-Forum.

Ja klar, Thomas, weil jedes Problem sich mit Pauschallösungen erledigen lässt, gell?

Jetzt hör mal mit dem kindischen Pinkelwettbewerb auf.

Mein Punkt war, daß es einen Grund gibt, warum man für sicherheitskritische (Avionik, Medizintechnik) Software teils drastisch erhöhten Aufwand betreiben muß.

Selbst scheinbar triviale Software hat potentiell extrem komplizierte Nebenwirkungen und Verhaltensweisen. Mit "ich hau mal kurz ein paar Zeilen Code zusammen" ist es nicht getan.

Können wir es dabei belassen?

Hallo Gerald,

warum denn so emotional? Du hattest mich indirekt gefragt, ob ich in meinem Leben schonmal ein paar Zeilen Code geschrieben habe. Mit einem belehrenden Unterton "Entwickel mal ein ..." ... "Du wirst Dich wundern". Ich hab geantwortet, unverwundert. Und scheinbar anders, als Du dachtest. Und das das Thema sowieso in andere Foren gehoert hatte ich gleich hintenangefuegt.

Also ja, lassen wir das und nutzen die "severe CAVOK-Bedingungen", die da vor der Tuer herrschen :-)

Hi Thomas,

Du hast mir eine Frage gestellt, die möchte ich beantworten.

warum denn so emotional? Du hattest mich indirekt gefragt, ob ich in meinem Leben schonmal ein paar Zeilen Code geschrieben habe. Mit einem belehrenden Unterton "Entwickel mal ein ..." ... "Du wirst Dich wundern".

Warum so emotional? Den belehrenden Unterton kann ich Dir auch vorwerfen:

"Lies mal durch's Forum...."

sowie einige Zeilen, die man als böswillige Unterstellungen lesen kann.

Aber ich nehme an, daß das von Dir nicht so gemeint war.

Passt scho' :)