Hi !!


I am currently messing around with MTK GPS stuff and the binary protocol.

Assuming my APM2.0 GPS has the 1.6 loaded, i want to upgrade the GPS FW. Since the gps is directly mounted to the mainboard i don't know how to do it.

The APM wiki http://code.google.com/p/ardupilot/wiki/MediaTek gives no hints.

Please help!

So long

Kraut Rob

EDIT: SOLUTION FOUND:

UPDATE 12/28/2012

I included a zip file with all the needed files and a complete guide below.

It contains basically the same files than the previous version but an extended guide and the source code.

UPDATE 12/28/2012

Added German guide.

UPDATE 19/01/2013

FTDI Hardwareflash on APM 2.0 (Set your FTDI to 5V, if you have one of these Breakoutboards)

1. Download the zip below to have all the files needed - and a flashguide.

2. Load MP and save all your parameters to a file (if desired).

3. Do Arduino / eeprom clear on your main CPU so that no serial traffic can disturb the process. Do not omit this step. It won't work with the arduino still talking on the serial line - i tested it. P.s. You can also use the precompiled hex from my post here: http://diydrones.ning.com/xn/detail/705844:Comment:1094234

4. Unpower APM for soldering. If FTDI connection is already established, powercycle to reset GPS to its' default state.

5. Locate the external GPS port (UART1). If you have not the right plug (like me) you have some solder pads right behind it. You will need GND/RX/TX. Look at this picture for the right connection: http://diydrones.com/forum/attachment/download?id=705844%3AUploaded...

Note: I labeled RX and TX relative to the GPS not the CPU (like printed on the PCB). I showed 3 points where you can get access to the important datalines, besides the obvious connectionport (that would be number 4:)).

6. Power APM Board, fire up the flashing soft and follow the documentation -> Point 8 in MTKFlashGuide2.pdf or point 7 in MTKFlashGuide2German.pdf. Reading the complete pdf is also ok.

7. Reload Arducopter FW on mainboard and reload your saved settings (if desired). Perhaps recheck calibrations (ACC etc.)

8. Done.

UPDATE 21/01/2013 - 02/03/2013

Here is a Must Try List - if you have a persisting flash problem (Thanks Anton for the idea)

- http://diydrones.ning.com/xn/detail/705844:Comment:1094071  (Thanks Anton)

- http://diydrones.ning.com/xn/detail/705844:Comment:1094290  (Thanks William Stoner)

- http://diydrones.com/xn/detail/705844:Comment:1097033       (Thanks Isaac)

- http://www.diydrones.com/xn/detail/705844:Comment:1097725 (Thanks Chris Webb // Mac running VMWare WinXP)

- http://diydrones.ning.com/xn/detail/705844:Comment:1140259 (Thanks "exaustgas" // Win serial port)

- http://diydrones.com/xn/detail/705844:Comment:1146635 (Thanks Cody // serial port in flashutil config)

- Try to rule out a driver/win firewall/administrator/viruskiller thing

UPDATE 02/03/2013

Due to the outstanding work of Perecastor here: http://diydrones.ning.com/xn/detail/705844:Comment:1149155

We have a French guide now as well !!

I took the liberty to put it here as well.

UPDATE 21/05/2013

Hardware - "Hack":

Use your PC - RC Transmitter Adaptercable as FTDI:

http://diydrones.com/xn/detail/705844:Comment:1252901 (Thanks Jan Boermans)

Cheers

Rob

Views: 22539

Attachments:

Reply to This

Replies to This Discussion

I did it anyway....

Here is how i did it.

I tried out what i thought what could work - and it worked! http://diydrones.com/xn/detail/705844:Comment:1055533

I attached a picture to show you 3 different locations to connect your FTDI to. I named RX and TX according to the GPS (MTK 3329) and not according to the CPU. I am sorry to say it wouldn't work without eeprom_clear of your arduino. Since my APM 2.0 was already mounted and i had no pins soldered to uart1 i took RX/TX from the big plasic connector of the GPS breakout board.

I hope this info helps others!

So long

Kraut Rob

Attachments:

Hi!

Now i did a version for the lazy ones: No FTDI, No soldering!

I wrote a little arduino passthrough program. So upload this little program to your Arduino (i always do eepromclear before). Now you can communicate with your GPS directly with your usb connection. So the flightcontrol is just an FTDI adapter then. You can start the flashprogram as usual (38Kbaud) it works perfectly (i flashed 2 gps firmwares for test).

Here is the listing (it's dead simple):

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

void loop() {
  uint8_t serbyte;
 
   if (Serial.available() > 0) {
    serbyte = Serial.read();             // Get Data from PC
    Serial1.write(serbyte);              // Give Data to GPS
   }

  if (Serial1.available() > 0) {
  serbyte = Serial1.read();            // Get Data from GPS
  Serial.write(serbyte);               // Give Data to PC
  }

}

So long

Kraut Rob

Attachments:

Sweet! Nice job...

Well done!!

That is fabulous news!!

I really want Chashpilot1000 in the dev team, also in the testers group... thanks man! :-)

We'll definitely be adding this to the wiki. Invitation to join the dev team coming, too!

