Search results for:

Not really, since the uploaded data only contains these 24 hours of data. If you can find another file containing more data for the GPS chip you could use that. If you use Android/Gadgetbridge you could use https://banglejs.com/apps/?id=agpsdata to automatically update the AGPS data in the background.

Thanks :) I cut down the top case a bit to get it closer the final dimensions and started carving out a bottom plate with material left for mounting the board.

Tried the first few cuts. Went better than expected :)

You need to use the Bangle.js variant of GadgetBridge. Have a look at https://www.espruino.com/Gadgetbridge#ht­tp-requests .
You can also have a look at https://github.com/espruino/BangleApps/t­ree/master/apps/owmweather since that does something similar to what you probably want to do.

I wanted to have a go at FreeCAD and thought designing a case for the bangle would be nice to try out modeling something to actually build for the first time :)

Wishlist:

1. USB-C for charging
   
2. Buildable by me
   
3. Not a lot thicker than the original case
   
4. Rugged (primarily better screen protection)
   
5. Screw on back.
   
6. Maybe even waterproof? (Found waterproof USB-C ports on ebay)
   
7. Keep HRM
   
   

TODO:

1. Try making space for a bigger battery (36x25x4 330mAh might fit with about a millimeter more thickness)
   
2. Simplify band mounting (just loops for textile straps maybe)
   
3. Solution for mounting internal components without to much glue
   
4. Find out if I can actually build the thing
   
5. Find out if the HRM can be removed from the original case without being destroyed
   
6. Refine the hardware mockups for better internal space representation
   
   

Has somebody attempted something like this? I am sure this will take some iterations and probably fail in the end but no way of knowing without trying, eh?

I have an old manual proxxon desktop mill that can do about 0.1mm precision and some other tools and want to do this in aluminium.

I'll attach the FreeCAD file but be assured that it probably is not well done as I do not have experience with it or CAD at all.

It sounds like if it is possible at all CPU-wise it will be awfully close. Probably too close for someone (Nordic) to attempt to implement newer bluetooth LE codecs on these chipsets. If it somehow actually works, storage would be the next big problem. 8MB flash is not much to store audio samples.

Oh wow, the confusion was on my end 😑.
My function ignores the first character and so it needs the $ given to it to directly ignore it...

I have tried it with PCAS02, the command to change the update rate and without the $ included in the checksum it changes nothing while including it works.

print(require("pcas").checksum("$GPGLL,5­300.97914,N,00259.98174,E,125926,A")); creates a checksum of 28 which matches your example. Doing the same without $ calculates 6F as checksum.

require("pcas").checksum is as follows:

function checksum(cmd) {
  var cs = 0;
  for (var i = 1; i < cmd.length; i++)
    cs = cs ^ cmd.charCodeAt(i);
  return cmd + "*" + cs.toString(16).toUpperCase().padStart(2­, '0');
}

I expect it to be a bit slow but copying current screen content into buffer, showing that as static overlay and then just waiting until the load is done before sliding the overlay buffer away like the hidden widgets do could work. Of course that would only work for fastloaded apps since there is no easy way for keeping display contents over a normal load. This would mean only one full screen extra buffer and no switching buffers around without the app knowing.

That is quite possible, the antenna is glued to the case and contacted by a spring contact on the mainboard. So it may have just corroded a bit if you had at some point humidity in your watch.

It does, but that happens after the checksum is calculated. The cmd going into checksum() does not yet contain it.

You are checksumming the command without the leading $, I think that needs to be included.

I currently use a protector made with the method described here: https://forum.espruino.com/comments/1642­1375/

It is now a matte one. The matte smartphone protector (for S22, so at least 6, maybe 8 Bangle size protectors) I used as base actually had two layers, a thicker clear one, too inflexible to be used on the bangle and a super thin matte one. I applied only the matte to my bangle and it has stood up to a lot of abuse. Some climbing and demolishing a brick wall included. It is obviously due for replacement in it's current state but it just got destroyed with no peeling at the edges. Initially applied 10.2022.

I have tried to make the PCAS-commands a bit more usable in a library, but some seem to do nothing at all (e.g. setting Standby mode) while other work fine (update interval). Is there a way to dump the current config to check?

