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

Thanks for your Help!

$PCAS03 solved my problem.

I did a little experimenting yesterday. But afterwards I was sure that it still worked.
Possibly I was the problem.
Sorry for the inconvenience.

@Gordon
is it possible to request from SMA:

• documentation on CASIC protocol that is compatible with the AT6558 firmware that is installed into the watch
  
• firmware update for AT6558 and instructions how to apply ?
  

is it possible to request from SMA:

I don't think so - I honestly think they don't know much more than us. Ideally we'd contact Hangzhou ZhongKe (the chip manufacturers)

Also I'm not sure what you're asking for out of this hypothetical firmware and documentation that we don't already have. So far what I've tried out of the existing documentation has worked, and anything that doesn't is unlikely to be rectified.

I have two CASIC documents v3.6 and v4.2. Many CASIC commands do not work.
For example simple command - set message MON-VER 0x0A,0x04 to rate 0xFFFF to get software version

Serial2.write(new Uint8Array([186, 206, 4, 0, 6, 1, 10, 4, 255, 255, 14, 4, 5, 1]).buffer);

always returns NACK
If I call it as "poll"

new Uint8Array([186, 206, 0, 0, 10, 4, 0, 0, 10, 4]).buffer

it also returns NACK

If such a simple command does not work, it looks very suspicious to me.
Why I suggested to ask docs and new firmware from SMA, because you have purchased their product. When SMA purchased AT6558 chips from Hangzhou ZhongKe they probably got all current docs, binaries and support from them. They, as a big customer, also can request firmware updates.
Also their support page looks more customer friendly. https://smawatch.com/Support
I've looked at https://www.icofchina.com/contact/ support is only by phone and all is in Chinese.

Is there a specific feature you're trying to access? At the moment it just looks like you're fishing.

Also, as someone who has worked in the commercial embedded world for many years, "SMA ... probably got all current docs, binaries and support from them. They, as a big customer, also can request firmware updates." is just fundamentally incorrect in every respect. Half the time the documentation is provided under NDA, the other half of the time the documentation simply doesn't exist at all. And finally, even if SMA had some secret firmware update they weren't bothering to pass on to customers, why would they turn around and give it to us? They might be a big customer, but we aren't.

Sure I am "fishing". I've bought this watch for fun, not for business. It is not a question of life and death for me if some functionality is not documented, and some completely does not work despite it is documented.
However, as many others I'd like to get updates and correct docs, examples, etc.
What is wrong with me? Am I desiring too much?
Yes I am not in professional embedded development. But I have some amateur experience with U-Blox. With U-Blox everything is well documented, you can download lots of docs, examples, firmware updates etc.
It is not under any NDA. Same with other vendors, like Nordic, Microchip... you name it.
ZhongKe publishes docs anyway. But it is just current ones. Older ones sit there and some available if a link can be found. So it is not secrets.
As well as a firmware is not a secret.

What I would try to use is RXM-SENSOR (0x03 0x07) - there is another accelerometer, gyroscope and thermometer.
May be RXM-MEASX for RINEX postprocessing.
May be I'd explore some ways that would allow to decrease power consumption, like CAS12 or like turning of reception of some sats if they are not useful.

It's not wrong to try and see what else you can get out of your device, but it's also important to temper your expectations. The documentation we have covers an entire class of devices with wildly different feature sets, and pricing to match. You get what you pay for, and SMA isn't going to spend extra on a chip with features they aren't intending to use or advertise. Heck, they probably designed the watch around the absolute cheapest option they had access to.

So, some of the commands you're aware of are for features that simply aren't present in the AT6558 - RINEX is one of those things that a manufacturer is likely to charge a lot more for, as that's sought after for more expensive devices in narrow markets with much higher margins on them than the consumer GPS market, like professional survey equipment. That said, the datasheet does claim the AT6558 is suitable for DGPS use, so shrug

And some commands are intended to give options to the hardware designer. There is no secret second IMU in the AT6558. Not even the more expensive chips have one. What they do have are spare pins on their IC packages that they can cheaply repurpose as a GPIO or serial bus expander. If you look at the datasheet you'll see several reconfigurable GPIO pins, including some that can be assigned as an I2c or SPI master. You can connect a separate device to these pins and then communicate with it via the GPS, which is useful if you've run out of pins on your primary microcontroller. This is explicitly called out in the datasheet in section 5.7 SPI - "SPI master device interface is used for connecting the SPI interface devices, such as MEMS sensors, FLASH, etc..". RXM-SENSOR is a convenience function for controlling an external IMU on this second bus - but since we already have an IMU directly connected to the nRF52 in the watch, this is unnecessary and therefore won't be connected to anything useful.

