Search results for:

so I tried Brave

Unfortunately Brave developers disabled web bluetooth intentionally because of their privacy focus. For more details see https://github.com/brave/brave-browser/i­ssues/9586#issuecomment-840743917 and https://github.com/brave/brave-browser/i­ssues/15637

Button can be defined in board file, see other boards for BTN1. this 'check button and skip load' is there for nrf52 too so that's basically all boards except ESP. could be added here https://github.com/espruino/Espruino/blo­b/master/targets/esp32/main.c#L69

Normally this should not happen, maybe you have HID enabled so windows detect it as keyboard mouse? In such case try to disable HID if it helps. there is similar issue described here https://stackoverflow.com/questions/6899­7468/web-bluetooth-connection-problems-i­n-chrome-on-windows-10

you say I need to write 'LED1.set()\n' - do I need to add true\false ?

no, https://www.espruino.com/Reference#Pin

after I have connected to the device , why can't I see the data I'm sending to him , is there any way to write something to log in order to see where is the problem ?
all I can see is -> Bluetooth
I'm sending sample data once every 10 seconds , and I can't see anything - why?

-> Bluetooth is printed when output console is switched to bluetooth, this indeed happens by default when you connect. When you disconnect you will probably see -> 'name your previous console'. Often this is what you want when you connect to the device via https://www.espruino.com/ide/ or espruino cli command. You can override this behaviour as per https://www.espruino.com/Reference#l_E_s­etConsole but if you keep console as it was you cannot send commands like the LED1.set() to console via bluetooth connection.

and I can't see anything - why?

output goes to bluetooth console but you probably don't read it at all

do you have an example\guide for it?

I think I linked more than enough guides already and it doesn't look like it helped

can you show an example code to put on the mdb42q

You don't need any code on mdb42q at all to do this. You also don't need to 'wait' on MDBT42 side for anything.

You just need to connect from the pi to the MDBT42 and send JS code to set the GPIO as shown in example https://www.espruino.com/Web+Bluetooth that is the easiest way to do this. There are other ways with custom service on MDBT42 - see e.g. this https://www.espruino.com/BLE+Communicati­ons but this is more complicated. Since you are struggling even with the basics there is no point in doing that as step 1.

As I see it, the biggest issue for you is how to write code on Pi side to connect and send string like 'LED1.set();\n' to Nordic UART service on MDBT42 (or any custom service if you go for the more complicated solution) . In both cases the Pi side will be similar - connect, write data to some characteristics. If you want reply back then also subscribe to notifications and get output back.

As for refusing connection from unknown devices check https://www.espruino.com/BLE+Security but I wouldn't worry about that in step 1.

I think we misunderstanding each other.... :-)

Yes, there seems to be a lot of misunderstanding on your side in both how BLE works and also what you exactly want to do and how :-)

And BTW here is example of getting battery via (already suggested) espruino cli command
http://forum.espruino.com/conversations/­297357/#13369180

can Espruino be used as client? meaning can I send data to it?
or they are ony used as "server" and send data to other devcies?

Espruino can be used on both sides quite easily. It is the linux on the Pi that is more complicated. Just found tutorial that may help a bit and describes various options , check https://www.espruino.com/BLE+Advertising­

require("Storage").eraseAll() clears all saved stuff and then E.reboot()
You can also check via Web IDE storage icon (in the middle) what is there now and possibly save it.

connecting the opposite way does not help you in any way, you need example for the Pi which connects the other way, not this piece of JS code for MDBT42. Then you would just send piece of javascript to toggle GPIO. As a start you can use web page in Chromium on the PI as per https://www.espruino.com/Web+Bluetooth - this is the easiest thing and web bluetooth works on the Pi

otherwise bluetooth in linux is a mess, there are many ways, maybe search raspberry forum or check this https://elinux.org/RPi_Bluetooth_LE#Usin­g_Bluetooth_LE_with_Python or node.js via https://github.com/noble/noble or dierctly via https://www.npmjs.com/package/espruino which is using noble

I want to connect to the mdb42q from my pi

your code example is doing it the other way - from Espruino to the Pi, so which one you want and which device has GPIO connected to something?

On Espruino side you can hook into incoming connection event and refuse any connection so you can filter by mac address even without secure connection if you wish.

I can see it in bluetooth and ble scan from my phone
so what is wrong?

