Search results for:

It's worth checking what it says at https://banglejs.com/apps/?id=weather&re­adme

Basically Gadgetbridge on Android doesn't provide weather out of the box - you have to add something to provide the weather to it. Once that's done it should work for you though

Yes, that's a tricky one.

Generally clock faces load big fonts which aren't used by anything else, so deleting them isn't a big deal.

However, when something uses a module, generally we don't try and remove the module from memory - and FontVGA8 is a module (require("FontVGA8").add(Graphics);).

I think in this case I'd just not delete the font from memory - in the scheme of things it's not going to be using huge amounts of RAM. As mentioned it might be an issue on Bangle.js 1 where memory is tight, but realistically you're probably not developing your app to run on that anyway.

You can increase the HRM interval past the default (which I think is nearer 12Hz on Bangle.js 2) with Bangle.setOptions({hrmPollInterval:time_­in_milliseconds}); (which you need to do before you turn the HRM on)

But the existing HRM algorithm won't work at that speed so you'll have to work yourself from the raw data - and you'll have to make sure you can handle the data coming in fast enough, as well as possibly configuring the HRM such that it can go fast enough.

There's an example of sampling at 200Hz in the Flash Counter app: https://banglejs.com/apps/?id=flashcount­

Code that does it at:

https://github.com/espruino/BangleApps/b­lob/d6d03e1aac0a9de5a183cf74527e0ee04d53­0bc1/apps/flashcount/app.js#L4

There's a library at https://github.com/espruino/BangleApps/b­lob/master/modules/buzz.js (and associated menu item at https://github.com/espruino/BangleApps/b­lob/master/modules/buzz_menu.js) which allows you to choose from a set of different buzz patterns.

I can understand maybe you want something fancy when driving an iPhone style haptic vibrator that's more like a voice coil than a motor, but when driving a motor, I think you can do whatever you want to do just by pulsing the GPIO pin in the right way, which can be done in software like above?

The Wifi module is built into the firmware because it's low level - it's documented at https://www.espruino.com/Reference#Wifi

I already sent him one - but I imagine there might be someone out there who wants one!

Hi - there are no immediate plans for a Bangle.js 3, in fact I'm due a delivery of another large batch of Bangle.js 2 in a few weeks so there definitely won't be anything in 2024.

While I'm interested in getting a wishlist for a Bangle.js 3 to see what people like and don't like, and doing one at some point, I want to release some other Espruino-based devices before I even consider a v3 Bangle.

Right now Bangle.js 2 does a lot of things right, and while it can doubtless be improved the cost of developing a brand new device is huge, so I can't afford to just keep pushing new ones out every 2 years unless it's going to be a vast improvement :)

That's great! Thank you for sharing!

This is exactly the kind of thing I'd hoped Bangle.js would get used for - implementing some feature that you wanted but couldn't find on a 'normal' watch, then being able to share it :)

Well, as I say the Uncaught undefined itself is ok. It should update when the settings change.

... but only once. I was finding that on the latest builds with factory firmware, it was printing Uncaught undefined every time you changed app!

I think I was wrong to write this off - while the Uncaught undefined itself is ok, I just flashed a version onto a device and did a Factory Reset, and I found it happened when loading every new app. Was this what you were seeing?

I believe the issue has been that the pretokeniser was pretokenising empty strings when it shouldn't have, and this caused an error - which wasn't reported properly because it was inside bootupdate.js. Once you update bootupdate.js manually it's fixed.

It seems the alarm app may have been broken by default anyway. I've just fixed the ide and the app loader, as well as the factory update image in cutting edge builds. Luckily I'm not sure how but it seems that 2v21 (including the factory image) escaped ok

Sorry about that - but yes, that'd be covered under warranty. I'll send you an email

Ok, I think that's fixed now - realistically the 6x15 font isn't that great anyway. The plan eventually is to try and replace them with the fonts from https://github.com/pebble-dev/renaissanc­e which at least all share the same style

Ok, I've just adjusted the font, so if you install the cutting edge Bangle.js build it should be fixed.

Characters like Ÿ aren't in ISO8859-1 (that's char code 376, not 0..255) so you'll have to install the Font app I linked if you want those

Sorry to hear that - it's probably better to respond on the post linked above that you just posted on though: https://forum.espruino.com/conversations­/394518/#17309516

it's 5 reports over the course of about 1.5 years and some thousands of bangles

Yes, it's pretty much 10,000 Bangle.js 2 sold now, and 5 with this problem (and I think one or two more via email). For something that spends every day on your wrist being knocked around it's not that high a failure rate - but as you say it's worth looking at strengthening for a v3.

It's worth noting that most people report their issues publicly on this forum (often in multiple posts), and I make a point of not deleting posts because I think it's important to be honest with everyone.

Unfortunately that means that people come here and see posts on a broken bit of watch body, or bluetooth, or the button, and get the idea that they're unreliable, despite there being a pretty low failure rate. I honestly believe these watches are no less reliable than the competition though, it's just that we don't hide any of the complaints.

That's odd - while we have different fonts for different sizes generally the characters should all be the ISO8859 codepage so should display the same, but I just tested with:

g.clear(1).getFonts().forEach((f,i) => {
  g.setFont(f).drawString(f+": àéèêùç ",0,i*20);
});

and I see the attached, so it looks like the 6x15 font has an issue with à - but is there other corruption you see?

If all software is up to date, you can install this font: https://banglejs.com/apps/?id=fontext

and messages will then use only that font which should render anything. You'll need to update your Bangle.js build to a cutting edge release to allow it to render the font in different sizes though

I don't think the algorithm has changed on the device at all.

It's worth noting that since the sensor is inside the watch body, potentially other sources of heat within the watch (the CPU, backlight, battery charging) could affect readings...

I'm not a fan I'm afraid.

It feels like CMake is just another dependency and thing you have to install to get the build going? And surely you can still use Makefile projects within CMake?

There's also a lot more work involved in running Espruino under Zephyr than changing the Make system :)

It should be live on the Play Store testing track now anyway, which you can sign up to with https://play.google.com/apps/testing/com­.espruino.gadgetbridge.banglejs

I've tried to submit it to everyone but it's having to go for review again

Do you have the bit that came off? Because it's ABS plastic it should stick back on with acetone pretty easily.

One of those '3D pens' might work as well to melt plastic back on.

It's tricky - in Pinetime I think they have more space to mount the strap inboard because they don't have a GPS aerial to worry about. If we extended the Bangle.js 2 case downwards I bet most people would complain it was too big.

It does seem you've been unlucky though - there aren't very many of these watches it's happened to given how many we've shipped out.

Great! Thanks for your work on this! I've finally managed to push an update to the Play Store, but the build was from before this was merged in.

... but I'll try and do another update in a week or so

Ok, I've just added some code, so tomorrow the Gadgetbridge nightlies should have the fix in.

I believe the HTML and :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~ should now be stripped out

Yes, that sounds like a good idea. It's something that would need to be done inside Gadgetbridge though.

I'll take a look and see how easy it is to get rid of stuff like that - however if Google change the format of invites then we'll probably have to change the regex again to try and strip them out.

Wow, very nice! that could really help (assuming you have the build yourself so you have the elf)

And about that small capacitor, by small you mean something around 1uF? Or 1nF?

I'd say 0.1uF is a pretty safe bet. 1nF might be a bit small, and I'm sure 1uF would be fine but it's actually quite large (it'd take a while to charge up after changing the GPIO).