360° Community Antennentracker mit Schleifring - Wer macht mit?

[Xell]

Hallo,
Ist der Absatz denn notwendig?
Wenn es hinbekommst, evtl. den Bügel mittig und einen Schlitz in die Mitte durch das dann das Antennenkabel nach innen geführt werden kann.
So zum Beispiel:


Gruß

 

[Chriss_:)]

Hi,

welchen Absatz meinst du? Also ein Antennenkabel nach Innen zu führen wird meiner Meinung nach nichtnotwendig sein, weil die meisten ihren Empfänger außen ran pappen, wer den Empfänger wo anders haben will, kann sich in der schrägen Deckplatte ein Loch einbringen!

Schöne Grüße aus dem Sauerland!
Chriss

Edit: Update


Hab im zwischenboden noch ein 15mm großes Loch eingebracht, man könnte die Kabel zwar auch nach vorne führen, aber ich dachte mir, so wird es ordentlicher! Es fehlen noch zusätzliche Bolzen für den Zwischenboden...

XT60 als Akku-Anschluss ok? Würde eh einen bestimmten Bereich frei lassen, dann kann jeder seinen eigenen Anschluss einbauen! Achja, wenn die Spannung über den Schleifring gehen soll, wäre es doch sinnvoll, die 12V (3S angenommen) über den Schleifring zu schicken, oder? Weil höhere Spannung aber weniger Strom!

Bin am Überlegen, ob es Sinn macht, den Bügel noch ein wenig nach hinten zu verlängern, dann könnte man bei schweren Gerätschaften noch Ausgleichgewichte anbringen, um den Servo zu schonen...

Edit#2: das untere Gehäuse wird schön kompakt, dadurch kkönnte der Tilt-Bügel 70° nach unten, dazu bitte noch eine Funktion implementieren: wenn der Bügel im 70° Winkel nach unten steht, diesen Sound abspielen: https://www.youtube.com/watch?v=QITTy35CV_A

 

[Rangarid]

XT60 ist ok. 20° nach unten sollten eigentlich auch reichen. Würde mich wundern, wenn jemand sich mit dem Tracker auf einen 1000m Berg stellt und dann aber unten auf 20m rumdümpelt. Der kommt doch nie wieder hoch mit einer Akkuladung...

 

[muerzi]

Hab mir euern Code gerade angesehen.

Bitte schreibt bei den GPS Daten (im Code) dazu welches Format.

ddmm.mmmm
ddmm.ssss
dd.dddddd
dd.ddmm

?

Mit meinem Hott Sensor gabs da arge Probleme

 

[Rangarid]

dd.dddddd wird beim Lokalen GPS ausgegeben

Würde sagen wir behalten das bei, damit lässt sich gut rechnen glaub ich. Oder welches Format wäre dir am liebsten?

Steht übrigens drin:

defines.h

//coordinates in decimal format
//e.g. 52.520817 13.40945      
typedef struct{
  float lat;
  float lon;
} geoCoordinate_t;

Ok ist mehrdeutig auslegbar. Ich mach decimal degree draus.

Ich glaub die Berechnung des Winkels von Tracker und Flugzeug ist auch falsch. Muss da mal nochmal kucken. Je nachdem mit welchen Werten es sich da am einfachsten rechnen lässt ändert sich das vielleicht nochmal.

So hab mal ne alternative Methode zur Berechnung des Winkels reingemacht. Werds dann heut abend testen.

 

[muerzi]

schau dir mal die tinygps oder tinygpsplus library an

http://arduiniana.org/libraries/tinygps/
http://arduiniana.org/libraries/tinygpsplus/

 

[Rangarid]

Interessant, da schau ich mal rein. Das sind die zwei die wichtig sind:

double distanceKm =
  TinyGPSPlus.distanceTo(
    gps.location.lat(),
    gps.location.lng(),
    EIFFEL_TOWER_LAT,
    EIFFEL_TOWER_LNG) / 1000.0;
double courseTo =
  TinyGPSPlus.courseTo(
    gps.location.lat(),
    gps.location.lng(),
    EIFFEL_TOWER_LAT,
    EIFFEL_TOWER_LNG);

 

[Metzelmaennchen]

Interessant, da schau ich mal rein.

Das war auch die lib mit der ich im Moment arbeite. Die lat/lon gab es da ueber get_position als long werte, nur altitude musste man in float über f_altitude abfragen.
Daher auch die long Werte im geo struct

 

[Rangarid]

Ok, wenn alle eh die TinyGps++ haben dann nehm ich das NMEA gedöns raus und bau die rein. Dann haben wir gleich alles aus einer Hand.

TinyGps++ benutzt übrigens Dezimalgrad. Also so wie ich es angedacht hatte. Wir müssten also alle Koordinaten die über Telemetrie reinkommen in Dezimalgrad umrechnen.

Ich hab gerade ein seltsames Problem mit meinem Multiwii, wenn ich das GPS einlese verschwinden irgendwie Datensätze. Wenn ich GGA + RMC übertrage kommt immer nur eins von beiden an und das newline fehlt auch manchmal...Jemand ne Idee? Ist sowohl bei SoftwareSerial als auch bei HardwareSerial.

