-
Notifications
You must be signed in to change notification settings - Fork 81
Add GSensord - not sure how to deal with checksums being optional #53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
It's really annoying that this vendor didn't follow the convention of prefixing proprietary message types with "P" talker id. |
Yeh that'd be nice. I thought about adding an api for adding other messages so it didn't require modifying the library for every vendor. But that still runs into the same question of handling the checksum. |
"nmea: sentence checksum mismatch [%s != %s]", checksum, checksumRaw) | ||
|
||
var checksumRaw string | ||
splice := strings.Split(raw[startIndex+1:], ChecksumSep) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use strings.SplitN and limit to 2 parts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed.
@adrianmo I'm ok with this, what do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are not checking that sentences contain the checksum anymore. E.g. the following sentence was invalid before, but it's accepted now.
$GPGSV,4,2,15,15,41,038,,18,45,328,19,20,60,095,34,21,54,261,14
I'm OK with adding sentences that do not contain a checksum, if their spec states so, but we should keep enforcing the checksum for those sentences that require it.
Maybe there should be a boolean field in the sentence struct to indicate whether or not the sentence type requires a checksum. What do you think @icholy?
) | ||
|
||
// GSensord represents measured g-loadings in the x, y and z axis. | ||
// http://aprs.gids.nl/nmea/#gsa |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This link is not pointing to the GSensord sentence spec, but to GSA. Can you update it and reference the GSensord spec?
}, | ||
} | ||
|
||
func TestGSensord(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add tests cases for other, non-valid, sentences? E.g. sending non-float values to x,y,z; more arguments than expected, including checksum...
"nmea: sentence checksum mismatch [%s != %s]", checksum, checksumRaw) | ||
|
||
var checksumRaw string | ||
splice := strings.Split(raw[startIndex+1:], ChecksumSep) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed.
return BaseSentence{}, fmt.Errorf( | ||
"nmea: sentence checksum mismatch [%s != %s]", checksum, checksumRaw) | ||
|
||
var checksumRaw string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we maintain and update the variable declaration block we had before? I find it more elegant?
@@ -87,6 +93,9 @@ func parseSentence(raw string) (BaseSentence, error) { | |||
|
|||
// parsePrefix takes the first field and splits it into a talker id and data type. | |||
func parsePrefix(s string) (string, string) { | |||
if s == TypeGSensord { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are adding a new, empty, prefix for Gsensord, we should add a test case for this.
@adrianmo it's just really annoying that this message type breaks all the conventions/rules. The more I think about it, the more I want to completely special-case it. I need to think about it more. edit: while we're at it, we could do the same for all "P" prefix messages and the vdo ones. |
Yeh I honestly didn't expect this to get merged in any way in it's current format. Edit: and if I'm honest I could have just checked if the message was prefixed with $GSENSORD before calling the library and handled it in code outside of the library. |
@freman this probably won't land as-is or soon. I'd recommend checking message prefixes in your code for the time being. I'm experimenting with different approaches which give the messages more control over how they are parsed. Once we find a good solution, this will need to be rebased against that. I encourage you to leave this PR open until that happens. |
@adrianmo that sounds fine to me. |
With the new const TypeGSensord = "GSENSORD"
type GSensord struct {
nmea.BaseSentence
X float64 // X-axis G value
Y float64 // Y-axis G value
Z float64 // Z-axis G valye
}
p := nmea.SentenceParser{
ParsePrefix: func(prefix string) (string, string, error) {
if prefix == TypeGSensord {
return "", prefix, nil
}
return nmea.ParsePrefix(prefix)
},
CheckCRC: func(s nmea.BaseSentence, fields string) error {
if s.Type == TypeGSensord {
return nil
}
return nmea.CheckCRC(s, fields)
},
CustomParsers: map[string]nmea.ParseFunc{
TypeGSensord: func(s nmea.BaseSentence) (nmea.Sentence, error) {
p := nmea.NewParser(s)
p.AssertType(TypeGSensord)
m := GSensord{
BaseSentence: s,
X: p.Float64(0, "x-axis g value"),
Y: p.Float64(1, "y-axis g value"),
Z: p.Float64(2, "z-axis g value"),
}
return m, p.Err()
},
},
}
m, _ := p.Parse("$GSENSORD,0.060,0.120,-0.180") |
NB: I don't actually expect you to merge this request, I've broken the handling of missing checksums.
I also think this might be a specific usecase and not a standards type issue.
Basically the Navman MIVUE dashcams add a $GSENSORD sentence that doesn't have checksums.
I did consider refactoring to make types checksum aware so they can complain if they're expecting a checksum or not, but I wasn't sure how you'd like to proceed.
Probably best to just leave it out entirely, or have an unexpected type handler, but then I could just do that with a substring match before parsing.
Sample data: