Most recent activity
-
Why are the battery volt limits for 0-100 between these 2 numbers?
Because analog input can take only up to 3.3v and battery is up to 4.2V so there must be some resistor divider to reduce voltage below 3.3V. Resistors were chosen 'randomly' by manufacturer for this design so no reason to multiply by 3.3. Across some fitness trackers I've seen the value varied a lot for each manufacturer/device model.
Was this code aimed for a more weared down battery?
individual resistor tolerancies can be even few % see e.g. https://www.electronics-tutorials.ws/resistor/res_2.html , can make some difference in the voltage divider for each device
-
The NRF object has both bluetooth and NFC functionality see header jswrap_bluetooth.h -
https://github.com/espruino/Espruino/blob/master/libs/bluetooth/jswrap_bluetooth.h#L88Maybe there could be some #ifdef to not include those NFC methods at all. In fact it is almost like that already and the methods are still there but empty, see
https://github.com/espruino/Espruino/blob/master/libs/bluetooth/jswrap_bluetooth.c#L2026
there is check forUSE_NFCmaking the method to do nothing. So not sure why not to remove whole method, I think in other cases methods are removed from same object based on build flags. -
unless you call g.clear() or clearRect for whole screen it is indeed strange to get whole screen. just note that with true parameter it still returns modified region bu then clears it so with next call you should get
undefined. The idea is that you call it with true if it is the last time you are interested in that region so next time it will be empty. you call it with false if you are just interested in current state but won't do any action (like sending it to display) so it is still modified -
With framebuffer in memory created by Graphics.createArrayBuffer the behaviour is that after resetting it returns
undefineduntil you draw something, which makes sense.With display this is used so that in g.flip() implementation you know which area is modified and must be send to the display.
-
Well then this would be not a bug but feature, you would need to set your preferred additional space to compensate for that font feature as e.g. without using accented letters the reserved space would be otherwise too big for you (on the top). This could be used both for handling '\n' in drawString automatically and could be read for g.clearRect when trying to clear area occupied by the text.
-
Well some settable line space setting would solve it as mentioned in first post? there is
https://www.espruino.com/Reference#l_Graphics_setFontAlign maybe this could remember line height/spacing preference too? -
well it uses customHeight here https://github.com/espruino/Espruino/blob/master/libs/graphics/jswrap_graphics.c#L1374 and it is read here https://github.com/espruino/Espruino/blob/master/libs/graphics/jswrap_graphics.c#L1322 and this call returns value 'scale' here https://github.com/espruino/Espruino/blob/master/libs/graphics/jswrap_graphics.c#L1280
so maybe the real issue is that the new font is now larger for same scale than before as mentioned here -
Looks like bug, there is now new vector font which is larger for same point size (e.g. size 26 now is similar to older size 30) so maybe some line pixel size constant was not updated somewhere in drawString code
-
I was tempted to get one to open up and find out
There are plenty of watches similar to this so the chance to get right one which is hackable is very low.
However this one looks like it does have NRF52832 according to https://www.ozbargain.com.au/node/548647 and https://www.bauhn.com.au/smart-watch-gps/ and there is manual https://www.bauhn.com.au/wp-content/uploads/2020/06/AFWGPS-0720-Smart-Watch-with-GPS-User-Guide-v12.5-OUTLINED.pdf which says the android app is called
Join Fit App https://play.google.com/store/apps/details?id=com.jion.fit , that is good beginning.
this is unrelated to this case, nothing is powered via resistor divider here, it is just input to analog pin