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

SDRAngel V3.7.8 has issue with Sampling Rate... #86

Closed
martywittrock opened this issue Oct 31, 2017 · 12 comments
Closed

SDRAngel V3.7.8 has issue with Sampling Rate... #86

martywittrock opened this issue Oct 31, 2017 · 12 comments

Comments

@martywittrock
Copy link

Edouard,

I tried the latest 3.7.8 SDRAngel and it seems to have lost the ability to have separate Source (receive) and Sink (transmit) sampling rate capability like was in 3.7.6-1. I'm having enormous problems setting up (for example) Source at 7.0MS/s and Sink at 3.5MS/s without the other being affected. I was adjusting the Source to 7.0MS/s and then went to Sink to adjust it to 3.5MS/s and came back to find the Source at 80MS/s..!! I adjusted the Source back to 7.0MS/s and then the Sink was at 0.875 MS/s. It seems they are coupled again - not independent like they were before, and I was depressed to see this. So I went back to 3.7.6-1 and everything was fine again.

Hope this helps...It was working SO WELL in 3.7.6-1, too...

73 de Marty, KN0CK

@texasyojimbo
Copy link

texasyojimbo commented Oct 31, 2017

This comment was full of derp and I'm removed it for brevity.

@texasyojimbo
Copy link

texasyojimbo commented Oct 31, 2017

I've confirmed with further experimentation that RX1 gets assigned to whichever source device tab has the LimeSDR device assigned (checkmark clicked) first under "Sampling devices control." As such order-of-operations is critical and perhaps not exactly clear from the documentation. I see it documented that there's a (smallish) number (0 or 1) in the top right hand corner. It's a bit easy to miss / not obvious what is going on the new user with regard to which channel is being used on the LimeSDR.

I can also confirm Marty's point regarding sampling rates. For example when I change samplle rate on T1 to 2 MHz, sample rate on R0 seems to change to 4MHz from 5MHz automatically. I also notice some weirdness relating to decimation settings...

@f4exb
Copy link
Owner

f4exb commented Oct 31, 2017

What you have to realize is that Rx and Tx sample rates are actually not independent due to hardware limitations. In the LMS7002M there is a single clock source for the DAC and the ADC. The hardware still allows for ADC and DAC sample rates to be related by a power of two that is DAC sample rate is twice the ADC or vice versa or they can be equal. The exact way this is done is not up to the client application this is all done in LimeSuite.

Whenever there is a change in sample rate or hardware decimation/interpolation on one side the other side will be affected and the new values are not calculated but obtained by calling the LimeSuite API. So whatever this is this should reflect the real rate and you should see what you actually get.

My code has not changed regarding the sampling rate and hardware decimation and interpolation algorithms between 3.7.6 and 3.7.8 the only change that can be related is that 3.7.8 is compiled with LimeSuite 17.10.0 while 3.7.6 was with 17.09.1

I am not going to stay stuck with LimeSuite 17.09.1 so the only way forward is to ask the Lime guys to enhance their interface although I vaguely remember that the ADC to DAC ratio can be configured in LimeSutie GUI so there could be a chance that there is some API function to guide the ratio calculations.

As a possible workaround you can set the ratio between hardware decimation and interpolation factors to more than 2 (i.e. 4, 8, ... at least 4) then the resulting host sample rates will be related by at least a factor of two since the ADC/DAC sample rates ratio is constrained to be 1 or 2 (or 1/2).

The other issue is not related and will be indeed followed on issue #52

@texasyojimbo
Copy link

It looks like 17.10.0 includes/relies upon the 2.11 gateware which makes some kind of change regarding sample rate on different channels. However I don't understand the change. Marty -- maybe we should ask MyriadRF?

@f4exb
Copy link
Owner

f4exb commented Oct 31, 2017

I upgraded to 2.11 gateware and it seem it works as it used to be with 3.7.6.
In detail:

  • Open and run the Rx on the first tab (Rx0) leave it at its default rate 5 MS/s and hardware decimation of 8
  • Open the Tx on the second tab (T1)
  • Set the hardware interpolation to 16. The DAC will be 80 MS/s while the ADC stays at 40 MS/s
  • Set Tx sample rate to 3.5 MS/s (3 MS/s then 3.5 MS/s)
  • The Rx is now at 7 MS/s

I have updated the release note of 3.7.8 to recommend a FW upgrade.

@f4exb
Copy link
Owner

f4exb commented Oct 31, 2017

I found the details on the ADC and DAC clock generation on page 17 here: http://www.limemicro.com/wp-content/uploads/2015/09/LMS7002M-Data-Sheet-v2.8.0.pdf
"There is a fixed divide by 4 within the ADC block hence clock division on the DAC side to provide more flexibility. There is a MUX to connect either Fpll, or Fpll/M to either ADC or DAC clocks. M is programmable and can be set to M = 1, 2, 4 or 8. ".

This is in fact much more complex because the CLKMUX can combine the paths between ADC and DAC in all possible ways. The only constant is that the divider by 4 is on the ADC branch.

In LimeSuite GUI this is controlled in the CLKGEN tab:

image

CLK_H is in fact Fpll and since it is connected to the ADC branch it passes through the fixed divider by 4 hence the ADC sample rate is 56 MS/s. The other branch passes through the programmable divider and here it divides by 4 and goes to the DAC so the DAC sample rate is also 56 MS/s. As you can see many combinations are possible.

@f4exb
Copy link
Owner

f4exb commented Nov 1, 2017

This is too complex to control the CLKMUX via the low level API so unless the Lime guys provide a high level API we will have to stay with the default behavior.

@martywittrock
Copy link
Author

martywittrock commented Nov 1, 2017

Edouard,

I reprogrammed my LimeSDR last night to the latest gateware and observed on 3.7.8 that it seems to run fine at 7MS/s for the Source (receive) but I cannot adjust the Sink (transmit) to half the value (3.5MS/s) without crashing SDRAngel now. They have to be the same sample rate. I used to be able to tune them independently in 3.7.6-1 and it worked wonderfully, but with the new gateware if I even try to set the transmit lower than 4MS/s SDRAngel will just crash. Also, I noticed that when I went to adjust the span of the SSB modulator for Sink, as I put my mouse on the control and clicked to move it SDRAngel crashed, too. I went back to 3.7.6-1 and tried the same thing and it didn't crash - I was able to adjust the span normally and it worked. So there's something with that, too.

Let me ask this - For the LimeSDR for both Sink and Source, what are the settings you use for Sampling, H, and S? I have been trying to set my Sampling to 7MS/s and H=16, S=64 in both Sink and Source. But if these are not the right values to use for SSB voice (and eventually data) then I would like to know what settings you use to get clear undistorted audio in SSB transmit in the HF band (try 3.970 MHz). I have found that if I run a Sample Rate of 7MS/s in Sink that the voice is intelligible, but it's kind of gravely (has some distortion in it). But when I ran (in 3.7.6-1) 3.5MS/s the voice quality was excellent - and this was when I was running Source at 7MS/s which works wonderfully, too. Now with both at the same Sampling Rate (7MS/s) Source sounds and operates excellent and Sink works, but the modulation isn't as clear as half the rate (3.5MS/s). If there's another way to get more clear audio in transmit with a different setting of H and S then please let me know and I'll try that.

Just my observations with 3.7.8 as of last night - but I'm certain in time this will all get sorted out.

73 de Marty, KN0CK

@f4exb
Copy link
Owner

f4exb commented Nov 1, 2017

Hello Marty,

it takes quite a bit of fiddling to get things the way you like since it is entirely up to LimeSuite to decide on the hardware factor and sample rate on one side when you change one of these on the other.

What worked for me (SDRangel 3.7.8 and Lime FW 2.11):

  • Select the Lime in the first Rx tab and set H: 8 and SR: 5 MS/s. Make sure the ADC rate is 40000 kS/s (displayed on the top left) else just exit and reopen and it will load these settings by default.
  • add a Tx tab and select the Lime on Tx this will be H:8 SR: 5 MS/s but the Rx changes to H:2 SR: 10 MS/s
  • on the Tx tab change SR to 3.5 MS/s. Then the Rx is changed to H:2 and SR: 14 MS/s
  • change the Rx SR to 7 MS/s. The Tx stays at 3.5 MS/s
  • at this point the ADC rate is 14 MS/s which may be a bit low. You can increase H: to 4 or 8 on Rx side and this will not change the SR of 3.5 MS/s on Tx

You can do this without starting the streaming. Once your all set you can go.

Note: the software factor S: is for decimation or interpolation in software and is truly independent. The voice plugins need a baseband sample rate of at least 48 kS/s to work right so you have to make sure that your software decimation or interpolation is not too high to make the value fall below this limit. At a factor of 64 this sets the SR limit at 3.072 MS/s.

Hope this helps,
Best regards, Edouard.

@f4exb
Copy link
Owner

f4exb commented Nov 2, 2017

In fact I am afraid the 3.7.8 binary for Windows was not compiled with 17.10.0 but still with 17.09.1

@martywittrock
Copy link
Author

I am pleased to report that with my LimeSDR firmware updated to the most recent release, Sampling rates set at 5.0 MS/s Source and Sink and keeping the same settings for H and S (H=64, S=16) both transmit and receive I'm finding that the operation with 3.8.0.7 to be REAL good and without any abnormalities observed thus far. Transmit is clear and clean and receive is very responsive. I have more testing to perform, but I have to say for what I see thus far this looks like a GREAT release. I will post if I have other observations, but this is probably an even better release than 3.7.6-1.

@f4exb
Copy link
Owner

f4exb commented Nov 8, 2017

Good news! So I think this can be closed now.

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

3 participants