Sure I am "fishing", I've bought this watch for fun... Am I desiring too much?

I provide you with what I know and the products of my work, for free. I'm not only doing that, but I work every day answering questions and improving Espruino for nothing more than the small profit I made on your initial purchase of the Bangle.

I said the Bangle.js had GPS, I've made it so you can totally access it from code, told you the exact model number and even linked to a datasheet most of which works. That's far more than any other watch manufacturer I'm aware of.

If there's not 100% accurate documentation then by all means go and find it yourself, contribute the result and I will happily add it to the docs so other users can find it.

Hi Gordon, I appreciate what you are doing very much.
I am also sharing my findings here (and I also have free projects, i.e. FreeShip https://github.com/markmal/freeship-plus-in-lazarus).
Yes sometimes it is frustrating that something does not work. I usually do all efforts to find a solution by myself. I do not expect you should document the GPS, the ZhongKe should.
I've found and translated the CASIC docs from Chinese. I can share it here as well with notes about what does work and what does not.
What I asked for was not a demand to you rather a humble plea to try to get proper docs/updates from/through SMA. I believe you are quite a big customer for them based we purchased 2000+ watches. And it is growing.
But if it is impossible or hard to do I can understand it, no problem.
I just doubt we can get any response from ZhongKe if we contact them directly. But if SMA contacts them ZhongKe may provide them with firmware updates.
Anyway thank you again.

"SPI master device interface is used for connecting the SPI interface devices, such as MEMS sensors, FLASH, etc..". RXM-SENSOR is a convenience function for controlling an external IMU on this second bus - but since we already have an IMU directly connected to the nRF52 in the watch, this is unnecessary and therefore won't be connected to anything useful.

yes, this makes sense.
Datasheet from ZhongKe AT-6558-R v1.7 does not mention thermometer or gyro. They published just one datasheet. Our chip is AT6558-5N-32-1C510800. They have "hidden" link to older DS https://www.icofchina.com/d/file/xiazai/2016-12-05/b1be6f481cdf9d773b963ab30a2d11d8.pdf
According to it our chip should not receive GLONASS. But it does. At least I saw 1 sat :)
They also declare - Support A-GNSS, Support D-GNSS differential positioning. But I do no trust :)

humble plea to try to get proper docs/updates from/through SMA. ..... But if it is impossible or hard to do I can understand it, no problem.

It is more that

• It doesn't look like effort spent with this would help us with implementing agps any faster
  
• Current GPS firmware looks capable enough to handle AGPS
  
• Time spent doing as you say is time not spent on improving Bangle 2 firmware
  
  

I've found and translated the CASIC docs from Chinese. I can share it here as well with notes about what does work and what does not.

That would be very nice.

I've already implemented loading of the "small" file ble_epo_offline.bin

the zip file is here.

1 Attachment

• CASIC-v4.2.zip

interesting... Loading from file ble_epo_offline.bin some messages give NACK. For example, first always gives NACK. Second gives ACK.

B=new Uint8Array( [0xba,0xce,0x48,0x0,0x8,0x7,0x1e,0xda,0xe3,0xe5,0xae,0xd,0xe,0xa1,0x65,0x2,0xc6,0x2,0x8b,0xbd,0x47,0x9f,0xa9,0x9d,0x4f,0x9c,0x57,0xa7,0x6,0x27,0x40,0x71,0x14,0x20,0x3c,0xaa,0xff,0xff,0x6c,0x32,0x40,0x5,0xfe,0x0,0xd7,0xe,0x3b,0x1e,0x11,0x1,0x0,0x0,0xe2,0xff,0x52,0x80,0x90,0x0,0x52,0x80,0x0,0x0,0xcc,0x56,0xfe,0xff,0xca,0xff,0x0,0x1,0x5,0x0,0x0,0x0,0x20,0x3,0xc3,0xa8,0x84,0xb4,0xcf,0xd2]);
Serial2.write(B.buffer);

