Search results for:

I think battery falling like that can only be either a horribly wrong value for the battery calibration (and relatively low charge being shown as full) or GPS being active. There is just no hardware taking that much power besides full power backlight, but I suspect you would have seen that at some point. Do you have agpsdata configured for autoupdating? Maybe there is some bug not turning GPS off after the update.

There are two app loaders you can use (additional to several ways of running your own). One at https://banglejs.com/apps/. That one needs manual intervention by @Gordon to be updated and should contain more stable (older) apps. The other one is https://espruino.github.io/BangleApps/ and is automatically up to date with all accepted pull requests of the Github BangleApps development project. The pull request you mention (https://github.com/espruino/BangleApps/pull/2778 ) has been merged two days ago and is available since then on the development app loader.

I have used the OsmAnd Pebble Integration by just filtering normal notifications in GadgetBridge. Watch buzzes with a new message whenever Osmand would have done some voice output. That worked well enough for walking around in areas with street name signs and when I had at least an rough idea of my route it even worked fine for biking. Normal OsmAnd notifications on the Bangle are completely useless as they are updated much too often (a notification every few meters).

Yes, default mode of BTHRM replaces internal HRM sensor and the events are usable in all apps without modifications.

I think I found the issue:
The location manager was not cleaned up when the Bangle was disconnected by connection loss. This pull request should fix that.
https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/3132

Either you managed to scratch the glass or the protector is still on. If I remember correctly it had no tab or something like that to pull it off. On my first Bangle I thought I had received a scratched one and only a few days later I discovered it to be a protector. It was a tiny bit "frosted". Without the protector you should have a mirror finish just like the display glass has.

Edit: @adjtm hehe, you ninjaed my post very closely :D

I have tested a bit again with current stable firmware and GB (2v17 and 0.74) and the changes for android from https://github.com/espruino/BangleApps/pull/2534 since without them I can not get GBGPS to activate on GadgetBridge:

• Connect watch to GB and start GPS Info to get GPS updates -> works fine
  
  • Battery level available in GB
    
  • Connected shown in GB
    
  • Sending notification works
    
  • characteristic write messages in logcat
    
• Put watch into metal box
  
  • Battery level vanished from GB
    
  • Few ms of disconnected (grey) state, then connected state shown again
    
  • After "reconnect" still no battery level
    
  • GB still trying to send GPS, but not characteristic write messages
    
  • Debug notification does not work, just added to queue like GPS messages
    
• Take watch out of box
  
  • nothing changes, stays fake connected without battery level
    
• Reload watch (2 sec button press)
  
  • nothing changes again
    
• Disconnect and reconnect watch with GB menu
  
  • Everything returns to normal
    
    

It seems there is a problem in the GadgetBridge GPS handling code, not the GPS code on the watch. It is in the metal box when the problem starts, so no influence on GB at that point in time. Without triggering GBGPS on the watch the "fake" reconnect does not happen and the actual reconnect after the box is openend restores full functionality.
Somehow some state in GB seems to be not cleared as it should be when the GPS service is active.

Slightly off-topic, so I will keep it short:

By making apps fast load that were never designed for it

Apps do not need to be designed for being loaded without a reset, they need to be able to clean up if another app is loaded without reset. Fastload Utils just enables loading every app after one that is able to clean up. There is no (intended) way to fastload with the current version if the currently running app can not clean up. There should not be any stuff accumulating except for bugs in apps regarding clean up. Real reset is still done for leaving nearly every app but clocks and launchers.

Edit: Nevertheless removing it as a possible source for errors is what I would do as well.

I've had similar problems (empty in a day) and have seen something in the trace logs. Do you have GPS via Gadgetbridge activated on your watch?
agpsdata turns on GPS for updates and I could not find it being turned off again in my log. I suspect this behaviour happens in combination with the workaround for Serial1-communication from the GadgetBridge GPS-handling code. So in the end the internal GPS gets switched on and only switched off if somehow a reload is triggered. This would explain why this happens only sometimes and not all the time. It would empty the Bangle if agpsdata pulls new data AND then no reload happens for long enough to eat a sizeable chunk of the battery.

Your problem with the buzzing code is a bit strange, but even if the CPU ran full tilt for the 6h it would consume under 30mAh or around 15% of the battery charge. Actual buzzing would probably need more power, but you said it wasn't actually buzzing a lot.

https://espruino.github.io/BangleApps/?id=gpstrek tries to do this using the barometer, but i needs some work on filtering. Currently the values for up and down are to high.

Yes, it only calibrates after 3 hours if it has seen a charging start and a charging stop event. Deliberately so to prevent setting the calibration too often. Maybe just starting a 3 hour timeout on charging start (event or even boot) would be better?
As for it being unlikely, I have seen it exactly once where I am sure that this has happened. The other times have been values much closer to correct ones. Those could have been caused by charging in cold environment or differing charger voltages or something like that.

Maybe unrelated, but since I updated my daily-driver bangle from 2v16 to 2v17.54 (and Gadgetbridge to another nightly, but I think without relevant changes for Bangle) this seems to be happening a lot less. I am down from practically every second day to maybe once a week.

I am using powermanagers auto calibration for the battery level. Seems to work well for the most part, but sometimes it sets offsets a little high (e.g. seemingly to early). Yesterday I had started the day on a very low charge. Bangle ran empty over night and I could only charge for about 20 minutes before leaving the house. So pretty much started the day on a close to empty battery and it was shown as such (low dual digits battery, definitely under 20%). Without having a charger with me that somehow changed to 89% somewhere around noon. It was a wrong offset for the voltage/percentage, probably set by powermanager, after resetting that offset it went back to showing 12%.

