Avatar for Ivor

Ivor

Member since Jul 2021 • Last active Jun 2024
  • 2 conversations
  • 24 comments

Hacker and Ultrarunner...
Blog
Mastodon

Most recent activity

  • in Bangle.js
    Avatar for Ivor

    This is amazing! I've got a little project to refurbish some 'heritage' window fittings at the moment - modelling them on my 3d printer - and this looks like the perfect service to get them fabricated properly 👍 (also a little bit jealous of your mill) 😀

  • in Bangle.js
    Avatar for Ivor

    yeah, excellent info, basically "no" :)
    but also how do these 'alliances' create such hard to understand or follow specifications? is it on purpose to prevent people implementing them, or am I just not on the right wavelength?
    I recall wading through the mheg specifications ages ago trying to add support for part of it and it was similar pages and pages of disjointed statements.

  • in Bangle.js
    Avatar for Ivor

    I used running footpods from the days before 😱 wrist based gps and have spent way too long thinking about the subject and looking into it on various projects.
    (including one of my more recent projects building a GPS tracker where I spent some time looking at the distance calculation from GPS data)
    Basically you're right with your ideas about smoothing and responsiveness of stride monitors. There are actually cheaper footpods than the stryd that can be used too (from both garmin and suunto) although I think those are ANT+ only which isn't (natively) supported by the bangle firmware.
    If you look at the footpod profiles for ant (and bluetooth) it's pretty simple protocol and is just basically calculating and giving a "stride" count/length based on a fixed calibration. (the stryd has power and other metrics in addition) Earlier models of garmins etc used to have a calibration step you needed to define this where you'd run for a fixed distance and it would set a ratio. Although I believe there were some auto-calibration options in later garmin versions where it tried to calculate this value in reverse off the GPS data (I assume it detected a straight line for a period with quality GPS)
    Interestingly the earlier Garmin e.g. 310XT seemed to actually use that stride data to improve and smooth the GPS tracks it recorded (fellrunr did some tests showing this, also has good commentary and reviews about themin general - https://fellrnr.com/wiki/Footpod), but that seemed to be left to history as the watches improved and I expect they found other tricks to achieve that.

    The other problem with the GPS data was the "wobble" this has improved considerably in recent years with the different multi-band chipsets and the overall improvements in accuracy and consistency but can still be an issue where if you're measuring "second to second" whilst you'll get a smooth trace the actual points are actually slightly off by a small amount each second, so for the overall trace it's fine and smooth, but if you actually take the instant data and use that to calculate pace then it jumps back and forth due to the small distances on the calculations.
    You can smooth the GPS data to get a more accurate speed data but you need to take into account, as you say, whether the path is straight or "bendy" but it's basic trigonometry, the downside then is the lag you introduce into the returned data.
    (also where I was calculating distance taking into altitude and curvature of the earth I did worry about the extra calculations I was doing on battery life!)

    The lag is something you definitely notice on a Garmin (without footpod) so I agree re footpods giving more accurate speed data, I've always used them for instant pace data or sprint data, so yes I reckon you definitely could get a puck to calculate this.
    I'll try to see if I can find some of my old code to calculate this (albeit that was for TI340 based chip) it was just detecting the "hit" of the foot from the G sensor, then getting the max of the acceleration between that and the next "hit" and from that estimating the speed, would definitely be a fun puck project.

    • 4 comments
    • 234 views
  • in Projects
    Avatar for Ivor

    However it's quite a lot of work

    Yeah well, everyone needs a hobby. :D
    Definitely some interesting phone modules, albeit most of the breakout all-in-ones seem to be 2G only. So a custom board is probably the way to go, might have a play.

    not much better than a Nokia candybar phone

    Yeah I still use an ancient Sony dumbphone when I don't need connectivity, but I like the flexibility of the js runtime you've created with espruino which you'd still be missing on a candybar.
    Just thinking the hybrid of a flexible "bangle" style ecosystem on a handheld but with the added built in connectivity and obviously phone functionality might be fun.

  • in Projects
    Avatar for Ivor

    This is just pondering/thinking out loud....
    I've been going through a phase of really disliking pretty much any current/modern smartphone, and I had been looking and pondering alternatives and saw devices such as:
    https://www.thelightphone.com/ although as far as I can see that's still just an android phone under the skin, but stripped down, so still limited hacking ability.
    but seeing components like this: https://www.dfrobot.com/product-2323.htm­l made me wonder, could a reasonable hackable espruino driven phone be constructed with a small number of basic off the shelf components?
    (I had pondered the rak5010 for the guts since I'm very familiar with it, and it's got an impressive set of features, but looks like the BG9x only has VoLTE)

  • in Projects
    Avatar for Ivor

    Loving (and watching) this project, I actually have, and use one of the LitterRobots which is actually pretty good to use day-to-day, although I have been meaning to modify/work with the onboard control board at some point which could be better.
    having said that - I have a higher priority project to work on first which is to figure out the protocol for the SurePet cat flaps, since their software/setup is really lacking (aka dumb as a box of bricks).
    (even with "internet" control it needs DST manually updating, and loses all it's timing settings when you change the batteries🤦♂️)

  • in Bangle.js
    Avatar for Ivor

    Someone correct me if I'm wrong... but I believe what's happening here is that during the bootloader the bluetooth hardware is initialised before espruino starts to run, the fact that your other device had stored the bluetooth mac address means that it detects, recognises and shows up the device during this process. Then once it boots the bluetooth is disabled.
    This is how you can flash and update the device when it powers up/doesn't boot. I expect the bootloader code could be changed to not activate bluetooth at all, but would make it less user friendly if it needed to be bootable to be able to flash.
    I guess/expect that code could be added to set a permanent flag that the bootloader could read during initialisation (although I've not looked at the bootloader code), but again that would open the possibility of ending up with a non-flashable device.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Ivor

    I've not tried/done it from espruino... but in my nrf code the steps to get to DFU are:

    1. disable softdevice
    2. disable interrupts (NVIC->ICER & NVIC->ICPR [0&1] = 0xffffffff)
    3. write 0x57 into GPREGRET
    4. call NVIC_SystemReset()
  • in Bangle.js
    Avatar for Ivor

    Superb! and welcome!

    and it's quite weird to not have to reverse engineer a device for a change

    bah, but that's half the fun. 😉

Actions