referring to fig1 , a first embodiment comprises a gps receiver 10 , a communications subsystem 11 and a host platform 12 . it may optionally also comprise a motion sensor 13 and net assist subsystem 14 . the device may be monitored and controlled remotely from a control system 15 via which end - users 16 may interact with the device . the device also has its own power supply 17 which is arranged to power each of the subsystems ( connections not shown ). in an on / off mode , the gps receiver 10 has no control whatsoever as to when it is turned on , and can only inform the host platform 12 when it wishes to be turned off . the gps receiver is therefore completely reliant on the host platform carrying out the requests it is given to power down the gps receiver . the requests are made by made by means of a simple signalling protocol ( for example by means of a standard nmea 0183 message , output at 1 hz ( the nmea 0183 interface standard defines electrical signal requirements , data transmission protocol , and time , and specific sentence formats for a serial data bus )) which simply informs the host whether the gps receiver should remain on or off . the reason for introducing the on / off mode of operation is as a means of power management . that is , when the gps receiver is not required to provide fixes continuously , the on / off mode of operation maybe employed to extend the battery life . it must be recognised that the power required ( on average ) for the gps receiver to generate a fix in a given scenario is essentially predetermined . a power management method , is used to make a trade - off between battery life and availability of positional information . at the two extremes , the method could be such that either for a given required availability the battery life is maximised or for a given required battery life the availability is maximised . however it would not generally be acceptable for the gps receiver to operate such that its required battery life was satisfied if , as a consequence , the receiver never generated any valid fixes . therefore the control method must , in some cases , be prepared to sacrifice battery life in order to improve availability . furthermore the gps receiver cannot predict in advance how long it will take to generate a valid fix at any given time , not least because it has no useful knowledge of the details of the environment . furthermore , that scenario will change with time : the gps receiver might , for example , be started in an indoor car park , then moved outdoors , then moved into a brick building , etc . referring now to fig2 , configuration of the on / off method is based upon settings of five parameters 22 a : the expected interval between fixes ( expinterv ), a time interval measured in integer seconds for example in the range 60 seconds ( 1 minute ) and 3600 seconds ( 1 hour ), but the range may be varied according to need . a value of 0 may be used to disable the on / off mode ( i . e . to revert to a continuous mode of operation ). for relatively long intervals ( for example over an hour ) the host platform may choose when to turn the gps receiver off , rather than rely on the on / off mode . the expected usage ( expusage ), as a percentage . this is the percentage of the time that the host expects to be turning the gps receiver on at the specified intervals . so , for example , if the gps receiver is expected to be used in the on / off mode during an 8 hour working shift , but is expected to remain off outside of that time , the expected usage would be 33 %, regardless of the expected interval between fixes . the expected life of the battery ( explife ), in integer minutes . this is the period of time that the battery would be expected to last if the gps receiver were operated continuously . note that this can refer to a hypothetical , or virtual , battery . however , this is perhaps best thought of as being the expected life assuming the battery is fully charged . the minimum required operational period of the gps receiver ( minreqlife ), in integer minutes . although this is not essential , it is suggested that this is thought of as being the minimum required operational period assuming the battery is fully charged . the net assist mode is a parameter which tells the gps receiver whether to expect net assist position and / or ephemeris input . the relevance of this is that , for example , it would clearly be an unnecessary expenditure of power for the gps receiver to remain on in order to try to decode ephemeris data if this same ephemeris data were likely to be provided by net assist . the gps receiver uses the first four of the above parameters to compute the total number of times it is expected to be required to generate a fix ( numon ), and the average period of time it is allowed to be on in order to generate these fixes ( avontime ). these two parameters are computed as follows ( noting that the software uses integer maths routines ). where numon is dimensionless , the constant 60 is used because minreqlife is in units of minutes but expinterv is in seconds , and the constant 100 is used because expusage is a percentage . where avontime is in units of seconds , the constant 60 is used because explife is in units of minutes , and a constant , 1 , is introduced to allow a short time between the gps receiver indicating that it wishes to be turned off and the host platform actually turning it off . the value of the constant may be varied as would be apparent to the skilled person . the control method essentially performs a cost / benefit analysis 23 , 24 to determine the duration of the time intervals during which the gps receiver will be turned on 25 . that is , at every update it looks ahead and computes estimates of the benefit of remaining switched on for various periods of time . it then estimates a cost for each of these periods of time . if the benefit is ever greater than , or equal to , the cost , the gps receiver will choose to remain switched on . otherwise , it will send a message to the host platform to turn the gps receiver off . during operation the gps receiver keeps track of the amount of credit or debt relative to the average period of time it is allowed to be on in order to generate fixes , since it was last configured . this means that the gps receiver is preferably re - configured each time the battery is recharged . so , for example , if avontime were 30 seconds , and a first attempt at generating a valid fix took 45 seconds , then the method would be in debt by 15 seconds . if a second attempt took 60 seconds , the algorithm would then be in debt by 45 seconds . however , if a third attempt took only 15 seconds , the debt would reduce to 30 seconds . the method keeps track of its current state by saving data to non - volatile memory just before sending the message to the host that it wants to be turned off . the data saved may comprise the five configuration parameters noted above , the number of consecutive failures to fix ( for use in computing the benefit of staying on ) and the current credit / debit balance . the benefit of remaining on is made up of two components . firstly , there is a benefit in terms of being able to generate a valid fix . clearly , the whole point of turning the gps receiver on is for it to generate a valid fix , so there is a benefit in remaining on long enough for this to be achieved . however , in addition to the benefit for the current period , there might be a benefit for future fixes . for example , if the gps receiver has no position data already stored in non - volatile memory then it has to perform a cold start . so the benefit of generating a valid fix in this case can be considered as being greater than if the gps receiver were in a position to perform warm starts , because generating a valid fix during a current period will aid the ability to generate fixes in the future . the second component of the benefit is in terms of being able to decode ephemerides , which can be used to aid future fixes . a more detailed explanation of these two components is given below . in computing the benefit in staying on for a given period of time so as to generate a valid fix , two elements are considered . firstly there is the question of what the benefit is of generating a valid fix ; secondly there is the question of the probability that a valid fix will be generated within the given time . a measure of the benefit of staying on for x seconds in order to generate a valid fix [ denoted posbenefit ( x )] is given by the product of the benefit of generating a valid fix [ denoted posbenefit ( valid )] and the probability of generating a valid fix in x seconds [ denoted probability ( x )] expressed as a percentage , divided by 100 . that is benefit of generating a valid fix [ i . e . posbenefit ( valid )] is defined as follows : if there is no previous position available from non - volatile memory , the benefit is defined to be a relatively high predetermined value ( for example 58 units ). if the position in non - volatile memory is considered good enough to allow a warm start , but is not good enough to be able to resolve millisecond pseudo - range ambiguities , the benefit is taken as a simple ( e . g . linear ) function of the expected interval between fixes , with a given range ( for example a maximum value of 48 units ( for a very small value of expinterv ) and a minimum value of 0 units ( for a value of expinterv of 30 minutes )). otherwise , the benefit is defined to be a relatively low - to - middle value ( for example 12 units ). note , however , that if as part of the configuration of the algorithm the gps receiver has received an indication that net assist position input is available , then this is treated as being the equivalent to there being a ‘ good ’ position already in non - volatile ( i . e . the benefit is defined to be 12 units ), there being no benefit for future fixes in expending power generating a valid fix during the current period if the gps receiver is going to be given a net assist position anyway . the benefit may be increased if the gps receiver was unable to generate a valid fix during its previous attempt . this increase is a function of the number of consecutive failures to fix immediately preceding the current attempt , expressed as a percentage of the total number of fixes it is expected to be required to generate ( i . e . expressed as a percentage of numon ). by way of example an increase of 5 units for every 0 . 1 % may be applied . so , for example , if numon were 1000 , 5 units would be added to the benefit for every preceding failure to fix . the probability of generating a valid fix in a given period of time is computed in two steps . firstly , the minimum and maximum period of time the gps receiver might have to stay on in order to have a ‘ reasonable ’ expectation of being able to generate a valid fix is computed . ( it is important to note that these two parameters do not have an exact definition . furthermore , their method of computation is far from exact and a number of suitable methods might be determined by empirical means .) however , the basic principle is that the method determines what additional information is needed in order to be able to compute a valid fix ( e . g . waiting 2 more seconds for the position status to be elevated to ‘ valid ’, or waiting until an extra 3 satellites are acquired and pseudo - ranges generated ), and then tries to predict how long it might take to acquire this additional information . to do this , it looks at each channel , and attempts to estimate the time required , firstly to acquire a satellite on that channel ( responsive , for example , to the time remaining for the current search ) and secondly how long it might take to decode an ephemeris for that satellite ( responsive , for example , to the signal - to - noise ratio ( snr ) of the signal if a satellite has already been acquired , and which navigation data sub - frames have already been decoded ). the second step in computing the probability of generating a valid fix in a given period of time involves interpolating between the above - computed minimum and maximum time periods . the basis of this is that the probability of generating a valid fix in the minimum time is assumed to be relatively low ( for example 10 %), and the probability of generating a valid fix in the maximum time is relatively high ( for example 100 %, though in reality a probability of 100 % is usually far from the case ). the probability ( expressed as a percentage ) of generating a valid fix in x seconds is then estimated as follows . if x & lt ; minimum , probability ( x )= 0 if x ≧ maximum , probability ( x )= 100 otherwise , probability ( x )= a function of ‘ minimum ’ and ‘ maximum ’ ( for example , 10 + 90 *( x − minimum )/( maximum − minimum ) if , as part of the configuration of the algorithm , the gps receiver has been told to expect net assist ephemeris input , then the benefit of remaining on in order to decode ephemerides is defined as being zero . otherwise , the benefit , in terms of decoding additional ephemerides , of remaining on for another x seconds is computed in three steps . firstly , for each channel on which a satellite has already been acquired but for which no ephemeris has been determined , the minimum and maximum period of time the receiver might have to stay on in order to have a ‘ reasonable ’ expectation of decoding the ephemeris are computed . it is important to note that these two parameters do not have a precise definition . these are computed as follows . if the snr is less than a given first threshold ( for example 20 dbhz ) it is assumed that it will not be possible to decode an ephemeris . otherwise , the minimum time is defined as being the time until the end of the last sub - frame required to complete the set will be received . if the snr is above a given second threshold ( for example 32 dbhz ), the maximum time is defined as being the same as the minimum time . otherwise , if the snr is above a third threshold ( for example 25 dbhz ), the maximum time is defined as being 30 seconds greater than the minimum time . otherwise ( i . e . if the snr is 21 dbhz or above ), the maximum time is defined as being 60 seconds greater than the minimum time . the second step is to compute the number of ephemerides we might ‘ expect ’ to decode within x seconds . the method for doing this is explained by means of the following pseudo - code , noting that the software uses integer maths routines : for ( chan = 1 .. total number of channels ) the third step is to define the benefit as being 1 unit for each ephemeris ‘ expected ’ if we already have 6 or more ephemerides available , or 2 units for each ephemeris ‘ expected ’ if we have fewer than 6 ephemerides available . this then gives us the benefit of staying on for x seconds in order to decode more ephemerides [( denoted ephbenefit ( x )]. the cost of staying on for x seconds is computed in a number of steps . firstly the component of the cost based just on the total time the gps receiver will have been on during the current period is computed , as follows . where time_on is the time we have currently been on during the current period . that is ( time_on + x ) is the total time the gps receiver will have been on in x seconds . the cost is inflated if the total time on will be more than a predetermined factor ( for example 3 . 75 ) times the average period of time it is allowed to be on , as follows : so , if , for example , avontime is 30 seconds , then the cost for various times on will be as follows : the next step is to decrease the cost if the gps receiver is within a few seconds of turning off . the reason for this is that it is undesirable to leave the receiver on for some time , only to turn it off a few seconds before getting a fix . then , if the gps receiver is currently in credit , the cost is reduced by a predetermined amount ( for example 5 units ). alternatively , if the gps receiver is currently in debt by more than some amount ( for example 1 . 25 % of the expected life of the battery ( i . e . 1 . 25 % of explife , or , as an example , 3 minutes if the expected life of the battery is 4 hours ), the cost is increased . finally , it is recognised that there is always some cost by introducing a positive lower limit on the cost value ( for example 1 unit ). the benefit is then compared with the cost at intervals of , for example , one second for a period of time into the future . in the embodiment described the look ahead period may be limited by a predetermined upper limit ( for example 5 - times the average period of time it is allowed to be on ), and is such that the gps receiver will never be on for more than 7 times the average on period ( the choice of limits may be varied in other embodiments ). this is explained by means of the following pseudo - code . if we ever reach here then the benefit has never been worth the cost , so if the gps receiver has decided that it wants to be turned off without having been able to generate a valid fix , but it has already had a number of consecutive failures to fix , the receiver recognises that it might have to try harder even if this is at the expense of the required battery life . this is achieved by adding additional checks , to see if the gps receiver should cancel some debt , as follows . if there have already been 4 or some other predetermined number of consecutive failures to fix , and the receiver is still in credit ( even though this might only be because it earlier cancelled some debt because of its failure to fix ), and the receiver has been on for less than 3 - times ( or some other predetermined factor ) the average period of time it is allowed to be on a decision may be taken to override the request that the gsp receiver be turned off , without changing the current credit / debit . this provides a fail - safe mechanism in the event there may be some a deficiency in the method or its implementation in respect of the current environment in which the receiver finds itself if the receiver started off this attempt to generate a fix in debt , and it has not yet cancelled any debt during the present attempt , and the number of consecutive failures to fix is greater than 1 % of the total number of times it is expected to be required to generate a fix of fixes ( i . e . if the number of consecutive failures to fix is greater than 1 % of numon , or , as an example , greater than 10 if numon is 1000 ), then the receiver cancels some debt , as follows . if the number of consecutive failures is 20 or more , all debt is cancelled ; otherwise , 50 % of the debt is cancelled . the receiver then over - rides the decision to request to be turned off . to this point the mechanism has been described without reference to the source of the commands and parameters controlling the cots - benefit analysis . in practice is maybe desirable to afford end - users of the gps receiver to specifically control the parameters , typically via a web interface to a base system which communicates remotely with the receiver , wherever it is located . alternatively it might be via a user interface located on the device itself . this allows end users to trade battery life for increased availability . one simple method would be to allow end - users to manipulate the key parameters directly , but in practice the end - users may not be sufficiently sophisticated users to understand the operation of the system in such detail . consequently it is desirable to provide a user interface 18 ( fig1 ) which provides a limited set of options to end - users and which are in turn automatically mapped to specific values of the operational parameters of the device . in one particular embodiment the end - user is presented with a menu offering selection of one from a predetermined set of options . these may be presented textually , numerically , or graphically , though in each case it is convenient to map the selected option to a numerical value for further computation . taking the instance where the option value ( throttlevalue ) is represented numerically , with higher numbers representing more battery charge being used so that the users have a higher probability of getting more valid fixes in gps challenging environment , whilst lower numbers are orientated towards configurations intended to preserve battery charge resulting in the system not trying as hard to get gps fixes in a challenging environment . where no value is manually selected a suitable default value for may be adopted for throttlevalue . referring again to fig2 , the selected option 21 is mapped 22 b to specific settings for the method described above . in particular : the expected interval between fixes ( expinterv ). the expected usage ( expusage ), as a percentage . this is typically set to 100 % but may be reduced is it is known that the device will be switched on only for a smaller proportion of the day . the expected life of the battery ( explife ), in integer minutes . this is set to the remaining fraction of the expected battery lifetime , based on knowledge of maximum battery lifetime when fully charged , and how much power has already been drawn from the battery . the minimum required operational period of the gps receiver ( minreqlife ), in integer minutes . minreqlife may be set to a value responsive to the expected interval between fixes ( expinterv ) and the user - selected opton value . fore example in one embodiment the minreqlife may be set to : where f ( throttlevalue , expinterv )=( n * throttlevalue + c ) if this is less than expinterv , otherwise ( expinterv − k ), in which n , c , and k are empirically selected integer constants . the net assist mode . this is set according to whether net assist location information available for the gps device in question . referring now to fig3 values are also determined for a long timeout and short timeout : the long timeout 31 is used by default and until the gps receiver fails to obtain a gps fix for the first time , from then on the short timeout is used . long timeout =“ gps throttle ” number of minutes plus one the short timeout 32 is used until the gps receiver manages to get a valid fix , at that time the long timeout is restored again . in one embodiment short timeout is set to a default minimum non - zero value throttlevalue is below a given threshold and simple ( e . g . linear ) function of throttlevalue if throttlevalue is at or above that threshold . referring now to fig4 , the long and short timeouts regulate the maximum time interval 40 - 44 during which the gps receiver is permitted to listen in order to obtain a gps fix . the principal of operation is that the long timeout 40 , 41 , 44 imposes an upper limit on the listening period duration as determined by the on / off control method , until the first failure to fix occurs 41 ; from then on the short timeout 42 , 43 is applied as the upper limit . in this way , while the device is considered to be in an area where it is difficult to acquire a fix , the device is not caused to spend undue time fruitlessly listening to obtain a fix . in either case the device stops listening before reaching the timeout if a fix is obtained . once a fix is re - acquired 43 , the long timeout value is reinstated as the upper limit of the listening period . the cost - benefit method described above acts to regulate the listening periods 45 , 47 , 49 subject to the maxima determined by the long timeout and the short timeout . as illustrated in fig4 ( b ) this may be combined with varying the time intervals 46 , 48 between listening periods 45 , 47 , 49 to produce listening behaviour which both varies the duration of powered - off periods between listening periods and the maximum durations of the listening periods 45 , 47 , 49 themselves . any range or device value given herein may be extended or altered without losing the effect sought , as will be apparent to the skilled person for an understanding of the teachings herein .