GPS Recorder - track filename ? and potential issue

Posted on
Page
of 2
/ 2
Next
  • Hi Gordon,

    Do you know who maintains the GPS recorder App?

    First I want to send my congratluations on the UI that draws the track. See screenshot.
    Really great job. This app deserves a good README file with screenshots, I'm happy to make a start on one.

    Secondly I was trying to figure out the filename format for the track files. It seems they are meant to be of the format .gpsrcN where n appears to be 0,1...9,a,b.....z. I would like to add logging to the gpsservice widget and use the same format so that the track drawing feature can be used.

    I wonder if a different filename format would be more user friendly, could I suggest gpslog.nn.csv Perhaps it would be usefult to have some standard filename formats for Pedometer, Heart rate and GPS logs.

    Thirdly I encountered a problem when I tried to create a log. I set the track number to 1 and could not see a log file being created. Later on I discovered and odd looking filename and it clearly had gps log data in it. So I think there is some sort of defect here, if track 0 is skipped. (see screenshots).

    Could you put me in touch with the person that developed GPS recorder ?

    Thanks
    Hugh


    1 Attachment

    • thumbnail_IMG_20210121_234336.jpg
  • contents of odd file that seems to have been created by GPS recorder when I skipped track no 0.


    1 Attachment

    • Screenshot 2021-01-21 at 23.35.46.png
  • screenshot


    1 Attachment

    • Screenshot 2021-01-21 at 23.34.44.png
  • screenshot of log file number 0.


    1 Attachment

    • Screenshot 2021-01-21 at 23.36.07.png
  • You're definitely using an up to date Bangle.js version? Having GPS data as a filename looks like something overflowed. Writing to track 1 is something that definitely normally works as I've done it a bunch with the GPS recorder, so this must have been some kind of problem.

    Actually I may know what caused this. If you're writing to Storage and it runs out of space, it goes and compacts itself to move things around, properly remove deleted files, and free up space. Usually that's not an issue but if you had a StorageFile open during compaction (and it wasn't writing to that file that caused it) I bet it could still end up writing to the wrong address. Just created an issue for that here: https://github.com/espruino/Espruino/iss­ues/1970

    I'm the one who did the GPS Recorder, so I guess that makes me the maintainer. A README would be great.

    The track names could really do with being fixed to bring them more in line with other things - I just haven't changed them because I didn't want people to lose their saved GPS tracks. But yes they are just postfixed 0..9, a..z as you say. They just correspond to the number you choose - there's nothing fancy there.

    I guess the question is: Why do you want to duplicate what's in the GPS Recorder widget when you could just install the widget in addition to your gps service widget? I think they should both work side by side if you install them at the same time?

    It's already a bit of a mess that BangleRun records data using almost the same format but not quite, so we have a bunch of duplicate code there, especially for the interface.html.

    I guess if you had to record yourself, a better solution might be to create a library for track recording (as is done for the OpenStreetMap view) which could be used from anywhere?

  • So ideally I think the way this should work is that there is a configurable service widget and client Apps that provide the UI and presentation.

    There is an assumption in the GPSrecorder that you wil get a fix every second and you just count down the number of fixes and record the nth fix. This will no longer be true when using the gpsservice set for an update period of say 120s.

    Also I think the logging needs to be configurable, eg min_distance_before_log so that you have to move so many meters before you log a new point, otherwise you will end up with 26 points when you stop to look at the map for a couple of minutes. When logging a 10k mountain walk you really only want about 50-100 points at most, maybe 100m apart. The min time to wait before logging a next point also needs to be set and then log whatever comes first.

    Definitely agree duplicate code all over the place is not a good idea and dont want to make things worse. I will have to read the code for the openstreetmap library to understand how it works.

    I was thinking of using the same file format so that I could add logging and then use the GPSrecorder app to plot my logs.

    You say its possibe for 2 widegts to coexist ? Is this really true if both are setting up the GPS config differently ? Is it possible to have 2 widgets registered as callbacks for Bangle.on('GPS',onxxx) ?

    Thinking about this I have realised there are still a few issues with gpsservice that I need to address. 1) there needs to be a gps_set_settings(settings_object) so that any App can pass in a configuration. I am not sure yet if that would write the settings back to storage OR if calling that should cause the GPS to power on if the settings were changes to ON (i think better to keep turning on/off as seperate call). 2) the gps_power_off() needs to set everything back to SuperE power management (ie default) so that the next app that uses the GPS is not using an unexpected configuration. I will work on fixes for these issues next.

  • Good point about the recording when GPS fixes happen less often. Some changes/options for distance/time instead would be great.

    You say its possibe for 2 widegts to coexist ? Is this really true if both are setting up the GPS config differently ? Is it possible to have 2 widgets registered as callbacks for Bangle.on('GPS',onxxx) ?

    Yes, that should be fine. Obviously if they're both configuring the GPS you have an issue, but the GPS recorder doesn't do anything apart from turn GPS on so it'll be fine.

  • So I did the change to the gpsservice widget to return settings to SuperE. I'm now wondering if that was the right thing to do. Would it be better for GPSrecorder to turn on the GPS picking up whatever GPS settings have been stored for the gpsservice widget when it was last used. The other option is for GPSrecorder to power on the GPS through gpsservice.gps_power_on(). If we want GPSrecorder to just Power On the GPS then I will need to take out the small bit of code that does a reset to SuperE mode when gpsservice does a GPS power off. Hope that makes sense. Happy to go either way.

    The other question is: which widget do you see as being responsible for writing the fix to a log and checking that it is within the desired settings. Probably GPS recorder? If so the logging settings belong to the GPSrecorder as well. I have been thinking loggings needs 4 settings. logging ON/OFF, log threshold DISTANCE or TIME based, distance setting (needs a logorithmic options scale 1,2,5,10,20,50,100,200,500 meters), time setting (1,2,5,10,20,60,120,300,600 seconds). Obviously it will be up to the user to pick compatible GPS update times with the logging time.

    I might do some tests with both widgets being on, possibly taking out the count down code in GPSService and relying on the setting for update time in gpsservice. IE just make GPSrecorder log when it gets a fix (with fix.fix true).

  • Would it be better for GPSrecorder to turn on the GPS picking up whatever GPS settings have been stored for the gpsservice widget when it was last used.

    Yes, personally I'd have thought it was better to keep it simple:

    • GPS Recorder widget/app doing what it currently does, but with added distance/time settings.
    • A 'GPS Settings' app that you run once and configure with the settings for GPS that you want (as being as they get saved to the GPS module). It could include power save mode, but also maybe which of GPS/Glonass/Beidou you need and possibly other things later

    That way any app that uses GPS can benefit from the power saving modes. Maybe there will be some that don't deal well with getting lower update speeds, but they could be fixed.

    Or am I missing something about how this works?

  • So the GPS chip itself has some battery backed RAM. In order to get the power settings to stick you have to call UBX-CFG-SAVE(). For the Widgets to work together without interferring with each other I will need to comment out 1 line where I reset the GPS to SuperE mode on powerOff. This should mean the GPS settings, setup through the GPS Settings app (currently called GPS Service) will come into play everytime another app just calls Bangle.setGPSPower(1).

    We will probably have to remove the countDown / log frequency / code settings from the GPSRecorder. If you set the GPS update time to say 120s through the GPS Service app then that will effectively control how often you get a fix to log. That will work for most situations. Also will need to hide one of the Widget ICONS when both GPS Service AND GPS Recorder are running together. For example I could see a sitation where you want to see the grid reference or GPS information watch face AND have the GPS logging at the same time AND also maybe be switch to following a route at the same time. At the moment that would mean two GPS widget icons will appear.

    I will do some experiments, EG set things up on the GPS Service, set interval time to be 2mins, check that the recorder records every 120s or there abouts (as I say I will need to comment out the code in GPS recorder to ignore the value of 'Time Period' in its settings.

    I will post any proposed code changes here for discussion rather than do a pull request.

  • We will probably have to remove the countDown / log frequency / code settings from the GPSRecorder

    The countdown would definitely have to go - but if we just checked the time instead then I guess it wouldn't matter. Worst case you set the GPS to 120s and log rate to a shorter interval and you don't get as many log entries as you're expecting, but that's not too bad.

    I could see a sitation where you want to see the grid reference or GPS information watch face AND have the GPS logging at the same time AND also maybe be switch to following a route at the same time. At the moment that would mean two GPS widget icons will appear.

    So what do we need 'GPS Service' widget for?

    Once you set stuff up with a 'GPS Setup' app presumably that is in the GPS until the Bangle's battery runs totally flat. So it seems like a Grid Reference watch face would just use the existing Bangle.on('GPS',...) APIs and would have no need for the 'GPS Service' widget at all?

    Or am I missing something here?

  • So I am under the impression that the only way to have an App that will run in the background is to do it through a widget.

    GPSinfo: keeps the screen on and as soon as you switch out of the app the GPS will turn off. In SuperE mode it will draw 73mA all the time. The only way to exit the app is to do a BTN3 reset and then the GPS gets turned off. That might be fixable.

    GPSrecorder will only record while the GPS settings screen is displayed. Exit the app using the Back option, the GPS widget icon will stay on but there will be no more GPS fixes as the GPS is powered off. I have verified this by connecting up the Avo and looking at the current draw. At this point the screen is on drawing 36mA, when the screen times out it goes to 0.02mA (ie the GPS can't possibly be powered on). Switch the screen back on (using BTN1) and the current goes back up to 36mA, I would expect the current to be 73mA if the GPS and screen were on at the same time.

    At the moment the gpsservice widget / gps.face.js / osref.face.js app is the only combination (i have observed) that will allow: Switch the GPS on, switch to the gps.face (looks like GPS info but will switch out to other Apps) and see the number of satelites and the fixes come in, switch to the osref.face and I can see a grid reference. I can switch to as many apps as I like without the GPS being powered off as long as I dont do a BTN3 reload or a BTN1+BTN2 reset.

    The switching the GPS off behaviour in GPSrecorder might be down to the load(); that is executed when "Back" is selcted. Is there a way round that ? If that is down to load() then it means any other app calling load will effectively turn the GPS off as well.

       'View Tracks': viewTracks,
        '< Back': ()=>{load();}
      };
    
  • GPSrecorder will only record while the GPS settings screen is displayed.

    Ahh - that could be the issue. It's not the case at all - you turn on recording in the menu, then as long as your app/watch face displays widgets the GPSrecorder will record for you. Doing load() does turn GPS off momentarily, but it'll come back on as soon as the new app loads (and is usually very fast to get a fix again).

    Is it possible that you have something else installed (your GPS service?) that actually turns GPS off with setGPSPower, and that overwrites what GPS Recorder did? Or that you're using a clock that doesn't load widgets?

    I can switch to as many apps as I like without the GPS being powered off

    Yes, this is definitely a bonus of the multiclock. However there should be no reason why you can't just do what you're doing with the multiclock face, but using the GPS Recorder widget.

    Even though GPS will be powered off momentarily after running a 'GPS Settings' app, it should still remember all the power save settings?

    When new apps are loaded, everything is reset to power-on state (GPS, sensors, screen, etc). It's not ideal, but honestly it's the only way to make the watch reliable when we've got so many mostly unvetted apps and so little memory - even a tiny mistake in one app could cause a memory leak that made the watch unreliable.

    Potentially I could make the GPS turn off only 1 second after an app load (so if you switched apps and the new app used GPS too, it kept running). However as mentioned I personally found it was very quick (just a few seconds) to get a new fix after it was powered off/on.

  • Good point - it could be the GPS service App turning the GPS off after the load(); If the widget is reloaded it will look at the service setting and see that it was set to OFF. I will remove it from my watch and retest / rethink.

  • Cool, thanks! I'm actually looking at fixing the power issue properly soon with https://github.com/espruino/Espruino/iss­ues/1971

  • @Gordon - I'm working on a gpssetup app to replace the gpsservice widget. I am thinking I will need to have an ON/OFF setting so that I can manually switch on the GPS when needed for watch faces like osref.face and gps.face etc. Once it is possible to determine the power status of the GPS through a call to Bangle.getGPSPower() then that wont be necessary as each App will be able to decide if it needs to power it on or not. I noticed that you supressed switch off of GPS in the gpsservice widget if the widget thinks its already off etc.

  • I'm not sure a global power option is a good idea - surely if a watch face needs GPS it should just call Bangle.setGPSPower(1) to turn it on? There's no problem calling Bangle.setGPSPower(1) twice.

    For now, if you need to check for GPS, how about something like:

    var hasGPSData = false;
    Bangle.on('GPS',fix => {
      hasGPSData = true;
      // ...
    });
    setTimeout(function() {
      // if no GPS data in 2 seconds, turn it on
      if (!hasGPSData) Bangle.setGPSPower(1); 
    }, 2000);
    
  • I have written the code for the gpssetup App. But am finding that on exit of the settings menu (caling load()) the GPS power is turned back off. I installed firmware 2.08.160 so I can see if the GPS is on or not.

    I will try the solution for the above.

    However I am not yet convinced switching the GPS on / off all the time is a great idea. Imagine a collection of apps that work with the GPS, a waypoint setter, a route follower, a waypoint finder, a position display with lat/lon or grid ref, a route logger etc. With a handheld GPS you can switch between all of these screens without the GPS being turned off and on. If the GPS is powered off it then has to go through the satellite aquisition process again and that can take 30 seconds to 5 minutes depending on how long the GPS has been off.

    Does Bangle.setGPSPower(1) do nothing if the power is already on ?

  • on exit of the settings menu (caling load()) the GPS power is turned back off

    Yes, that's expected. I think I'd mentioned before about this in another post, but between apps everything gets returned to power-on state. The recent changes are there just to stop widgets calling Bangle.setGPSPower(0) and breaking other apps.

    However, I believe you're saving the GPS config? Even though it is saved to nonvolatile RAM on the GPS, turning the GPS 'off' shouldn't lose any of that state - it's more like 'standby' than 'off.'.

    I am not yet convinced switching the GPS on / off all the time is a great idea

    It's not ideal, that's for sure. I think I mentioned before but it's something that could be fixed with a firmware update later on - so I wouldn't try and add stuff to hack around it just yet.

    However once the GPS has a lock, if it's turned off for a few seconds I don't think it should take that long to reacquire. If you've got your low power 120s fix stuff added I doubt you'd even notice.

  • Few further developments / tests.

    1) Config not surving across power on/off: I built a 2nd version of the gps face for multiclock. I setup GPS for PMSOO mode with 120/6 second values. The GPS then powers off. However when it powers back on through a simple Bangle.setGPSPower() the settings dont seem to have stuck. I deleted the gpsservice widget in case of complications. This is the bit that I did not / but now have tested. The UBX-CFG-SAVE() seems to work if it is within the same session of the GPS being on. IE without out it, the GPS continues to run through a 1 sec high power cycle. So probably more work to do on the GPS config to ensure the setup survives a power cycle.

    2) gpssetup App code: I have the code for a gpssetup App, I will post it here. Would you want it as a pull request yet or shall I hang on until I have either succeeded to make the config survive or I am out of things to try ?

    3) Going to try a tiny widget to show GPS Power status - a bit like the BLE widget turns blue on connection. It will use getGPSPower() so wont work for others unless they have 208.160 firmware or above.

  • Hi,

    Thanks for that testing! That's very surprising - the UBX-CFG-CFG command you're using sure looks like it'd be doing the correct thing.

    1. Maybe leave it for now - if it turns out you don't have any success in a week or two then we can figure out what we're going to do.

    2. Ok, sounds good - but how about just responding to the Bangle.on('GPS' event? That'd work on all devices. Also bear in mind that I've now renamed getGPSPower to isGPSOn because it turns out I already has isLCDOn and wanted to keep everything looking the same.

  • It wil be back to the datasheet I think, and searching the internet for code snippets. I'll take a break for a few days as been doing lots of Bangle tinkering. Its very addictive ! Its the perfect device for tinkering with !

  • Hey - success ! I was wrong about the GPS settings not sticking across a Power Off /On.

    I had not used my GPS for a while so got fooled by the extra time it takes when it has completely lost track of satellites. So I think I have a working gpssetup App !

    At the moment I have an ON/OFF - just because I need a way of turning the GPS Power off BUT I can easily do that through any App. Shall I take the ON/OFF option out to do a pull request ?

    One question I have is that I want to display a message while the GPS is powered on , setup and then powered off. At the moment I just get a blank screen. Here is the code snippet.

        '< Back': ()=>{ exitSetup(); }
      };
    
      return E.showMenu(mainmenu);
    }
    
    function exitSetup() {
      log_debug("exitSetup()");
      if (settings_changed) {
        log_debug(settings);
        g.clear();
        g.setFontAlign(0,0);
        g.setColor(3);  
        g.setFontVector(25);
        g.drawString("Configuring GPS",120,120);
        wait(500);
        setupGPS();
        wait(500);
      }
      load();
    }
    
    loadSettings();
    showMainMenu();
    

    I am showing the back end of the menu setup. When you select Exit setupGPS() is called picking up the settings you have selected. Problem is I never see the message "Setting Up GSP". Do I need to trigger the call to setupGPS() through an interval timer say 10 ms after the call to g.drawString("Configuring GPS",120,120);

  • That's great!

    I want to display a message while the GPS is powered on , setup and then powered off.

    What is the wait function? If it's what I think it is, it's best to totally avoid those - if the function actually waits for 500ms, that stops Espruino from handling any data that comes in, which will probably cause buffer overflows.

    However if wait uses setTimeout then you'll find that the code drops through immediately and displays your message and then maybe clears it right after. I'd say what you really need is something like:

    function exitSetup() {
      log_debug("exitSetup()");
      if (settings_changed) {
        log_debug(settings);
        g.clear();
        g.setFontAlign(0,0);
        g.setColor(3);  
        g.setFontVector(25);
        g.drawString("Configuring GPS",120,120);
        setTimeout(function() {
          setupGPS();
          setTimeout(function() { load() }, 500);
       }, 500);
      } else load();
    }
    

    Also, just FYI but you can also just do E.showMessage("Configuring GPS") - it's a helper function for this sort of thing.

  • will try both methods.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

GPS Recorder - track filename ? and potential issue

Posted by Avatar for HughB @HughB

Actions