Search results for:

This seems to have got broken recently.
Setting log=2 is now displaying and logging (ie the both setting).
I have checked the settings app and bootupdate code and all seems well

SO wondering if this is a firmware change. I am currently on 2v17, it last worked on 2v16.x
Will have to try downgrading and a retest.

Worth raising an issue for it, then someone might fix it.

Nope!

Thought so. Will fix to be consistent

My App is available for test at:
https://hughbarney.github.io/BangleApps/?id=clkinfogps

Latest code at:
https://github.com/hughbarney/BangleApps/tree/master/apps/clkinfogps

upload as the assisted GPS page loaded?

No just a way of saving the fumbling about on the phone. I would still expect to have to go through the Bluetooth connection dialogue via the browser pop up. The key part for me is to skip finding the app and the selection dialog in the existing interface.

Does anyone know if it is possile to have a single link to the Assisted GPS App that would automatically
upload the gps hints ?

The app is here
https://banglejs.com/apps/?id=assistedgps

I am thinking of something like
https://banglejs.com/apps/?id=assistedgps&gps

That would enable me to put the URL on the desktop on my phone and avoid all that fumbling about to get the gps hints sent.

I dont use GadgetBridge consistantly so its not an option ATM.

Thanks for that, that worked.

I have been testing the next iteration.
I have noticed that after I have hada fix that after swiping out of the clock_info back to say the battery display that the GPS gets powered on again.

My question is:

  var timeout;   // is this the same variable as

        hide: function() {
          Bangle.setGPSPower(0,"clkinfo");
          Bangle.removeListener("GPS", onGPS);
          if (this.timeout) {
            clearTimeout(this.timeout);  /// <<<<  as the variable here ?
            this.timeout = undefined;
          }
          resetLastFix();
        }

I'm not 100% sure I understand how this.timeout gets defined in code at:

https://github.com/espruino/BangleApps/blob/master/apps/clock_info/lib.js
line 83

      hide : function() {
        Bangle.setHRMPower(0,"clkinfo");
        Bangle.removeListener("HRM", hrmUpdateHandler);
        if (this.timeout) {
          clearTimeout(this.timeout);
          this.timeout = undefined;   //////  where does timeout get declared, just seems to spring into existance
        }
        hrm = 0;
      },
    }

I'm working on a GPS clock_info. But have a few questions as I am not sure I have got the code right below.

GOAL: I am buiding a simple GPS clock_info that will show the OS map grid coordinates for use when walking. When you swipe to the gps clock info it turns on the GPS. The first time it gets a fix display the time value from the fix.time from the GPS. Once a fix is established turn off the GPS and then start a timer to turn it back on 3 minutes (I will probably choose 90 seconds later on). The goal is to be able to get a GPS fix every 3 mins or so. This is good enough when walking. As long as you have downloaded AGPS the time to first fix is a few minutes. After that it takes about 20 seconds from power to next fix providing the distance travelled is small (which it will be when on foot). In this way the battery drain of turning on the GPS is reduced to 20 seconds every 3 minutes. I have a library module that I made for GPStouch that will do the lat/lon to OS grid conversion. For now I am just displaying the lat/lon.

My code is below.

Problem is that while onGPS() is getting called the info.emit('redraw'); does not seem to result in a redraw. The only way to get an update is to tap the screen again, then it will update.

Would appreciate any feedback on the code as stuff with timers like this can go wrong.

