Open jeremyherbert opened 2 months ago
Is this something that would be adjusted during runtime? seems like a hardware configuration to me which is better implemented in the devicetree :)
I agree that it seems like a good fit for the devicetree, but unfortunately yes, it is something that I would need to adjust at runtime. In my case, the user can select which antenna they want to used based on the device location/installation method. It may also be the case that the device can try both antennae to see if one can get a better fix than the other.
We will need to enumerate the antennas, binding index 0 to a specific antenna, like 0=internal, 1=external0, ...
a dts schema like
gnss {
antennas {
internal@0 {
};
external@1 {
};
};
};
could work
Is your enhancement proposal related to a problem? Please describe. Some GNSS modules have the ability to switch between multiple antennas (internal vs external, etc). It would be good if the API supported a way to adjust and report back which antenna was used.
Describe the solution you'd like Change the
gnss_info struct
to something like:If a device only has a single antenna,
antenna_index
would always be set to 0. This data can be parsed by the GNSS callback.Add a function like:
To set which antenna is being used.
Describe alternatives you've considered An out of tree driver for this specific radio, but this still would require changes to the zephyr code anyway.
Additional context Example module is Quectel LC86G, which supports an internal antenna (mounted directly on the module) or an external antenna connected to a pin on the module. Setting the antenna type is done through a command like:
And the radio sends out regular messages like the following which contain the antenna selection status: