Search results for:

Hi,

I'm afraid it's not something that I is exposed - but presumably you could just attach a signal diode (so only 0.3v drop) between the STM32 TX pin and the serial line, so it's only ever capable of pulling the signal down?

You could take a look at https://www.espruino.com/STM32+Peripherals though as it may be you can set the STM32 up as normal and then just poke a register value in the UART to enable the half duplex mode?

Thanks!

Did I understand correctly that I need to reinstall all apps for them to be re-pretokenized?

If you've installed everything in the last 6 months with the pretokenised option enabled and up to date firmware then there's no need.

But it shouldn't hurt to click 'Reinstall apps' (which should keep existing apps' data but will re-upload everything else). It doesn't hurt to do a backup first just in case though!

I just added a bit of info on what I mentioned above in https://www.espruino.com/Bangle.js+Performance - so if your Bangle is running slow then that might help you to figure out what apps are causing it!

Just a note that you can do:

require("Storage").writeJSON("setting.json", Object.assign(require("Storage").readJSON("setting.json",1),{bootDebug:1}))
load();

In the IDE, and then when you next load an app Bangle.js will print out how long each bit of bootcode/widget/clockinfo took to load, eg:

.boot0 122 ms
android.boot.js 31 ms
bthome.boot.js 28 ms
health.boot.js 10 ms
messagegui.boot.js 1 ms
sched.boot.js 10 ms
welcome.boot.js 2 ms
widlock.wid.js 2 ms
widbat.wid.js 5 ms
widbt.wid.js 3 ms
widid.wid.js 3 ms
widalarm.wid.js 6 ms
widmessages.wid.js 39 ms
recorder.wid.js 30 ms
recorder.clkinfo.js 8 ms
clkinfogpsspeed.clkinfo.js 6 ms
clkinfocal.clkinfo.js 10 ms
bthome.clkinfo.js 11 ms
clkinfosec.clkinfo.js 7 ms
stopw.clkinfo.js 12 ms
smpltmr.clkinfo.js 32 ms
sched.clkinfo.js 38 ms

You can turn it off with:

require("Storage").writeJSON("setting.json", Object.assign(require("Storage").readJSON("setting.json",1),{bootDebug:0}))

So you can then see pretty clearly which things are slowing down the boot time of your Bangle. The app itself isn't included in that list though.

Does squeezing in the top right make it come back to life? That's usually the sign it's a hardware issue.

Why does the banglejs2 bluetooth sometimes just...seem to die?

In the very first KickStarter batch there appeared to be an SMD soldering issue in some watches and it seemed the chip itself lifted slightly off the PCB, which is why we replaced those ones. But since then the rate of failures has been very low.

The aerial is part of the case, and the connection to it is made with a gold-plated contact from the PCB to the case. If your watch was getting wet inside (do you shower with it?) the aerial contact could get corroded over time and then lose contact?

If that's the case, repeated squeezing might make the contact move slightly, wear off the oxide and it might start working semi-permanently again.

The other possibility is the battery expands slightly and pushes the PCB away, breaking the contact, but I haven't yet seen any watch with any sign of that happening.

Ok, firmware is just fixed - @Pologram you could take those fixes out of your app now hopefully!

Well, I take it back about the touch thing - it just happened to me in a settings menu and I'm not 100% sure why, and wasn't able to reproduce it.

I just tried putting another touch handler after and voila!

var inMenu = false;
E.showMessage("Tap");
Bangle.on('touch', function (zone, e) {
  if (inMenu) return;
  inMenu = true;
  E.showMenu({
    A : ()=>print("A"),
    B : ()=>print("B"),
    C : ()=>print("C"),
    D : ()=>print("D"),
    E : ()=>print("E"),
    F : ()=>print("F"),
  });
});
Bangle.on('touch', function() {
});

It seems 100% reproducible. So I think what was happening before was we completely re-wrote the list of event handlers when something was added/removed (and it was the list of handlers that got queued for execution). Now, we just modify that list so if you're iterating and you're not at the last entry when it executes it'll carry on.

So this needs fixing internally. I guess I'll go back to the old behaviour of making a whole new list of events for every modification - it's not so nice/efficient but I think it's more what people expect.

Recent tweaks I just committed to BangleApps (dev app loader):

• Anton clock 160ms
  
• load("messagegui.app.js") 210ms with read message
  
• load("messagegui.app.js") 260ms with unread message
  
  

So we're now over 80ms faster loading the bare clock, 60ms loading messages!

I've also made some big improvements to the widget/clockinfo loading speed and fixed a few that were taking a long time to load (android/widmessages/sched) so especially if you have a lot of widgets or clockinfos you should see some noticeable improvements!

