Search results for:

The PR does not fix the behaviour when the GB side is configured not to provide GPS events. At least not yet. Can we check if a GB setting is set? Then it would be easy to integrate a check and prevent this situation. If we can not check the settings, maybe the app should send it's GPS setting state to the bangle when the gps_power message arrives?

I have had this exact problem on imageclock while working with 4 bit. Copying over my solution from there yields the correct result, but it seems a bit complicated. It essentially uses a palette to force the colors to be correct. I suspect there is an easier way.

    let colormap={
      "#000":0,
      "#00f":1,
      "#0f0":2,
      "#0ff":3,
      "#f00":4,
      "#f0f":5,
      "#ff0":6,
      "#fff":7
    };

    let palette = new Uint16Array([
      0x0000, //black #000
      0x001f, //blue [#00f](https://forum.espruino.com/search/?q=%2300f)
      0x07e0, //green [#0f0](https://forum.espruino.com/search/?q=%230f0)
      0x07ff, //cyan [#0ff](https://forum.espruino.com/search/?q=%230ff)
      0xf800, //red [#f00](https://forum.espruino.com/search/?q=%23f00)
      0xf81f, //magenta [#f0f](https://forum.espruino.com/search/?q=%23f0f)
      0xffe0, //yellow [#ff0](https://forum.espruino.com/search/?q=%23ff0)
      0xffff, //white [#fff](https://forum.espruino.com/search/?q=%23fff)
      0xffff, //white
      0xffff, //white
      0xffff, //white
      0xffff, //white
      0xffff, //white
      0xffff, //white
      0xffff, //white
      0xffff, //white
    ]);

    let g2 = Graphics.createArrayBuffer(g.getWidth() * 2, g.getHeight(), 4, {msb:true});
    let g2img = { width:g2.getWidth(), height:g2.getHeight(), bpp:4, buffer:g2.buffer, palette: palette };
    let R = Bangle.appRect;
    let x = R.w / 2;
    let y = R.y + R.h / 2;
    let animInterval;
    let animate = function(step) {
      if (animInterval) clearInterval(animInterval);
      slideX = -g2.getWidth()/2;
      animInterval = setInterval(function() {
        slideX += step;
        let stop = false;
        if (slideX>=0) {
          slideX=0;
          stop = true;
        }
        g.drawImage(g2img, slideX, 0);
        if (stop) {
          clearInterval(animInterval);
          animInterval=undefined;
        }
      }, 50);
    };
    g.reset().setBgColor("#0f0").clearRect(R); // clear whole background
    g.setFontAlign(0, 0).setFont("Vector:30").drawString("WIBBLE", g.getWidth()/2, g.getHeight()/2);
    let screengrab = g.asImage();
    // Draw to offscreen buffer
    g2.setColor(colormap["#f00"]).fillRect(0,0,g2.getWidth(),g2.getHeight());
    g2.setColor(colormap["#fff"]).setFontAlign(0, 0).setFont("Vector:30").drawString("FLIBBLE", g2.getWidth()/4, g2.getHeight()/2);
    g2.drawImage(screengrab, g2.getWidth()/2, 0);
    animate(3);

Edit: The forum search links in the comments are somehow autogenerated from the #colorvalues

Wow, that is very cool. Throw GPS in there and some kind low power display (epaper or transflective LCD) and it would be very close to perfect for me.

Just a note on another minifier problem:
Classes defined in the script seem to be removed by the minifier. Wrapping the script in a scope apparently works around this. At least it does for 2047pp. https://github.com/espruino/BangleApps/pull/2500

Maybe a "hidden" key is enough, with a switch in the alarms app options toggling between showing everything or only not hidden timers/alarms. Since the sched lib works really well any duplication of the functionality there would be suboptimal.

I might have to test drive that clock for a bit...

The userbase for the Bangle watches is in the thousands, the user base for unofficial but half decent working other watches will probably be more like lower single digits ;)

Installing Gadgetbridge on GrapheneOS is tricky

This behaviour seems to have started with the update to Android 13. I can not say that for sure, since the device also has changed from Pixel 4a to Pixel 6a at that time, but I suspect the hardware has nothing to do with this. Installing the Bangle.js build from the Playstore (I used Aurora from FDroid to do that) has worked and the notification access permission can be set to on as expected. Both versions of GB from FDroid do not work on that device for me, the changing of the setting is just not allowed.

All in all a very nice addition to the bangle :) This even makes auto-updating the position for the "My Location" app easy on the battery.

Just some notes on some of your points:

• Charger shorting out on metal surfaces is a valid point, but more for the attached power source than the watch itself. There are some 3D printable or laser-cutable charging cradles. Those should help out with this.
  
• The bottom "plastic" surface is glass and had a protector on it on my bangles :) The Bangle itself stands up to surprising amounts of abuse for me without looking to scuffed, scratches all over should not be normal on a new one.
  
• Battery charge level is measured as a voltage and not all Bangles are created equal in that respect. There are manufacturing differences in the voltage divider resistors which can cause inconsistent behavior between two watches on charge level readouts. Settings->Utilities->Calibrate Battery on a fully charged Bangle should help with that by storing an offset for the fully charged voltage and essentially marking that as 100%. There is a "Power Manager" app, which can automate this and additionally force monotonic voltage and percentage outputs.
  
• If you have the wake on twist enabled maybe the thresholds can help with the watch lighting up. There are some apps that can cause lighting up sometimes, Quiet Mode Scheduler comes to mind
  
• Normal Gadgetbridge should work fine for the most part, but not all features are implemented there. Bangle Gadgetbridge is not really a fork, just a different build of the same code with more access rights enabled (Internet access mainly). There is an FDroid repository containing a nightly build for the newest features.
  
• Backlight turns on with notifications for me
  
• Sleep stats are not yet transmitted as far as I know
  
• I too have syntax-error toasts, but those could easily be caused by one of my many installed apps, since the do not seem to create any further problem I currently ignore them :)
  
  

The GrapheneOS thing interests me, I see the same problem with another watch and phone and default GB build from FDroid without a solution so far. Does it actually work for you if the APK from FDroid is installed manually by e.g. file explorer or do you mean something like Aurora installing the Playstore-APK by "other client" ?

There is an app list at the bottom of the "More..."-tab in the device info section.

How about just adding the versions to the installed app list in the "more..." tab of the apploader? The information should be already available there.

The phone delivering GPS data is done to save power when GPS is active on the bangle. It does not push GPS events all the time.
The automatic fallback just restores the default Bangle GPS behaviour when some app is using that. So if you use GPS on the Bangle you usually are aware of the power use and in case the phone can help out you save power with this feature. It does not use additional power in any previously possible usecase.
The nightly on fdroid already has these changes. Did not test a lot, but the location icon on the phone pops up if I start a GPS app on the Bangle.

I think you have hit an edge case there. Clocks can fastload iconlaunch since it contains loadWidgets, but iconlaunch does not handle the possibility of already loaded widgets in the case of being fastloaded with fullscreen configured. The solution would probably be using widget_utils to hide the widgets if settings.fullscreen = true.

Small update: Have not connected the Bangle to GB since saturday morning, no freezes since then and significantly lower battery use.

PRs welcome ;)

OK :) #44

The name of the Bangle changes from "Bangle xxxx" to "DfuTarg" when it is in the DFU mode. It is what you need to select in the app by Nordic.

Bangle.js 2

Long-press the button for about 10 seconds until the screen goes blank
While ==== is going across the screen, release the button (releasing it later will just boot back to Bangle.js)
The watch should now be in DFU mode

You can find the complete description here:
https://www.espruino.com/Firmware+Update#android-ios-app

Since in this case only the specific combination of one Bangle and one Smartphone is relevant, maybe a configurable RSSI value as threshold is good enough? I think at least leaving the room should be clearly distinguishable in the RSSI values and would be better than complete connection loss as the only indicator. Can we get the RSSI of the connection to the Phone, maybe using this https://www.espruino.com/Reference#t_l_NRF_setRSSIHandler?

