Gadgetbridge: Feature request: Add A-GPS data update for Amazfit Bip

[lgasp]

Before opening an issue please confirm the following:

• [x] I have read the wiki, and I didn't find a solution to my problem / an answer to my question.
• [x] I have searched the 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 github policies and terms of services

Your issue is:

Feature request: Add A-GPS data update for Amazfit Bip, to make GPS fix faster. A-GPS data should be updatet daily. I have no idea of how the official app does it.

Your wearable device is:

Amazfit Bip Watch
FW: 0.1.1.14
GPS: 9567,8b05506,0,0
HW: V0.11.1.4

Your android version is:

Motorola Moto G5S+
Android 7.1.1

Your Gadgetbridge version is:

0.26.2

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

[LuccoJ]

Gadgetbridge can already flash an A-GPS update file if you already have one, but I imagine obtaining it automatically would be a problem: Gadgetbridge just connecting to Huami servers without authorization runs a certain risk of being unwelcome.

An alternative would be to reverse-engineer the format and recreate the update file from public almanac data.

[IzzySoft]

@LuccoJ and @lgasp: Gadgedbridge has no INTERNET permission (and won't ever have), so it cannot get the almanach data itself. The only way I could imagine this could be solved would be by some other app (e.g. "automation software" like Tasker or MacroDroid) downloading those data and either calling to GB to ship them to the watch, or save them in a location known to GB so GB could then check that location and ship it to the watch whenever a new file is there.

I don't think any of that is already implemented, though.

[danielegobbetti]

The two issues are there and are orthogonal, namely:

• how to get access to "public almanac data"
• how to create an AGPS file that the amazfit bip understands

Solving one aspect without the other one would be fruitless. :-)

However we have got confirmations that gadgetbridge can upload agps data to the watch, just as it can do with the firmwares, resources, dials, etc.

[lgasp]

I know nothing about android programming, sorry.

I don't know if this can help, but Satstat ( https://github.com/mvglasow/satstat ) can download a-gps data for the phone gps, or, more likely, can request that the system updates it's a-gps data. Maybe GB could obtain this data from the system and flash it.
Converting A-GPS data to a format that Bip can use remains as another issue, as @danielegobbetti stated.

[LuccoJ]

Admittedly, solving this would be a big boon for the Bip's GPS, as unless mine is particularly bad, trying to use it without the A-GPS data downloaded can be completely fruitless sometimes... as in, tens of minutes without any fix at all.

[LuccoJ]

Coincidentally, I wrote a comment on Reddit about this matter. It's in response to questions about Mi Fit, so not directly related to Gadgetbridge, but I mentioned a couple of things that may be worth noting.

As far as I know, supl.google.com and supl.nokia.com (both mentioned in the essay I link in the comment) are the two "best known" SUPL servers, or at least they were already the two I knew best. It's potentially relevant in that it should be very possible to obtain data from those, or other SUPL servers in a reasonably standard way; then, turning it into whatever Amazfit firmware expects is an entirely different can of worms, I assume.

[ashimokawa]

The files (CEP and ALM) from the official server are protected and only distributed to logged in Mi Fit users. I got a few samples of these from someone and I could not make sense of them. They are binary files and seem either compressed or encrypted. It could also be some binary format which is native to the SONY GPS receiver inside the Bip. No idea.

The CEP is around 64k and ALM 2k, I have no idea which of the ones is more important to fast fixes.

If someone wants to have a look, inside the Mi Fit apk, there is a file called gps_alm.bin, it never changes and is distributed with every Mi Fit, I assume they accidentally ship it.

[LuccoJ]

If someone wants to have a look, inside the Mi Fit apk, there is a file called gps_alm.bin, it never changes and is distributed with every Mi Fit, I assume they accidentally ship it.

I think unlike the ephemeris, the almanac can be valid for a pretty long time, like six months. It could still need to be updated for precision or because some satellites get decommissioned, etc, but I guess that's why it makes sense to distribute a "standard" one in the APK itself.

I expanded a bit on the Reddit thread about what I know on the difference between almanac and ephemeris and other A-GPS stuff.

