Bangle.js 2 incoming?

how will adapting apps work then? Is the watch using the same app loader?

Yes, I'm still sorting out the specifics (I'm open to ideas for how to do this in a nice way!). But we're using the same app loader, and right now apps that I know either work or don't work are tagged b2 or bno2 so for instance https://banglejs.com/apps/#b2 will show you apps that work on Bangle.js 2.

I'm considering adding a prompt at boot (like https://espruino.com/apps), but when you first connect the app loader will adjust the filter options automatically so you only see apps that will definitely work.

I'm also working on some libraries which should make it easier to target both devices with one app, and I'll be going through the more popular existing apps converting them to use that as well.

Published my preview video here:
https://www.youtube.com/watch?v=xtr_cA-t­6e0

It is on Spanish (because I am spaniard) so if you know anyone that speaks spanish send it to him 😄

How much do you expect the price to drop for the proper release?

The current Bangle.js is £58.30 ex VAT for one, and I'm expecting the new Bangle to be a tad more as the underlying hardware is costing me more. It should still end up under £70 ex VAT though.

Super excited about it!

Definitively I will buy it.
But i would like to have best practices or templates to make an app cross compatible for BJS1 and 2 .
I assume the cost of lossing part of the screen due different resolutions

But i would like to have best practices or templates to make an app cross compatible for BJS1 and 2

Yes, absolutely. I'm working on that! Right now the idea is to try and use the layout library as much as possible - more info on that at http://forum.espruino.com/conversations/­367445/#comment16163673

What about the heart rate sensor?
Though I assume that it would be several times better than Bangle.js
Can it obtain relatively accurate data to be used during sports?

And if the wrist sensor hw is not good enough, would it be feasible to receive info from a BLE chest band?

it is not that much or only about the data you get but about the algorithm you use to analyze that data, check the never ending step counting thread which has some promising results. so maybe the heart rate will be similar success in future

Heart rate is actually very similar problem, you search for periodic beats (instead of steps in step counting) and try to filter out the noise. In the heart rate case the noise is also movement of the watch on your wrist/skin when checking for pulses.

I think some proprietary libraries from HR sensor manufacturers try to correlate HR data with data from accelerometer to compensate the movement or at least ignore data temporarily when the movement is likely to affect the data a lot.

Still the new sensor has something to tune and configure via i2c unlike the old that just provided analog value without any way to configure it.

would it be feasible to receive info from a BLE chest band?

definitely yes

As @fanoush says... I think initially the new HRM sensor probably isn't going to be miles better than the old one, but the good news is it's entirely digital and so it can be improved in software as time goes on.

We don't have the source files from the sensor manufacturer, and it seems they may even distribute their algorithm as a binary blob but as @fanoush says they do use accelerometer data as well as heart rate sensor data.

Right now we're using a reverse-engineered version of their auto-tuning algorithm to get the heart rate data, but once the data is in we're using our own algorithm. It may be at some point I just give in and include a reverse-engineered (or binary blob) algorithm but I feel like we should be able to do pretty well ourselves.