Pytrack GPS API

[stefan85e]

@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):
´´´´

[andrethemac]

@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:
print(L76.gps_message('GGA')['NumberOfSV'])
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]

@andrethemac published a new version of the Library to github
https://github.com/andrethemac/L76GLNSV4

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

[stefan85e]

@andrethemac

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

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

[stefan85e]

This post is deleted!

[stefan85e]

@andrethemac

(I dont get any nr due to I done get a signal from the GPS, I have to go outside to get it)

When I do this the program keeps running:

#print(L76.gps_message('GSV'))
print(L76.gps_message('GGA'))

And when I doing this then this happens:

print(L76.gps_message('GSV'))

print(L76.gps_message('GGA'))

[andrethemac]

@stefan85e Hi Stefan
sorry for the delay. you better put the the two firsts lines following the while(true): before. you don't need to init the library every run . I'll guess it's generating the error's.
the commands stop when the timeout runs out (default aflter 180 seconds). you can change that if needed.
The timeout occurs if the gps itself can't get a fix because it can't see (enough) sattelites.
best regards

[andrethemac]

some tweaks to my library https://github.com/andrethemac/L76GLNSV4
methods returning multiple values now return them as a dict;

[stefan85e]

@andrethemac Like this?

[andrethemac]

@stefan85e yes.
maybe of interest. I have 2 pytrack board and testing them side by side I found out that 1 takes way longer to get a fix, almost double as long.
So you need to tweak the timeout parameter to get the best results for your module.
best regards

[stefan85e]

@andrethemac Okay thanks... what time are you using!?

[andrethemac]

@stefan85e I'm up to 5 minutes now (timeout=300)
when your outside you'll get a fix a lot faster

[stefan85e]

This post is deleted!

[johncaipa]

@andrethemac Hi, Is there any way to have the accuracy value of each GPS fix? when my pytrack is stationary the accuracy of each point is very different

[bmarkus]

@johncaipa said in Pytrack GPS API:

@andrethemac Hi, Is there any way to have the accuracy value of each GPS fix? when my pytrack is stationary the accuracy of each point is very different

Do you mean HDOP?

[johncaipa]

@bmarkus I am not an expert in this topic, I need to send the coordinate and accuracy as possible in my project, plus some way to detect when it is moving to send the message. If that parameter HDOP works for me, I'll keep it in mind.

[bmarkus]

@johncaipa said in Pytrack GPS API:

@bmarkus I am not an expert in this topic, I need to send the coordinate and accuracy as possible in my project, plus some way to detect when it is moving to send the message. If that parameter HDOP works for me, I'll keep it in mind.

There are no accuracy available in terms of meters. HDOP is a factor in determining the relative accuracy of a horizontal position. The smaller the DOP number, the better the geometry.

[xbolshe]

@bmarkus HDOP can be recalculated to meters. So, an accuracy is a function of HDOP.

[Alex Dew]

@Neuromystix Did you ever figure out a way to get faster fixes? Is it really just a hardware issue or is there some programming that can make it faster?

[Gijs]

I had a short discussion with someone here: https://github.com/pycom/pycom-libraries/pull/143 where they used an undocumented message ID to improve fix time. I did not yet get around to testing that, but perhaps it can help you out