Sending Assisted GNSS (A-GNSS) to Bangle 2 GPS (AT6558)

Nice:

AGNSS data from CASIC.
DataLength: 2434.
Limitation: 7/1000.
...

I'm number 7 of 1000 allowed downloaders.

How did you do that?

Now I see why the CASIC protocol is so poorly documented. Many functions do not work as documented. No firmware updates, etc...
Probably all is classified...
https://en.wikipedia.org/wiki/China_Aero­space_Science_and_Industry_Corporation

I'm number 7 of 1000 allowed downloaders.

me too :)

I suspect the bin is something specific to CASIC. I do not know what it is for.
The actual EPO file is in subdir with name of YYYYMM, https://api.smawatch.cn/epo/202201/

You can also download big EPO from
http://epodownload.mediatek.com/EPO.DAT
people is saying...

This information can be downloaded from MediaTek as well, in a much larger file, comprising 30 days of satellite data
http://epodownload.mediatek.com/EPO.DAT
MediaTek 276480 bytes vs Garmin's 64512
but only 28 days with valid data seem to be present at all times. Day 29 and/or 30 have all their satellite number fields zeroed out (00).

https://www.reddit.com/r/Garmin/comments­/hyg0l5/manual_gps_epobin_update_with_ga­rmin_offline_for/

so it probably needs to be shrunk to the first 258048 bytes.

Well that ble_epo_offline.bin file is just a bunch of CASIC MSG-GPSEPH/MSG-GPSION/MSG-GPSUTC messages with a text header. So there's nothing too tricky about it. If the chip accepts it we could even build it ourselves using data from another service (e.g. supl.google.com) or pulled from another gps unit.

According to CASIC docs MSG-GPSEPH/MSG-GPSION/MSG-GPSUTC messages are "type cycle" (read-only). Is it possible to set that data using these messages? May be these are to dump a sort of backup?
It appears that EPO data is not standardized. Each vendor uses their format.
I am reading https://www.researchgate.net/publication­/351855783_Partial_Decoding_of_the_GPS_E­xtended_Prediction_Orbit_File
Interesting article.

actually if you download AGPS.zip from https://www.icofchina.com/xiazai/# and then translate Chinese docs, there are descriptions how to load Long Term Ephemeris data. I assume it is the larger DAT file in YYYYMM subdirectory.

I can completely parse the ble_epo_offline file, and it doesn't make sense for these messages to be used if they're really read-only. It's possible they've been nasty and added extra checksum values in the reserved fields that have to be correct in order to accept the message.

I'm not yet convinced the .DAT files are useful; they're either obfuscated or they're a completely unknown format. Edit: just read that paper Mark_M cited - that's definitely the same format, and since it's for a Mediatek GPS chipset it looks like those files are intended for another SMA product that uses it - not useful for us.

Limitation: 7/1000

My guess is that SMA download off of CASIC's servers, and just copy it to their own server every few hours. That way everyone gets the same file, they don't go past their download limits or distribute their username/password.

Well that ble_epo_offline.bin file is just a bunch of CASIC MSG-GPSEPH/MSG-GPSION/MSG-GPSUTC messages with a text header.

Ok, so are we saying we just strip off the header and stream it direct to the GPS? Regardless of what they say in the docs, it'd be easy enough to test if it decreased the time to get a fix.

edit: Just to add that I'm not sure what 'read only' means in this context, but you'd expect the almanac data to only be written to RAM (not flash)? After all, it'll be kept as long as the battery doesn't go flat, which is what happens to the almanac data that is read direct from the GPS

