Search results for:

Hi, sorry you've had so many issues. I'm pretty hopeful this isn't a storage issue though - generally if something really bad happens when you restart your Bangle it actually pops up a menu saying "Storage Corrupted" and puts you into the recovery mode - luckily this is very rare now!

I can't really comment on the Working Memory app, but it wouldn't surprise me if some of the apps on the app store do occasionally behave a bit strangely. But if you can figure out how to reproduce it, it'd be great if you could file a bug report so it can be fixed.

I'm not sure what the top "TS" item is

It's touchscreen. It'll be red until you tap the screen and it registers a tap in the correct area :)

Some sort of corruption where I needed to reset the bootloader

Were you playing around developing things with the Web IDE? Especially if you've been using other Espruino devices you may well have had it set to Flash, which overwrites the bootloader. We do mention this a bit in the getting started guides but it can be quite easy to miss, especially if you've used the IDE before.

factory reset but not communicating and displaying "-> Bluetooth" when it boots

Exactly as @fanoush says. Far from Bluetooth not working, this is almost certainly because one of your devices is automatically connecting to the Bangle, and since it can only have one Bluetooth connection active it's stopping the others from connecting.

Best bet is go outside away from your PCs/Laptops and just try and connect with your phone. If you can't connect, try going into your phone's OS Bluetooth settings and see if it's listed there, and if so forget it.

But most likely it's a PC/Laptop you have at home that's ended up with Bangle.js paired in the OS menu for some reason, so it's trying to automatically connect any time it sees it.

I'm not sure how well the casing/pins will response to attempts to clean up the old polish first with polish cleaner stuff...

Thanks for checking - yes, the pins should be ok but the case will melt with Acetone which is normally in nail varnish remover. Maybe your stuff will be better - but you could try first on a small patch under where a strap attaches so if it messes up something you'll never see it :)

Things like IPA (Isopropyl alcohol) will be totally fine, but won't soften the paint.

I think as long as you've cleaned the area with detergent to get any oils off, applying paint on the old paint would be ok if it really has worn away.

Wow, that is surprising. I imagine there's a via in there that actually makes the connection to the far side of the PCB. I guess that could have gone all the way though, but it's got to be maybe 0.8mm of copper that would have to have corroded away.

I hoe it stays this way :)

Please can you try and clean hers and then cover up that particular pin with a sticker or maybe a small dot of nail varnish? Just something to stop the corrosion - it's why we ship them with the sticker on the back.

You can change the linker file to get all the elf files to point to 0x00.. like this https://github.com/espruino/Espruino/blob/d6e543beec98b55cb4d00bed39cb9dab7fd53790/boards/NUCLEOF401RE.py#L51

But IIRC it's better having them 0-based because then the addresses only take up ~18 bits or so and are easier to store

i have the same issue...

You mean the screen works but you can't use the touchscreen? And you tried it in recovery mode and you still can't scroll, even after flattening and recharging the battery?

Glad it's working again, but 'a little water on the touchscreen' shouldn't have that effect - generally where we see water getting in it's because of complete submersion, or repeated, multi-day exposure to water splashing on it (like showering with it)

That's a real shame - I'm afraid I don't think there's much we can do from software. If you're up for a bit of a challenge you could try and remove the screen and take off/reseat the connector (and we have new screen + touchscreen assemblies) but the fact the battery was behaving strangely and then you had this seems like it's probably not a coincidence.

Of course it could be there was a problem with the touchscreen all along, and it was that which was draining the battery quickly...

Hi,

You should be able to see what changes have been made to the WIZnet library at https://github.com/espruino/Espruino/commits/master/libs/network/wiznet

The last w5500.c commit I see is Updated to Wiznet/ioLibrary_Driver 3.1.3 though - so if there are new libraries or patches it'd be great if you could do a PR with an update

Something like this? Assuming 10 LEDs in the first string:

var rgb = new Uint8ClampedArray(25*3);

 require("neopixel").write(B15, new Uint8Array(rgb.buffer, 0, 10*3));
 require("neopixel").write(other_pin, new Uint8Array(rgb.buffer, 10*3)); 

