Search results for:

@Gordon Just tried it on a Bangle.js and everything seems to work fine and can connect from that pre-release Web IDE.

Has it been deployed to the App Loader? Doing "Install Default Apps" seemed a hell of a lot faster than I remember.

This sounds amazing Gordon. Love everything in your list. Agree that Aruduio header should be left off by default but would like the ability to add header pins.

On the Pi front, one thing to watch out for is the orientation of the connector on the Pi 400. I've ended up using multiple adapters etc to get some screens and other devices pointing the "right" way around.

Also agree with Jean-Philippe on the IMU. I'm using a Pixl at the moment with an external one to pick up movement. Works fine, just messy.

On-Off switch for sure. But should totally turn off device even when connected to a charger (badge 2018 doesn't).

Would an RTC be an over-stretch? I have one soldered to one of my 2018 badges and it's dead handy, particularly if you restart the device a lot.

Are you thinking full USB on the nRF52840 or just charging?

Any thoughts on USB-C connector vs micro USB? The latest Blackpill boards and some of the RISC-V boards have moved over.

Lots of SPI Flash would be great. It's so handy on the Bangle.js

One simple thing is that any buttons should be chunkier/meatier than the tiny ones of the 2018 badge or the tack switches of the 2017 badge. Just from a user experience perspective. Also games :-)

Thanks, yeah I'll focus on the simpler things first. But the SC Control Point on footpods (and similar bike equipment) enables the watch/phone to adjust the calibration of the device.

@Gordon I think so, if it has caught other people out too. Anything that makes it more compatible with off the shelf products, that are impossible to debug on their end, is a good thing.

Of course, even tho the Garmin can now see the Pixl, it can't "connect". But the same is true of the ESP32/Arduino. I bet it's related to the SC Control Point which at least I can test on the Pixl side.

Oh you absolute legend @Gordon - That worked!! I'd never have figured it out. Was going around in circles over several weekends 🤦

Really looking forward to writing this project up over Christmas. Should have wrapped it up months ago.

No joy with temporarily stealing the Milestone's address or playing with connection interval.

I'm already advertising 0x1814 and NRF Connect sees the Pixl updating the speed and cadence. There just seems to be something in the output that is different between the Pixl.js and the ESP32/Milestone that the Garmin does not like. And there's unfortunately no way to debug built-in features in the Garmin. Whatever it is, Zwift on Android doesn't care about it and sees the Pixl as a footpod with no issue.

I went down a rabbit hole with the Milestone Pod as it alternates between advertising as a footpod and advertising as an iBeacon. I thought that was the difference. But the ESP32 Arduino code doesn't do that.

All three in screenshots. FootpodConor is the ESP32/Arduino device. MilestonePod 59 is the real commercial footpod. Pixl.js 8dfc is the only one that the Garmin doesn't see.

I think the Garmin is connecting to the devices, if not pairing, as it doesn't list them if they are connected in NRF Connect.

Thanks @Gordon - I've been on a process of elimination and Service Changed was the last major obvious difference to me.

I had been wondering about Connection interval.

I'll try setting the address to Public.

Pretty sure it isn't pairing at that point, since the Garmin never even lists the Espruino when I ask it to scan. But it always finds the Arduino device.

I've been working on a little project to emulate a BLE footpod on a Pixl.js and I've been using a Milestone Pod (now Zwift) to compare against. The Pixl.js works fine as a Running Speed and Cadence device (0x1814) with the Zwift App on Android but my Garmin watch refuses to recognise it as a footpod.

I had been trying to clone the Milestone's output just to see which characteristic/setting/value I'm missing but with no success. Yesterday however I found some dead-simple Arduino code for ESP32 doing the same thing as me. It worked instantly with the Garmin and it has none of the extra complexity of the Milestone's output.

The only major difference I can see between my Espruino output and the Arduino output (in NRF Connect) is that on Espruino the 0x1801 Generic Attribute Service shows as empty, whereas it has 0x2A05 Service Changed Characteristic and 0x2902 Client Characteristic Configuration on ESP32 Arduino.

I've tried doing:

0x1801: { // generic attribute service
            0x2a05: {
                indicate: true,
}
}

in setServices but it has no effect and the Service still shows as empty.

Is there any way to enable this directly in Espruino or is it one of those things that the underlying stack turns on in certain situations?

Fantastic news, welcome Christine!

Love this @PaulC!

@JumJum We ran into a lot of issues trying to train the model with data from more than one person. When we demoed what we were physically doing to the person who built the model, we all realised that e.g. "swipe left" was done completely differently by different people. So you end up with a poor model trying to recognise a wide variety of motions. It's actually much better and more accurate to train it with your specific movements.

Sweeeet!

