-
-
Is anyone else finding that the GPS performance of the Bangle2.js is significantly worse than that of the Bangle.js? I ran this code on the Bangle2 and placed it outside on a south-facing window ledge:
var max=0; var count=1; var max_count=1; Bangle.setGPSPower(1); Bangle.on('GPS',function(fix){console.log(fix.satellites + ' satellites at ' + count + 's, max is ' + max + ' at ' + max_count +'s');if (fix.satellites>max){max=fix.satellites;max_count=count;}count=count+1;});
After 20 minutes it was seeing 7 satellites, a total which had been reached around 6:30 in and remained consistent from then on. I uploaded GPS data (GPS only) and ran it again; this time it had seen 11 satellites within 2 minutes although the total varied between 7 and 10 until the 20 minutes was up.
I thought uploading the data was only supposed to decrease time to fix, but it looks like it somehow determines whether the sketchier satellites will be visible at all. For the original Bangle.js you also have a choice of how many days' worth of GPS data to upload, but for the Bangle2.js there is no indication of how long it will be valid for. All that aside, when wearing both watches at the same time and saving a GPS track, the Bangle.js invariably does a far more accurate job.
-
-
Is anyone else unable to update the Settings app? As soon as I try, the time and date revert to 01/01 01:00 (or similar), the watch disconnects, and I have to close and reopen my browser to get it to connect again. This has only been happening since I updated to 2V13. All my apps (including Settings itself) seem to be intact.
-
-
-
Uploading AGPS data is still flaky and fails most of the time although I can usually get there eventually. I have tried flipping between the few apps I have installed while connected to the IDE but didn't see any errors. While trying to upload AGPS data just now it showed me a bunch of "OK" lines and then "Uncaught [object Object] at line 1 col 226".
-
-
-
-
-
-
-
var c = require("Storage").readJSON("myfile.json",true); console.log("type of c is " + typeof(c));
If I am reading the documentation correctly, if myfile.json is mangled, c should be set to undefined, but my app simply dies and never logs anything at all. (If myfile.json doesn't exist, c is set to undefined as expected.) If I change "true" to "false", a syntax error is logged and then the app dies. For the record, myfile.json contained "#0f0" when I discovered the issue, which I am currently working around with try/catch.
-
-
-
Took out the second g.reset() and it still hung, at 19220 this time. I have previously had the app hang without RAM Widget loaded so the fact that it hangs with the Bluetooth widget displayed would seem to implicate Battery Level Widget (with percentage). Running another test just now, will see if I can get anywhere with Ctrl-C.
edit: I see suspicion about Battery Level Widget is growing :D
-
I have been wrestling with my app mysteriously hanging, requiring a long press of BTNs 1 and 2, and believe I have tracked the problem down to Bangle.drawWidgets. It happens randomly and I have only ever seen it happen when both GPS and HRM power are enabled. The widgets I currently have loaded are Bluetooth Widget, Battery Level Widget (with percentage) and RAM Widget. The following code demonstrates the problem:
var ctr = 0; g.clear(); Bangle.loadWidgets(); Bangle.drawWidgets(); Bangle.setGPSPower(1); Bangle.setHRMPower(1); setInterval(function(){ g.reset(); g.setFont("6x8", 3); g.drawString(ctr.toString(),60,60,true); if(ctr++%10 == 0){ g.reset(); Bangle.drawWidgets(); } g.flip(); },100);
When it hangs, which can take anywhere up to an hour, the count is always a multiple of 10 (e.g. 16140 in my final test just now) - hence my assertion that drawWidgets is triggering the problem - and the only widget remaining visible is the bluetooth symbol. The app hangs on both the current stable firmware and bleeding edge. Nothing is logged on the console and memory usage (when running test code above) was stable at 22%.
-
-
Thanks, and sure enough, I found a thread from a couple of months ago where the same problem was described and the g.reset() solution was advised, but isn't this actually a race condition? If a widget can call bangle.drawWidgets() itself, wouldn't I really need to call g.reset() before every single instance of g.drawString() etc., and even then, it would only maximise my chances of winning the "race"?
-
After a good deal of testing I have come to the conclusion that either I am handling widgets incorrectly in the app I am working on, or at least one widget (RAM Widget in this particular case) is misbehaving. The problem can be demonstrated with this simple code snippet:
g.clear();
Bangle.loadWidgets();
Bangle.drawWidgets();
g.drawString("hello world",64,64);The string "hello world" appears on the display somewhat to the left of the expected 64,64. If I comment out the Widgets lines, it appears at 64,64 just fine. Battery Level Widget (with percentage) and Bluetooth Widget don't cause this problem. So is it my code, or is it RAM Widget, or possibly even the firmware?
-
Thanks, seems to be working normally now.