Muss mal nen andern Arduino probieren, ob da das selbe Problem auftritt...

 

[der-Frickler]

Du pollst die serielle aber oft genug und rufst auch oft genug gps.encode() auf?
Sonst läuft dir der Puffer recht schnell über und du verlierst Zeichen.

 

[Rangarid]

Ich mache in jedem loop

if (gpsSerial.available()){
    gps.encode(gpsSerial.read());
}

Ich hätte gedacht, ein Loop ist schneller rum, als ein Zeichen in den Buffer kommt, deshalb nur das if available(). Ist in einem der Arduino Beispiele zu SoftwareSerial genauso.

Oder meinst du es wäre besser wenn ich

while(gpsSerial.available() > 0){
    gps.encode(gpsSerial.read());
}

mache?
Verlangsamt das die loop oder geht das so schnell, dass es egal ist?

Mir ist dabei auch noch aufgefallen, dass eich eigentlich RMC und GGA reinbekomme, aber das Newline dazwischen fehlt. Manchmal kommt eine 0. RMC und GGA sind also zusammengeklatscht in einer Zeile...

 

[der-Frickler]

Ich würde auf jeden Fall immer alle Zeichen lesen die im Buffer stehen, der rest kann schnell zu langsam sein. Je nachdem was du in der loop alles machst sollte die while auch mehrfach in der main loop stehen.

Newline kann ja so oder so aussehen und interpretiert werden, mal \n mal \r mal beides, evtl hast da n Fehler.

 

[Rangarid]

So also ich hab mal if und mal while probiert, macht keinen Unterschied. Hier mal die Ausgabe:

$GPRMC,000229.000,V,,,,,,$GPGGA,000229.199,,,,,0,0,,,M,,M,,*40
$GPRMC,000229.199,V,,,,,0$GPGGA,000229.400,,,,,0,0,,,M,,M,,*45
$GPRMC,000229.400,V,,,,,$GPGGA,000229.599,,,,,0,0,,,M,,M,,*44
$GPRMC,000229.599,V,,,,,.$GPGGA,000229.800,,,,,0,0,,,M,,M,,*49
$GPRMC,000229.800,V,,,,,$GPGGA,000230.000,,,,,0,0,,,M,,M,,*49
$GPRMC,000230.000,V,,,,,0$GPGGA,000230.199,,,,,0,0,,,M,,M,,*48
$GPRMC,000230.199,V,,,,,$GPGGA,000230.400,,,,,0,0,,,M,,M,,*4D

Auffällig ist, bei RMC fehlt die Checksum. Wenn ich das GPS direkt auslese ist alles ok...

 

[der-Frickler]

Da fehlt aber noch mehr, die GPRMCs sind ja nicht komplett, fehlt ja z.B. die checksum.
Woher kommen die Daten denn? Werden sie direkt am PC richtig angezeigt (Arduino Konsole)

 

[Rangarid]

Kommt direkt aus dem GPS. Ich mach quasi ne 1:1 Kopie vom SoftwareSerial auf den HardwareSerial und schau mir das an der Arduino Konsole an. GPS direkt dran macht wie es soll 2 Zeilen und alle Daten sind da.

GPS direkt:
$GPGGA,000025.000,,,,,0,0,,,M,,M,,*4F
$GPRMC,000025.000,V,,,,,0.00,0.00,060180,,,N*45
$GPGGA,000025.200,,,,,0,0,,,M,,M,,*4D
$GPRMC,000025.200,V,,,,,0.00,0.00,060180,,,N*47

und beim Fehler:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(8, 11); // RX, TX

void setup()  
{
  Serial.begin(38400);
  mySerial.begin(38400);
}

void loop() // run over and over
{
  if (mySerial.available()){
    uint8_t c = mySerial.read();
   Serial.write(c); 
  }
}

Lese gerade, dass mehrere den Fehler haben. Scheint an SoftSerial zu liegen...

 

[der-Frickler]

und deine Hardware Serial is auch mind. so schnell wie die Soft eingestellt?
Und du machst n Serial.write und kein print?

 

[Rangarid]

Siehe oben, hab noch den Code eingefügt. Aber scheint ein weit verbreitetes Problem zu sein. Vielleicht muss ich mal 9600 Baud oder so probieren. Damit gehen ja immernoch 5Hz.

 

[Rangarid]

Ok, das Problem lässt sich lösen, indem man die Buffersize vom SoftwareSerial von 64 auf 128 erhöht...Kann das mal bitte jemand gegenchecken, ob GPS an 38400 Baud ebenfalls Probleme verursacht? Der Standardbuffer hat 64byte.

 

[der-Frickler]

Stell die normale Serielle doch einfach mal schneller. Für am PC isses doch Latte.

Wobei die Softserial wohl bei schnelleren Baudraten nicht so gut geht.
Warum nimmst da nicht die Hardware für den GPS?

 

[Rangarid]

Jo, grad nochmal getestet...64byte klatscht alles zusammen, bei 128byte funktioniert alles wunderbar...