Search results for:

Indeed I am planning to submit you a pull request with the code on GitHub.
(It may take me some time thought as I am not that familiar with the Espruino Store architecture and Javascript in general.)
I would like to design a popup window where someone enters his/her OpenHaystack advertisement key (aka public key) before uploading the code.
(I have seen some examples on the Store I could get inspired from.)

---

To compute the extra average current consumption due to clock calibration, data is taken from the above measurements (@3V):

• 386.58uA clock calibration average current during 18.64ms every 8s
  
• 2.14uA deep sleep average current
  
  

Thus, alternating calibration for 0.001864s and deep sleep for 8-0.001864 = 7.998136s every 8s, the average current required for such cycles can be computed as a weighted arithmetic mean:

( 386.58*0.001864 + 2.14*7.998136 ) / 8 = 2.23uA

The additional average current consumption due to clock calibration (mandatory when using the internal RC oscillator) with respect to a board that deep sleeps only (thus equipped with an external low-frequency crystal) is:

2.23 - 2.14 = 0.09uA

This represents 0.09 / 2.14 = 0.042 = 4.2% more

---

PS: Could you move this thread to Home / Projects in the Forum?
I believe it rather belongs there than where it is currently at Home / Official Espruino Devices / Puck.js, Pixl.js and MDBT42.

After further analysis it seems the spikes on N51-RC-LDO in this post on GitHub are not as erratic as I thought:

Those are 4s interval spikes and are certainly due to the clock calibration involved when using the internal low-frequency RC oscillator (as there is no such spikes when enabling the external low-frequency 32.768kHz crystal) (see N51-XTAL-LDO).

Thus the 8s interval spikes on the nRF52832 might be due to clock calibration as well (at half the frequency though). As the Puck.js is not equipped with an external low-frequency 32,768kHz crystal, I cannot enable it and thus clock calibration is mandatory.

The 8s interval spikes (see above post) might be due to Espruino or Puck.js's hardware themselves as they don't occur when running the OpenHaystack (ultra low power) alternative firmware on a nRF51822 (see measurement N51-XTAL-LDO in this post on GitHub).

Note that, despite those 8s interval spikes, it seems the nRF52832 is more power efficient than the nRF51822 (6.30uA vs 7.60uA).

There is no external low-frequency 32,768kHz crystal available on the Puck.js, thus the internal low-frequency RC oscillator used instead that requires regular clock calibration, might be responsible for the 8s interval spikes. On the nRF51822, clock calibration when using the internal RC circuit seems to be more erratic though (see measurement N51-RC-LDO).

But from my current tries with my Holyiot YJ-17095 board, it seems the Espruino version consumes about 45uA so about 5 to 6 times more than the beacon version in C

It seems something was wrong with my preliminary tests on the Holyiot YJ-17095 board since today I measured an average power consumption on the Puck.js acting as a beacon of only 6.30uA @ 3V (see this post on the forum).

There are some spikes on the graphs I cannot explain though:
See the little spike in the middle of the two broadcasting spikes (separated by 5s as programmed):

The average current on the 4.999s selected range when the beacon is supposed to be sleeping is 3.52uA and could be reduced further (2.08uA, see previous post) if this spike in the middle wouldn't be there.

This spike when zoomed in, looks like this:

It is not as greedy as a broadcasting spike though (386.58uA vs 2.91mA).

Such spikes are spread regularly at a 8s intervals:

Below are some power measurements (current @ 3V) of the Puck.js programmed using this code made using my NORDIC Power Profiler Kit II:

Current shape when switching from being connected to the IDE to restarting the BLE stack to act as a beacon

Average current consumption of the beacon over a minute ~ 6.30uA

Average current and shape of the beacon while sleeping ~2.10uA

Average current while broadcasting ~ 2.91mA

TL;DR

The Puck.js running this code is very energy efficient:
According to those readings, the average power consumption is 6.30uA which makes a 3V CR2032 230mAh battery last more than 4 years:

230/0.00630 = 36507 hours = 1521 days = 4.16 years

Below is some code to make a Puck.js (or Pixl.js or MDBT42) act as a beacon to be tracked via Apple's massive Find My network ...act as an Apple AirTag equivalent if you will. Thus you can find your Puck.js if you lose it.

