Command 01 Version Response

01 Version Response

This response is sent by the Pod to the two pairing commands (07 Assign ID and 03 Setup Pod) using during Pod startup and has two formats of different lengths for the two cases.

Shorter Command 07 Version Response

The 01 Version Response message with mlen of $15 is returned from the first pairing command 07 Command and has the following format:

OFF 1  2 3 4  5 6 7  8  9 10111213 14151617 18 19202122
01 LL MXMYMZ IXIYIZ ID 0J LLLLLLLL TTTTTTTT GS IIIIIIII

• 01 (1 byte) [0]: mtype value of 01 specifies the Version Response command
• LL (1 byte) [1]: mlen of $15 is this format (the 07 Command response)
• MXMYMZ (3 bytes) [2:4]: pod firmware version major.minor.interim (for PM 2.7.0 MX.MY.MZ = 02.07.00)
• IXIYIZ (3 bytes) [5:7]: pod interface firmware major.minor.interim (for PI 2.7.0 IX.IY.IZ = 02.07.00)
• ID (1 byte) [8]: Product ID, 02 for 2nd gen Omnipod (i.e., Eros)? (for PM 2.7.0 always 2)
• 0J (1 byte) [9]: Pod Progress State, typically 02 (but possibly 01) for this shorter response
• LLLLLLLL (4 bytes) [$A:$D]: Pod Lot
• TTTTTTTT (4 bytes) [$E:$11]: Pod TID
• GS (1 byte): [18]: bits ggssssss containing reported Pod radio information
  • gg: Pod's current receiver low gain, observed minimum gain is at 2 & observed maximum gain is at 0
  • ssssss: Pod's current Received Signal Strength Indicator (RSSI) value, observed maximum & minimum values of 61 & 8
• IIIIIIII (4 bytes) [19:22]: Pod address ID as given in the 07 Command

When pairing using a 433 MHz RileyLink it has been observed that when the reported RSSI value is too high or too low, there is a significant increase in odds of 01 Version Response packets being dropped which can potentially lead to pairing difficulties &/or pods that won't get their radio ID register properly initialized.

Example #1 for Command 07 response (mlen $15)

Taken from Pairing 03:

01 LL MXMYMZ IXIYIZ ID 0J LLLLLLLL TTTTTTTT GS IIIIIIII
01 15 020700 020700 02 02 0000a377 0003ab37 9f 1f00ee87

• LL = $15 (shorter response type for the 07 Command)
• PM = 2.7.0
• PI = 2.7.0
• ID = 2
• 0J = 2 (Reminder initialized Pod Progress State)
• Lot = $0000a377 = L41847
• TID = $0003ab37 = 240439
• GS = $9f: Receiver Low Gain = 2, RSSI = $1f (31)
• IIIIIIII = $1f00ee87 assigned Pod address ID

Example #2 for Command 07 response (mlen $15)

Taken from Pod setup with known Lot and TID:

01 LL MXMYMZ IXIYIZ ID 0J LLLLLLLL TTTTTTTT GS IIIIIIII
01 15 020700 020700 02 02 0000a640 00097c27 9c 1f08ced2

• LL = $15 (shorter response type for the 07 Command)
• PM = 2.7.0
• PI = 2.7.0
• ID = 2
• 0J = 2 (Reminder initialized Pod Progress State)
• Lot = $0000a640 = L42560
• TID = $00087c27 = 556071
• GS = $9c: Receiver Low Gain = 2, RSSI = $1c (28)
• IIIIIIII = $1f08ced2 assigned Pod address ID

Because this format 01 Response is used to reply to 07 Command that is used as the first step of activating a new Pod, the Pod progress byte 0J must be less than 03 (Pairing completed) for this format and except in rare cases will always be 02 (Reminder initialized).

Longer Command 03 Version Response

The 01 Version Response message with a mlen of $1b is returned from the Pod for the second pairing command 03 Command.

OFF 1  2 3  4  5  6  7  8  91011 121314 15 16 17181920 21222324 25262728
01 LL VVVV BR PR PP CP PL MXMYMZ IXIYIZ ID 0J LLLLLLLL TTTTTTTT IIIIIIII
01 1b 1388 10 08 34 0A 50 020700 020700 02 0J LLLLLLLL TTTTTTTT IIIIIIII (for PM 2.7.0)

