#2037 Amazfit GTR GPS stops working upon pairing with Gadgetbridge

Open
opened 1 week ago by ciancel · 11 comments
ciancel commented 1 week ago
name about
Bug report Create a report to help us improve

Before reporting a bug, please confirm the following:

I got Gadgetbridge from:

If you got it from Google Play, please note that version is unofficial and not supported here; it’s also often quite outdated. Please switch to one of the above versions if you can.

Your issue is:

The following steps were taken:

1.) Unpackage the device
2.) Initiallize the device using the Zepp app as instructed, creating an account and updating the firmware
3.) Test out all features including a workout with GPS. GPS locks on location within seconds and produces good track.
4.) Obtain pairing key for use with Gadgetbridge.
5.) Kill Zepp app and pair watch with Gadgetbridge
6.) Test out all features again including multiple workouts with GPS. This time GPS takes a long time to lock or doesn’t lock at all after 10 minutes.

7.) Factory reset watch and repeat steps 2-4, reconnecting with Zepp app.
8.) Test out workouts with GPS. GPS locks reliably within seconds every time.

9.) Repeat steps 5-7 a couple more times over several days.

These tests were done over a series of days and in varying environments with clear weather and no obstructions to cloudy weather with some buildings and trees. It seems that the act of pairing with gadgetbridge somehow cripples the GPS functionality. Could it be that pairing the watch makes it dump its A-GPS data in anticipation of an update (which Gadgetbridge never provides)? If so, the GPS should still work eventually (albeit slower). After a day of being paired to Gadgetbridge, GPS never locked again until a factory reset and pairing with Zepp.

Your wearable device is:

Please specify model and firmware version if possible
Amazfit GTR 47mm
H.W. 0.31.19.17
F.W. 1.3.6.05

Your android version is:

Android 11 (RP1A.201005.004)

Your Gadgetbridge version is:

0.47.2

New issues about already solved/documented topics could be closed without further comments. Same for too generic or incomplete reports.

--- name: Bug report about: Create a report to help us improve --- #### Before reporting a bug, please confirm the following: - [x] I have read the [wiki](https://codeberg.org/Freeyourgadget/Gadgetbridge/wiki), and I didn't find a solution to my problem / an answer to my question. - [x] I have searched the [issues](https://codeberg.org/Freeyourgadget/Gadgetbridge/issues), and I didn't find a solution to my problem / an answer to my question. - [x] If you upload an image or other content, please make sure you have read and understood the [Codeberg Terms of Use](https://codeberg.org/codeberg/org/src/branch/master/TermsOfUse.md) ### I got Gadgetbridge from: * [x] F-Droid * [ ] I built it myself from source code (specify tag / commit) If you got it from Google Play, please note [that version](https://github.com/TaaviE/Gadgetbridge) is unofficial and not supported here; it's also often quite outdated. Please switch to one of the above versions if you can. #### Your issue is: The following steps were taken: 1.) Unpackage the device 2.) Initiallize the device using the Zepp app as instructed, creating an account and updating the firmware 3.) Test out all features including a workout with GPS. GPS locks on location within seconds and produces good track. 4.) Obtain pairing key for use with Gadgetbridge. 5.) Kill Zepp app and pair watch with Gadgetbridge 6.) Test out all features again including multiple workouts with GPS. This time GPS takes a long time to lock or doesn't lock at all after 10 minutes. 7.) Factory reset watch and repeat steps 2-4, reconnecting with Zepp app. 8.) Test out workouts with GPS. GPS locks reliably within seconds every time. 9.) Repeat steps 5-7 a couple more times over several days. These tests were done over a series of days and in varying environments with clear weather and no obstructions to cloudy weather with some buildings and trees. It seems that the act of pairing with gadgetbridge somehow cripples the GPS functionality. Could it be that pairing the watch makes it dump its A-GPS data in anticipation of an update (which Gadgetbridge never provides)? If so, the GPS should still work eventually (albeit slower). After a day of being paired to Gadgetbridge, GPS never locked again until a factory reset and pairing with Zepp. #### Your wearable device is: *Please specify model and firmware version if possible* Amazfit GTR 47mm H.W. 0.31.19.17 F.W. 1.3.6.05 #### Your android version is: Android 11 (RP1A.201005.004) #### Your Gadgetbridge version is: 0.47.2 *New issues about already solved/documented topics could be closed without further comments. Same for too generic or incomplete reports.*
ashimokawa commented 1 week ago
Owner

@ciancel

Thanks for the bug report.