Huh, that's interesting in itself. It almost seems like the I2C error isn't coming from the touchscreen but the accelerometer.

Either way, with all that running (even though the while loop failed) it should run your battery down in ~5 hours or so.

I think UART are on 42/43 (P1.10,P1.11) which I'm pretty sure aren't analog? It's usually 2..5 + 28..31 and those don't seem on anything that's easily available: https://www.espruino.com/Bangle.js2+Technical

So you've got HRM_SDA/HRM_SCL/UARX/UATX - that's 4 pins?

I don't know of others I'm afraid, but you could always look at using an I2C or OneWire IO expander? You could glue a chip to the PCB and then wire from that to the pins.

OR if it's just for buttons, connect each button to one IO pin with a resistor to GND, then when you see the IO pin drop to GND in a setWatch, remove the watch, set the pin high and then lower it, and see how long it takes to hit 0 again, and the time taken will depend on the value of the resistor and hence the button.

Something like:

function buttonWatch() {
setWatch(function(a) {
  PIN.set();
  setWatch(function(b) {
    print(b.time - a.time);
    buttonWatch();
  }, PIN, { edge:"falling"});
  PIN.read();
}, PIN, { edge:"falling"});

buttonWatch();

If it works well enough then potentially you could even use 2^n resistor values so you can detect more than one button being held at a time

and then "uncaught error I2C", which fills the screen

Ok, thanks - that's interesting. So that means that the Bangle can't communicate with the Touchscreen IC, so either the chip has locked up, or the physical connection to it has become disconnected.

It's pretty rare that happens, but in the past I'm pretty sure someone reported this several years back and power cycling the watch did fix it...

but can't scroll or touch anything so can'r access the flatten battery option.

Ahh, sorry - yes, of course. Please can you connect with the Web IDE and paste the following into the left-hand side, that should have the same effect:

      Bangle.setLCDTimeout(0);
      Bangle.setLCDPower(1);
      Bangle.setLCDBrightness(1);
      if (Bangle.setGPSPower) Bangle.setGPSPower(1,"flat");
      if (Bangle.setHRMPower) Bangle.setHRMPower(1,"flat");
      if (Bangle.setCompassPower) Bangle.setCompassPower(1,"flat");
      if (Bangle.setBarometerPower) Bangle.setBarometerPower(1,"flat");
      setInterval(function() {
        var i=1000;while (i--);
      }, 1);

Hi - I'm not quite sure why you're compiling espruino_embedded.c ? That's not normally what we'd use on an ESP32 build...

Did you do anything with the watch between it working and not working? And does the screen look ok, or does it have different coloured patches on it? I guess it could be that if the battery had problems from being left those 3 years uncharged and then it swelled up, that might affect the touchscreen performance.

Please can you try long-pressing the button (~15 seconds) so it reboots, goes through the bootloader and boots back up into the recovery screen (you need to release the button as soon as you see the screen).

And does it scroll when you do that? That would help to discount the effect that any software might have.

You could also try going to Settings -> Utils -> Flatten Battery and leaving the battery to go completely flat, which would cause the touchscreen to have a full hardware reset, just in case it was something related to that.

So the answer appears to be: it's not supported, and the S3 fork is still young but might work.

Yes - there's a board file called ESP32S3_IDF4.py and if you build that then it should work - although you'd have to figure out how to access the screen/keyboard/etc directly from JS, but that's probably not the end of the world as it seems reasonably well documented

Well, I think they may add something later - right now they're just trying to make sure they get everyone happy with it as-is :)

It was a real shame about the Starfield watch - they actually did a bunch of improvements to the app and watch software, but Bethesda/Microsoft didn't want them to change anything after it had shipped (and MS published the app) so their hands were tied - but that's not the case with this one at least!

:) Yes, it's been great fun to work on. It's basically just a big toy.

Hopefully there'll be more stuff in the future - the more things this gets used for the more of a toolbox of useful things there will be for the next project. Right now we have AVI/WAV file decode and play for STM32, but those are built in only for PipBoy - but I imagine in future things like that will just get made into generic modules that anyone can use.

