Search results for:

Might be related: issue #3166

Sorry my fault, I thought I updated. Firmware .20 works.

@Gordon Could we also currently have an issue with backup/restore? I just tried a backup from one Watch and restore on the other and the json files can no longer be read, e.g. sched:

require('Storage').readJSON('sched.json'­,0)
Uncaught SyntaxError: Got ID:t expected '}'
at line 1 col 3 in sched.json
[{t:53100000,del:false,on:false,rp:false­,as:false,dow:127,la...

Also you might want to check issues#3110 and try the new Util.readStorageJSON() (or replicate what it does after downloading the files from the IDE)

Not sure what the problem is, when I try the attached script on 2v20.27 I get

{
"key1": "value"
}

no error.

Not yet, do you always select the same area or did you try different ones? Do you see any output in the console of https://www.espruino.com/ide/ when opening the osm app? Could you maybe attach the openstmap.*.img/json files from the watch? You can download the files in the ide or via backup.

4: I'm curious, do you have a link to the video? I don't see a reason that you 'need' the compass app. But as a casual sailor I say a compass generally often helps.
In the button menu of the osm app you can switch the direction marker between GPS and compass, you can also reset the compass here for recalibration. That should cover most requirements of the compass app.

6: Mainly position + direction. It is also commonly used by the recorder app when plotting the course.

@Ganblejs Did you ever finish this?

FyI: Have not seen the issue with the new firmware version until today. Seems to be fixed, thank you.

~80 BPM was reported by the Bangle

Something like this?

Did a small test on indoor bike (not very representative):
sports mode=-1 (auto): Bangle internal: 111, BT belt: 135
sports mode=0 (normal): Bangle internal: 86, BT belt: 136
sports mode=1 (running): Bangle internal: 103, BT belt: 139
sports mode=2 (ride bike): Bangle internal: 89, BT belt: 134
and just for fun:
sports mode=0 (normal), hrmmar=fftelim: Bangle internal: 131, BT belt: 138

so far "running" was best, so lets try another sample:
sports mode=1 (running): Bangle internal: 124, BT belt: 127

Algorithms like Tapir do count the time between peaks after some filtering.

... I wonder if we should just make a small app that forces one of the sport modes:
https://github.com/espruino/Espruino/blo­b/master/libs/misc/vc31_binary/algo.h#L1­0

I can confirm the indoor bike issue, had the same in the last weeks, it measured the cadence of ~80 BPM.

So I don't know what to call the current HR reliability, its almost non-existent I would imagine.

I would not go that far, when walking or cycling outdoor it is not that off.

The watch is usually shipped with the cover, so unless you removed it or it accidently fall off I would check again.

I thought from reading this thread that most people were finding that the Bangle bpm was lower than manual measurements

Thats because of noise due to motion artifacts, e.g. when walking with 60 BPM with heart rate = 100 BPM the sensor will give you the 60 BPM walking (or a mix of both). This does not apply when sitting still.

Interesting, at one point I ran some motion artifact algorithms from papers like WPFY but they always failed because of the noisy data. Maybe I should try again with the changed LED intensity.

it shows something like 90 bpm where my heart rate is probably more like 50 bpm when I am sitting still.

ok this is unexpected. Just to make sure, you did remove the plastic cover from the sensor? Because from my experience the readings only become bad if movement is involved.

You could add that to mylocation

So what happens if you use locale from main repo?

When you connect with https://www.espruino.com/ide/ do you see any output in the console?

Just checked, there is also a problem, the current setDST() call does not return true on Date.getIsDST() if inside the dst time.

Also I would rename setDST() to setAutoDST() and update widdst accordingly and just add a new setDST() with just ab Integer as param. Or setDST() just checks the type of parameter. If array handle as before, if Integer just add param number of seconds to setTimeZone().

Next control the order of the setDST() calls, last one wins. So if widdst is installed chances are high that the user does want automatic dst setting and not from gadgetbridge.

There is E.setDST(), widdst uses it. I think if gadgetbridge does not set it, it is a bug.

Maybe a widget can indicate the timezone so we do not change the watchface?

(new Date()).getIsDST()

should tell DST on/off

and

(new Date()).getTimezoneOffset()

the zone.

Personally I would prefer having there +1 instead of the abbrevation CET (Paris)

Looks ok to me, at least for german local:

require("locale").time(new Date());
="07:28:24"
require("locale").time(new Date(), 1);
="07:28"

What locale are you using?

ok, I have pushed a fix to PR #3118

@Gordon Can we have the linter check those?