Messages

rijackson741 - your question is really, really good. When you want to buy a memory card for your devices, this big question always pops up: which speed class do I really need in this device? And it is almost always no clear answer, no device spec, no guideline. It is absolutely true that a higher speed memory card has no effect if the memory channel becomes the bottle neck. But flash memories are extremely slow devices when comes to band width. This is due to the semiconductor physics behind the storage technology. RAMs and flash memories are using completely different technologies. We use flash memories for two reasons: storage density and non-volatile capabilities (keeps stored data without power). So when you power on a device, it takes time because programs and data need to be copied into the fast working memory - RAM.

So back to the band width: class 4 = minimum write speed 4 M bytes. I do not know the bus controller used in the phones for the memory port, but to handle the 10MB speed of Class 10 devices is really a piece of cake. Compare to USB 2.0: channel speed 480 Mbit/s, i.e. about 60 Mbyte/s. These numbers are not exact due to overhead in bus operations and protocols. So I can't believe the bus controller to a memory card can be the limiting factor (but as I said, i do not know which controller is being used). You may not find phone operations faster with a class 10 over class 4, but you *may* solve burst write problems. I never had any phone crash problems before I instaleld Locus, and I don't know how/why Locus is involved in this. Menion has been very cooperative and did his very best to help me for a long time. The last thing to try now, was another memory card. And so far, that seems to make the difference.

What can class 10 do for you? You will certainly not need that bandwidth over time, but the point here is to be able to handle a burst of read/write requests. The a class 10 card will certainly be able to handle the queue in a shorter time than a class 2 device. When I bought my first 32GB card last December, I was even wondering if I needed class 4. There is a significant price step between the speed classes, and at that time class 10 was up in the skyes. The memory card issues that seem to be the root cause of my phone crashes, may not be the speed class, but could very well be initial production problems since I got hold of one of the very first 32GB class 4 microSD cards that became available on the market at that time. The web shop where I bought the card accepted a replacement without any further questions. And to rule out any possible bandwidth related issues, I decided to spend the little extra now between class 4 and class 10.

This sounds very much like the same problem I have been fighting with for the last 4 months. Refer my thread " Serious phone hang issue while recording - test results".

'wldbest' is saying "When locus & system enters powersave mode(screen off), the crash occurred ..". This is exactly what I observed dozens of times. After trying all kind of settings and tests, Menion recommended me to try another memory card. After I did that 4 days ago, I haven't had any problems at all.

Even though memory cards are speed classified, that class is minimum guaranteed speed. Because of production tolerances, there will always be a distribution of speeds of the actual cards from different production lots, some may be at the guaranteed minimum speed, but several will also be faster (I am designing integrated circuits and know these details very well, so trust me).

So my point is that if several processes are writing to the memory card at the same time, some writes may be queued and take longer time. If a process doesn't handle timeouts correctly, it will certainly crash. I am pretty sure that when you turn on/off the screen, there is some status writing to the memory card. That can explain why I found most crashes to happen when I turned on/off the screen. I was using a 32GB Class 4 card when I had all these crash problems. When I changed to an old Class 4 8GB card, I haven't had a single crash - so far (just 4 days of experience)! Even though same speed class, the actual speeds may be slightly different such that one card works smoothly and the other card causes crashes. I am now waiting for a new 32GB Class 10 card. That should at least solve any speed related issues, so I am crossing my fingers. You may want to try same thing.

svartbjorn: you're able to record tracks without crash now? How's this possible?

Thanks for asking Menion, how my phone is doing without crashing. I did what you suggested: replaced the microSD card. I copied the whole contents from the 32GB microSD card to my PC, put back in my old 8GB card and simply copied back from the PC to the microSD 8GB in the phone (just leaving out some large Locus and Copilot maps due to less space). Everything came up fine. I didn't have to reconfigure anything. This is only 3 days ago, so limited experience. But I record all the trips I make to test this out. So far both the Locus recording and the phone have been rock solid! I do not feel convinced yet until I have gathered some more experience.

The net shop where I bought the 32GB card 7 months ago, accepted a replacement without any further questions. I'll get the new 32GB card (same manufacturer Kingston) next week. My guess is that there could have been some initial production issues since I got hold of one of the very first samples of the 32GB Class 4 card that become available on the market from Kingston. A colleague of mine has the same phone and same 32GB card and has had no issues at all with Locus recording, but he bought his card much later than me. So I am crossing my fingers hoping that it really was the microSD card that was the root cause of all these troubles the last 6 months.

