Search results for:

Does anyone actually care about the barometer?

Personally, I'm not sure I see the use-case for having a pressure sensor on the watch, it's certainly not worth sacrificing waterproofing for. However, I think people could see real value in a microphone / speaker, and that would be something I would see as a good trade-off with regards to waterproofing.

My wishlist would be:

• Speaker, I think there are some really good use-cases for having a speaker for audio feedback e.g. listening to instructions, music etc.
  
• Microphone, the ability to answer a call or even just send voice commands to your phone via the Bangle would be such a cool feature.
  
• Stronger vibration motor, I think it's just a little too subtle. If I am for example working in a physical job and I have an alert setup on my watch, I'm not sure how likely I am to feel it.
  
• Richer screen, the ability to render higher quality images would be great e.g. being able to set a background photograph or just view images from apps like WhatsApp.
  
  

Disclaimer - I was not one of those people who were complaining to you about there not being a microphone or speaker. I think you've done an amazing job with these, and not just from a hardware perspective but with the whole Bangle ecosystem (emulator, app loader, docs etc.). So only support & praise from me, keep up the great work!

@Serj thanks for your detailed reply, it's definitely good to hear first-hand experience from someone who's worn it day to day.

I noticed that many people have problems with the button and contact corrosion on the Bangle 2. Probably, relative to all users, these cases are not so many, but the first version of the Bangle did not have such problems, right?

Yeah that's a well documented issue with the B2. It wasn't an issue on the B1 because the SWD pins weren't exposed, you had to open it up to reprogram it.

It does seem like there is an argument to suggest that the B1 was sturdier, even if just from a design perspective than the actual hardware itself. @Gordon what was the reason for the B1 being discontinued? It does seem like there could be good use-cases for it with regards to using the watch in a 'tougher' environments.

Thanks Gordon, the use-case I'm thinking about is the watch not being handled with care (e.g. being chucked around). So was just wondering how much of a beating the screen / carcass could take before it would become compromised.

I wasn't aware of the cover so that would definitely help with regards to shock absorption! :)

Just from a visual perspective, the Bangle 1 encasing looked a bit more ruggedised than the Bangle 2, other than the IP rating being dropped from 68 > 67, is there any other factors that would suggest that the Bangle 2 wouldn't necessarily withstand the same physical wear and tear the Bangle 1 would?

For example, how tough are parts like the screen / casing / straps? And how do they compare to the Bangle 1, and to other industry standard devices like the Apple watch / Fitbit etc?

Perfect :) and yeah that is a challenge too. My plan for that was to return the custom UUID data in the SCAN_RESPONSE packet - I found this article, the array format for setScanResponse is pretty horrible, I noticed you mentioned you'd log an issue for adding a nicer API, any updates on this?

In the meantime, any tools or references I can look at to help me build a scan response payload? e.g. if I wanted to advertise a custom service UUID with some data

I see in the docs it mentions there is currently no support for custom UUIDs in setAdvertising, any idea if or when you see this coming?

Bit of a limitation for me at the moment as I would like to advertising some custom data without having to connect.

@Gordon worked a treat, thanks! I'm intrigued, how did you apply the fix without me having to update Espruino 🤔 When the tag is flashed are the libs downloaded in the fly?

@Gordon brilliant :) I'll give it a try tonight and let you know how I get on. Thanks

Hi Gordon,

Thanks for the reply (and apologies for not putting this in the right place, wasn't sure where the best place to put it was).

Well I did find this thread and as a result I actually already tried the approach you've suggested but to no avail. The only difference in the other thread is they've got pretty much all the code in onInit as opposed to including Ruuvitag outside i.e.

function onInit() {
      var Ruuvitag = require('ruuvitag');
      Ruuvitag.setEnvOn(true);
      setInterval(function() {
        console.log(Ruuvitag.getEnvData());
      }, 5000);
}

I will try with exactly the sample you've suggested if you think it would make the difference, however, failing that do you have any other ideas? From the looks of the other thread it seems like it's a limitation from the Ruuvi side?

Got some odd behaviour trying to advertise some environmental data from a Ruuvi tag using Espruino. In a nut shell, flashing via web IDE and outputting env data works perfectly fine however as soon as I persist the firmware on the board the readings seem to skew and not change.

Can be reproduced with very minimum code e.g.

var Ruuvitag = require('ruuvitag');
Ruuvitag.setEnvOn(true);
setInterval(function() {
  console.log(Ruuvitag.getEnvData());
}, 5000);

Any ideas what's going on?