So the question is, could somehow leaking currents or something like that have triggered the charging event without having a charger present? Has anybody seen something like this?

I have tried to get incorrect values in the charging event by wiggling the charger around, but as far as I can see that works just perfectly. There do not seems to be events lost or doubled, every event changes state from the previous event. The state changes in powermanager seems to match up fine.

powermanager currently ignores the charging state on boot but in my testing that does make no difference in the behaviour. Maybe setting a timeout for recalibrating instead of using the charging=false-event would work better, but I don't know how to check it actually works better than before. Maybe someone else has an idea for testing?

After 2 years, @NewAtEspruino might not be new at espruino anymore :) As for drawing rings, there is now a graphics_utils library for that extracted from https://espruino.github.io/BangleApps/?q=choozi.

Maybe a utility button in the apploader "More..."-tab for deleting the setting.json file would be useful for these cases. At least that would get the watch usable again without fiddling with the IDE. An alternative could be an interface page for the settings app that allows to change or reset some/all settings from the apploader.

That should be relatively easy. Battery could be a problem, but you can use https://espruino.github.io/BangleApps/?id=hrmaccevents to test this. It can stream accelerometer and pulse data as fast as possible. If you can do that for a day there should not be major problems for your usecase.

Without comparing to a BTHRM and without testing with much movement, the values given by the HRM seem to be a lot closer to reality. Having a resting pulse with the old algo of under 50 would be nice to have, but for me it is not exactly realistic :) So at least in the constraints of it being an optical sensor it now works much better. I had the chance to play around with a Garmin Fenix 7X which should have one of the best optical sensor available. That worked impressively well, but even that thing wasn't able to keep up with steep rises and falls in pulse rate during movement like an EEG based sensor does.

I had problems with a dodgy WAHOO TICKR X2 which disconnected at least once a minute. That caused the first changes to get better connection stability/automatic reconnects and then feature creep happened :) The sensor has since been replaced by WAHOO and the new one works a lot better but still disconnects from time to time.

You should get BT HRM only when selecting the custom mode and setting that to:

Replace HRM ✔️ (replacing the internal sensors values)
Start w. HRM ✔️ (react to the same power calls as the internal sensor)
HRM Fallback ☐ (do not try to activate the internal sensor if BT gets lost)

Moving the code that is able to detect and pair with sensors into the settings could probably reduce the RAM use by quite a bit with the cost of always having to pair a sensor before use. That is probably not really a problem, most devices I know actually need some configuration before using a HRM instead of using whatever is available.

Another possibility would be a low memory mode hard coding a lot more of the connection steps without the custom logic for handling many of the errors and parsing of additional data like battery and HRV data. Even restoring the initial implementation as base app and making the current one into a BT HRM+ version like many clocks are currently having would probably help a lot on B1.

The BTHRM widgets should be blue/dark blue for the "BT HR" recorder, green/dark green for the "HR int" internal recorder and no other colors should be possible. The normal "HRM" recorder (icon should be red) is enough if you set BTHRM to replace the HRM event.

The reason for it being draft is the problems caused by sending a lot of data. There is currently no definitive cause found for this. I think it is not caused by the GPS code, but I can not prove that yet.
There are https://forum.espruino.com/conversations/384228/ and https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/2996 for more info on possible causes.

Bangle.setGPSPower() is modified to handle the activation of the GPS sending by GadgetBridge. There is an open pull request that simplifies the code for using GPS by GadgetBridge and fixes some issues. The state in the pull request uses GPS events from the phone if they keep arriving and falls back to internal GPS if the last received GB-GPS event is too old.
From app perspective nothing changes in the use of GPS. setGPSPower for "requesting" GPS use and on('GPS',func) for getting the events. The combination Bangle.js GadgetBridge nightly and the PR works fine for me.
There are problems sending lots of messages to the Bangle, but I currently think that this is independent from GPS and a more generic problem with sending data via BT.

Maybe even a hot water bottle could work. I have done one mine with a hot air gun and without setting it to 140°C I could not get it to budge. That was hot enough to let the display go blank. It recovered completely but that did not feel save.

I think the Renaissanc­e font looks very nice and well readable. Having a way to get a font fitting into a given height would be great for layouts for both B1/B2 since something like setFont(g.getHeight()/5) could just work. Something like that would even be future proof if an even better matching font is added later (e.g. 30px wanted, 24 available, 28 added later). That would be great for replacing fonts system wide or making them a property of the theme. setFont with number as parameter could be used to find a matching font while string as parameter denotes a specific font directly as it does now.

As for the different width glyphs I think that would be very beneficial for rendering more text. The problem of watchfaces or similar stuff could be solved by having setFontMono(bool) which would cause the font rendering to use the max width of all glyphs and and center the glyphs on render. Another way would be just working around that problem by rendering single characters in the app. Probably good enough for the time on watch faces.

It is probably a different issue, the characteristics are not null. In the broken state it hangs in BtLEQueue in line 177 mWaitForActionResultLatch.await(); so nothing further is transmitted. Executing mWaitForActionResultLatch.countDown() in the frame does seem to revive the processing of the transaction queue. It sends out everything it got.
If I set a breakpoint in the queue, force the disconnect and then let the code run after reconnecting, it works just fine. So essentially something must be wrong with the interleaving of queue processing thread and cleanup/reconnect. Deactivating auto-reconnect and reconnecting manually does also hide this problem so it isn't the manual disconnect that "fixes" it.

That really should not happen. Did you use the detail logging? That can write a lot of data relatively fast into a storage file. Normal logging writes two files every 5 minutes and on reloads. Do you know how full the storage was?