CGM page decoding needs some enhancements and additional events

[tmecklem]

New cgm event discoveries from comparison with Excel dumps and decoding various example pages:

0x03 Sensor Calibration

• two bytes including opcode
• participates in relative offset like normal sgv event
• calibration type in other byte, decoded as:
• 0x00: meter_bg_now
• 0x01: waiting
• 0x02: cal_error

0x04 Sensor Packet

• two bytes including opcode
• participates in relative offset like normal sgv event
• packet type in other byte, decoded as:
• 0x02: init
• 0x??: pre_init (found in csv but no pages yet obtained with this)
• 0x??: burst (found in csv but no pages yet obtained with this)

0x05 Sensor Error

• two bytes including opcode
• participates in relative offset like normal sgv event
• error type in other byte, decoded as:
• 0x01: end

0x06 Sensor Data Low

• sgv of 40
• single byte event
• participates in relative offset like normal sgv event

0x07 “Fokko-07” - Sensor Data High

• sgv of 400
• two bytes including opcode
• other byte is unknown (perhaps raw sensor reading above 400?)
• participates in relative offset like normal sgv event

0x08 Sensor Timestamp

• 5 bytes including opcode
• Third timestamp byte (in page order) has timestamp type encoded in top bits (& 0b01100000), decoded as:
• 0b00100000: page_end - written as last event of every page
• 0b01000000: gap - written whenever there is a gap in the events that require a reference sensor timestamp value
• 0b00000000: last_rf - written whenever requested via rf command, such as carelink report data upload (this is important later in the algorithm changes)

0x0B Sensor Status

• 5 bytes including opcode
• Third timestamp byte (in page order) has status type encoded in top bits (& 0b01100000), decoded as:
• 0b00000000: off
• 0b00100000: on
• 0b01000000: lost

0x0D Sensor Sync

• 5 bytes including opcode
• Third timestamp byte (in page order) has sync type encoded in top bits (& 0b01100000), decoded as:
• 0b01100000: find
• 0b00100000: new
• 0b01000000: old

0x0E Cal BG For GH

• 6 bytes including opcode
• Third timestamp byte (in page order) has source type encoded in top bits (& 0b01100000), decoded as:
• 0b00000000: rf
• others not yet encountered

0x10 “10-Something”

• 8 bytes long including opcode (not 5 as in current decocare)
• other three bytes seem to always be 0x000001

0x11, 0x12 and 0x13 (aka "19-Something")

• have been observed but do not appear in csv dumps
• Perhaps sync bytes for the isig table?

Algorithms discoveries/changes needed:

• Sensor Timestamps (0x08) are the only events that serve as a reference for sensor events that follow the 5 minute offset pattern
• Sensor Timestamps serve as the reference point for events that precede them in time (current decocare algorithm offsets forward instead of backward)
• Events that should be offset 5 minutes iteratively:
• 0x02 sensor_weak_signal
• 0x03 sensor_calibration
• 0x04 sensor_packet
• 0x05 sensor_error
• 0x06 sensor_data_low
• 0x07 sensor_data_high
• >= 0x20 sensor_glucose_value
• When a good reference sensor timestamp is not available, pump command 0x28 will write a sensor timestamp to the current cgm page.

[tmecklem]

Two implementations that can serve as a reference for the requested changes:

Elixir

Implementation: https://github.com/tmecklem/ex_decocare/tree/master/lib

Test Suite: https://github.com/tmecklem/ex_decocare/tree/master/test

Swift

Implementation:

https://github.com/ps2/rileylink_ios/blob/dev/MinimedKit/GlucosePage.swift
https://github.com/ps2/rileylink_ios/tree/dev/MinimedKit/GlucoseEvents

Tests:

https://github.com/ps2/rileylink_ios/blob/dev/MinimedKitTests/GlucosePageTests.swift
https://github.com/ps2/rileylink_ios/tree/dev/MinimedKitTests/GlucoseEvents