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

Units for timestamp keyword on setFrequency() are inconsistent with the rest of SoapySDR #60

Open
wifimaker opened this issue Jan 3, 2024 · 0 comments

Comments

@wifimaker
Copy link

Calling bladeRF_SoapySDR::setFrequency() with a "timestamp" keyword argument currently requires the timestamp to be in units of "bladeRF ticks". The rest of SoapySDR uses units of nanoseconds. For consistency, I propose that the "timestamp" keyword argument should also be in nanoseconds. Timestamps returned by bladeRF_SoapySDR::readStream() are already in nanoseconds and having consistent units will allow timestamps from received buffers to be directly used when scheduling frequency changes.

Philosophically, an argument can also be made that Soapy should be hiding backend specific details from the user, so BladeRF specific units should be hidden.

The necessary change to the source is:

diff --git a/bladeRF_Settings.cpp b/bladeRF_Settings.cpp
index 3d06548..4f95ef1 100644
--- a/bladeRF_Settings.cpp
+++ b/bladeRF_Settings.cpp
@@ -490,6 +490,9 @@ void bladeRF_SoapySDR::setFrequency(const int direction, const size_t channel, c
 
         auto value = args.find("timestamp");
         long long timestamp = value == args.end() ? 0 : std::stoll(value->second);
+        if(timestamp != 0) {
+          timestamp = _timeNsToRxTicks(timestamp);
+        }
 
         retune(direction, channel, timestamp, quickTuneIter->second);
         return;

Checking against 0 is a convenience, in that allows "BLADERF_RETUNE_NOW" to still function. I'm not aware that SoapySDR has an equivalent function that BLADERF_RETUNE_NOW can be mapped to in order to hide this bladeRF specifity.

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

No branches or pull requests

1 participant