It's volatile data, definitely. Standalone GPS units invariably have a ram backup battery to keep the most recent almanac/ephemeris/location/time data to allow a warm boot, but I'd expect the watch to be designed to keep the gps warm off the main battery even when disabled (it's microamps or less) or else the software needs to cache the AGPS data and feed it back in when necessary.

The other part of improving the TTFF is having an approximate location/time to start from, which obviously isn't part of the ephemeris data. The AGPS.zip file has code that builds an AID-INI message that has that in it, so I think the full solution is going to need both parts.

There are NMEA (CAS00) and CASIC (CFG-CFG) commands that allow to clear, save and load configuration information to/from the chip internal flash.
When I turned on/off the chip, it restarted warmly. I assume it uses the main battery to keep itself warm. But you can restart it fresh even with factory settings.
I believe the second (bigger) long term DAT file is loaded between AID-INI 06 AID-INI 09 commands. The commands are not documented in the docs v3.6 and v4.2. According to AGPS C code the file does not need to be decrypted and should be loaded as is. But I did not try.
I agree that the smaller file can be pushed as is as well even with its text header that should be ignored by the chip. But this feature is not documented as well.
When I send CFG-MSG with query for MSG-GPSUTC it returns ACK-ACK (success). But it does not return the actual MSG-GPSUTC payload.

Serial2.write(new Uint8Array([186, 206, 4, 0, 6, 1, 8, 5, 255, 255, 12, 5, 5, 1]).buffer)
{ "hdr": 47822, "len": 4,
  "payload": new Uint8Array([6, 1, 0, 0]).buffer,
  "payloadBytes": new Uint8Array([6, 1, 0, 0]),
  "class": 5, "msgId": 1,
  "checkSum": new Uint8Array([10, 1, 5, 1]),
  "name": "ACK-ACK"
 }

When I pushed last 3 messages from the file I've got NACK for 0x08,0x07 and ACKs for 0x08,0x05 and 0x08,0x06

Serial2.write(new Uint8Array([0xBA,0xCE,0x48,0x00,0x08,0x0­7,0xBD,0x38,0x5C,0x4D,0xF8,0x63,0x0D,0xA­1,0xBC,0x23,0x5B,0x05,0x3D,0x0F,0xDD,0x0­E,0xE6,0xA4,0xAE,0xF2,0x9B,0x5B,0xE8,0x2­6,0x79,0x89,0x29,0x4C,0xD9,0xA6,0xFF,0xF­F,0x1D,0x32,0x72,0xFF,0x2B,0x03,0xD5,0x1­2,0x36,0x19,0x1B,0x03,0x47,0x00,0x25,0x0­0,0xF2,0x2B,0x90,0x00,0xF2,0x2B,0x00,0x0­0,0x2E,0xC7,0xFA,0xFF,0xF0,0xFF,0x00,0xE­4,0x13,0x00,0x00,0x00,0x1F,0x03,0x43,0x3­8,0xC2,0x71,0xC0,0xA1]).buffer);

Serial2.write([0xBA,0xCE,0x14,0x00,0x08,­0x05,0x92,0x19,0x66,0x90,0xFC,0xFF,0xFF,­0xFF,0xFB,0xFF,0xFF,0xFF,0x12,0x12,0x63,­0x90,0x89,0x07,0x03,0x00,0x38,0x33,0xD4,­0x25]);

Serial2.write([0xBA,0xCE,0x10,0x00,0x08,­0x06,0x47,0xF5,0xFD,0x11,0x0C,0xFF,0xFF,­0x02,0x38,0xF6,0xFD,0x0E,0x03,0x00,0x00,­0x00,0x9E,0xEA,0x03,0x2A]);

Does a particular message always gets NACK - even when sent in a different order or with pauses between them?
I'm thinking of "NACK = currently busy - please try again later".

I am more afraid that size of the message can be a factor. Can Espruino split the array making it not a byte buffer, but rather an associated array due to free RAM fragmentation?
I tried with new Uint8Array([...]).buffer , but got no success.

The paper and links you've found make it very clear that the .DAT files are specifically for Mediatek GPSes. Since we don't use one of those there's no point chasing that red herring.

I just tried the three messages you listed myself and got ACK-ACK for all of them.

Incidentally, I had to turn off all the NMEA messages with CAS03 before I got reliable responses from the CASIC commands.

The paper and links you've found make it very clear that the .DAT files are specifically for Mediatek GPSes.

is this file for Mediatek? https://api.smawatch.cn/epo/202201/m2_ep­o_offline_2022-01-11_847f4858827d0765e04­02b8d7158c0aa.DAT

I just tried the three messages you listed myself and got ACK-ACK for all of them.

That is good! May be I just need to restart the watch to defragment RAM.

I had to turn off all the NMEA messages with CAS03 before I got reliable responses f

Can you share the command string for this. I could not get them to shut up at all.

Serial1.println("$PCAS03,0,0,0,0,0,0,0,0­,0,,0,,,0*32")

That is good! May be I just need to restart the watch to defragment RAM.

On Bangle.js 2 I seriously doubt available RAM is a factor you have 256k - and every time you load a new app, RAM is cleared, so defragmentation will not be an issue.

PCAS03

Interestingly looking at the watch firmware, it pretty much only ever seems to send:

"$PCAS03,1,0,0,0,0,0,0,0,0,0,0,0*..."

Which is setting it to GGA only? I wonder if that helps with power usage at all...

I posted this up in some previous conversation, but had trouble finding it now, so: https://github.com/geary/AnyTone-D868UV/­issues/61

Some interesting info about improving time to GPS lock there

Basically the advise there is - turn off Beydou.
This is quite simple, the command can be send to Serial any time.
Another interesting item in the article to check GPS antenna soldering. http://members.optuszoo.com.au/jason.rei­lly1/868mods.htm?fbclid=IwAR3We8hIt20lFB­OhBdOoGneDnTRfB2PTQAMff1Tsupw06QlFLPlOnO­nBRLE#FasterGPS
Yes, it is different device - radio. But who knows, NMEA shows antenna is off, may be it is. Gordon, if you have disassembled watch, could please you take a look if soldering there is done properly?

As far as I can tell from the board I have here it's fine - the antenna arrangement is very different but the two connections look fine. Honestly, I think if the antenna wasn't connected you wouldn't see any GPS lock.

I've just updated the AGPS app on https://espruino.github.io/BangleApps/ and it should now work with GPS. Hopefully it also turns off Beidou.

Not sure if I missed this discussion elsewhere (there seem to be a bunch of threads open now) but in https://www.icofchina.com/d/file/xiazai/­2017-05-02/ea0cdd3d81eeebcc657b5dbca8092­5ee.pdf there are some interesting NAV-PV/NAV-TIMEUTC commands that I guess may really help.

The commend in the AGPS.zip file that @HughB found could appear to be AID-INI that's mentioned at https://www.icofchina.com/d/file/xiazai/­2020-09-22/20f1b42b3a11ac52089caf3603b43­fb5.pdf?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_­hl=en-GB but given it's not mentioned in the other doc we found I wonder if out GPS/firmware version accepts it

... also that GitHub link I posted shows some other (undocumented) form of ASCII lat/lon string that the device they have is sending. I guess one option is I reflash a dismantled Q3 that I have, solder onto the GPS RX/TX wires, and then try and run AGPS and see what commands are actually sent to the chip

If you are talking about the string after PCAS04
$PMTK�PMTK�$GPTXT�$GNRMC�$GPRMC�$GPGGA�$­GPGSV�,0�,1,25,180000,60000�,1,3000,1200­0,18000,72000�,0,1,0,1,0,5,0,0,0,0,0,0,0­,0,0,0,0,0��$PCAS02,1000�$PCAS03,1,0,0,0­,1,0,0,0�$PCAS03,0,0,0,1,0,0,0,0�$PCAS04­,3�,091926.000,3113.3166,N,12121.2682,E,0.5­1,09,0.9,36.9,M,7.9,M,,000056�,961639.00­,A,2458.21111,N,11838.31444,E,0.18,,0912­17,,,A,V*,,*
I do not think it is a command as is. It does not have any prefix. It may be a constant for default value for something. To find it out we need to sniff traffic.
Also, these $PMTK tell me that it is for MTK chip.

I have tried the AGPS update on my Bangle 2.

Unfortunately, I no longer get any GPS messages.
Neither via on('GPS-raw'), nor via on('GPS').

I tried a reboot, reboot without code and factory reset.
Nothing helped.

>Bangle.on("GPS", print)
=undefined
>Bangle.on("GPS-raw", print)
=undefined
>Bangle.setGPSPower(1)
=true
ÿ$GPTXT,01,01,02,MA=CASIC*27 false
$GPTXT,01,01,02,IC=AT6558-5N-32-1C510800­*48 false
$GPTXT,01,01,02,SW=URANUS5,V5.1.0.0*1F false
$GPTXT,01,01,02,TB=2018-04-18,10:28:16*4­0 false
$GPTXT,01,01,02,MO=GB*77 false
>new Date
=Date: Wed Jan 12 2022 15:35:25 GMT+0100
>new Date
=Date: Wed Jan 12 2022 15:37:37 GMT+0100

you receiving GPTXT. So your GPS is fine. Try to enable messages via $PCAS03, i.e.

    Serial1.println("$PCAS03,1,0,0,0,0,0,0,0­,0,,0,,,0*33")

Thats an odd one, because I've run this on several devices here and it's been fine. Were you experimenting with it before and could you have run PCAS03 yourself?