Most recent activity
-
One option for you is Gadgetbridge loads the 'App Loader', which is basically this file: https://github.com/espruino/BangleApps/blob/master/android.html
The URL is configurable in settings, so you could fork the app loader, change it to be exactly how you want it (if that's deleting everything and replacing it with one big text box that would work fine, but you could do much more), and then change the URL in Gadgetbridge to your version hosted on GitHub pages and you're sorted.
-
Apart from the Bangle being more supported and stable...
The main one as far as I'm aware is that Bangle.js has a documented API in the form of
Bangle.*methods running fromjswrap_bangle.c. https://github.com/jeffmer/WatchApps doesn't have that, and implements some of it, in JS, for example: https://github.com/jeffmer/WatchApps/blob/master/apps/main-gw32/main-gw32.js#L4If you're writing all your own apps from scratch you might not care, but it does mean that a great deal of existing Bangle.js apps that depended on that API existing and working in a certain way won't run.
I had suggested in the past that it wouldn't be that hard to build in
jswrap_bangle.cfor a lot of these devices so that they would be a bit more compatible, but I don't think there's been that much interest in doing that really as I think the watch ports were more done for fun than for use as reliable every-day watches. -
It's hard to know what to suggest - I guess the size of the model maybe can be trimmed down by tweaking EdgeImpulse - I think under the hood it's running exactly the same tools as the original Colab file.
Espruino will attempt to be smart with the tensorflow model - if you safe to the
.tfmodelfile then it will do the tensorflow calculations in the idle loop, so there's the max amount of free memory available.I'm afraid what with Espruino and Bangle.js, I don't really have time to keep up to date with all the latest happenings in Tensorflow though. I could attempt to pull in a new Tensorflow implementation at some point though.
-
Just a normal
E.enableWatchdog(2)should be ok I think? That turns on 'auto' mode so Espruino will keep kicking it automatically.You can't turn the watchdog off once it's been turned on - it's a hardware safety thing. To stop it you need to fully reboot the device and then not run
E.enableWatchdog -
when the bangle.js gadgetbridge app is not connected to the watch, the watch shows in the NRC app (it does not show when the watch is connected with the phone via gadgetbridge)
Yes, that's what you'd expect...
is there anything else I can try?
You could try enabling passkey pairing on the Bangle. It may be that the Nike app only wants to connect on a 'secure' connection, and enabling passkey pairing can help to force that.
Otherwise I'm not sure - I doubt you'll have luck on the phone, but you might be able to find some mention online about what devices it's working/not working with
-
I can't help but feel there's something super obvious I'm missing.
What about the code example I posted? Surely that will work fine, without messing with the lock timeout?
it really does seem to be behaving like it's locked but it shouldn't be.
It eats the first press if it was locked or the backlight was off. Your backlight timeout is 10s so it could have been off.
-
Ok, so on the Bangle it goes blue, but then it goes grey again after a few seconds?
That does feel like an issue with bluefy - it might be worth trying another browser, and also just turning bluetooth off and back on on your iOS device just for good measure - it's surprising how many times I've found folks with iPhones/etc get the bluetooth into a state where it won't connect properly, and just toggling it off and on fixes it.
-
Hi - to flash the Puck with your own firmware via SWD, just connect up the GND, SWDIO and SWCK pins to an SWD programmer (https://www.espruino.com/Puck.js#pinout) - you could just solder direct to the pads if you have thin wires.
The nRF52DK needs to be told something is connected with the ground detect. Full schematic of what to connect is here, albeit for bangles: https://www.espruino.com/Bangle.js2+Technical#swd
So if you have the DK working then flashing the code to the Puck should be easy.
Although have you tried connecting with NRF Connect and writing to the
0010203... characteristics (or maybe turning the lights on and off then reading the values?). It feels like that might be a real possibility.Also, it looks like the lights have a "Mesh Proxy Data In" characteristic which is part of "Mesh Proxy Service", and as I understand it, that means you can connect to them via normal Bluetooth and can the access the mesh via that - which means you could use the standard Espruino firmware on Puck.js.
However, I'm struggling to find documentation on that - but if you could figure that out, that would be awesome - and is something that'd be really neat to turn into a library for Puck.js
-
Also, just to check - can you connect from a desktop/laptop computer?
Another thing to try is if the Bangle was paired with iOS you could try unpairing it first, just in case somehow the fact that iOS is using it is causing issues.
Hi,
It would be pretty straightforward to have an option that deleted your calendar when your phone bluetooth connection dropped, which would solve that issue though.
No - it's been discussed, but it's a bit of a minefield. For instance a 6 digit pin code might be considered a lot - you could encode everything you store in flash memory with that, right?
Once the encoded contents were out of the watch's memory, how long do you think it'd take them to brute-force all 1000000 pin codes by running it against an emulated Bangle.js to see if it boots? Once the code was written, it'd be maybe an hour.
I feel like a lot of big companies are going to rely on some obscurity - either a hidden key in the chip for encoding, or making the memory impossible to read out with custom silicon. But that's completely at-odds with making an open, hackable watch where everyone can see all the firmware :(
Sure, we could make it more difficult to get the data, but if there's one thing I've learnt it's that for the people that care about this, they will never be happy if there's any chance of their data being accessed so I'd rather not even try, and just say that any info stored on the watch should be considered potentially at risk.
The HRM can detect if it's against a surface, so that could be useful although not foolproof.
You've got to assume basically anything could be read out by someone sufficiently intelligent.
No, I don't think so. If you have physical access to the device, you can physically unsolder the flash chip and stick it in a programmer.
Yes, it's stored in flash - but as above when bluetooth disconnects messages are removed. however Bangle.js uses a journalling filesystem, so if you were sufficiently clued up you could still dig it out of memory unless
require("Storage").compacthad been called.I should add here that there's nothing built into the Bangle.js low-level firmware that stores messages in flash, it's all JS - in fact as far as I know, when a message is received it's stored in RAM, and if your clock supports fast load the message is kept in RAM (and not written) and the messages app is loaded. If the message is acknowledged at that point, it'll be removed, and at no point will be message have been stored in volatile memory.
If you were willing to potentially lose messages, you could just delete the relevant line that writes the message (https://github.com/espruino/BangleApps/blob/master/apps/messages/lib.js#L140) - or even just paste
require("messages").write = function(){};into theCustom Boot Codeapp, and then no messages would ever get written to volatile memory.