Jump to content
Schiffsmodell.net

Mal ganz allgemein: BUS-Systeme


Guest

Recommended Posts

Hallo Freunde,

 

angeregt durch einen Beitrag von Uemmie trau ich mich mal eine Frage zu stellen, die mir schon länger im Gebeiss schwelt: Wer von Euch nutzt BUS-Systeme und welche Erfahrungen macht Ihr damit?

 

Just my two cents: Bei meinem Lieblingsprojekt werde ich letztendlich um die 30 Funktionen schalten mögen. Eins kommt für mich gar nicht in Frage: Grob gesagt von EINEM Empfänger aus für jede Funktion eine Strippe quer durchs Schüffle ziehen, das ist so Seventies. Dazu kommt ja noch eine recht aufwändige Telemetrie-Verdrahtung nebst Sensorik und an die acht Akkustromkreise.

 

Nun hat dieses Projekt eine Besonderheit: 18 unabhängig schaltbare Lichtfunktionen, von denen die meisten im Aufbau installiert sind.

 

Meine Überlegungen gehen in folgende Richtungen:

 

- MC32, favorisiert weil man die Geber recht frei sinnvoll platzieren kann. Hier den entsprechenden Multiswitch Decoder im Aufbau platziert - da geht dann vereinfacht ausgedrückt in den abnehmbaren Aufbau nur eine Strippe zum Decoder, eine für die Stromversorgung und eine fürs GPS-Modul des Autopiloten. Schön auch die Lösung, ebenso das Soundmodul schalten zu können.

 

- X9E, hat den Reiz, in der Telemetrie viel freier gestalten zu können vor allem im Hinblick auf das Zusammenspiel mit dem Autopiloten. Hier wären einfach vier Empfänger im Spiel, sinnvoll platziert würden sie die Verdrahtung auch enorm vereinfachen. Nachteil: nicht so schick viele Geber-Optionen wie die MC32

 

Also erstmal nix mit BUS-Systemen, kann man auch anders lösen. Ahaber: Es gibt noch andere Projekte, die nicht ganz so tricky sind, wo ich mir nicht diese ultimative Redundanz vorstelle (Jeder der beiden Antriebe hat eine komplett eigene Stromversorgung, einen eigenen Empfänger, einen eigenen Regler - ebenso die Ruderanlage. Warum ich diesen Aufwand treibe, sei dahin gestellt).

 

Für diese anderen Schüffle beschäftige ich mich mit eben jenen BUS-Systemen, hab auch angefangen damit rumzuspielen... aber zunächst mehr theoretisch und Schreibtisch-Bastelei alá "aha, das funktioniert tatsächlich!"

 

Wäre spannend, Eure Erfahrungen und Meinungen zu lesen - denn eins ist mal klar: In den Siebziegern führten beim Mercedes 450 SEL 6.9 knüppeldicke Leitungspakete in die Türen, heute macht das bei nem 08/15 Golf der CAN-BUS über ein paar Litze und kann trotzdem viel mehr ;o)

Edited by Guest
Link to comment
Hellmut Kohlsdorf

Ich halte den I2C Bus für gut geeignet. Hat man sorgen, dass die Umgebung im Schiff "elektronisch" zu laut ist, dann kann man Buffer einsetzen die bis zu 15 VDC im I2C-Bus gestatten. Ich verbinde so meine Temperatur- und Feuchtesensoren. Der Controller arbeitet mir 5 VDC, der Buffer erhöht die spannung auf 12 VDc und vor dem sensor reduziert ein weiterer Buffer die Spannung auf die benötigten 3,3 VDC. Da die von mir eingesetzten Sensoren der Firma Sensirion nur eine feste I2C Bus Adresse besitzen, verwende ich noch einen Hub, Der verbindet dann zu den einzelnen Sensoren.

Link to comment

Hellmut, genau damit triffst Du den Nagel sehr elegant auf den Kopf: Elektronisch zu laut! Weil, eine subjektive Wahrnehmung lässt mich rätseln, warum ein Boot so dermassen exakt GPS-Daten auswertet und dementsprechend präzise dem Autopiloten folgt und ein anderes Boot vergleichbarer Grösse, aber durch die Platzverhältnisse / Installationsmöglichkeiten etwas "dichter" verkabelt werden muss und messbar deutliche Defizite in der Präzision und vor allem auch Reichweite der Rückmeldung via Telemetrie-Strecke hat.

 