setting.json is the file I meant, it caches if the last set clock had widgets at that time. Rewriting the settings currently just recreates the .boot0 file, that would not help in this case.
Just go into the settings app
-> System
-> Select Clock
-> Select your clock, even if already selected

That will recheck if the clock has a loadWidgets call and update the cached value accordingly. You can check the value by opening setting.json in the IDE before and after.

You have your BANGLEJS2 constant defined in the big scope for cleanup and the handler is run in the global context. The variable does not exist there and is undefined so the check never triggers. To solve that either move the declaration out of the block and later delete global.BANGLEJS2 in the remove method or access process.env.HWVERSION for every check instead of storing the result in a constant. Same applies to stuff running in timeouts and intervals.

For the "has no widgets" message, maybe you need to update the clockHasWidgets value stored in the settings file? It was possibly set at a time where your clock did not yet have loadWidgets. You can update that by just setting the clock again in the settings app.

I have tried several kinds of tape (kapton tape, generic electric tape, 3M clear waterproof repair tape), but the best so far is generic clear document film (known in Germany under the tesafilm moniker). I use a strip about 5mm wide to cover both middle contacts and to give it some area to cling to it is quite long. Starting directly at the ridge of the heart sensor to have no easy starting point for it to peel off and extending over the two contacts to the next ridge in the bangle case under the strap. Close to perfect since a few months and very easy and cheap to replace if it should fail. Tried nail polish and acrylic paint as well with very mediocre results. Be careful how you clean the watch before applying tape or paint, the ABS plastic really does not like acetone as found in some nail polish removers.

I have captured another log. Clock was frozen at 11:41 and log goes back to 9:10.
First Unable to notify characteristic: null at 11:10:22:934
Manual reconnect in GB at about 12:44.

Bootloader will be installed on close to every bangle in active use, that is on 151 installs currently. Is think there are just not yet that many people reporting those statistics. That makes for about 10% of reporting users having installed BW-Clock and "only" half having Anton. Since Anton is preinstalled that is actually a surprising amount of users having actively removed Anton.
Maybe showing a percentage from available reports additionally to the number would be helpful to gauge interest.

I like to have a local apploader running to be able to install an app containing multiple files to the watch in one go and then just copy the one file I currently work on to the web IDE and set it up to push to the corresponding file on the watch (as set in metadata). For the local apploader I just installed https://jekyllrb.com/ and run jekyll serve in my apploader checkout. Default access is then on localhost:4000.
Only disadvantage is the missing way to use the emulator. Being able to install from apploader to emulator would be nice.

(previous message)

I have noticed a hanging watchface today, stuck on 18:41. Last value for battery in GB is 15:11 (100%). I have powermanager with monotic voltage/percentage settings active, so quite possible there was no change in reported battery between 15:11 and 18:41. Next battery value is 56% at 20:48, so quite a big drop. Maybe something going into an endless loop, eating cpu cycles?

Watch was still connected to GB at 20:48. I saved two GB logs, one 20:48 before reconnecting and one 20:50 after reconnecting. Both logs are identical save the additional lines in the one saved later.
It starts at 19:13, so the moment of freezing was not captured, but there are a whole lot of

19:13:32.816 [main] WARN  n.f.g.s.b.TransactionBuilder - Unable to write characteristic: null

lines.

First log stops at 20:47:33.853, so definitely still hanging then, reconnect in GB reviving the Bangle shortly after that. Sadly nothing obvious (at least to me) in the logs. Saving the debug logs did not actually store the logs. I am using the fdroid version of the app.
I have attached a log with private info replaced by placeholders.

Edit: Not a percent of battery lost in the last hour, so hanging actually does something expensive in terms of power use on the watch.

---

Yes, did not touch the bangle after noticing the freeze. Disconnecting and reconnecting in GB usually brings it back, holding the button for full reboot works as well. I'm on 2v16.7 currently. I had some hangs that could not be solved by reconnecting in GB, but have not seen one of those for months.