Search results for:

I've seen this occasionally, and as far as I can tell the lcd changes its optical properties very slightly depending on the power state of the watch. It's too fast to be a display update and the blink rate goes up dramatically when I pick the it up and the watch starts querying the accelerometer more often looking for a "twist" gesture.

Layout precalculates the size of the widget bounding boxes. If you do anything that changes the size of a widget you need to call layout.update() before layout.render().

The 10ms jitter is a deliberate collision avoidance mechanism in BLE. Do you really need sub-10ms accuracy on a watch?

If you want to maximise battery life, then there are a few parameters: age, cycle count, charge level and temperature. You can't do anything about age and max charge level. Temperature in the watch should already be below 40C at all times (one would hope, being on your wrist!)

The best thing to do is to not put the watch on the charger every night, but only when the level is low. That'll remove long periods of the battery being at 100% charge. Since the watch lasts for weeks before needing a charge, even a battery that loses 20% after only 200 cycles (a extremely conservative estimate) should still be good for years.

The hole for the barometer is on the top of the watch under the strap pin, so nowhere near the charging connector.

The ephemerides are only valid for about 4 hours, so an upload at midnight is probably not too useful.

@Mark_M, the docs explicitly say CFG commands require waiting for an ACK, all others do not. The AGPS data only uses MSG commands. This is probably because the CFG commands modify flash settings, which are a lot slower than anything that just goes into RAM.

Why does nobody just take me at my word? :)

Line 74-85 - downloads the AGPS data (hosted on Espruino server and pre-encoded)
Line 157-160 - adds JS to the watch upload which writes the AGPS data to the chipset

If you're expecting to see code which interprets/builds binary CASIC commands, there isn't any - the download is already formatted for being written directly to the GPS serial port.

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.

I looked at the code - its not actually getting AGPS data yet - its just setting the satellites to one set or more - which makes getting a first fix simpler.

I don't know where you're getting that idea; it is absolutely downloading the AGPS data and sending it to the watch, and has been since the app was added to the Bangle.js 2 apploader. The constellation selector was committed afterwards and is only of minor/unknown benefit (although you can definitely make things worse if you disable the GPS constellation, as that's the only one we get AGPS data for.)

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.

"Upload" the Assisted GPS app from the app loader before starting a run. This will immediately and significantly improve your initial fix and you should easily get a fix outdoors in only a few seconds instead of minutes.

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.

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.

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.

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.

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. 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.

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.

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.

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.

Yeah, I spent way too long doing exactly the same things as @diego did, and I either got constant build errors due to not having exactly ABI version 88, or I'd get everything just right... and discovery wouldn't return a single result. Tossed the lot out and decided it was just rotten. (for reference, I'm running Ubuntu 21.10 here.)

I've fixed the bugs in my node-ble branch (new PR is up) and it now nicely gives me a terminal and everything behaves as it should. Although not before spending three hours trying to determine why I got every rx packet twice... only for it to stop the instant I closed the (disconnected) WebIDE I had running in another window. So yeah, don't have that going when using this :)

I was just about to suggest/implement an unholy combination of the espruino-cli and this python implementation, and then I noticed there's an alternate BLE node.js module for linux that is a lot newer than noble and uses the DBus interface so it's also much better ergonomically.

So I implemented a new serial plugin for the espruino tools that uses it. Seems to detect and connect to my Bangle without issue. A PR is up on the github now.

Now I just need to figure out why the cli terminal isn't working properly...

@HiFiJ, you can also run the App Loader locally (python3 -m http.server in the BangleApps dir, and hey presto http://localhost:8000) which will handle most of the heavy lifting of an app installation as long as you have apps.json set up.

And after that you can just overwrite the one file you're interested in and leave the rest of the installation alone!

For one, you're trying to manually handle endian conversion, and you've ended up tying yourself in knots. Funnily enough, I'm pretty sure your checksum routine is getting the right answer!

First: the CASIC packet format is 0xBA,0xCE,2-byte payload length,class,id,payload,uint32 checksum. All little-endian. The example packet you have in the comment right above your test() function has this backwards.

So for your example packet (class=5, id=1, payload=[6,0,0,0]) it should look like BA,CE,04,00,05,01,06,00,00,00. The checksum bytes at the end are 0A,00,05,01. And that is 0x0105000A.

function casic_checksum(id, cl, payload) {
  let buf = new Uint8Array(4+payload.length);

  // Varying field sizes is what DataView is for
  let dv = new DataView(buf.buffer);
  dv.setUint16(0,payload.length,true);
  dv.setUint8(2,cl);
  dv.setUint8(3,id);

  buf.set(Uint8Array(payload),4);

  // jazz hands
  return Uint32Array(buf.buffer).reduce((a,b) => a+b, 0);
}

function test() {
  let c;

  c = casic_checksum(1, 5, [6, 0, 0, 0]);
  print("test1 - expecting 0x0105000A");
  print(c.toString(16).padStart(8,'0'));  
  print("");
  print("");
  print("");

  c = casic_checksum(0, 6, [1, 7, 192, 8, 0, 194, 1, 0]);
  print("test2 - expecting 0x08c7c909");
  print(c.toString(16).padStart(8,'0'));
}