ENCLOSED SPACES

BACKGROUND

[0001] Outdoor navigation systems designed for vehicles use global positioning system (GPS) signals to find position and find a route to a destination, both of which are expressed and displayed in terms of two-dimensional space. For outdoor navigation applications, determination of a vertical location, such as a level within a building, is unavailable. Further, for most outdoor land navigation, vertical location, such as level within a building, is irrelevant.

[0002] However if navigation is to be provided for a pedestrian within a building, requirements different from those present in outdoor navigation will present themselves, and the failure to fulfill these requirements has frustrated attempts to solve problems related to indoor navigation. If they can be accurately determined, floor levels in an indoor navigation system may be used to accurately guide the user from one part of a building on a first floor to a second part of a building on a different floor. Additionally, frequent updates to a vertical level will be needed to track changes in user location between levels.

[0003] Most if not all related-art systems suffer from problems of inaccuracy that compromise usability.

[0004] One of the common methods is measuring the strength radio signals on a floor level. Such radio signals are broadcast by WI-FI routers, IEEE 802.15.4 Wireless Sensor Networks or any other radio-transmitting device. The accuracy and performance of these signal strength methods are unsatisfactory, and additional problems arise with such techniques in that they will require a network set up in the building. Further some of the radio networks will require radio transmitters to be installed in pre-determined patterns to support floor detection. Such requirements immediately limit the use of radio network based methods to a handful of buildings. For example, these techniques are of limited value in exhibition halls or parking garages that have no permanent WI-FI networks installed.

[0005] An alternative, called,“fingerprinting,” is labor heavy in that it requires detailed survey of each and every floor. Effectively a‘radio wave fingerprint’ of each and every floor is plotted from all possible locations on that floor level. Site survey is a manual process and therefore is costly and time consuming. Another disadvantage of fingerpring systems is that behaviour of transmitters change in a building over time, requiring site survey to be repeated periodically and user systems must be updated with new survey results.

SUMMARY

[0006] At least one example embodiment is a computer-implemented method for determining a vertical location of a hand-held computing device, the method comprising: generating an estimate of expected vertical location based on items of beacon data received from beacons by a radio receiver of the hand-held computing device; generating an error covariance of the estimate of expected vertical location based on the items of beacon data; calculating a level normalized change based on measurements of barometric pressure by a pressure sensor of the hand-held computing device; calculating the vertical location of the hand-held computing device based on the level normalized change, the error covariance of the estimate of expected vertical location, and the estimate of expected vertical location; and activating a relevant map for a level comprising the vertical location and displaying the vertical location on a display device of the hand held computing device.

[0007] In the example method, calculating the vertical location of the hand-held computing device my further comprises generating an integer value representing a level inside a structure based on a Kalman filter having inputs comprising the level normalized change, the error covariance of the estimate of expected vertical location, and the estimate of expected vertical location. The inputs may further comprise an error covariance of the level normalized change and the method further comprises refining the error covariances using items of measured data. The example method may further comprise iteratively calculating expected vertical location from beacon data and the level normalized change estimated from barometric pressure and respective error covariances. The inputs may further comprise an error covariance of the estimate of expected vertical location representing reliability of the items of beacon data.

[0008] In the example method, the generating the estimate of expected vertical location may further comprise: generating an integer value representing an estimate of an expected level inside a structure based on a set of probabilities calculated at least in part from beacon data comprising beacon distances, beacon distance accuracies, and items of beacon data time information, wherein the beacon distance accuracies are calculated using venue-dependent accuracy constants. The beacon data may be read from a beacon data dictionary. The generating the integer value representing an estimate of expected level inside a structure based on the set of probabilities may further comprise generating level weights sums from probabilities for beacons on each of a set of levels from which the items of beacon data been received. The generating the integer value representing an estimate of an expected level inside a structure based on the set of probabilities may further comprise generating probabilities for beacons on each of a set of levels based on the items of beacon data time information.

[0009] The example method may further comprise: assigning time information to the items of beacon data; estimating beacon distances for the items of beacon data; and estimating beacon distance accuracies for the items of beacon data. The method may further comprise: receiving the items of beacon data at the radio receiver of the hand held computing device; determining validities of the items of beacon data; and storing the beacon distances, beacon distance accuracies, and items of beacon data time information in a beacon data dictionary. The beacon data dictionary may comprise a table of datagrams having index keys based on a horizontal beacon location and a beacon level.

[0010] The example method may further comprise iteratively updating the vertical location of the hand-held computing device using expectation estimates.

[0011] Another example embodiment is a hand-held computing device comprising: a processor; a memory coupled to the processor; a display device electrically coupled to the processor; a barometric pressure sensor electrically coupled to the processor; and a wireless communication system electrically coupled to the processor, the wireless communication system configured to receive items of beacon data wirelessly from beacons external to the hand-held computing device. The memory stores a program that, when executed by the processor, causes the processor to: generate an estimate of expected vertical location based on the items of beacon data, generate an error covariance of the estimate of expected vertical location based on the items of beacon data, calculate a level normalized change based on measurements of barometric pressure by the barometric pressure sensor, calculate a vertical location of the hand-held computing device based on the level normalized change, the error covariance of the estimate of expected vertical location, and the estimate of expected vertical location, and display the vertical location on the display device.

