Search results for:

Hm, I saw that it was running out of memory. Could be my code, but the clock app worked now since July ...

Since I'm using this version I get a strange behaviour: The time and date resets after approx 10 to 90 minutes - but only when I wear the watch. Everything is fine when the watch is on the desk e.g. during night and not being moved. Has anyone else a smiliar behaviour? Since it appeared together with the acceleration changes in the firmware - might there be a connection?

@Gordon it seems that with the latest cutting edge firmware my Bangle.js is back in business. Thank you!

@Gordon from the first 30mins - it's looking good. And if I trust the battery level it even charges the watch without a power plug :-)

@Gordon yes, it's now running the latest version. I will report the next days and I will also re-enable the second interval.

I can only repeat my point from the other the thread: If I reduce interval calls the battery lasts longer. The more interval calls I have the more dramatically the battery duration drops. Just an observation for my case, but I like to remind to this.
In detail: my watch app has an interval event even without active display every second (yes it's not best pratice, but for this although a good idea) Battery lasted with V5 more than one week, even if I paint the watchface without display on. If I do it now with latest fw battery lasts two to three days. From my point of view the interval causes got more battery consumption. I can't tell where the underling problem is (e.g. power saving). But maybe this is a hint.

@d3nd3-o0 Thank you I appreciate your work!

Uh, I tested it with several versions. It started with the versions that include the new font as far as I remember. I suggest to compare the latest version before the new font and the the latest edge version.
The problem must be in interval oder date, which seem to be much more expensive than before. Even calling evey second the watch lasted one week. With the latest versions it lasts less than the half. Even when disabling this the runtime dropped.
Thank you for taking this serious!

So I analyzed it for my case: I used a one second interval to test for full hour to produce a chime. This was no issue before, but after firmware upgrade (also latest) this leads to drain. When I disable this, the interval battery drain stops. It involves only interval, date and 24 times a day a buzz.

I changed nothing for weeks but the firmware. Before it ran for more than a week, now sometimes less than two days. And it is unpredictable. It drains slow than suddenly fast. It's also strange that the battery widget shows "old" values. My app shows other values (widget from app loader approx 90% bar, my app 56% as a numeric value), but the drop was not that high in the widget update cycle.

Hi,
has someone a similar experience? I updated to 2v06 and after this the time on battery drops from more than one week to two or three days. It might be that my Bangle.js is a special case where this effect is getting more visible than on others. I'm running a hour buzz chime which (unnecessarily) checks every second if another hour is over. But this (and also the 24 buzzes) did not drain the battery that much in the previous versions.
Something is different in this version.

Tx

Stable fixed the BLE problem. Hopefully also the erase problem. The watch felt slow even after the unwanted erase without any code.
At the moment I also got with this the old font back, which looks definitly more elegant than the new one. Is there any possibility to load the old font on a Bangle with a newer firmware?

No, it's random while the watch sleeps. The watch behaves strange since the last firmware update. I'm recovering from the latest erase and it takes five minutes to get the code on the bangle. I'll try to go to the latest stable firmware version.

Whoops it did it again ... It happens when I detach timers and the LCD sleeps.
Last code is:

Bangle.on('lcdPower',on=>{
 console.log("LCD Event"); 
 if (on) {
    console.log("LCD Event ON");
    //state.screen=scrnClock;
    b.clear();
    if (state.screen==scrnClock) {
      writeTime();
      writeCircles();
      state.clockDots=false;
      writeClockDots();
      handleSecondClock=setInterval(clockUpdate, 1000);
    }
    if (state.screen==scrnDate) {
      writeDate();
    }
    g.drawImage({width:240,height:190,bpp:1,buffer:b.buffer, palette: color},0,48);
  }else {
    if (handleSecondClock){
      console.log("LCD Event: Clearhandle");
      clearInterval(handleSecondClock);
      handleSecondClock = undefined;
  }
 }
});

I have traced the memory status via console.log. I can't see a huge memory allocation in the code. All memory consuming variables are local with a strict scope and all timer-related ones global, so that there can't be duplicates caused by timers. I meanwhile think that launching the external js is the best solution since it leaves some more memory for new functions :-)

By the way: I got for the first time today a "storage is corrupt" while uploading the app. The firmware handles this in a good way and leaves the device functional although everything must be reinstalled.

Thank you Gordon, yep I did it this way. The strange thing is that the maximum memory usage is 73% when it is out of memory. I implemented a workaround: The clock launches an external launch.js and in the end it launches the clock if nothing else is launched. Works "ok" since it flickers, but it works.

I'm rewriting a clock appliction with intgrated touch launcher to a buffer-based app. I'm using a 1 bpp array buffer and the app is meanwhile getting big. When I start the app I'm using 53% of the memory (including buffer). When I retrieve the app list from the storage I'm running into memory problems. My idea was to free the buffer for the launcher part by assigning an empty array and afterwards to reallocate the buffer for clock operation. However I'm running into memory issues since it seems that the garbage collector of JS is slower than a user can interact with the watch, e.g by pressing the assigned exit list button, which then clears the list and quickly reallocates the buffer.
Is there any way to get rid of this memory problem?

Hm. Looks somehow interesting. This pic is from an existing app in the emulator.

Cool.

When I see this I'm thinking of a stylish hipster wood version :-)

Took Pico, connected with other piezo. And every one from that bunch is very weak.

Sounds that your fix is like the original piezo. You can't barely hear it too. You don't miss anything with your solution compared to the original piezo. From my point of view it's not worth to fix a missing one. Just use the buzzer in your apps.

Have you checked that your computer is NOT paired to Bangle?

there should be a reference to a function e.g.
setWatch(myhandler, BTN4, {edge:"falling", debounce:50, repeat:true});
I'm a the moment a bit unsure whether an arrow function can deliver this. Maybe try an anonymous function().

Hm. Why is in the travis master no bangle.js build file? The older build directories look completly different.

I'm having lots of difficulty maintaining a connection between Bangle.js and Gadgetbridge.

If you have Android this might be the battery optimization. In this case exclude Gadgetbride vom the optimization in the Android battery settings and it will not be stopped by Android.

@PiOfThings: A mean a single connection between two BLE device adresses. I haven't tried python yet.