@jumpbucker They are very very stiff. If it doesn't move pushing from one side, try from the other side. Just be careful not to slip and tear the rubber of the strap.

@PiOfThings 24mm won't work. It's actually quite a narrow gap once you remove the stock strap. My adapter gives you more space to work with.

You do have to be careful as they are very stiff initially, and if your implement slips, you may damage the rubber. But it's just a metal bar held in by friction, not a proper watch spring bar.

The Colab is the best place to start. For background you can read the blogpost by Andreas Madsen who built the TF models etc.

I am also doing a write up on how I added a simple new gesture to my watch and then wired it into a different Bluetooth HID app. Spoiler video here
:-)

Unfortunately I got distracted with building Espruino on Particle Xenon and never got back to looking at ANT+, sorry :-(

This is on my left wrist and rotating it. From face down to face up, quickly, I get a buzz. But any other angle rarely causes a buzz, no matter how fast/suddenly I rotate.

Would an analysis of Z help? Is it + or - 9.8 when facing up? Z graph seems very stable when facing up or facing down. So going from Z not near 9.8 to Z approx 9.8?

Seems even less responsive than the first one. Only buzzing on 1 in 4/5 attempts. Same 90 degree issue. No amount of snapping over 90 degrees causes it to buzz. Has to be ~180 degree turn.

It needs a fairly snappy rotation to get it to buzz on mine. Any sort of slower rotation doesn't work. And once it's face-up, you can't do a 90 degree flick-down/flick-up to get it to buzz, you have to do a full 180 again.

Would TensorFlow be an insane over-engineering in this case? :-D

App Store uploads remain unreliable

I did add CRC in the latest builds just in case - but could you check
the dev console and see if anything is reported? Maybe make another
post if there's anything. It's always been solid for me.

Awesome re CRC. I'm doing a few watches this week and will check. Several of us having the problem here. Usually when installing a bunch of apps in quick succession.

The lack of proper build numbers (because travis doesn't pull in the
full Git history for some reason) screws this up a bit. Right now I'm
still treating these as beta and trying to make sure I get things in a
good state for release more than I care about making people update
everything - realistically you'll only have to wait a few more weeks
and it'll stabilise though.

Yeah figured it would make more sense when everything stabilised.

Also, there's now an Install default apps button in the app loader,
which should help you out significantly with new watches.

Ooh I'll tell our intern! They'll be very happy to hear that.

HID

Just filed an issue for this:
https://github.com/espruino/Espruino/iss­ues/1752

I haven't been using it on mine so far so hadn't come across it as a
problem. If you can find a way to actually force a crash then it'd
make life a lot easier debugging.

For everyone it just randomly crashes the watch when HID enabled but doing nothing, and not connected, just walking around. They only know it has rebooted because clock has reset to 1970. So will be hard to replicate. Unless it's on a timer of some sort.

Thanks again.

Few things for me are:

1. App Store uploads remain unreliable. Particularly the Settings app for some reason. I think it the uploads should be checksummed in some way and rejected if the checksum fails.

2. I think there needs to be some sort of version compatibility check between the Apps and the Firmware. We've had a lot of issues with app changes (e.g. the appearance of Launcher) causing issues with older Firmwares. At this point we flash the firmware and the apps on exactly the same day just to be sure.

3. You have to delete and re-install an App in the appstore to reliably update it. That should be a one-step process.

4. We've had the same unreliable Bluetooth issue as reported above. We have to reset the watch multiple times a day if doing any sort of dev on it, as it just becomes invisible to the IDE. Far more than any previous Espruino device.

5. HID remains very unstable. Watch will crash at least once an hour with it enabled.

6. Grabbing the latest time off GPS on reboot is far preferable to leaving it on Jan 1 1970. As long as the GPS time isn't set to the year 2250 then it's likely to be reasonably correct. This should address the lack of an RTC for most people.

7. Power-off still seems to drain the battery. We've had multiple internal people get dead watches in the post after they were sent fully-charged and powered off.

   1. Agree with all of your items in the top post :-D
      
      

Still love it!

This is the code I use for an ESP32 with MAX7219. Relevant init code at the end.

https://github.com/conoro/im-on-a-call-ble/blob/master/light_esp32.js

@PiOfThings The most reliable setup for me remains Pi3 and Pi4. Still using abandonware/noble.

Just a word of warning that Noble is currently unmaintained and does not work with the most recent versions of Node.js.

This version works quite well on Mac and Linux: https://github.com/abandonware/noble (less so on Windows)

And this version still seems to be ok on Windows despite lack of updates: https://github.com/jasongin/noble-uwp

Just confirming that both Flappy Bird and Hypno Rings are working on the latest nightly build. Thanks again Gordon.