Search results for:

Just realised what this is - in whatever build you're doing you're compiling with the peer manager but with no central connections enabled. I'll try and sort the build out properly soon but the easy method would be to copy the lines from NRF52840DK that ensure you have central connections enabled

Ok, what you're after looks like it's similar to some other clock apps - for example https://banglejs.com/apps/?id=worldclock­ (there are some others, like https://banglejs.com/apps/?q=zone)

Those use a 'customiser' page on the app loader to let you configure them from the App Loader (https://www.espruino.com/Bangle.js+Custo­m)

You can check the code out at https://github.com/espruino/BangleApps/t­ree/master/apps/worldclock but basically:

• An HTML file that runs in the app loader lets you configure timezones: https://github.com/espruino/BangleApps/b­lob/master/apps/worldclock/custom.html
  
• They are written to a file on the watch into called worldclock.settings.json
  
• The clock loads the data using data = require("Storage").readJSON("worldclock.­settings.json")
  
  

is Bangle.js aware of timezones and daylight savings?

It's not enabled by default, but if you install https://banglejs.com/apps/?id=widdst then yes it is

Ok, thanks for trying to narrow this down. I think really I'd need to see an example of this being used, but nothing looks that bad space-wise, unless what you're pushing into it ends up including a bunch of extra info (maybe via the scope it was defined in).

Honestly though, this is not the way to write code for Espruino. It's going to be so slow! By using Queue you're basically just reimplementing what Array does but adding a whole extra layer of abstraction which is eating memory and CPU time.

I mean, you look at isEmpty, it's calling this.any() which calls _this.length which is a getter which calls this.internalArray.length. It's just a nightmare - it's like someone wrote the code specifically to waste CPU cycles - even on Node.js it's going to suck.

On Espruino as far as I can see you could just use Array directly, and if you really need to limit the size of the queue you could override .push to just call splice after it to limit the length.

Just a quick example:

var q = new Queue(20);
t=getTime();for (var i=0;i<20;i++)q.push(i);print(getTime()-t­);
// 0.082 seconds
var q = [];
t=getTime();for (var i=0;i<20;i++)q.push(i);print(getTime()-t­);
// 0.0102 seconds

So it's 8x slower than just using an Array, and honestly I'm amazed it's that good.

As @fanoush says really... Also you could try without 'default_console_baudrate' : "38400", and just use 9600 as a start because that's what Espruino usually defaults to (including the IDE).

... so it could be that it's all working and the IDE's baud rate is wrong?

Once connected by Bluetooth you could do Serial1.println("Hello") and Serial1.on("data",print) to check out if RX/TX is working separately

I just tried another build using BOARD=NRF52840DK and that works fine here - so as @fanoush says I'd definitely look at doing provision (you may have to delete all extra files in targetlibs/nrf5x_15 beforehand to get it to work them out again).

I can't find BLEP_BONDING_STATUS in any *.h file!

It's there:

./libs/bluetooth/bluetooth.h:  BLEP_BONDING_STATUS,              //< Bonding negotiation status (data is one of BLEBondingStatus)

So I think likely when you did git pull maybe there was some merge error? I'm not sure what changes you have made yourself but I'd consider checking out fresh from the Espruino repo and then trying to re-apply your changes on top of what's there now

Hi! I think everyone's got this answered already - but nice to see you're coming from Pebble and looking at porting your old watch face.

Just one note on the display - unfortunately unlike the color pebbles this display is only 3 bit (so on/off RGB), not 6 bit color - but we do perform dithering in the firmware.

You can access the button (using Bangle.setUI ideally, but setWatch is lower level) - but just a note that usually you do Bangle.setUI({mode:"clock"}) which then automatically uses the button press to start the launcher.

Obviously if you want to change it for your clock face it's up to you, but that's what most other clock faces do - and if you want to use the button you may have to avoid using Bangle.setUI({mode:"clock"}) (just use mode:"custom") so it doesn't try and exit to the launcher on button presses :)

Interesting about the pin code. If it makes you feel any better you might have cancelled the Pin pairing process, so the phone was using the Bangle without the fully end to end encrypted connection - 2v19 fixed that, which is why you then had issues - and repairing should have fixed it.

I'm not sure I understand about the BOOTING boot loop. Initially you mentioned you got it when downgrading to 2v18, but now you're saying that you get is when going to 2v19? When it's got that BOOTING... loop did it display anything else after BOOTING... (like the Bangle.js logo or part of the watch screen?)

Do you have any other bluetooth settings enabled like Whitelist?

I'm now wondering whether the pincode functionality works at all?

Yes, it definitely does. I've just tried it again here and it works great on a watch with 2v19, even after reboot.

Great! Glad it's working again!

It is possible to replace the battery - and I'd have to check but I think we may have a few replacements in stock still.

However the short battery life might not be the battery, but some slight short in the circuitry causing a high power draw - I guess you could try charging the battery up and see if you can measure the voltage across it when it's charged? If it's getting 4.2v when charged but the watch is still reading low then it's likely that increased resistance on the board is what's making it read the voltage as very low.

I guess it's also possible that the resistance has meant that something that draws a bunch of power (like the GPS) is turned on? 8 hours of life is about what you'd expect if that's what it is.

That looks great!

Looking at the first bit of code you have there I see you do:

BoardPart = BoardParts.Items[Y][X];

But then you do:

      if (BoardParts.Items[Y][X]) {
        if (BoardParts.Items[Y][X].AnimPhase < 2) {
          pegsLeft++;
          result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X + 2, Y, false);
          result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X - 2, Y, false);
          result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X, Y - 2, false);
          result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X, Y + 2, false);
          result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X + 2, Y - 2, false);
          result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X + 2, Y + 2, false);
          result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X - 2, Y + 2, false);
          result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X - 2, Y - 2, false);
        }
      }

So you reference BoardParts.Items[Y][X] a lot - each time Espruino is having to do a lot of lookups to find BoardParts, Items, then Y and X. What if you just replaced all occurrences or BoardParts.Items[Y][X] with BoardPart (which should be the same?).

That might make a reasonable difference to the speed as well

That's an odd one - were all your apps up to date? I think most people are using 2v19 now without issues.

And Gadgetbridge repeatedly complained that it couldn't connect? Or did you only try it once? Did you have any other bluetooth options set like a Pin code? I know we did add some code (in 2v19 I think) to ensure that if the pin pairing was requested, you couldn't communicate with the watch without the watch having been properly paired and I guess you might have hit that (but unpairing/repairing should have fixed it).

however somehow then my Bangle.js 2 came stuck in an infinite 'BOOTING...' loop

Sorry to hear that - was that when updating using https://banglejs.com/apps/?id=fwupdate ?

It can happen when using the DFU updater (especially from iOS) but it's rare it happens with the fwupdate app - at least (as you found) when it gets in that state you can update it with a DFU app

Potentially it would, yes... It'd require a little messing around to pull the code out of the assisted GPS app but it's definitely possible.

If you just want to get to the AGPS app quick you can always use the link https://banglejs.com/apps/?id=assistedgp­s to go to the app loader though - so it's a few less clicks to get to upload AGPS that way

Perhaps a MDBT42Q could be an alternative

Yes - it can self calibrate the RTC based on the high speed oscillator, but it's still not entirely accurate.

I'll then use a Pico without the Crystal and a DS3231 module as an external reference.

That's probably the best bet for a standalone clock. Even external crystals like ABS06-107 are 20ppm accuracy (so not much better than just using the high speed oscillator) , but the DS3231 is 2ppm - so 10x more accurate!

This looks great! It'd be good to see this in the app loader!

Do you think you could come up with a small self-contained example bit of code that you could post up here that runs really slow like you mentioned? It might be we can find a way to make it faster.

What do you mean by "Moves Left" - does it actually try and run through each move each time to see how many would be needed to finish?

Just a thought but even without using compiled code, if you could split the code up such that it could run as a function that gets called multiple times, you could update the screen immediately, and then run the calculation in the background. If the user interacted with the Bangle to make another move you could just cancel, redraw with the new state and start again.

Great - thanks for all you work on this! Just for anyone else, this is now live on the main app loader: https://banglejs.com/apps/?id=waternet

Hi - I think this is expected... Because the Pico doesn't know if it has a crystal or not it has to check, so I believe what it does is:

• Powers up using the internal RC oscillator
  
• Switches on the external oscillator
  
• Starts executing code
  
• After ~1 second it then looks at the external crystal and it it seems to be working it swaps over to using it.
  
  

But that's complicated again, because on the Pico, we wanted to be able to get accurate timing (better than 32kHz), but that timing should also match the real time clock (which only runs at 32kHz).

So we have some crazy logic that uses the processor's high speed clock counter, but then syncs that against the RTC - and it takes a while to adjust itself to the right speed, especially as it just started adjusting itself once to the internal RC oscillator and then has to readjust to the external one.

So I'm afraid I don't think there's a great deal we can do to avoid that

:) yes - literally second line.