[0012] In the example hand-held computing device, when the processor calculates the vertical location of the hand-held computing device, the program may further cause the processor to generate an integer value representing a level inside a structure based on a linear solution calculation having inputs comprising the level normalized change, the error covariance of the estimate of expected vertical location, and the estimate of expected vertical location.

[0013] In the example hand-held computing device, when the processor generates the estimate of expected vertical location, the program further causes the processor to: generate an integer value representing an estimate of an expected level inside a structure based on a set of respective probabilities calculated at least in part from beacon data comprising beacon distances, beacon distance accuracies, and items of beacon data time information.

[0014] Yet another example embodiment is a computer program product in a computer- readable medium for location of a handheld computing device, the computer program product in a non-transitory computer-readable medium comprising instructions, which, when executed, cause a processor of a handheld computing device to perform: generating an estimate of expected vertical location based on items of beacon data received from beacons by a radio receiver of the hand-held computing device; generating an error covariance of the estimate of expected vertical location based on the items of beacon data; calculating a level normalized change based on measurements of barometric pressure by a pressure sensor of the hand-held computing device; calculating a vertical location of the hand-held computing device based on the level normalized change, the error covariance of the estimate of expected vertical location, and the estimate of expected vertical location; and displaying the vertical location on a display device of the hand-held computing device. [0015] In the example computer program product, the calculating the vertical location of the hand-held computing device may further comprise generating an integer value representing a level inside a structure based on a calculation having inputs comprising the level normalized change, the error covariance of the estimate of expected vertical location, and the estimate of expected vertical location.

[0016] In the example computer program product, the generating the estimate of expected vertical location may further comprise: generating an integer value representing an estimate of an expected level inside a structure based on a set of probabilities calculated at least in part from beacon data comprising beacon distances, beacon distance accuracies, and items of beacon data time information.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] For a detailed description of example embodiments, reference will now be made to the accompanying drawings in which:

[0018] Figure 1A shows an overhead view of a single floor of an indoor venue in accordance with at least some embodiments;

[0019] Figure 1 B shows a side view of a multiple floors of an indoor venue in accordance with at least some embodiments;

[0020] Figure 2 shows a block diagram of a mobile device in accordance with at least some embodiments;

[0021] Figure 3 shows a block diagram of a navigation program in accordance with at least some embodiments;

[0022] Figure 4 shows a block diagram of the internal components of the vertical position estimation module in accordance with at least some embodiments;

[0023] Figure 5 shows an overhead conceptual view of a process of location determination accordance with at least some embodiments;

[0024] Figure 6 shows a side conceptual view of a process of location determination in accordance with at least some embodiments;

[0025] Figure 7A shows a schematic of a beacon data dictionary for use in location determination in accordance with at least some embodiments;

[0026] Figure 7B shows a schematic of a beacon data dictionary for use in location determination in accordance with at least some embodiments; [0027] Figure 8 shows a flowchart of a method for maintaining a beacon data dictionary, in accordance with at least some embodiments;

[0028] Figure 9 shows a flowchart of a method for estimating an expected level, in accordance with at least some embodiments;

[0029] Figure 10 shows a flowchart of a method for estimating a level normalized change, in accordance with at least some embodiments;

[0030] Figure 1 1 shows a flowchart of a method for iteratively predicting and revising a vertical location, in accordance with at least some embodiments; and

[0031] Figure 12 shows a method in accordance with at least some embodments.

DEFINITIONS

[0032] Various terms are used to refer to particular system components. Different companies may refer to a component by different names - this document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms“including” and“comprising” are used in an open- ended fashion, and thus should be interpreted to mean“including, but not limited to... .” Also, the term “couple” or“couples” is intended to mean either an indirect or direct connection. Thus, if a first device couples to a second device, that connection may be through a direct connection or through an indirect connection via other devices and connections.

[0033] “Controller” shall mean individual circuit components, an application specific integrated circuit (ASIC), a microcontroller with controlling software, a digital signal processor (DSP), a processor with controlling software on memory, a field programmable gate array (FPGA), or combinations thereof, configured to read inputs and drive outputs responsive to the inputs.

DETAILED DESCRIPTION

[0034] The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims. In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any embodiment is meant only to be exemplary of that embodiment, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that embodiment.

[0035] It is noted that the various embodiments were developed in the context of determining vertical location or level within a building of a handheld computing device, such as a mobile phone or mobile computer in indoor navigation circumstances, and thus the description is based on the developmental context; however, indoor navigation is merely an example of a situation where a vertical location, determination may be made, and other uses are possible (e.g., asset tracking, outdoor pedestrian navigation, GPS- based automobile navigation, and aviation navigation). Thus, the developmental context shall not be read a limitation of the various embodiments. The specification now turns to an example environment to help orient the reader.

