RRLP update

historical

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20130403/ad0d5607/attachment.htm>