Replies to This Discussion

3D RoboticsPermalink Reply by Chris Anderson on September 23, 2011 at 9:23am

The code you're using is ancient, designed for versions of the Mediatek firmware that haven't been out for years. Use the current code instead.

• ▶ Reply

Permalink Reply by lucky13 on September 25, 2011 at 1:53pm

Oops! You are right. Now its working fine.

Another question.. Is it possible to use it the TinyGps lib? If yes do i have to load another firmware?

I have a problem with the FastSerial in my project using the code that u mentioned above that why i want to do it with TinyGps.

 

thank you

• ▶ Reply

Permalink Reply by Ritchie on September 25, 2011 at 2:10pm

Your problem is the test sketch uses the libraries from APM so you compiling for use separately will mean the libraries won't be included as they are in the APM folder. If you take a copy of the fast serial library and place it in your test sketch folder it will work (unless the fast serial has dependencies too in which case grab those libraries too).
Tiny GPS lib will only work if you change the MTK to NMEA mode as the MTK has a special firmware to make it much faster than standard.

• ▶ Reply

Permalink Reply by lucky13 on September 25, 2011 at 2:20pm

Thanx fo the answer Ritchie. I have already done what you are describing with the fast serial and its working. But in my application i also use another library that uses that HardwareSerial so im getting errors when i try to compile it.

Do you know what firmware version i have to load in order to take NMEA to work with the tinyGps?

• ▶ Reply

Permalink Reply by Ritchie on September 26, 2011 at 11:16am

You can send the MTK setup strings to change from binary (the custom protocol) to NMEA.

#define MTK_SET_BINARY "$PGCMD,16,0,0,0,0,0*6A\r\n"

#define MTK_SET_NMEA "$PGCMD,16,1,1,1,1,1*6B\r\n"

 

AFAIK the Tiny GPS lib should work then but it may require more tinkering.

• ▶ Reply

Permalink Reply by Ritchie on September 29, 2011 at 5:43am

Ok I have this work with TinyGPS and the NMEA output @ 38400bps

I have been trying to get the MTK to output the binary and use the old ArduPilot MTK sketch to translate but it has not exactly worked (although I'm hoping for help).

MTK defaults to NMEA @ 38400. Using the TinyGPS you must call the encode function to read the stream everytime you want to check GPS data. Not exactly a great way (at all) but functional. You must use two separate UART lines to read GPS and monitor data otherwise it doesn't work. Code I use is below and works fine. nmea is my GPS serial while Serial transmits the data to my computer.

 

void GPS_NMEA()

{  while (nmea.available() > 0){

    int c = nmea.read();

    if (gps.encode(c)){

      gps.get_position(&current_loc.lat, &current_loc.lon, &fix_age);  // lat * t6

      current_loc.alt = gps.altitude();  // height in centimeters

      ground_speed = gps.speed();

      ground_course = gps.course();

      if (fix_age == 0xFFFFFFFF){

        GPS_fix = NONE;

      } else if (fix_age > 5000){

        GPS_fix = OLD;

      } else {

        GPS_fix = fix_3D;

       }

    }

  }

}

 

void loop()

{

  GPS_NMEA();

  if (GPS_fix == fix_3D){

    GPS_print();

  }else{

    Serial.println("No Lock");

  }

}

• ▶ Reply

Permalink Reply by lucky13 on September 29, 2011 at 6:00am

Thanx for the reply Rechie.

Can u post the full code that you are working? Also what firmware version you have on the MTK?

I was able to read the gps data without changing anything in the example of the tinygps library(test_with_gps_device) and running the 1.6v firmware.

The problem that i have is although im getting a good fix(about 40) ,connected to 9 sats and have set a 10Hz update to the gps, i have to move many meters in order to get new lat and long from the gps.

Are you facing the same problems with your code?

• ▶ Reply

Permalink Reply by Ritchie on September 29, 2011 at 10:44am

The only parts I'm using extra are the variables like the location structure and enumeration of the fix variable.
I haven't tested while moving yet but it's on my list

• ▶ Reply

Permalink Reply by lucky13 on September 29, 2011 at 11:39am

Oh ok.

Are you sending something like this

port.print("$PGCMD,16,1,1,1,1,1*6B\r\n"); in the initialize in order to output NMEA?

At the initialize im also sending this

port.print("$PMTK300,100,0,0,0,0*2c\r\n$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n");

in order to switch at 10hz

 

Also what firmware version are u using in the MTK?

Permalink Reply by Ken on September 29, 2011 at 3:22pm

> The problem that i have is although im getting a good fix(about 40),

> connected to 9 sats and have set a 10Hz update to the gps, i have

> to move many meters in order to get new lat and long from the gps.

 

Correct. To keep from showing "wobbly" data, when the unit detects speeds below a certain threshold, it locks the output position until the position has changed by several meters.

 

• ▶ Reply

Permalink Reply by lucky13 on October 2, 2011 at 9:59am

Thanx for the answers. I find that this speed threshold is very high for the position hold code that im working.. For example if try to lock in a lat/lot and the quad is slowly drifting away from that direction the gps dont update the data, it must move fast in order the gps update the lon/lat.

Is there any way to change this threshold speed?

 

Permalink Reply by Ken on September 29, 2011 at 4:02pm

You do not need to send any commands to put the unit in NMEA mode. It will power up in that mode. Unless, of course, you have leftover APM software that sends the binary mode initialization to the unit.

 

I do not believe the unit will do 10Hz in NMEA mode. Too much output data, the port will never keep up (at 38400). The default NMEA set -- GLL + RMC + VTG + GSA + GSV + GGA -- at 1Hz uses 15% of the port bandwidth. At 10Hz that would be 150%. Perhaps if you disable several messages, and only enable RMC or what you need. 

• ▶ Reply