Beispiel:

 

- Barkasse hat auf dem User-Treffen den Autopilot Telemetrie-Kontakt bei 380 Metern abgebrochen, keinen Kurs mehr geplottet - erstaunliche Werte weil Empfangsmodul direkt im Läpptopp eingestöpselt war, also dem kompletten, nicht zu unterschätzenden Elektronik Lärm des Notebooks ausgeliefert war.

 

- Aniella hat nicht so einen bauchigen Rumpf mit grosszügigen Zugangsmöglichkeiten, der eine grosszügige, getrennte Verkabelung zulässt. Ergebnis und Siegerehrung: Von den Werten der Barkasse kann ich nur träumen.

 

Wie gesagt, nur gefühlt und daher ist vielleicht ein BUS die bessere Lösung?

 

Werd morgen mal googeln um Deinen Beitrag vollumfänglich zu begreifen weil grad jetzt erstmal: Güterbahnhof? ;o)

 

Dankeschön für den gedanklichen Schubbser ;o)

Edited by Guest
Link to comment

Ich möchte bei BUS-Systeme wie I²C noch zu bedenken geben, dass diese getaktet sind. Somit könnte es im ungünstigen Fällen zu einer induktiven Spannungsübertragung in benachbarte Leitungen kommen. Diese Buffer, von denen Hellmut Kohlsdorf schreibt nennen sich auch Logik-Pegelwandler.

Link to comment
Ralph Cornell

Ja, FrySky... Scheint mittlerweile ein must-to-have zu sein, wenn man so viele Funktionen zu schalten hat. Warum nicht die schon öfter erwähnte Taranis? Das, kombiniert mit einem S-Bus könnte die Lösung sein.

Link to comment

Für die Richtung Empfänger -> Aktoren (Sonderfunktionen, die Servos + Fahrregler habe ich konventionell angeschlossen) nutze ich eine Art "Bussystem light": Den Summensignalausgang des Empfängers. Den hatte ich schon zu 40 MHz-Zeiten an Empfängern von ACT, heute bei Graupner Hott gibt es den serienmäßig in (fast) allen Empfängern, andere werden so etwas wohl auch haben (?).
Das (PPM-) Summensignal mit einem Mikrocontroller auszuwerten bzw. zu dekodieren ist ziemlich simpel: Man muss letztlich nur die Breite der einzelnen Impulse in der Impulskette auswerten - und immer schön die Impulse mitzählen. Das digitale Summensignal, das moderne Empfänger alternativ anbieten, ist auch nicht komplizierter: Es handelt sich dabei um ein seriell übertragenes Datenpaket, das sämtliche Kanalinformationen enthält. Das kann man über eine ganz normale UART-Schnittstelle eines Mikrocontrollers entgegennehmen und dann auseinanderpflücken.
Zur Zeit habe ich nur einen einzigen Controller am Summensignalausgang hängen (da kann man noch nicht wirklich von einem "Bus" sprechen, es ist ja nur eine Punkt-zu-Punkt-Verbindung), der als Decoder für sämtliche Sonderfunktionen dient. Da es sich um eine simple Einrichtungs-Kommunikation handelt, kann man aber auch problemlos mehrere Decoder an diese Leitung anschließen, von denen sich jeder "seine" Informationen aus dem Signal herauspickt.
 
Hier der Quelltext für das Summensignal-Decoder-Programm für die Sonderfunktionen in meinem ZANDER (sicherlich kein Musterbeispiel der Programmierkunst, aber es erfüllt seinen Zweck :roll: ):
 

/******************************************/
/* fdec.c                                 */
/*                                        */
/* Funktionsdecoder  (Platine MR 07 11)   */
/* für SRB Zander                         */
/*                                        */
/* µC: ATtiny 2313                        */
/******************************************/

#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/wdt.h>

#define F_CPU 1000000

