Skip to content

Honour advert location policy in builds without GPS - #3391

Open
jbrazio wants to merge 1 commit into
meshcore-dev:devfrom
jbrazio:fix/advert-data-no-gps
Open

jbrazio wants to merge 1 commit into
meshcore-dev:devfrom
jbrazio:fix/advert-data-no-gps

Conversation

@jbrazio

@jbrazio jbrazio commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

In buildAdvertData(), ADVERT_LOC_SHARE reads _sensors->node_lat and node_lon. Builds compiled without GPS never populate those, so a node set to share its location advertises coordinates 0,0.

Gates the function on ENV_INCLUDE_GPS like the rest of the GPS paths: builds without GPS honour ADVERT_LOC_NONE and otherwise fall back to the configured node_lat/node_lon.

buildAdvertData() read the sensed coordinates unconditionally, so in
builds with ENV_INCLUDE_GPS disabled ADVERT_LOC_SHARE advertised
0.0000/0.0000 (sensed coordinates are generally unavailable there,
and the CLI cannot select ADVERT_LOC_SHARE without GPS support).
Gate the sensor branch on the macro, keep honouring
ADVERT_LOC_NONE, and fall back to the configured position
otherwise.
@f3sty

f3sty commented Sep 10, 2026

Copy link
Copy Markdown

Builds without GPS prevent switching between ADVERT_LOC modes, i.e. you can set node_lat/node_lon but you can't get them to be included in adverts because the only way to set ADVERT_LOC_PREFS is via the gps advert command - which isn't available without GPS support.

I think a fix should not only set ADVERT_LOC_NONE if the stored coords are 0/0, but also provide a command to set ADVERT_LOC policy that is still available without GPS support. Otherwise the repeater can never advertise the coords set in prefs.

@oltaco oltaco left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be tidier to just guard the ADVERT_LOC_SHARE branch, unless I am missing something?

Comment thread src/helpers/CommonCLI.cpp
@@ -178,6 +179,16 @@ uint8_t CommonCLI::buildAdvertData(uint8_t node_type, uint8_t* app_data) {
AdvertDataBuilder builder(node_type, _prefs->node_name, _prefs->node_lat, _prefs->node_lon);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you dropped the else and moved the guard to here I think it would achieve the same outcome but you could drop the duplicated if (_prefs->advert_loc_policy == ADVERT_LOC_NONE) branch in the #else below?

@oltaco

oltaco commented Sep 14, 2026

Copy link
Copy Markdown
Member

Builds without GPS prevent switching between ADVERT_LOC modes, i.e. you can set node_lat/node_lon but you can't get them to be included in adverts because the only way to set ADVERT_LOC_PREFS is via the gps advert command - which isn't available without GPS support.

I think a fix should not only set ADVERT_LOC_NONE if the stored coords are 0/0, but also provide a command to set ADVERT_LOC policy that is still available without GPS support. Otherwise the repeater can never advertise the coords set in prefs.

@f3sty I think this is a separate but related issue, is there currently an issue open for it?

@oltaco

oltaco commented Sep 14, 2026

Copy link
Copy Markdown
Member

@jbrazio What do you think about changing this to use isGPSDetected() for the middle branch, gated on lat/lon != 0 so that the advert doesn't report 0 before a fix has acquired?

@jbrazio

jbrazio commented Sep 14, 2026

Copy link
Copy Markdown
Contributor Author

@oltaco I don't think those two are interchangeable.

isGPSDetected() answers a runtime question: is a GPS unit attached and talking. ENV_INCLUDE_GPS answers a compile-time one: is any GPS code in this binary at all.

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.

3 participants