Most recent activity
-
I cleaned the whole board but nothing, same problem.
doing some calculations and tests I found that a 150 ohm resistor between the button pin and 3.3v solves the problem (it means that the pin is "short" to gnd with around 400 ohm); the problem is that it consumes about 6/7 mAh... too much...
I'll try cleaning the board again and maybe reflowing the chip with a hot air gun... -
always 0.09V
with pinMode(BTN, 'output'); it jumps to 2.7V
pinMode(BTN, 'input_pullup'); -> 0V
pinMode(BTN, 'input_pulldown'); -> 0.09V -
the pads on the PCB look a big dull (although that could just be lighting)
from another angle/light it is actually clean. I'll try to clean it anyway.
How old is the watch?
1 year
being pulled up to 3.3v via an internal pullup
this is the strange thing, reading the value between GND and the button pin with a tester I detect a voltage of only 0.09V (no it's not a typo)
There is a vanishingly small chance that the unpopulated component you found could be an optional pullup resistor
I look at this here: https://www.espruino.com/Bangle.js2+Technical, it seems that the component is also missing.
and in any case given the proximity it should be a component of the compass.you can effectively disable the button
yes, I've already tried, it works but I'm trying to understand if I can get it to work again without using the "tap" trick
-
does the board look corroded in any way?
nope, I'm attaching an image even if my smartphone sucks a bit...
I also disassembled the rear part and there are no signs of humidity or corrosion.the last time it worked, I used it in a cold environment but considering that it was always worn and under the jacket, I don't think it ever went below 10°C.
I only noticed one thing, in the part "circled" in red, there seems to be 2 soldering points but there is no component.
is it missing or is it correct like this? -
Sorry if I reopen an "old" post, but I have the exact same problem:
clock in bootloop because it detects the pressure of the BTN1.
since the button "seemed" stuck, I already opened the watch; only that even if you physically remove the button, the board detects it as pressed.
I then tested the button with a tester and it works fine.
what could I do? -
do you want to be able to handle/display messages without them even being stored on the device? Do you still want to be able to store some messages? Or do you not want to store any?
The more I think about this, the more I feel like we could have one messages library that all apps can interact with to add/remove messages. But we make sure that library can be implemented by any app that wants to (eg like sched or textinput)
that's exactly what I meant, move all the logic ( saving messages, managing music... ) to an app/library/... and move the GUI to a separate app (perhaps with an app type like for example "clock" )
to make everything more compatible I thought of using events, so as to be able to manage each app independently, but I see that we don't really like that idea.I believe this "library" should provide the basic methods which can then be used and configured by the user / by whoever will program the GUI.
for example I find it "wrong" that the pushMessage automatically saves the messages that arrive; I believe that the two things ( message management / message saving ) are 2 separate things and the library should give the possibility to use the two functions separately.
( PERSONAL OPINION: I find that the management of saves, views, etc via "handled"/"noMessageApp" is confusing and in the long run difficult to manage, maintain and document correctly; but I repeat it is a PERSONAL OPINION )
By having the event, we potentially end up in a situation where we have multiple apps storing the same message in different ways. And then if you delete the message on one app, it's not deleted in the other one.
however it could also be that different apps need to store different types of messages and therefore not centralize everything in a single list... mine are just hypotheses
For example right now we have require("textinput") - but textinput can be provided by any different keyboard app. Or require("sched") - we have a default scheduler, but any app can implement a new one. It's simple, it's fast, and efficient. I don't really see the issue with doing this for messages too.
this methodology for me has a "problem" (I'm not saying it's serious but more "annoying")
when you install the Android/IOS app, the messages app is also installed from the dependencies; at this point the user can also install the app he wants to view the messages which will overwrite the "messages" file by inserting his own code so that by calling require("messages") the custom app is called.
now in the custom "messages" file it is necessary to reimplement all the pushMessage,clearAll, getMessages, status, buzz, stopBuzz functions going to create a duplication of the code.
having overwritten the original "messages" you can't even recall the functionality of the other file.
(premise: I'm not sure about this point, I haven't done any tests) if the original "messages" app is updated, does it overwrite the "messages" file and therefore the custom app should be re-installed?
and even if you uninstall the "message" app, when the "Android/IOS" app is updated, for the dependencies the "message" app is also reinstalled (overwriting the files)?in theory, these problems could be solved (at least partially) by providing a specific type of app for displaying messages. (I saw that the "notify" type exists but from what I understand it's an "old" method for handling notifications, right? )
TL;DR;
- create a library with the common features -> yes, perhaps providing more functions but which allow greater customization
a way to split off the GUI parts to different apps/files
- it is already done automatically with the creation of the library
- the methodology of overwriting the "message" file (or any other file) -> I think it needs an improvement to work smoothly (I'm talking more about user experience)
PS: with @rigrig 's suggestion i implemented a message app which i'll ask for a PR.
I overwrote the require function to make everything work; I don't like it, but it would seem to work.
PPS:although nobody is yet to make a PR to actually just improve the standard message app :(
I think the problem is that everyone would like an ad-hoc app, and honestly I wouldn't want to touch the GUI/functionality of a program when others like it, I prefer to implement my own version.
But if there are shared choices and you need a helping hand, work permitting, I'm here :) - create a library with the common features -> yes, perhaps providing more functions but which allow greater customization
-
hello, i have the same problem with iconlaunch and rebble.
rebble I know it's a mess and should be fixed as suggested by @Ganblejs but,The fast loading won't work if the clock doesn't have widgets
does this mean that the fastload ( Bangle.showClock() ) will never work with full screen clocks?
and if so, how does the launcher know which load to use to avoid problems?sorry in advance if I misunderstood
sadly, nope.
I tried cleaning with alcohol and using a hot air rework station to try to re-solder the microcontroller; but the problem persists...
in the next few days I'll try the hot air again, I'll dare a little more with the heat, until it holds up.