|From:||Ralph A. Schmid, dk5ras|
|Subject:||Re: [Discuss-gnuradio] New UHD seems to break a lot...|
|Date:||Mon, 20 Apr 2015 21:27:08 +0200|
Thanks for all the research - sound reasonable, now I know what is going wrong, great!
Regarding the TX gain, I was never able to see any nonlinearity from saturation, the amp seems to be way below the critical input level. The signal is 1a clean, no spurs and no excessive harmonics, no IM.
To close the loop on this thread, 3.8.3-RC1 has a bug in new code that automatically calculates master_clock_rates when they are not explicitly stated. This specifically affects B2x0 and E3x0 since they are AD9361 based with a very flexible master_clock_rate. In this case Ralph asked for a sample_rate of 9.142857 MHz and UHD erroneously forced a master_clock_rate of 8MHz. An explicit master_clcok_rate request (in this case for 9.142857MHz) works around the bug as shown (green without, yellow with): http://ianbuckley.net/ralph_spectrum.jpg. The master_clock_rate override does print a warning in the UHD log so you can see that this is happening:
The hardware does not support the requested TX sample rate:
Target sample rate: 9.142857 MSps
Actual sample rate: 8.000000 MSps
There is also another bug in RC1 that also prints incorrect warnings. Warnings of this form can currently be ignored until this is fixed should you know that you have actually set sensible sample_rates:
The requested decimation is odd; the user should expect CIC rolloff.
Select an even decimation to ensure that a halfband filter is enabled.
decimation = dsp_rate/samp_rate -> 37 = (9.142857 MHz)/(0.250000 MHz)
NOTE: Ralph, your flow graph used a TX gain of 99…this is way too high for the signal being driven to the USRP, you were driving the output amp into saturation.
On Apr 18, 2015, at 12:24 AM, "Ralph A. Schmid, dk5ras" <address@hidden> wrote:
Yes, I can confirm hash 2fe3..., and the images were downloaded with the supplied uhd_image_downloader, what is configured like this:
_DEFAULT_BASE_URL = "http://files.ettus.com/binaries/images/"
_AUTOGEN_IMAGES_FILENAME = "uhd-images_003.008.003-rc1.zip"
_AUTOGEN_IMAGES_CHECKSUM = "8522b02386f5fe0bb51baa3ba0001ef0"
The GRC filkes are accessible now, the only modifications I made were due to Ron Economos' hints regarding sampling rate, and I added a frequency slider to choose the correct European TV channel without having to know the frequency.
I'm not able to access either of the .grc files on your website, but using the original dvbt_tx_demo_8k flow graph from gr-dvbt, the spectrum I generate with 003.008.003-RC1 has a 3dB bandwidth of about ~7.5MHz the same as your uhd_master screen shot. I don't see the truncated bandwidth of your uhd_rc1 screenshot. http://ianbuckley.net/dvbt.jpg
Can you verify please that you have UHD at the current 003.008.003-RC1 tag position git hash 2fe319d9790c7ec0bcdb9582c4fea95f3fd809b9, and that the downloaded FPGA images are from: http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip
I'll need your exact flow graph if I'm to debug this anymore.
On Apr 17, 2015, at 11:48 AM, "Ralph A. Schmid, dk5ras" <address@hidden> wrote:
I have put it all here, flow graphs and screenshots of the flow graphs:
OK, here we go. The hotel TV was dvb-c only, so I had to do the tests
chosen dvb-t bandwidth is 8 MHz.
Adjusting the channel bandwidth in the uhd sink block from 0 to a
RC1, master seems to work.
It is a B210, but as a note, due to the up to now missing FPGA
is received without problems.
I will know more in about three hours.
|[Prev in Thread]||Current Thread||[Next in Thread]|