GPS Code Änderungen

Roberto

Erfahrener Benutzer
#1
Hi !

Ausgehend von diesem Post (http://fpv-community.de/showthread....f%FCr-Multiwii&p=247898&viewfull=1#post247898) geht es jetzt weiter. Ziel ist es die MTK 3329 GPS Unterstützung zu verbessern. Dabei soll ein binäres Protokoll zu Einsatz kommen (wie z.B bei Ublox) das hier dokumentiert ist: stuff.storediydrones.com/reference/CustomizeFunctionSpecificationv16.doc. Aktuell experimentiere ich mit der FW AXN1.51_2722_3329_384.1151100.5.bin von hier:http://code.google.com/p/i2c-gps-nav/downloads/detail?name=MTK-firmware-tools-for-2.1.zip&can=2&q= .
Die Auslesung des MTK Binärprotokolls in der aktuellen eos bandi Version (auch APM) ERSCHEINT mir aus mehreren Gründen im Zusammenhang mit der FW (s.o) problematisch/fehlerhaft. Da der tatsächliche, serielle Datenstrom einige unschöne Überraschungen bereit hält und von der Dokumentation abweicht.
Hier ist ein Codevorschlag, wie man die seriellen Binärdaten auslesen könnte. Ich habe mich dabei an dem tatsächlich beobachteten Datenstrom der FW (s.o) orientiert.
Code:
bool GPS_MTK_newFrame(uint8_t data)
{
   static uint8_t pstep;                              // Parse Step
   static uint8_t lastbyte;                           // Last Byte for Sync detection
   static uint8_t LSLshifter;                         // Bitshiftvalue

   static int32_t lat;                                // MTK Dataset
   static int32_t lon;                                // MTK Dataset
   static int32_t alt;                                // MTK Dataset
   static int32_t grspeed;                            // MTK Dataset
   static int32_t grcourse;                           // MTK Dataset
   static uint8_t satn;                               // MTK Dataset
   int32_t tmp32;
   bool parsed;
   
   parsed = false;

   if(pstep == 0 || pstep>5){                         // Only search for Sync when idle or lat and lon already decoded.
    if (data == 0xdd && lastbyte == 0xd0) pstep = 100;// Detect Sync "0xD0,0xDD"
   }
   lastbyte = data;

   switch(pstep) {
    case 0:                                           // Special Case: Do Nothing
    break;
    case 100:                                         // Special Case: Jump into decoding on next run
    pstep = 1;
    break;

    case 1:                                           // Payload Byte is always $20! (This is the first Byte after sync preamble)
    if (data == 0x20) pstep++;                        // Since it is always $20 we take it as extended, undocumented syncword "preamble3"
     else pstep =0;
    break;

    case 2:                                           // Read Dataset Latitude
    lat = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 3:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    lat = lat | tmp32;
    if (LSLshifter == 24){lat = lat * 10; pstep++;}
    break;    

    case 4:                                           // Read Dataset Longitude
    lon = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 5:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    lon = lon | tmp32;
    if (LSLshifter == 24){lon = lon * 10; pstep++;}
    break;

    case 6:                                           // Read Dataset MSL Altitude
    alt = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 7:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    alt = alt | tmp32;
    if (LSLshifter == 24){alt = alt/100; pstep++;}
    break;

    case 8:                                           // Read Dataset Ground Speed
    grspeed = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 9:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    grspeed = grspeed | tmp32;
    if (LSLshifter == 24) pstep++;
    break;

    case 10:                                          // Read Dataset Heading
    grcourse = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 11:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    grcourse = grcourse | tmp32;
    if (LSLshifter == 24) pstep++;
    break;

    case 12:                                          // Read number of satellites in view
    satn = data;
    pstep++;
    break;
    
    case 13:                                          // Read Fix Type and finish readout, mwii does not need the rest
    if (data==1){                                     // No Fix
    i2c_dataset.status.gps2dfix = 0;
    i2c_dataset.status.gps3dfix = 0;}
    if (data==2){                                     // GPS 2D Fix
    i2c_dataset.status.gps2dfix = 1;
    i2c_dataset.status.gps3dfix = 0;}
    if (data==3){                                     // GPS 3D Fix
    i2c_dataset.status.gps2dfix = 1;
    i2c_dataset.status.gps3dfix = 1;}
    GPS_read[LAT] = lat;
    GPS_read[LON] = lon;
    i2c_dataset.altitude = alt;
    i2c_dataset.ground_speed = grspeed;
    i2c_dataset.ground_course = grcourse;
    i2c_dataset.status.numsats = satn;
    parsed = true;                                    // RDY
    pstep = 0;                                        // Do nothing with the next bytes
    break;
   }
 return parsed;
}
Ausserdem könnte man dem GPS noch einen "Spikefilter" zur Seite stellen, der möglichst Ausreisserwerte erkennt und eliminiert. Das könnte dann z.B so bewerkstelligt werden http://fpv-community.de/showthread....f%FCr-Multiwii&p=244379&viewfull=1#post244379

Programmiert könnte es so aussehen (Beispiel für GPS Lat/Lon Daten):
Code:
     //   AT THIS POINT: We have a valid GGA frame and we have lat and lon in GPS_read_lat and GPS_read_lon
    int32_t extmp;
    uint8_t rdy,sortidx,maxsortidx;
    extmp = GPS_read[LAT];
    LatSpikeTab[4] = extmp;
    LatSpikeTab[0] = extmp;
    extmp = GPS_read[LON];
    LonSpikeTab[4] = extmp;
    LonSpikeTab[0] = extmp;

    rdy = 0; maxsortidx=4;
    while(rdy == 0){
     rdy = 1;
     for (sortidx = 0; sortidx<maxsortidx;sortidx++){
      extmp = LatSpikeTab[sortidx];
      if (extmp > LatSpikeTab[sortidx+1]) {LatSpikeTab[sortidx] = LatSpikeTab[sortidx+1]; LatSpikeTab[sortidx+1] = extmp; rdy = 0;}
     }
     maxsortidx --;}
    rdy = 0; maxsortidx=4;
    while(rdy == 0){
     rdy = 1;
     for (sortidx = 0; sortidx<maxsortidx;sortidx++){
      extmp = LonSpikeTab[sortidx];
      if (extmp > LonSpikeTab[sortidx+1]) {LonSpikeTab[sortidx] = LonSpikeTab[sortidx+1]; LonSpikeTab[sortidx+1] = extmp; rdy = 0;}
     }
     maxsortidx --;}

    GPS_read[LAT] = LatSpikeTab[2];                                          // Fill Filter
    GPS_read[LON] = LonSpikeTab[2];
Im Anschluss könnte man die Spike - gefilterten GPS Daten noch einem kurzen, gleitenden Mittelwertfilter zuführen. Da die GPS Daten bei Weiterverarbeitung schnell die 32 Bit sprengen, müssen 64Bit für die Mittelwertsumme verwendet werden. Das könnte programmiert dann so aussehen:

Code:
    LatTab[Avgidx] = GPS_read[LAT];                                          // Fill Filter
    LonTab[Avgidx] = GPS_read[LON];
    Avgidx++; if (Avgidx==GPS_FILTER_VECTOR_LENGTH) Avgidx=0;
    uint8_t IdxCnt=0;
    int64_t tmp64Lat=0,tmp64Lon=0;
    while(IdxCnt<GPS_FILTER_VECTOR_LENGTH){tmp64Lat = tmp64Lat + LatTab[IdxCnt]; tmp64Lon = tmp64Lon + LonTab[IdxCnt]; IdxCnt++;}
    i2c_dataset.gps_loc.lat = tmp64Lat/GPS_FILTER_VECTOR_LENGTH;
    i2c_dataset.gps_loc.lon = tmp64Lon/GPS_FILTER_VECTOR_LENGTH;
Tja, dann bin ich noch auf die Idee gekommen, den hardware nahen mwii-seriellen code in die eos bandi Version ein zu bauen.
In der Summe kann ich hier nur eine hoch experimentelle ALPHA Version anbieten. Die Version ist NUR als Codebeispiel gedacht! Voraussetzung ist die AXN1.51_2722_3329_384.1151100.5.bin.

LG
Rob
 

Anhänge

Zuletzt bearbeitet:

RC FAN2

Erfahrener Benutzer
#5
Hi ,

Da hab ich gleich mehrere Fragen :)
Ich hab irgendwo gelesen (glaub auch von dir) das der I2C Code Probleme mit 115200b haben könnte.
Betrifft das nur NEMA und MTK Binär oder auch das UBX Protokoll ?
Ich verwende ein Ublox Neo 6m mit dem UBX Protokoll und 115200b , und habe das Problem das ich im Flug oft mal für 1-2sek. kein gps habe . Hab schon alles mögliche getestet und denke das es ein Parsingfehler bzw. ein fehler der Seriellen schnittstelle ist. Nun überlege ich ob ich den Multiwii Seriell Treiber in den I2C code einbaue um dieses Problem zu beheben .
Was meinst du dazu ?

