Hi,
Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more with
latest uhd. A quick check during lunch break showed, the produced output
is
not decodable any more. I will take a closer look this evening at home,
where I have more and better equipment.
Ralph.
On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
Hi,
Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more with
latest uhd. A quick check during lunch break showed, the produced output is
not decodable any more. I will take a closer look this evening at home,
where I have more and better equipment.
Ralph,
which device is this on?
Thanks,
Martin
It is a B210, but as a note, due to the up to now missing FPGA images I
used
003.008.003-RC1, not the latest master. Still I had no access to a
spectrum
and DVB-T analyzer, so I have no idea what is happening, I just can
confirm
that RF is transmitted, and the receiver doesn’t get a picture, while
with
the snapshot of the same VM before the upgrade is received without
problems.
I will know more in about three hours.
Ralph.
Thanks, Ralph. Just to clarify: When you say ‘New UHD’, do you mean
3.8.3-RC1, or latest master?
Martin
RC1, master seems to work.
Ralph.
master works, but RC1 does not? Huh, I’m confused now. Can you give some
detail on what’s going on, so we can try and reproduce this?
Thanks,
Martin
Due to a mistake I lost this copy of the VM yesterday 
I try to
reproduce
the issues this evening, I am traveling, so lots of time in the evening,
but
no test equipment. Hopefully the hotel TV set will do DVB-T 
Otherwise
it
will have to wait for the weekend…
Ralph.
OK, here we go. The hotel TV was dvb-c only, so I had to do the tests
back
at home.
I took my perfectly working Kubuntu 14.04 64 bit VM container together
with
my B210, made a copy and updated this one, first I made a git pull to
get
latest master, built it, rebuilt gnuradio, rebuilt gr-dvbt, updated the
FPGA
images, and everything still was fine. The chosen dvb-t bandwidth is 8
MHz.
Then I changed to 003_008_003_rc1, did the same procedure, fired up grc,
and
the signal was not decodable both with a dvb-t PC receiver and with an
dvb-x
analyzer. The analyzer saw the RF level, but no data, no constellation,
nothing, it looked to him like interference.
When you have a look at the two “uhd” screenshots here
http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then
you
will find that RC1 produces a somehow narrower signal, so it really
looks
something gets cut at the ends with all the filtering and DSP stuff.
Adjusting the channel bandwidth in the uhd sink block from 0 to a
sensible
value changes nothing.
Btw., the dvb-t2 package behaves identical.
Ralph.
Great Ralph, thats a big help. Can you send me your exact flow graph
used to generate these 2 plots off list please. I want to re run this
scenario and see your exact configuration.
Thanks
-Ian
I have put it all here, flow graphs and screenshots of the flow graphs:
http://dk5ras.dyndns.org/tmp/DVB/
This way we can keep it on the list without sending attachments.
They were taken from the VM container before all the upgrades were made,
but
I did not change anything when upgrading.
Ralph.
Ralph,
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.
-Ian
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 = “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 E.’ hints regarding sampling rate, and I added a frequency
slider
to choose the correct European TV channel without having to know the
frequency.
Ralph.
From: Ian B. [mailto:[email protected]]
Sent: Saturday, April 18, 2015 03:45
To: Ralph A. Schmid, dk5ras
Cc: ‘Martin B.’; [email protected]; ‘GNU Radio D.ion
List’
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot…
Ralph,
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.
-Ian
On Apr 17, 2015, at 11:48 AM, “Ralph A. Schmid, dk5ras”
[email protected]
wrote:
I have put it all here, flow graphs and screenshots of the flow graphs:
http://dk5ras.dyndns.org/tmp/DVB/
This way we can keep it on the list without sending attachments.
They were taken from the VM container before all the upgrades were made,
but
I did not change anything when upgrading.
Ralph.
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:
UHD Warning:
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:
UHD Warning:
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 99this is way too high
for the signal being driven to the USRP, you were driving the output amp
into saturation.
-Ian
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.
Ralph.
From: Ian B. [mailto:[email protected]]
Sent: Monday, April 20, 2015 20:05
To: Ralph A. Schmid, dk5ras
Cc: ‘Martin B.’; [email protected]; ‘GNU Radio D.ion
List’
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot…
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:
UHD Warning:
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:
UHD Warning:
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.
-Ian
On Apr 18, 2015, at 12:24 AM, “Ralph A. Schmid, dk5ras”
[email protected]
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/
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 E.’ hints regarding sampling rate, and I added a frequency
slider
to choose the correct European TV channel without having to know the
frequency.
Ralph.
From: Ian B. [mailto:ianb@ http://ionconcepts.com
ionconcepts.com]
Sent: Saturday, April 18, 2015 03:45
To: Ralph A. Schmid, dk5ras
Cc: ‘Martin B.’; mailto:[email protected]
[email protected]; ‘GNU Radio D.ion List’
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot…
Ralph,
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
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.
-Ian
On Apr 17, 2015, at 11:48 AM, “Ralph A. Schmid, dk5ras” <
mailto:[email protected] [email protected]> wrote:
I have put it all here, flow graphs and screenshots of the flow graphs:
http://dk5ras.dyndns.org/tmp/DVB/ http://dk5ras.dyndns.org/tmp/DVB/
This way we can keep it on the list without sending attachments.
They were taken from the VM container before all the upgrades were made,
but
I did not change anything when upgrading.
Ralph.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs