Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. uhd_rx.cpp (Venkatesh Sandilya)
2. Re: Sychnronize two USRP X310 with GPS (Hartmann, Simon)
3. Fwd: overrun 'o' from USRP B210 (altaf sk)
4. Re: Fwd: overrun 'o' from USRP B210 (Marcus D. Leech)
5. Re: uhd_rx.cpp (Ian Buckley)
6. Re: overrun 'o' from USRP B210 (Ian Buckley)
7. Re: Zeros are not zero? (Jim Hunziker)
8. Re: Zeros are not zero? (Michael West)
9. Re: Zeros are not zero? (Michael West)
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 Dec 2014 12:22:26 -0500
From: Venkatesh Sandilya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] uhd_rx.cpp
Message-ID:
<CAGNcrNL984NQZ9rL4pNKAR1vT-=PhbBWx8zX6Am=9cyripj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello
I have gnuradio 3.7.2.1 and uhd installed on my Linux machine. Is there a
uhd_rx.cpp? If yes, can someone please tell me where it is?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141223/1dde31af/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 21 Dec 2014 21:16:26 +0100
From: "Hartmann, Simon" <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Sychnronize two USRP X310 with GPS
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Ian,
thanks for your answer. Regarding your questions some more information about
the setup:
We updated the UHD and FPGA images before starting the measurements. Both usrps
were powered up at least one hour before we started the measurements.
Unfortunately we had only the possibility to set the GPS antennas on the window
sill.
We know it's not the best solution to have them close to the building. But we
couldn't test it in a free field yet.
Are there some past experience with the influence of the antenna position on
the GPS sync?
To determine the sync we connected both usrps with the same frequency generator
and turned it on and off during the measurement.
If the urps are synchronized, the measurement data should show the activation
or deactivation of the frequency generator at the same point in time.
In future it is planned to have the usrps at 2 remote locations, for the sync
measurements they were placed at the same location.
Thanks,
Simon
________________________________________
From: Ian Buckley [[email protected]]
Sent: Friday, December 19, 2014 19:26
To: Hartmann, Simon
Cc: [email protected]
Subject: Re: [USRP-users] Sychnronize two USRP X310 with GPS
Simon,
A few questions that will help in diagnosing what you are seeing:
How long have you had the X300's continuously powered (with GPS antennas
connected and a good view of the sky) before you make these measurements?
Can you describe how you determine they are out of sync? It sounds like you
have them at 2 remote locations?
Are you using the latest in UHD and FPGA images?
The fact that you see the same rx-time stream tags is a good sign that you are
using the API correctly to perform the capture. The fact that you are within
20-100uS tells me that UHD has tried to initialize the internal VITA timestamp
to a UTC related time, otherwise this value would be a count of 200MHz clock
ticks since power was applied to each unit.
Thx
-Ian
On Dec 19, 2014, at 5:10 AM, Simon Hartmann via USRP-users
<[email protected]> wrote:
> Hi all,
>
> the last weeks we tried to synchronize our two usrps X310 between two
> stations with two seperate GPS antenna, but the results weren't as good as we
> hoped.
> For your information, every usrp is connected to his own pc on which the same
> code is running.
>
> Our first intent was to check if the gps antenna is locked
> (get_mboard_sensor('gps_locked')) and then start to receive samples with the
> same time given (set_start_time(uhd.time_spec_t(self.start_time))). We only
> want to receive samples, therefore we used set_start_time() instead of
> set_command_time().
>
> When we checked the sync, there was a difference about 20 - 100 us. According
> to the documentation only ~100 ns should be allowed.
> We also read out the rx-time stream tags for both measurements and compared
> them. However, they were identically.
>
> In the documentation of Ettus it's explained, if the GPS is locked to the
> satellites the internal VITA timestamp will be initialized to the GPS time,
> and the internal oscillator will be phase-locked to the 10MHz GPSDO reference.
>
> So if their both locked they should have the same timestamp, or? Or do we
> need some further code to initialize the gps time to the usrp?
> What else could be the problem?
>
> Thanks,
>
> Simon
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Mon, 22 Dec 2014 12:20:00 +0100
From: altaf sk <[email protected]>
To: [email protected]
Subject: [USRP-users] Fwd: overrun 'o' from USRP B210
Message-ID:
<CAGxkagZg4w_FzSp-9Nvqy9owuFwpPHEt=mf9po0kyq2l6ct...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello USRP users,
I am running a flowgraph application (written in C++) with USRP B210
connected to host via USB3.
Sampling rate: 15.36MS/s
Master clock rate: 15.36MS/s
using gnuradio 3.7.3 and uhd 3.7.1
I have the overrun 'o' printed on stdout every 3-4 seconds. The signal
processing function on the host has heavy computing and I do not want to
change the decimation factor.
I tried running the application with high priority but no success.
Is it possible to solve with recv_buff_size parameter.?
Can you please guide me on how to solve this overrun problem.
Regards,
Alt-F
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141222/a5108e48/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 23 Dec 2014 12:47:28 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Fwd: overrun 'o' from USRP B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 12/22/2014 06:20 AM, altaf sk via USRP-users wrote:
> Hello USRP users,
>
> I am running a flowgraph application (written in C++) with USRP B210
> connected to host via USB3.
>
> Sampling rate: 15.36MS/s
> Master clock rate: 15.36MS/s
>
> using gnuradio 3.7.3 and uhd 3.7.1
>
> I have the overrun 'o' printed on stdout every 3-4 seconds. The signal
> processing function on the host has heavy computing and I do not want
> to change the decimation factor.
>
> I tried running the application with high priority but no success.
>
> Is it possible to solve with recv_buff_size parameter.?
>
> Can you please guide me on how to solve this overrun problem.
>
> Regards,
>
> Alt-F
>
Increasing recv_frame_size may or may not help.
If, on long-term average, your machine cannot "keep up" with the flow,
then no amount of buffering will help.
Also, some USB-3.0 controllers don't handle high-speed flows very
well--what type of USB-3.0 controller do you have?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 5
Date: Tue, 23 Dec 2014 10:13:39 -0800
From: Ian Buckley <[email protected]>
To: Venkatesh Sandilya <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] uhd_rx.cpp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
venkatesh,
The entire UHD source tree is available at:
https://github.com/EttusResearch/uhd
You'll find *.cpp source files related to host side UHD under host/lib/*
-Ian
On Dec 23, 2014, at 9:22 AM, Venkatesh Sandilya via USRP-users
<[email protected]> wrote:
> Hello
>
> I have gnuradio 3.7.2.1 and uhd installed on my Linux machine. Is there a
> uhd_rx.cpp? If yes, can someone please tell me where it is?
>
> Thanks
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141223/4d31c8ab/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 23 Dec 2014 11:16:02 -0800
From: Ian Buckley <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] overrun 'o' from USRP B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
ALT-F,
One interesting little experiment for you. Try running exactly the same
application with sample_rate 15.36M and master_clock_rate 30.72M.
It may make no difference what so ever, but in theory it makes the B200 capable
of responding a little quicker to available DMA bandwidth to upload data onto
the USB3 bus.
-ian
On Dec 23, 2014, at 9:47 AM, Marcus D. Leech via USRP-users
<[email protected]> wrote:
> On 12/22/2014 06:20 AM, altaf sk via USRP-users wrote:
>> Hello USRP users,
>>
>> I am running a flowgraph application (written in C++) with USRP B210
>> connected to host via USB3.
>>
>> Sampling rate: 15.36MS/s
>> Master clock rate: 15.36MS/s
>>
>> using gnuradio 3.7.3 and uhd 3.7.1
>>
>> I have the overrun 'o' printed on stdout every 3-4 seconds. The signal
>> processing function on the host has heavy computing and I do not want to
>> change the decimation factor.
>>
>> I tried running the application with high priority but no success.
>>
>> Is it possible to solve with recv_buff_size parameter.?
>>
>> Can you please guide me on how to solve this overrun problem.
>>
>> Regards,
>>
>> Alt-F
>>
> Increasing recv_frame_size may or may not help.
>
> If, on long-term average, your machine cannot "keep up" with the flow, then
> no amount of buffering will help.
>
> Also, some USB-3.0 controllers don't handle high-speed flows very well--what
> type of USB-3.0 controller do you have?
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Tue, 23 Dec 2014 15:15:09 -0500
From: Jim Hunziker <[email protected]>
To: Michael West <[email protected]>
Cc: usrp-users <[email protected]>, support
<[email protected]>, Timothy Maese <[email protected]>
Subject: Re: [USRP-users] Zeros are not zero?
Message-ID:
<CAGH06Ju6sdwemDxKN_6Rm+ETfj8H=_b_xujjlq3vrvhjobh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Here is the fix for this problem.
The original problem is that the DAC sends out uncalibrated zeros when the
transmitter is not transmitting. So when it does start transmitting, there
are bad transients related to the jump from uncalibrated zeros to
calibrated zeros. This makes using scheduled transmissions (providing a
time_spec_t to the transmit function) not possible without a data quality
problem.
To fix it, the X300 needs to set the SR_CODEC_IDLE register to the
calibrated I and Q values (as read from the calibration file for the
desired output frequency). I verified it by putting the following line in
UHD's x300_impl.cpp:setup_radio function.
perif.ctrl->poke32(TOREG(250), 0xf448f448);
0xf448 was picked because our calibration file says I and Q need a -0.045
offset at our transmit frequency.
When you fix this yourselves, you should do it in the part of the UHD code
where the transmit frequency is changed so that you can look up the proper
correction in the calibration file.
Please let me know when you have a patch. This problem is keeping us from
using scheduled transmissions (and thus ATR). Thanks
--
Jim Hunziker
BCI Systems and Software Engineering
[email protected]
On Mon, Nov 17, 2014 at 7:28 PM, Michael West <[email protected]>
wrote:
> Hi Jim,
>
> It looks like it will take some time to investigate and resolve the
> issue. I have filed a bug so we will continue to look into it. As a
> workaround for the time being, just keep the stream running and insert
> zeros where you need them.
>
> Regards,
> Michael
>
> On Mon, Nov 17, 2014 at 2:39 PM, Michael West <[email protected]>
> wrote:
>
>> Hi Jim,
>>
>> Thanks for trying that. Let me take a closer look at the UHD and FPGA
>> code to see what is going on and get back to you.
>>
>> Regards,
>> Michael
>>
>> On Mon, Nov 17, 2014 at 7:44 AM, Jim Hunziker <[email protected]>
>> wrote:
>>
>>> Attached is the scope plot with the patch applied. I verified that the
>>> patch was active by making a build with an exit(0) above the change to
>>> force the program to exit. It did, so I removed the exit(0) and ran again.
>>>
>>> You can see in the plot that our LFM pulse surrounded by zeros is riding
>>> on top of the calibration (manually set to 0.3 I, 0.3 Q in the calibration
>>> file). The time when no transmission is scheduled is still uncalibrated.
>>>
>>> The plot is the I+ signal from the DAQ test point. (The I- is just the
>>> mirror image, as expected.)
>>>
>>> --
>>> Jim Hunziker
>>> BCI Systems and Software Engineering
>>> [email protected]
>>>
>>> On Fri, Nov 14, 2014 at 7:38 PM, Michael West <[email protected]>
>>> wrote:
>>>
>>>> Hi Jim,
>>>>
>>>> This may be due to the ATR. The TX mixer is disabled, the gain is
>>>> reduced to 0, and the TX antenna is deselected when in the idle state. The
>>>> attached patch configures the ATR the same for the idle and TX states for
>>>> the CBX daughter board. Give it a try and let me know if anything changes.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Fri, Nov 14, 2014 at 11:52 AM, Jim Hunziker via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> After some further investigation, we've found that the problem is
>>>>> still there. We're now looking at the I+ and I- outputs of the DAQ on the
>>>>> X310 using a scope.
>>>>>
>>>>> The calibration offset is only being applied when a scheduled
>>>>> transmission is taking place. This missing calibration offset is causing
>>>>> the "zeros are not zero" problem.
>>>>>
>>>>> I don't see how the X310 can be used with time_specs set without
>>>>> disabling calibration. (We're using a CBX-120, by the way.)
>>>>>
>>>>> Please see the attached document for plots.
>>>>>
>>>>> --
>>>>> Jim Hunziker
>>>>> BCI Systems and Software Engineering
>>>>> [email protected]
>>>>>
>>>>> On Wed, Nov 12, 2014 at 11:29 AM, Marcus M?ller <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> > How does the device choose the lo_off when you
>>>>>> don't specify it?
>>>>>>
>>>>>> It tries to make the LO offset as small as possible, which gets more
>>>>>> intuitive if you think about the USRP, by user expectation, has to work
>>>>>> like a direct downconversion receiver.
>>>>>>
>>>>>> Also, 15MHz LO offset is *much*; with the standard daughterboards,
>>>>>> you'll only get 40MHz analog bandwidth, meaning that you get +-20MHz
>>>>>> around
>>>>>> the physically tuned frequency; for the -120 Daughterboards, it's
>>>>>> +-60MHz.
>>>>>> So, if you're on a 40MHz daughterboard, and you use 15MHz offset tuning,
>>>>>> and get a sample rate of 10MHz, you will see the filter rolloff in the
>>>>>> upper part of your digital spectrum.
>>>>>>
>>>>>> >Does it bounce around every scheduled transmission?
>>>>>>
>>>>>>
>>>>>> Yes (kind of). Unless you specify otherwise, UHD will determine
>>>>>> "optimal" tuning by the "as close as possible" algorithm. If you, for
>>>>>> example, want to tune to different center frequencies within the analog
>>>>>> bandwidth, you can use the same tune_request magic to only tune your DSP
>>>>>> --
>>>>>> making tuning a lot faster, in most cases.
>>>>>>
>>>>>> Greetings,
>>>>>> Marcus
>>>>>> On 11/12/2014 05:15 PM, Jim Hunziker via USRP-users wrote:
>>>>>>
>>>>>> I changed my tune request from allowing it to use an automatic lo_off
>>>>>> parameter to forcing it to use 15 MHz. This fixed the problem
>>>>>> completely. I
>>>>>> don't know why this worked. How does the device choose the lo_off when
>>>>>> you
>>>>>> don't specify it? Does it bounce around every scheduled transmission?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing
>>>>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141223/2964f8c4/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 23 Dec 2014 16:18:42 -0800
From: Michael West <[email protected]>
To: Jim Hunziker <[email protected]>
Cc: usrp-users <[email protected]>, support
<[email protected]>, Timothy Maese <[email protected]>
Subject: Re: [USRP-users] Zeros are not zero?
Message-ID:
<cam4xkrobk7qevm9bvo0td5q9vra-lp6cyfhhg2+e7nxeu59...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jim,
Thanks for the information. We will look into this right away.
Regards,
Michael
On Tue, Dec 23, 2014 at 12:15 PM, Jim Hunziker <[email protected]>
wrote:
>
> Here is the fix for this problem.
>
> The original problem is that the DAC sends out uncalibrated zeros when the
> transmitter is not transmitting. So when it does start transmitting, there
> are bad transients related to the jump from uncalibrated zeros to
> calibrated zeros. This makes using scheduled transmissions (providing a
> time_spec_t to the transmit function) not possible without a data quality
> problem.
>
> To fix it, the X300 needs to set the SR_CODEC_IDLE register to the
> calibrated I and Q values (as read from the calibration file for the
> desired output frequency). I verified it by putting the following line in
> UHD's x300_impl.cpp:setup_radio function.
>
> perif.ctrl->poke32(TOREG(250), 0xf448f448);
>
> 0xf448 was picked because our calibration file says I and Q need a -0.045
> offset at our transmit frequency.
>
> When you fix this yourselves, you should do it in the part of the UHD code
> where the transmit frequency is changed so that you can look up the proper
> correction in the calibration file.
>
> Please let me know when you have a patch. This problem is keeping us from
> using scheduled transmissions (and thus ATR). Thanks
>
> --
> Jim Hunziker
> BCI Systems and Software Engineering
> [email protected]
>
> On Mon, Nov 17, 2014 at 7:28 PM, Michael West <[email protected]>
> wrote:
>
>> Hi Jim,
>>
>> It looks like it will take some time to investigate and resolve the
>> issue. I have filed a bug so we will continue to look into it. As a
>> workaround for the time being, just keep the stream running and insert
>> zeros where you need them.
>>
>> Regards,
>> Michael
>>
>> On Mon, Nov 17, 2014 at 2:39 PM, Michael West <[email protected]>
>> wrote:
>>
>>> Hi Jim,
>>>
>>> Thanks for trying that. Let me take a closer look at the UHD and FPGA
>>> code to see what is going on and get back to you.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Mon, Nov 17, 2014 at 7:44 AM, Jim Hunziker <[email protected]>
>>> wrote:
>>>
>>>> Attached is the scope plot with the patch applied. I verified that the
>>>> patch was active by making a build with an exit(0) above the change to
>>>> force the program to exit. It did, so I removed the exit(0) and ran again.
>>>>
>>>> You can see in the plot that our LFM pulse surrounded by zeros is
>>>> riding on top of the calibration (manually set to 0.3 I, 0.3 Q in the
>>>> calibration file). The time when no transmission is scheduled is still
>>>> uncalibrated.
>>>>
>>>> The plot is the I+ signal from the DAQ test point. (The I- is just the
>>>> mirror image, as expected.)
>>>>
>>>> --
>>>> Jim Hunziker
>>>> BCI Systems and Software Engineering
>>>> [email protected]
>>>>
>>>> On Fri, Nov 14, 2014 at 7:38 PM, Michael West <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Jim,
>>>>>
>>>>> This may be due to the ATR. The TX mixer is disabled, the gain is
>>>>> reduced to 0, and the TX antenna is deselected when in the idle state.
>>>>> The
>>>>> attached patch configures the ATR the same for the idle and TX states for
>>>>> the CBX daughter board. Give it a try and let me know if anything
>>>>> changes.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>> On Fri, Nov 14, 2014 at 11:52 AM, Jim Hunziker via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> After some further investigation, we've found that the problem is
>>>>>> still there. We're now looking at the I+ and I- outputs of the DAQ on the
>>>>>> X310 using a scope.
>>>>>>
>>>>>> The calibration offset is only being applied when a scheduled
>>>>>> transmission is taking place. This missing calibration offset is causing
>>>>>> the "zeros are not zero" problem.
>>>>>>
>>>>>> I don't see how the X310 can be used with time_specs set without
>>>>>> disabling calibration. (We're using a CBX-120, by the way.)
>>>>>>
>>>>>> Please see the attached document for plots.
>>>>>>
>>>>>> --
>>>>>> Jim Hunziker
>>>>>> BCI Systems and Software Engineering
>>>>>> [email protected]
>>>>>>
>>>>>> On Wed, Nov 12, 2014 at 11:29 AM, Marcus M?ller <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> > How does the device choose the lo_off when you
>>>>>>> don't specify it?
>>>>>>>
>>>>>>> It tries to make the LO offset as small as possible, which gets more
>>>>>>> intuitive if you think about the USRP, by user expectation, has to work
>>>>>>> like a direct downconversion receiver.
>>>>>>>
>>>>>>> Also, 15MHz LO offset is *much*; with the standard daughterboards,
>>>>>>> you'll only get 40MHz analog bandwidth, meaning that you get +-20MHz
>>>>>>> around
>>>>>>> the physically tuned frequency; for the -120 Daughterboards, it's
>>>>>>> +-60MHz.
>>>>>>> So, if you're on a 40MHz daughterboard, and you use 15MHz offset tuning,
>>>>>>> and get a sample rate of 10MHz, you will see the filter rolloff in the
>>>>>>> upper part of your digital spectrum.
>>>>>>>
>>>>>>> >Does it bounce around every scheduled transmission?
>>>>>>>
>>>>>>>
>>>>>>> Yes (kind of). Unless you specify otherwise, UHD will determine
>>>>>>> "optimal" tuning by the "as close as possible" algorithm. If you, for
>>>>>>> example, want to tune to different center frequencies within the analog
>>>>>>> bandwidth, you can use the same tune_request magic to only tune your
>>>>>>> DSP --
>>>>>>> making tuning a lot faster, in most cases.
>>>>>>>
>>>>>>> Greetings,
>>>>>>> Marcus
>>>>>>> On 11/12/2014 05:15 PM, Jim Hunziker via USRP-users wrote:
>>>>>>>
>>>>>>> I changed my tune request from allowing it to use an automatic lo_off
>>>>>>> parameter to forcing it to use 15 MHz. This fixed the problem
>>>>>>> completely. I
>>>>>>> don't know why this worked. How does the device choose the lo_off when
>>>>>>> you
>>>>>>> don't specify it? Does it bounce around every scheduled transmission?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing
>>>>>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141223/d4486300/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 23 Dec 2014 19:41:14 -0800
From: Michael West <[email protected]>
To: Jim Hunziker <[email protected]>
Cc: usrp-users <[email protected]>, support
<[email protected]>, Timothy Maese <[email protected]>
Subject: Re: [USRP-users] Zeros are not zero?
Message-ID:
<CAM4xKrrmgv6uuH2t17YsWYCbHC=KaNFSA2K81Kn-K=bw2p2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jim,
Attached is a patch that sets the SR_CODEC_IDLE register to the same values
as the TX DC offset. That should give you what you need. Please give it a
try and let me know if it works for you. We are also looking into a more
permanent and appropriate fix for the issue to be included in a future
release of UHD.
Best regards,
Michael
On Tue, Dec 23, 2014 at 4:18 PM, Michael West <[email protected]>
wrote:
>
> Hi Jim,
>
> Thanks for the information. We will look into this right away.
>
> Regards,
> Michael
>
> On Tue, Dec 23, 2014 at 12:15 PM, Jim Hunziker <[email protected]>
> wrote:
>>
>> Here is the fix for this problem.
>>
>> The original problem is that the DAC sends out uncalibrated zeros when
>> the transmitter is not transmitting. So when it does start transmitting,
>> there are bad transients related to the jump from uncalibrated zeros to
>> calibrated zeros. This makes using scheduled transmissions (providing a
>> time_spec_t to the transmit function) not possible without a data quality
>> problem.
>>
>> To fix it, the X300 needs to set the SR_CODEC_IDLE register to the
>> calibrated I and Q values (as read from the calibration file for the
>> desired output frequency). I verified it by putting the following line in
>> UHD's x300_impl.cpp:setup_radio function.
>>
>> perif.ctrl->poke32(TOREG(250), 0xf448f448);
>>
>> 0xf448 was picked because our calibration file says I and Q need a -0.045
>> offset at our transmit frequency.
>>
>> When you fix this yourselves, you should do it in the part of the UHD
>> code where the transmit frequency is changed so that you can look up the
>> proper correction in the calibration file.
>>
>> Please let me know when you have a patch. This problem is keeping us from
>> using scheduled transmissions (and thus ATR). Thanks
>>
>> --
>> Jim Hunziker
>> BCI Systems and Software Engineering
>> [email protected]
>>
>> On Mon, Nov 17, 2014 at 7:28 PM, Michael West <[email protected]>
>> wrote:
>>
>>> Hi Jim,
>>>
>>> It looks like it will take some time to investigate and resolve the
>>> issue. I have filed a bug so we will continue to look into it. As a
>>> workaround for the time being, just keep the stream running and insert
>>> zeros where you need them.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Mon, Nov 17, 2014 at 2:39 PM, Michael West <[email protected]>
>>> wrote:
>>>
>>>> Hi Jim,
>>>>
>>>> Thanks for trying that. Let me take a closer look at the UHD and FPGA
>>>> code to see what is going on and get back to you.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Mon, Nov 17, 2014 at 7:44 AM, Jim Hunziker <[email protected]
>>>> > wrote:
>>>>
>>>>> Attached is the scope plot with the patch applied. I verified that the
>>>>> patch was active by making a build with an exit(0) above the change to
>>>>> force the program to exit. It did, so I removed the exit(0) and ran again.
>>>>>
>>>>> You can see in the plot that our LFM pulse surrounded by zeros is
>>>>> riding on top of the calibration (manually set to 0.3 I, 0.3 Q in the
>>>>> calibration file). The time when no transmission is scheduled is still
>>>>> uncalibrated.
>>>>>
>>>>> The plot is the I+ signal from the DAQ test point. (The I- is just the
>>>>> mirror image, as expected.)
>>>>>
>>>>> --
>>>>> Jim Hunziker
>>>>> BCI Systems and Software Engineering
>>>>> [email protected]
>>>>>
>>>>> On Fri, Nov 14, 2014 at 7:38 PM, Michael West <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Jim,
>>>>>>
>>>>>> This may be due to the ATR. The TX mixer is disabled, the gain is
>>>>>> reduced to 0, and the TX antenna is deselected when in the idle state.
>>>>>> The
>>>>>> attached patch configures the ATR the same for the idle and TX states for
>>>>>> the CBX daughter board. Give it a try and let me know if anything
>>>>>> changes.
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>> On Fri, Nov 14, 2014 at 11:52 AM, Jim Hunziker via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> After some further investigation, we've found that the problem is
>>>>>>> still there. We're now looking at the I+ and I- outputs of the DAQ on
>>>>>>> the
>>>>>>> X310 using a scope.
>>>>>>>
>>>>>>> The calibration offset is only being applied when a scheduled
>>>>>>> transmission is taking place. This missing calibration offset is causing
>>>>>>> the "zeros are not zero" problem.
>>>>>>>
>>>>>>> I don't see how the X310 can be used with time_specs set without
>>>>>>> disabling calibration. (We're using a CBX-120, by the way.)
>>>>>>>
>>>>>>> Please see the attached document for plots.
>>>>>>>
>>>>>>> --
>>>>>>> Jim Hunziker
>>>>>>> BCI Systems and Software Engineering
>>>>>>> [email protected]
>>>>>>>
>>>>>>> On Wed, Nov 12, 2014 at 11:29 AM, Marcus M?ller <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> > How does the device choose the lo_off when you
>>>>>>>> don't specify it?
>>>>>>>>
>>>>>>>> It tries to make the LO offset as small as possible, which gets
>>>>>>>> more intuitive if you think about the USRP, by user expectation, has to
>>>>>>>> work like a direct downconversion receiver.
>>>>>>>>
>>>>>>>> Also, 15MHz LO offset is *much*; with the standard daughterboards,
>>>>>>>> you'll only get 40MHz analog bandwidth, meaning that you get +-20MHz
>>>>>>>> around
>>>>>>>> the physically tuned frequency; for the -120 Daughterboards, it's
>>>>>>>> +-60MHz.
>>>>>>>> So, if you're on a 40MHz daughterboard, and you use 15MHz offset
>>>>>>>> tuning,
>>>>>>>> and get a sample rate of 10MHz, you will see the filter rolloff in the
>>>>>>>> upper part of your digital spectrum.
>>>>>>>>
>>>>>>>> >Does it bounce around every scheduled transmission?
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes (kind of). Unless you specify otherwise, UHD will determine
>>>>>>>> "optimal" tuning by the "as close as possible" algorithm. If you, for
>>>>>>>> example, want to tune to different center frequencies within the analog
>>>>>>>> bandwidth, you can use the same tune_request magic to only tune your
>>>>>>>> DSP --
>>>>>>>> making tuning a lot faster, in most cases.
>>>>>>>>
>>>>>>>> Greetings,
>>>>>>>> Marcus
>>>>>>>> On 11/12/2014 05:15 PM, Jim Hunziker via USRP-users wrote:
>>>>>>>>
>>>>>>>> I changed my tune request from allowing it to use an automatic lo_off
>>>>>>>> parameter to forcing it to use 15 MHz. This fixed the problem
>>>>>>>> completely. I
>>>>>>>> don't know why this worked. How does the device choose the lo_off when
>>>>>>>> you
>>>>>>>> don't specify it? Does it bounce around every scheduled transmission?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing
>>>>>>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141223/8cb3bed1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x300_zeros_at_idle.patch
Type: text/x-patch
Size: 2857 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141223/8cb3bed1/attachment-0001.patch>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 52, Issue 24
******************************************
