[USRP-users] B210 device driver - is

Red Gator redgatormds at gmail.com
Wed Sep 24 10:14:56 EDT 2014


We are seeing what might be a problem with reproducability. In one pass we
will see one nice place, in a second pass we will have additional spurs.
I'm working through dumping the calibration register space with my UHD-SPI
driver to see if values are consistent between passes.

On Thu, Jul 31, 2014 at 1:58 PM, Red Gator <redgatormds at gmail.com> wrote:

> I have implemented an SPI read/write operation over the USB interface. My
> enhancement defines "spi/addr" and "spi/value" properties; reading or
> writing the "spi/value" will affect the register at "spi/addr". I seem to
> be reading/modifying registers as expected. Not hard to implement -
> straightforward after getting my head wrapped around
> coerse/publish/subscribe semantics.
>
> RSSI experiment was a fail (attempting to configure and elicit some RSSI
> variation while sweeping a signal through the tuned frequency).
>
> FASTLOCK experiment is now a SUCCESS. I'm trying to verify the FASTLOCK
> timing now. AD9361 FASTLOCK allows a RX (or TX) calibrated settings to be
> stored in one of 8 "profiles" on the device and recalled with as little as
> 1 SPI write.
>
>
>
> On Tue, Jul 29, 2014 at 4:06 PM, Red Gator <redgatormds at gmail.com> wrote:
>
>> I have implemented an SPI read/write operation over the USB interface.
>> The interface defines "spi/addr" and "spi/value" properties; reading or
>> writing the "spi/value" will affect the register at "spi/addr". I seem to
>> be reading/modifying registers as expected.
>>
>> RSSI experiment was a fail (attempting to configure and elicit some RSSI
>> variation while sweeping a signal through the tuned frequency).
>>
>> FASTLOCK experiment was a fail. Making the assumption that some of the
>> FASTLOCK operations are a single SPI write, this should allow us to
>> characterize the tuning time (from stable frequency to new stable
>> frequency). However, I don't see any evidence that loading the saved
>> FASTLOCK profile is having any effect.
>>
>>
>>
>>
>> On Tue, Jul 22, 2014 at 8:13 AM, Red Gator <redgatormds at gmail.com> wrote:
>>
>>> The property list looks to be the right way to do any extensions. The
>>> RSSI report, for instance, fits nicely in the "sensor" model.
>>>
>>> However, before cutting into the FX3 code I'd like to be able to
>>> prototype the particular SPI operations, So, I will start by exposing the
>>> fx3_control_*() and when I get a set of steps I like I will slip it under
>>> the property list.
>>>
>>>
>>> On Mon, Jul 21, 2014 at 9:26 PM, Balint Seeber <balint.seeber at ettus.com>
>>> wrote:
>>>
>>>> Hi Red,
>>>>
>>>> All the B200-specific (all model-specific for that matter) interfaces
>>>> are hidden from the public API, so you may wish to consider two types of
>>>> surgery:
>>>>
>>>> 1) Create your own public interface containing all the functionality
>>>> you require and place it in uhd/host/include/uhd/usrp (for example). Then
>>>> add a helper method to the uhd::device class to return a pointer to your
>>>> own interface class (the default implementation can just return a dummy
>>>> version of your interface so you don't have to implement the call for all
>>>> the other device implementations). Implement your interface in b200_impl,
>>>> and then from the public API after you create your multi_usrp instance,
>>>> call get_device and then call the helper to get your interface. Of course
>>>> you could also just add whatever additional functionality directly to
>>>> uhd::device too, and skip the separate interface (depending on how clean
>>>> you want it to be).
>>>>
>>>> 2) Register additional items in the property tree in b200_impl that
>>>> expose the functionality you desire. The property tree is flexible in how
>>>> you can cause 'values' to be altered, read back, etc. For example, you
>>>> could have a 'R/W' value that represents a register to read on the B200.
>>>> Upon setting the value of this item, you would then make the appropriate
>>>> calls to read the register and then store the result back in the original
>>>> item (or another property tree item). You can accomplish this by using the
>>>> appropriate combination of publish/subscribe/coerce functions on your
>>>> property tree node (e.g. see b200_impl where there are plenty of examples -
>>>> if you wish to have a single R/W item, coerce will be where you do the
>>>> transaction).
>>>>
>>>> Hope that helps.
>>>>
>>>> Kind regards,
>>>> Balint
>>>>
>>>>
>>>> On Sun, Jul 20, 2014 at 11:02 AM, Red Gator via USRP-users <
>>>> usrp-users at lists.ettus.com> wrote:
>>>>
>>>>> I see the fx3 implementation of ADI recommended register choreography
>>>>> is now. My colleague would like to get comfortable with the cal/tuning
>>>>> results from these operations, so just reading the final values of the
>>>>> various registers would be handy. However, It does not look like the
>>>>> fx3_control_(read|write)() functions are available even with a re-cast
>>>>> top-level object. There looks to be needed 'surgery" just to expose them.
>>>>> It may be as simple as declaring them virtual in the public b200_iface
>>>>> header.
>>>>>
>>>>>
>>>>> On Wed, Jun 25, 2014 at 2:45 PM, Marcus Leech <mleech at ripnet.com>
>>>>> wrote:
>>>>>
>>>>>> It's not a speed queen.  Every tuning requires a fair amount of
>>>>>> "dancing about" in the AD9361, which requires SPI (or is it I2C, I forget)
>>>>>> transactions against the AD9361.
>>>>>>
>>>>>> Some of them could be skipped if one were writing their own tuning
>>>>>> driver for the AD9361, but the current driver is based on the recommended
>>>>>> approach from Analog Devices.
>>>>>>
>>>>>> And if you're tuning from the host, you have to pay the USB
>>>>>> control-endpoint latency penalty, whatever that is.
>>>>>>
>>>>>> All the code to do this is published (including, now, the FX3 code),
>>>>>> so you can certainly experiment yourself.
>>>>>>
>>>>>>
>>>>>>
>>>>>>  on Jun 25, 2014, *Red Gator* <redgatormds at gmail.com> wrote:
>>>>>>
>>>>>> So then the question becomes - does anybody have a number for how
>>>>>> fast the USRP B210 can tune?
>>>>>>
>>>>>> And open-loop benchmark (because I can't know when the receiver is
>>>>>> tuned) says ~1500us just to do the set_rx_freq() driver function in a C++
>>>>>> loop.
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 25, 2014 at 1:45 PM, Marcus Leech <mleech at ripnet.com>
>>>>>> wrote:
>>>>>>
>>>>>>> In general, not all products have all the same sensors.
>>>>>>>
>>>>>>> Now, having said that, there's pending updates to UHD and firmware
>>>>>>> for B2xx that will create an "lo_locked" sensor, although the semantics on
>>>>>>> the AD9361 are a bit complicated, according to
>>>>>>>   my understanding.
>>>>>>>
>>>>>>> uhd_fft shouldn't go asking for a sensor that isn't universally
>>>>>>> there,  so the "bug" here is twofold: uhd_fft asking for something that may
>>>>>>> not exist, and the B2xx interface not currently
>>>>>>>   provide an "lo_locked" sensor.
>>>>>>>
>>>>>>> The "properties tree" has filesystem-like syntax, but it's actually,
>>>>>>> as I recall, a Boostism.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   on Jun 25, 2014, *Red Gator via USRP-users* <
>>>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>>>
>>>>>>>   I've been tasked with measuring the tune time on a B210. I have
>>>>>>> been able to get the Windows system to run (binaries from Ettus.com site)
>>>>>>> and I am in the process of getting a late-version Fedora system built to
>>>>>>> try that.
>>>>>>>
>>>>>>> Although it runs, the uhd_fft example spits out this diagnostic:
>>>>>>>
>>>>>>>
>>>>>>>  Exception in thread Thread-7:
>>>>>>>  Traceback (most recent call last):
>>>>>>>    File "C:\python27\lib\threading.py", line 810, in
>>>>>>> __bootstrap_inner
>>>>>>>      self.run()
>>>>>>>    File "C:\python27\lib\threading.py", line 763, in run
>>>>>>>      self.__target(*self.__args, **self.__kwargs)
>>>>>>>    File
>>>>>>> "C:\a\jsaari\project\df_pod\ettus_n210\gnuradio\examples\uhd\uhd_fft.py",
>>>>>>> line 192, in _chan0_lo_locked_probe
>>>>>>>      val = self.uhd_usrp_source_0.get_sensor('lo_locked')
>>>>>>>    File "C:\Program Files
>>>>>>> (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.py", line 3002, in
>>>>>>> get_sensor
>>>>>>>      return _uhd_swig.usrp_source_sptr_get_sensor(self, *args,
>>>>>>> **kwargs)
>>>>>>>  RuntimeError: LookupError: Path not found in tree:
>>>>>>> /mboards/0/dboards/A/rx_frontends/B/sensors/lo_locked
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It looks like the driver has a pseudo-filesystem to hold
>>>>>>> "properties" including "sensors", and the "lo_locked" output is apparently
>>>>>>> a "sensor".
>>>>>>>
>>>>>>> Can I assert from this that reading the LO lock state is not
>>>>>>> supported on the B210 platform? If I'm chasing a ghostie I'd like to know
>>>>>>> that sooner rather than later.
>>>>>>>
>>>>>>> A follow up observation: the "uhd_usrp_probe" utility does not
>>>>>>> populate the "Sensors:" field in the RX entries:
>>>>>>>
>>>>>>>  |     _____________________________________________________
>>>>>>> |    /
>>>>>>> |   |       Mboard: B210
>>>>>>> |   |   revision: 4
>>>>>>> |   |   product: 2
>>>>>>> |   |   serial: F5002D
>>>>>>> |   |   FW Version: 4.0
>>>>>>> |   |   FPGA Version: 3.0
>>>>>>> |   |
>>>>>>> |   |   Time sources: none, external, gpsdo
>>>>>>> |   |   Clock sources: internal, external, gpsdo
>>>>>>> |   |   Sensors: ref_locked
>>>>>>> |   |     _____________________________________________________
>>>>>>> |   |    /
>>>>>>> |   |   |       RX DSP: 0
>>>>>>> |   |   |   Freq range: -16.000 to 16.000 Mhz
>>>>>>> |   |     _____________________________________________________
>>>>>>> |   |    /
>>>>>>> |   |   |       RX DSP: 1
>>>>>>> |   |   |   Freq range: -16.000 to 16.000 Mhz
>>>>>>> |   |     _____________________________________________________
>>>>>>> |   |    /
>>>>>>> |   |   |       RX Dboard: A
>>>>>>> |   |   |     _____________________________________________________
>>>>>>> |   |   |    /
>>>>>>> |   |   |   |       RX Frontend: A
>>>>>>> |   |   |   |   Name: FE-RX2
>>>>>>> |   |   |   |   Antennas: TX/RX, RX2
>>>>>>> |   |   |   |   Sensors:
>>>>>>> |   |   |   |   Freq range: 50.000 to 6000.000 Mhz
>>>>>>> |   |   |   |   Gain range PGA: 0.0 to 73.0 step 1.0 dB
>>>>>>> |   |   |   |   Connection Type: IQ
>>>>>>> |   |   |   |   Uses LO offset: No
>>>>>>> |   |   |     _____________________________________________________
>>>>>>> |   |   |    /
>>>>>>> |   |   |   |       RX Frontend: B
>>>>>>> |   |   |   |   Name: FE-RX1
>>>>>>> |   |   |   |   Antennas: TX/RX, RX2
>>>>>>> |   |   |   |   Sensors:
>>>>>>> |   |   |   |   Freq range: 50.000 to 6000.000 Mhz
>>>>>>> |   |   |   |   Gain range PGA: 0.0 to 73.0 step 1.0 dB
>>>>>>> |   |   |   |   Connection Type: IQ
>>>>>>> |   |   |   |   Uses LO offset: No
>>>>>>> |   |   |     _____________________________________________________
>>>>>>> |   |   |    /
>>>>>>> |   |   |   |       RX Codec: A
>>>>>>> |   |   |   |   Name: B210 RX dual ADC
>>>>>>> |   |   |   |   Gain Elements: None
>>>>>>> |   |     _____________________________________________________
>>>>>>>
>>>>>>>   ------------------------------
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> USRP-users at lists.ettus.com
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users at lists.ettus.com
>>>>> 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/20140924/b571d1c1/attachment-0002.html>


More information about the USRP-users mailing list