[Loadstone] Loadstone enhancements (updated)

Shawn Kirkpatrick shawn at loadstone-gps.com
Thu Feb 5 10:17:19 GMT 2009


I'll go thrue your list point by point and give my feedback.

- Problem: Automatic route creation, perceived as the most important, most useful and long-awaited ability of navigation software for the blind, is very limited and time consuming in Loadstone, especially without any access to the PC, on-line tools and the Internet.
Route creation is understood here as an automatic guidance from one point to another, which includes recording, playing, browsing and reversing a path.
Chained points are on the todo list. We're going to need this before any kind
of route planning can be built. This will involve a way to browse the
checkpoints and options for manipulating them.
I really don't want to make any of these functions depend on the internet.
This may happen at some point but not for quite a while.
The breadcrumb generator may be integrated at some point depending on how well
it actually works.
* Solution 3: Introducing additional Settings tab, called "Logging", which acts as a kind of NMEA sentence filter.
The idea is: In order to make a route creation process less complex, to decrease amount of data processed on a phone or server, and to transform Loadstone into a powerful data logger, such as Wintec WBT-201, Royaltek RBT-2300 etc., you can set which NMEA data and under what conditions are to be saved in a .log file. These conditions are as follows
(Note that ideas below are based on different hardware data loggers and on Aspicore GSM Tracker application):
(Automatic mode):
-- Entry saving upon a specified time interval (eg. every 5 seconds).
-- Entry saving upon a specified distance (eg. every 50 metres).
-- Mix of both (eg. NMEA entries are saved every 5 seconds, unless the distance of 50 metres is exceeded before).
-- Entry saving upon a specified time interval, depending on the velocity (eg. within speed of 1-10km/h - every 5 seconds, within speed of 10-50km/h - every 10 seconds, etc).
-- Dynamic platform: smoothing of speed deviations, too rapid and non-typical for a particular transportation mode.
-- Maximal speed above which the entry is not created.
-- Maximal accuracy (HDOP) above which the entry is not created.
-- Minimal angle (eg. 20 degrees) - entry is saved only if heading equals or exceeds this value.
(Manual mode):
* Solution 3B: Push-to-log: a mapable key (eg. long #), which causes manual adding NMEA entry when key pressed.
I'm really not sure why we'd need or want such a complex logging menu. I'm
thinking a setting to exclude data if there's no signal may be nice to cut
down on invalid data but other than that I'm not sure what else would be
needed.

- Problem: Loadstone database engine for phones with SYmbian 3rd Edition (eg. Nokia N82) seems to work more slowly than on Symbian 2nd phones (eg. Nokia 6680), especially during import or export.
This probably has to do with your memory card more than the phone itself. Do
this test with loadstone installed to the phone memories and see what the
results are. We can't test every combination of phones to verify this. In my
experience the third edition phones are faster than the previous generations.
Major differences in speed can be noticed depending on the type of memory card
used. Not all memory cards are created equal.

- Problem: Polish RealSpeak "goes mad" and reads point information in a completely incoherent way.
As a consequence, it is impossible to use the official version 0.71 at all.
This glitch has been fixed in the latest testing version. This problem occured
because the Polish beta testers/translaters didn't do the propper testing. In
the future when messages are posted to the beta and language lists maybe people
will pay more attention.

- Problem: When Loadstone catches a fix, but the user doesn't move, then instead of a message eg. "Last heading: North", there is: often a message "Speed: 0km at , heading: North"
(message translated from Polish).
The solution to this is to set your static threshold setting to an appropriate
value. This is probably happening due to decimal point rounding errors. A bit
of tweaking could probably be done to ignore speed values that are obviously
too low.

- Problem: It is tricky to refresh status of GPS fix (key 3 in navigation mode).
You have to choose another shortcut and press 3 again. Multiple pressing of "3" causes no reaction.
It actually does work like all other options. This bug is caused by talks or
symbian not wanting to reprint the same string more than once. I'm not sure if
this is a talks or symbian problem. The way we normally get around it is to
switch the case of the first letter of the string. Of course this doesn't work
if the string starts with a number. Maybe there's a better work around for this
problem.

- Problem: It's impossible to use all the localization technologies for a particular receiver simultaneously.
How would you connect to multiple technologies at once? you only want input
from one receiver so you have to select which one.

- Problem 1: Selecting GPS receiver (internal or Bluetooth) is too complex.
It requires goig both to Settings and to GPS menu.
Therefore it is not confortable to quickly switch between different GPS receivers.
This is more of an opinion than a problem. An option to temporarily switch
receivers might be added to the gps menu.

Problem 2: Internal receiver doesn't work properly or doesn't work at all on Nokia N82.
Can you specify? On the n82 I was testing the internal receiver worked fine.
We've had reports of bluetooth connections not working on the n82 if phone is
selected as the gps source. This seems to be specific to the n82 thoe since
this combination seems to work on other phones.

- Problem 1: The technology Bluetooth appears even under Internal receiver technologies.
This is not a problem. The choice is called phone and will present any
technologies the phone has that are able to deliver nmea sentences. This list
may be effected by choices made in the phone's positioning settings. Usually
the list will include bluetooth. You might want to use this if you wanted to
use your receiver with more than one program at once or if this method worked
better than loadstone's internal bluetooth code. You may prefer Loadstone's
bluetooth code if you don't want to pair the receiver with the phone or if the
phone's bluetooth isn't working as in the case of the n82.

Problem 2: In spite of choosing that "Bluetooth", there is "No signal" message" even if Bluetooth receiver is turned off.
So far nobody has reported this. Can you provide more detail?

Problem 3: As it can be observed on the Loadstone mailing list, that "bluetooth" present under Internal receiver, causes a mess and is not clear for most users.
This was explained above. Removing a choice probably isn't a good idea.

- Problem: If during an import process the user doesn't keep watching over the phone, he won't know if all points had been imported or which were wrong and why.
A summary is displayed at the end of an import. Maybe an ok option or
something could be added.

- Problem: Loadstone options are sometimes unclear.
This is an opinion rather than a problem. Menu items seem to have a limit of
22 characters so sometimes we have to compromise with option names.

* Solution 2: The filename "DefaultBluetoothGPS" should be renamed into "DefaultGPS", as the default may be internal, not bluetooth receiver.
This is correct since this default only effects the bluetooth gps source
choice. There's a default_module file for the phone gps source choice.

- Problem: Some options are available even if they cannot be used at all.
* Solution 1: If a point is checked, then an option "Check point" should not be available for this point.
* Solution 2: If a point is locked, then an option "Lock point" should not be available for this point.
This is the case. Can you provide examples of when this goes wrong?

- Problem: At least in Polish version, there is not enough space for UserId in a window "About" and it doesn't show up.
(Unfortunately, the license message cannot be shortened due to translating reasons).
I think the solution to this is to put the about screen in a scrollable text
box with an ok button.

- Problem: Point announcement parameter (setting to 0) is not consequential.
What setting are you referring to?

- Problem: It's not clear how to show all the search results in one list.
You wouldn't want it to do this. Depending on the size of your database it may
take a very long time before any results came back. Depending on the number of
results the phone may run out of memory trying to store them. The way it is
now you get results in a reasonable amount of time. If you want more results
there's the continue option. If you want to see the effect of having all
results at once try setting the search results setting to a very high number.

- Problem: Checkpoints are sometimes announced too early or too late.
* Solution: In checkpoints announcement, the priority should be given to approach distance and not to approach time, as the distance seems to play more crucial role here.
This is completely wrong. The time is the only important setting. You wouldn't
want it based on distance since the time to arrival would depend on your
speed.

Problem: Many users ask for easy automatical announcements of points which are being passed.
The problem here is that the constant checking of the database could cause the
program to go non-responsive for several seconds at a time. This is not what
people want. The real solution to this would be a better database engine.

- Problem: Manual checking of a large number of points is quite "laborious" without access to a PC and on-line tools.
There's an upper limit of how many checkpoints you could have at once. Trying
to select an entire database would most likely cause the program to run out of
memory. There could be an upper limit but then how would you decide what points
to select?

- Problem: Operations made on checkpoints list files is quite difficult without access to a PC and on-line tools.
There will probably be a browse checkpoints option as mentioned above. From
there there will be options to manipulate checkpoints.

- Problem: Quick showing or checking of points recently added to database, requires too many key presses and good brain memory. It is not always easy to remember the names and sequence of added points.
This could probably be implemented. Trying to sort the database in this way
could take a very long time depending on the size of the database.

- Problem: It is quite tricky to find out when a point was created, especially without any access to the PC, on-line tools and the Internet.
I'm thinking there'll be a show point details option to display all
information about a point. The creation date might be a bit hit and miss thoe.
Points created with various conversion tools will have ids in the past and
points created on people's phones will have different time zones.

- Problem: Point removal can be achieved only partially. They change priority to 4, but still exist in the database, making that large and messy.
It's difficult to filter out such points without any access to the PC, on-line tools and the Internet.
Loadstone will ignore deleted points. They have to stay in the database thoe
because in case that database is exported to the point share the point share
has to know that the point has been deleted. Maybe there's a better way of
handling this. This really shouldn't be a problem unless you have a large
number of deleted points.

- Problem: Quick update of a nearest point requires quite many key presses.
I'm thinking of adding a last point menu that would have various options for
handling the last point referenced.

- Problem: If one uses Auto-Announce quite often, then has to turn it on each time Loadstone is started.
This could probably be implemented. I've personally never used this feature so
haven't given it much thought.

- Problem: It happens that there is no time for making a text label to a point.
Voice labels are on the todo list. There's a few problems to be worked out
thoe. We have to get sound recording and playback working on all phones. Then
we have to get sounds to play in sync with talks or mobile speak, this could
be the tricky part.

- Problem: Loadstone menu is not always intuitive enough.
This is more of an opinion rather than a problem.
* Solution: It might be rearranged for better operation, as follows
(Note that only suggested changes, and not the whole menu structure is presented below):

*** Mode: Exploration mode, Navigation mode, Training mode.
The exploration and navigation modes are exclusive to one another. The
training mode probably isn't going to be used very often. Putting these in
there own submenu would probably just add to the number of key presses since it
would make the main menu longer.

*** Memos: Record memo, Play memo, Browse memos
The whole memo system needs a lot of work.

*** Tripmeter: Start / Show / Pause / Resume / Stop (tripmeter).
Not sure what the difference between stop and pause would be. The trip metre
options may get a submenu. This would shorten the menu where they currently
are but lengthen the main menu.
The trip metre may get additional information, not sure about that yet thoe.
It may be more trouble than it's worth.

*** Logging: Start / Show / Pause / Resume / Stop (logging).
These may get a submenu but not sure. What's the difference between stop and
pause in this context? What would show do? The ability to create multiple log
files will probably go in.

*** Help: About, License, User ID.
Probably easier to just have the about screen in a text box unless we can build
a more comprehensive help system.

- Problem: Loadstone shortcuts are not always intuitive enough.
An opinion rather than a problem. We're never going to get everyone to aggree
what these should be so that's why they're mapable. A built in keymap editor
is on the todo list but it's easier said than done.

- Problem: It is easily forget to save checkpoints.
This is on the todo list and will probably be in the next version.

- Problem: Checkpoint file format deviates too much from database format.
Therefore it is more tricky to create checkpoints on PC and forces user to make additional text edition steps.
This was done on purpose for a couple reasons. The first was we needed to
store more information about a point including an extra comment that doesn't
exist in the database. We needed to be able to automatically convert old
checkpoint files to the new format. The format isn't the same as the database
format to prevent people from trying to import a database in to the checkpoint
list and then complaining when this failes. The layout of fields in the
database files is decided by the database engine and should not be counted on.
This is why there's table headers at the top of each table. Coordinates in the
new checkpoint file format can be integers like in database files or decimal
numbers like in the old format. Decimal numbers are currently used since it
was easier from a programming point of view.
This format isn't going to change unless there's a very good reason to do so.

- Problem: It is difficult to observe the progress of import, export or search.
* Solution: During these operations, only the message eg. "Importing..." should appear on the screen, 
with a progress bar (read by Talks, as in the case of software installation);
under SoftKey 2 - "Cancel", under SoftKey 1 - nothing.
Doing this would prevent the program from doing anything else, possibly for a
very long time. Depending on the phone this may be pretty much the case but on
a faster phone you can still do other things. In the next version there'll be
periodic updates while importing and exporting.

- Problem: In case of search results, area results etc., it's impossible to determine at which item of a list the focus is placed.
This data isn't a standard list because a listbox is unable to display the
amount of data we needed. I'm not sure if there's a good work around for this.

- Problem: Making new Loadstone users to learn shortcuts more efficiently.
We hit the 22 character menu item limit again. A shortcut name could be quite
long such as long shift 1. This would leave very little room for the function
name. Maybe there's some other way of doing this?

- Problem: Sometimes it would be practical to use several databases at once.
This is currently being worked on and will be in the next version.

- Problem: Auto-Announce interval is limited by the predefined values.
This just isn't true. If this interval is set to 0 then the interval is
automatically calculated. If set to a non-zero number then that interval is
used.

- Problem: Although "Use checkpoints only" is checked, Loadstone shows different points from the database.
It's presumed that if you do a show area or search then you probably want to
know about points you don't have checked. Maybe this isn't always the case.

- Problem: It's not possible to get automatical info of proximity to a locked point.
We may treat the locked point like a regular checkpoint. It's something to
consider.

- Problem: Sometimes there is a need for quick remote sharing current GPS location or a given point.
We're currently working on this. Some of it might be in the next version.

- Problem: It is tricky to make a selected database and checkpoint file loaded at startup.
Pretty easy really, just call the file default and all is fine.

- Problem: It is not intuitive for some users that in order to apply Settings, additional SoftKey1 (OK) press is required.
It's nice to be able to look at the settings without changing them. An
ok/cancel just makes sence. These buttons may be able to be changed to
save/cancel thoe.

- Problem: Upon Loadstone crash or battery discharge, all settings are gone and have to be made for scratch.
This has been talked about. Sometimes this would be nice but you don't always
want this to happen.

- Problem: It is possible to enter capital letters under "Update point" option, 
but it is not possible to search for capital letters under "Find point" option.
This really isn't a problem since the strings are converted to lower case
before saving. At some point it may be possible to enter upper and lower case
as normal and have it save in the database.

- Problem: Comment field placement.
The database needs a lot of work. We want a lot of additional information
but this will require breaking the existing database format. This will happen
at some point but I'm hoping to have a new database engine when it does.

- Problem: Searching, browsing and exporting of points is quite limited.
Categories will go in when we change the database format. We'll also have to
come up with a usable list of point types. We also want to add address and
phone number fields.

Do not try replying directly to this message since it's rather long, start 
another thread.


More information about the Loadstone mailing list