Skip to content

Auto Restarts #180

@efidoman

Description

@efidoman

Support automatic restarts. Raw notes / requirements copied from gitter to here:

  • Restarts should be on day 7 for g5 and day 10 for g6.
  • Don't waste 3 days of a coded no-cal start.
  • Restarts should not use a code to restart.
  • Restarts should not happen while a user is in the process of starting a new sensor.
  • So, if you stop the sensor (or issue any NS or command line driven cgm control - start/stop/reset/ then auto-restart will be delayed by 3 hours.
  • Auto-restarts would be to restart immediately (w/o a code) within 30 minutes of when the transmitter reports it will reach the end of the session and a new sensor needs to be started. when the transmitter reports it needs calibration, it would automatically send a synthetic calibration based on the current unfiltered glucose reading and the LSR calibrations from before the last session of the same sensor ended.
  • There will need to be a minimum of 3 LSR-based calibration records for autostart to work.
  • if a new sensor is inserted, the user can simply start a new session with a code, and that wouldn't trigger any of the auto-restart or automatic first calibration behavior.
  • Question: Will auto restart be done by Logger or by xdrip-js?
  • The restart at 30 minutes before the end of a session will backdate the start/stop messages by 2 hours, thereby avoiding the 2 hour warmup period. A similar implementation has been done before (iOS in CGMBLEKit) and has been used sucessfully.
  • then, once the native algorithm has been restarted with a single calibration, leave it up to the user to enter real calibrations to get it to re-learn the slope and intercept. Until that happens, Logger will continue to use the last 8 calibrations (mostly from the last session on the same sensor) to calculate glucose (the current expired behavior).
  • Pick up real calibrations as they're entered, and add them to the LSR data, such that the LSR and native algorithms would gradually converge over the course of multiple calibrations.
  • the trick is to send both the stop and start commands during an active session.
  • Question, do we need a restart message in xdrip-js that does both the start/stop in the same 5 minute wake-up session?
  • the only potential downside to auto-restarts would be in the scenario where the user is pulling BGs into NS with the Share bridge, and the sensor session has an abnormal slope/intercept, such that the native algorithm's single point calibration becomes highly inaccurate when BG diverges significantly from the point at which it was calibrated. that's not an issue for Logger-uploaded BGs, as long as we use the expired behavior, because we have the full LSR data from the last sensor session. To mitigate that, Logger could refuse to calibrate an auto-restarted sensor if the slope/intercept is too abnormal, thereby forcing the loop to run off of Logger data until the user calibrates manually. Or do something smarter like wait to do the first calibration until BG is at the low or high end of the target range, depending on whether the slope/intercept is way higher or lower than normal, such that we ensure that if we end up looping on the incorrect single point calibrated data, we always err on the side of too little insulin rather than too much.
  • Another potential issue with auto-restarts is that I vaguely remember a discussion where it was suggested that Dexcom expects the raw readings to continue to settle down over a longer period than 2 hours - so they apply some kind of exponential correction for a number of hours afterwards. Since in our case we don't really have a new sensor that would result in a inaccurate reported drift. The Dexcom readings on a newly restarted sensor drift low (compared to BG actually being higher) over the first 2 days. Yes, very clearly shows up when doing staggered multiple receiver restarts on a G4. The correction is the problem. The correction is applied to handle the normal case of an actually new sensor bedding into tissue. When the sensor is actually 7d old, the corrections cause falsely low readings. The easiest fix is just to calibrate twice a day when it asks you to. If you fail to do that, you get slightly less insulin than you'd otherwise need, and BG runs a bit high. not a safety concern. There is one mitigation that we'd be doing: using LSR-based expired mode for Logger-reported glucose readings until we had a few calibrations.
  • stop/start/calibrate will all be done in one 5 minute interval. The sensor immediately goes into 2nd Calibration.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions