Search results for:

where did you find those firmwares?

Well, it is from Smart Health app - firmware update functionality available from their servers, sadly there is no firmware file named R8, btw is b8:37 part of your device mac address? I'll search other binaries for R8 maybe the file has different name.

EDIT: searched all binaries and sadly don't see any with "R8" inside. for R1 and R2 the name is probably done in same way as there is this in the binary R2..%s %02X%02X so R2 gets formatted with two hex numbers (possibly from MAC address)
Here are device names with nrf52 firmware update available from SmartHealth BNR860,DEFIRO,E04S,E10PROA,E20E10A,E20E1­0I,E20E10J,E66C,E67,E68,E80A,E80C,E80DL,­E80DLA,E80DLF,E86,E86DL,ES09,F81,FW46,H0­1,H28,H6,H6B,M18PLUS,M8,P50C,R01,R02,R1,­R2,R2C,S2,S2D1,S6,S6Glu,TYFE80A,U32,V6,Y­B,YC,YC024,YC030,YC31,YC66
most of them are probably smartwatches (their firmware is much bigger, over 300KB vs <200KB for rings)

could someone indicate how to extract the firmware (for backup) and create my own from here onwards?

What is bluetooth name of that device and what is the name of android mobile app for it? If it is that VWAR ring and the name is R1 or R2 then maybe we have matching DFU zip. Also is there some firmware version info in the mobile app?

EDIT: attached is some random nrf52 ring firmware, if the name is matching you may try DFU, either it will be refused or it will brick your device or it will still work. If it will still work then it can be later restored to it (over swd pins). Also the binary can be reverse engineered to get more info about the hardware.

I tried to use that ~$5 amiibo nrf52832 based keychain for that but it is not very loud, there is very small buzzer inside, I even got bigger louder buzzer chips that still somehow fit inside ( "7525 Passive" from https://www.aliexpress.com/item/32864653­388.html ) but did not finish it. So with that having it on your keys could work.

What do you mean by "BLE speaker"?
Some (super small) custom device with buzzer+battery+BLE chip with some special BLE service implementing beeps?
LE Audio is not an option and typical Bluetooth speaker is not using BLE but Classic Bluetooth which is not an option too.

btw in this listing https://www.aliexpress.com/item/10050065­27342041.html which is not nrf chip it can be seen that some of them are actually transparent so you can really see where the chips are. This one is said to be FR8016HA

Cool, let us know when you get it and what is its bluetooth name. We may already have its firmware and could tell if it is nrf52 inside. Some aliexpress listings even allow to return for free, not this cheap one though. I think hx3605 is used in Magic3/Rock/C6/C17/QY03 watches(?), getting raw data should not be big problem.

How about reaching to the manufacturers and ask for a custom firmware with Espruino?

I think that so far there are exactly zero cases out of many tries where it worked like this before (including both bangle.js watches). But maybe next time.

But still, if you can spare the money, get it and take it apart than that is still something that could be interesting. At least we would know there is indeed nrf52 chip inside.

Yes you can write modified data there as the sha256 hash is checked after it is all written, but then it will mark it invalid and won't execute it. So either you have bricked device sitting in DFU waiting for correct package or with dual banked update (when there is enough space) the new invalid code is sitting in empty space above the real application waiting for you to jump into it via some clever exploit of original application over BLE
EDIT: or softdevice, I think there is a reason why S132 2.0.0 and S132 3.0.0 are no longer available from downloads here https://www.nordicsemi.com/Products/Deve­lopment-software/s132/download

Yes had same ideas but found out it is about finding SHA256 collision = different binary having same hash that is signed in init packet. this currently takes more time than the universe exists, or you get lucky and win a lottery.

init packet is signed so it must stay as it is and part of it is sha256 hash of whole binary - at least that is the core idea behind it, looks solid

ios may cache it too but the NRF.setConnectionInterval(7.5) is for connection not advertising, for that you need to set interval:xx inside NRF.setAdvertising call, default is 375ms

It is marked in red on that wiki page https://github.com/joric/nrfmicro/wiki/A­lternatives
search for "Workarounds". I just crush it in the middle with small flat screwdriver but could be desoldered too.

Also down on that page for nice!nano v1 "Regulator: AP2112K (code G3P, up to 600 mA, leaks 55uA), you can replace it with XC6220 (up to 1A, leaks 8uA)" so the voltage regulator leaks less than half of this cheap board. however if you power LED from it it draws much more anyway and if you need much less then the VDD pad could work (or GPIO pins).

OK, so I had to scratch it off. When it was there and D13 was pulled down it draw like 500uA, when pulled up it was still about 145uA (from 4.2V battery). When I scratched it off it still draw about 145uA when pulled up as before however when pulled down it turned off power to VCC pin and went down to normal 5uA idle when radio is not used. So the 140uA is the 3.3V voltage regulator when it is turned on. Which is not that great if you need to power something from 3.3V like the display. Does nice!nano have more efficient 3.3V regulator going to EXT_VCC pin? Anyway, nrf52840 can produce 3.3V (or 1.8V) by itself too when powered from VDDH (5v from usb or 4.2 from battery). And indeed the VDD pad near SWD gives 3.2V even if the regulator is turned off so maybe it could handle that low power display more efficiently.

So overall it is good board with that resistor scratched off. Also the antenna is as good as my other boards, better than watches like Magic3. It can find xiaomi thermometer advertising over coded phy behind several walls which Magic can't. And rssi for that thermometer is about the same as on my phone or 52840 dongle from same location.

interesting but that one is over usd50 for me, here it is possibly same one for half https://www.aliexpress.com/item/10050064­67962445.html
however I am afraid that if it can't be taken apart without damage it quite likely won't be updatable as the firmware updates are typically signed

yes, it is documented that scratching off some specific resistor near usb connector helps, it is 5K pull up to vcc by mistake but cpu can drive that pin too after the resistor is removed, have that cheap board too but did not test this yet. and the leak is when driving that pin low which turns off power to external stuff so if not used for anything it may be pulled high to prevent the leak(?)

Oh, missed this post completely. This is very nice. Love the dual display idea too :-)
nice!nano clones are quite cheap on aliexpress so good source of small 52840 boards with usb and lipo charging chip.