An Apple Mac computer is required though.

It is some Espruino code to mimic the beacon code of the OpenHaystack framework. It is based on Eric Betts original code.

The code:

/*
OPENHAYSTACK
A framework for tracking personal Bluetooth devices via Apple's massive Find My network
2021-07-15 SK
*/
print("OpenHaystack Beacon\n===================\n");

const key_b64 = "Fy5SNl1ehMqUe49PJ4sxgrvTJLj/hlNjVYy5q1=="; // replace with your public (advertisement) key

function b64ToArray(str) {
    let bstr = atob(str);
    let arr = [];
    for (let i = 0; i < bstr.length; i++) {
        arr[i] = bstr.charCodeAt(i);
    }
    return arr;
}

const key = b64ToArray(key_b64); // public key

print("Public key:");
print("- base64:\n" + key_b64);
print("- hexadecimal:\n" + key.map(x => x.toString(16).padStart(2, '0')).join(' '));

const mac = [ key[0] | 0b11000000, key[1], key[2], key[3], key[4], key[5] ].map(x => x.toString(16).padStart(2, '0')).join(':'); // mac address

print("\nMAC address:\n" + mac);

const adv = [ 0x1e, 0xff, 0x4c, 0x00, 0x12, 0x19, 0x00, key[6], key[7], key[8], key[9], key[10], key[11], key[12], key[13], key[14], key[15], key[16], key[17], key[18], key[19], key[20], key[21], key[22], key[23], key[24], key[25], key[26], key[27], key[0] >> 6, 0x00 ]; // advertising packet

print("\nAdvertising packet:\n" + adv.map(x => x.toString(16).padStart(2, '0')).join(' ') + "\n");

NRF.setAddress(mac);
NRF.setAdvertising(adv, {interval:5000});

print("\nTo start beacon click on IDE upper-left icon to disconnect board. BLE stack will restart");
print("Then reset (if code saved in RAM) / hard-reset (if code in Flash) board to reconnect IDE");
print("To hard-reset hold BTN1 for >5s while repowering the board. Type reset(1) to erase Flash");

...yields:

 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v09 (c) 2021 G.Williams
>
OpenHaystack Beacon
===================

Public key:
- base64:
Fy5SNl1ehMqUe49PJ4sxgrvTJLj/hlNjVYy5q1==
- hexadecimal:
17 2e 52 36 5d 5e 84 ca 94 7b 8f 4f 27 8b 31 82 bb d3 24 b8 ff 86 53 63 55 8c b9 ab

MAC address:
d7:2e:52:36:5d:5e

Advertising packet:
1e ff 4c 00 12 19 00 84 ca 94 7b 8f 4f 27 8b 31 82 bb d3 24 b8 ff 86 53 63 55 8c b9 ab 00 00

BLE Connected, queueing BLE restart for later

To start beacon click on IDE upper-left icon to disconnect board. BLE stack will restart
Then reset (if code saved in RAM) / hard-reset (if code in Flash) board to reconnect IDE
To hard-reset hold BTN1 for >5s while repowering the board. Type reset(1) to erase Flash

EDIT: I moved the content of this post to another thread in the forum as I plan to publish the code on Espruino App loader once it is finalized and refer to it for explanations.

It seems enabling the DC/DC regulator doesn't improve (always?) performances: check my post on GitHub where I compare different settings on a nRF51 board programmed to be a beacon in C. Enabling the low-frequency crystal does improve power consumption thought.

I am planning to do the same comparison with my FEASYCOM FSC-BT630 (nRF52) as soon as I get it. Additionally I would like to compare the beacon when programmed using Espruino (see this post for the original code). But from my current tries with my Holyiot YJ-17095 board, it seems the Espruino version consumes about 45uA so about 5 to 6 times more than the beacon version in C.

I can't explain this as I thought

NRF.setAddress(mac);
NRF.setAdvertising(adv, {interval:5000});

required restarting the BLE stack with different settings (disabling the communication with the IDE, etc) that would make this code running very similar to the code directly generated from C.

@MaBe pointed out to me that I can get inspired from the Bangle.JS2 board definition file to tweak my boards' settings.

