If you look through the file you'll find A0A20000 34 which has a
valid payload. Other times there's an A0A200 34 and has a scrambled
payload. I'm not exactly sure how SiRFDemo is able to read the
data but it's there when the start sequence is A0A20000. If it
drops the last 00 then the packet is dead. I suppose SiRFDemo just
reads until the end sequence B0B3 and takes the packet.
Sounds like the actual problem, then, is that the device is emitting
garbled MID52 messages, but the vendor has failed to notice this
because SiRFDemo accepts the invalid packet. This would account for
the code failing to set the leap second correctly
I think the safest thing to do would be to document this as a known SiRF.
firmware bug. Can you identify the SiRF firmware version from the log?