Does your command miss the checksum or did you omit that on purpose?

https://github.com/halemmerich/BangleApp­s/blob/pcas/modules/pcas.js

To give some indications for speed/RAM:

1. Allocation of one full screen 4 bit buffer on Bangle.js 2 would be about 10% of the RAM. On Bangle.js 1 probably more like about a quarter.

2. 1000 iterations of an empty for loop take nearly 230ms

3. Assigning a variable on each iteration costs 136ms extra

4. Commenting out that assignment still costs 24ms over the base loop

As for javascript as the language of choice I'm with @fanoush. You could use C/C++ like on other micros, but that will cost a lot of convenience and simplicity. Nevertheless you can even include native/compiled code in the JS if you need every last bit of speed the processor can muster.

If protection of e.g. the GPS tracks on the watch is the goal here, maybe regular or automatic sync (with auto delete in case no sync happened for a while) of the data to GadgetBridge or wherever and then just deleting it from the watch would be a way to tackle this?

There are functions in the GPS context that would do well and be useful in a module, for example compass noise filtering, handling access to track data more encapsulated, "sensor fusion" between compass and GPS and lots more of smaller things that could be useful outside of their apps. Some refactorings in this spirit I would like to do to GPS Trekking.
When developing for the Bangle, there are some tradeoffs to make. One big part of the execution time is actually parsing the javascript text. So the "form" of your code directly influences execution speed. I have written Imageclock and learned the hard way how expensive function calls and verbose code are. In there I started with recursively parsing JSON and rendering that as a watchface. That was so slow that watchfaces with seconds just weren't possible. "Flattening" that tree of watchface components in the browser and generating the rendering code for the Bangle got that several times faster for some watchfaces. It was calling exactly the same rendering code for the elements, just no longer recursively traversing the JSON saved that much execution time.
Another example would be the Layout module. It's great for easy creation of layouts, but if you need to refresh often or are doing memory intensive stuff otherwise you will probably run into problems with either speed or RAM usage. That's not to say Layout is not a great module, I try to use it whenever possible. But it shows that on a platform this constrained there won't be a way to make every code nice and tidy, sometimes getting to the edges of available resources means ugly code or hacks to even get it to work at all.

Besides the performance and RAM reasons for keeping the code "flat" there should also be taken into consideration that there are users who are technical novices just starting out to code using the espruino environment. Too much rules and focus on "best practice" could maybe deter those from even trying. There are however some apps already using typescript, so I do not see a problem in trying to get better code quality for some apps while keeping in mind the resources (especially in Bangle.js 1) and the beginners just starting out.

The Bangle.js 2 already has a transflective display :)

This sounds different to the freezes I had. Do you use the default messaging ui app or one of the other ones? I had complete freezes (no reaction at all on the bangle), often remedied by disconnecting and reconnecting GadgetBridge.

I haven't seen it in while now and had this problem a lot before. I think there were some fixes regarding buzzes causing some buildup of intervals or timeouts and some other stuff regarding handling of messages fixed in current firmwares. Do you already use something newer than 2v18? I currently use 2v18.90.

It partly works, just the inital draw does not seem to happen. If you scroll up and down there are numbers drawn.

I had just enabled the Pebble-messages and disabled normal notifications for OsmAnd in the GadgetBridge notification filters. But at least for the current Bangle.JS GadgetBridge nightly installed from FDroid this seems to be no longer needed. With the default Message UI app the navigation messages seem to be handled correctly via some kind of native OsmAnd integration. At least I see arrows and symbols for things like roundabouts when using navigation with OsmAnd.

If the motivation is saving power this won't do much. AFAIK the display is still refreshed at about once a second. If no code is loaded the Bangle 2 runs for a really long time. I tried to record a discharge curve and lost about 20% of battery in 4 weeks before giving up. Maybe a 0 brightness setting would be more useful for very low power use.

It does not load another app, but it does not yet use the message events. It overrides the require call for the messages lib which is quite hacky. Boot order won't save that, only updating messages overlay to correctly using the messages event will help.
I wanted to have a go at updating messages overlay anyway since it does not work correctly with navigation messages. If you want to help out with that feel free to do so, otherwise I fear you will have to wait until I find some spare time :)