#include <util/delay.h>

volatile bool blink;

void init(void)
{
  // IO-Ports:
  PORTB = 0xe1;                     // unbenutzte Pins: Pullup ein,
                                    // Blaulicht (PB0, low-aktiv) aus
                                    
  PORTD = 0x4f;                     // unbenutzte Pins und PD6=ICP: Pullup ein 
  DDRB  = 0x1d;                     // Port B: Bits 0, 2, 3, 4 Ausgang
  DDRD  = 0x30;                     // Port D: Bits 4, 5 Ausgang
  
  DIDR  = _BV(AIN1D);               // AIN1 (PB1) Digital Input Disable
  ACSR  = _BV(ACBG);                // Bandgap-Referenz -> Analog-Komparator

  // Timer 1 (Impulslängenmessung für Fernsteuerung)
  TCCR1B = _BV(ICNC1) | _BV(CS10);  // Timer 1 Input Capture Noise Canceler,
                                    // Teilerfaktor 1
  TIMSK  = _BV(ICIE1);              // Input Capture Interrupt    
}

ISR(TIMER1_CAPT_vect)
{
  static uint8_t i;
  static uint16_t t_alt;
  static bool error;
  static uint16_t t[9];

  uint16_t t_neu, t_diff;
  
  t_neu = ICR1;
  t_diff = t_neu - t_alt;
  if (t_diff > 3000)
    {
      i = 0;
      error = 0;
    }
  else if ((t_diff < 800) || (t_diff > 2400))
    {
      error = 1;
    }
  t[i] = t_diff;
  if (i < 8)
    {
      i++;
    }
  else
    {
      if (!error)
        {
          wdt_reset();

          if (t[1] > 1850)
            ;
          else
            ;
          if (t[1] < 1300)
            ;
          else
            ;
          
          if (t[2] > 1850)
            ;
          else
            ;
          if (t[2] < 1300)
            ;
          else
            ;
          
          if (t[3] > 1850)
            ;
          else
            ;
          if (t[3] < 1300)
            ;
          else
            ;
          
          if (t[4] > 1850)
            ;
          else
            ;
          if (t[4] < 1300)
            ;
          else
            ;
          
          if (t[5] > 1850) {
            PORTB |=  _BV(3);           // Decksbeleuchtung
            PORTD |=  _BV(4);           // Decksstrahler
          }
          else if (t[5] < 1300) {
            PORTB |=  _BV(3);           // Decksbeleuchtung
            PORTD &= ~_BV(4);
          }
          else {
            PORTB &= ~_BV(3);
            PORTD &= ~_BV(4);
          }
          
          if (t[6] > 1850)              // Blaulicht
            PORTB &= ~_BV(0);
          else
            PORTB |= _BV(0);
          if (t[6] < 1300)
            ;
          else
            ;
          
          if (t[7] > 1850)
            PORTD |=  _BV(5);           // Signalhorn
          else
            PORTD &= ~_BV(5);
          if (t[7] < 1300) {
            if (!blink) 
              PORTB |=  _BV(4);         // Rundumlicht (Morselicht)
          }
          else {
            if (!blink)
              PORTB &= ~_BV(4);
          }
       }
    }
  t_alt = t_neu;
}

ISR(TIMER1_OVF_vect)                    // Blinken, ca. 1 Hz
{
  static uint8_t z;
  
  if (z == 10) {
    PORTB |= _BV(4);                    // Rundumlicht (Morselicht)
  }
  if (z < 15) {
    z++;
  }
  else {
    z = 0;
    PORTB &= ~_BV(4);                   // Rundumlicht (Morselicht)
  }
}

int main(void)
{
  init();
  wdt_enable(WDTO_500MS);               // Wachhund: Time-out ca. 0,5 s
  sei();
  PORTB |= _BV(2);                      // Positionslichter ein
  
  for (; {                            // Endlosschleife
    blink = (ACSR & _BV(ACO)) == _BV(ACO);          
    if (blink) {                        // AIN1 < Ref => Blinken (Morselicht) 
      TIMSK |= _BV(TOIE1);
    }
    else {
      TIMSK &= ~_BV(TOIE1);
    }
  }    
}

Das Ganze ist also nicht nur graue Theorie, sondern wird auch tatsächlich eingesetzt ;)

 