[0036] Figure 1A shows an overhead view of an indoor venue in accordance with at least some embodiments. In particular, Figure 1 shows the layout 100 of an example indoor venue 102. A person may enter the indoor venue 102 through doors 104. Once inside, the person may want to navigate from the entry hall area 108 (on second level 134) to the exhibition area 106 (on first level 132) or exhibition area 110 (on third level 130) each of which may be located on a different level within the building, in addition to having a different horizontal location, requiring navigation between them through the use of elevators 126, stairs 120, ramps 124, ladders or escalators 122. Disposed within the indoor venue are a plurality of beacon devices 1 12. Not all beacon devices are numbered so as not to unduly complicate the figure. The beacon devices 1 12 may be placed at any suitable location, such as ceiling-mounted beacon devices, wall-mounted beacon devices, beacon devices mounted on structural pillars, and the like. The beacon devices 1 12 may take any suitable form, such as Bluetooth Low Energy (BLE) devices, or Ultra Wide Band (UWB) devices, available from many manufacturers. Moreover, location determinations may take any suitable form, such as triangulation, received signal strength indications (RSSI), and combinations. The various embodiments of determining initial vertical location be used with any suitable location determination method and system.

[0037] Consider a user that has entered the facility, is standing at location 1 14 in the entry hall 108, and would like to navigate to location 1 16 within exhibit hall 1 10. The hand-held computing device or mobile device carried by the user has a navigation program that either knows in advance, or is provided upon request from the beacon devices 1 12 or a cellular data network, the layout of the indoor venue 102. A purely horizontal navigation path from location 1 14 to location 116 through exhibition hall 106 may appear possible to a two-dimensional navigation system, but may be impossible in fact, due to the fact that exhibition area 106 is located on second level 132 and exhibition area 1 10 is located on third level 130. Instead, a horizontal and vertical navigation path from location 1 14 to location 116 using stairs 120 and one of elevators 126 and ramps 124 is required.

[0038] In related-art systems, the navigation platform may unable to determine the level occupied by the user at location 1 14, in which case the user may be given a wrong navigation path (e.g., towards exhibit hall 106 rather than exhibit hall 1 10 in this example).

[0039] The problem of indoor navigation without level determination is further illustrated by Figure 1 B. Figure 1 B shows a side view of a multiple floors of an indoor venue in accordance with at least some embodiments. Within a 3-dimensional exhibit space 150, The person at location 1 14, holding a handheld computing device 148 that interacts with beacons 1 12a-f by means of radio signals 156a-f may want to navigate from the entry hall area 108 (on second level 134) to the exhibition area 106 (on first level 132) or exhibition area 110 (on third level 130).

[0040] Some embodiments support multiple-vertical-level indoor navigation as needed in the example above by determining a vertical location of a hand-held computing device 148 through a method that includes generating an estimate of expected vertical location of the handheld computing device 148 based on items of beacon data (derived from radio signals 156a-f) received from beacons 1 12a-f by a radio receiver of the hand-held computing device 148. In some embodiments, the method further includes generating an error covariance of the estimate of expected vertical location based on the items of beacon data. In some embodiments, the method further includes calculating a level normalized change based on measurements of barometric pressure by a pressure sensor of the hand-held computing device 148. In some embodiments, the method further includes calculating the vertical location of the hand-held computing device 148 based on the level normalized change, the error covariance of the estimate of expected vertical location, and the estimate of expected vertical location. In some embodiments, the method further includes activating a relevant map for a level comprising the vertical location and displaying the vertical location on a display device of the hand-held computing device 148.

[0041] Figure 2 shows a block diagram of a mobile device in accordance with at least some embodiments. In particular, Figure 2 shows example mobile device 200 comprising a controller 202. The controller 202 takes any suitable form, such as an application specific integrated circuit (ASIC), a microcontroller with controlling software, a digital signal processor (DSP), a processor with controlling software, a field programmable gate array (FPGA), or combinations thereof, configured to read inputs and drive outputs responsive to the inputs. In the system of Figure 2, the controller 202 is implemented in the example form of a processor 204 coupled to a memory 206. The controller 202 couples to host of internal components and devices by any suitable direct connection or bus system, as shown by the example internal bus 208.