Try also connection over BLE from the phone (e.g. via nrfConnect), does it work? What are you next steps if connection works? How do you plan to receive GPIO toggle command on Pi side (if this is the right direction)?

I added the active: true but it made no difference.

It makes a difference when data (like device name, or basically anything) is in scan response packet and not directly in advertisement packet. Packet size is very limited so sometimes the less important data is in scan response, which is asked for only with active scan. Anyway, great you got it working.

you may try with active: true as per https://www.espruino.com/Reference#l_NRF­_findDevices , also try to remove the filters in case it is the filter which is not matching for some reason

Screen data transfer over SPI of course draws something too but I'd guess it is minimal when compared to CPU usage needed for typical javascript redraw routine (as the javascript interpreter may need to run thousands of cycles per each trivial JS line). Tens or hundreds of milliseconds of 100% cpu usage at ~4mA is much more than few miliseconds of SPI transfer and LCD screen pixel changes. As an example see this http://forum.espruino.com/conversations/­376504/#16554635 - burning 15ms of cpu for base64 decoding and heatshrink decompression over and over again probably draws much more than pushing pixels to the display in the end. But still maybe those 15 ms per icon are not worth optimizing if drawn only once per minute.

most probably the body is not part of the notification? Is the body visible in android phone notification when you pull down notification drawer? it just resends this info to the watch

That the manual approach worked for you does suggest the App Loader may be the source of this 2v14 problem.

manual approach - DFU mode is part of nrf52 bootloader, should work even if espruino firmware zip is completely broken so could also be that nightly build was broken and did not start at all

if you have android phone (or iphone) download nrfConnect from store, download stable firmware zip to phone, then hold watch button until it reboots and line is printed over screen, release button before it goes over, then it is in DFU mode, search in nrfConnect for DfuTarg device, click connect, then click DFU icon and upload the zip. You need to be quick as it does not wait in this mode for very long. If you are selecting zip and see on watch that it already boots then first reboot watch again in same way and then finish selecting zip, it may reconnect and start uplading.

Oh, cool, many thanks, will test it. I wonder how it deals with possibly different MTU negotiated with each device.

It could make sense. However I'm not sure how much it would save. SPI flash can momentarily draw like 15mA (see e.g. table on page 83 for similar chip here https://www.winbond.com/resource-files/w­25q128fv%20rev.m%2005132016%20kms.pdf#pa­ge=83 ) while the CPU being 100% busy draws like 5mA (table here https://infocenter.nordicsemi.com/topic/­ps_nrf52840/_tmp/nrf52840/autodita/CURRE­NT/parameters.i_cpu.html?cp=4_0_0_4_1_0_­2 ) however there is some cache buffer implemented for reading JS data from SPI flash so it is not read all the time and may actually sleep most of the time with short bursts of activity. Interpreting JS code makes the CPU busy almost all the time as long as your redrawing code runs so while CPU draws less than SPI flash it may consume majority of the power.

There is also internal flash directly on the nrf52 chip, bangle 2 has like 500KB free, would be interesting to have test with some longer busy looping JS code running from storage how much loading code from external SPI would add vs running same code from internal flash (or from "ram" which should be similar)

retty much all wrist-mounted heart-rate monitors tend to have trouble when you move your arm around but generally they use the accelerometer data so they can filter out false positives and still get some useful information out.

Recently I found interesting paper with some 'heavy handed' approach to this problem:
Motion Artifact Reduction in Wearable Photoplethysmography Based on Multi-Channel Sensors with Multiple Wavelengths
https://www.researchgate.net/figure/Syst­em-diagram-of-the-wearable-multi-channel­-PPG-acquisition-system-including-PC_fig­2_339798967
they use four typical sensors with multiple wavelengths plus accelerometer and try to do some motion compensation with that. Full download of the paper is available so lot of interesting info related to this problem there. See also citations below for more related papers.

found the topic - check http://forum.espruino.com/conversations/­370717/#16299790 or here http://forum.espruino.com/conversations/­374715/#16475478

regarding the hole - there is some stuff in it to protect from dust/water but keep pressure sensor working, also I can't find some photos of internals now but let's hope you won't break something inside near the hole you make

My recent idea is, that I received device with tightly-closed sensor without contact with environment.

Yes, that is most probably the problem. They later added small hole on the top side where the strap is. If you have no hole there the watch is a bit more waterproof but you get pressure inside watch not outside. Also search the forum here, there are more details, some early Bangle 2 watches are like that too. I also have such Q3 without hole and can confirm it behaves like that.

