-
Notifications
You must be signed in to change notification settings - Fork 0
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
M10spg #22
Conversation
… not knowledgabe engough to properly know how to implement it by myself
…e knowledge to finish this on my own...
I beg to holier powers that this may work, and if it does not I will rewrite the entire thing in NMEA format as pennance |
The bus speed on the interface and integration manual is wrong, as stated in the data sheet, the maximum speed of the bus is 320k. This is not a siginificant performance hit, so its fine just to change the bus speed for all sensors
Kept m10spg files the same and modifications to main.c that were important, accepted other changes
- Rearranged the source file - Renamed many functions - Reworked how a user interacts with the sensor driver to be simpler and work with message queues/collectors - Add and rework docstrings
- Added new data types - Added a thread function that will read values from the m10spg and write them to the main thread message queue - Need continue implementing types, and consider the possibility of changing existing tag types
Missed in the merge, but will fix the git history later
Resolves #8. We'll need new issues for all the improvements that can be made to this work. I also expect we might need to talk about the data types again. Converting altitude to a float could be more agnostic of the sensor, but would hurt our performance on smaller processors for not much gain. I would prefer just to use mm and a unsigned integer, and maybe we can just be more careful about our math for the MS5611 and change that too. This also works better for the packager format, since it uses unsigned integers for GPS data. I think there's a decent amount of duplication the collector that could be fixed too. |
|
||
/** An enum representing the commands that can be used for polling m10spg data */ | ||
typedef enum { | ||
UBX_NAV_UTC, |
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.
Short command description would be nice on each enum member
|
||
/** A struct representing the UBX-NAV-TIMEUTC (UTC Time) payload */ | ||
typedef struct { | ||
uint32_t iTOW; |
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.
Picky but make sure all your struct members have a docstring.
usleep(RECV_SLEEP_TIME); | ||
// Get the time now | ||
clock_gettime(CLOCK_MONOTONIC, &stop); | ||
} while ((stop.tv_sec - start.tv_sec) < timeout); |
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 scares me but it's definitely the M10's fault lol.
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.
yuup. I think going to a periodic model would be better for this reason, we shouldn't need to wait for our response
init_valset_message(&msg, RAM_LAYER); | ||
uint8_t config_disabled = 0; | ||
// Disable NMEA output on I2C | ||
add_valset_item(&msg, (uint32_t)0x10720002, &config_disabled, UBX_TYPE_L); |
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.
I'd probably #define
these hex values.
Merging for now, added some review comments to work on while implementing more features though. |
Adds m10spg functionality (hopefully)