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

Optimise GPS probe code - one message per family #5193

Open
fifieldt opened this issue Oct 31, 2024 · 3 comments
Open

Optimise GPS probe code - one message per family #5193

fifieldt opened this issue Oct 31, 2024 · 3 comments
Assignees
Labels
good first issue Good for newcomers help wanted Extra attention is needed low-priority Possibly something we'll consider in the future but doesn't serve the core use-cases or problematic

Comments

@fifieldt
Copy link
Contributor

fifieldt commented Oct 31, 2024

In the GPS probe code (

PROBE_SIMPLE("UC6580", "$PDTINFO", "UC6580", GNSS_MODEL_UC6580, 500);
), we write commands on the serial line and determine which GPS we have based on the result.

GPS units in the same family sometimes use the same command, but return different results (eg AG3335 and AG3332 both use $PAIR021*39). Currently we run the command once per GPS. Instead we should run each command only once per family, record the result, and select the GNSS MODEL based on the result.

This will mean probing takes a shorter time.

@fifieldt fifieldt added help wanted Extra attention is needed good first issue Good for newcomers low-priority Possibly something we'll consider in the future but doesn't serve the core use-cases or problematic labels Oct 31, 2024
@absolut3ego
Copy link

can you assign this to me?

@fifieldt
Copy link
Contributor Author

fifieldt commented Nov 3, 2024

Welcome to Meshtastic, we're happy to have you!

One way I thought about implementing this was to change the PROBE_SIMPLE macro.

At the end, save the command we sent as a variable (lastcmd = TOWRITE). Then, at the start, check if TOWRITE == lastcmd and perform the check of the buffer from last time there. Would require changing GPS::getACK so that it can handle returning the buffer or accepting a pointer to a buffer.

Let us know if you need any pointers!

@absolut3ego
Copy link

Hi @fifieldt,

I have a few questions. First, can you tell me how the PROBE_SIMPLE macro currently works? To make sure that my modification can work correctly with your project. Second, how do you want me to solve this issue? As I initially understood, I need to add something to store the results of each GPS family, so that I can call a family many times without having to re-execute the PROBE_SIMPLE macro. But according to your suggestion, I understand it in a different way, which is to save the last command. If the next command matches it, I will get the result that was just called to return. Can you explain this issue more clearly? I need to understand clearly to be able to have the correct solution.

absolut3ego added a commit to absolut3ego/firmware that referenced this issue Nov 4, 2024
thebentern added a commit to absolut3ego/firmware that referenced this issue Nov 4, 2024
jp-bennett added a commit to absolut3ego/firmware that referenced this issue Nov 13, 2024
fifieldt pushed a commit to absolut3ego/firmware that referenced this issue Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed low-priority Possibly something we'll consider in the future but doesn't serve the core use-cases or problematic
Projects
None yet
Development

No branches or pull requests

2 participants