Closed labomb closed 7 years ago
While it would certainly be useful to be able to detect when this functionality is supported by the tuner, it seems wise to only enable this when specifically instructed by the user to avoid sending current to an antenna that doesnt have an LNA :)
As for the RTL-SDR drivers I lose track of what functionality is available, and enabled by default, in the many forks... but hopefully the more dependant software which has support for Bias-T means greater justification for this to be pushed into the widely distributed version of this code...
That doesn't answer the question at all.
I am not aware of a means to programmatically detect the existence of the bias-t related calls in the driver, or a means to probe the hardware to determine if the bias-t capability exists. That's the reason I went the define route... the user has to be aware that they do indeed have the appropriate rtlsdr lib in place, and has to manually enable the define when building to get the support. The build will obviously fail if a user enables the define and does not have the appropriate lib in place.
The other scenario is when a user does have the appropriate lib with bias-t support and enables it while building, but occasionally uses a dongle without bias-t support. No harm no foul if they simply don't use the --enable-rtlsdr-biast switch. If they do use the switch in this scenario, I don't believe anything negative would happen (since there is no bias-t support in the dongle), but I can't be certain of that, certainly given all the hardware variations out there.
Ok, let's go with having to pass in the define via CPPFLAGS or whatever for now. It would be useful if the modified librtlsdr provided a #define in its headers directly to indicate that the bias-t functions were available.
Is there any way we can detect support for the bias-t functions without needing the user to provide a define?