Pytrack GPS API

  • This post is deleted!

  • @andrethemac

    The program stop after 180 sec and if I do this:

    #print(L76.coordinates(debug=True)) it will not do anything :)


  • @andrethemac published a new version of the Library to github

    If you find some errors or have a request, please ask.
    best regards

  • @stefan85e The timeout is to prevent the library to wait for ever. 180 seconds (3 minutes) is (for me) most of the time enough to get a fixed location. (that is after a cold start)
    the GGA sentences contains the number of messages seen by the GPS, In the dict that GGA returns, this is the "NumberOfSV' fied.
    with this you get this number -> L76.gps_message('GGA')['NumberOfSV']
    In your screenshot the line that prints the number of satellites has scrolled out of view
    but if you make this line the last you get the number:
    or remove the 'debug=True) from the coordinates line (the debug spews out a lot of information)
    I'm still working on the library to make it faster
    best regards

  • @andrethemac


    Got this

    I see that you have a 180 timeout in the code:

    -> L76GNSV4 - So how do I know how many sattelites i have then :) just so I look at right nr :)

    def init(self, pytrack=None, sda='P22', scl='P21', timeout=180,debug=False):

  • @stefan85e An example on how to get the number of satelites with my library

    from pytrack import Pytrack
    from L76GNSV4 import L76GNSS
    py = Pytrack()
    L76 = L76GNSS(pytrack=py)
    print("test L76")
    # returns the info about sattelites in view at this moment
    # even without the gps being fixed
    # returns the number of sattelites in view at this moment
    # even without the gps being fixed
    # returns the coordinates
    # with debug true you see the messages parsed by the 
    # library until you get a the gps is fixed

  • @stefan85e If you are using my code (and just my code, not the one from @andrethemac), when you call gps_data = l76.coordinates1() it will return a list gps_data with latitude at first position (gps_data[0]), longitude at second (gps_data[1]), and so on till the sixth position where you get the number of satellites (gps_data[5]). So, number_of_satellites = gps_data[5].

  • @neuromystix said in Pytrack GPS API:


    Does this work:

    return(lat_d, lon_d, gps_time, gps_altitude, valid, num_satellites)

    I want num_satellites...

  • @andrethemac
    (2018, 4, 17, 11, 29, 12, 564887, None)(None(53.33632, 12.53262)
    (None, None) Got when I add this:

    gps_data = l76.coordinates1()
    n_sat = gps_data[5]

    Did also try to use this lib:

  • @stefan85e Hello,

    You have to do something like this inside your code, and you'll get the number of satellites used for fix:

    gps_data = l76.coordinates1()
    n_sat = gps_data[5]

    Or you can use the @andrethemac library which will get you all the data ;)

  • @neuromystix said in Pytrack GPS API:

    For use it just call l76.coordinates1() which will return (lat, long, time(not formatted), altitude (M), valid fix (true ou false), number of satellites).
    So what did you do to get the nimber of satellites? We are trying this and we cant get it to work.

  • Hi all. I've taken the original librarya and @Neuromystix addtions and made my own library. It parses aml the sentences from the L76 gps and returns them as a dict. you can get the coordinates parsed, the time, ...

    I've noticed one (strange?) thing. the RMC (required minimum data to get a fix) message only pass once (just after starting the gps) and does not reappear. Any idea's ?
    best regards

  • @neuromystix said in Pytrack GPS API:


    Sorry did not udnerstand that :)

  • @stefan85e If you need the number of satellites used to fix, it's already parsed in l76.coordinates1(). The "Satellites in view" i haven't done it, but it's easy to implement, just parse any $__GSV sentence, the third field is "Satellites in view".

  • @bmarkus said in Pytrack GPS API:

    umber of satellites visible /used for fi

    • number of satellites visible /used for fix - Is this possible yet?!

  • @mwtidd When i wrote it i was reading the "Quectel l76 Series GNSS protocol Specification V3.3" which says (@page 12):
    Fix Status
    "1"=GNSS fix
    "2"=DGPS fix
    "6"=Estimated (dead reckoning) mode

    That's why i only used "1". But even with that, we can use the value "2" for the DGPS fix. I haven´t checked if i had some fixes "2" ou another values. If it worked for you, nice ;)

    Best regards
    Nelson Pinto

  • @neuromystix your work has been awesome. Thank you so much for your efforts. In running some test logs earlier today, I found that I got a series of fixes logged that were "invalid". Upon reviewing you code the protocol documents, I have one update to propose

    def _fix_quality(self, gngga_s):
        valid = gngga_s[6]
        if valid == '0':
            return False
            return True

    Your initial fix quality function only returned true if gngga_s[6] was 1, however it seems that values such as 2 or 3 may be valid as well.

    Per v2.2 of the protocol spec:

    Value Description
    0 Fix not available or invalid
    1 GPS SPS Mode, fix valid
    2 Differential GPS, SPS Mode, fix valid
    3 GPS PPS Mode, fix valid

    Once again, thanks for your efforts. Just wanted to share my findings.

  • @neuromystix Works like a champ - it would be good if this was added to the main lib. I added HDOP (GPGGA) as that is a good indication of accuracy.

  • @andrethemac i followed the original lib which use gc to clean memory. But haven't tried any other options.
    Same problem here with the starting time. Sometimes i just unplug the cable from my computer and plug it to a powerbank and have to wait 5 minutes for it to get fix. For my project this will not be a problem but for a battery operated device it's not a good thing...

  • @neuromystix I used to search the nmea messages with _read looking for xxGGA until a fix was found. Only then I use the l76.coordinates to find the exact position.
    a bit of a work around.
    The new library you posted works as a charm, no more memory errors.
    The Quectel is a bit "slow" but with a timeout of 180 (3 minutes), I manage to get a fix (almost) every time the wipy/lopy comes awake (after deep sleep). Not so good for the battery, 3 minutes on +- 70 mA vs 390 uA in deep sleep with the pytrack. The 390 uA are probably from the accelerator, I use the accelerator to wake up the unit when it gets more than 2g for over a second.


Pycom on Twitter