Zusätzlich zu der Decoderfunktion ist hier noch eine einfache Akkuspannungsüberwachung eingebaut: Wenn die Spannung am Analogkomparatoreingang des Controllers einen bestimmten Wert unterschreitet, blinkt das Morselicht mit ca. 1 Hz.

 

 

Grüße

 

Matthias

 

Link to comment
Ralph Cornell

Das Ganze ist also nicht nur graue Theorie, sondern wird auch tatsächlich eingesetzt ;)

 

Zusätzlich zu der Decoderfunktion ist hier noch eine einfache Akkuspannungsüberwachung eingebaut: Wenn die Spannung am Analogkomparatoreingang des Controllers einen bestimmten Wert unterschreitet, blinkt das Morselicht mit ca. 1 Hz.

 

 

Grüße

 

Matthias

Interessante Lösung. Ich projektiere bei meiner WESER zusätzlich zur Telemetrie eine interne Spannungsüberwachung über das Beier-Soundmodul. Sobald die Spannung da in den Keller geht, leuchten die Fahrstörungslampen auf.

Link to comment

Die FrSky Empfänger unterstützen teilweise den S-Bus von Futaba. Vielleicht ist damit was zu machen?!?

 

Interessant, das verschiebt meine Präferenz bissie in Richtung X9E ;o) Dankeschön für den Hinweis!

Link to comment

@MatthiasR

Schön das du uns an deinen Erfolg teilhaben lässt und danke fürs Zeigen des Quellcodes. Aber mir als Informatiker fällt gleich diese gigantische If-else-Konstruktion ins Auge. Ich denke die lässt sich ein wenig auflockern.
 

static void t5_handler(static uint16_t pulse)
{
  if (pulse > 1850) {
    PORTB |= _BV(3); // Decksbeleuchtung
    PORTD |= _BV(4); // Decksstrahler
  }
  else if (pulse < 1300) {
    PORTB |= _BV(3); // Decksbeleuchtung
    PORTD &= ~_BV(4);
  }
  else {
    PORTB &= ~_BV(3);
    PORTD &= ~_BV(4);
  }
}

static void t6_handler(static uint16_t pulse)
{
  if (pulse > 1850) // Blaulicht
    PORTB &= ~_BV(0);
  else
    PORTB |= _BV(0);
  if (pulse < 1300)
  ;
  else
  ;
}

void (*Pullse_Handlers[9](static uint16_t)) = {..., t5_handler, t6_handler, ...};

...
else {
  if (!error) {
    Pullse_Handlers[i-1](t[i]);  // i-1, weil ein Array immer mit dem Index 0 anfängt
  }
...

ist jetzt nicht getestet, aber so in etwa könnte es eleganter laufen. Das könnte sogar schneller sein, da hir die t<x>_handler-funktionen direkt angesprungen werden und nicht erst die eintausend und eine If anweisung ausgewertert werden muss.

 

 

 

Link to comment

Ich habe nie behauptet, dass das schön/besonders elegant/wasauchimmer ist... ;)

 

So ineffizient dürfte das übrigens gar nicht sein. Der ganze if/else-Krempel wird erst nach dem letzten Impuls aufgerufen - er steht nämlich im else-Zweig von

if (i < 8)
  {
    i++;
  }
else

Da kommen dann alle if/else-Teile auf einmal zum Zuge, genau einmal pro 20 ms-Zyklus. Dass so eine lange Funktion "am Stück" nicht gerade schön ist, da stimme ich Dir auf jeden Fall zu.

 

Die Abschnitte für t[1] bis t[4] stehen übrigens absichtlich (als Platzhalter) da, obwohl sie nicht benutzt werden. Das hat auf die Laufzeit keinen Einfluss, die werden vom Optimierer sowieso entfernt :)

Mal ganz abgesehen davon, dass sich der Controller bei dieser Aufgabe sowieso arg langweilt...

 

Aber wie gesagt, man kann das bestimmt "besser" machen - und eigentlich ist Lesbarkeit/Übersichtlichkeit ja auch ein wichtiges Kriterium!

 