Thanks for answering, Menion. But I think we are not on the same page.

You are saying that "if this does not work correctly with values above 60s, don't use it". But that is not what I am reporting. Any value at 1s and above works as expected, also any value above 60 seconds.
And I am fully aware of the power saving benefit of setting a value above 30s or so.
But my point is at the 0s-1s end. When you are driving a car or are biking, you need continuous position updates to make the right turn at intersections. And this works fine with 1s. And it also worked with the 0s default setting until I tried a higher value to save power. The 0s setting used to keep the GPS receiver on all the time. But now the 0s setting is ignored, Instead the previous setting is used.

To summarize: Any setting at 1s and above works exactly as expected, but the 0s setting is simply ignored. And 0s is your default setting, so it is supposed to mean continuous on.

Hi Menion. Do you have any comments? I noticed yesterday that when the accuracy is good, the 1s setting will cause the GPS status to flash on/off once/1s (as expected), so we need the 0s setting to keep the GPS receiver on all the time. And again, this is your default setting and hence is supposed to work, right?

Exactly same thing happened to me yesterday, using the latest version of Locus Pro.

I was out flying. Screen on all the time, GPS posistion every 1s, recording point every 2s. It was 1 hour flight, and the red recorded line showed up on the screen, continuously updating.  But about 3 minutes before landing, the red track stopped, but my position was still updated. After landing, everything looked normal except for the missing last 3 minutes. The recording menu was still there, and I pressed STOP. The saved track is missing the same last 3 minutes, and when I tap on the last visible point on the track, the point has status "Distance to end" = 0m. So this is not a display problem, it is a recording problem.

This is the first time I have seen this problem. I recorded 5 other trips the last two days (two by bike, three by car) without any issues.

When selecting "Axis Y" = Altitude, the X axis is displayed correctly with units (distance or time). However, when selecting "Axis Y" = Speed (only), the X axis is missing the units (only the text "Distance (km)" / "Time (min)" is shown, but no numbers)

How to recreate:
- Set GPS > "Time between GPS locations" to e.g. 30 seconds. I can see the GPS receiver is turned on once every 30 seconds as expected.
- Then set to 0s. ==> The previous value (in this example 30s) is still being used.

I have to set it to 1s to force continuous location updates. Since 0s is the default value, I assume this is supposed to be a valid value and work as continuous updating (i.e. same as 1s), right?

Yes, I noticed the white outline, but the vertical line segments at each end is not that easy to see. When standing still the scale is definitely not a problem, but the readability becomes an issue when you need to take a quick look at the map while running, flying, .... That is why larger fonts, thicker lines would help.

DISTANCE RINGS:
Regarding scale: on Garmin G1000 navigation systems in airplanes, there is something similar to your "Time rings", namely "Distance rings". That is widely used to report your position relative to know points.

Could you add a "Distance rings"  entry in your Map menu? The distance should then show the distance in units as specified in the Settings > Localization > Length units. To avoid interference on the map, the user should only enable one of them, either "Time rings" or "Distance rings", at a time. Alternatively the "Distance rings" could have another color and the text could be displayed at the lower half of the circle. This would be a great feature!

The new
  Settings > Map > Map text size
is excellent! Combined with the "Color on map" setting this is just perfect! Thank you!

I have one small wish: could you enable this "Map text size" also to apply to the scale text? May I also suggest a thicker scale indicator line? And the vertical lines at each end do not seem to have the outline as the horizontal line.

I seem to have identified a very INTERESTING coincidence: Locus recording crash almost always happens at the moment I turn on/off the phone's screen with the hardware on/off button. After weeks of trying all kind of things, I started to see a pattern:
- when I didn't touch the phone (screen either on all the time or off all the time) when biking, running, driving to work, Locus very rarely crashed. I also recently had a 3 hour flight with 5 legs, phone screen on all the time and not a single crash.
- when I was running to work and Locus crashed the phone in the same area every single time (at least 10 times in a row), I finally realized that I every time had turned on the screen at the same place to check Locus.

