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

Use periodic messages on M10SPG #57

Open
wants to merge 21 commits into
base: main
Choose a base branch
from
Open

Use periodic messages on M10SPG #57

wants to merge 21 commits into from

Conversation

AngusJull
Copy link
Contributor

Periodic messages offer a number of benefits over regular polling

  • No time waiting for a response
  • Output of message as soon as they are available
  • Less busy reading
  • Easier to configure output of multiple message types

Also made a couple other changes

  • Added a context structure for the gps
  • Added a function for also sending a valset message to simplify using them
  • Removed the timeout for read, the sensor will attempt to read a message 10 times, evenly spaced, instead of checking the monotonic clock
  • Added a way to check if a message is of a certain type. The array of message headers will be useful for a polling interface in the future, if that's required.

Added configuration for the platform model, which will prevent gps data
from being discarded during flight, and increased the mesasurement rate
to roughly 3Hz
It seems that using the hypothetical limit on update rate for NAV-PVT
causes problems with messages after about 10 have been recieved. This
might be a problem with periodic/polled messages. Also fixed the config
key, and moved some definitions
Premade messages shouldn't be neccessary with a periodic messaging
system, and will just take up space
Filled in a couple functions and changed how valset works to better
support these functions
Added some todo messages for future changes, and updated the main
function to use the new periodic message interface
- Now sending and recieving a UBXFrame so information about lengths of
  messages and types are not lost upon return, also allows return error
  codes
- Using send_valset in the enable_periodic function, reducing duplicated
  code and adding an actual check to the configuration
- Updated the premade headers and added a way to check if a message is
  of a specified type, these headers may be useful for assembling a
  rarely polled message in the future
@AngusJull
Copy link
Contributor Author

Closes #45 - this is a good start on periodic message reception.

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

Successfully merging this pull request may close these issues.

1 participant