Grüße

Matthias

 

PS.: Das hat man davon, wenn man so ein Quick-and-Dirty-Progrämmchen postet... :?

Ich hoffe, das Wesentliche ist aber trotzdem 'rübergekommen: Dass es relativ simpel ist (das Programm ist ziemlich kurz!), so ein Summensignal auszuwerten!

 

 

Link to comment
PS.: Das hat man davon, wenn man so ein Quick-and-Dirty-Progrämmchen postet... :?

Ich hoffe, das Wesentliche ist aber trotzdem 'rübergekommen: Dass es relativ simpel ist (das Programm ist ziemlich kurz!), so ein Summensignal auszuwerten!

 

Wenn ich was falsches geschrieben habe, tut  es mir leid, ich wollte dich auf keinen Fall angreifen. Quick-and-Dirty sieht es auch nicht wirklich aus. Ich habe auch etwas überlegen müssen, wie mann eine solch große IF-Folge besser machen könnte (was nun besser ist sei mal dahingestellt). In der Softwareentwicklung ist es übrigends gang und gebe erst mal so genannte Prototypen zu schreiben, die dann in der Regel sehr Quick-and-Dirty sein können und da dein Programm offenbar funktioniert ist schon erstmal alles gut.

 

Die Platzhalter habe ich durchaus verstanden und du hast völlig recht, dass diese vom Compiler rausoptimiert werden. Letzten ende ist es geschmackssache.

 

Also nimm es nicht so schwer... ;)

 

Und das soll es jetzt für  das Off-Topic "Programmieren sein"... Für weiteres Interesse in Sachen Programmieren könnten wir ja einen neuen Thread eröffnen...

  • Like 1
Link to comment

Wenn ich was falsches geschrieben habe, tut  es mir leid, ich wollte dich auf keinen Fall angreifen.

 

Keine Sorge, das habe ich nicht so aufgefasst. Und für Anregungen, wie man etwas besser machen könnte, bin ich im Allgemeinen durchaus zu haben... :)

 

So, jetzt soll hier aber wirklich Schluss sein mit dem Programmierkram - viele Grüße

 

Matthias

Link to comment

Hallo Jester,

 

für meine Fernsteueraufgaben außerhalb der normalen Funktionen benutze ich den LIN-Bus.

Durch diesen sehr robusten Bus aus der Autoindustrie mache ich mir recht wenig Sorgen um die Störfestigkeit und Drahtlänge im Boot.

Da dieser Bus einfach an eine serielle Schnittstelle zu koppeln ist, kann man sich sein eigenes Protokoll nach Aufwand

relativ einfach "stricken".

Meine Module besitzen alle diesen Bus, dadurch ist es mir möglich unendlich viele Module vom gleichen Typ an den Master zu koppeln und die Funktionen können sehr einfach den erforderlichen Bedingungen auch in der Protokollbreite angepasst werden.

Mein kürzester Befehl lautet #ok$.

Ebenso bin ich gerade dabei meine neuen Module mit USB auszurüsten.

Durch diese Erweiterung ist es mir möglich die Module über LP oder PC und den gleichen Befehlen einfach und schnell im Labor zu Testen,  vorausgesetzt die MC's haben mehrere  USART was aber heute kein Problem darstellt.

 

Sollte mich mal der Teufel reiten, könnte ich ohne viel Aufwand auch einen Mini-PC ins Boot verfrachten und brauche die Module nicht nochmals neu Entwickeln, laufen auch dann sofort am PC.

 

Viel Spaß beim Entwickeln

 

Gerd

 

Link to comment

Hallo Gerd,

 

