But instead it is a device-specific rollover. It’s relatively common for GPS receivers to handle the limited week counter by having a baked-in epoch that is more recent than the latest rollover, which gives them a nearly 20 year lifetime after that epoch instead of failing at the GPS rollover.
I think devices that need a longer life should keep track of the last seen timestamp, then they can detect a rollover. The device would keep a local rollover counter and just add 20 years per count. This should stay correct until that counter rolls over, or if the device is offline for >20 years.
If you’re going to use more space keep a rollover counter you may as well just add more bits to your timestamp field instead, since every bit doubles the amount of time that field can represent.
The GPS week counter is part of the signal GPS satellites send and is not easily changed by the manufacturer of receivers.
Of course, devices that accept CNAV now have a few extra bits to work with.
Better in some ways, worse in others.
Can still result in unexpected behavior if configuration memory is lost.
And if it ever accepts an invalid future time for whatever reason, it gets "stuck" in that failure state.
Truncate the current wall clock time to a 10 bit unsigned, then subtract the number reported by the device, and interpret the result as an unsigned 10 bit. That's the amount of time that has passed since the device emitted its timestamp. (Assuming at most one wraparound event.)