FiPy vs LoPy GPS acquisition time difference.



  • I have a few FipY's and LoPy's using the PyTrack 2. I have noticed that while the LoPy's GPS acquisition time is merely seconds to a minute max, the FiPy takes over 15 minutes or more to acquire GPS. I have tested the setups side by side with clear sky and consistently see the same issue. I have even interchanged the shields to see.

    Has anyone else noticed this? Is there a workaround specific to overcome this in the FiPY? Any help will be greatly appreciated. All boards/PyTrack 2 shields have updated firmware. Should I do an RMA for the FipY's since maybe this particular batch I ordered from Pycom is deffective?

    Any help towards this will be greatly appreciated.



  • @jcaron thank you for the reply. I will test code with timestamps and report back.



  • @Reynel-Rodriguez you should start by running the same code on both, so that you can be sure this is indeed them GPS acquisition which takes longer and not something else.

    Can you connect both devices to a PC to capture output and add time stamped logs on each?

    Logging the raw output of the GNSS chip would also be interesting.

    Have you double-checked that you use the same version of the L76GNSS module? Older versions had trouble when the GNSS chip locked on something other than GPS for instance.



  • Thank you for reaching out. I Am using the L76GNSS module and just import it (from L76GNSS import L76GNSS) then just add code to read lat and lon as such:

    This is the FiPy code on main.py:

    def main(self):
    
        while True:
            self.check_LTE_attached()
            self.cleanup()
            thisdevicemgrs = self.createMGRS()
            self.read_lora()
    
    def get_gps(self):
    
        # Get the GPS Lat and Lon
        coord = l76.coordinates()
        lat, lon = coord
    
        if (lat is None) and (lon is None):
    
            lat = 0
            lon = 0
    
            pycom.rgbled(0xFF0000) # Blink Red no lock
            time.sleep(0.1)
            pycom.heartbeat(False)
            return (lat, lon)
    
        else:
    
            return(lat, lon)
    
    def createMGRS(self):
    
        lat, lon = self.get_gps()
        thisdevicemgrs = LLtoMGRS(lat, lon).encode()
        return thisdevicemgrs
    

    I follow the same approach for the LoPy4 (main.py):

    while (True):
       try:
    
        coord = l76.coordinates()
        lat, lon = coord
    
        if (lat is None) and (lon is None):
            pycom.rgbled(0x0000FF) # Blue for NO FIX
            time.sleep(0.1)
            pycom.heartbeat(False)
            lat = "0.0"
            lon = "0.0"
            #time.sleep(5)
            #pass
    
        else:
            loc = LLtoMGRS(lat, lon).encode()
    

    I receive the location updates via remote API and turn the mgrs into a kml. I get the location update for the LoPy4s in about 20 seconds to a minute while the FiPy takes up to 15 minutes or longer to update. The boards aer co-located (about 10 feet away from each other). You are referring to a jumper on the FiPy? I was under the impression the SMA connector has an internal jumper that will switch antenna selection to external if attached.

    According to this text in the documentation: "The Pytrack 2.0 X features a SMA connector that allows for the connection of an external active or passive GPS antenna. The SMA connector has an internal switch that switches the connection from the internal to the external antenna automatically upon connection of the external antenna."

    I Am using the internal GPS antenna. Hope you or anyone else is able to shed some light into the matter. Thanks in advance.



  • @Reynel-Rodriguez Can you clarify how you perform this test (i.e. relevant source code) and how you measure it?

    It seems quite weird as this should be strictly within the PyTrack GNSS chip and completely independent of the module (FiPy or LoPy).

    Is the antenna also the same? Are you using the internal antenna or an external one? If so, what model? Is the antenna jumper present on both?


Log in to reply
 

Pycom on Twitter