On the Amazfit Bip and S which uses the same GPS chip we do not have that problem.

however I suspect that we set the timezone in a wrong way, and that could cause the problem.

What we are doing is that in summer time we just add the time instead of changing the timezone. The reason was that changing timezones lead to problems with importing the sports activities somehow.

But it could be that the wrong time might be the cause for bad GPS reception.

If you are CEST, changes are good that when the time changes to CET again end of october, it wil be better.

It would be great if you could try again after that, and if you can confirm an improvement we should correct the behavious (we should anyway but the appropriate time would be probably when most of our users are in standard time anyway)

@ciancel Thanks for the bug report. On the Amazfit Bip and S which uses the same GPS chip we do not have that problem. *however* I suspect that we set the timezone in a wrong way, and that could cause the problem. What we are doing is that in summer time we just add the time instead of changing the timezone. The reason was that changing timezones lead to problems with importing the sports activities somehow. But it could be that the wrong time might be the cause for bad GPS reception. If you are CEST, changes are good that when the time changes to CET again end of october, it wil be better. It would be great if you could try again after that, and if you can confirm an improvement we should correct the behavious (we should anyway but the appropriate time would be probably when most of our users are in standard time anyway)
ciancel commented 1 week ago
Poster

@ashimokawa

Thanks for your response! That is an interesting thought which did not occur to me.
I am in eastern time and I will be happy to try again after the clock moves. However, as a quick check I did manually adjust the system time zone on the phone and GPS did lock fairly reliably for the first time while connected to Gadgetbridge (took about 15 seconds). This would suggest you’ve identified the issue. Why doesn’t it affect the Bip (which I also have and can confirm works pretty well)?

As a side note, I am very willing to try and help this project somehow. What might you suggest be my first look to get up to speed? Is this very GPS/time zone issue something I can help with?

@ashimokawa Thanks for your response! That is an interesting thought which did not occur to me. I am in eastern time and I will be happy to try again after the clock moves. However, as a quick check I did manually adjust the system time zone on the phone and GPS did lock fairly reliably for the first time while connected to Gadgetbridge (took about 15 seconds). This would suggest you've identified the issue. Why doesn't it affect the Bip (which I also have and can confirm works pretty well)? As a side note, I am very willing to try and help this project somehow. What might you suggest be my first look to get up to speed? Is this very GPS/time zone issue something I can help with?
vanous commented 1 week ago
Collaborator

I will totally try this tomorrow with my Bip, to see if GPS fix is faster, it can take about 30-50sec. to get a fix.

I will totally try this tomorrow with my Bip, to see if GPS fix is faster, it can take about 30-50sec. to get a fix.
ciancel commented 1 week ago
Poster

@vanous

I performed the same quick test using a Bip and did not notice an appreciable difference in GPS lock time. Both took about 20-25 seconds.

It sure makes a difference on the GTR, however. It either works in under 30 seconds with the time zone shifted manually or it times out after several minutes when set by default.

@ashimokawa

Again, I appreciate the feedback on this issue. This was causing a lot of frustration for me this week. Let me know if there something I can do to help. Hopefully my informal tests are of use.

@vanous I performed the same quick test using a Bip and did not notice an appreciable difference in GPS lock time. Both took about 20-25 seconds. It sure makes a difference on the GTR, however. It either works in under 30 seconds with the time zone shifted manually or it times out after several minutes when set by default. @ashimokawa Again, I appreciate the feedback on this issue. This was causing a lot of frustration for me this week. Let me know if there something I can do to help. Hopefully my informal tests are of use.
ashimokawa commented 1 week ago
Owner

@ciancel

Probably the only thing that has to be done is here in BLETypeConversions.java

public static byte mapTimeZone(TimeZone timeZone, int timezoneFlags) {
        int offsetMillis = timeZone.getRawOffset();
        if (false && timezoneFlags == TZ_FLAG_INCLUDE_DST_IN_TZ) {
            offsetMillis += timeZone.getDSTSavings();
        }
        int utcOffsetInHours =  (offsetMillis / (1000 * 60 * 60));
        return (byte) (utcOffsetInHours * 4);
    }

remove “false &&” here.

We should do that if it helps end of october. And then fix possible regressions or work around them.

You could help by testing that now! :)

