Zauberkiste v3.1 (Navirechner)

Über das Thema, wie ich die Navigation auf dem Schiff lösen möchte gibt es mittlerweile schon recht viel.

Trotzdem muß ich an das Thema noch mal ran.

Schon verblüffend, wie sich das Ganze von „DVB-T Stick am Laptop“ zu einer Art „Zentraleinheit“ entwickelt hat.

Wie dem auch sei: Das Teil hat die letzten 2 Jahre gut funktioniert und die Liste der Probleme war recht kurz:

– Wlan Empfang ist hin und wieder ausgefallen (das interne WLan vom RPI3 ist nicht wirklich gut, behoben durch Wlan Stick + externer 6dB Antenne)

– defekte SD Karte (vermutlich durch nicht korrektes Herunterfahren, behoben durch Shutdown-Routine)

– ausschalten vergessen – Schutzschaltung vom LiPo hat Tiefentladung verindert

Ungelöste Dinge:

  1.  LED Reihe zur schnellen Kontrolle, ob alles funktioniert ohne Funktion
  2.  LCD Display funktioniert meistens nicht (Zeit Position, Geschwindigkeit, Kurs und Luftdruck unabhängig vom Raspberry)
  3.  Schaltung, damit Raspberry sicher herunterfahren kann ist stark verbesserungswürdig
  4.  Lüfter für Zwangskühlung ist sehr laut / hat ein unangenehmes Geräusch (ist ein 25mm Lüfter, der gute 10000Upm drehen kann)
  5.  GPS Datenstrom setzt hin und wieder grundlos aus… *grrrr*

Einiges war einfach, wie z.B.:

  1.  ein simpler Kabelbruch bei den LED und
  2. LCD, wobei ich mich bei letzterem dann doch für ein I2C Display entschieden habe, um ein paar Pins am Arduino zu sparen.
  3. Die neue Abschaltautomatik war schon schwieriger. Vorher lief das einfach über ein Relais, welches über einen Transistor + Kondensator gehalten wurde. Somit hatte der Raspberry vom Moment es Abschaltens etwa 12 Sekunden Zeit – viel zu wenig um alle Dienste zu beenden. Deshalb habe ich für die Zeitsteuerung den guten alten ATMega 328P (Arduino Nano) genommen und eine Zustandsmaschine programmiert. Das hat den Vorteil, daß nun statt der 3 Zustände („Aus“, „Arduino ein“ und „Arduino und Raspbbery ein“) mehr Zustände zur Verfügung stehen, da auch die vorherige Schalterstellung berücksichtigt wird. Zudem kommen jetzt bistabile Relais zum Einsatz, die keinen permanenten Haltestrom benötigen.
  4. Den Lüfter habe ich durch einen Noctua NF-A6x25 getauscht, der wesentlich leiser ist.
  5. Ja und dann noch die Sache mit dem GPS Datenstrom. Das hat Nerven gekostet. Ganz kurz erklärt: Ich brauche den Datenstrom in 4800 Baud, da sonst die Funke damit nicht klar kommt. Das GPS sendet aber mit 9600 Baud und damit kommt man in Probleme (Bufferüberlauf), wenn der Datenstrom vom Arduino zwar mit 9600 Baud empfangen wird, aber nur mit 4800 wieder rausgeht… Aber es gibt eine Lösung! Man initialisiert das GPS mit 9600 Baud, sendet einen Befehl, um es auf 4800 Baud umzuschalten und verbindet neu mit 4800 Baud. Funktioniert 1A, außer daß das Modul anscheinend hin und wieder auf 9600 Baud zurückfällt. Warum auch immer. Auch der Support konnte mir dafür keine Erklärung geben. Die Lösung ist ein Work-Around. Sobald keine verwertbaren PGTOP Daten (Die sagen etwas über den Zustand der GPS Antenne) mehr kommen, wird mit 9600 Baud verbunden und das Modul auf 4800 zurückgesetzt. Ist keine schöne Lösung, aber mir fällt keine andere ein. Sicherlich wäre es besser die Firmware des Moduls zu ändern, aber da ist kein Herankommen…

4 Antworten auf „Zauberkiste v3.1 (Navirechner)“

  1. Danke für diese Berichte!

    Ich versuche mich an einem sehr ähnlichen Projekt. Mein Funk hat schon ein eigenes GPS, ich würde ein zweites mit den Raspberry verbinden. Welches GPS Modul hast du denn verwendet?

    Nutzt du noch den DVB-T Stick für AIS?

    1. Hmm .. was für einen USB Empfänger ich an meine RPI nutze, kann ich Dir gar nicht sagen. Ich habe einen Blumax-Not GPS Empfänger (mit LiPo) über den ich Seriell und via BluTooth the Daten rausbekomme. Der PRI Empfänger ist aber ein normales USB-Gerät – so um die 65€. Die gibt es auch günstiger, aber die Empfindlichkeit und Kanalzahl ist direkt proportional zum Preis. So kann ich mit dem Empfänger sogar in Stahlbetongebäuden ein Signal empfangen. An dem Ultimate-GPS habe ich auch noch eine externe Antelle dran. Die ist dann via SMA angeschlossen.

      „Jetzt“ würde ich überlegen, ob ich das gleich auf Galileo ausrichten würde. Wenn es mich rafft, dann bau ich die Kiste auch noch um. Vom Gefühl her würde ich aber sagen, daß es dafür noch etwas zu früh ist. Die Sateliten sind oben und senden, aber die Empfängertechnologie ist noch in der Steinzeit – auch Firmwaretechnisch.

      Wegen dem DVB-T ja – nutze ich noch. 2 parallel für die beiden AIS Frequenzen. Dazu kommt noch der AIS Empfänger meiner Funke und der meines AIS Senders. Damit habe ich einen 6 Kanal Empfänger an Bord – völliger overkill 😉

  2. Kannst Du das GPS-NMEA nicht auf einem Arduino mit 9600 Baud annehmen, in einen Puffer schreiben und (Teile des) Puffer wieder mit 4800 an die Funke senden?

    1. Das hatte ich initial versucht, aber da kommt man an die Grenzen der Hardware. Wenn es nur darum gehen würde, daß der 328P die Daten liest und wieder ausgibt, dann ja. Da ich aber noch ein Display, Lüftersteuerung und den BME280 dran habe, gibt es vor allem das Problem, daß der RAM alle wird 😉

      Man könnte sich nur den RMC String holen, jedoch hat man dann keine Infos mehr über die Qualität des Signals. Bei OpenCPN habe ich herausgefunden, daß man RMC, GSA, GGA, VTG und GSV benötigt. Das sind im schlimmsten Falle 7 Zeilen mit je 80 Zeichen -> also braucht man etwa 560(Nutz)+21(CRC) Byte im RAM (mindestens) für den Ringpuffer.

      Statt dessen habe ich mich dazu entschieden die Daten der SoftwareSerial direkt in den Ausganspuffer der HardwareSerial zu schreiben. Per Interrupt geht das am schnellsten und braucht keinen zusätzlichen Speicher 😉

      Mit Hilfe des Supports vo Adafruit habe ich aber auch einen Workaround entwickelt. Link: https://forums.adafruit.com/viewtopic.php?t=146042&f=19

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.