Jump to content
  • 0
Alexey

High Sample Rate Tuner Bandwidths

Question

Something must have changed in recent firmware update because now the API rejects the tuner change if the sample rate is more than 42. So, if I set the bandwidth to more than 37.8 MHz (acceptable value) then the calculated sample rate is more than 42 (unacceptable value) and WbtSystem.updateTunerSettings() returns false. Do I have to manually limit the sample rate from now on or is this a temporary development? Can I rely on getMaxBandwidth or rather hardcode it to 42?

API version is 2.4.6.13.

Share this post


Link to post
Share on other sites

5 answers to this question

Recommended Posts

  • 1

Some time in the past we added more sophisticated validation within WbtSystem::updateTunerSettings(). Prior to that, an out of range sample rate would simply be passed along and adjusted farther down the chain, returning true within the API. The issue was that WbtSystem::updateTunerSettings() is meant to return true only if exactly what is defined in the provided RadioSettings was applied to the system, and return false if any setting was invalid. As such, the returning of true for an out of range sample rate was unexpected behavior and was corrected.

There are plans in the near future to add more intelligent functions for handling Tuner settings that will allow for things such as automatic calculation of sample rate relative to bandwidth, but for the time being you will need to manually calculate your sample rate. It sounds like you're already on the right track in this regard. Using getMaxBandwidth is preferred, as not all systems are guaranteed to allow for a sample rate of 42. You can utilize WbtHelper::ClampFloat to restrict your sample rate in a convenient manner, passing getMinBandwidth, getMaxBandwidth, and your calculated sample rate to the function, and assigning the result back to your sample rate.

 

Share this post


Link to post
Share on other sites
  • 0

Thank you for this explanation!

Just one note: I asked about the reliability of getMinBandwidth/getMaxBandwidth because here http://forum.qrctech.com/topic/79-tuner-bandwidths-in-v24/ you said that their behavior will change:

What getMinBandwidth and getMaxBandwidth are actually returning is the min and max sample rates, rather than the bandwidths. This is a known issue that will be fixed in a future release.

So if I use these methods - at some point in the future the app might break and I need to watch out for this.

Share this post


Link to post
Share on other sites
  • 0

Apps should not experience any issues going into the future as a result of using these values. Because we do not allow bandwidths that are larger than the sample rate (for data integrity reasons), you can always be assured that the min and max values will be safe.

I would feel free to use it and not worry about getting (or the possibility of) out of range values.

Share this post


Link to post
Share on other sites
  • 0

I'm not worried about going out of range but rather about incorrect recording setup.

Imagine this: user enters the bandwidth value of 40 MHz, the app calculates the sample rate at 44.4 MS/s and clamps it to 42 using getMaxBandwidth and so the recording is started with BW=40, SR=42. If getMaxBandwidth will change and return an actual bandwidth limit (40 MHz) then the recording will start with BW=40 and SR=40 which is not 100% good.

Anyway, it's not that big of an issue and the app can easily be fixed in the future. Thanks for the support!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×