Category
Other
Hardware
Seeed Card Tracker T1000-E
Is this bug report about any UI component firmware like InkHUD or Meshtatic UI (MUI)?
Firmware Version
2.7.15.567b8ea
Description
According to the docs, one should be able to manually query the position of a cooperative node on a properly-configured secondary channel even if that node is configured to automatically periodically share location data on its primary channel. Precision is configurable on a per-channel basis, but the firmware is ignoring the precision setting on the channel in which the exchange occurs in favor of the precision setting on the primary channel.
(Do not conflate automatic location sharing with manual location sharing. The latter is performed by, for example, manually clicking to "Exchange Position" button on the node list, whereupon the sending radio generates and sends to the recipient a position packet including its own position and the 'want_response=true' flag, thereby requesting a response position packet.)
Here is the operative text from the Configuration Tips:
Sharing Location on a Private Secondary Channel
This is a newer feature that only works for firmware 2.7.1+
To share your location on a private secondary channel while keeping the default primary channel unencrypted, follow these steps:
Disable location sharing on the primary channel (Channel 0) to prevent broadcasting your position to all users.
Select a secondary channel where you want to share your location. Enable position sharing and choose your desired precision level.
Understand automatic location updates:
Only one channel receives your automatic, live location updates.
This is the lowest-indexed secondary channel (excluding Channel 0) with location sharing enabled.
If multiple secondary channels have location sharing enabled, only the one with the lowest index will receive automatic position broadcasts.
Channels with location sharing enabled but not receiving automatic broadcasts can still be used for manual position requests.
Example Scenario
Imagine you’re in the following channels:
Channel 0: “Everyone” (location OFF)
Channel 1: “CampChat” (location ON)
Channel 2: “Friends” (location ON)
Channel 3: “TutuTuesdayGroup” (location OFF)
How It Works
CampChat (Channel 1) receives your live, automatic location updates because it’s the lowest-indexed channel with location sharing enabled.
Friends (Channel 2) can request your location manually, but it won’t receive automatic updates.
TutuTuesdayGroup (Channel 3) allows chatting but does not share or receive location data.
To Reproduce:
- Radio A (remote):
Primary channel = public (PSK: AQ==), with position sharing enabled at 14-bit precision
Secondary channel = private1 (PSK: [legitimate_key_X]), with position sharing enabled at 32-bit precision
- Radio B (local): (channels reversed in order to ensure messages sent on private channel)
Primary channel = private1 (PSK: [legitimate_key_X])
Secondary channel = public (PSK: AQ==)
Using Radio B, initiate the position exchange via the private channel by clicking the "Exchange Position" button after selecting Radio A from Radio B's Nodes List.
Expected behavior: Response from Radio A with 32-bit-precision location data for Radio A, as the docs state.
Actual behavior: Response from Radio A with 14-bit-precision location data for Radio A.
I suspect this may be rooted in the semantics of the channel "number" seemingly sometimes having to do with the channel index, and other times having to do with the encryption context, but that's more of a WAG than a hypothesis.
Relevant log output
Category
Other
Hardware
Seeed Card Tracker T1000-E
Is this bug report about any UI component firmware like InkHUD or Meshtatic UI (MUI)?
Firmware Version
2.7.15.567b8ea
Description
According to the docs, one should be able to manually query the position of a cooperative node on a properly-configured secondary channel even if that node is configured to automatically periodically share location data on its primary channel. Precision is configurable on a per-channel basis, but the firmware is ignoring the precision setting on the channel in which the exchange occurs in favor of the precision setting on the primary channel.
(Do not conflate automatic location sharing with manual location sharing. The latter is performed by, for example, manually clicking to "Exchange Position" button on the node list, whereupon the sending radio generates and sends to the recipient a position packet including its own position and the 'want_response=true' flag, thereby requesting a response position packet.)
Here is the operative text from the Configuration Tips:
To Reproduce:
Primary channel = public (PSK: AQ==), with position sharing enabled at 14-bit precision
Secondary channel = private1 (PSK: [legitimate_key_X]), with position sharing enabled at 32-bit precision
Primary channel = private1 (PSK: [legitimate_key_X])
Secondary channel = public (PSK: AQ==)
Using Radio B, initiate the position exchange via the private channel by clicking the "Exchange Position" button after selecting Radio A from Radio B's Nodes List.
Expected behavior: Response from Radio A with 32-bit-precision location data for Radio A, as the docs state.
Actual behavior: Response from Radio A with 14-bit-precision location data for Radio A.
I suspect this may be rooted in the semantics of the channel "number" seemingly sometimes having to do with the channel index, and other times having to do with the encryption context, but that's more of a WAG than a hypothesis.
Relevant log output