Search results for:

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 :)

Nice, very useful. Was this the first opening of this particular watch? If so I need to get me a hotplate :) Mine fought back A LOT more using hot air.

Great :) The json you had posted seems to be valid, but if that indeed was the cause, there is a "Reset Settings" button in the "More..."-tab in the apploader that deletes the setting.json without using the IDE.

Maybe you can take the setting.info file from the backup and see if that one is valid? It also contains json.

Just delete the 4 setting* files and after a reload the settings app is gone. Do you have constant output on the left side of the IDE? If so maybe you can identify the app that is messing with your app update?

Yeah, copied the wrong link... https://www.espruino.com/Bangle.js2#rese­tting-without-loading-any-code

That can happen if some app does write to the console during the update. Just try again a few times. If it does not work, boot the Bangle without loading anything and perform install/removal then. There it should work. https://www.espruino.com/Bangle.js+Getti­ng+Started#resetting-without-loading-any­-code

That seems weird. Maybe the app info file that gets generated during install was somehow corrupted? In any case, reinstalling settings will probably help. Maybe perform a backup before using the app loader in case there is more corruption going on.

Yes, sure seems that way. This was sitting and snacking. So not completely without movement but close. Kickstarter version Bangle.

Do you maybe have .../index.html instead of .../android.html in your URL config for the apploader?