I was just thinking...
Has anyone looking into real-time correcting the LEA-6 (or other DIY Drones GPS) using RTCM via Internet Protocol (NTRIP). I'm assuming you would just need to have a cellular modem (or phone) on the copter connected to the internet, receiving the RTCM data and passing it along to the GPS unit. I checked the U-Blox website and it says the LEA-6 has an interface for the RTCM protocol (http://www.u-blox.com/images/downloads/Product_Docs/LEA-6N_ProductS...). Many state's now offer a real-time GNSS network via NTRIP, some are free subscriptions while others are paid subscriptions.
I'm not a programmer so I'm unsure what it would require on that end to make it work.
Here is some example code I found for .NET (http://www.sharpgis.net/post/2005/01/21/Differential-GPS-using-RTCM...)
I've been known to develop some GPS software :) Spent a couple years with it in college
A few notes on cm-level GPS.
There are basically two levels of accuracy achievable with GPS. Meter-level and centimeter-level. Meter-level accuracy relies on C/A code data and centimeter-level relies on carrier phase data. Any properly designed GPS receiver can provide meter-level accuracy under good receiving conditions by itself using the C/A code data. For centimeter accuracy you need a receiver which will process local carrier phase data in conjunction with carrier phase data from a base station.
The cm-level receiver market is much smaller than the meter-level one so these type of receivers are much more expensive. You also need a data link for the base station data so that's more hardware and on a small UAV even a little extra electronic gear can be a problem. This all assumes you have a carrier phase base station source.
Now, as pointed out, there are more and more sources of "carrier phase" (NTRIP) base station data becoming available all the time. If one is available for your area and the radio modem is small enough you are good to go. That is assuming your GPS receiver can process carrier phase data which the Ublox LEA6 does not.
Yes, it can process RTCM data and NTRIP servers may provide data in RTCM format, but it only processes CODE RTCM data, not CARRIER data. Back in the days of Selective Availability (DoD purposely degrading civilian GPS accuracy) code RTCM corrections were important as they would get the accuracy down to meter-level from a typical 60 meters or so. Now C/A code corrections do essentially nothing to improve GPS accuracy. At least for the cheap chipsets.
So if you really want cm-level accuracy you still have to pay for it one way or another. The most straightforward way is to buy a compatible GPS receiver if you have an NTRIP or similar server available. The other way which costs less in dollars, but much more in time is to spend a little more money on GPS boards with raw carrier phase data output and use software like RTKLIB to do the processing. Of course you need data link(s) and a computer also.
A couple more things to think about.
You may want cm accuracy, but do you really need it? Typically professional applications like hydrographic surveying and photogrammetry navigate with meter-level GPS and later post-process GPS data for cm-level accuracy. Small UAVs can do the same. While the potential is there to navigate much more precisely your not going to be able to fly real close to objects - except from above - because the view of the satellites will be compromised. Also in the case of flying very close to the ground or a roof of a building you will need to know the ground elevation or roof height to a high degree of accuracy. And do you really want to trust the position hold abilities of the software algorithm in the varying wind currents near an object?
If you want to use the DIYdrones software does it even currently handle cm-level resolution? I haven't been following the development lately, but for the best results some code modification will probably be necessary.
One last practical note. Code GPS processing is much more robust than carrier phase processing. When you get to the tight confines of a small UAV the electrical noise environment may be such that code processing works well enough, but carrier phase processing fails. Your exact situation can make all the difference, but in the real world this is a common problem especially on small rotorcraft. Now you're back to spending more time designing your own noise filters or spending more on the GPS receiver (anti-jamming technology).
Thanks for the great explanations!
I have a couple questions.
1. How can you tell if a GPS can handle CODE or CARRIER? (i.e. Can you show me where the LEA6 says in the specs that it can't process CARRIER? I believe you that it can't, I'm just curious where to find that information)
2. Do you know of any "less expensive" GPS receivers that can handle CARRIER data?
3. The "raw carrier phase data output" with RTKLIB sounds interesting, do you know of anyone that has this working to test out?
4. I agree with you about the need for cm-level real-time accuracy. I would be happy, for now, with post-processed data from an inexpensive CODE only GPS that is cm accurate (I didn't realize you could post-process CODE only GPS data down to cm-level accuracy!). You stated that is possible now, can you explain the steps (and software) used to post-process the data using the DIY Drones GPS?
5. I understand the electrical noise issue. I know that you can buy an expensive CARRIER processing GPS that is built into a tablet that can't get cm-level real-time accuracy unless you add on an external antenna to keep it away from the electrical noise of the tablet.
Thanks again for your responses and sharing your knowledge!
I look forward to hearing your answers (especially about post-processing the current GPS CODE data!).
1) Look at the accuracy specs. If the specs are cm-level carrier phase data is being used, if meter-level it's code only. There's a middle ground, but I'm trying to keep it fairly simple. If the GPS can do better than a meter or two it will be advertised. Look for the ability to use carrier phase RTCM messages like 18, 19, etc.
2) I seriously doubt there are any ~$100 or even ~$500 GPS boards processing carrier phase data. I don't follow the market closely anymore, but prices are probably > $1000. Just as an example you can look at the specs of say, the Magellan DG14 RTK. I have no experience with this board.
3) I've only looked at the post-processing functions of RTKLIB - with mixed results. In this forum there are posts about RTKLIB. Some searching should turn up user Anthony Wooldridge who has mentioned some success with the RTK functions.
4) This must be a misunderstanding. I didn't know you could process CODE only GPS to cm accuracy either :).
OK, re-reading the post a few times I think I see where you got this. I mentioned navigating with meter-level GPS and then post-processing to cm-level. This would be with a board like the Ublox LEA6-T. The "T" means it has raw carrier phase output. It doesn't process the carrier phase (no real time cm-level accuracy), but just dumps it to a port which can be recorded and later processed to cm-level accuracy. The hardware is cheaper (<$500) than a RTK board. The accuracy is at least as good, it's just not there in real time. You do need post-processing software which can cost quite a bit. There are free packages (like RTKLIB), but not any really user friendly ones that I know of.
In short, cm-level accuracy is doable, but requires a fair amount of money and/or knowledge. The confines of a small UAV add to the difficulties and the benefits are limited for most applications.
Thanks again for the excellent information!
Couple more questions.
1. Could you explain the "middle ground"? I don't mind if your answer is more complex, I think it will be great information to process.
Thanks for the RTKLIB info, I'll look that up in the forums.
Once again, thanks for all of the information, you have broadened my knowledge of GPS.
The "middle ground" in accuracy for GPS (decimeter-level) can be gotten to via either code or carrier or a combination of both. Differential corrections are required though.
Higher-end boards have better code range measurements and can achieve accuracies in the decimeter range with code differential. Techniques like carrier phase smoothing of the code are used if you want to look into this further. Also, decimeter-level accuracy can be achieved by using carrier phase info without "fixing" the integers in what is often called a "float" solution. The float solution starts out at meter-level accuracy and converges to cm-level over time. With no major interruptions of the differential data link a float solution might be accurate to a decimeter or two after 3 minutes and accurate to 5 cm after 10 minutes (just as an example). A fixed integer solution means the once the integers (referring to the carrier phase cycles) are fixed correctly the position accuracy goes immediately to a couple cm.
This can all be done in real time or post-processed. Post-processing will be more robust as you can analyze the data both forward and backward in time.
This is all concerning L1 receivers. Dual frequency, Glonass, etc. add better capabilities and increased cost.
At this point though we are getting away from just spending a few hundred dollars.
If you want to play around with the possibility of decimeter or centimeter accuracy with GPS and do it as cheaply as possible I'd look at some of the Ublox "T" OEM boards and a software package like RTKLIB. You might be able to pick up the hardware for ~$250 or so. Realize though that it will probably be more of a learning experience than having a perfectly functioning RTK system in a week or two.