[lgasp]

I had a look at the Almanc file found in the apk as #ashimokawa suggested. The file is has likely 2 section, divided by a long series of 0s. The first part is likely divided in similar registers, that once aligned, look like this:
A0 80 08 00 8B 07 87 13 D0 B4 40 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA F7 66 8B 07 87 13 C9 36 41 31 A8 39 0F 74 FD 66 00
A1 0D 35 13 FB 4B 16 CE A1 DA 7E 87 05 00 19 F3 CA 8B 07 87 13 CB B4 42 85 3D 39 01 B0 FD 52 00
A1 0D 22 11 F3 89 AC 3A 1A ED 35 78 43 FF C0 92 09 8B 07 87 13 CE 37 43 03 40 39 0A C6 FD 3D 00
A1 0B F1 3E 70 2B 23 28 E7 A2 B7 61 F2 00 15 5B F4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8B 07 87 13 D3 35 45 28 2B 39 02 4D FD 31 00
A1 0C 9D 3D D7 E2 16 F1 7F 52 12 28 F6 00 32 BB 69 8B 07 87 13 D5 B4 46 03 3A 39 0F 54 FD 62 00
A1 0C 44 13 A3 D2 C4 1E 8C EA B1 84 25 00 2C 6F 10 8B 07 87 13 D8 35 47 52 62 39 0E 58 FD 53 00
A1 0C 9E 94 A5 68 95 78 59 C0 99 F1 34 FF FA 9A 58 8B 07 87 13 DA B7 48 12 2F 39 0E FD FD 4E 00
A1 0C 1C E8 BC 90 D8 6F B1 4F 61 B1 FA 00 13 0A B4 8B 07 87 13 DD 35 49 06 A2 39 07 A8 FD 55 00
A1 0D 6B 68 B9 7B 47 5A A3 3A 10 C3 22 00 53 F0 5E 8B 07 87 13 DF B7 4A 10 4E 39 0A E6 FD 3E 00
A1 0C DE 3E 48 2E 87 D8 4F 87 D7 A2 F0 00 1A 6C 42 8B 07 87 13 E2 34 4B 88 C5 39 E3 DC FD 31 00
A1 0D 0F 04 0E 79 41 64 FF C3 2D 9A A7 00 1B FB C3 8B 07 87 13 E4 B5 4C 32 5E 39 1E BE FD 37 00
A1 0C 87 C0 AF 24 1F BE F6 A8 A2 41 33 00 00 68 65 8B 07 87 13 E7 34 4D 21 47 39 12 4C FD 6C 00
A1 0D 26 6D C3 90 4C 70 75 EA CA A0 F8 FF E6 53 BB 8B 07 87 13 E9 B7 4E 46 CD 39 0D 64 FD 63 00
A1 0C 7F 6C 33 C8 B0 8B EB 21 2A F1 F9 00 10 6A 35 8B 07 87 13 EC 34 4F 49 15 39 F7 C3 FD 40 00
A1 0D 3E 66 61 EF 16 52 14 11 89 BC D3 00 19 92 AA 8B 07 87 13 EE B6 50 48 91 39 1F 0F FD 37 00
A1 0C 85 C1 73 9C 0F 83 91 59 7E 45 02 00 11 4C CE 8B 07 87 13 B2 B6 51 5E 77 39 17 9A FD 5F 00
A1 0C 16 EA FD 86 B2 CC 0E 2E 53 72 E6 00 06 1B A3 8B 07 87 13 B5 34 52 8E 0C 39 F4 70 FD 1F 00
A1 0D 3E 3C CE 79 B4 CC 0E 6F FF 0C 4C 00 31 16 F0 8B 07 87 13 B7 B6 53 54 09 39 15 C9 FD 5F 00
A1 0C D0 EC F4 8E 24 7E 68 B0 82 9B BC 00 04 B9 E9 8B 07 87 13 BA 37 54 26 FF 39 F5 4F FD 1E 00
A1 0C 47 3A B4 92 3D 9B FF 0D 75 7B 3B 00 20 36 18 8B 07 87 13 BC B6 55 C0 A3 39 FD 50 FD 50 00
A1 0D CA 12 61 6C B9 5B 2A 95 BC 17 BA 00 14 91 2C 8B 07 87 13 BF 37 56 3B CD 39 F3 1F FD 1A 00
A1 0C 8D 3C D0 C1 B5 2F AF 1C 27 9A 15 FF AE C5 23 8B 07 87 13 C1 B7 57 5B 5E 39 01 BA FD 4F 00
A1 0C 23 68 DC 8E 99 49 FE FF 9B D6 E5 00 1E 55 95 8B 07 87 13 C4 34 58 2A 50 39 03 52 FD 47 00
A1 0D 58 92 95 BE 10 CA 0D E6 2A 64 FC 00 0C 05 08 8B 07 87 13 CB 32 59 2F 71 39 16 F5 FD 2C 00
A1 0C DF BE 82 EB 1E AE DE 92 BC 54 D8 FF D9 6C D5 8B 07 87 13 CD B3 5A 0B 60 39 0B 25 FD 1C 00
A1 0C 8D BE 00 64 F7 DE D7 84 DF 36 BD FF E5 65 F9 8B 07 87 13 D0 32 5B 21 19 39 14 46 FD 55 00
A1 0C F0 E8 E9 0E 0C 0E FF 34 9C 57 17 00 4E 37 A7 8B 07 87 13 D2 B0 5C A5 17 39 1E 3E FD 39 00
A1 0C B5 C1 A5 0F BF 1E 24 54 E6 A2 4B 00 2B 05 23 8B 07 87 13 D7 B0 5D 04 60 39 18 4A FD 5D 00
A1 0D 53 EB 65 15 F9 3A EF 8D 1D 40 53 FF F9 44 AF 8B 07 87 13 DA 31 5E 13 6B 39 05 0D FD 44 00
A1 0D 8D 96 54 0D 7F 9F BF C0 5A BA 14 00 1C EE 2F 8B 07 87 13 DC B0 5F 45 C8 39 11 77 FD 58 00
A1 0C 95 95 10 19 F2 59 3B B9 F0 A1 1E FF EC CA 55 8B 07 87 13 DF 31 60 05 05 39 0A 9F FD 5A 00
A1 0C FC 68 D2 3F 92 B6 1E 51 82 0A E0 FF 95 48 EC

You can see that after the first line, every line start and end with the same characters, and some sections appear similar on different lines. One line is divided in 2 with 0s, but apart from that, it's regular. Considering this, there are 31 "registers".
Does anyone know what could be contained here? I can guess something like satellite identifier and some sort of position for every "register", but knowing what could possibly be, may help.

In the second part of the file, I couldn't find any "regularity"

[lgasp]

So, I analyzed the file a bit more, now it makes a bit more sense
The new alignment is the folowing:
A0 80 08 00
8B 07 87 13 D0 B4 40 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA F7 66
8B 07 87 13 C9 36 41 31 A8 39 0F 74 FD 66 00 A1 0D 35 13 FB 4B 16 CE A1 DA 7E 87 05 00 19 F3 CA
8B 07 87 13 CB B4 42 85 3D 39 01 B0 FD 52 00 A1 0D 22 11 F3 89 AC 3A 1A ED 35 78 43 FF C0 92 09
8B 07 87 13 CE 37 43 03 40 39 0A C6 FD 3D 00 A1 0B F1 3E 70 2B 23 28 E7 A2 B7 61 F2 00 15 5B F4
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
8B 07 87 13 D3 35 45 28 2B 39 02 4D FD 31 00 A1 0C 9D 3D D7 E2 16 F1 7F 52 12 28 F6 00 32 BB 69
8B 07 87 13 D5 B4 46 03 3A 39 0F 54 FD 62 00 A1 0C 44 13 A3 D2 C4 1E 8C EA B1 84 25 00 2C 6F 10
8B 07 87 13 D8 35 47 52 62 39 0E 58 FD 53 00 A1 0C 9E 94 A5 68 95 78 59 C0 99 F1 34 FF FA 9A 58
8B 07 87 13 DA B7 48 12 2F 39 0E FD FD 4E 00 A1 0C 1C E8 BC 90 D8 6F B1 4F 61 B1 FA 00 13 0A B4
8B 07 87 13 DD 35 49 06 A2 39 07 A8 FD 55 00 A1 0D 6B 68 B9 7B 47 5A A3 3A 10 C3 22 00 53 F0 5E
8B 07 87 13 DF B7 4A 10 4E 39 0A E6 FD 3E 00 A1 0C DE 3E 48 2E 87 D8 4F 87 D7 A2 F0 00 1A 6C 42
8B 07 87 13 E2 34 4B 88 C5 39 E3 DC FD 31 00 A1 0D 0F 04 0E 79 41 64 FF C3 2D 9A A7 00 1B FB C3
8B 07 87 13 E4 B5 4C 32 5E 39 1E BE FD 37 00 A1 0C 87 C0 AF 24 1F BE F6 A8 A2 41 33 00 00 68 65
8B 07 87 13 E7 34 4D 21 47 39 12 4C FD 6C 00 A1 0D 26 6D C3 90 4C 70 75 EA CA A0 F8 FF E6 53 BB
8B 07 87 13 E9 B7 4E 46 CD 39 0D 64 FD 63 00 A1 0C 7F 6C 33 C8 B0 8B EB 21 2A F1 F9 00 10 6A 35
8B 07 87 13 EC 34 4F 49 15 39 F7 C3 FD 40 00 A1 0D 3E 66 61 EF 16 52 14 11 89 BC D3 00 19 92 AA
8B 07 87 13 EE B6 50 48 91 39 1F 0F FD 37 00 A1 0C 85 C1 73 9C 0F 83 91 59 7E 45 02 00 11 4C CE
8B 07 87 13 B2 B6 51 5E 77 39 17 9A FD 5F 00 A1 0C 16 EA FD 86 B2 CC 0E 2E 53 72 E6 00 06 1B A3
8B 07 87 13 B5 34 52 8E 0C 39 F4 70 FD 1F 00 A1 0D 3E 3C CE 79 B4 CC 0E 6F FF 0C 4C 00 31 16 F0
8B 07 87 13 B7 B6 53 54 09 39 15 C9 FD 5F 00 A1 0C D0 EC F4 8E 24 7E 68 B0 82 9B BC 00 04 B9 E9
8B 07 87 13 BA 37 54 26 FF 39 F5 4F FD 1E 00 A1 0C 47 3A B4 92 3D 9B FF 0D 75 7B 3B 00 20 36 18
8B 07 87 13 BC B6 55 C0 A3 39 FD 50 FD 50 00 A1 0D CA 12 61 6C B9 5B 2A 95 BC 17 BA 00 14 91 2C
8B 07 87 13 BF 37 56 3B CD 39 F3 1F FD 1A 00 A1 0C 8D 3C D0 C1 B5 2F AF 1C 27 9A 15 FF AE C5 23
8B 07 87 13 C1 B7 57 5B 5E 39 01 BA FD 4F 00 A1 0C 23 68 DC 8E 99 49 FE FF 9B D6 E5 00 1E 55 95
8B 07 87 13 C4 34 58 2A 50 39 03 52 FD 47 00 A1 0D 58 92 95 BE 10 CA 0D E6 2A 64 FC 00 0C 05 08
8B 07 87 13 CB 32 59 2F 71 39 16 F5 FD 2C 00 A1 0C DF BE 82 EB 1E AE DE 92 BC 54 D8 FF D9 6C D5
8B 07 87 13 CD B3 5A 0B 60 39 0B 25 FD 1C 00 A1 0C 8D BE 00 64 F7 DE D7 84 DF 36 BD FF E5 65 F9
8B 07 87 13 D0 32 5B 21 19 39 14 46 FD 55 00 A1 0C F0 E8 E9 0E 0C 0E FF 34 9C 57 17 00 4E 37 A7
8B 07 87 13 D2 B0 5C A5 17 39 1E 3E FD 39 00 A1 0C B5 C1 A5 0F BF 1E 24 54 E6 A2 4B 00 2B 05 23
8B 07 87 13 D7 B0 5D 04 60 39 18 4A FD 5D 00 A1 0D 53 EB 65 15 F9 3A EF 8D 1D 40 53 FF F9 44 AF
8B 07 87 13 DA 31 5E 13 6B 39 05 0D FD 44 00 A1 0D 8D 96 54 0D 7F 9F BF C0 5A BA 14 00 1C EE 2F
8B 07 87 13 DC B0 5F 45 C8 39 11 77 FD 58 00 A1 0C 95 95 10 19 F2 59 3B B9 F0 A1 1E FF EC CA 55
8B 07 87 13 DF 31 60 05 05 39 0A 9F FD 5A 00 A1 0C FC 68 D2 3F 92 B6 1E 51 82 0A E0 FF 95 48 EC

So, on the 5th columnt it looks like there is the satellite id, with the 5th satellite missing (it may happen). I'm comparing this data with what can be found in the almanac found here, and 33 satellites at least, make sense :
https://www.navcen.uscg.gov/?pageName=gpsAlmanacs

Next step is comparing some almanac that I will download from old versions of the mifit apk, maybe I can find something more
EDIT: the almanac file contained in the apk is always the same, if there is any (in 2.2.8 there isn't any, 3.1.2, 3.2.4, 3.3.1 and 3.3.2 contain the same file).
@ashimokawa, if you can hand me some different file, it could help. I can probably find the week inside, and other info. Having also the date in which it was downloaded could be very helpful for comparing the same almanac downloaded from the url I mentioned above

[lgasp]

I tried to install mifit app on my phone. It updated the software and the A-GPS data too. I was hoping I could copy a A-GPS file from cache, but the folders (chache and data folders) in the mihealt folder in /Android/Data/ were empty. I was hoping to get the file from there, but probably the app immediately deletes it.
Do you have any suggestion on how to get this file?

[pm-cz]

@lgasp: The AGPS data is downloaded to /data/data/com.xiaomi.hm.health/files/agps.zip* so unless you have a rooted phone or patched MiFit allowing adb backups, you will not be able to extract them from application. It contains 4 files, gps_alm.bin, cep_pak.bin and their md5 checksums.

The almanac file changes, but slowly, e.g. files from 2018-05-26 to 2018-06-11 had the same almanac. What changes often are the Ephemeris (+potentially other important data), which are probably in the second file and the provided file is valid for 7 days. They seem to be downloaded each 3 days (72h + some minutes).

Hopefully attaching the file is not a problem:
example-2018-06-23.zip

[pm-cz]

I have analysed the gps_alm.bin file and after much searching, I found out that it in fact contains a header, then ONLY a GPS almanac + timing data (no GLONASS, sorry), which are mostly parity-stripped GPS sub-frame 4 and 5 pages indexed by ID byte with TLM header replaced by GPS week, CRC-16 checksums of each data part and additive sum of all data followed by a footer. I did not have time to analyze the eph_pak data file.

For details, see attached schema:

and GPS specification. Whilst most part of it can be generated from publicly downloadable data, I am not sure about the rest (if they are necessary). In the end I guess it would be easier to extract data from some GPS receiver, export and share them or make the manufacturer's files available.

[danielegobbetti]

@pm-cz I have a few questions, I found this reference url which hopefully is related to the data you posted :)

• GPS_week vs GPS_week valid 1: in the zip file you provided the first "dummy" record contains week 982 (+1024), but the second record (sat 1) contains 983 (+1024). Hoewer in the almanac files I found on the navcen website there is only one GPS Week Number, so the question is: how are GPS_week and GPS_week valid 1 related?
• int24 with (OMEGA)0 (RaaW) ...: should the fields Longitude of Orbital Plane and Rate of Right Ascension be multiplied?
• generally speaking for int24 fields, how is the sign encoded?
• HOW calculation: I cannot find a TOW value in the almanac but only TOA (Time of Applicability)
• GPS_S + 0x40 I don't quite understand the note "empty if sat disabled": does this mean that this byte is set to 0x40? what happens to the following 24 bytes? are they all ff? (edit: I see in the file you posted that a record is all 00, including the leading preamble (normally 8b )

FYI the hardcoded f7 66 bytes at the end of the first "dummy" record, are actually its CRC16/xmodem result, so it further validates your assumptions :-)

[pm-cz]

I will try to clarify the issues:

• GPS week is normally encoded as the same value, but in the same files it contains the mix of values. Originally I thought it is used as validity for the future, or that data is mixed from multiple sources as the records came,but I may be mistaken and they use the last bit as some indication? I have some more samples from different dates and in some of them all are the same, in other they contain mix of n and n+1 values. In valid I tried to mean that it is probably validity information for the satellite, but it is the same value. 1024 is the modulo of GPS week published in almanacs as it is limited in the transmitted GPS data.
• Int24 means that it is normal two’s complement, the same Int11 (I11). You just have to stuff the bits in beginning with 0s or 1s based on the sign (EDIT - meaning the MS bit of the n-bit value) of the value to get correct Int32 or Int16 number. They save data by transferring it this way. Each of the fields is separate, only in the end the bits from multiple values are mixed. The TABLE 20-VI. and FIGURE 20-1 (without padding parity bits) shows more.
• TOW is taken directly from GPS, it is the number of seconds / 6 from the beginning of the week in its reduced size. More about it in 20.3.3.2 Handover Word (HOW) in the resource. But I suppose it could be generated from ToA by adding some random time to it.

I know about the hardcoded bits, but as the header does not seem to change I listed them this way and not as the CRC, but it is so.

But as I said, the best way to generate the AGPS data would be by publishing them on-line extracted directly from the GPS receiver. There is a lot in the 73-7f messages in the end of the file which is not available in SEM/YUMA files from which it can be parsed normally.

EDIT: I forgot to mention, what I meant in "empty if sat disabled" is that the value is 0x00 as well as the rest of the values in that record

[danielegobbetti]

You mean one getting data from one of these services? Or can one just hook into the GPS raw data and get the needed info? If this is the case it would mean we could re-build the AGPS data for the watch from the android device completely offline, and it would be really cool!

[pm-cz]

Actually, the almanac is the GPS RAW data just with a few modifications, organized by the IDs, not the subframe pages, as I mentioned in my original post.

Ephemeris data is available on ftp server as well, but I was not able to access the server to look at it (i think it is stored in RINEX format).

For other possible sources of time correction factors and other needed data, I think e.g. the xtra.bin file for phones contains similar information (+ the ephemeris data), but I was not able to find any description of the format. The data provided from ublox API mentioned in #1021 contains it as well, but encoded differently and this is a gray area as there is a leaked a API key in that post. Another common file, MTK7d.EPO obtainable from several sources contains (probably only) ephemeris data as well.

@danielegobbetti: The ntrip casters mentioned in the link are one way I was also researching as well as some of them include message with almanac. But their main use is to provide correction factors to apply to make the positioning even more precise, so only a few casters send the almanac data and again, I did not find any tool which would extract content of the messages (but it should be feasible).

Now about the GPS Almanac + ephemerides extraction on Android device, it will not be possible, I am afraid. The GPS API does not supply the almanac data from GPSD and only some receivers built in the devices actually support this feature. And the xtra.bin file is not readable by applications, I think it is not even stored on the file system. More likely an external GPS module (e.g. ublox-6) could be used for extraction and uploading data to some web server.

[danielegobbetti]

Actually, the almanac is the GPS RAW data just with a few modifications, organized by the IDs, not the subframe pages, as I mentioned in my original post.

You have to apologize for asking the same question over and over, but I still have some issues following you even after I understood some of the jargon by looking at the links you posted :-)

I am currently working on a script to rebuild the message according to your image, using the navcel alm sources. I believe I have reconstructed the SAT records right, apart for the HOW bytes.

[pm-cz]

I understand that you ask, I had also to understand the format and I know quite a lot about the GPS from past. ;-)

Concerning the HOW, as it is not available, it will have to be generated by some random "offset". Consider it something like a serial number of transmitted frame in the given week, which rotates to 0 weekly on Sat/Sun midnight. Actually we could probably take seconds from the start of the week of today's midnight and divide them by 6 as the initial stamp and 5 for each satellite as in original time.

The SAT records will probably not be a problem, but the last records after the block of zeros may be :-(

[pm-cz]

@danielegobbetti I seem to be making some progress understanding the structure of xtra.bin and/or EPO files which are used by Android phones, so maybe parsing almanac text files will not be necessary, I hope.

[pm-cz]

I had a random thought related to Time Zone being set incorrect I mentioned in #1107. How long does it take to get a fix on watch being used solely with GadgetBridge? Is it unreasonably long? Because I wonder what time the Amazfit Bip is using during GPS startup. If it is the UTC time set on the watch, wrong timezone would mean it is off, typically by 1h, which would probably increase time to first fix before the time is synchronized from the satellites.

[LuccoJ]

How long does it take to get a fix on watch being used solely with GadgetBridge? Is it unreasonably long?

I am currently unable to quantify, but I have found it "unreasonably long" in my walks before, when I tried. I do often have the almanac data from Mi Fit, admittedly, so I don't experience that very often.

If it is the UTC time set on the watch, wrong timezone would mean it is off, typically by 1h, which would probably increase time to first fix before the time is synchronized from the satellites.

Mine is not set to UTC, but I haven't thought about this or tried whether setting it to UTC would change anything outdoors.

[LuccoJ]

About using data from the Android phone's GPS and generally investigating what's available... Maybe everyone else knew it already but https://github.com/barbeau/gpstest is fresh off F-Droid and it looks like it can play more tricks with assistance data than I knew SatStat being capable of doing.

[pm-cz]

@LuccoJ: Unfortunately, the GPStest application as well as other apps of this type use just internal Android API (LocationManager's sendExtraCommand) to push xtra file data to the (Qualcomm) GPS chip. I have managed to crack some of the xtra file internal structure, so as of now we can download it and regenerate the significant parts of gps_alm from it, but I was not able to make sense of the prediction records in it, GLONASS parts of V2 Xtra file, nor the cep_pak records used for ephemeris predictions on Amazfit. So generating the almanac (the first 3% of AGPS download in official application) is possible, but not the rest.

[LuccoJ]

@pm-cz today I got a cold fix from the top of an artificial hill (clear view of the sky) in roughly two minutes (I messed up with the timer...) Without assistance data loaded, or rather, probably just the almanac.
This was in ideal sky conditions though, it has taken much much longer before in city streets.

[LuccoJ]

@pm-cz about the XTRA data, I don't really know what's going on with all that, but with my phone (ZTE Axon 7), GPSTest reports that XTRA injection is not available, and I guess that makes it unsurprising that no satellites seem to ever appear with the "E" (have ephemeris), but only with the "A" (have almanac), despite being "U" (in use).

But I don't really know, I imagine there is some other side channel (carrier data direct to the modem?) A-GPS information is obtained from on this phone, as the fixes can be very fast anyway. Also, I'm unsure on SUPL's role within all this realm of proprietary assistance data "injection"... after all, Google still does run a SUPL server.

[dazzzl]

Hi,
as a quick and dirty solution: Is it possible to download the files from Huami servers with login and password and manually flash it with Gadgetbridge? I used the Mi fit App to update the A-GPS, but it synchronized everything first, which I do not want... So, this is not a doable way for me.

[pm-cz]

@dazzzl Yes it is (not with login & password, but with login and app tokens), but it is gray area. I have implemented a proof-of-concept shell script capable of doing it, but I have no server to host the files and I do not plan to make the script public right now.

[ius]

Sony has recently announced the SPRESENSE IoT development board. This board features the CXD5602 SoC - Bip's GPS receiver should be very similar, if not equal.

Along with it, the SPRESENSE SDK is available on Github. A quick glance suggests it might contain some pointers, but the ioctls used to upload alm/eph/cep data just take an opaque blob (there's a download ioctl for alm/eph as well).

Perhaps someone could use a SPRESENSE board to dump and publish a public almanac and ephemeris in the correct format, but if I understand @pm-cz's excellent notes and reversing work correctly, CEP would be required to actually predict the ephemeris offline.

While the SDK allows linking in CEP (CONFIG_CXD56_GNSS_CEP_FILENAME, /mnt/spif/gnss_cep.bin) - no hints are provided as to where to obtain it...

[danielegobbetti]

I found this: http://www.gdgps.net/products/embedded_aep.html

Embedded GPS/GLONASS Autonomous Ephemeris Prediction (AEP) software enables fast signal acquisition in your PND or cell phone without any external aiding whatsoever. No Connectivity - No Problem!
AEP is written in highly portable C. It has been ported to Linux, and Windows Mobile in a variety of host platforms. JPL will work with your company to tailor the software and its interface to your specific operational environment, and your specific requirements.

There are contact infos in the page. I wonder if they would be willing to release the source code :) Can someone try to reach out to them?

[DiegoVicen]

Just ran into this issue, my Amazfit Bip tells me to "connect to the app and automatically update A-GPS to get location faster", then tries to get the GPS location and... that's about it: loops there forever or waits for me to cancel GPS and start the activity with no location trace.

I would prefer not to sync at all with Mi Fit, so is there any possible solution? I am running 1.1.2.05, which I think is the last version of the firmware, could I get it to get the position faster by downgrading it, or that makes no difference at all?

[Nephiel]

A-GPS should be updated every few days in order for the GPS function to work. The Mi Fit app does this, but AFAIK currently there is no easy way to extract A-GPS updates from Mi Fit, or build it from other sources.

Downgrading would make no difference.

[LuccoJ]

@Nephiel GPS works anyway, it just tends to take longer to obtain a fix than with the A-GPS data. The message where it asks you to sync with Mi Fit is just advice, you can say "okay, right" and then continue trying to acquire a GPS fix without the A-GPS syncing. If you're indoors, forget about it, but outdoors you will get a fix at least within 5 minutes or so, in my experience, unless you're very deep inside an urban canyon.

[danielegobbetti]

There is no need for A-GPS data, they just make it faster to acquire a fix (and make the fix more precise faster as well). If you know you want to use the outdoor activities in the immediate future, you could go to the second screen of the "Compass" watch application. It will power on the GPS chip and you will see your position after a few minutes. Afterwards, when you start the activity tracking, watch will still complain about missing A-GPS data but will get a fix in less than one minute since it's a "warm-start".

This is a workaround. If you want to help please read the whole thread, it contains information about how you can help us getting the functionality to work (like what kind of data we need, and who you might try to contact in order to get those).

[xandro0777]

I would love this feature but I have also seen some reports that the BIP can get stuck in hard to recover states if anything goes wrong during AGPS update with the official MiFit app. Unfortunately because unlike fw update AGPS updates would have to be very frequent this could turn out to be a big problem.

[endes123321]

Hi, I was reversering engineering this device firmware in this issue https://github.com/amazfitbip/documentation/issues/4 . And recently I founded(Thanks to @JohnRThomas) the GPS protocol https://github.com/sonydevworld/spresense/tree/c2c84a9db6eb2e03afc28554ce0345f2d7ff2ffd/examples/gnss_atcmd .
The BIP sends the @GALS commad to the gps to inject the almanac data.

For the CEP package uses @CEPW but unfortunately that command isn't in that code.

[nickspacek]

So reading through this issue, it seems that we have the ability to generate part of the data for the A-GPS update, but generating the majority is still a mystery. Barring a revelation about how Huami generates the files, we seem to be stuck and unable to proceed with this feature built into Gadgetbridge. Is that a correct summary?

Is there an approach that would allow the official application to do the A-GPS update without interfering with the workflow of Gadgetbridge users? It was earlier mentioned that the official application does a full sync, in addition to updating the A-GPS and that the full sync causes issues for users.

[TE-AmitSa]

I am trying to search for GPS data structure. Found one, http://www.rfwireless-world.com/Tutorials/GPS-frame-structure.html. But, looking for more detail description. Kindly help me.

[jiri-one]

Hi, is there any news about this feature request/issue?