nu wird das interessant, könnte mich jetzt unendlich festlabern aus meiner beruflichen Praxis warum es keinen Sinn ergibt, einen CAN-Bus Rekorder in einer Sattelzugmaschine zu installieren wenn die Fehlermeldung (Hier "Störung Bremsystem", begleitet von rotem Dreieck im Zentraldisplay und diversen Kollateral-Wirkungen wie zum Beispiel Ausfall der kompletten Beleuchtung oder Ausfall aller Fahr-Assistenz-Systeme) nich mal, solange die "Zündung" eingeschaltet ist und wie sonst auch, unter "Fehlermelungen" quasie händisch im LKW darstellbar bzw. reproduzierbar ist. Auslesen der Fehlerspeicher ergab nichts ausser den most usual suspects, die hervorgerufen werden z.B. durch zu kalten Diesel getankt (Kraftstoffsystem prüfen usw.)

 

Will sagen: Hier war die Ursache ein simpler Wackel einer Masseverbindung und die dadurch entstehenden Spannungsspitzen. Etwas weiter ausgeholt: Die Zugmaschine hatte zwei Wochen nach Auslieferung einen veritablen Kabelbrand und in einer aufwändigen Reparatur ist ein neuer Hauptkabelstrang eingezogen worden. Die Erfahrung zeigt: Sowas ist von vorn herein zum Scheitern verurteilt denn bei der Komplexität einer modernen Sattelzugmaschine mit all diesen aufwändigen Anlagen zur Abgas-Regelung  kann man Leitungen nur einmal sinnvoll verlegen: Bei der Montage im Werk.

 

Nun bin ich nicht ganz so hysterisch wenn ich meine Schüffle verdrahte, aber anscheinend - soll ich besser sagen, offensichtlich - gibt es auch hier einen zunehmende Problematik die sich hochschaukelt. Mal ganz leger: Wenn ich einer guten Freundin, die Ihre Mikrowelle aus dem Haushalt verbannt hat, erzählen würde was für Frequenzen wirken wenn ich die elektronischen Systeme eines meiner Schüffle hochfahre (Neben der üblichen 2,4 GHz Anlage andere Geschichten wie Telemetrie für den Autopiloten, FPV-Übertragung), dabei Heinrich Hertz sich wohl nie hätte vorstellen hätte können, dass die nach ihm benannte Einheit sich mal im 5,8 GHz Bereich abspielt...

 

Lange Rede gar keinen Sinn: Die Möglichkeiten sind da. Es macht Spass, da rumzufummeln aber wer hat auf seiner Werft schon ein komplett ausgestattetes Labor zur Erfassung von elektromagnetischen Strahlen und vor allem, wer kann die Wechselwirkungen ergründen und auswerten?

 

Und nu kommst Du, auch wenn sich die Programmier-Freaks hier aus dem Faden verabschiedet haben als es grade spannend wurde: Wie kann man den von Dir genutzen LIN-Bus verknüpfen, hard- und softwaremässig mit bestehenden Systemen? Wäre es dreist nach einem Beispiel zu fragen, was Du damit in einem RC-Schüff verwirklicht hast?

 

Mag nochmal meinen persönlichen Schwerpunkt darlegen: Ich möchte einen schön tragbaren Sender, der intuitiv zu bedienen ist "per Haptik" (Geber sinnvoll angeordnet) Schwerpunkt Nachtfahren, Schwerpunkt auch nebenbei mal sabbeln können. Ich akzeptiere ein Tablet das schnell hochfährt (aufklappen der Hülle) um mal eben fix Parameter/Waypoints im Schüff auf dem Wasser ändern zu können - keinesfalls aber um Funktionen zu schalten. Was ich möchte, und das ist mir im Nachgang zum Usertreffen schon fast peinlich: Nie wieder mit ner Kabeltrommel rumlaufen um ein Laptop über mehrere Stunden am Laufen zu halten weil nur dies eine Standleitung zum Boot hat ;o)

 

Wenn ich mich so selber beim scrollen dieses Beitrags schreiben höre, müsst Ihr mich wieder mal für bekloppt halten. Es sind halt Erfahrungen, und es macht Spass die Grenzen auszuloten bzw. Erreichtes zu optimieren. Wobei, ohne shyce: Hab nicht den Eindruck, dass meine Bastelei im Entferntesten an den Grenzen kratzt wenn ich Eure Lösungs-Ansätze lese... Bestümmt hab ich bei aller Stöberei überlesen, dass viele Boote mittlerweile per FPV gesteuert werden, dynamisch in Regelkreise greifende Telemetrie Standard ist und natürlich sind Drohne und Boot korelliert?