They have someone in-house doing a huge amount of the work who is amazingly clued up (you may well see a few commits from rblakesey). Often I'll get something going and then he'll work from there and get it working really smoothly with everything else, but things like the Radio I2C were done entirely by him.

edit: Dickens (the Starfield watch) was a pain because it used some fonts that weren't entirely open, so we could never include them in the main build, but for PipBoy you really can build your own firmware from the main repo.

I do occasionally see WARNING: No free GPIOTE for watch on a totally normal Bangle, so I wouldn't worry about it.

It's complaining about an issue setting a hardware watch with setWatch - but are you actually trying to do that, or are you just reading the pins with digitalRead?

It's possible that there is an issue with HRM_INT because the firmware may be inserting its own watch on that for the HRM at a lower level? It should still work as a GPIO though, and other pins should be able to be watched

That's a bit strange - not sure what to suggest to be honest. It could be the new strip is a different type and the timings are subtly different so they can't be chained.

On the WS2811 once the signal goes into the first led I believe it's reformed by it - so the issue probably can't be fixed by anything on the Espruino side (but maybe putting the new strip first would fix it?).

On the WiFi you should be able to use any SPIx_MOSI pin, so could you connect the second strip to its own pin?

It seems one or two people have started to notice, but this device:

• https://www.thewandcompany.com/fallout-pip-boy/
  
• https://www.youtube.com/watch?v=a9kQs6lUt0E
  
  
  

Is running Espruino - you can plug it in via USB, connect with https://www.espruino.com/ide and can start programming it!

This is 100% official - The Wand Co have been paying me to work on this for the past few months and much of the work I've done has made its way back into the normal firmware and everyone else's devices now as well.

If there's interest I can post up a bit of a quick 'getting started' guide - it's even possible to save apps in such a way that they're accessible from the Pip-Boy UI.

Does GB itself detect SMS and notify, and because I've enabled notifications from my SMS app I'm getting both?

Yes, I believe it does...

To track it down for sure, probably the best bet is in Gadgetbridge soon after you got an SMS, click on Debug then Fetch device Debug Logs

Connect your phone to a PC and set it to share storage, then look at the log file in Internal shared storage/Android/data/com.espruino.gadgetbridge.banglejs/files

In it you'll see some lines like SENDING GB({"t":"notify",...

And you should be able to see in those lines if you get two similar ones I think they'll have different src values that might help track down where they're coming from

There's no schematic, no. I believe the PCB is 4 layers so it's not easy to trace out!

Basically everything I know is in https://www.espruino.com/Bangle.js2+Tech­nical

But if you find a testpoint, all the pins we know are marked in that doc so you can just try toggling/reading the other pins and see if anything happens?

Is there some logging of the phone javascript side where this WebRTC part runs?

It should be about the same logging as in the IDE (IIRC it's the same code) so it's worth a try connecting by USB and using chrome://inspect-devices

... but you could try some other webrtc examples with your phone like https://peerjs.com/examples? If they fail there's not much I'll be able to do!

I think you need FILESYSTEM but not FLASHFS.

FLASHFS was added in https://github.com/espruino/Espruino/commit/a167bd3eeb3fcdd3667562a96e8a8aba44e68d93
to allow some of the flash memory to be used by turning it into a FatFS filesystem.

At the time the Storage module didn't handle multiple files well so @Wilberforce wanted wanted a way to expose it, but I believe doing so uses FatFS so it can't be used for other stuff (at least in the current implementation).

Personally I'd like to remove FLASHFS totally now. I don't know what others think but IMO it's a bit confusing having two different filesystems, one of which appears in the IDE one of which doesn't. For instance the second post on the forum right now is https://forum.espruino.com/conversations/400842/#comment17584054 where this exact thing has happened

We could remove FlashFS and change the partitions so we have a great big area for Storage - and because of the way Storage stores data it's all memory-mapped, so if you write something to it (for example an image) it can be used in Espruino straight from Flash without ever loading it into RAM.

Ok, cool. I've just gone from 2s -> 10s timeout so let's see if that helps