@ciancel Probably the only thing that has to be done is here in BLETypeConversions.java ``` public static byte mapTimeZone(TimeZone timeZone, int timezoneFlags) { int offsetMillis = timeZone.getRawOffset(); if (false && timezoneFlags == TZ_FLAG_INCLUDE_DST_IN_TZ) { offsetMillis += timeZone.getDSTSavings(); } int utcOffsetInHours = (offsetMillis / (1000 * 60 * 60)); return (byte) (utcOffsetInHours * 4); } ``` remove "false &&" here. We should do that if it helps end of october. And then fix possible regressions or work around them. You could help by testing that now! :)
ciancel commented 1 week ago
Poster

@ashimokawa

Ok, great! I will give this a try later today or tomorrow. I’m glad it’s seems such an easy fix.

@ashimokawa Ok, great! I will give this a try later today or tomorrow. I'm glad it's seems such an easy fix.
ciancel commented 1 week ago
Poster

@ashimokawa

Indeed, that simple change does the trick. You would know better than I how that might ripple outward and cause other problems, but at least it fixes this issue.

Thanks for your attention to this. How might you want to proceed?

@ashimokawa Indeed, that simple change does the trick. You would know better than I how that might ripple outward and cause other problems, but at least it fixes this issue. Thanks for your attention to this. How might you want to proceed?
vanous added the
bug
label 5 days ago
ashimokawa commented 4 days ago
Owner

@ciancel
I would propose you record some workouts before winter time and see if they sync and if they show the correct time (with your changes).
Then try the same after the time change.

Also sync normal step data and see if they are correct.

In any case we should do the change I proposed above after time changes.

@ciancel I would propose you record some workouts before winter time and see if they sync and if they show the correct time (with your changes). Then try the same after the time change. Also sync normal step data and see if they are correct. In any case we should do the change I proposed above after time changes.
ciancel commented 1 day ago
Poster

@ashimokawa
I have since gone back to try and do some more testing, but the problem now is that my AGPS data is out of date and location locks take forever either way. I only have successfully achieved a lock once and that was with the phone time zone set manually rather than with the code change you proposed. Every other attempt has just resulted in timeouts.
With regard to other data, I noticed some trouble syncing step and activity data, but I have a feeling this has more to do with the different versions of the app conflicting. I was using a spare phone with the self-built gadgetbridge installed so as to leave my main phone untouched. Going back and forth between them produces periods of time in the step data that are blank. My guess is that each version of the app sees the steps as having occurred at different times.
I was hoping that progress had been made with regard to some sort of back channel way to update A-GPS on the amazfit devices. I see the discussion about it #1876
Is there any way to manually update the A-GPS data so that more testing of this can be done? Ideally, we figure out an automated way of supporting it, but a manual process to be done once a week is a decent starting point.

Thanks!

@ashimokawa I have since gone back to try and do some more testing, but the problem now is that my AGPS data is out of date and location locks take forever either way. I only have successfully achieved a lock once and that was with the phone time zone set manually rather than with the code change you proposed. Every other attempt has just resulted in timeouts. With regard to other data, I noticed some trouble syncing step and activity data, but I have a feeling this has more to do with the different versions of the app conflicting. I was using a spare phone with the self-built gadgetbridge installed so as to leave my main phone untouched. Going back and forth between them produces periods of time in the step data that are blank. My guess is that each version of the app sees the steps as having occurred at different times. I was hoping that progress had been made with regard to some sort of back channel way to update A-GPS on the amazfit devices. I see the discussion about it https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/1876#issuecomment-77844 Is there any way to manually update the A-GPS data so that more testing of this can be done? Ideally, we figure out an automated way of supporting it, but a manual process to be done once a week is a decent starting point. Thanks!
belette commented 1 day ago

would be nice to be able to find a way to update A-GPS or add it manually somehow.
I got the same problem on my GTS where, on average I need 5/7 min in a clear sky to get GPS and one third of the attemps timeout and I need to start the process again :(

would be nice to be able to find a way to update A-GPS or add it manually somehow. I got the same problem on my GTS where, on average I need 5/7 min in a clear sky to get GPS and one third of the attemps timeout and I need to start the process again :(
ciancel commented 9 hours ago
Poster

@ashimokawa

Did another couple workout tests today (managed to get a GPS lock) and confirmed that they import successfully, but they show the wrong time. The watch itself reports the time correctly, but gadgetbridge reports the workouts as one hour earlier. Step data didn’t import correctly either.

@ashimokawa Did another couple workout tests today (managed to get a GPS lock) and confirmed that they import successfully, but they show the wrong time. The watch itself reports the time correctly, but gadgetbridge reports the workouts as one hour earlier. Step data didn't import correctly either.
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.