I think waking up in itself is expensive, regardless of what is actually done after.

Not really. The CPU needs to wake up all the time to keep Bluetooth protocol happy so waking/sleeping is fast and is not an issue. nrf52 can last months from coin battery sending advertising packets every few hundred of milliseconds which wakes up CPU and radio for every packet.

So it definitely depends on what is actually done after waking and for how long. The power is drawn by CPU being busy running code or by some other hardware which is not put to sleep . Bangle running any JS code from flash storage makes CPU and SPI flash chip busy. Drawing to display keeps CPU and display busy.

What you're doing there with the getShoeImageSource function looks good to me.

Well, just measured and calling the getShoeImageSource takes 15ms

>var d=Date();getShoeImageSource();d=Date().m­s-d.ms;
=15.47241210937
>var d=Date();getShoeImageSource();d=Date().m­s-d.ms;
=15.65551757812

writing to file and then drawing it from file vs from getShoeImageSource

var s=require("Storage")
s.write("yyshoeimage",getShoeImageSource­())
>var d=Date();g.drawImage(s.read("yyshoeimage­"),20,20);d=Date().ms-d.ms;
=12.05444335937
>var d=Date();g.drawImage(getShoeImageSource(­),20,20);d=Date().ms-d.ms;
=26.51977539062

whether 15ms of CPU time is worth optimizing (for power, when e.g. redrawing watchface periodically) is of course debatable, if drawn every second it can make a difference.

the part with

return require("heatshrink").decompress(atob("o­FAwkEogA/AH4A/AH4A/AH4A/AE8AAAoeXoAfeDQU­BmcyD7A+Dh///8QD649CiAfaHwUvD4sEHy0DDYIf­EICg+Cn4fHICY+DD4nxcgojOHwgfEIAYfRCIQaDD­4ZAFD5r7DH4//kAfRCIZ/GAAnwD5p9DX44fTHgYS­Bf4ofVDAQEBl4fFUAgfOXoQzBgIfFBAIfPP4RAEA­oYAB+cRiK/SG4h/WIBAfXIA7CBAAswD55AHn6fUI­BMCD65AHl4gCmcziAfQQJqfQQJpiDgk0IDXxQLRA­EECaBM+QgRYRYgUIA0CD4ggSQJiDCiAKBICszAAs­wD55AHABKBVD7BAFABIqBD5pAFABPxD55AOD6BAD­iIAJQAyxLABwf/gaAPAH4A/AH4ARA=="));

could be rewritten to decompress to file in storage once at startup or even be already uploaded in decompressed state as binary file. Storage.read doesn't take extra RAM and returns pointer to the storage data directly. With bangle 1 and 2 this data is read on demand from SPI flash. Bangle 2 also has about 500KB of internal directly mapped flash available as drive c:. Not sure whether this feature is already enabled in stable firmware but if you do Storage.write("c:filename",buffer) it should end in internal flash. When reading specifying the drive letter is optional, should be found both as c:filename and also filename. This internal flash is directly visible for CPU like RAM so speed should be more or less the same like having data in RAM.

Just a small followup - I found aliexpress store that sells those STLink V2 dongles (board photo https://ibb.co/m4MpRhB) with Geehy APM32F103CBT6 https://www.geehy.com/apm32?id=14

This APM32F103CBT6 is somewhat interesting STM32F103 clone that has 128KB of flash and can run at 96MHz with usb working (real STM32F103 can only do 72MHz). It even has interesting memory mapped single precision FPU that seems to work. So I made Espruino build that run on that chip at 96MHz.

These dongles are cheap, small and versatile but the ram/flash is pretty small (20KB,128KB) so the Espruino build is stripped down but still it can be used for small USB to GPIO/SPI/I2C projects. The usb stick like form factor with metal case and pin header on the other side can be handy.

The shop is here https://www.aliexpress.com/item/10050016­21626894.html but no guarantee you'll get same chip too. I got it twice and made third order. Anyway, it is no big deal, just small heads up.

And btw this one is also nice because it has two LEDs, no strong pull resistors on B6/B7 and even have extra A9/A10 and BOOT0 pads available on PCB so apart from SWD can be flashed via serial bootloader and those two more GPIOs are also readily available for extra HW uart.

Thanks for answer, looks like it might be still worth it then even if being simple. The variable/function address lookup and possibly other stuff known only at runtime cannot be done on server indeed.