Link to comment
  • 2 weeks later...

Hallo Jester,

 

puh, schwere Kost.

 

Mal ganz simpel geantwortet, mein System beruht alleine auf meine eigenen Entwicklungen und ist mit nichts kompatibel und das bleibt auch so.

Ob man die Module mit handelsüblichen Modulen verbinden kann, weiss ich nicht.

Meistens hapert es ja daran, dass Entwickler ungern das Datenformat ihrer Schnittstellen preisgeben und ich keine Lust habe andere Systeme zu knacken.

LIN-Bus habe ich einfach aus reiner Lust und Laune gewählt, weil einfach und simpel anzuwenden.

Meine CVG-Steckverbinder sind so stabil in ihrer Kontaktierung, Kabelbrand ausgeschlossen!

 

Was habe ich bereits realisiert?

Mein System kann autonom nach Kompass fahren, auch mit GPS, und zeigt das auch an Land in einem Display an.

Komme mit GPS aber nie und nimmer auf die sagenhaften Genauigkeiten der anderen Entwickler.

Manchmal habe ich bis zu 30m Abweichung vom momentanen Standort.

Alleine das Überfliegen von Verkehrsflugzeugen stört das System.

Trotzdem könnte man mit dem System weite Strecken nach GPS abfahren und kommt mit den technisch bedingten Abweichungen ans Ziel ...soweit habe ich es realisiert.

 

Zu den Programmierern hier im Forum.

Sie haben recht, sich hier nicht weiter mit Programmteilen zu äußern, denn es gibt immer wieder Leute, die es wesentlich besser machen können ...meinen sie.

Wie ich mein Ziel als Hobbyprogrammierer erreiche, ist doch völlig egal, es muss funktionieren.

Ich mag meine Programme auch noch nach Jahren wie ein Buch lesen zu können und nicht darüber Grübeln, was meine bis zur Unendlichkeit verschachtelte Programmzeile eigentlich machen soll.

Klare einfache Anweisungen lassen sich auch besser Debuggen ...aber lassen wir das, bringt eh nichts.

Ich mache es so und der Andere ganz anders und beide kommen an ihr Ziel.

 

Mein Ziel ist es etwas zu Entwickeln und dann auf Funktion zu Testen.

 

Funktioniert es dann, lege ich es eh in die Ecke da der Zweck erfüllt ist.

 

Gruss

 

Gerd

Link to comment

Moin Jester,

bei den Antworten deiner Frage bin ich nach dem zweiten Satz schon ausgestiegen.Das ist mir doch alles zu Theoretisch.

Aber, meine sehr günstige, Multiplex Smart SX 9 nutzt das BUS System.

Seit einem Jahr nutze ich das Paket und bin,alles zuverlässig und störungdfrei,sehr zufrieden.

Gruß Mathias

Link to comment

Erstmal Dankeschön Gerd und Matthias, vielleicht hab ich mich auch einfach ein bissie euphorisieren lassen bei den angesprochenen Lösungsansätzen ;o)

 

Was mir vorschwebt, ist ein echtes Bus-System um nicht zur Ansteuerung von jeder beliebigen Funktion A, B, C, D usw. eine PWM-Leitung von Empfänger 1, 2, 3 zum Steuermodul X, Y, Z usw.quer durchs Boot ziehen zu müssen, idealerweise unter Einbindung ALLER an Bord befindlichen Systeme wie zum Beispiel Autopilot, Schaltmodulen, Fahrtreglern usw. und ein Träumchen: Auch der Telemetrie.

 

Vermutlich kommt der S-Bus meinem Wunsch am nächsten ohne Eigenentwicklungen zu betreiben, weil Pixhawk kann den verstehen...

 

Übrigens Matthias, ich hab grad ne Multiplex Cockpit bestellt - bin gespannt ob die Bedienungsfreundlichkeit an die des 150,- Euro HK-Senders ranreicht, den ich so gern zum Rumexperimentieren nutze weil smartphone-ähnliche Menues bei dem Billigteil :mrgreen:

Edited by Guest
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.