Hi! I've been putting a bunch of work into optimisations on Espruino/Bangle.js lately, and I've done a bunch of stuff with the latest builds.

You'll find that writes to 1/2/4 bit offscreen buffers are a lot faster now, built-in JS functions now execute a lot faster (we're able to skip a 'parsing' step, and we also store them pretokenised), and for Bangle.js 2 specifically I've now built in the Layout library (you'll have to reinstall any apps that use Layout for the app loader to realise your Bangle has layout and upload your apps without their own version).

Not that the change is massive, but with a totally 'factory reset' watch with android installed the load times are as follows:

Bangle.js 2v24

• Anton clock 246ms
  
• load("messagegui.app.js") 329ms with read message
  
• load("messagegui.app.js") 331ms with unread message
  
  

2v24.128

• Anton clock 241ms
  
• load("messagegui.app.js") 271ms with read message
  
• load("messagegui.app.js") 308ms with unread message
  
  

So we manage to be 10% faster when viewing messages, and any app that uses setUI/showMenu/Layout/etc should be a lot snappier.

That should save both on CPU cycles and flash writes.

Not if you're constantly writing that staging file?

But if you're not leaving the app then just keeping the last value in a variable and being sure to write it in an E.on("kill",...) handler would do it?

Thanks for the report @Pologram, and for tracking this down @Ganblejs! That's a bit of a pain. The change in event handling was to fix some errors other apps/people were having (which made things behave differently depending on whether there was a pre-existing event handler or not).

I was trying to make a very basic proof of concept for this, and:

var inMenu = false;
Bangle.on('touch', function (zone, e) {
  if (inMenu) return;
  inMenu = true;
  E.showMenu({
    A : ()=>print("A"),
    B : ()=>print("B"),
    C : ()=>print("C"),
    D : ()=>print("D"),
    E : ()=>print("E"),
    F : ()=>print("F"),
  });
});

or just

Bangle.on('touch', function (zone, e) {
  E.showMenu({
    A : ()=>print("A"),
    B : ()=>print("B"),
    C : ()=>print("C"),
    D : ()=>print("D"),
    E : ()=>print("E"),
    F : ()=>print("F"),
  });
});

don't seem to trigger it for me on latest firmwares. I even tried with an extra Bangle.on('touch', ()=>{}) just in case. I can't even seem to get your Elapsed Time app to fail the way you show it? Can anyone reproduce on 2v24.128 or later?

As an easy fix I think just changing showMainMenu(); to setTimeout(showMainMenu,0); should fix it, but it seems odd it can't be reproduced now?

Date

Interesting! (new Date()) + (new Date()) produces Thu Oct 24 2024 13:09:57 GMT+00001729775397865.07299804687

So on one call it's producing a string, and the other a number. The actual change at fault was a seemingly unrelated https://github.com/espruino/Espruino/commit/f09330e7baf42cb8f7fda2c8fec5fd9be11991df but I've managed to get a fix in now!

You can't really edit a value in the file without re-saving it. Flash memory starts at 1 and can only be made zero, so all you could do with just Storage is to zero out an area, which would probably make life hard later on.

I think your best bet is to use StorageFile, but if you want to delete a line you just iterate, writing just the stuff you want into a new file:

// delete last line
var src = require("Storage").open(STORAGE_FILE_A, "r");
var dst = require("Storage").open(STORAGE_FILE_B, "w");
var line = src.readLine();
var newLine = src.readLine();
while (line && newLine) { 
  dst.write(line+"\n");
  line = newLine;
  newLine = src.readLine();
}

Since you're loading line by line memory won't be an issue, and for 50k max it shouldn't take too long - it just means you have to have your file name changing (since you can't rename).

Or depending how you're working with this, you can just add a line saying DELETE LAST LINE
and then when you finally read the log out you use that to ignore the previous line if you see it?

Ok, that's a shame. The whole compaction issue is surprising - I spent several hours yesterday trying to even reliably reproduce it but without success.

It did make me wonder whether it was related to some of the optimisations we put in for external flash (like the filename table). So I've made another build (attached below) without these - I'd be really interested to see whether that works any better.

You've still got 360k flash, so I'd hope that you could install a decent amount of stuff (especially with pretokenise enabled) - just not things like the extra fonts that do take up a chunk of space

Glad you got it sorted! Very surprising about the app loader connection issues - they both use the same code and API to connect.

However maybe some app on the Bangle is outputting something when the connection first starts, and that's throwing off the App Loader (which tries to find out what apps are installed when it connects).

Maybe you could open DevTools for the App Loader, type Puck.debug=3 in the console, then try and connect and paste up what's printed to the console?

Oh, damn. You're right. Sorry - don't try the iflash one I attached, I'll try and delete it.

Try the noflash build I've attached below.

And interesting - ok, I didn't realise @devsnd had issues. However I did just install the attached noflash build, did a factory reset, updated apps, then compacted, and it still seems to work fine so I'm hopeful.

It's entirely likely that what happened was @devsnd restored a backup that was too big and then even though compaction kicked in there wasn't enough space for all the apps, so not all the files got copied in.

If that happened you could always delete big files/apps from the backup zip until it got small enough and then try again.

there used to be a problem with the compacting storage feature

Wasn't that the firmware that used both internal and external flash? I thought the one that just used internal flash was fine? After all, we use that in every other non-Bangle.js Espruino board we sell and it seems to work fine?

All the information you need for connection, including pictures, is on https://www.espruino.com/arduino-esp8266

Can I connect it directly/pins to pixl.js without soldering? How

From https://www.espruino.com/arduino-esp8266#using-as-is

• Ensure SW1 and SW2 are OFF
  
• Connect a jumper lead from the TXD pin on Debug Port to D0 on the Arduino header
  
• Connect a jumper lead from the RXD pin on Debug Port to D1 on the Arduino header
  
  

I would like to power both boards using CR2032 battery. How?

It's not possible I'm afraid. A CR2032 doesn't provide enough voltage or power for the ESP8266.

You'd need to use at minimum a Lithium Ion battery, but maybe the easiest is just to use a USB power bank?

Are you able to connect to it when it's in DFU mode? The IDE/App Loader won't connect in that case, you'll have to use the DFU app: https://www.espruino.com/Firmware+Update#nrf52

If you were on an old (pre-2v22) firmware, there were some changes in 2v22 that made Bluetooth more reliable on some devices (if the crystal oscillator wasn't running as accurately as we'd assumed).

I guess it's possible that you have a bluetooth hardware problem on your Bangle, although the fact that it seems to at least start connecting makes me feel like it's less likely. You could try pinching the Bangle in the top right corner and see if that improves the connection (there's a sprung connection to the aerial inside the watch there, and I've seen a few devices where it can lose contact with the aerial)

Opening the Chrome devtools in the web browser (F12 or Ctrl+Shift+C) and looking at the 'Console' for any messages shown may help too - if you could copy/paste them here we might be able to help figure out what's gone wrong.

Another thing to try is to restart the watch in recovery mode: https://www.espruino.com/Bangle.js2#recovery-menu

While still in recovery mode try and connect with the App Loader, and that should work regardless of what's installed on the watch

Great - thanks for the update, and glad it's made it better!

What you're missing here is that you're doing JSON.parse(data) and not JSON.parse(data.resp)

This works great though:

Bangle.http("https://worldtimeapi.org/api/ip").then(data => {
  let time = JSON.parse(data.resp).datetime.split("T")[1].split(".")[0];
  g.clear();
  g.drawString("Time: " + time, 120, 120);
}).catch(err => {
  g.clear();
  g.drawString("Error: " + err, 120, 120);
});

An in the other 7 posts you made about this - it really helps to use the remote debugging for this so you can see what's going on: https://www.espruino.com/Gadgetbridge#remote-debugging

Bangle.http only works when running under Gadgetbridge

If you want to develop, it's a lot easier if you use the Web IDE remote connection to allow you to communicate with your Bangle while it's connected to Gadgetbridge: https://www.espruino.com/Gadgetbridge#remote-debugging

Maybe you can try using the Remote debugging to allow your Bangle to stay connected to Gadgetbridge while you run code: https://www.espruino.com/Gadgetbridge#remote-debugging

Then you can see if there are any error messages when you run the command. There is an example at https://www.espruino.com/Gadgetbridge#http-requests

Bangle.http("https://pur3.co.uk/hello.txt").then(data=>{
  console.log("Got ",data);
});

Note that you have to use HTTPS, not just HTTP because of Android.

If you want to find other apps, literally just go to the GitHub Bangle.js repo and search for Bangle.http: https://github.com/search?q=repo%3Aespruino%2FBangleApps%20Bangle.http&type=code

Yes, let's try and get it in. It'd be nice to make it seem a bit more responsive!

Yes, please just forget about the SWD - it won't be useful for what you want to do at all.

It'd be a good idea to try connecting from some other device and see if that can keep a connection - a phone maybe?

Sorry - yes, Wake on button is best - I wrote the wrong thing.

Can a permanent notification triggen the high power mode without seeing the notifacion in the bangle?

No - it's just when data is sent to/from the Bangle.

How do I dump the logs? Where to find them?

https://gadgetbridge.org/internals/topics/logs/

but is very strange that after a factory reset I get like a week of low power usage.

What if you just factory reset and leave it not connected to a phone? What's the power usage then?