Status Packets

Unpaired

When unpaired, the address fields appear to be set to 0xff:

158ms: ffffffffa3ffffffff040607041f01482b037f8d
457ms: ffffffffa3ffffffff040607041f01482b037f8d
756ms: ffffffffa3ffffffff040607041f01482b037f8d
1055ms: ffffffffa3ffffffff040607041f01482b037f8d
1353ms: ffffffffa3ffffffff040607041f01482b037f8d
1652ms: ffffffffa3ffffffff040607041f01482b037f8d
1951ms: ffffffffa3ffffffff040607041f01482b037f8d
2250ms: ffffffffa3ffffffff040607041f01482b037f8d
2549ms: ffffffffa3ffffffff040607041f01482b037f8d
2848ms: ffffffffa3ffffffff040607041f01482b037f8d
3146ms: ffffffffa3ffffffff040607041f01482b037f8d

Paired

When paired status packets appear as triplets. The first packet is from the PDM, the next one is from the POD, and the last is from the PDM.

1f01482bbf1f01482b30030e010002ef04
1f01482be01f01482b340a1d18002640000000abff835bb5
1f01482b411f01482bc9

==============
1f01482ba81f01482b08030e0100815b4f
1f01482be91f01482b0c0a1d180037c0000001d3ff83cf34
1f01482b4a1f01482b76

This one is interesting, because in the last packet the second address copy is all zeros. Did the PDM not hear the pod, and indicate so in the last packet (which seems like it might be a kind of ack)?

1f01482bb21f01482b04030e0100035ec0
(response from pod too loud)
1f01482b5400000000ea

Status packets from @dan:

1f02d5adb11f02d5ad0c030e010002bf48
1f02d5ad531f02d5ad27

==============
1f02d5ada91f02d5ad0c030e010002bf65
1f02d5ad4b1f02d5ad0c0489e2

Packets from @t1djoe

Status check, no temp basal running

1f0218c3b41f0218c310030e010002bdaa
1f0218c3f51f0218c3140a1d180184c000000743ff81f1fa
1f0218c3561f0218c3b8

1f0218c3a01f0218c334030e010080249c
1f0218c3e11f0218c3380a1d180187c000000767ff0003d2
1f0218c3421f0218c305

1f0218c3ac1f0218c318030e010001b378
1f0218c3ed1f0218c31c0a1d1802bc10250014f7ff003624
1f0218c34e0000000048

1f0218c3bd1f0218c300030e0100819593
1f0218c3fe1f0218c3040a1d9802c8401e00155bff006e6e
1f0218c35f0000000018

Status check, ACK pod at 39U

1f0218c3b61f0218c334030e010080249e
1f0218c3f71f0218c3380a1d9905aab83b083423180385cb 
1f0218c3b91f0218c33c030e0101032fd5 
1f0218c3b91f0218c33c030e0101032fd5
1f0218c3fa1f0218c30015021301000000000000000000000d030000000000008268c5
1f0218c35b000000009705d18e73a02c2d218013f3
1f0218c3bc1f0218c33c0711050a2e31d21001fcf7
1f0218c3bc1f0218c33c0711050a2e31d21001fcf7
1f0218c3fd1f0218c3000a1d9905aaf83b0034231880575
1f0218c35e000000007a