(function () {
  var timeout;
  var last_fix;

  var resetLastFix = function() {
    last_fix = {
      fix: 0,
      alt: 0,
      lat: 0,
      lon: 0,
      speed: 0,
      time: 0,
      course: 0,
      satellites: 0
    };
  };
  
  var formatTime = function(now) {
    try {
      var fd = now.toUTCString().split(" ");
      return fd[4];
    } catch (e) {
      return "00:00:00";
    }
  };

  var onGPS = function(fix) {
    console.log(fix);
    last_fix.time = fix.time;

    // we got a fix
    if (fix.fix) {
      last_fix = fix;
      // cancel the timeout, if not already timed out
      if (this.timeout) {
	clearTimeout(timeout);
	this.timeout = undefined;
      }
      // power off the GPS
      Bangle.setGPSPower(0,"clkinfo");
      // power on the GPS again in 3 minutes
      timeout = setTimeout(function() {
	timeout = undefined;
	Bangle.setGPSPower(1,"clkinfo");
      }, 180000);
    }
    info.emit("redraw");
  };

  var gpsText = function() {
    if (last_fix === undefined)
      return '----- , -----';

    if (!last_fix.fix) 
      return formatTime(last_fix.time);
    
    // use basic lat,lon for now
    return last_fix.lat.toFixed(3) + ' , ' + last_fix.lon.toFixed(3);
  };
  
  var info = {
    name: "Gps",
    items: [
      {
        name: "gridref",
        get: function () { return ({
          text: gpsText()
        }); },
	run : function() {
          Bangle.setGPSPower(1,"clkinfo");
          /* turn off after 5 minutes, sooner if we get a fix */
          this.timeout = setTimeout(function() {
            this.timeout = undefined;
            Bangle.setGPSPower(0,"clkinfo");
          }, 300000);
	},
        show: function () {
          resetLastFix();
	  Bangle.on("GPS",onGPS);
	  this.run();
        },
        hide: function() {
          Bangle.setGPSPower(0,"clkinfo");
          Bangle.removeListener("GPS", onGPS);
          if (this.timeout) {
            clearTimeout(this.timeout);
            this.timeout = undefined;
          }
          resetLastFix();
        }
      }
    ]
  };

  return info;
});

what are your thoughts on the format?

I prefer 1:23 or 1:45:15 rather than 1m23s and 1h45m15s, I think its easier to read and : take up less pace than h, m or s. On the LCD watch space is at a premium for one of the quarter segments, if the string wont fit the font has to be halved in size, so that quite significant.

so health should ignore any modification of hrmmar.

But surely the point is to modify the heart rate detected by patching the code by installing the hrmmar app ?

I dont see much point of installing an app that is meant to improve the heart rate detection only to find that it only works under experimental situations. The whole heart rate measurement thing is a bit confusing right now with different apps all tweaking things differently.

I tried out the app and logged to the console as you suggested whilst sat on the sofa. I had been up and down the stairs a few times so my heart rate was around 80bpm. All the time I could see confidence = 0 the corrected bpm recorded in the logging was around 95-110, wheras the original value was actually closer to what it was ( I also used an AmazFit bip on the same wrist to check it).. So not improved but made worse. I could understand it not working well if I was actaully moving about a lot but I think the app is basically not working. I have attached the log.

I think I would count down the last 59 seconds, that would make more sense. But even if it counted down in seconds all the way - the power consumption is not going to be an issue bad for a 5 minute period. Most people will use a countdown timer for boiling eggs or a 5 minute break or something like that.

I probably wont meddle with this app and its quite inetgrated and there might be quite a few users who like it just the way it is.

Downloaded the file and uploaded via the IDE for a quick test.

I think if you are going to support tenths of a second then switch over after the first 60 seconds.
That way you have a stopwatch that can do tenths for the first minute. After that the accuracy does not matter so much relatively.

I thnk from a simplicity (less code, less chance of bugs etc) and a pragmatic point of view, tenth second accuracy on a watch like is not really a big deal. If you need to time someone doing a 100m sprint you would use a proper athletic stopwatch. Sometimes giving the user too many options kind of takes a way from the feel of the app and makes it less satisfying. Its all a matter of personal taste I guess, its your app at the end of the day so I think you have the right to choose how it works. It will still feel elegant whichever way you decide.

I wish you every success with this. These things are not for the feint hearted. Getting step counting to work kind of finished me off for trying anything too ambitious that required lots of testing.

It seems to redraw. I get T-5min, T-4min. T-3min, T-2min, T-1min. Seems a bit clunky. I dont think counting down in mm:ss and redrawing it once per second would be too high a cost in terms of battery life. I guess it depends if this is going to be your most frequently used feature.

I will see if I can find the thread you mention but not had a lot of success with the search facility in the past.

Jus tried it out. It does not quite work as I imagined. When using the clock_info all you see are options to add or subtract 5 minutes from the countdown timer. You dont actually get to see it counting down so never know how close you are.

Hi @bobrippling. I tried out v0.02 of clckinfostopw. Between 0-59 seconds the format is showing 1 decimal place ie 1.0, 2.0, 3.0 etc. Think you left the decimal point in, even though the interval period is now 1 second.

Thanks @bobrippling. Look forward to trying it out. Its a really neat clock_info. I'm thinking a countdown timer would be good as well. The count down would have to be a configurable value through a settings men with maybe options for 1,2,5,10, custom minutes.

I am wondering if having an update frequency of 100ms is wise for the stop watch clock_info.
I have 2 reasons for saying this.

