| | 01-03-13, 12:03 PM Thread Author #1
LittleBrother v2.0 RELOADED (by emacberry)
actually after the central WebService LocationProvider for LittleBrother v1.x have stopped working (see forum.emacberry for details) I have thought over the past few days about a possible solution to continue the app - without loosing the efficiency. I am some sort of happy to share with you the news, that I have created a v2.0 version of LittleBrother that DOES NOT NEED any central database - instead the device GPSProvider is used to detect the location by itself and storing this location fix for later use.
So at the beginning of the usage of LittleBrother, the GPS-Signal is used to get your location - and once the location is approved (by multiple fixes over the time) it will be later used right away for all the known LittleBrother notifications & functions you are used too.
Getting LittleBrother v2.0
Point your BlackBerry browser (min OS5.0) to http://www.emacberry.com/ota/lbrother.jad
Here is the "Theory"
Assuming you are starting with an empty CellTower & WLAN DB. You can purge your existing DB's to get a fresh start (which makes the identification of the NEWLY generated CellTowers/WLANs in the local database list much easier). When you decide to purge your existing DB content then please read the the section 'Purging your existing CellTower & WLAN DB's carefully!
For testing purposes I would kindly ask you to purge your local DBs - but only if you feel comfortable to do so.
If no location information is available (e.g. cause you are inside a building) LB will not try to get a gps-fix for this CellTowerId/WLAN again for the next hour (60min) - this should avoid the situation that LB is draining your device battery when you are all day inside a building [it have to be evaluated during the testings, IF this approach is acceptable].
If a location information IS available, the information will be stored with the CellTowerId/WLAN and all the LB functions & notifications will be executed based on this initial location. In the CellTower/WLAN DB List you will see that with each of the entries you find an additional information about the location source - for an initial gpx-fix based location you should see the info "[GPS_T(0)]".
This means, that this CellTower/WLAN location is based on a gps-fix, and the T(0) indicated, that this is a TEMPORARY location, that is based on a single fix. It's important to know, that LB will not request a gps-fix for such a Celltower/WLAN in the next 4h (as long as you don't reboot your device in the meantime). When your device is connecting itself again to this CellTower/WLAN within the next 4h, LB is using the location of the initial gps-fix.
Once the 4h mark have been passed and your device is connecting to the same CellTower/WLAN, LB is trying to get an additional gps-fix - if no fix could be received, LB is not requesting a location again for the next 1h (same as before) - if a second gps-fix could be detected, then LB is calculating the difference between the initial gps-fix location and the new one.
If the new CellTower gps-fix is more then 300m (980ft) away [for WLANs a minimum distance of 15m (50ft) have been selected], then LB takes the average value of the Latitude & Longitude of both fixes and stores this average value as new location for the CellTower/WLAN. In the CellTower/WLAN DB List you will see that the T(count) value should be increased by one - indicating, that the stored location of this entry is based one more then one gps-fix.
This procedure will now repeat itself over the time - till the "GPS TEMP counter" have reached 5 (five) - when LB have requested a gps-fix five times for a CellTowerId/WLAN, the application assumes, that the created average location value should be fairly "ok". These locations will be marked as "[GPS_FULL]" ([Qualified GPS Location]) in the DB-Overview list. From that point LB will not fire up the GPS-Antenna of your device for the specific CellTower/WLAN to update the location - it will be considered as fixed and will be used for the LB functions & notifications.
Purging your existing CellTower & WLAN DB's
Please take a moment to read about the consequences of purging your current DB's - and what you should do in order to be able to restore the DBs later (if needed/wanted) and what could be the consequences of an empty DB
- Use the DesktopManager Software to create a local backup of your existing "LittleBrother CellTower DB" (this includes WLANs as well - despite of the name)
- Make sure that this backup worked...
- Purge your local WLAN & CellTower DB's in LittleBrother [this is really important]
Open the LB Options - select "Local CellTower Database" - select 'Show local Database' - open the BB-Menu and select 'Purge LocalDB'
Open the LB Options - select "Local WLAN Database" - select 'Show local Database' - open the BB-Menu and select 'Purge LocalDB'
Please note, when you have Purged your DB, all CellTower/WLAN-List Sectors [Sector definitions that are just a list of CellTowerId's or WLAN's] will not work any longer, simply cause the Sectors have only stored the location information of each CellTower/WLAN (and NOT it's ID).
When you have recreated the CellTower/WLAN DB with the help of various GPS-fixes (CellTowers/WLANs will be listed with the addon "[GPS_FULL]" ([Qualified GPS Location]) in the DB-Overview list, then you can stat to recreate these Sectors based on the final (LB self calculated) CellTower/WLAN locations.
Most of you will be concerned about CPU-Usage (=Power consumption) - specially when traveling - LB have always cost some CPU when traveling - since with every new CellTower/WLAN that have been detected, the app have send a request to the internet (in order to get the location) - this has cost some CPU.
Since mid of November 2012 the central LB WebService is not providing location information for CellTowerIds/WLANs that had not been requested before (by you or other LB users). With that you might have also noticed, that the overall CPU usage of LB v1.x have went massively up (which is not good at all) - this demonstrate very drastically that the WebService Requests are also not "free".
On the other hand side when I use my other location based application (GPSLogger II) - I have realized that CPU-usage was not too bad (even with an update interval of 1sec) - comparing the CPU Usage of LB with GPSLogger (for a walk of 1h) the comparison was quite surprising - GPSLogger used even less CPU then LB (of course this was cause LB have requested multiple times the CellTowers and WLANs).
When comparing the WebserviceRequest-Method vs. the gps-fix-Method then both seams to have their advantages - while WebService is always require an internet connection for new locations, the gps-fix-Method relays on the availability of the GPS-signal - which is in general quite bad inside of buildings and still far from being optimal near large buildings or trees - and sometimes even on bad weather. Of course the "optimal" solution would be a combination of both - but since GoogleGears-Service have been shut down this is just theoretical [but I am still working on that end as well (find a location WebService alternative)].
LB 2.0 have been implemented in a way, that should prevent extended CPU-Usage by requesting too much gps-fixes:
Please note, that both of these "caches" will be wiped on a device reboot - so when you frequently reboot the device you might notice additional gps-fix requests.
- If for a CellTowerId/WLAN no gps-fix could be received, LB stores this as failed attempt and will skip a second gps-fix request for the next 1h for the same CellTowerId/WLAN. This one hour mark is a first attempt (and it's currently hard coded) - might be with later versions I can add a Expert-Configuration-Option which allows you to adjust these values.
- When a gps-fix could be initially received then LB also stores this successful request and skip any further gps-fix requests for the next 4h for this CellTowerId/WLAN. Have in mind, LB is trying to get a maximum of five gps-fixes for each CellTowerId,WLAN and calculate the average location of all fixes.
- When for a CellTowerId/WLAN no gps-fix could be received for 50 times, then LittleBrother will 'BlackList' this CellTowerId/WLAN from any further gps-fix requests (simply ignoring it)
You can then enter the location for this CellTowerId/WLAN manually in the Database list. Permanently failed entries can be identified by the addon '[GPS_FAILED]'
You can enable toe DEBUG-LOG function of LB in order to see the failing gps-fix request (including the failing reason).
Also you have always the possibility to enter the location information for a CelltowerId/WLAN manually via the Database List - a manually entered/modified location will be considered as constant - and will never be requested again.