I agree, that is alot simpler then needing to use a ftdi cable!

However, couple suggestions if I may.

1) That same code can be used to connect the MTK to MiniGPS (or U-Center for Ublox) on the PC as well.. For Monitoring Sats, configuration changes, etc.. not just firmware upgrades.

You may find you'll want multiple versions of these for different baud rates. ( as firmware upgrades tend to be different baud rates than what APM communicates at ) or could be just added to the docs on Wiki, and have the user change them to appropriate values?

2) Also just comparing the CLI rawgps test code, you can see below that we had included blinking the LED's while activity was occouring. You could incorporate that into your UpdateGPS code for visual feedback.

 --------------------

test_rawgps(uint8_t argc, const Menu::arg *argv)
{
    print_hit_enter();
    delay(1000);
    while(1) {
        // Blink Yellow LED if we are sending data to GPS
        if (hal.uartC->available()) {
            digitalWrite(B_LED_PIN, LED_ON);
            hal.uartB->write(hal.uartC->read());
            digitalWrite(B_LED_PIN, LED_OFF);
        }
        // Blink Red LED if we are receiving data from GPS
        if (hal.uartB->available()) {
            digitalWrite(C_LED_PIN, LED_ON);
            hal.uartC->write(hal.uartB->read());
            digitalWrite(C_LED_PIN, LED_OFF);
        }
        if(cliSerial->available() > 0) {
            return (0);
        }
    }

}

oops, pasted the wrong copy... that was from ardupilot (which has some HAL terminology) not the arducopter test.pde

Here is the code from arducopter test.pde. but it looks to have been commented out though... probably to save memory.

(the serial port numbers below are for ftdi use as you can probably tell ;)

//static int8_t test_rawgps(uint8_t argc, const Menu::arg *argv) {
/*
* print_hit_enter();
* delay(1000);
* while(1){
*  if (Serial3.available()){
*  digitalWrite(B_LED_PIN, LED_ON); // Blink Yellow LED if we are sending data to GPS
*   Serial1.write(Serial3.read());
*  digitalWrite(B_LED_PIN, LED_OFF);
*   }
*  if (Serial1.available()){
*  digitalWrite(C_LED_PIN, LED_ON); // Blink Red LED if we are receiving data from GPS
*  Serial3.write(Serial1.read());
*  digitalWrite(C_LED_PIN, LED_OFF);
*   }
*  if(cliSerial->available() > 0){
*  return (0);
*   }
*  }
*/
//}

Also Merry Christmas to DIYDrones!

Yes, it works with MiniGPS.

Feel free to upgrade the code for different baudrates/fastserial/buffer/led blinking etc!

They are just a few lines of non-fancy code to get the job done.

Cheers and Merry X mas!

Kraut Rob

I agree, you dont need all the extra lines... I was simply pasting current repository code. Those were included simply because it was part of the CLI test modes.

The blinky led's :) and using it for miniGPS example was all I was getting at. (Sorry if it threw off your groove :) I've used the method you posted (gps-passthrough) many times in the past.

Another reason I liked to have direct pc->gps access was to update current sat data to the ublox gps with u-center from the internet. (I subscribed to thier update service (free)) which made lockups much faster if it had been off for a few days.

But firmware upgrade will be common to address some hardware issues; so I'm glad this will make as a solution onto the wiki.

Sorry, Darren i didn't want to be impolite or offend you!

I included your blinky code from above. But i didn't test it because my quad is nicely setup with 2.9rc1 and waiting for a spin! Here is the untested "Disco version". You can define your own baudrate as well. I let the definition for led A in, because may be led b and c are giving unpleasant lightshow - so you can change it easily :) .

#define A_LED_PIN        27        // APM_HARDWARE_APM2 NOT USED IN EXAMPLE
#define B_LED_PIN        26        // APM_HARDWARE_APM2
#define C_LED_PIN        25        // APM_HARDWARE_APM2
#define LED_ON           LOW
#define LED_OFF          HIGH

#define baud             38400     // MTK defaults at 38400 Baud, change it if needed with different GPS/FW (57600,115200)

void setup() {
  pinMode(B_LED_PIN, OUTPUT);
  pinMode(C_LED_PIN, OUTPUT);
  Serial.begin(baud);
  Serial1.begin(baud);
}

void loop() {
  uint8_t serbyte;
  if (Serial.available() > 0) {
   digitalWrite(C_LED_PIN,LED_ON);
   serbyte = Serial.read();             // Get Data from PC
   Serial1.write(serbyte);              // Give Data to GPS
   digitalWrite(C_LED_PIN,LED_OFF);
  }
  if (Serial1.available() > 0) {
   digitalWrite(B_LED_PIN,LED_ON);
   serbyte = Serial1.read();            // Get Data from GPS
   Serial.write(serbyte);               // Give Data to PC
   digitalWrite(B_LED_PIN,LED_OFF);
  }
}

Ho,Ho,Ho Merry Xmas

Kraut Rob

Attachments:

Update: Tested the Blinky-Version successfully on my APM 2.0

Greetings

Kraut Rob

RSS

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service