Added PR. I refrained from creating an enum for the signal ids. It looks like devices may send back proprietary values for older protocol versions. Also having the signal field behind a variable-length group, is kind of screwy. I hope the parsing logic makes sense.

NMEA in general and GSV in particular are really quite messed up. E.g. How do you know that you received ALL GSV messages for the cycle? And the signal id function as a key, too (Talker ID + Signal Id) with the added fun that the signal id may be null ...

Yep, in many places it's quite inconsistent and messed up with proprietary conventions. That's what I've always tried to hide and make easier for users in this library, but unfortunately it's not always that easy, given all those oddities. In other words, following the sentence structure 1:1 isn't always the feasible way when designing the sentence interface.

@ktuukkan By the way, I was thinking about the issue of the "reporting cycle". As there is no way to know where the message cycle ("transaction") starts or ends, GPSD does some profiling to determine a complete cycle across GPS devices. Did you ever consider implementing something like this in Marine API? I wonder if that would be a good add-on. It is crazy that this is not covered in the standard.

SatelliteInfoProvider collects a sequence of GSVs and delivers the data in a single event, but other than that I haven't given it much attention. Now that you meantioned it, the provider should probably be amended with signal ID as well, in any case. And while at it, maybe see if there's also something to improve?