Der Spikefilter gefällt mir auch sehr gut , kann dieser auch für das UBX Protokoll verwendet werden ?
Kannst du genau sagen wo er im Code seinen platz findet ?

Danke Schonmal ;)
 

Roberto

Erfahrener Benutzer
#6
@RC FAN2:

..Betrifft das nur NEMA und MTK Binär oder auch das UBX Protokoll ?...
..Nun überlege ich ob ich den Multiwii Seriell Treiber in den I2C code einbaue um dieses Problem zu beheben ...
Punkt 1: Das kann ich Dir nicht sagen. Wahrscheinlich würdest Du mit 57K Baud besser fahren.
Punkt 2: Das hatte ich mir auch gedacht, und habe es umgesetzt. Fazit: Hat nichts gebracht. Geschadet hat es bis jetzt nicht und die Codesize ist reduziert....

Der Spikefilter gefällt mir auch sehr gut , kann dieser auch für das UBX Protokoll verwendet werden ?
Ja, der Spikefilter befindet sich direkt nach der Datenaquisition von GPS Länge/Breite. Dabei ist die Datenquelle/ das Protokoll egal. Der Filter kommt daher an die Stelle: ca. Zeile 1260

Code:
..
       // We have a valid GGA frame and we have lat and lon in GPS_read_lat and GPS_read_lon, apply moving average filter
..
also so:

Code:
....
       // We have a valid GGA frame and we have lat and lon in GPS_read_lat and GPS_read_lon, apply moving average filter
       // this is a little bit tricky since the 1e7/deg precision easily overflow a long, so we apply the filter to the fractions
       // only, and strip the full degrees part. This means that we have to disable the filter if we are very close to a degree line


    int32_t extmp;
    uint8_t rdy,sortidx,maxsortidx;
    extmp = GPS_read[LAT];
    LatSpikeTab[4] = extmp;
    LatSpikeTab[0] = extmp;
    extmp = GPS_read[LON];
    LonSpikeTab[4] = extmp;
    LonSpikeTab[0] = extmp;

    rdy = 0; maxsortidx=4;
    while(rdy == 0){
     rdy = 1;
     for (sortidx = 0; sortidx<maxsortidx;sortidx++){
      extmp = LatSpikeTab[sortidx];
      if (extmp > LatSpikeTab[sortidx+1]) {LatSpikeTab[sortidx] = LatSpikeTab[sortidx+1]; LatSpikeTab[sortidx+1] = extmp; rdy = 0;}
     }
     maxsortidx --;}
    rdy = 0; maxsortidx=4;
    while(rdy == 0){
     rdy = 1;
     for (sortidx = 0; sortidx<maxsortidx;sortidx++){
      extmp = LonSpikeTab[sortidx];
      if (extmp > LonSpikeTab[sortidx+1]) {LonSpikeTab[sortidx] = LonSpikeTab[sortidx+1]; LonSpikeTab[sortidx+1] = extmp; rdy = 0;}
     }
     maxsortidx --;}

    GPS_read[LAT] = LatSpikeTab[2];
    GPS_read[LON] = LonSpikeTab[2];
Dann musst Du oben noch die Variablen definieren.

Code:
...
////////////////////////////////////////////////////////////////////////////////////
// GPS SPIKE filter variables Crashpilot1000 AKA ROB
//
static int32_t LatSpikeTab[5];
static int32_t LonSpikeTab[5];
...
Ob der Spikefilter etwas im Flug taugt, kann ich nicht sagen. Im Stand macht er einen sehr guten Eindruck.

LG
Rob
 

Roberto

Erfahrener Benutzer
#7
So, ich habe mal die MTK GPS FW: AXN1.30_2389_3329_384.1151100.1_v16.bin von hier http://code.google.com/p/ardupilot/wiki/MediaTek aufgespielt und den Datenstrom analysiert.
Kurzfazit: Die AXN1.51_2722_3329_384.1151100.5.bin (http://code.google.com/p/i2c-gps-nav/downloads/detail?name=MTK-firmware-tools-for-2.1.zip&can=2&q=) scheint mir ein genaueres Ergebnis zu liefern, kann aber auch von der Tageszeit etc abhängen. Ich flashe auf jeden Fall wieder zurück auf die 1.51.

Jetzt kommt das eigentlich merkwürdige. Zum einen produziert die 1.30 auch abgehackte Datensätze mit falschem "Payloadbyte" (soll die Datensatzlänge zeigen) bei fehlenden Sats, zum anderen liefert sie allerdings beide Checksummen (A&B). Die 1.51 liefert nur Checksumme A. Das wirklich komische ist, dass die eos bandi empfohlene Firmware 1.51 zu seiner (APM) Ausleseroutine absolut inkompatibel wäre, wenn sie so funktionieren würde wie gedacht. Da eigentlich nur GPS Koordinaten ausgegeben werden dürfen wenn BEIDE checksummen korrekt sind. Ich glaube, mehr muss man zu dem Parser nicht sagen (auch APM!). Leider ungeil.

LG
Rob
 

JUERGEN_

Generation 60++
#8
.
gibt es zum MTK eigentlich keine umfangreiche Dokumentation vom Hersteller ?
wie zb von µ-BLOX
 

JUERGEN_

Generation 60++
#10
Die Dokumentation des DIY Drones custom binär Protokolls
habe ich nur bei diy drones gefunden (siehe Link oben).
Orginal oder Re-Engineering ?

ev. liegt µ-BLOX auch deswegen so weit vorne, weil sie wissen was sie tuen ?
und Dokumentationen sehr umfangreich vorhanden sind. :)
-> http://www.u-blox.com/images/downlo...DescriptionProtocolSpec_(GPS.G6-SW-10018).pdf
-> http://www.u-blox.com/images/downlo...rdwareIntegrationManual_(GPS.G6-HW-09007).pdf


und, . . . wer hat's erfunden ? :D

:)
 

Roberto

Erfahrener Benutzer
#11
Epic fail!

So, es gibt Neuigkeiten!

Ich muss mich jetzt schämen!!!

Hier habe ich es schon gepostet: http://www.multiwii.com/forum/viewtopic.php?f=8&t=649&start=1490#p27737

EOS Bandi hat sich gemeldet und gezeigt (Programm: Realterm), dass auch ohne Sats komplette Datensätze gesendet werden. Das Problem war meine serielle Monitoring Software PUTTY. Ich hatte Putty unter "Logging" auf "All session output" gestellt in der Annahme, dass eben auch alle Daten in das logfile kommen. Fehlanzeige. Das tückische: Wenn er gefüllte Datensätze hatte, hat er die auftretenden Nullbytes übertragen (im logfile gespeichert) nur wenn es zuviel wurden hat er sie komplett gestrichen und nicht aufgezeichnet. Diese Logfiles haben mich zu der Annahme gebracht, dass da etwas ganz gewaltig schief läuft. Schande über mich. Wenigstens hat die Sache ein gutes: Wir haben jetzt einen eigenen, sicher funktionierenden MTK Binärparser, der Checksumme A gegenprüft. Der Checksumme B traue ich nicht.