@Gordon : I bought a pixel during the Bangle.js campaign. It is peanuts but I made sure to buy official boards and your book. I thought the donated badge was automatic when buying something during the campaign and it could be a mistake... I realise buying/donating are two different things. Additionally it is not worth putting that badge for peanuts.

Thank you!
I already had removed LED1 from the definition file.
I kept BTN1 (set to D3 thought for the FEASYCOM FSC-BT630 board) to allow HARD RESET mainly, but to perform DFU upgrade too as I find it a nice feature. I was thinking to use SWD to flash the firmware only once and to perform next upgrades OTA.
Thanks to your assistance, I just switched the default console to bluetooth and removed default_console_tx and default_console_rx from the definition file.

I am currently experimenting with my Holyot YJ-17095 board and will try it enabling the DC/DC regulator. I will make screenshots to observe the current spikes I was talking of and to compare power consumptions.

Great that the Holyot YJ-17095 board supports the DC/DC regulator!
It seems that the FEASYCOM FSC-BT630 board supports the DC/DC regulator too (see board datasheet, page 11, 4. PHYSICAL INTERFACE, 4.1 Power Supply).

I will compare power consumption of the FEASYCOM FSC-BT630 used as a beacon, programmed using Espruino, for all the different setting combinations (as soon as I receive it).

AVERAGE POWER CONSUMPTION (in uA @ 3V):

Low-Frequency Oscillator / Internal Power Supply Regulator	LDO (Default)	DC/DC
Internal RC Circuit (Default)	?	?
External 32.768 kHz Crystal	?	?

To let the bootloader take into account the new reset pin definition D3, I modified my board definition file with 'BTN1' : { 'pin' : 'D3', 'pinstate' : 'IN_PULLDOWN' } and invoked make with argument BOOTLOADER=1. Is this enough?

The Espruino documentation is top-notch and the file entitled Espruino Internals: Build Process explains how to enable the low-frequency crystal and the DC/DC converter as well:

   'makefile' : [
     'DEFINES += -DESPR_LSE_ENABLE ', # to enable low-frequency crystal
     'DEFINES += -DESPR_DCDC_ENABLE', # to enable DC/DC converter

@Gordon : Can you tell me how to get the Donated badge under my name in the forum? I did donate during the Bangle.js Kickstarter campaign and I own official Espruino boards (Pico, Puck.js) + your book.

Sorry for being that little clear: I don't have a MDBT42Q board. I want to define my own definition board, and I thought MDBT42Q.py was a good start...

Indeed I do have a board with a low-frequency crystal (actually it is still in the mail) and I want to enable it so it is not sitting there wasted + to save some power.

I have 2 nRF52832 boards I would like to use as beacons:

• a Holyot YJ-17095 without any external low-frequency crystal,
  
• a FEASYCOM FSC-BT630 equipped with a MCU-external though board-embedded low-frequency crystal.
  
  

I used the standard MDBT42Q.py definition file to build the firmware for the Holyot board.
I would like to write a board definition file for the FEASYCOM that:

• enables its MCU-external though board-embedded low-frequency crystal +
  
• sets a pin to let the board enter DFU mode / hard reset mode.
  
  

I did some power measurements on nRF51822 boards programmed as beacons (not nRF52832 boards though, not Espruino based) using the NORDIC Power Profiler Kit II, and I came out with this comparison chart:

Low-Frequency Oscillator	Average Current Consumption @ 3V
External 32768 kHz crystal	7.85 uA
Internal RC circuit	8.24 uA (14% more)

Thus I expect to save about 14%. This result corroborates this discussion on Nordic DevZone Q&A.

Once I successfully generate an optimised Esprino firmware for my FEASYCOM board, I would like to do the same comparison...

I did some measurements on the Holyot board programmed as a beacon using Espruino and was impressed by its low power consumption already!

However I also noticed little current spikes here and there in-between two broadcasting emissions (the board was sleeping?) that might be due (I have no clue though) to the use of the RC internal oscillator.

This is why I would like to try the same code on the FEASYCOM board which Espruino firmware is built enabling its low-frequency crystal (+ redefining the reset pin to be able to exit the NRF.setAdvertising mode easily).

• Regarding the builtin DC/DC converter, I need to understand how to enable it using Espruino?
  
• Regarding the bootloader, I need to understand how to account for that new button pin definition?
  

It is very clear. Thank you very much!

So I guess I have to reassign the Espruino DFU/reset Pin to something other than D0 to have this feature working?
Maybe by modifying D0 in line 'BTN1' : { 'pin' : 'D0', 'pinstate' : 'IN_PULLDOWN' } of file MDBT42Q.py with D3.

Thank you so much! I will do some digging...

What about D0 being P0.00/XL1 and D1 being P0.01/XL2. Is this true?

I have a nRF52832 board equipped with an external low-frequency 32678 kHz crystal.
Is there a way to switch the low-frequency oscillator from:

• the internal RC oscillator to
  
• the external 32678 kHz crystal oscillator?
  ...to generate an espruino build?
  
  

I would like to use the external low-frequency 32678 kHz crystal to improve the board power consumption when used as a beacon.

The external low-frequency crystal is connected between P0.00/XL1 and P0.01/XL2 (see enclosed picture).
D0 and D1 are used on the Esprino MDBT42Q board to switch to DFU/reset modes and to light an LED.

• I believe that D0=P0.00/XL1 and D1=P0.01/XL2. Is this true?
  
• I believe there is an easy way to use different pins to switch to DFU/reset modes and to light an LED by creating a different board definition. Is that right?
  
• But I can't see any easy way to switch from the internal low-frequency RC oscillator to an external 32678 kHz crystal. Is there one?
  
  
  

@jeffmer: I am really impressed. I have an iPhone too and would be really interested to see what kind of application you will end up with~~

@PlaidFox: I believe I am not really a programmer too. Bangle.js gave me the opportunity to implement a simple watch face with the minimalist 2x3 pixel numerical digit font I came up with. See 2x3 Pixel Clock :-) The attached picture displays 17:49. Some other digits like 2 or 5 are more challenging to read. Programming was relatively simple thanks to @Gordon great API.