[0042] The example mobile device 200 comprises an accelerometer 210 electrically coupled to the controller 202 by way of the internal bus 208. The accelerometer 210 may take any suitable form, such as a single-axis accelerometer, or multi-axis accelerometer. In a particular example, the accelerometer 210 is a three-axis accelerometer such that the mobile device 200 may be able to determine acceleration in any dimension (e.g., movement in the horizontal plane or vertical plane. In other cases the accelerometer 210 may be one or more velocity meters, from which acceleration can be mathematically determined. The example mobile device 200 further comprises an electronic gyroscope 212 electrically coupled to the controller 202 by way of the example internal bus 208.

[0043] The example mobile device 200 further comprises a barometer 214 electrically coupled to the controller 202 by way of the example internal bus 208. The barometer 214 may be used to read barometric pressure, which is indicative of the elevation and change in elevation. Of course, barometric pressure is also influenced by high and low pressure weather patterns; however, frequent readings of the barometer are much less likely to be influenced by weather, especially when relative elevation changes are used. Further, in some embodiments, the data from the barometer 214 are combined with other data for elevation, vertical position, or level determinations. [0044] The example mobile device 200 further comprises a short-range wireless communication system 216 coupled to the controller 202 by way of the example internal bus 208. The short-range wireless communication system 216 may take any suitable form and protocol, such as Bluetooth, or any or any of the various WIFI protocols, such as IEEE 802.11 . In example embodiments, the mobile device 200 receives data from beacon devices 1 12 (Figure 1A-B) as part of providing navigation services to the user of the mobile device 200.

[0045] The example mobile device 200 further comprises a cellular communication system 218 electrically coupled to the controller by way of the example internal bus 208. The cellular communication system 218 wirelessly communicates with cell towers to provide voice and data services. In example embodiments, internal maps of indoor venues (such as indoor venue 102 (Figure 1A-1 B)) may be downloaded using the data aspects of the cellular communication system 218. The maps may also be downloaded by use of the short-range wireless communication system 216 in addition to, or in place of, the cellular communication system 218.

[0046] The example mobile device 200 further comprises a display device 220 electrically coupled to the controller 202 by way of display driver 222. As the name implies, the display driver 222 takes data provided by the controller 202 (e.g., maps, graphical indications of direction to travel) and displays the information on the display device 220 for the user. In some example systems, the display device 220 is covered by or integrated with a touch screen system (not specifically shown). The controller 202 may interface with the touch screen system by way of touch screen interface 224. Thus, using the touch screen system and the touch screen interface 224, the controller 202 may receive information from the user, such as by way of keyboard implemented using the display device 220. In other cases, the mobile device 200 may implement a physical keyboard in addition to, or in place of, the touch screen system and touch screen interface 224.

[0047] Finally, the example mobile device 200 comprises a battery 226. The battery 226 provides power to all of the noted internal components, but the electrical connections to the battery 226 are not shown so as not to unduly complicate the drawing. The battery 226 may take any suitable form, such as a lithium-ion battery, but any currently available or after-developed battery technology may be used. Thus, the mobile device 200 may be any currently available mobile device (e.g., APPLE® brand iPhones available from Apple, Inc., or ANDROID® brand devices available from Google, Inc.) or any after- developed hand-held computing device or mobile device. The discussion now turns to a software environment in which the example embodiments are operated, and it will be understood the various pieces of the software that make up the software environment may be executed by the controller 202, and in specific examples stored on the memory 206 and executed by the processor 204.

[0048] Figure 3 shows a block diagram of a navigation program in accordance with at least some embodiments. In particular, Figure 3 shows that navigation program 300 interfaces with various devices of the mobile device 200 (Figure 2), such as the accelerometer 210, gyroscope 212, barometer 214, and short-range wireless communication system 216. The navigation program 300 may provide to the user navigation information, such as by placing that navigation information in display device 220 of Figure 2. The example navigation program 300 is conceptually, though not necessarily physically, divided into a plurality of modules and data engines. In particular, the example navigation program 300 comprises a vertical position estimation module 304a, which, as the name implies, is designed and programmed to determine or estimate the vertical position, elevation, or level within a building, as described herein. The vertical position estimation module 304a reads or takes input in the form of beacon data 368 from the short-range wireless communication system 216 and barometric pressure data 366 from the barometer 214. A horizontal position estimation module 304b also receives beacon data 370 from the short-range wireless communication system 216. An inertial navigation module 310 provides movement data 354 to a data supply engine 312 based on accelerometer data 364 and gyroscope data 372. In the example environment of Figure 3, horizontal position data 362 is provided from horizontal position estimation module 304b to data supply engine 312. In the example environment of Figure 3, vertical position data 360 is provided from vertical position estimation module 304a to data supply engine 312, and in particular the vertical position estimation module 304a periodically (e.g., once every second) provides position data (e.g., a level within a building) such that three-dimensional location data 356 can be provided to a reporting module 308a. Further, three-dimensional location data 358 can be provided to a direction instruction module 308b and navigation instructions 350 can be provided to other processes through the location reporting module 308a as a part of location and direction instruction reports 352 that can be provided to other processes through the location reporting module 308a. The direction instruction module 308b further receives map data 306 from the navigation program 300, such as map data downloaded through the cellular communication system 218 (Figure 2) or read through the short-range wireless communication system 216.

[0049] In example embodiments, vertical position estimation module 304a is conceptually, though not necessarily physically, divided into a plurality of underlying modules and engines.

[0050] Vertical position estimation module 304a receives as input barometric pressure data 366 from the barometer 214, as well as location information through the short-range wireless communication system 216, such as location information such as beacon data 370 from beacon devices 1 12 (Figure 1A). The position vertical position estimation module 304a is shown separate from the horizontal position estimation module 304b to signify that any currently available or after-developed position estimation methodology may be used. In many cases the horizontal position estimation module 304b uses a triangulation method and/or a RSSI method to determine horizontal location.

[0051] Figure 4 shows a block diagram of the internal components of the vertical position estimation module in accordance with at least some embodiments. Vertical position estimation module receives beacon data 410 at a data collection engine 406 (DCE), which checks validity of the data, manages a beacon data dictionary 404 (BDD), eliminates obsolete data, and estimates beacon distances. Beacon data dictionary 404 is a data structure containing information reported on local beacons. Data collection engine 406 provides data 412 to beacon data dictionary 404 and provides data 414 to expected level estimator 416 (ELE). Expected level estimator 416 estimates a current level based on data in BDD 404 and updates the expected level, if necessary. A level determination engine 402 includes expected level estimator 416, a predictive decision engine 418 (PDE), and a level normalized change module 420 (LNC). Expected level estimator shares data 414 bi-directionally with data collection engine 406 and shares data 424 bi-directionally with beacon data dictionary 404. Predictive decision engine 418 provides a current level 408 based upon expected level data 426 received from expected level estimator 416 and level normalized change data 422 received from level normalized change module 420. Level normalized change data 422 is a normalized value representing a pedestrian’s level change. Level normalized change data 422 and expected level data 426 are inputs to Predictive decision engine 418 that determines the current level 408 of the pedestrian. As shown in Figure 4, level determination engine 402 includes of three illustrated modules: expected level estimator 416 (ELE), level normalized change module 420 (LNC) and predictive decision engine 418 (PDE). Expected level estimator 416 (ELE) estimates a level based on beacon data. Level normalized change module 420 (LNC) estimates normalized change in level using sensor data.

[0052] Predictive decision engine 418 (PDE) takes inputs from level normalized change module 420 (LNC) and expected level estimator 416 (ELE) and their respective error covariances to predict current floor level.

[0053] Figure 5 shows an overhead conceptual view of a process of location determination accordance with at least some embodiments. As shown in diagram 500, position 506 of a user with regard to a point of reference 504, such as a beacon 1 12 of Figure 1 A in an enclosed space 502, is determined with regard to coordinates along an x-axis 508 and a y-axis 510.

[0054] Figure 6 shows a side conceptual view of a process of location determination in accordance with at least some embodiments. As shown in diagram 600, a beacon 614 is shown as mounted on a ceiling 608 that is suspended at a known level height 604 (LH) from a floor 602. Distance 612 (d) from beacon 614 is the distance between the beacon 614 and the pedestrian 610 without consideration of any angle.

[0055] Distance (d) 612 is estimated using signal strength represented by rssi and two constants, a and n. Constants (a, n ) are determined by the type of radio transmitter and its power level. In some cases those constants are empirically determined, in some cases they are dependent on components used.

—rssi— a

d = 10 n (1 )

[0056] Because the formula above becomes less and less accurate as the pedestrian moves away from the transmitter, estimation of expected accuracy is therefore a part of distance estimation in some embodiments. In recognition of the impact of distance

Accuracy [dA] on overall accuracy for floor level estimation, some embodiments calculate distance accuracy using a formula as shown below:

dA = e ^~hd (2)

As used herein, h is a constant and d is the estimated distance. Constant [h] is venue dependent as structures and obstacles change from venue to venue. Using an initial value

(in some embodiments, h = 0.05) and embodiments improve this initial value when used in a particular venue using distance values with higher certainty. Therefore, venue dependent constant [h] is improved when a pedestrian is in a venue, increasing significantly the overall accuracy of level determination.

[0057] Level Height 604 (LH) is the distance from ceiling to floor for a particular floor level. It will be appreciated that some buildings will have a number of different LH values on a single floor, as some areas of the same floor may have a higher ceiling or a lower floor. In some embodiments, LH is a map-encoded parameter. When required, LH is taken directly from the map.

[0058] A time stamp is used to stamp the data collected with time. A time stamp can then be used to indicate how old the data is. Within the context of some embodiments, a time stamp is accurate down to milliseconds. A typical time stamp for some embodiments is of the following form, where the last four digits indicate milliseconds.

hh.mm.ss.xxxx - 07.03.20.874 (3)

[0059] Figure 7A shows a schematic of a beacon data dictionary for use in location determination in accordance with at least some embodiments. A beacon data dictionary 700 is a data structure including a series of datagrams 702a-n. Beacon data dictionary 700 is a repository for collected data, in some embodiments understood as a hash table. In some embodiments, there is no constraint placed on the size of beacon data dictionary 700, as it is size-limited by an area that a pedestrian can cover within a certain time. However, if required, a size of BDD 700 may be limited for a given embodiment. Each entry into BDD 700 is called a datagram 702a-n.

[0060] Figure 7B shows a schematic of a beacon data dictionary for use in location determination in accordance with at least some embodiments. A datagram 722 includes a representation of beacon data including x location 710, y location 712, level 714, time stamp 716, distance accuracy 718, and distance 720. A datagram key is composed of x location 710, y location 712, and level 714. A datagram key is used in some embodiments to increase data access power efficiency and speed, so as to decrease handheld computing device energy consumption in data location. Some parameters are in the datagram are calculated. Some parameters of datagram are captured from nearby beacon advertisements.

[0061] In some embodiments, program code running on mobile device is configured to work with a few advertising signals per second, which reduces energy requirements of the handheld computing device and it allow beacons to last longer. For example, beacons advertising 50 times per second will typically run out of battery power in 3 months, whereas, if advertisement signals were sent 3 times per second, the battery may last for a year.

[0062] Figure 8 shows a flowchart of a method for maintaining a beacon data dictionary, in accordance with at least some embodiments. In some embodiments, data collection engine 406 of Figure 4 executes process 800 as shown. In some embodiments, a primary task of data collection engine 406 of Figure 4 is to listen to beacon advertisements and to collect, maintain data and update beacon data dictionary 404 of Figure 4. Data collection engine 406 of Figure 4 executes process 800 periodically, capturing and validating data in preparation for other operations.

[0063] Beacon data is acquired (block 802). A determination is made as to whether the data is valid (block 804). Validity of data is checked by ensuring that captured data is coming from beacons within the building and it is within limits. For example, a beacon reporting itself as being on level 6 in a 3-story building could be rejected on the assumption that it is not possible to have floor level 6 in a 3-story building. If the data is not valid, the process returns to block 802 for acquisition of additional beacon data. If the data is valid, a time stamp is generated (block 806). Flaving ensured that data is valid, data time stamped, creating a reference point for its age. Distance is estimated (block 808). In estimating distance, level height (LH) is extracted from map data and checked to confirm that it is within correct limits. Distance accuracy is estimated (block 810). Data collection engine 406 estimates distance Accuracy (dA) and improves the value of ( h ) using an internal machine learning engine. The beacon data dictionary 404 of Figure 4 is updated with a newly-created valid datagram (block 812). The process then returns to block 802 for acquisition of additional beacon data. In some embodiments, data collection engine 406 of Figure 4 does not delete data from beacon data dictionary 404 of Figure 4, allowing deletions to be handled by another module.

[0064] Figure 9 shows a flowchart of a method for estimating an expected level, in accordance with at least some embodiments. In some embodiments process 900 executes on expected level estimator 416 of Figure 4, and, using data collected from beacons, expected level estimator 416 (ELE) generates an estimate of expected floor level along with its error covariance. The beacon data dictionary 404 of Figure is read (block 902). A determination is made as to whether data is present (block 904). If no data is present, the process returns to block 902. If data is present, expired beacons are eliminated (block 906). Once data is acquired from beacon data dictionary 404, expired beacon data is eliminated by deletion. In some embodiments, expiry duration is a constant time span and is decided upon by considering the trade-off. The longer the expiry duration, the better the estimation becomes as there are more beacon data to use in floor level estimate. Flowever, longer expiry duration reduces system responsiveness, as it needs to wait for more data to be collected. In some embodiments, expected level estimator 416 starts off with an average expiry duration constant and adjusts duration over a period of time for a particular venue.

[0065] Freshness is updated (block 908). The following formula is used for freshness calculation.

[0066] Data from beacon data dictionary 404 for each level is split (block 910). Beacon data is grouped for each level. For example, floor level 1 may have data from three beacons and floor level 2 may have data only from one beacon.

[0067] Beacon weights for each level are calculated (block 912). For each beacon, beaconweight is calculated using the following formula.

beaconweight = ( freshness * dA)/d (5)

In the formula above, dA is distance accuracy and d is the distance of pedestrian from beacon. [0068] Level weight is calculated for each floor (block 914). To calculate weight for a floor, all beaconweights for a particular floor is summed. The mathematical expression is lev elw eight (Z) å _n be aconw eight (n) (6)

In the formula above, n is the number of beacons for a single level. Levelweight(l) is calculated for each floor level. To express the above mathematics in words: beaconweight(n) for each beacon is a bigger floating number if beacon data is fresher and its accuracy is higher. Levelweight(l) becomes a bigger floating point number with higher value beaconweights for a single floor.

[0069] Level weight is converted to probability (block 916). Levelweights are converted into probability using the sum of all levelweights.

[0070] An expected level is calculated (block 918). Expected level uses summed level probabilities to estimate an expected level using the formula below.

E(L) = å _I&c iPr (i = 0 (7)

In the formula above E(L) is expected level, and L is the set of possible levels in the venue, fetched from the map data. This is represented by: z _t = [b _t ], where b _t is the expected beacon level at time t.

[0071] Error covariance for E(L) is R _t = [s]? ² ]. R _t is a floating point number that indicates reliability of beacon data. In some embodiments, venues are assigned an average R _t at initialization. In time this value is improved by a machine learning engine in cloud as venue is used and more data is obtained over time.

[0072] The process returns to block 902 for periodic repetition.

[0073] Figure 10 shows a flowchart of a method for estimating a level normalized change, in accordance with at least some embodiments. Level normalized change module 420 executes process 1000. Level normalized change (LNC) is a value that indicates a pedestrian’s level change as a floating point number and not as an integer. This floating point number is then used in predicting pedestrian level. Floating point arithmetic allows for more accurate level predictions.

[0074] A barometer reading is periodically taken and converted to absolute altitude (block 1002). Barometers measure air pressure and are used for indicating weather conditions, and air pressure can also easily be converted into altitude. Weather changes take place rather slower than a pedestrian walking in a building. Altitude estimated in such a short space of time reflects almost no influence from changing whether conditions. As a pedestrian walks in a building, it is therefore possible to measure relative altitude changes using a barometer.

[0075] An altitude change is calculated (block 1008). In some embodiments, estimation techniques use floating point numbers to increase accuracy. Use of loating point numbers in most calculations increases final level estimation accuracy. Relative altitude (Altitude Change) as pedestrian walks reduces inaccuracies due to floor changes.

[0076] A level height is acquired (block 1004). Level Height (LH) is a map parameter and is extracted using pedestrian’s current position.

[0077] A level normalized change is calculated (block 1006). Level Normalized Change (LNC) is then estimated by a division operation.

[0078] Consider an example: Note that resultant LNC is a floating point number.

[0079] Altitude-Reading-1 - Altitude Reading-2 = Altitude Change [AC]=2.2-1.0 = 1.2

[0080] AC = 1 .2

[0081] LH = 2.5

[0082] LNC = 1.2 / 2.5 = 0.48

[0083] LNC is expressed as a matrix as

u _t = [Ah _t ] (8)

In the above expression, h _t is the relative change in altitude at a time t. Note that all barometers have some error associated with their readings. Accuracy is a manufacturer specified constant. Sensor type and manufacturer are detected by embodiments and an applicable accuracy constant is selected to be used on a particular hardware platform. Accuracy is also relative altitude dependent. It is squared to convert it into variance. Accuracy covariance is then expressed as follows.

Qt = R ² ]. (9) where s£ is the accuracy and s]? ² is covariance and Q _t is matrix representation. LNC (u _t = [ h _t ]) and Q _t are used by Predictive Decision Engine.

[0084] Figure 1 1 shows a flowchart of a method for iteratively predicting and revising a vertical location, in accordance with at least some embodiments. Process 1 100 executes in predictive decision engine 418. At block 1 102, expected level estimation ELE and level normalized change (LNC) with their respective error covariances are inputs to a Kalman filter, which continuously predicts and corrects its predictions using expected level estimates. The Kalman filter (KF) then generates a floating point number, KF. level. Use of the Kalman filter, in some embodiments, presents significant error resiliency in floor level determination.

[0085] At block 1 104, a rounded value of KF. level is calculated as the variable calculatedlevel.

[0086] At block 1 106, a determination is made as to whether the current calculation is the first calculation for a floor level. If the current calculation is the first calculation for a floor level the process moves to block 1 108.

[0087] At block 1 108, a determination is made as to whether the value of calculatedlevel exists in map data. If the value of calculatedlevel exists in the map data, then the process proceeds to block 1 122, which is described below.

[0088] Returning to block 1108, if the value of calculatedlevel does not exist in the map data, then the process proceeds to block 1 1 10. Calculatedlevel is reset to the nearest map level to the value of KF. level. The process proceeds to block 1 122, at which the variable currentlevel is reset to the value of calculatedlevel.

[0089] Returning to block 1 106, if the current calculation is not the first calculation for a floor level the process moves to block 1 1 16. At block 11 16, a determination is made as to whether the value of the variable currentlevel is equal to the value of the variable calculated level. If the value of the variable currentlevel is equal to the value of the variable calculated level, then the process proceeds to block 1 1 12, at which no change to the value of currentlevel is made. The process then repeats periodically.

