Most recent activity
-
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?
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.