Skip to content
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

common.linear_map ValueError handling #40

Open
vesuvisian opened this issue Apr 24, 2021 · 1 comment
Open

common.linear_map ValueError handling #40

vesuvisian opened this issue Apr 24, 2021 · 1 comment

Comments

@vesuvisian
Copy link

vesuvisian commented Apr 24, 2021

I've got a bit of KLV metadata that I'm trying to parse, but I've run into an edge case that needs handled. Basically, since my sensor isn't actually flying, it's returning dummy data. For instance, it's first value is b'\x02\x08\x00\x00\x00\x00\x00\x00\x00\x00', which is a precision timestamp corresponding to the UTC epoch. That's fine, but when the parser gets to sensor latitude, the corresponding bytes are b'\x0D\x04\x80\x00\x00\x00'. That '\x80\x00\x00\x00' becomes an integer of -2147483648, which is outside the allowed domain of (-(2**31-1), 2**31-1). Providing such an extreme value is the sensor's way of signaling that it doesn't exist, but unfortunately this raises a generic ValueError (which was really difficult to trace down, requiring me to understand the code and go through it step by step). When such a domain error is encountered, I would propose that instead of raising a ValueError, the value is reported as None.

@vesuvisian
Copy link
Author

For reference, from the table on page 17 in the standard here:
Sensor Latitude. Based on WGS84 ellipsoid.
Map -(2^31-1)..(2^31-1) to +/-90.
Use -(2^31) as an "error" indicator.
-(2^31) = 0x80000000.
Resolution: ~42 nano degrees.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant