You need to be a member of diydrones to add comments!

Join diydrones


  • I am working on SUP500 with AdruPilot (not mega). Haven't had any free time lately to work on it.

    Not sure what latency on the SUP500 is but otherwise it looks OK in the compassion SparkFun did (thanks SparkFun).

    I will post to this thread when I get some time to work on the code.

  • ups, here's the link... MediaTek GPS
  • Hi daniel,

    I think the new GPS to be supported by DIY drones is this MediaTek with adapter...

    it's really cheap and you only need the cable sold in the DIY drones store to connect it to your board
  • Sorry to get this Post up again, but i am ready to buy my ArduMEGA soon, has anyone successfully tried running the SUP500 with Ardupilot, preferably ArduMEGA? If so, is it doable for a noob like me?

  • @C Moss - Thanks... I'm really trying to get a grasp on how consumer-grade GPS chips currently process the signals. One thing that I've noticed is that consumer-grade chips never talk about latency... how much the "current" reading lags. For example, the Ashtech G12 (commercial-grade) has a published 50ms lag, and even includes position latency output (see spec sheet)! By the same token, consumer-grade GPS chips tend to have anywhere from 300msec latency to a full 2 secs!

    Thus, if your drone is flying at 100mph, the GPS output will lag by 44' (at 300ms) at best, or 292 feet at worst! If you're banking in a turn, it gets even worse since the computed vector no longer resembles your flight path. It is for that reason that I stress the necessity for integrating GPS latency into the kalman filter computations, so that a true bearing correlation is derived (see paper).
  • @C Moss - Can you give us an example, from manufacturer literature, confirming what you just said? It's easy to speculate, but I'd rather have the facts.
  • Theoretically it can lock from cold faster.

    For any given satellite signal, multiple receiver channels can be attempting to align their locally generated despreading codes with the receive signal in parallel. As long as these locally generated despreading codes have different alignments, a lock (despeading code aligned with received spreading code) will be achieved faster.

    Beyond locking from cold and warm faster, there's probably not a lot of difference to more modestly endowed GPS receivers.

  • T3
    IMO 65 channels is still useful.
    Imagine what happens when almanach has 24 positions in memory and you turn on the GPS and it sees a fresh 11 sats. It is not sure which are what so it puts the data incoming into the empty slots. This requires up to 35 slots. Progressively as the data is complete the results from different processing pipes are merged into one updated processing channel and spare pipes are liberated.
    This is my theory why it should be beneficial: faster time to 1st lock in some cases, or faster recovery from total lockout.
  • Its marketing.
    Hoping most people will see that 65 is bigger than 30, and bigger must be better. But as I understand and so do you. There are only 24 in orbit and most of the time at least 1/2 of those are on the wrong side of the earth (out of view).

  • Can someone explain what is the purpose of having 65 channels on a GPS receive, while there are only 24 GPS satellites?
This reply was deleted.