Code:
bool GPS_MTK_newFrame(uint8_t data)
{
   static uint8_t pstep;                              // Parse Step
   static uint8_t lastbyte;                           // Last Byte for Sync detection
   static uint8_t LSLshifter;                         // Bitshiftvalue
   static uint8_t chkA,count;

   static int32_t lat;                                // MTK Dataset
   static int32_t lon;                                // MTK Dataset
   static int32_t alt;                                // MTK Dataset
   static int32_t grspeed;                            // MTK Dataset
   static int32_t grcourse;                           // MTK Dataset
   static uint8_t satn,fixtype;                       // MTK Dataset
   int32_t tmp32;
   bool parsed;
   
   parsed = false;

   if (pstep == 0 && data == 0xdd && lastbyte == 0xd0) pstep = 100; // Detect Sync "0xD0,0xDD" Only search for Sync when not already decoding
   lastbyte = data;

   switch(pstep) {
    case 0:                                           // Special Case: Do Nothing
    break;
    case 100:                                         // Special Case: Prepare next decoding run
    pstep = 1;                                        // Jump into decoding on next run
    chkA = 0; count = 0;                              // Reset values
    break;

    case 1:                                           // Payload Byte is always $20! (This is the first Byte after sync preamble)
    if (data == 0x20) pstep++;                        // Since it is always $20 we take it as extended, undocumented syncword "preamble3"
     else pstep =0;                                   // Error! Wait for sync
    chkA = chkA + data;
    count ++;
    break;

    case 2:                                           // Read Dataset Latitude
    lat = data;
    LSLshifter = 0;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    case 3:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    lat = lat | tmp32;
    if (LSLshifter == 24){lat = lat * 10; pstep++;}
    chkA = chkA + data;
    count ++;
    break;    

    case 4:                                           // Read Dataset Longitude
    lon = data;
    LSLshifter = 0;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    case 5:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    lon = lon | tmp32;
    if (LSLshifter == 24){lon = lon * 10; pstep++;}
    chkA = chkA + data;
    count ++;
    break;

    case 6:                                           // Read Dataset MSL Altitude
    alt = data;
    LSLshifter = 0;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    case 7:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    alt = alt | tmp32;
    if (LSLshifter == 24){alt = alt/100; pstep++;}
    chkA = chkA + data;
    count ++;
    break;

    case 8:                                           // Read Dataset Ground Speed
    grspeed = data;
    LSLshifter = 0;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    case 9:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    grspeed = grspeed | tmp32;
    if (LSLshifter == 24) pstep++;
    chkA = chkA + data;
    count ++;
    break;

    case 10:                                          // Read Dataset Heading
    grcourse = data;
    LSLshifter = 0;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    case 11:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    grcourse = grcourse | tmp32;
    if (LSLshifter == 24) pstep++;
    chkA = chkA + data;
    count ++;
    break;

    case 12:                                          // Read number of satellites in view
    satn = data;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    
    case 13:                                          // Read Fix Type
    fixtype = data;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;

    case 14:                                          // Wait for cheksum A
    if (count == 33){                                 // 33 = 0x21
      if (chkA == data) pstep++;                      // ChecksumA reached. Correct? than go on
       else pstep = 0;                                // Error?
    }else{
      chkA = chkA + data;
      count ++;}
    break;

    case 15:                                          // Dataset RDY !! Cheksum B omitted, ChkA was OK
    if (fixtype==1){                                  // No Fix
    i2c_dataset.status.gps2dfix = 0;
    i2c_dataset.status.gps3dfix = 0;}
    if (fixtype==2){                                  // GPS 2D Fix
    i2c_dataset.status.gps2dfix = 1;
    i2c_dataset.status.gps3dfix = 0;}
    if (fixtype==3){                                  // GPS 3D Fix
    i2c_dataset.status.gps2dfix = 1;
    i2c_dataset.status.gps3dfix = 1;}
    GPS_read[LAT] = lat;
    GPS_read[LON] = lon;
    i2c_dataset.altitude = alt;
    i2c_dataset.ground_speed = grspeed;
    i2c_dataset.ground_course = grcourse;
    i2c_dataset.status.numsats = satn;
    parsed = true;                                    // RDY
    pstep = 0;                                        // Do nothing
    break;
   }
 return parsed;
}
LG
Rob
 
Zuletzt bearbeitet:

helste

Erfahrener Benutzer
#12
Na schäm Dich;-)

