I would start by modifying the library to print every character that it gets. Plus print the state. That would help answer the following questions...
1. After the GPS has emitted its first valid packet, does it keep sending more valid packets?
It may need a command or acknowledgement to send the next one.
2. Does the parser get stuck in a stable state? Stable is bad here. Any sequence of invalid characters should eventually get it back into the zero state that is looking for the start character.
3. Is there something between the packets like carriage-return putting it into that stable state?
4. Is it overruning any buffer and writing received characters to places it shouldn't?
I've never worked with that library but it does seem unlikely that it is so terrible that the parser gets stuck like that.
1. GPS transmits packets continuously. The length of the packet is up to 100 millis, I have 200 millis repetition time (5 Hz). Necessary messages are placed in the package even at a speed of 19200. Leave free time. I need to get only one of the five messages in the package. Separate messages are joined in a packet without intervals. There is no command to transfer, the transfer goes automatically and continuously.
2.
I think the parser works that way. Therefore, with a packet length of up to 240 bytes, everything is fine! More than 240 bytes, it does not get stuck, I think, it does not receive data from the Serial library at all, or it receives very rarely - once a minute.
3. No, first byte of next messages come.
4.No
Sample of packet with two messages:
12:54:28 R -> UBX NAV-DOP, Size 26, 'Dilution of Precision'
12:54:28 R -> UBX NAV-VELNED, Size 44, 'Velocity in WGS 84'
b5 62 01 04 12 00 f8 f1 ad 21 c0 00 a7 00 5e 00 µb....шс!А.§.^.
85 00 64 00 4b 00 43 00 0a 34 b5 62 01 12 24 00 ….d.K.C..4µb..$.
f8 f1 ad 21 07 00 00 00 05 00 00 00 fa ff ff ff шс!........ъяяя
0b 00 00 00 09 00 00 00 7a 26 25 00 64 00 00 00 ........z&%.d...
f2 84 2d 00 d1 ec