Active Topics

 



Notices


Reply
Thread Tools
Posts: 248 | Thanked: 1,142 times | Joined on Dec 2014 @ Earth
#71
Originally Posted by carlosgonz View Post
what happen with ZRAM is this available to jolla p1? if yes this will help with poor RAM.
By default, Jolla1 has 2 ZRAM swaps activated on boot.

It's also possible to use a (resilient) SD card for external (but slower) swap.

Note that external SD is limited to ~20MB/s on Jolla 1
(been there, done that).

use an SD card with ECC and static+dynamic weal levelling (e.g.: Transcend consumer cards, or most Industrial-grade cards).

Note that since Sailfish 2.2 switched to "udisk" instead of their home grown "sdmount.sh", you'd need to mount the swap manually.
(still doing that on my modern Xperia X).
 

The Following 5 Users Say Thank You to DrYak For This Useful Post:
pichlo's Avatar
Posts: 6,445 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#72
Wow, what a lot of interesting comments!

Slow search:
Thanks, I will try to turn on logging.

Inertial navigation:
Isn't there something remotely related there already? On a junction, the maps rotates as if assuming I am following the route, even when I am not. It takes a few seconds to figure out I am not and correct itself.

DrYak:
Whoa, that's a lot of new info! The speed bias for example would explain why every single car I have ever driven has always shown I was driving faster than the GPS was indicating.
__________________
Русский военный корабль, иди нахуй!
 

The Following 4 Users Say Thank You to pichlo For This Useful Post:
Posts: 248 | Thanked: 1,142 times | Joined on Dec 2014 @ Earth
#73
Originally Posted by pichlo View Post
Inertial navigation:
Isn't there something remotely related there already? On a junction, the maps rotates as if assuming I am following the route, even when I am not. It takes a few seconds to figure out I am not and correct itself.
Unless you have a smancy-fancy sat receiver (simultaneous multichannel GPS, Glonass, Gallileo + assisted, etc.), you don't get precision down to a few CM.

Most of the satnavs (including Pure Maps) do "snap to road".
They assume you're still on the road and not 1m outside of the road as current GPS position gives (due to errors, not enough visible sattelites and/or urban canyon).
So they automatically "map" you to the closest road.

The autorotation hapening despite you not taking a turn is simply the satnav guessing wrong when trying to "snap to road".

Using the in build accelerator would be an extremely crude and unreliable way to guess if a change of direction occured.

