Hi!
While messing around with my MTK i found a weird initialization string in the AP_GPS_MTK_Common.h for waas.
It is currently:
#define WAAS_ON "$PSRF151,1*3F\r\n"
this string doesn't seem to be a valid command judging from the documentation.
Is it a 3Drobotics special?
Wouldn't this be correct?
#define WAAS_ON "$PMTK301,2*2E\r\n"
So long
Kraut Rob
Replies
thanks craig now it works
cu
Michael
I'm having the same issue as Michael. I updated the GPS with 1.9 FW ( http://code.google.com/p/ardupilot-mega/downloads/detail?name=AXN1.... ) and got the latest of AC 2.9 from the repository.
After flashing the FC I go into terminal and do 'test', 'gps' and get a series of dots. I look at 'rawgps' and i see NMEA:
$PGACK,003,-1*71
$PGACK,16,1*68
$PMTK001,220,3*30
etc..
I put some printf()'s in the code and it is definitely setting binary mode:
$PGCMD,16,0,0,0,0,0*6A
It keeps setting binary mode while in the test, gps routine every few seconds. Yet it remains in NMEA mode.
Interestingly the 1.6 firmware doesn't have this issue. It stays in binary mode properly. I'm stumped (tried GPS_PROTOCOL_AUTO it doesn't even go into the MTK19 class's code!).
the dedection of the right gps version is not working. see the trace of the MTK GPS Version 1.9 together with AC 2.9 rc1.
i can see that the gps will be switched from NMEA mode into Binary. after 5 seconds the mode changes again into a mixed mode between Binary and NMEA mode. i thnk it switched into normal NMEA mode.
Also the MP does not show the reported 07 in the gpsstatus it always stays at 3. my be Michael Oborne need to to something.
trace_mtk19_auto.txt
I did another version wich activates everything that possibly can be activated. Perhaps it is an improvement over the first zip ?
So long
Kraut Rob
AP_GPSMTKCorrected3.zip
Will this be a mod we will see in next release of arducopter and arduplane? Maybe that is why uBlox is giving better results because it doesn't have these issues?
It seems to me that this modification certainly has a marked influence on the precision of the MTK3329. I replaced the library files with those originally posted by Crashpilot1000 and tested the result.
The first picture shows the pre-change performance over a period of 20 mins. The quad was stationary but the drift in reported position is obvious. Incidentally there is some Photoshopping going on here to stitch together the tracks over this extended time - the tracks however are quite genuine.
After updating the libraries the performance was totally different. The reported position started at point A (see second image) with a satcount of 7 and gpshdop of 1.7 . The satcount dropped to 5 with hdop increasing to 3.8 and the reported position drifted to point B. The GPS then picked up 6 sats with hdop improving to ~2.4 and the quad 'set off' for point C where 7 sats were accessed, hdop improving to 1.7 and the reported position settling as indicated by the quad symbol.
The third image shows the reported position over a further 5 minutes.
This is the best and most consistent position reporting I have ever seen with my quad.
Thank you Crashpilot1000.
Pre Update.jpg
Post update variations.jpg
Post Update.jpg
You are spot on with your correction. The $PSRF151 command is from the SiRF command set when the Sparkfun GPS was used. I will be adding your patch to the configuration file and I would like to send you 3DRobotics t-shirt for your contribution.
Thanks,
Craig
i found this a description
Packet Type: 301 PMTK_API_SET_DGPS_MODE
Packet Meaning:
API_Set_Dgps_Mode
DGPS correction data source mode.
DataField:
PMTK301,Mode
Mode: DGPS data source mode.
‘0’: No DGPS source
‘1’: RTCM
‘2’: WAAS
Example:
$PMTK301,1*2D<CR><LF>
i think in addition we also need this parameter:
Packet Type: 313 PMTK_API_SET_SBAS_ENABLED
Packet Meaning:
API_Set_Sbas_Enabled
Enable to search a SBAS satellite or not.
DataField:
Enabled: Enable or disable
‘0’ = Disable
‘1’ = Enable
Example:
$PMTK313,1*2E<CR><LF>