Few links
https://zmk.dev/ ZMK firmware - keyboard firmware for these boards, based on ZephyrOS so most likely not using SoftDevice for BLE.
https://github.com/joric/nrfmicro/wiki/A­lternatives - the SuperMini NRF52840 / Pro Micro is quite cheap on aliexpress

I was looking at it as a proof of concept how it could be done so if it works at least for P8 and some percentage of bangle apps work on top of it then the POC is done and we can learn from it how it can be done properly for real - still reshuffling and renaming stuff or even deciding what went completely wrong and should be done differently.

This is great effort and overall it looks good, thank you, please continue :-)

BTW there is also discord with espruino (and arduino and a bit of pinetime and waspos) smartwatch channels here https:// discord.gg/7vxUDFJN but it is pretty quiet nowadays and most activity is in the epaper/pricetag channels. that's where porting stuff to various nrf52 watches was discussed but nowadays there are not much news as most manufacturers moved to other chips and older watches are harder to get.

You're welcome. If it is still not enough then you may also add your own characteristic. since you already use custom code like

await client.start_notify(UUID_NORDIC_RX, uart_data_received)

then keeping standard console away from this and using same start_notify code just with your own one instead of UUID_NORDIC_RX (or even one of standardized ones for this) could make it a faster and you'd have it more under control as then from accelerometer event you would simply update the characteristics value directly with no nordic uart buffering or limitations.

how many packets in one connection interval can devices handle

just checked and we are sending only one packet per connection interval (?) here
https://github.com/espruino/Espruino/blo­b/master/targets/nrf5x/bluetooth.c#L981
there is a warning in comment above it, however it would be interesting to have the value tweakable, maybe most of the time in cases like this increasing the value would help and people can verify in their specific case how high they can go without breaking it

One more comment - If it gets stuck and disconnects I would guess the most probable case is that data is generated faster then it can be sent via BLE.

every console.log may trigger new BLE packet(s), typical BLE packet is 21 bytes, if your device running python can negotiate higher MTU then puck can send 50 bytes in one packet. How fast packets can be sent depends on connection interval https://www.espruino.com/Reference#l_NRF­_setConnectionInterval and how many packets in one connection interval can devices handle, some can do more than one, some can do only one packet per connection interval

I would try to

• use only one console.log - possibly more packets can be send in one interval or more data together can be sent in less packets (may or may not make a difference)
  
• minimize data (just array of numbers instead of complex json structures) - less packets
  
• make connection interval shorter (beware that smaller values drains battery more)
  
  

if it starts to slow down it can be issue on both sides, on puck side the data may be generated faster than can be sent or some idle mode kicks in. Ther is such mode for BLE connection (see setConnectionInterval linked above) but if data is sent all the time it should not be triggered, not sure if there is something for accelerometer too - possibly not, you can just set sensible rate here https://www.espruino.com/Reference#l_Puc­k_accelOn

BTW if the flow of data is steady and relatively fast the connection is indeed better than simple advertising

I tried a build of espruino_2v21.9 on p8 and magic, and it seems the inline display driver gets broken.

I have updated the code.js example at https://github.com/fanoush/ds-d6/tree/ma­ster/espruino/DFU/Magic3 and made fresh build of 2v21 for MAGIC3. Then I uploaded the example to internal flash and it works :-) I can see the .bootcde has atob() expanded and pretokenized fonts and the Inline C driver binary and it did not break it. Also same source still works with 2v10.

this one is ~8 if I clear cookies do not login

you can buy without login? I see the discount only for one piece and I need to login or register to buy

OK, I'll dig up my Magic3 and try. BTW they are quite cheap on aliexpress now. Here https://www.aliexpress.com/item/10050053­73233740.html it is for US$11.50 for me including VAT and free shipping. I couldn't resist (again) and got some more.

is bangle using 6.1.x too?

I don't think so. there is 6.0.0. when building full hex here https://github.com/espruino/Espruino/blo­b/master/make/family/NRF52.make#L42
unless you updated it there should be 6.0.0

maybe some delay between connecting and reading data could help, I think there is MTU negotiation running right after device is connected, but it is there too also even for SDK12