(Compass heading change would be better.
The best would be to ask the AI running on the camera for cars that have LDAS/FCAS.
Anyone motivated to port Comma.ai's Openpilot onto Sailfish ?)
 

The Following 4 Users Say Thank You to DrYak For This Useful Post:
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#74
Originally Posted by DrYak View Post
Note that since Sailfish 2.2 switched to "udisk" instead of their home grown "sdmount.sh"
I actually personally know some of the maintainers and the original author of libblockdev (which also started to be used with the switch to udisks). They liked it when I told them Sailfish OS started using it & one of them even has Xperia X with Sailfish OS.

Udisks is a daemon that provides DBUS API for storage management and it's what does flash drive mounting, LUKS container opening/closing and general dynamic storage manipulation on most modern Linux distros. So it's a good sign that also Sailfish OS uses it now, most likely to prepare for eventual LUKS based user data encryption support (based on what plugins are enabled in liblockdev on Sailfish OS). Not to mention it should be possible to monitor/manipulate storage by custom scripts/software by calling the respective udisks DBUS API.

But we might be getting a little bit off topic at this point.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 7 Users Say Thank You to MartinK For This Useful Post:
pichlo's Avatar
Posts: 6,445 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#75
Originally Posted by DrYak View Post
The autorotation hapening despite you not taking a turn is simply the satnav guessing wrong when trying to "snap to road".
The times when I noticed that, I was waaaaay beyond the positioning accuracy. Maybe a combination of accuracy, refresh rate and... err, something else.

Whatever it is, all I was suggesting is that some rudimentary basis for continuing along the route within a tunnel may already exist
__________________
Русский военный корабль, иди нахуй!
 

The Following 4 Users Say Thank You to pichlo For This Useful Post:
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#76
Originally Posted by pichlo View Post
The times when I noticed that, I was waaaaay beyond the positioning accuracy. Maybe a combination of accuracy, refresh rate and... err, something else.

Whatever it is, all I was suggesting is that some rudimentary basis for continuing along the route within a tunnel may already exist
OK, it depends on which version are we talking about.

During navigation, WhoGo/Poor Maps used direction of the route you were navigating on. Same is done in Pure Maps, unless you ticked "Snap to road" at the navigation page.

With snap to road, map matching is used to guess on which street you are using the few last coordinates along your movement and assuming that you are moving with the specified transportation (car, bicycle, ...). Snap to road/map matching works quite well, but you could hit an issue or two next to the turns (it sometimes guesses wrong, sometimes gets stuck for 10-20 or more meters).

PS: not much about the tunnel in this case, since it was matching the last known position to the route or road network
 

The Following 4 Users Say Thank You to rinigus For This Useful Post:
pichlo's Avatar
Posts: 6,445 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#77
So, I spent a lot of time playing with it yesterday and had some, let's just say interesting results. All on J1.

Originally Posted by rinigus View Post
Slow searches using OSM Scout Server.
I have added OSM Scout Server support for autocompletion on WhoGo side, but the server itself doesn't have any fancy algorithms made for such scenario specifically. It just runs the full search on every new input. So, maybe it has queued some searches before you get to the last of it.
You may be onto something here. I saw a few partial searches in the log last night. For example, searching for "Lancelot Court, Hull" took about 1:10 and yielded about 20 results, none of them to the exact place but all of them containing part of the address string (for example, "Hull Road, London" - made up as I do not remember the exact example but I hope you get my drift).

I could not reproduce it again, every subsequent search for the same address gave me one exact result. But I did see entries in the OSM server log that looked a bit like this (this is a repeated test this morning, with the same result):
Code:
INFO: 08:54:55 Request: /v1/search?limit=25&search=Lanc
INFO: 08:55:38 Parsed query [GB]: house: {lanc}; 
INFO: 08:55:38 Parsed query [GB]: h-0: {lanc}; 
INFO: 08:55:41 Request: /v1/search?limit=25&search=Lancelot+Court,+Hull
INFO: 08:56:19 Parsed query [GB]: city: {hull}; road: {lancelot court}; 
INFO: 08:56:19 Parsed query [GB]: h-0: {hull}; h-1: {lancelot court};
OK, I thought, I can understand partial search queries resulting from the instant search while typing. But what if I enter the address quickly, for example by pasting it or selecting from history? So I tried:
Code:
INFO: 09:04:16 Request: /v1/search?limit=25&search=Lancelot+Court,+Hull
INFO: 09:04:51 Parsed query [GB]: city: {hull}; road: {lancelot court}; 
INFO: 09:04:51 Parsed query [GB]: h-0: {hull}; h-1: {lancelot court};
As you can see, there is always a 30-40 seconds delay between the "Request" line and "Parsed query". That cannot be explained by partial searches.

Geocoder, again, and missing streets
This looks like a map problem rather than the maps client's. Here is my example. I searched for "Redwick Road, Magor" and got no results. Then I changed the search to just "Redwick Road" and found a match... in Magor! Except that the search result did not say it was in Magor, it said it was in Monmouthshire. Here is the query and the location for your entertainment:

Code:
INFO: 09:13:01 Request: /v1/search?limit=25&search=Redwick+Road
INFO: 09:13:02 Request: /v1/mbgl/style?style=osmbright-car-en
INFO: 09:13:35 Parsed query [GB]: road: {redwick road}; 
INFO: 09:13:35 Parsed query [GB]: h-0: {redwick road};
Name:  Screenshot_20180829_001.jpg
Views: 281
Size:  22.1 KB


Originally Posted by pichlo View Post
The voice instructions told me to turn into A404, which it pronounced as "eigh-four-four" instead of "eigh-four-oh-four". This happened several times, so I was not hearing it wrong. Or maybe I was but consistently
I noticed that again, on the same road. Then, about 30 minutes later, on the A423, the voice instructions said "eigh-four-twenty-tree" rather than the expected, "eigh-four-two-three".

So I guess something somewhere is trying to be too clever and splits longer numbers into groups of two digits. A423 into A-4-23, A404 into A-4-04. Then something else is being even more clever and shortens 04 into 4.


Lastly, I am encountering this issue every time, no matter how long or short the route or the navigation session is. It was first observed in WhoGo and is still present in Pure. Life is too short so I am always rebooting at the end of navigation.
__________________
Русский военный корабль, иди нахуй!
 

The Following 7 Users Say Thank You to pichlo For This Useful Post:
mosen's Avatar
Community Council | Posts: 1,669 | Thanked: 10,225 times | Joined on Nov 2014 @ Lower Rhine
#78
Originally Posted by rinigus View Post
OBDfish and the tunnel problem

I am sorry, but while it sounds cool, I think there are many other things that have to be done before that.
Do not be sorry, please. I am happy enough that i could explain the point and it turned out to be not too crazy Just wanted to plant the seed.

User experience wise, CAN bus integration is kind of the only feature (besides a nice positioned screen) stock nav solutions have over mobile applications.
And it is heavily used as a selling point by car sales persons if you start talking against stock navs and their shortcomings regarding map updates and such.
So they are fully aware of the feature

This is a topic since 2006 for me when i bought my first garmin "nüvi" and was utterly disappointed that it strictly relied on gps, still costing 800bucks back then.
I did not even investigate into this before buying and was expecting it would be hooked into can bus as my former THB Bury Naviflash system from 2004 was. Thanks gamin and alikes for watering the term "car navigation" to brake into the market i guess.
 

The Following 4 Users Say Thank You to mosen For This Useful Post:
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#79
@pichlo, great job! My replies below.

Originally Posted by pichlo View Post
... searching for "Lancelot Court, Hull" took about 1:10 and yielded about 20 results, none of them to the exact place but all of them containing part of the address string (for example, "Hull Road, London" - made up as I do not remember the exact example but I hope you get my drift).
Yes, that's an expected one. Its not very good in autocomplete due to the difficulties in parsing of sub-strings. However, it does start to pick up correctly while you type in the string and I have found it rather helpful.

Originally Posted by pichlo View Post
I could not reproduce it again, every subsequent search for the same address gave me one exact result. But I did see entries in the OSM server log that looked a bit like this (this is a repeated test this morning, with the same result):
Code:
INFO: 08:54:55 Request: /v1/search?limit=25&search=Lanc
INFO: 08:55:38 Parsed query [GB]: house: {lanc}; 
INFO: 08:55:38 Parsed query [GB]: h-0: {lanc}; 
INFO: 08:55:41 Request: /v1/search?limit=25&search=Lancelot+Court,+Hull
INFO: 08:56:19 Parsed query [GB]: city: {hull}; road: {lancelot court}; 
INFO: 08:56:19 Parsed query [GB]: h-0: {hull}; h-1: {lancelot court};
OK, I thought, I can understand partial search queries resulting from the instant search while typing. But what if I enter the address quickly, for example by pasting it or selecting from history? So I tried:
Code:
INFO: 09:04:16 Request: /v1/search?limit=25&search=Lancelot+Court,+Hull
INFO: 09:04:51 Parsed query [GB]: city: {hull}; road: {lancelot court}; 
INFO: 09:04:51 Parsed query [GB]: h-0: {hull}; h-1: {lancelot court};
As you can see, there is always a 30-40 seconds delay between the "Request" line and "Parsed query". That cannot be explained by partial searches.
Note that Poor/WhoGo/Pure maps cache the search results and will not bug the server if the string is the same as before. So, to search again, you would have to close/open the map client.

Time difference between request and parsed query is induced by libpostal. So, in your case, that's a performance limitation (RAM/CPU/all together). Not much can be done by me here, unfortunately.

Originally Posted by pichlo View Post
This looks like a map problem rather than the maps client's. Here is my example. I searched for "Redwick Road, Magor" and got no results. Then I changed the search to just "Redwick Road" and found a match... in Magor! Except that the search result did not say it was in Magor, it said it was in Monmouthshire. Here is the query and the location for your entertainment:

Code:
INFO: 09:13:01 Request: /v1/search?limit=25&search=Redwick+Road
INFO: 09:13:02 Request: /v1/mbgl/style?style=osmbright-car-en
INFO: 09:13:35 Parsed query [GB]: road: {redwick road}; 
INFO: 09:13:35 Parsed query [GB]: h-0: {redwick road};
If you see at OSM, Magor is added as a node. As a result, its hard for the geocoders to figure out whether that street is in Magor or next to it. Same problem is in few other countries. Some geocoders are a bit better than others in guessing that its in Magor. I will have to work on it and search for solutions.

Originally Posted by pichlo View Post
I noticed that again, on the same road. Then, about 30 minutes later, on the A423, the voice instructions said "eigh-four-twenty-tree" rather than the expected, "eigh-four-two-three".

So I guess something somewhere is trying to be too clever and splits longer numbers into groups of two digits. A423 into A-4-23, A404 into A-4-04. Then something else is being even more clever and shortens 04 into 4.
that's a bug then on Valhalla's side, I think.

Originally Posted by pichlo View Post


Lastly, I am encountering this issue every time, no matter how long or short the route or the navigation session is. It was first observed in WhoGo and is still present in Pure. Life is too short so I am always rebooting at the end of navigation.
Bäd news. I hoped it was solved by Osmo in one of his commits. Will open an issue, its a nasty bug. Have you tried killing Pure Maps, as was suggested in that thread?
 

The Following 5 Users Say Thank You to rinigus For This Useful Post:
Posts: 191 | Thanked: 271 times | Joined on Mar 2015 @ Germany
#80
I have been worked a little bit on translation, for german.

I need help, evtl. one or more person get in transifex.

 

The Following 6 Users Say Thank You to monkeyisland For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 11:21.