Great news! Jordi has now released the awesome new (and tiny!) 10Hz Mediatek GPS module attached to an adapter that makes it 100% ArduPilot (and ArduIMU and ArduPilot Mega) compatible. All in one--no soldering required--and you won't believe how small it is! (And just $38.95!) It's preloaded with custom DIY Drones firmware so it outputs an efficient binary protocol optimized for UAV use. Sample code is provide here and will be added to ArduPilot, ArduIMU and ArduPilot Mega over the next month.
We like this one a lot. It's nearly as good as the uBlox module, but cheaper and smaller. We'll be supporting it as a recommended GPS module going forward.
Here's the product description:
USB/UART Interface
Build-in patch antenna for optimal sensitivity
DGPS(WAAS, EGNOS, MSAS) support (optional by firmware)
Maximum update rate : up to 10Hz (optional by firmware)
RoHS compliant
-Based on MediaTek Single Chip Architecture.
-Dimension:16mm x 16mm x 6mm
-L1 Frequency, C/A code, 66 channels
-High Sensitivity:Up to -165dBm tracking, superior urban performances
-Position Accuracy:< 3m CEP (50%) without SA (horizontal)
-Cold Start is under 35 seconds (Typical)
-Warm Start is under 34 seconds (Typical)
-Hot Start is under 1 second (Typical)
-Low Power Consumption:48mA @ acquisition, 37mA @ tracking
-Low shut-down current consumption:15uA, typical
-DGPS(WAAS, EGNOS, MSAS) support (optional by firmware)
-USB/UART Interface
-Support AGPS function ( Offline mode : EPO valid up to 14 days )
We like this one a lot. It's nearly as good as the uBlox module, but cheaper and smaller. We'll be supporting it as a recommended GPS module going forward.
Here's the product description:
State-of-the-art 66 channels MediaTek MT3329 GPS Engine
High sensitivity: Up to -165dBm tracking, superior urban performanceUSB/UART Interface
Build-in patch antenna for optimal sensitivity
DGPS(WAAS, EGNOS, MSAS) support (optional by firmware)
Maximum update rate : up to 10Hz (optional by firmware)
RoHS compliant
Note that the new MediaTek has custom and exclusive "DIYDrones" firmware that allows the unit to output an efficient and very compressed binary protocol. You can still change between NMEA and Binary protocol with standard MTK messages, and switch the refresh rate between 1hz to 10hz, or set any standard serial baud rate (by default is set to 38400 bps and custom binary protocol).
Features:-Based on MediaTek Single Chip Architecture.
-Dimension:16mm x 16mm x 6mm
-L1 Frequency, C/A code, 66 channels
-High Sensitivity:Up to -165dBm tracking, superior urban performances
-Position Accuracy:< 3m CEP (50%) without SA (horizontal)
-Cold Start is under 35 seconds (Typical)
-Warm Start is under 34 seconds (Typical)
-Hot Start is under 1 second (Typical)
-Low Power Consumption:48mA @ acquisition, 37mA @ tracking
-Low shut-down current consumption:15uA, typical
-DGPS(WAAS, EGNOS, MSAS) support (optional by firmware)
-USB/UART Interface
-Support AGPS function ( Offline mode : EPO valid up to 14 days )
Comments
A question: when navigating will ArduPilot utilise the full 10Hz update rate of this GPS and navigate accordingly?
1) 'Key' users will have to switch ASAP due to extremely vulnerable Achilles Tendon of P2.
2) I have seen the P1 code and P5 code side by side and P5 is definitely NOT backwards compatible
3) WAAS geosynchronous precision GPS support satellites are already dropping out of position due to fuel exhaustion and will not be replaced (Alaska region is happening now due to defunct Intellsat) so bye-bye high precision for current users.
Bottom line:
1) Current equipment won't work any better than an old analog TV tuner works on new digital TV broadcast stations except for MAYBE pedestrians and marine use.
You wrote,
L5 will be operational in 2-3 years and L1/L2 service decomm's 2 years after that so all of the present GPS modules become useless!
This is incorrect.
1. P code is not guaranteed to be maintained after December 31, 2020. It may be on, off, or intermittent as the geeks play with the signals. This date assumes that all "Key Users" = US Military have converted to M code.
Result: $15,000 RTK type GPS's used by surveyors, *may* become non-functional (at least in high-accuracy mode). These equipments, even though they can not decode the encrypted military signals, have been using characteristics of the P code waveforms to enhance accuracy.
2. Modernization of the L1C (civilian) signals are backwards compatible, and current equipments should continue to work as designed.
3. Addition of the L2C signal may allow *some* current civilian equipments to get better accuracy. It is hoped that some L1 receivers can, with a firmware upgrade, be able to listen on dual frequencies and eliminate more atmospheric errors. That will be highly manufacturer dependent.
Bottom line:
1. All the old hand held GPS receivers and modules made over the last decade (or more?) will continue to work, though they might be considered obsolete given advantages of a combined L1C+L2C or an L5 receiver.
2. The people who paid $10,000-$30,000 for a RTK GPS are going to fill the news media with FUD about the "whole GPS system" becoming unusable.
I have mine plugged in and it locked up the first time inside a metal stud building!
Steady blue light on now!
Can someone point me towards a introduction "installing the ardupilot pre-alpha for newbies"?
NewBeez
It is zoomed out too far to see all of the data points clearly. The change in color is due to elevation changes.
Just to give you one example: the way to make things like GPS modules cheaper to users is to buy them in quantity. Let's say they cost $50 each in units of $1,000. That's $50,000 of up-front costs, just for one component. You can see how this quickly becomes very expensive. The only way we can do this is to have a very rich benefactor who is going to give us a few million dollars (good luck), or to run the operation like a proper company (minus the intellectual property right protection, since we're open source and give all the IP away.)
We're one of an emerging class of open source hardware companies (like MakerBot or AdaFruit) who all operate the same way. Open source software can be free to all. Open source hardware cannot, because the components have real costs that must be paid for. Instead, we "give away the bits and sell the atoms", charging just enough over cost to ensure that we can continue to keep the component and product pipeline full and avoid running out of stock of stuff and making people wait too long.