[0090] Returning to block 1 1 16, if the value of the variable currentlevel is not equal to the value of the variable calculated level, then the process proceeds to block 1 1 18, at which a determination is made as to whether the value of calculatedlevel exists in the map data. If the value of calculatedlevel does not exist in the map data, then the process moves to block 1 1 12, which is described above.

[0091] Returning to block 1 1 18, if the value of calculatedlevel exists in the map data, then the process moves to block 1 120, at which a determination is made as to whether the absolute value of a difference between the value of KF.Ievel-currentlevel exceeds a threshold. If the value of KF.Ievel-calculatedlevel does not does not exceed the threshold, then the process moves to block 1 1 12, which is described above.

[0092] Returning to block 1 120, if the absolute value of a difference between the value of KF.Ievel-currentlevel exceeds the threshold, then the process moves to block 1 122, at which a level change is made and currentlevel is set to calculatedlevel. The process then repeats periodically.

[0093] To further appreciate the mechanism described above, consider two examples.

[0094] A first example follows the right branch of the flowchart through blocks 11 16-1 118.

[0095] currentlevel = 2

[0096] At block 1102, KF.Ievel = 2.85.

[0097] At block 1104, calculatedlevel = round(level) = 3.

[0098] Assuming at block 1106 that this example is not the first calculation for this floor level, at block 1 1 16,“currentlevel¹calculatedlevel.” Therefore, the process next moves to block 1 118, at which a determination is made as to whether the value of calculatedlevel exists in the map data. Assume that the answer is“Y”. Assume that level change threshold is 0.8. Then next calculation is ABS(2.85-2)> 0.8 -> 0.85 > 0.8 -> Ύ” at block 1 120.

