Support Needed for G7 Extended Wear Sensors

[marionbarker]

Issue Description

Early reports are that the G7 extended wear sensors work with OS-AID apps but run into a problem when they hit the 10-day + 12-hour grace time that is hard coded into the G7SensorKit code.

Plan Forward

An update to the code is required but for people who are currently wearing these sensors, they run into this issue at 10.5 days wear time.

Emergency fix

Browser builders

View this link for instructions on customizations:

• https://loopkit.github.io/loopdocs/browser/edit-browser/#add-personal-customizations-to-build_loopyml

Insert this customization into build_loop.yml or build_trio.yml. Be sure to remove these lines later once the code is updated or it you return to 10.5 day wear sensors.

          # G7SensorKit Patch:
          # Emergency fix for users of 15-day G7 extended wear sensor:
          curl https://github.com/loopandlearn/G7SensorKit/commit/ac920ed738e2af2042a53f6fcb0ae9762e2cbab8.patch | git apply --directory=G7SensorKit -v --whitespace=fix

In this example link, you can see the build_loop.yml modification in place:

• docs-test/LoopWorkspace@17465a2

Mac-Xcode builders

If you change these 2 lines (65 and 66) of code in G7SensorKit/G7CGMManager/G7Sensor.swift you can extend the use of the sensors to 15.5 days

from

    public static let lifetime = TimeInterval(hours: 10 * 24)
    public static let warmupDuration = TimeInterval(minutes: 25)

to

    public static let lifetime = TimeInterval(hours: 15 * 24)
    public static let warmupDuration = TimeInterval(minutes: 60)

[marionbarker]

Proposal

The only time the sensor advertises the lifetime, warmupDuration and gracePeriod information is during the initial pairing with the Dexcom app. Because this time information is not available to Loop, I propose we add a 15-day enable/disable switch to the UI.

• The effect of the switch will modify the reported times in the Sensor screen and when the orange and red lines show up in the HUD for Loop.

Status Update

I transitioned from a 10-day sensor to a 15-day sensor 14-December-2025.

Before making the transition, I hard-coded the lifetime and warmup durations in G7SensorKit for my Loop build to the numbers appropriate for the 15-day sensor.

• The Loop suggested expiration time was incorrect (5 days too long) and the indicator that I was near expiration on the HUD vanished.

• Except for time being wrong for Loop, behavior was nominal.

• When the 10-day sensor hit 10.5 days, the Dexcom app indicated sensor was no longer reading and Loop stopped getting updates.

• After I paired to the 15-day sensor with the G7 app, Loop started scanning and picked up the new readings at the next cycle.

• The Loop reported expiration and grace period end times for Loop (almost) match the G7 Dexcom app value

  • Loop says 07:15, Dexcom says 07:16

[ps2]

Hmm, Loop often does hear the initial pairing messages, and I'm wondering if there are more ways to identify the version of the sensor in later messages. Since this value is mostly just used for display, a switch could be ok, as a last resort. It would be ideal to detect somehow, obviously.

[marionbarker]

I connected to Xcode debug logger for the entire transition from G7 10-day to G7 15-day.

20251214_2105_Xcode_Debug_G7_transition_10_to_15_day.txt.zip

I started the G7 15-day at 2025-12-14 07:15 PST and watched it with the receiver during the day.
Good agreement with the G7 10-day results.

The times in the table below are local, UTC -8.

Time	What
20:40:57	last reading from DXCMGB (78 mg/dL)
20:46	Critical alert from G7 app that sensor was no longer reading
20:53	Connect Dexcom G7 app to the new sensor
20:54	Dexcom app said 15-day sensor, tapped on pair
20:58	Pair request accepted first value on iPhone from DXCMPp (112 in Dexcom app) Loop switches to Searching for Sensor
21:03	Loop picked up the 15-day G7 (129 mg/dL)

I did notice a lot of backfill messages in the debug log at the transition.
I saw some Ignoring authentication response: lines in the debug log.

I also saw this:

CGMManager:G7CGMManager did update with error(G7SensorKit.AlgorithmError.unreliableState(expired))
Type: Notice | Timestamp: 2025-12-14 20:45:56.813165-08:00 | Process: Loop | Library: Loop.debug.dylib | Subsystem: com.loopkit.Loop | Category: DeviceDataManager | TID: 0x1be69

[gui-dos]

By using swift-section (https://github.com/MxIris-Reverse-Engineering/MachOSwiftSection) on the decrypted Dexcom G7 executable (https://decrypt.day/app/id1569432518) you can easily find out the layout of the response to the new 0x52 opcode:

class ExtendedVersionResponse: G7TxKit.TxResponse {
    let sessionLength: Swift.UInt32
    let warmupLength: Swift.UInt16
    let algorithmVersion: Swift.UInt32
    let hardwareVersion: Swift.UInt8
    let maxLifetimeDays: Swift.UInt16
}

I played a little sending the extended version command just after receiving the sensor status response 0x05 and I was usually getting the response well before the Dexcom app sent the disconnect opcode 0x09 (https://github.com/gui-dos/DiaBLE/blob/ffa04157ac027bd78f6728d3126f612b255ffa18/DiaBLE/DexcomG7.swift#L186-L188, https://github.com/gui-dos/DiaBLE/blob/ffa04157ac027bd78f6728d3126f612b255ffa18/DiaBLE/DexcomG7.swift#L443-L451)

I think that it will be really easy to schedule sending this command at the next connection if such extended structure has not been received before.

Notice that requesting to backfill the glucose data is also very simple. You only need to send just nine bytes: the opcode 0x59 and the 4-byte start and end timestamps.

In this case much more care should be taken however to avoid the official app sending the disconnect opcode in the meantime…