• 01 (1 byte) [0]: mtype value of 01 specifies the Version Response command
• 1b (1 byte) [1]: mlen of $1b is this format (the 03 Command response)
• VVVV (2 bytes) [2:3]: Volume of pulse in micro-units per tenth pulse for U100 insulin (for PM 2.7.0 always $1388 -> 5000/100,000 = 0.05U per pulse)
• BR (1 byte) [4]: Basic pulse Rate in 125 mS per pulse (for PM 2.7.0 always $10 -> 16/8 = 2 seconds per pulse)
• PR (1 byte) [5]: Prime pulse Rate in 125 mS per pulse for Prime or Cannula Insertion Boluses (for PM 2.7.0 always $08 -> 8/8 = 1 second per pulse)
• PP (1 byte) [6]: # of Prime Pulses (for PM 2.7.0 always $34 -> 52 pulses x 0.05U/pulse = 2.6U priming bolus amount)
• CP (1 byte) [7]: # of Cannula insertion Pulses (for PM 2.7.0 always $0A -> 10 pulses x 0.05U/pulse = 0.5U cannula insertion bolus amount)
• PL (1 byte) [8]: # of hours maximum Pod Life (for PM 2.7.0 always $50 -> 80 hours)
• MXMYMZ (3 bytes) [9:11]: pod firmware version major.minor.interim (for PM 2.7.0 MX.MY.MZ = 02.07.00)
• IXIYIZ (3 bytes) [12:14]: pod interface firmware major.minor.interim (for PI 2.7.0 IX.IY.IZ = 02.07.00)
• ID (1 byte) [15]: Product ID, 02 for 2nd gen Omnipod (i.e., Eros)? (for PM 2.7.0 always 2)
• 0J (1 byte) [16]: Pod Progress State, should always be 03 for this response
• LLLLLLLL (4 bytes) [17:20]: Pod Lot
• TTTTTTTT (4 bytes) [21:24]: Pod TID
• IIIIIIII (4 bytes) [25:28]: assigned Pod address ID

Notes on the mlen $1b Values

The fixed 7-byte sequence ($13881008340a50 for pod firmware PM 2.7.0) in this longer format is now known to consist of six basic pod configuration constants. The PDM will reject pairing with a pod if it doesn't have an VVVV value of $1388 = 5000 (i.e., 0.05U per pulse for U100 insulin) and then uses the returned VVVV value in all resulting insulin delivery calculations. The PDM also uses the returned BR, PR, PP and CP values for insulin delivery calculations without any checking. If PL is > 72, the PDM will set the nominal pod life to 72 hours, otherwise the nominal pod life will be set to PL-1 hours.

The controlling DIY software can probably simply verify that the returned values match the expected constants since it's seems unlikely that there will be some future Eros pod with returning anything other than the fixed firmware values of $13881008340a50. In the most general case, the controlling DIY software should verify that pulse volume VVVV is the expected value of 5000 (i.e., 0.05U pulse size for U100 insulin) and then use the other returned values in place of using various hardcoded constant values in most places as per the PDM.

Example for Command 03 response (mlen $1b)

Taken from Pod setup with known Lot and TID:

01 LL VVVV BR PR PP CP PL MXMYMZ IXIYIZ ID 0J LLLLLLLL TTTTTTTT IIIIIIII
01 1b 1388 10 08 34 0a 50 020700 020700 02 03 0000a377 0003ab37 1f00ee87

• LL = $1b (longer response type for the 03 Command)
• VVVV = $1388 = pulse Volume of 5000 micro-units of U100 insulin per tenth pulse (i.e., 0.05U per pulse)
• BR = $10 = Basic pulse Rate of 16 eighth seconds per pulse = 2 seconds per pulse
• PR = $08 = Priming pulse Rate of 8 eighth seconds per pulse = 1 second per pulse for prime & cannula insertion boluses
• PP = $34 = 52 Prime Pulses needed, 52 * 0.05U/pulse = 2.6U prime bolus amount
• CP = $0a = 10 Cannula insertion Pulses needed, 10 * 0.05U/pulse = 0.50 cannula insertion bolus amount
• PL = $50 = 80 hours maximum Pod Life
• PM = 2.7.0
• PI = 2.7.0
• ID = 2
• 0J = 3 (Pairing completed Pod Progress State)
• Lot = $0000a377 = L41847
• TID = $0003ab37 = 240439
• IIIIIIII = $1f00ee87 Assigned Pod address ID

Because this $1b longer format 01 Response is used as a response to a 03 Command that is used as part of a fixed sequence when activating a new Pod, the Pod progress byte 0J should always be 03 (Pairing success) for this response format.

Observations on the Different Version Response Formats

The shorter mlen $15 format message is the response for the first pairing command 07 Command and fits in a single packet. This shorter format contains the GS byte with the pod's radio information which can be used to verify suitable communication quality by the PDM or other controlling software before proceeding with the second step of pairing.

The longer mlen $1b format message is the response for the second pairing command 03 Command. This longer format doesn't contain a GS byte, but has a 7-byte sequence of six basic Pod constants which makes the longer version response span a packet. The pod's radio configuration will not actually be fully completed until the after this longer response has been successfully acknowledged.