Tracking freezes qfield in newer versions

[bladnor]

What is the bug or the crash? What were your expectations and what actually happened?

Hi,

When we start line or polygon tracking, qfield becomes unresponsive. The only way out is to kill the app. Manual digitizing of lines and polygons works. This used to work, and only in recent versions this happens (I cannot tell exactly when it started). We usually use the Samsung Galaxy Active Tab 3. Because I thought that the hardware might be too old for the latest qfield versions, I tired it on Samsung Galaxy Tab Active5 but the problem remains. As GNSS we use the Emlid RS3. I also switched on and off every option in the positioning section without luck.

At the workshop in Bern at "QGIS Anwendertreffen 2025 Bern" tracking worked for the simple sample case with the device internal GNSS. For a real-world project it does not work anymore.

1. What do you suggest to fix this?
2. Shall we meet in Bern so that I can show you the problem?
3. Do you want me to do some tests?
4. Since we are the reseller of Emlid Devices in Switzerland, do you want me to send you a demo RS3, RS2, or RX so that you can investigate the issue yourself?
5. Could I switch off somehow the background tracking you added recently to qfield and test again?

Thanks Roland

Steps to reproduce the issue

1. Create a Project with about 150 lines, points or polygon layers.
2. Attach an external GNSS like the Emlid RS3 or RS2. With an internal device it happens too but a little less dramaticly.
3. Start Tracking.
4. Try to do something like show and hide the legends/layer flyout. Or change zoom level.

Version

3.6.6-Gondwana

Operating system name

Android

Operating system version

Android 15 / One UI 7.0

Reinstall QField

• [x] I have a fresh install of the latest QField version, but the problem persists.
• [x] Problem can be reliably reproduced, doesn't happen randomly.
• [ ] Problem happens with all files and projects, not only some files or projects.

Additional context

No response

[nirvn]

@bladnor , could you try two things:

1/ can you add a time requirement constraint and set it to 1 second and see if it helps? 2/ can you turn the visibility of the layer off then start a tracking session and see if that helps?

[bladnor]

Month ago we discovered when attaching an external GNSS without setting a time or distance tracking constraint qfield frezzed too. Since then we always set a distance constraint of 0.1meters. That is what our customers required. I was even thinking of filing a feature request to make setting a constraint a requirement when an external GNSS is attached which sending measurements to qfield more often (60Hz?) than an internal GNSS. For you I tested just now the 1 second constraint. The result is not different. Even worse. Compared to the distance constraint it feels like qfield becomes unresponsive right away. With distance constraint qfield becomes unresponsive after the GNSS head starts to move. Hiding the layers did not change a thing. I even tried to hide all the layers in the project. Still, the problem persists. What do you want me to test next?

[nirvn]

@bladnor , thanks for the swift reply.

Something else that'd be useful is to provide us with a log of the NMEA strings received by QField. You can generate these logs by enabling this setting (visible when an external GNSS is configured in QField):

This will create a .log file in your QField app directory, which for Android devices will be accessible by clicking on the "open local files" button in QField's home screen, then selecting the QField files directory, then the QField directory, and finally the logs directory. You'll see the NMEA logs in there, which you can then send over to yourself by clicking on the 3-dot menu. If you can send that over to us, we can probably emulate your situation.

[nirvn]

@bladnor , I've looked into it a bit and applied a few optimizations, you'll find some test APKs in this PR in a few minutes (https://github.com/opengisch/QField/pull/6487).

That being said I suspect it's not going to fully address the regression you've spotted here. The logs would be useful. I'll also have my colleagues in Switzerland contact you on this :)

[bladnor]

Hm, the NMEA logfiles are not written in my case. I can't see them in the qfield app, nor can I see them when I connect the tablet to my linux machine. Nothing is in mtp://SAMSUNG_SAMSUNG_Android_xy/Interner%20Speicher/Android/data/ch.opengis.qfield/files/QField/logs Any ideas?

PS: I'm going to test the new APK after lunch.

[bladnor]

I have tested your beta apk. I did not see any improvements in the performance/freezing of tracking. After all the hours I have spent in the past days to try to improve the performance of the tracking feature, I can give you my thoughts and findings:

1. Tracking works when using the demo wastewater management project on the "Reaches" layer with distance constraint of 0.1 meter.
2. Tracking freezes when using a project with a medium number of layers. Approx. 150 (Points, Lines, Polygons)
3. Tracking freezes are independent of the visibility of the layers.
4. Tracking freezes are independent of the constraint applied to tracking (time or distance)
5. Tracking freezes are independent of the setting in "Activate accuracy indicator"
6. Tracking freezes are independent of the setting in "Show position information"
7. Tracking freezes are independent of the setting in "Enable averaged positioning collected"
8. Tracking freezes are independent of the setting in "Skip altitude correction"

So, to improve tracking performance/freezes even for medium-large projects, I would check/do/test the following things:

• Are the invisible layers refreshed on the screen during tracking? If yes, I would try to remove them from drawing to the screen to see if it improves the performance. If that is the case, I would add a switch for "fast tracking" or similar which disables all (or a preset set of) layers and shows them again after tracking.
• Can the drawing to the screen somehow be improved?
• Are the numbers of measurements streaming from an external GNSS to the app a problem? Need they be further limited independent of the constraining mode?

a) If you send me a version where the NEMA Logs are saved, I can do another test and send the logs to you. b) Let me know if I can send you a demo Emlid GNSS device for testing (RS3, RS2, RX). c) Our project is an offline "qfield cloud for organisations project". So everything is local on the mobile device. If you want to test it, I could set up the project on our pre-production environment and can give permission for the project to a user you name. But please do not upload the changes you do to the cloud. Or I could even grant you permission to our production environment if you guarantee to take care. Would be easier and faster to do for me but more risky.

Let me know how to proceed from here.

Thank you very much for your efforts. Roland

[nirvn]

@bladnor , for your project with 150 layers, is using the internal GNSS resulting in the same freeze as the external GNSS?

[bladnor]

Good question. Just made the test:

1. On the new hardware (Samsung Galaxy Active5) tracking with internal gnss with distance constraint 0.1 meter on a project with approx. 150 layers works in a way that the feature is usable.
2. On the older hardware (Samsung Galaxy Tab Active 3) tracking with internal gnss with distance constraint 0.1 meter on a project with approx. 150 layers works too but very, very bad so that the feature is unusable. Most of the time it is unresponsive, screen updates happen only from time to time.

As I initially wrote: Tracking never worked fluently, but at least it was usable on the old hardware with an external gnss with distance constraint applied on a project with approx. 150 layers.

So, I guess we narrowed down the problem a bit, and I would say that: a) Some recent changes in the app are consuming more cpu and makes the app freezing when using an external gnss with distance constraint set to 0.1 meter on a project with approx. 150 layers even on the latest hardware. b) Position streaming from external GNSS devices can 'overwhelm' the app.

Let me know if I can do other tests.

Thanks Roland

[bladnor]

@nirvn Can you give me a short update on what is happening on the issue? Do you think you will be able to resolve it? By when would that be? If you have some apk to test, let me know.

[nirvn]

@bladnor , the NMEA logging functionality was fixed in QField 3.7.1; you could download it here (https://github.com/opengisch/QField/releases/tag/v3.7.1) and provide us with a few minutes worth of NMEA logs for your device.

That being said, 150 layers is magnificent, but that's also a lot of layers :) is the layer onto which the tracking occurs an online database layer (postgis, wfs) or on-disk dataset (geopackage)? I assume that the "freezing" would have to do with the map canvas being refreshed, and there you could also have ways to improve things by e.g. avoiding any kind of feature labeling (or feature as obstacle) settings on the tracker layer.

[bladnor]

@nirvn Sorry for the late response. I had to wait for the gnss to come back. Attached you find the NEMA log. I have recorded it with verison 3.7.2.

The traking behaviour in that version has changed in that it stays responsive but does not track anything at all.

The project is a qfield cloud project and all layers are offline. nmea-2025-08-08T18:52:27.log

[nirvn]

@bladnor , thanks for the logs as well as the heads up on tracking not working for you.

We've fixed the issue that prevented tracking from working for you, you can test it using the APK here: https://github.com/opengisch/QField/pull/6553

It'll be deployed in production in the coming 72 hours.

As for the freezes, I'm investigating this further.

[bladnor]

@nirvn I have tested the version 3.7.4. Tracking works again but still with the known freezing limitations. Did you find out what is causing the freezing with the NEMA logs? Let me know if I can do something to help find the bottleneck.

[nirvn]

@bladnor , good to know tracking works gain :)

Your logs were useful, but I've not been able to replicate the freeze locally. If you set a minimum time constraint (i.e. say 5 sec), does it help?

[bladnor]

@nirvn I wanted to test your suggestion yesterday. Another regression prevented me from doing it. The Tracking Setup Screen popped up only the first time. After that it does not show up anymore when pressing start tracking. Only a restart of the app helps and then the problem starts over. The Version I used was 3.7.6 Haida Gwaii

[nirvn]

@bladnor , could you attach a screencast or precise steps to reproduce (using the sample bees project's tracks line layer)? I can't replicate over here.

[nirvn]

@bladnor , was the vector layer used to do tracking set to suppress the feature addition form ? If so I stumbled on your issue, fixed here: https://github.com/opengisch/QField/pull/6659#issuecomment-3314929073

[bladnor]

@nirvn can you update me about the state of this issue?