Packet decoding will need to account for pump model

[loudnate]

There are a lot of folks now with hardware that plan to talk to X22 pumps, which have about a dozen encoding differences across major packets. The most common one is when decoding insulin amounts, since the X22 and X23+ have different stroke sizes. However, there are other cases where bytes are in different offsets.

One approach that should work would be to create a family of PumpModel classes with an index by model string, and a family of Message classes to handle the decoding. MinimedPacket should continue to be agnostic to the intricacies of the message data and focus on RF encoding/decoding and validation.

Thoughts?

[ps2]

That makes sense; I have that separation (packet encoding vs message semantics) in the https://github.com/ps2/minimed_rf library as well, and I'd like to keep them roughly in sync.

[ps2]

One thing I'd like to do differently than minimed_rf, is to have the message classes be aware of the first 5 bytes. I plan to update minimed_rf message classes to be the same way

[ps2]

When separate message types have a common field type that is parsed in varying ways determined by pump model, then it makes sense for that decoding to be shared, and configurable by pump model. I would think that there is still a single message type that can handle the various pumps.

But I might not be understanding what's common and what varies completely. We'd need to discuss specifics, I think, to get the best layout. For now, I agree 100% on separating message semantics from the 4b6b encoding, crc calculation, and other rf packet details.

[ps2]

This issue was moved to ps2/rileylink_ios#1