Rob, es gibt keinen Grund sich zu schämen. Nur wer nichts macht, macht keine Fehler. Gerade beim Programmieren ist es praktisch ausgeschlossen, dass man keine Fehler macht. Murphys Law schlägt da gnadenlos zu.
Ich weiß wovon ich rede. Ich verdiene seit ca. 20 Jahren mein Geld mit der Entwicklung von Software.
 

Roberto

Erfahrener Benutzer
#13
Danke Helste, für Deinen Zuspruch!
Vielleicht könntest Du hier einsteigen?
Ich verrenne mich relativ häufig, aber das war schon wirklich heftig. Immerhin brauche ich mir um die MTK Datenaquisition keine Sorgen mehr zu machen. Der code ist idiotensicher, wahrscheinlich schneller und lässt sich leicht erweitern, wenn man Datum und Uhrzeit noch auslesen möchte.
So, jetzt habe ich eine Version zusammengebaut, von der ich denke, dass sie brauchbar/fliegbar ist. Die Basis ist der aktuelle EOS Bandi code. Es hat sich unter der "Motorhaube" allerdings etwas geändert.

1. Betrifft: NMEA UBLOX MTK
1.1 Seriell
Der arduino serielle Teil ist durch den Multiwii seriellen Teil ersetzt. Der Vorteil ist u.a, dass es jetzt einen 256 Byte grossen Eingangspuffer für serielle Daten gibt (vorher 64 Byte). Das reduziert die Wahrscheinlichkeit von verlorenen, seriellen Datenpaketen. Bislang habe ich keine Probleme mit dem multiwii seriellen Teil feststellen können.

1.2 Spikefilter
In der Conig.h dieser Version kann man mit "#define SPIKEFILTER" (default: AUS) einen experimentellen Filter für Ausreisser- GPS Daten einschalten. Der Filter sitzt vom Programmablauf her direkt hinter der GPS Datenaquisition, also vor dem eos bandi moving average filter. Dieser lässt sich in der config.h der multiwii FC hier aktivieren/deaktivieren (" #define GPS_FILTERING // add a 5 element moving average filter to GPS coordinates, helps eliminate gps noise but adds latency comment out to disable"). Eos Bandi empfiehlt diesen Filter nur für NMEA Daten mit 10Hz Datenrate. Wenn man den Spikefilter mit dem anderen kombinieren möchte könnte ich mir vorstellen, dass eine Reduktion der "#define GPS_FILTER_VECTOR_LENGTH 5" auf 3 sinnvoll wäre. Wie gesagt es fehlen Praxiserfahrungen. Der Spikefilter sollte eigentlich kaum Latenz produzieren und kann m.E alleinstehend mit "5Hz Daten" verwendet werden.

1.3 Variablen reset
Bei Verlust eines Sat Fixes wird die Navigation in den "Reset" geschickt, d.h. Variablen werden mit 0 beschrieben. M.E wird die lat/long Geschwindigkeitsberechnung dabei vergessen. Zur Sicherheit habe ich die Variablen "last_longitude" und "last_latitude" deswegen bei satfix-Verlust auch auf 0 gesetzt. Kann nicht schaden.

2. Betrifft: NMEA
Beim Auslesen des NMEA Datenstroms ist eine Variable von 16 auf 32 Bit erweitert worden um einem Variablenüberlauf vorzubeugen. Die Meinungen darüber, ob das nötig ist, gehen auseinander. Schaden kann es nicht.

3. Betrifft: MTK (Binärmodus mit FW AXN1.51_2722_3329_384.1151100.5.bin)
Das Modul wird auf 57K Baud geschaltet. Die Datenfrequenz wird auf 10Hz gestellt. SBAS wird eingeschaltet.
Das Ausleseprogramm des seriellen Datenstroms ist komplett neu geschrieben.

So, das müsste es gewesen sein. Da ist eigentlich für jeden etwas dabei.

Viel Spass beim Testen!

LG

Rob
 

Anhänge

Zuletzt bearbeitet:

weisseruebe

Erfahrener Benutzer
#14
Auch von mir meine Hochachtung!
Dass man sich mal (derbe) verrennt, das gehört dazu, auch wenn es frustriert.
Ich benutze zum Reverse-Engineering (und generell) für serielles Zeug gerne HTerm. Da kann man alle möglichen Zahlensysteme anzeigen lassen und die Daten auch wunderbar so umbrechen, dass man schön arbeiten kann.