This is what happens when I turn on or try to turn on the screen:
- either the phone is just dead already,
- or the screen turns on and I can operate Locus and the phone for some few seconds (about 5 seconds) and then the phone locks up completely with the message "Application Locus Pro does not respond" and the phone is dead.
- The recording either stops at this moment or I can see the track recording stopped last time I turned on/off the screen.

It does not crashes every time, but when it does, my observations above seem to be true every time. Hard to believe?

Now I have seen this repeatably for about 20 times. It seems very consistent. Can this tell you something?

The new Time Rings are really great! It is no problem reading the text ("xx minutes") when standing still, but this is something you typically will read while moving. Then the text often is hard to read by a quick look at the screen, a bit depending upon the map background. Would it be possible to have a white background for the text frame? The user could select the transparency of the text box, so it would be solid white with 0% transparency and invisible with 100% transparency. Just copy the transparency feature you already have today for tracks. May be the magenta font color today is too bright with a white background. Check it out.

The same applies to the scale indicator at the bottom left corner of the map. Would it be possible to implement the same frame box control for the text? Also the black distance line would be easier to see with a wider white outline (seems to be a small white outline for the horizontal part of the line). Or make the distance line much thicker.

so border is 2.5% of elevation change. Maybe it's too low values and because of this, to much values are stored in uphill and downhill? What you think?

To get an idea how steep a 2.5% angle really is, one can look at an airplane coming in for landing: standard descending angle is 3 degrees, which is equal to 5% (tan 3 = 0.05). 2.5% equals 1.4 degrees (arctan 0.025 = 1.4 degrees). So 2.5% (1.4 degrees) may be reasonable is the GPS altitude accuracy were better, but with the accuracies we actually get today from GPS, may be a 5% criteria would work better and rule out more of the small variations due to GPS altitude inaccuracy. But I assume you are using this declivity decision after smoothing? Otherwise it won't make sense at all (refer the raw data example from MyTracks).

I see the dilemma and I was probably a bit too quick to criticize Locus.

I can admit Locus is excused when displaying tracks recorded by another app like MyTracks, since MyTracks obviously store points unfiltered and applies smoothing when analyzing the track afterwards. I looked at a track recorded by Locus during a flight, and it was actually very smooth. Two Locus bike tracks do have some altitude noise that will add more uphill/downhill meters than actually is the case. When I looked at Locus tracks of two walking trips, that charts were quite noisy. So it seems that the lower the speed, the more incorrectly the smoothing works.

When to do smoothing - during recording or as post processing? Well, we know that the raw data are not correct anyway, so why store it unfiltered? If the smoothing algorithm is fixed and not user selectable or speed dependent, then storing raw data and doing post processing should work fine too. But then the smoothing should be applied also when exporting tracks, such that the apps using those data, get meaningful data (my original example with MyTracks show how bad this can turn out when doing it the MyTracks way). If however the smoothing level were user selectable, then the smoothing has to be done during recording I think, otherwise you would need to change the smoothing level from track to track depending upon what kind of trip it was (flying, sailing, running, ..).

I see the challenge of how strong the smoothing should be: too weak will pass through too much altitude noise and hence add too much to uphill/downhill, and too strong will filter out some real up and downs in a rough terrain. So may be the smoothing algorithm Locus is using today during recording is the best compromise after all. Since Locus is supporting display of MyTracks recorded tracks, may be the same Locus smoothing algorithm should be applied before displaying those charts and statistics.

Regarding my phone hang problems with Locus, yes they remain. I even tried more things yesterday, but nothing helped. Locus crashed and killed the phone dead twice during the same 1 1/2 hour trip. But I also can be lucky once in a while and record a trip without issues.

Vertical GPS accuracy is not as good as horizontal - that is a fact. My point here is that because of just that,  some sort of smoothing algorithm is required. And MyTracks obviously does a much better job with that than Locus. I would suggest a smoothing with user selectable smoothing level, e.g. off, weak, fair, strong, very strong. E.g. if you go cayaking from lake to lake, you want a very strong smoothing. If you go hiking, your elevation doesn't chnage abruptly by several meters between sored points and you may want a fair smoothing, but if you go running in a rough terrain, you may want a weak smoothing. And if you go downhill skiing, you may need to turn off smoothing.