PyTrack GPS Lock

[pymiom]

Hi All,

I have been doing some testing with the PyTrack, but the ability to get a strong signal with GPS is sometimes not the best, but when it works in a location with direct line of sight to the sky it is great. As soon as I move it slightly to a windowsill or inside a car, the ability to get co-ords is difficult.

With how it is working now I could only really use this outside of a case, and it has to have that clear line of sight - this doesn't make it very useful. I have a cheap GPS tracker hidden inside my car with no line of sight to the sky, and this can get my location super accurate and quickly.

I see there are some cases to house an expansion board, but I cant see them working too well with how my PyTrack is behaving. I have seen posts asking for the ability to add an external antenna, this would help immensely.

Has anyone else had similar experience?

Cheers

[peekay123]

@pymiom, while waiting for LTE-M1 in Canada (I fear my FiPy will be obsolete by then!) I decided to test it with the PyTrack board I bought at the same time. My workshop is in the basement with only a small window at ground level. I am also working on other GPS projects (using UBlox NEO-M8Q) so I decided to get a cheap USB powered GPS signal repeater on Aliexpress. This allows me to get a very good lock indoors.

The FiPy/PyTrack has been running for a couple of weeks now.

[pymiom]

Thanks @peekay123 !

That seems very different to what I am seeing. Is anyone aware of any diagnostics I could run? Could it potentially be an issue with the firmware on the device?

Thanks

Michael

[crumble]

@pymiom said in PyTrack GPS Lock:

Has anyone else had similar experience?

I have no problem with mine in the case for the expansion board. Inside it needs a long time for a fix, but it get a fix where other devices will not get one.

Do you use a plain *Py/pytrack combination or have you added other parts which may reduce the signal quality or drain to much power?

[peekay123]

@pymiom, note that I modified the GPS library to decode different messages. Nonetheless, the ability to lock is independent of that.

[pymiom]

Hello,

Thanks for the advice so far :)

I just have a deep sleep board in between the two but I believe this may not be needed after reading some other posts.

When I am back with the board in the next few days I will give it another try.

Thanks!

[jinjiro]

@pymiom I'm using a SiPy with the PyTrack and my experience so far is similar.
I'm using firmware 1.17.3.b1 on the SiPy and 0.0.8 for the PyTrack which seem to be the most recent for both.

Indoors I find that it is difficult te get a fix, even when placing the board near a window.

Perhaps my code is not good enough to get a quicker/better fix.

This is what I use in main.py:

import machine
import math
import network
import os
import time
import utime
import socket
import struct
from network import Sigfox
from machine import RTC
from machine import SD
from machine import Timer
from L76GNSS import L76GNSS
from pytrack import Pytrack

# setup as a station
import gc

time.sleep(2)
gc.enable()
init_timer = time.time()

# setup rtc
rtc = machine.RTC()
rtc.ntp_sync("pool.ntp.org")
utime.sleep_ms(750)
print('\nRTC Set from NTP to UTC:', rtc.now())
utime.timezone(7200)
print('Adjusted from UTC to EST timezone', utime.localtime(), '\n')
py = Pytrack()
l76 = L76GNSS(py, timeout=30)
chrono = Timer.Chrono()
chrono.start()
sd = SD()
os.mount(sd, '/sd')
f = open('/sd/gps-record.txt', 'w')

while(True):
    # time-counter configurations
    final_timer = time.time()
    diff = final_timer - init_timer
    # save the coordinates in a new variable
    coord = l76.coordinates()
    #coord = (43.345543, 7.890123)  # test coords instead of waiting for fix
    # verify the coordinates received
    if coord == (None, None):
        print("Getting Location...")
        continue
    # SigFox time wait (max 1 msg/10 mins)
    # diff <= 600 takes 10 min approximately to send the next message. Use 10 for testing.
    if diff <= 10 and coord != (None, None):
        print("Waiting to send the next Sigfox message")
        continue
    # write coords to sd card
    f.write("{} - {}\n".format(coord, rtc.now()))  # save coords SD card
    # send the Coordinates to Sigfox
    s.send(struct.pack("<f", float(coord[0])) + struct.pack("<f", float(coord[1])))
    print(struct.pack("<f", float(coord[0])) + struct.pack("<f", float(coord[1])))  # temp to see what s.send transmits
    print("Coordinates sent -> lat: " + str(coord[0]) + ", lng: " + str(coord[1]))
    # reset the timer
    time.sleep(5)
    init_timer = final_timer

[pymiom]

Hey @jinjiro ,

My code is more or less the same as yours (excluding the SD card write)!!

Like you, I am only wanting to send the coordinates to sigfox...

Does anyone have any feedback on the code, or can see any issues with it?

Thanks

[jinjiro]

It would also help if someone knows how to make the current status more visible, more verbose.

Why are the coords stuck on "none, none" for so long, is it because of the weak signal strength, how many sats did it find (none, or 2 or just waiting on the last one).

I'm learning as I go and my skills in python are not quite there yet, any help is very much appreciated.

[agmatthews]

@jinjiro @pymiom Have a look at https://forum.pycom.io/topic/2992/pytrack-gps-library-only-works-with-glonass-derived-positions
It may be that the reason that you see (None, None) is the L76GNSS library is not decoding GPS only sentences (ie it does not decode GPS fixes without GLONASS)

[jinjiro]

@agmatthews Thx for posting, I've changed the line to GPGLL but unfortunately it did not make a difference here compared to GNGLL. Still stuck on (None, None) for a long time. I replaced GNGLL for GPGLL, maybe that's not correct?

On the topic of using micropyGPS, it is a rather large lib (29kb compared to the L76 is 3kb, and yes I know it is not as complete but still) and I get a "MemoryError: memory allocation failed, allocating 342 bytes" on my SiPy board.

Do you use micropyGPS on a SiPy or on a different Pycom?

[jinjiro]

update: The idea of using micropyGPS as a "frozen module" is interesting and a little more advanced than my current level ...

Found this page specifically for the Pycom SiPy (but I assume it works for all Pycom boards): https://mjuenema.github.io/iot/pycom_sipy_sigfox/firmware_upgrade/

[robert-hh]

@jinjiro If you get the memory error during import, you can try to precompile the module with mpy-cross. I have a pre-built version here: https://github.com/robert-hh/Shared-Stuff/blob/master/mpy-cross_pycom.exe or here https://github.com/robert-hh/Shared-Stuff/blob/master/mpy-cross_pycom_linux
Sorry, no OS X version. These tools create a .mpy file out of a .py file, which can be import like the .py file.
@seb: How about providind precomiled versions of mpy-cross at least for Windows and OS X. The Linux folks should be able to handle that themselves.

[jinjiro]

@robert-hh Thx, work kept me a bit busy but found some time to play today.

I went the micropyGPS frozen module route. I've been running into issue after issue trying to get the dev environment up on OSX. So had to deploy a ubuntu box with all the tools first and flashed the new firmware from there.

Preliminary tests show that the frozen module and the code works. Obtaining a GPS lock indoors not really yet however I need to look into it further. At least now I have more data/cmds to start troubleshooting.

I have a Pi Zero with attached GPS module, 3G dongle and external GPS antenna which gets a GPS lock indoors fairly quickly and is using 3G to transmit coords so that's my benchmark. My goal is to downsize this tracker to sipy-pytrack-sigfox.

Thx all for the pointers and support.