RRLP update

A quick update ahead of some full blown documentation on my blog. 1. You need to set your GPS seed position: The GPS positioning signal has a period of 1 ms, corresponding to a distance of about 300 km. This means that there are many potential solutions for the GPS positioning equations in an irregular lattice around the Earth. If the GPS receiver does not know its true position within about 200 km, it must check all of these potential solutions in a brute force search before making a reliable position estimate, a process that can take 20 minutes or longer. To avoid this delay, the GPS receiver requires a seed position within 200 km of its true location: config GSM.RRLP.SEED.ALTITUDE xx config GSM.RRLP.SEED.LATITUDE xx.xxxxxx config GSM.RRLP.SEED.LONGITUDE xx.xxxxxx Note: You can find your own latitude, longitude and altitude (in meters) for the seeds here: http://veloroutes.org/elevation 2. Make sure your server time is correct: Current time must be known to within a few seconds to make rough estimates of satellite position and bootstrap the positioning calculations. Like seed position, rough time can determined through a brute-force search, but that is very time-consuming. With OpenBTS the rough current time comes from the time-of-day clock on the machine running the RRLP server. 3. There are 4 OpenBTS configuration options which determine when a RRLP query is performed: e.g. during call setup, during call teardown, during a Location Update Request (LUR) or during a SMS: config Control.Call.QueryRRLP.Early 1 config Control.Call.QueryRRLP.Late 1 config Control.LUR.QueryRRLP 1 config Control.SMS.QueryRRLP 1 QueryIMEI determines if the MS is checked to see if it supports RRLP: config Control.LUR.QueryIMEI 1 4. A common problem as widely reported and also obsered by myself is: range error=ephemURA of xx.0 (xx) doesn't fit in (0,15) In RRLPServer.cpp this causes method transact to return early without as MS location being determined (and table RRLP being written to). This error is output in roundAndCheck at line 912 in rrlpserver.erl URA stands for User Range Accuracy. The URA index defined bounds are -16 to 15. The valid range for ephemURA data is defined in the ephemeris Adjustment Table that is used for Ephemeris corrections, scaling, etc at line 1164 in rrlpserver.erl e.g. 0-15. The adjustment table defines: Correction, Scale, Min, Max I suspect that the problem is that a negative number is being returned in the GPS ephemeris data e.g. in ftp://ftp.trimble.com/pub/eph/CurRnxN.nav - at the very least the correct URA bounds are -16 to 15 rather than 0 to 15. My hack (for now) is: {"ephemURA", [0, 0, -16, 256]}, I'll carry on trying to get to the bottom of this error and fix it properly. Regards Craig