I have just enabled https on my local server and WebBluetooth works just fine now. Thanks~~

Ohhhh OK Thanks.
Indeed I remember having read something about this now.
I will try using https as I wasn't able to interpret the errors in the console.

To simplify my app development workflow I decided to host Bangle.js Loader on a local server (a Synology NAS) rather than GitHub.io.
Currently I have selected Apache HTTP Server 2.4 as the back-end server, and PHP 7.3 with its default profile for PHP. I also tried with Nginx and a more advanced configuration for PHP.
The Bangle.js Loader web page displays fine when connecting to my local server (10.0.1.4) with Google Chrome under Windows 10.
But when I click on Connect I get this error message:

10.0.1.4 says
This Web Browser doesn't support Web Bluetooth.
Please click Ok to see instructions for enabling it.

Do you know the reason for such a bug? Is it to find on my server side or does it have to do with something wrong with the AppLoader code?

Indeed, with the french keyboard on Windows, e.key values are:

• "Dead" when pressing on the grave accent,
  
• "`" when pressing on the space bar preceded by the grave accent.
  
  

Thus the key value in the script is "Ctrl + Dead" when pressing on Ctrl together with the grave accent.

Regarding the keyCode, e.code for the grave accent is "Backslash" on the MacBook french keyboard.

Hope this helps.

Hmm - that's odd.

Indeed, I might have messed up triggering resetting without loading any code properly?!? It is complicated (if not impossible due to my probable mistake) to reproduce. Let's forget about it. My bad.

This remark is for me: After releasing BTN2, make sure to keep BTN1 pressed till the watch has finished rebooting not to load any code. (If not a standard reboot only will be triggered.)

I did play a little with the Chrome developer tools but I am too new at it to make a good use of it:

• I could set breakpoints and catch the first key pressed in a key combination but I didn't make it in running the code till the second key pressed (e.g., experimenting with Ctrl+Space, for auto-completion, that works fine with the french keyboard).
  
• I tried to modify the code (e.g., adding console.log(key)), saving index.js and experimenting with the shortcuts, but this resulted in my Chrome tab freezing for a long time.
  
  

Anyhow, what I observed is that the Ctrl+` shortcut works fine under Linux with the french keyboard (where the grave accent is not considered as a dead key) but doesn't under Windows or Mac OS (where it is a dead key).