Also, if you give us some idea of what search words you'd likely search for on the Espruino site to find the info then I can add those to the keywords list for the page so it comes up for more people.

Same for any page really - I pretty much never get any PRs for this, but if there's a page that you found that didn't come up when you searched, there's a link at the bottom of the page that goes to GitHub (eg https://github.com/espruino/EspruinoDocs­/blob/master/info/Features.md) and you can add to the KEYWORDS list at the top of the file and do a PR

Is theming always global?

Well, Graphics state is always global - you should always get in the habit of calling g.reset() before you start rendering in a function where you're not 100% sure of the graphics state it's called from.

If you just do g.drawString then font, alignment, color, etc could be set to anything.

The current solution is just a sensible compromise of complexity and memory usage... I guess potentially we could have a way to 'clone' a graphics instance into a variable where state for that var is kept separately - but I think the end result is it'd end up getting used pretty lazily and we'd end up storing loads of different graphics states for things that really didn't need it.

Without a complete mini example to look at I can't be sure, but any function that is defined (even arrow functions) will contain a link to the scope they were defined in. Espruino isn't smart enough to figure out when the function is defined if it actually references any local variables.

So likely:

setTimeout(function() {
  this.printMem();
}, 3000);
setTimeout(this.printMem, 3000);

Will print two very different results. Could that be it?

Thanks - it is slightly concerning that it doesn't cause an error though.

It seems that in Espruino, a=3 actually returned a reference to a when really it should have returned 3. So (a=2)=3 was possible when it shouldn't be according to the spec - I've just fixed this for cutting edge builds.

Ok, it should be fixed now in the development app loader.

Thanks for the backup! Just installed and I can reproduce.

But it looks like you had Translations enabled. I just tested again here - if you enable translations and re-upload it breaks, but if they are disabled it's fine - so it should be easy enough for you to get working again.

@Hank could you have been using translations too?

Issue reported here too: https://github.com/espruino/Espruino/iss­ues/2417

Ok, so I'd be pretty sure that actually all the bonding info stays in place after a reboot. @user156416 so you actually checked what I said, and Android reported it was bonded?

Because I'd have thought that even if Android remembered it was bonded, if the bonds were erased on the Bangle then it would refuse to connect.

So I think the issue is probably the very recently added NRF.resolveAddress which tries to resolve the address: https://www.espruino.com/Reference#l_NRF­_resolveAddress

(code for it is at https://github.com/espruino/Espruino/blo­b/cfbc4040dac6a7881e3465f60adc4dd8a1e45b­85/targets/nrf5x/bluetooth.c#L3654-L3673­)

Maybe you could try calling it from the IDE along with NRF.getSecurityStatus() after a reboot (you can do remote access from a desktop via the App Loader in Gadgetbridge). I would imagine that if bonded, bonded would still stay true after a reboot but maybe resolveAddress(NRF.getSecurityStatus().c­onnected_addr) might not work for you?

If so, perhaps while the peer info is all saved to storage, maybe the peer manager doesn't actually load it on boot, so pm_next_peer_id_get ends up not iterating over all saved peers?

What clock face are you using? Those can have quite a big effect - for instance Slope Clock which updates once a minute still uses quite a bit of power because it's animated.

In order of power consumption (there are some figures at https://www.espruino.com/Bangle.js2#powe­r-consumption):

• GPS
  
• LCD backlight
  
• Compass
  
• Heart rate
  
• Bluetooth connection
  
  

GPS is a massive power draw, so yes, if you have it on the battery will flatten quickly - there's not really a way around that.

So to get the absolute best battery life, you want:

• A non-animated clock that updates once a minute
  
• 'Wake on twist' turned off
  
• Ideally no (or 10 minute) heart rate sensing
  
  

I have a bunch of watches here that I use for development, and for the ones sitting on the desk (especially if they just have the factory apps on) I reckon I must get almost 2 months

I'm still really struggling to reproduce this, either with or without pretokenisation.

And you're definitely updating the apps from https://banglejs.com/apps/ and not your own personal app loader?

Please could you do a 'Backup' from the app loader and email me the zip (if you're happy to do that - it's a complete copy of what is on the watch so could contain some personal info) - I can then attempt to reproduce it here.

This sounds really interesting - thanks for sharing!

From my point of view, Bangle.js 2 would be very interesting as the receiver doesn't appear to do quite as well as Bangle.js 1 or standalone ones.

Not sure if you saw it but we have some info on communicating with the GPS at https://www.espruino.com/Bangle.js2+Tech­nical#gps and you can turn on the output of extra GPS data that might be interesting with the $PCAS03 command