B=new Uint8Array(
[0xba,0xce,0x48,0x0,0x8,0x7,0xb2,0x32,0x6b,0x6b,0x5c,0xaf,0xc,0xa1,0x7c,0x7d,0xc6,0x2,0x3b,0xd8,0xd9,0x8f,0x26,0x34,0x6c,0xb,0xce,0x24,0x20,0x26,0xe3,0x6f,0xdf,0x4b,0xfc,0xa4,0xff,0xff,0x9f,0x39,0xec,0xfb,0x61,0xff,0xc2,0xd,0xec,0x1d,0x34,0xff,0x27,0x0,0x2b,0x0,0x52,0x80,0x90,0x0,0x52,0x80,0x0,0x0,0xc6,0x64,0xef,0xff,0xe9,0xff,0x0,0x8,0x48,0x0,0x0,0x0,0x1e,0x3,0xc3,0xa8,0xac,0x65,0xde,0xdd]);
Serial2.write(B.buffer);

Also, in case you missed it, Gordon has already integrated uploading the ble_epo_offline.bin file using the Assisted GPS app, and it makes a massive difference for TTFF even if a few messages are silently failing under the hood.

So, that is great!, the issue with AGPS is resolved. ( Unless we want to dig deeper trying to load the "big" file from here https://api.smawatch.cn/epo/202201/. I've looked into the file, its data structure is not clear. )
@fanoush - your first item is covered.

Yes I saw Gordon has announced this app. I've just looked into the code. It pushes the file content to Serial. When I tried to do this similarly, manually loading the bin file to storage and then just read it into Uint8Array and pushed the buffer to Serial as a whole, the Serial chocked with FIFO error after couple of messages. CASIC doc tells not to push next message before ACK message is received. I've done it this way in my experimental code, that parses the content and pushes messages one by one. It works ok, though some messages fail with NACK. But at least it does not chock.
The only problem is - how to download the file. Gordon mentioned some Android Bangle Assistant/Companion app. May be this could help? Is there another way to get the file over BLE?

I feel like we're going around in circles here; not sure how many times I need to reiterate that the .DAT files you keep pointing to are not for the AT6558.

https://api.smawatch.cn/epo/ble_epo_offline.bin is for AT6558
https://api.smawatch.cn/epo/202201/m2_epo_offline_2022-01-16_8187dedc4479046dfea07770bea2ecd1.DAT is not? Why do you think so? (Reiteration is not an explanation.)

You're the one who posted the information definitively identifying those files as being for Mediatek chipsets, so I don't know what else to tell you.

Mediatek's one was from http://epodownload.mediatek.com/EPO.DAT
I've looked inside them again, structure-wise the both look similar. So yes, you are right. I was just confused. :)

Anyway what would be a best or easiest way for Bangle2 app to download the SMA .bin file from URL, without a need to go to Apps site and run Assisted GPS manually? This way it can be automated. Because the .bin file is updated at least daily there.

So, that is great!, the issue with AGPS is resolved.

I'm not convinced. The code for the AGPS app is here:
https://github.com/hughbarney/BangleApps­/blob/master/apps/assistedgps/custom.htm­l

Lines 137-141 handle Bangle 1 and send UBLOX AGPS data.

Lines 142-155 handle Bangle 2 and only send a CAS04 NMEA command to select the type of GPS service. The code is incorrectly saying CASIC when these commands are NMEA protocol.
The CASIC checksum is a lot more complex than the code at 122-129 which is only doing a simple XOR checksum for NMEA commands.

The comments in lines 151-154, show that the author knows that to send AGPS to the Bangle 2 GPS chip you need to use the CASIC AID-INI (0x0B 0x01) message and this is not implemented yet.

UPDATE: I should add that using the AGPS app sending CAS04 set to GPS only I did observe the first fix time to be about 1 minute which is perfectly fine for what I want and I could just modify my GPS touch app to send a CAS04 first.

CASIC AID-INI is probably for other data. In the .bin file there are 32 MSG-GPSEPH (0x08 0x07) messages, for each GPS satellite. Then one MSG-GPSION (0x08 0x06) and one MSG-GPSUTC (0x08 0x05). The last one I'd probably re-craft with more current time, if it will work.
All messages already have checksums pre-calculated. They are ready to be pushed to the chip.
The only my concern is, they need to be pushed one by one, after ACK for each message is received. That is how it is stated in the doc.

The only my concern is, they need to be pushed one by one, after ACK for each message is received.

I assume you have sent these one by one manually. You probably only need a 30ms gap between each one. You can chain timeout or use promises. Or a really crude way.

send1() {
      Serial1()....
      setTimeout(  send2(), 25); 
}

send2() {
       Serial1()....
       setTimeout(  send3(), 25); 
}

On Bangle 1 - we just sent the data with enough delay and did not check for an ACK.
It would be possible to measure the time it takes to get the ACK back.