Ich werde das mal weiter verfolgen, und wenn ich die Zeit finde baue ich gerne den Code dann mal direkt in den MW-Code ein. So wie ich es verstehe, arbeitest Du ja noch auf dem separaten Seriell-I2C?
 

Roberto

Erfahrener Benutzer
#15
Noch eine Version!

@weisseruebe:
Danke!!!!
Auf Dein Angebot mit dem Einbauen in den offiziellen Mwii code nehme ich sehr gerne an !!!
Das HTerm ist auch ein sehr guter Tip!!
Ich benutze das von Wollez geschenkte I2C - LZ-GPS (http://www.wii-copter.de/lz-gps.html).
Dank der besch...eidenen Dokumentation der MTK Firmwares, habe ich dirket noch ein Problem entdeckt. Ich weiss nicht, was die ganze Geheimniskrämerei soll, schliesslich müsste auch der Hersteller ein Interesse an einer transparenten Dokumentation haben. Offensichtlich liegt da ein anderes Geschäftsmodell vor. Jürgens Einwand ist berechtigt.
So, in dem Post von eos bandi hier http://www.multiwii.com/forum/viewtopic.php?f=6&t=1881&start=10#p19325 ist zu lesen, dass MTK im Binärmodus und 10Hz Datenrate das SBAS abschaltet. Es funktioniert nur mit 5Hz. Weil es mir zu bunt wird habe ich eos bandi angeschrieben, ob er nicht eine Dokumentation für seine custom FW hat. Hier die Antwort: http://www.multiwii.com/forum/viewtopic.php?f=8&t=649&start=1500#p27774. Also ist es unklar, von welchem Laster die FW AXN1.51 gefallen ist. Es ist nur klar, dass sie das DIY Drones Binärprotokoll macht. Im Übrigen kann man auch die, genau so schlecht dokumentierte, original DIY Drones Firmware "1.6" verwenden von hier http://code.google.com/p/ardupilot/wiki/MediaTek. Das ist dann die AXN1.30_2389_3329_384.1151100.1_v16.bin, die auch hier dabei ist: http://code.google.com/p/i2c-gps-nav/downloads/detail?name=MTK-firmware-tools-for-2.1.zip&can=2&q=.
Um das ganze Durcheinander nicht unnötig zu vergrössern, und eigene Konfigurationsschritte zusammen zu schustern, habe ich die Konfigurationssequenz aus dem aktuellen APM Treiber 1:1 übernommen. Punkt und aus. D.h. 5Hz, Binärmodus, SBAS und WAAS an. Gleichzeitig habe ich in der config.h noch die Möglichkeit eingebaut auf 10HZ schalten zu können "#define MTK10HZ". Wer weiss schon, was sonst noch für FW Versionen auftauchen. Vielleicht schafft eine SBAS/WAAS mit 10Hz im Binärmodus. Dann habe ich mir noch einen Punkt für die config.h ausgedacht "#define AFALWAYSOFF". Damit kann man den averagefilter (für 10HZ NMEA Daten gedacht) permanent im I2C Modul abschalten. Das hat den Vorteil, wenn man eine neue Mwii Version flasht, kann man das Auskommentieren von "#define GPS_FILTERING" ruhig vergessen, der Averagefilter bleibt aus. Eine Variable aus dem Hauptprogramm habe ich in der config.h zugänglich gemacht. Und zwar die Mindestanzahl der Satelliten die für GPS Funktionen erforderlich sind. "#define MINSAT 5". Der Sinn ist folgender: Vordefiniert ist ein Wert von 5 Sats. Das gibt bei mir (ungünstige Bedingungen) eine geschätzte Abweichung von 50m, bei 6 Sats ca. 20m, ab 7 Sats wird es brauchbar. Wenn man diesen Wert z.B auf 7 oder 8 stellt, kann man sicher sein, das er beim Einstellen von z.B PH nicht wegen volkommen irrer GPS Koordinaten abzischt. Im Zweifelsfall macht er eben nichts.
So sieht jetzt die config.h aus:
Code:
// *********************************** GENERAL GPS TYPE
//#define NMEA
//#define UBLOX
#define MTK                            // Defined: Binary, 57K Baud, 5Hz, SBAS

// *********************************** GENERAL FILTER VALUES
#define SPIKEFILTER                    // Turn on experimental spikefilter
#define AFALWAYSOFF                    // Always turn off the moving average filter("AF"), doesn't matter whats in mwii config.h defined

// *********************************** GENERAL GPS VALUES
#define MINSAT 5                       // 5 is default minimal number of sats for gps functions, if desired you can change it here

// *********************************** MTK BINARY SPECIAL (FW:AXN1.51_2722_3329_384.1151100.5.bin)
//#define MTK10HZ                      // According to this post: http://www.multiwii.com/forum/viewtopic.php?f=6&t=1881&start=10#p19325
                                       // when enabeling 10HZ in mtk binary mode, you will loose SBAS functionality!! That will just work at 5Hz (default).
Viel Spass beim Testen!!

LG
Rob
 

Anhänge

Zuletzt bearbeitet:

JUERGEN_

Generation 60++
#16
MTK GPS von GlobalTop Technology

.
es gibt ja einen, der einen haufen MediaTek Cipsätze verbaut

GlobalTop Technology

wenn auch der MediaTek MT3329 schon eine ganze Weile veraltet ist.

haben die wenigstens noch eine Support Seite. :) aber solange du keine 10000St. abnehmen willst. :D