[0099] Therefore current level changes from 2 to 3 at block 1 122.

[0100] A second example follows the left branch of the flowchart through steps 1 108- 11 12.

[0101] currentlevel = undefined, as this is the first calculation.

[0102] KF.Ievel = 2.2

[0103] calculatedlevel = round(level) = 2

[0104] Let us also assume that Map data does not include a floor level 2.

[0105] A block 1 108, a determination is made as to whether the value of calculatedlevel exists in in the map data. The answer is“N”. At block 1 110, the nearest map level to KF.Ievel is chosen. KF.Ievel“2.2” is closer to“3” than to“1”. Therefore, floor level 3 is chosen.

[0106] To explain KF calculations mathematically, the state of the Kalman Filter at time t is represented by: x _t \ _t = [l \, where X _t \ _t is the Kalman Filter’s floating point level estimate at time t. The level normalized change (LNC) computed from the barometer data is represented by, u _t = [Ah _t ], where Ah _t corresponds to LNC at time t. The expected level computed from the beacon data is represented by, z _t = [b _t \, where b _t is the expected beacon level at time t, i.e. the expected level computed from the beacon data currently in BDD. The state is updated with the LNC data at time t ( u _t ) using the prediction procedure of the Kalman Filter:

where F _t is the state transition model, and B _t is the control-input model, which are identity matrices of size l x l. P _t ^ is the predicted covariance estimate, and Q _t is the process noise covariance matrix, i.e., the error covariance of LNC { h _t ).

[0107] The state is updated with the expected beacon level at time t ( z _t ) by the correction procedure of the Kalman Filter

(12)

(13)

(14)

(15) (16) where y _t is the measurement residual. S _t is the residual covariance, K _t is the optimal Kalman gain, x _t \ _t is the corrected state estimate. P _t \ _t is the corrected covariance estimate. R _t is the measurement noise covariance matrix, i.e., the error covariance of the expected beacon level ( b _t ), and H _t is the observation model which is an identity matrix of size l x l.

[0108] Figure 12 shows a method in accordance with at least some embodments. An estimate of expected vertical location is generated, based on items of beacon data received from beacons by a radio receiver of the hand-held computing device (block 1210). In one example embodiment, an estimate of expected vertical location includes vertical position data 360 of Figure 3, such as a level within a building, which is generated by an expected level estimator 416 of Figure 4, based on items of beacon data 350 of Figure 3 received from beacons 1 12a-f of Figure 1 B by a radio receiver, such as short range wireless communication system 216 of Figure. 2, of the hand-held computing device (e.g., mobile device 200 of Figure 2). In some embodiments, the beacon data is read from a beacon data dictionary. In some embodiments, the generating the integer value representing an estimate of the expected level inside the structure based on a set of respective probabilities further includes generating respective level weights sums from probabilities for beacons on each of a set of levels from which the items of beacon data been received.

[0109] An error covariance of the estimate of expected vertical location based on the items of beacon data is generated (block 1212). In one example embodiment, expected level estimator 416 of Figure 4 generates an error covariance of the estimate of expected vertical location based on the items of beacon data 350 of Figure 3 received from beacons 1 12a-f of Figure 1 B. In some embodiments, generating the estimate of expected vertical location further includes generating an integer value representing an estimate of an expected level inside a structure based on a set of respective probabilities calculated at least in part from beacon data comprising beacon distances, beacon distance accuracies, and items of beacon data time information, wherein the beacon distance accuracies are calculated using respective venue-dependent accuracy constants.

[0110] A level normalized change is calculated based on measurements of barometric pressure made by a pressure sensor of the hand-held computing device (block 1214). In one example embodiment, a level normalized change is calculated by level normalized change module 420 of Figure 4 based on measurements of barometric pressure, such as barometric pressure data 366 of Figure 3 made by a barometer 214 of Figure 2, which is one example of a pressure sensor, of the hand-held computing device (e.g., mobile device 200 of Figure 2).

[0111] The vertical location of the hand-held computing device is calculated based on the level normalized change, the error covariance of the estimate of expected vertical location, and the estimate of expected vertical location (block 1216). In one example embodiment, the vertical location of the hand-held computing device is calculated based on the level normalized change, the error covariance of the estimate of expected vertical location, and the estimate of expected vertical location by predictive decision engine 418 of Figure 4. In some embodiments, the calculating the vertical location of the hand-held computing device further includes generating an integer value representing a level inside a structure based on a Kalman filter having inputs comprising the level normalized change, the error covariance of the estimate of expected vertical location, and the estimate of expected vertical location. In some embodiments, the inputs further include an error covariance of the level normalized change and the method further includes refining the error covariances using respective items of measured data. In some embodiments, the inputs further include an error covariance of the estimate of expected vertical location representing reliability of the items of beacon data.

[0112] A relevant map for a level comprising the vertical location is activated, and the vertical location is displayed on a display device of the hand-held computing device (block 1218). In one example embodiment, a relevant map from map data 306 of Figure 3 for a level comprising the vertical location is activated, and the vertical location is displayed on a display device 222 of Figure 2 of the hand-held computing device (e.g., mobile device 200 of Figure 2).

[0113] In some embodiments, the process repeats steps 1210-1218, iteratively calculating expected vertical location from beacon data and level normalized change estimated from barometric pressure and respective error covariances.

[0114] The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.