1. The tenth of a second accuracy is only displayed for the first 60 seconds
   
2. I have noticed a difference in battery consumption.
   
   

I am now running tests but it looks like using simplest++ clock the battery drops (from 100%) to below 50% in 12 hours when running the stopwatch clock_info. Using the Lato clock (with same config) the battery drops to 10% in 12 hours. I am now repeating the tests with both watches fully charged to 100% and the stop watches started at the same time. Of course I will have to swop the watches round as the difference could be due to the watches. But conclusion is that 100ms refresh time uses a lot more battery power and that it seems to be more obvious with an app that uses a custom fonts.

Thanks for the work on this. Any reason the PR is still draft ? Do you know when the GB changes will get released ?

I noticed that the display on LCD clock when stopwatch clock_info is running is quite stuttering, freezing approx once every second (probably the main clock redraw).

Also after 60 seconds the format switches to 01m00s etc.
This makes the size of the text on the LCD clock almost unreadable.

I think the sub second part is overkill. If I wanted sub-second accuracy I would use a proper stopwatch that was ergonmically designed to be clicked easily etc.

the nmber format would be better as 0 to 59 for the first 59 seconds, then 1:01 to 1:59 to 59:59 to 1:00:00 etc etc. That way the h, m, s letters inside the format are not needed and the length of the string is kept short for situations like LCD clock.

I have done a PR.

Thanks for that.

I was just about to go and reset a test watch to factory defaults and try build a set of steps to reproduce when I connected the charging cable and I spotted a different icon had displayed. I can get it to show if I swipe sideaways after the tap.

The difference is that stopWatch clock_info has set its own menu to 'timer' when all the other so far have just used 'Bangle'.

Stopwatch:

return {
        name: "timer",
        img: img(),
        items: [
            {
                name: "stopw",

Calendar Clock Info:

  return {
    name: "Bangle",
    items: [
      { name : "Date",

```

Had a look at the PR and will test if you post a link to your personal loader.

I noticed that the key bit of code appears to be:

   if (h.confidence > 80 && Math.abs(Bangle.getHealthStatus().bpm - h.bpm) < 1) Bangle.setHRMPower(0, "health");

IE turn off the HRM power if confidence is greater than 80 we are not getting heart rate values different to the recorded value.

I wonder if the same change needs to be put into the clockInfo module ?

The reason I say this is that I did not realise that the heart rate clock info will only update once when it is displayed for the first time. Only if you tap it, will it update. OR it will get updated periodically without inter-action if you have the health app installed as that will wake up and measure your heart rate more often.

The confidence threshold level in the clock_info is greater than 60 will stop measuring. So this would make the very first reading displayed by the clock_info less accurate than subsequent events generated by the health app waking up the hrm. I appreciate in practice nobody will notice or care. This is just me trying to understand how the heart rate stuff works.

Even with this PR though - its not tackling the HRT accuracy beyond resting heart rate. There is still the issue of the the heart rate slowing down on movement. I did try the Artifact Removal app but not sure if I could see it working or not. The guy that wrote that app is non contactable.

https://banglejs.com/apps/?id=hrmmar

I'd be interested to know if anyone has a description of how to show that the artifact removal app works or not.

ok, understood. I'm not using the health app atm.

I read #718. I think maybe if a limit is placed on how much historiical data you can transfer was set to something sensible like 7,10 days then it could be made to work.

Got it, this would be very very for debugging. The hope would be that it would encourage more development as things were simpler and easier to debug.

That sounds great.

So would this mean you would be able to open a console when connected to the App loader ?
And therefore as the App Loader is integrated into GadgetBridge you would just then navigate to the console through the App Loader UI.

Recently I have been trying out Android + GadgetBridge again after giving up with it all a while back.

Things are much improved. Eg I can now see a battery chart that works and steps etc.

However I have realised that the way steps are being recorded on GadgetBridge is wrong in my opinion.
What seems to be happening is that the Bangle is generating a step event and sending it to the phone.
Therefore the only way this could ever be accurate would be if you carry your phone round in your pocket next to your Bangle all day so that every step event will also be captured by your phone. So if you happen to go for a short walk and not take your phone those 1150 steps taking the dog out will not be counted on the phone. So very quickly the step count on GadgetBridge is wrong.

How I think it should work is that the step event being sent to GadgetBridge should be the total steps value as recorded by the Bangle as Bangle.getHealthStatus("day").steps. The phone should not be attempting to count the step events but instead be taking the master total value from the Bangle.