... aber die download, ist auch wenig ergiebig.
-> http://www.gtop-tech.com/en/page/download-01.html

und die MediaTek MT3339 gehören auch zur "Billigen" Massenware, die es auch in DE gibt.
zum Bleistift hier.
-> http://shop.trenz-electronic.de/catalog/default.php?cPath=105_181



muss aber jeder selber wissen, ob Billig sich wirklich lohnt. :)
oder doch lieber gleich einen µ-BLOX

:)
 
Zuletzt bearbeitet:

Roberto

Erfahrener Benutzer
#17
Wie gesagt, die Links sind leider 0 ergiebig, wenn man wissen will, was eine spezielle Firmware kann. Man könnte auch gängige FW zusammenstellen und zum Download anbieten (mit Beschreibung). ublox in allen Ehren, aber so schlecht kann mtk auch nicht sein, sonst könnten die sich am Markt nicht halten.....
 

mbrak

Erfahrener Benutzer
#18
hi

der paul von flyduino hat im rc-groups mal einige firmwares für sein fmp04 gps angeboten. habe dort 2 firmwares runtergeladen mit 5hz /57600 und 10hz/115200.

hat sich so gelesen, als wenn die firmwares für ihn auf wunsch gemacht wurden. das fmp04 basiert doch auch auf dem MTK chipsatz (MT3329)

gruß
 

Roberto

Erfahrener Benutzer
#19
Wir müssen jetzt nur aufpassen, dass nicht alles durcheinander kommt. NMEA / Binärprotokoll und verschiedene Versionen des 3329. Wenn es sich auch um ein PA6B handelt und sich die 10HZ auf das Binärprotokoll beziehen und gleichzeitig funktionierendem WAAS/SBAS, dann sind die FW sehr interessant!

LG
Rob
 

mbrak

Erfahrener Benutzer
#20
eben :)

die firmware die ich habe kann nur nmea 5hz/10hz. ich denke eine nicht kleine anzahl user hat das fmp04 gps von flyduino. kann man dort die von dir genannte firmware flashen?
ich steige ja im moment selbst nicht durch. deswegen frage ich ja :)
möchte nach möglichkeit nicht unbedingt noch ein ublox kaufen, da ich ja ein halbwegs funktionierendes mtk (nmea) habe.
je nach empfang und laune des wiicopters waren damit recht gute ergebnisse im hold mode möglich. allerdings wurde dies mit späteren devs nicht mehr erreichbar. der copter brach aus und war nicht am punkt zu halten. keine ahnung ob da das parsing nicht gescheit funktionierte. habe jetzt erstmal die dev 1279 drauf und in der gui schaut das soweit ok aus.
 
FPV1

Banggood

Oben Unten