Search results for:

Gordon will be along during working hours. I will bet he has some ideas to diagnose the problem, but if not I've seen a few people on here offered a replacement for faulty watches, so I am sure you won't have an issue.

I can only speak for myself, but in even fairly low light the screen is readable without the backlight. I have brightness set to 0.1, but most of the time it is unnecessary. Something sounds odd for you.

Oh, so you did! I guess I tried it before you did that (or I wasn't paying attention).

@malaire this was more a curiosity for me because I haven't noticed click drift large enough to personally care about, but I was thinking you could do something with this to make measuring the drift easier for use in your widget... maybe press a button, it sets the bangle time to computer time and puts a timestamp in a cookie or local storage, then the user can come back at a later point and press another button to calculate the drift? I don't know how long you need to reliably determine the drift, perhaps it could be done without storing anything at all?

Edit: if you made it that easy, you could probably convince people to contribute their clock drifts and you could work out what the range is across bangles.

So you can set locking independent of the LCD.

Oh, that is much easier. Somehow I assumed that Bangle.setOptions would actually write the new settings like the Settings app does.

Maybe just disable locking in your app?
Perhaps a Bangle.setLockTimeout like Bangle.setLCDTimeout would be useful?

Right now you could do:
Bangle.on("lock", (state) => {if (state) Bangle.setLocked(false);});

if you imagine something like the Settings app, it means that it'd have to have every menu loaded into RAM at once. We really need the functions. We could have "Submenu" : { submenu: function() { ... } }, though I guess.

Ah, ok. I thought about it accepting either the object or a function, but looking through my blinkers at the original gist I didn't think about the need memory issue.

Personally I don't exactly love using the label for this (nor the back button, not sure about the memory issue, but I'd have been tempted to have parent menu as an optional parameter to E.showMenu rather than needing to put it explicitly in the submenu). Does using the label add any confusion for translations? At the end of the day, though, the important thing is the distinction between submenu and action.

Maybe "Special"? I feel "Config" doesn't cover the range of things that would be in there - Firmware Update isn't configuration, for example.

This is the gist from the start of the thread, modified in the way I described (the non-hacky way).

https://www.espruino.com/ide/?gist=e346a3df9ab3ab26e5f4238c15e8f7f0

The changes required to menu code are:

// First menu
var mainmenu = {
  "" : { "title" : "Main Menu" },
  "< Back" : function() { print("Back") },
  "Submenu" : function() { E.showMenu(submenu); },
};
var submenu = {
  "" : { "title" : "SubMenu" },
  "< Back" : function() { E.showMenu(mainmenu); },
  "One" : undefined, // do nothing
};

becomes:

var submenu = {
  "" : { "title" : "SubMenu" },
  "< Back" : function() { E.showMenu(mainmenu); },
  "One" : undefined, // do nothing
};

// First menu
var mainmenu = {
  "" : { "title" : "Main Menu" },
  "< Back" : function() { print("Back") },
  "Submenu" : { submenu: submenu },
}

This is a hard one - as far as the menu system is concerned there is no difference between a menu item that does something and one that opens a menu - they are both items that are tapped. I guess we could try and have some kind of way of distinguishing them...

If you are happy for this to require a code change in apps, I will submit a PR for this. Unchanged apps would work but would show submenu without the ">" as it was in a previous iteration of the new system. I imagine this is OK, as apps need to change for the booleans anyway.

Edit: Actually, I think I can do it without requiring any change on the app side... I will report back.

Edit Edit: Ah, no, that was silly. Original offer stands.

Edit x 3 ( a longer one):

I can do it so it doesn't require any changes on the app side, but it feels a bit dirty...

My original idea was to change the way submenus are created to an object with the key submenu (the value would be the submenu itself). Standard menu items would be rendered without the ">" but if the item is a submenu, it is rendered with it. Existing code would work, but would not show the ">".

My hacky idea is to call .toString on the function in menu items and see if it contains E.showMenu. I think I would prefer not to do this, but existing apps can't be changed to use the { submenu: submenu} style until everyone has the new menu system (or can they?).

OK. Good to know. I finally had chance to look at what the algorithm is doing with mine and I can clearly see the skipped beats. Probably just need a tweak to the peak finding algorithm (or valley finding as it is if I remember correctly).

Maybe Firmware Update should have special treatment? It isn't that obvious that you need to use an app (that isn't even an app in the usual sense).

@Aadrik is the confidence higher with the correct or low reading? It should be higher when the reading is correct, but I wonder if like me you will see the correct rate has close to 0 confidence and the low one ~100%.

Is it just me (pretty sure I installed the latest update) or does everything still look like it goes to a sub menu? I think the distinction is important - a curious person might press e.g. factory reset if they think there are further options, but don't actually want to factory reset.

I don't know anything about Chromebooks but I always set that window to be "always on top" (Linux window managers usually have this feature easy to find, Windows you can do it with autohotkey.

Also working for me. Required a refresh (I guess the browser had cached it?)

Ah I had the same in the dev app loader last night but I thought it was my phone/browser.

Edge on Android (LineageOS).

Hi,
Also a Linux user. Not had an issue with the Bangle yet but had issues with other random Bluetooth things. When this sort of thing happens, best bet is to try combinations of reboot, restart the Bluetooth service, and toggle the adapter with rfkill. You could use rfkill to choose your adapter I guess, but don't think it is your main problem.

Hi @Niko,

Which firmware version are you on? If you are not on 2v12 then upgrading (using the firmware update "app") should make a difference.

Heart rate while exercising is not expected to he accurate yet but it is being worked on. Personally I see a low heart rate at rest about 50% of the time, but I am an outlier so hopefully you'll be OK on the latest firmware.

ESP32 does support BLE*. Maybe you are mixing up with ESP8266 which doesn't?
You might be able to do what you want with MicroPython.

• but I gather from this thread Espruino + ESP32 doesn't?
  

You say you can't scroll in the menu. Can you select an item if it is already highlighted? I thought I remembered someone having the same problem- I misremembered, but the code @Gordon gave for diagnostics in that case will still be useful I think: http://forum.espruino.com/comments/16366989/

1. 2v11 isnt the latest stable version, 2v12 is. You can install it using the Firmware Update "app" https://banglejs.com/apps/#firmware%20update

2. Are you saying you don't have the default apps (including settings) installed? Could you install the Settings app just to sort your debug issue? Or are you saying something different?

I've just flashed this and I agree. The back button doesn't fit in somehow, is easy to miss when touching, and can be confusing because it isn't there when you are e.g. in the multiple choice screen. Aesthetically I also preferred the way the title was displayed before (centred with a horizontal rule rather than the hamburger icon). On the whole though, this feels like a huge improvement.

Can confirm that the first reading of getPressure() results in undefined, subsequent readings are fine. I've tested with a Kickstarter Bangle 2 and a newer Bangle 2 and this problem only occurs with the newer one. Presumably related to the different sensor?

It depends. I think the end result will probably not be identical, and I have no idea what is more efficient.