Replies to This Discussion

3D RoboticsPermalink Reply by Chris Anderson on February 13, 2011 at 12:32pm

Sorry, the store listing had the old protocol. I've updated with the new one.

• ▶ Reply

Permalink Reply by Ken on February 13, 2011 at 12:49pm

Also, I am assuming the behavior for the receiver is it starts up in binary mode, 10hz refresh at 34800 baud rate. Is that correct?

 

No. Power up is NMEA. During initialization the ArduXXX commands GPS to binary @ 10Hz.

 

 

• ▶ Reply

Permalink Reply by Rich Weaver on February 13, 2011 at 1:43pm

Ken -

I have a somewhat related question with the Mediatek.  I was trying to adapt it to the UDB red board but found the 38400 baud rate having to much % error in the serial stream from the dspic to reliably communicate with it.  I could reprogram the Mediatek baud rate lower, but was afraid if I got an inflight power glitch, I would never get the dspic to re-establish communication with the Mediatek so therefore I abandoned trying to adapt it to the UDB.

 

• ▶ Reply

Permalink Reply by Ken on February 13, 2011 at 2:51pm

Odd to get so much error on the serial lines. Did you try using good quality twisted pair? Loop the wires through a ferrite bead? Another thing that might help if you had ringing from hard driving outputs is to put 330ohm resistors (+/-, 330 is not a magic number) in series with the rx & tx wires.

 

If you lose GPS communication, you need to detect that. Failure to get a valid message (not failure to get a GPS position) for x-seconds can cause the CPU to send a baud-rate command.

 

• ▶ Reply

Permalink Reply by Ken on February 13, 2011 at 4:05pm

Another thought -- How old is your MediaTek? Is it the one with the battery on the adapter board? If so, then you have no worries, the backup will maintain not only the almanac & ephemeris data, but the baud rate and message settings.

 

Now, the problem with that board is that they are fussy. Chris Anderson recommends that you pull the battery off and says something about it improving reliability. I recently seemed to have figured out why. Maybe.

 

My testing has shown that the MediaTek comes online fairly reliably with a dead backup battery, but if it has been operating well and the power cycles, it is more likely to go into what last summer we called, "the low voltage problem." In other words, having Vbackup made the unit more likely to lock up. For obvious reasons, I started with my most-unreliable MediaTeks and converted them to auxiliary power and / or removed the backup battery on these units first. 

 

I think I have a solution, but I have only 1 virgin MediaTek left with a backup battery and it was the most reliable one. It is hard to get to lock up, but when I do get it to lock up I have found a fairly simple way to restore operation. If I could find a few MediaTek users with really fussy, easy to lock-up units, I might be able to see if my fix works on all of them. Then I'll spread the word...

 

 

 

 

 

• ▶ Reply

Permalink Reply by Rich Weaver on February 14, 2011 at 5:12pm

Thanks for your input as always Ken.  Not sure if I should keep hijacking nilbo's thread...or post a new one, let me know... but here goes...

(this is for the UDB board and not for the APM).  Since the UDB board uses the HS 16Mhz crystal option I can't change the base Fcy for hardware limitation reasons and I would also affect base software timing loops so I'm rather limited in selecting baud rate generator values and the one's I can select are either 8.5 % too high or 7% too low for the 38400 baud selection which cause the serial errors. 

 

The good news is it is an old MediaTek with the battery and sounds like it could be used without losing the lower baud setting on a power reset.  My orginal intent was to open the cheaper MediaTek gps to the UDB community however.  Since this older design is no longer supported, sounds like I could donate it to the testing your doing since it is unmodified (I did update it with newer firmware).  Let me know if you want it.

 

• ▶ Reply

Permalink Reply by Ken on February 14, 2011 at 6:06pm

Ah yes. I recall something about that somewhere on a not-so-recently accessed synapse. Inexact baud rates at certain speeds. The usual fixes are going to come up lacking. A bit of juice on the Vbackup at least, and Vcc if possible would do you some good.

 

Well, here's the fix I'm trying to see is legitimate or luck...

 

If you have a MediaTek that is exhibiting what we used to call, "the low voltage problem" -- blinking slowly, never gets lock, even outdoors, simply briefly touch a short jumper wire between ground ("GND") and enable ("EN") (top most and bottom most pads on the back side).

 

This has worked for me. But since it was my "good" GPS, maybe it is luck. My last unmodified MediaTek, on the rare times I can get it to lock up, {conditions are usually a well charged battery (been running a while), Vcc off for a few seconds}, will restart if I briefly ground enable. And, when doing that it comes back remembering its state and hot starts, so it will 3D lock in 2 or 3 or at the most 4 seconds ... indoors.

 

Somehow it seems that low Vcc, with Vbackup present, when the GPS comes out of reset causes the lockup. OTOH, when the GPS comes out of reset with an externally boosted Vcc all is well. When the GPS comes out of reset with a weak Vcc, but a strong Vbackup, even externally boosting Vcc (post reset) doesn't fix a lockup. 

 

If this proves to work, we could connect the enable wire back to the processor on any unused data line to reset the GPS at will.

 

I'm rambling. Hope it makes sense.

 

• ▶ Reply

Permalink Reply by nilbo on February 13, 2011 at 10:06pm

Hey all,

Thanks for the information! I've got everything up and running. I tossed it all into the truck and drove around, the accuracy looks great (<3 meter error). You can tell which spot I parked in :) It appears the accuracy improves with time after a lock is obtained. Is there a value I can look at to get an estimate on the error? It would be nice to know. It looks like (in the vanilla data sheet) dgps is enabled by default. Is that correct? Don't see any reason not to have it running.

 

Perhaps I should clean some of this code up and post it? For people who want to use this receiver with a Uno or similar maybe it'd be helpful to have a starting point.

 

Thanks again,

Ryan

• ▶ Reply

Permalink Reply by Ken on February 14, 2011 at 7:01pm

Yes, the estimate will improve a little as it runs. If you look at the number of sats receiving from (Might be easier to do in MiniGPS) you will see 3D lock when you get as few as 4 sats. These often -- but depends on conditions--are the ones right over head thus strongest signals. After a few minutes the GPS will usually find some more sats to throw into the mix.

 

The ways to tell how good your position is...

1. Look at the DOP. Depending on mode & message you are working with, you may have HDOP, VDOP, PDOP.

 

Generally, take DOP * theoretical best (3-5m with WAAS, 15m without WAAS). 95% of the time you should be less than that far off the exact location. (DOP will decrease as the number of satellites used in the solution grows.)

 

Vertical error is usually 1.5 * horizontal error.

 

2. WAAS is on by default, but is the GPS using it (can it see a provider)? There have been problems with some of the sats providing WAAS.

 

Look in the list of satellites for #51. That is the bird that provides WAAS over the US and that MediaTek seems to know about. It is stationary, unlike the regular sats which are in 12 hour orbits. If you look in MiniGPS at the locations, you will see #51 staying in place while the others slide slowly over the face of the "target." For me, in central Florida, #51 is fairly high elevation to the southwest. The further west you are, the further east 51 will be for you. Apparently it will be too low in the sky for parts of Alaska to see.

 

There was another sat (#48) covering the US/Pacific, but it began to have problems late last summer/last fall (due to an April solar flare) then it totally failed mid-December after drifting east to 93 west. I think its status now is best described as, "we have regained control. We have it parked above 93 degrees west while we work on it. We think we know what went wrong, and we will test it and move it back into place (133 degrees west or near there by early to mid-March) and let y'all know if/when it is ever working again. We hope to be able to set it active before it gets all the way to its home." 

 

When #48 got sick they activated a temporary one, #46, but the GPS may or may not know to use it. (Mine does not seem to use it.) Also, #46 is further east (98W) than #51 (107W) so it is of no help to the far, far west US (for example, Alaska).

 

So:

  #46 (PRN 133) is a backup. GPS may not know to use it.

  #48 (PRN 135) is being repaired.

  #51 (PRN 138) is working.

 

 

 

• ▶ Reply

Permalink Reply by nilbo on February 14, 2011 at 11:11pm

Thanks for the information. Looking back through the data I recorded, I am seeing between 8 and 11 sats and HDOP varies between 1.25 and 0.95 which sounds about right. I'm currently using the binary protocol, so I'm not sure if a waas bird is being used or not. I'll have to have a look.

• ▶ Reply