Update GPS via WiFi

[Dutchman]

After intensive testing, the following changes have been made to the 'Home'-function and subroutine in the attached files:
- timer threshold reduced to 500msec.
- comparison on validity changed from AND to OR-function
- added variable 'valid' for easy testing on valid GPSdata

It takes several seconds (iPad-1) before GPSvalidity changes after switching WiFi ON or OFF in device-settings.

I tried to change the variables x,y and z in the function 'GET GPS' to GPSx, GPSy and GPSz
but that resulted in 0,0,0 as output.
Is that a bug, or am I mistaking?

time-threshold increased to 3000msec. on 08 Dec 2013, 19:50
Subroutine adapted according to reply on 09 Dec 2013, 13:21

[Mr. Kibernetik]

What does not work in your program?

Several comments:
1. 500 ms may be too short for GPS to turn on and get valid result.
2. It is not a good idea to turn on and off GPS very often - turning it off really stops it, and it may requite extra time to get new data in next cycle after turning it on. GPS is quite slow in starting. Proper usage is to turn it on in the beginning and then get all data. It is even not necessary turn it off in the end because it is automatically turned off when program stops. You should turn it off if you don't want more GPS data, and if your program continues to run.
3. In your function "Home", GPS is turned off only if GPS data received. But absence of GPS data does not mean that GPS did not start.

[Dutchman]

Thanks for your remarks and advice.
I increased the time-threshold to 3000msec. That is 10 times the value at which it operated properly on my iPad

However the SET GPS OFF command has to stay
That is why It took me days rather than hours to design these commands.
Otherwise the GPS stops operating after 3 calls.
I did the following changes in 'HomeGPS-Sub':
HomeGPS-Sub.txt adapted:
1. TEXT CLEAR removed, so all output remains on screen
2. SET GPS OFF removed, according to your proposal
3. time threshold is increased to 3000 msec
That gave the following result:

Code: Select all

Latitude     Longitude    Altitude
--------     ---------    --------
 51.3652      5.25504      26.9689 
n= 1 
Latitude     Longitude    Altitude
--------     ---------    --------
 51.3652      5.25503      27.123 
n= 2 
Latitude     Longitude    Altitude
--------     ---------    --------
 51.3652      5.25503      27.1712 
n= 3 
Latitude     Longitude    Altitude
--------     ---------    --------
-1           -1           -1 
NO GPS available.

Note that it stops after 3 calls. I get the same result with the function-version.

The major reason why it took so much time, is given in the question

I tried to change the variables x,y and z in the function 'GET GPS' to GPSx, GPSy and GPSz
but that resulted in 0,0,0 as output.
Is that a bug, or am I mistaking?

It is illustrated if you run the following code.
It is the code from 'HomeGPS-Sub' in which the variables x,y and z are replaced by GPSx, GPSy, GPSz

Code: Select all

'HomeGPS subroutine with x,y,z replaced by GPSx,GPSy,GPSz
' by Dutchman, december 2013
TIMER RESET
n=0
Do
GOSUB HomeGPS
n=n+1
TEXT CLEAR
PRINT "Latitude","Longitude","Altitude"
PRINT "--------","---------","--------"
PRINT GPSx,GPSy,GPSz
IF NOT GPSvalid THEN
  PRINT "NO GPS available."!END
ENDIF
PRINT "n=";n
UNTIL n>9
PRINT "Finished in";TIMER()/1000;"sec"
END
'
'==== S U B R O U T I N E 
HomeGPS:
time=TIMER() ! SET GPS ON
GPSx=0!GPSy=0!GPSz=0!GPSvalid=0
WHILE x<=0 OR y<=0 OR z<=0
  GET GPS LAT GPSx LON GPSy ALT GPSz
  IF (TIMER()-time)>3000 THEN Exit
END WHILE ! SET GPS OFF ! GPSvalid=1
Exit:
RETURN

On my iPad the result was: "NO GPS available."
It turned out that the returned values were 0,0,0 rather than -1,-1,-1, if GPSx etc were not initiated to zero.
In the above code GPSx etc are initiated to 0. Then the result is -1,-1,-1
So I suppose that the GPS is operating but the values are not written to the 'idle' variables which were set to zero at program start or in the beginning of the subroutine.

It took me a lot of time, but with fun
If i changed it back to x, y and z, than I got proper results

[Dalede]

When using WiFi to simulate GPS it is ok I think for it to stop after 3 tries but your mileage may vary. It is not going to continue to update with any new data since the WiFi router location is fixed. If you move the device throughout your house it will be the same. This location data is simulated without a real GPS (I use a Bluetooth GPS with my WiFi iPad). As you have found it does not accurately duplicate a real GPS is is intended for location based services.

-1 and -1 and -1 are actually all legal values for lat, lon, and altitude. Any values could be used and the GPS simulation will typically provide 0,0,0 I think.

Dale

[Mr. Kibernetik]

1. When GPS returns -1 -1 -1 this means that no new data is available. For this reason GPS_COUNT() function exists. Actually, there is no sense to call GET GPS if GPS_COUNT() is zero, because it will anyway return -1 -1 -1. GPS_COUNT() function returns number of new GPS data awaiting to be read.

2. In your code there is:
WHILE x<=0 OR y<=0 OR z<=0
GET GPS LAT GPSx LON GPSy ALT GPSz

note your x, y and z variables here - they are left from older version.

[Mr. Kibernetik]

It turned out that the returned values were 0,0,0 rather than -1,-1,-1, if GPSx etc were not initiated to zero.
In the above code GPSx etc are initiated to 0. Then the result is -1,-1,-1

I cannot confirm that. In my tests I always get -1 -1 -1.
Can you please post an example when you get 0 0 0 after GET GPS?

[Dutchman]

Your remark on 09 Dec 2013, 12:19

note your x, y and z variables here - they are left from older version.

was indeed the error.
I am completely embarrassed. Sorry.
Regarding your request:

Can you please post an example when you get 0 0 0 after GET GPS?

No, I don't want to give that, because that was even more embarrassing
Thank you for your help.
I admire your ideas about the coming sprites.

I corrected the subroutine in the attached file in the original post of 08 Dec 2013