09-15-2013 09:13 PM - edited 09-15-2013 09:17 PM
I'm having an issue here, I started with some of the sample code and it worked good, then I tried to make it more specific to my flow and started adding argumentsd to the GPS settings but that made it much worse since the accuracy of my samplings got pretty bad, it seems like once the GPS kicks in it doesn't update the new location anymore and it stays at the last value reported by the network . I only get a few points that are right but my path is not grabbed , it seems like when the GPS kicks the fix doesn't change anymore
GPS_src->setProperty( "provider", "hybrid" ); //pick sat and/or wifi
GPS_src->setProperty( "canRunInBackground", true ); //pull stuff when screen is OFF
then I added
GPS_src->setProperty( "accuracy", 5.0 );;
GPS_src->setProperty( "fixType", "best" )
Still no diff.. what did I miss??, the initial code was doing great but junked it thinking this would be better
09-18-2013 04:03 PM
You must set the desired properties before calling startUpdates(). If called in the order you've shown your statements, the property values you've set won't be applied till the next time startUpdates() or requestUpdate() is called.
Having said that, when you set the "accuracy" property to a value > 0.0 this instructs the underlying location manager to wait until it gets a fix of 5.0m or better accuracy, regardless of the period you specified. This is a fairly stringent requirement. To get a good gps fix the device must typically be outside with a clear view of the sky. A gps fix can often be obtained inside, near a window say, but not typically with an accuracy better than 10m. It depends on how many satellites are in view, and their distribution in the sky. Did you try other accuracy values (remember to stopUpdates() set the property and then startUpdates() again)?
Also note the time to get the first fix can be long, and the accuracy of the first fixes can be poor, until the gps "gets its bearings". Once it collects a few fixes, the regularity and accuracy improve.
If you set the accuracy property to 0.0 this disables the accuracy criteria (the period will be honoured). It may be better to do this, get the position update and check the accuracy yourself. You can choose to ignore updates that don't have your desired accuracy.
09-22-2013 08:19 AM
I did realized about that setting the props before the updates, so I did try it after I made sure but still I'm having the same issue. I have a couple of other generic apps I'm using to compare the accuracy of my code and they get it right so the GPS and stuff is good on my test device . It is my code that is missing something , I'm trying to turn the updates off when the GPS option is not used to save battery. I did try starting in the GPS option and not leaving still no cigar.
I had not accuracy setting before but have not trie it with 0, tha may nbe my next try.
I see some samples where they specifically deal with the GPS (not the network)and check for available sattelites and stuff I'm just using the Geopostioning and its signals only. Do I Need to get into that extra stuff???
09-23-2013 12:19 PM - edited 09-23-2013 12:21 PM
You don't need to use the satellite data, but it can help in determining whether gps will work on the device, in a given environment. You can't always get a GPS position but you should be able to get a satellite update. The number of satellites in view and especially the number of satellites in use can give you an idea of whether you can get a position fix, whether you could expect to get one soon, and what quality you could expect (in general the more satellites, the higher the likelihood).
You could try using two QGeoPositionInfoSource instances, one set for NonSatellitePositioningMethods, and one set for SatellitePositioningMethods. Then set the responseTime property on the SatellitePositioningMethods source to limit how long it tries to get a gps fix.
If you can share some of your code I can take a look at it.
12-09-2013 01:38 PM - edited 12-10-2013 09:19 AM
I'm back to this ... I was using the QGeoPositionInfo, wired my signal to a slot that looked cool but never got it to work in the sense I never got a proper set of gps points got some start , end point and maybe one or two points in between but nothing else I tried it on a car , on foot ... maybe I was close?? ... something missing on the setProperty I'd supose, the documentation is so vague... that is what is so annoying.
so I nuked that and went back to KISS using the bps and before even start testing for accuracy the issue I have now is if the user stops the location option I want to catch that but the geolocation_request_events seems cached I pause my logging minimize my App go to Settings & stop the location services and back to the App but it doesn't catch that, still the old values either way it is only the 1st time it catches , most users will hate my guts if I ask them to restart the App for this. Is there some hidden trick for this???? e.g. catch a change on Location settings
Thanks in advance
Edit: I stuck a geolocation_stop_events(0) before reactivating it so far it seems to catch enabling/disabling the Location setting, but I'd like to pop a Toast alerting the user the Location is turned off without restarting the App.
bps_event_get_domain(event) == geolocation_get_domain() only checks the event is/isnt there not that the location is turned off
12-10-2013 09:04 AM
I can't answer your question, but if I were you, I would try a few things.
- There are a number of is_valid() functions in geolocation.h. Perhaps one will let you know something isn't right.
- BPS_API int geolocation_request_status(void) is a function that may help.
Just to be clear, when you turn location services off you still get geolocation events? I'm thinking along the lines of:
bps_event_get_domain(event) == geolocation_get_domain()
Is that true?
12-13-2013 12:13 PM
Sorry that you couldn't get the QGeoPositionInfoSource to work. I would look at your code to try to help if you can share some of it.
Regarding the bps interface, if you are trying to detect when Location Services is turned off you can determine this via a GEOLOCATION_ERROR event. When Location Services is turned off by the user you should be notified through bps_get_event(). It should provide you with a GEOLOCATION_ERROR event. Use geolocation_event_get_error_code() and check the return value. It will be GEOLOCATION_ERROR_FATAL_DISABLED when Location Services is turned off. Is this what you're doing but the GEOLOCATION_ERROR is only happening once?