Re: [USRP-users] N321 QSFP+ XQ image network connection

2020-11-23 Thread Michael Dickens via USRP-users 
Hi Pat - I recently verified that the N321 QAFP+ interface works with UHD 4.0 
release. I am also using an Intel XL710 (QDA2, but that probably doesn’t matter 
too much). The trick for me was using the Intel QSFP+ NIC configuration tool to 
set the NIC to 2x(2x10 Gb) mode. This is the setting that the N321 requires, 
and one that the NIC provides. Once that was set then you need to configures 
the host and USRP network interfaces as you normally would. After all of that, 
the link worked very nicely! I hope this is useful! - MLD 

> On Nov 23, 2020, at 4:44 PM, Patrick Kane via USRP-users 
>  wrote:
> 
> 
> I have an N321 connected to serial console and QSFP+ through a XL710 Intel 
> NIC. With the default HG image, I can connect through 1G and serial as 
> expected. I updated the filesystem to UHD 4.0.0.0 using mender, and the build 
> artifact reflects that this was successful. Then, after loading the XQ image 
> (using 2x 10Gb lanes through QSFP+ port), I lose all ethernet connectivity 
> through the 1G port SFP0 (expected), but I get the following output in the 
> console window:
> 
> [  451.560674] nixge 4000.ethernet sfp0: Link is Up - 10Gbps/Full - flow 
> control off
> [  453.800673] nixge 4000.ethernet sfp0: Link is Down
> [  454.920676] nixge 4000.ethernet sfp0: Link is Up - 10Gbps/Full - flow 
> control off
> [  458.280672] nixge 4000.ethernet sfp0: Link is Down
> [  459.400677] nixge 4000.ethernet sfp0: Link is Up - 10Gbps/Full - flow 
> control off
> [  462.760705] nixge 4000.ethernet sfp0: Link is Down
> [  463.880678] nixge 4000.ethernet sfp0: Link is Up - 10Gbps/Full - flow 
> control off
> [  466.120673] nixge 4000.ethernet sfp0: Link is Down
> 
> uhd_usrp_probe:
>   _
>  /
> |   Device: N300-Series Device
> | _
> |/
> |   |   Mboard: ni-n3xx-31E00AC
> |   |   dboard_0_pid: 338
> |   |   dboard_0_serial: 31DB406
> |   |   dboard_1_pid: 338
> |   |   dboard_1_serial: 31DB407
> |   |   eeprom_version: 3
> |   |   fs_version: 20200914000806
> |   |   mender_artifact: v4.0.0.0_n3xx
> |   |   mpm_sw_version: 4.0.0.0-g90ce6062
> |   |   pid: 16962
> |   |   product: n320
> |   |   rev: 7
> |   |   rpc_connection: local
> |   |   serial: 31E00AC
> |   |   type: n3xx
> |   |   MPM Version: 3.0
> |   |   FPGA Version: 8.0
> |   |   FPGA git hash: be53058.clean
> |   |
> |   |   Time sources:  internal, external, gpsdo, sfp0
> |   |   Clock sources: external, internal, gpsdo
> |   |   Sensors: ref_locked, gps_locked, temp, fan, gps_gpgga, gps_sky, 
> gps_time, gps_tpv
> 
> Are there any configuration items needed to connect to the N321 through the 
> QSFP+ port. Note that I only see eth0, sfp0, sfp1, and int0 in 
> /etc/network/interfaces.
> 
> Thanks,
> Pat
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] UHD 4.0 RFNoC migration questions

2020-11-23 Thread Nick Foster via USRP-users 
Just had a few q's regarding RFNoC in UHD 4.0 as I migrate my applications
to it.


   1. In the style of a tedious conference Q&A session, this is more of a
   comment than a question: I noticed NoCScript is dead: great! But it sure
   would be nice if there were something which filled the role of obviating
   the need for explicit block controllers for simple blocks.
   2. I noticed both the "registers" sections of the YAML definitions are
   unused in stock UHD blocks and unlooked-for in rfnoc_blocktool's
   templating process. I also noticed a lot of _regs.vh
   register definition files in the RFNoC Verilog blocks included in UHD,
   which look suspiciously like autogenerated boilerplate. Seems like
   something which would be reasonably straightforward (I say, having not done
   it myself) to implement in rfnoc_blocktool. What am I missing?
   3. I'm a little unclear on the difference between the rfnoc_chdr clock
   and ce_clk. Some block definitions just use one, some use both. I'm
   assuming the rfnoc_chdr clock is equivalent to the old bus_clk. Is the
   lack of a ce_clk in the block definition just to avoid having to route
   ce_clk to logic which doesn't require it? Is ce_clk decoupled entirely
   from radio_clk now on X310?
   4. Is there a plan to integrate rfnoc_modtool and rfnoc_blocktool? At
   least within the same repository? The overlapping functionality between
   them is confusing. It would be a huge reduction in boilerplate madness if a
   single YAML block definition could result in both Verilog blocks and
   coordinated C++ block controllers being generated.

Thanks for all the work on this: UHD 4.0 looks like a major improvement.

Nick
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP E100/E110 linux update

2020-11-23 Thread Philip Balister via USRP-users 
On 11/23/20 6:09 PM, Robin Coxe via USRP-users wrote:
> There is a legacy Ettus E100 github repo that may or may not be useful:
> https://github.com/EttusResearch/ettus_oe

This directory might help with kernel driver archeology:

https://github.com/EttusResearch/ettus_oe/tree/master/recipes/linux

Philip

> 
> This product has been EOL for >5 years, so as Philip points out, the
> institutional memory of it is basically non-existent.
> 
> On Mon, Nov 23, 2020 at 5:22 AM Sébastien DI MERCURIO via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
>> Hi Philips,
>>
>> thank you for your answer. I will have a look to your git repository. I'm
>> not very good with linux kernel intrinsics but I will try to have driver
>> work with newer kernel.
>>
>> If I succed, i will post my results.
>>
>> Thank you !
>> Le 23/11/2020 à 14:10, Philip Balister a écrit :
>>
>> On 11/23/20 7:09 AM, Sébastien DI MERCURIO via USRP-users wrote:
>>
>> Hi,
>>
>> I've got several USRP E100/E110 with outdated Linux and Gnuradio
>> software on it. So I decided to build a Yocto image, more up-to-date and
>> succeeded in after several tries.
>> The new image boots and run a reasonable updated version of Linux and
>> Gnuradio.
>>
>> But, because of Ettus proprietary kernel driver, I cannot connect to
>> FPGA and so the board is useless.
>>
>> It's an open driver, just non of us remember how it works. I did find
>> the code:
>> https://github.com/balister/linux-omap-philip
>>
>> The linux DMA architecture has likely changed, so the driver will need
>> work, but the code is out there. Let me know if you have questions, it
>> would be great to see these running. I'll answer as best I can. It has
>> been like 6-7 years since I last looked at it though.
>>
>> Using it like an N-series is likely not possible. The fpga is connected
>> to the Overo via the GPMC (General Purpose Memory Controller).
>>
>> Philip
>>
>>
>> My questions are:
>>
>> - Did someone achieve to get an updated Linux base and Gnuradio
>> software, with working FPGA communications (whatever the method)
>>   - Is it possible to get source code of Ettus kernel driver, as the
>> board is now End-of-life
>>   - Is it possible to enable Ethernet communication pass-throughto
>> FPGA, a bit like in N series, in order to use it over Ethernet(not
>> standalone)
>>
>> Regards!
>>
>> Sebastien
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> .
>>
>>
>>
>> ___
>> USRP-users mailing 
>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> --
>> [image: INSA Toulouse]
>>
>> *Sébastien DI MERCURIO*
>> *Ingénieur d'étude Systèmes embarqués et IoT*
>> Département GEI
>> Tél. : 05 61 55 98 34
>> dimer...@insa-toulouse.fr
>>
>> INSA Toulouse
>> 135 avenue de Rangueil
>> 31077 Toulouse CEDEX 04
>>
>> *www.insa-toulouse.fr  *
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP E100/E110 linux update

2020-11-23 Thread Robin Coxe via USRP-users 
There is a legacy Ettus E100 github repo that may or may not be useful:
https://github.com/EttusResearch/ettus_oe

This product has been EOL for >5 years, so as Philip points out, the
institutional memory of it is basically non-existent.

On Mon, Nov 23, 2020 at 5:22 AM Sébastien DI MERCURIO via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Philips,
>
> thank you for your answer. I will have a look to your git repository. I'm
> not very good with linux kernel intrinsics but I will try to have driver
> work with newer kernel.
>
> If I succed, i will post my results.
>
> Thank you !
> Le 23/11/2020 à 14:10, Philip Balister a écrit :
>
> On 11/23/20 7:09 AM, Sébastien DI MERCURIO via USRP-users wrote:
>
> Hi,
>
> I've got several USRP E100/E110 with outdated Linux and Gnuradio
> software on it. So I decided to build a Yocto image, more up-to-date and
> succeeded in after several tries.
> The new image boots and run a reasonable updated version of Linux and
> Gnuradio.
>
> But, because of Ettus proprietary kernel driver, I cannot connect to
> FPGA and so the board is useless.
>
> It's an open driver, just non of us remember how it works. I did find
> the code:
> https://github.com/balister/linux-omap-philip
>
> The linux DMA architecture has likely changed, so the driver will need
> work, but the code is out there. Let me know if you have questions, it
> would be great to see these running. I'll answer as best I can. It has
> been like 6-7 years since I last looked at it though.
>
> Using it like an N-series is likely not possible. The fpga is connected
> to the Overo via the GPMC (General Purpose Memory Controller).
>
> Philip
>
>
> My questions are:
>
> - Did someone achieve to get an updated Linux base and Gnuradio
> software, with working FPGA communications (whatever the method)
>   - Is it possible to get source code of Ettus kernel driver, as the
> board is now End-of-life
>   - Is it possible to enable Ethernet communication pass-throughto
> FPGA, a bit like in N series, in order to use it over Ethernet(not
> standalone)
>
> Regards!
>
> Sebastien
>
>
>
>
>
>
>
>
>
> .
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> [image: INSA Toulouse]
>
> *Sébastien DI MERCURIO*
> *Ingénieur d'étude Systèmes embarqués et IoT*
> Département GEI
> Tél. : 05 61 55 98 34
> dimer...@insa-toulouse.fr
>
> INSA Toulouse
> 135 avenue de Rangueil
> 31077 Toulouse CEDEX 04
>
> *www.insa-toulouse.fr  *
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] N321 QSFP+ XQ image network connection

2020-11-23 Thread Patrick Kane via USRP-users 
I have an N321 connected to serial console and QSFP+ through a XL710 Intel
NIC. With the default HG image, I can connect through 1G and serial as
expected. I updated the filesystem to UHD 4.0.0.0 using mender, and the
build artifact reflects that this was successful. Then, after loading the
XQ image (using 2x 10Gb lanes through QSFP+ port), I lose all ethernet
connectivity through the 1G port SFP0 (expected), but I get the following
output in the console window:


[  451.560674] nixge 4000.ethernet sfp0: Link is Up - 10Gbps/Full -
flow control off

[  453.800673] nixge 4000.ethernet sfp0: Link is Down

[  454.920676] nixge 4000.ethernet sfp0: Link is Up - 10Gbps/Full -
flow control off

[  458.280672] nixge 4000.ethernet sfp0: Link is Down

[  459.400677] nixge 4000.ethernet sfp0: Link is Up - 10Gbps/Full -
flow control off

[  462.760705] nixge 4000.ethernet sfp0: Link is Down

[  463.880678] nixge 4000.ethernet sfp0: Link is Up - 10Gbps/Full -
flow control off

[  466.120673] nixge 4000.ethernet sfp0: Link is Down


uhd_usrp_probe:

  _

 /

|   Device: N300-Series Device

| _

|/

|   |   Mboard: ni-n3xx-31E00AC

|   |   dboard_0_pid: 338

|   |   dboard_0_serial: 31DB406

|   |   dboard_1_pid: 338

|   |   dboard_1_serial: 31DB407

|   |   eeprom_version: 3

|   |   fs_version: 20200914000806

|   |   mender_artifact: v4.0.0.0_n3xx

|   |   mpm_sw_version: 4.0.0.0-g90ce6062

|   |   pid: 16962

|   |   product: n320

|   |   rev: 7

|   |   rpc_connection: local

|   |   serial: 31E00AC

|   |   type: n3xx

|   |   MPM Version: 3.0

|   |   FPGA Version: 8.0

|   |   FPGA git hash: be53058.clean

|   |

|   |   Time sources:  internal, external, gpsdo, sfp0

|   |   Clock sources: external, internal, gpsdo

|   |   Sensors: ref_locked, gps_locked, temp, fan, gps_gpgga, gps_sky,
gps_time, gps_tpv


Are there any configuration items needed to connect to the N321 through the
QSFP+ port. Note that I only see eth0, sfp0, sfp1, and int0 in
/etc/network/interfaces.


Thanks,

Pat
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 UBX digital tune not occurring?

2020-11-23 Thread Dustin Widmann via USRP-users 
Marcus,

Interesting, I hadn't considered that. I'm seeing this with both UHD 4.0 and 
UHD 3.15.

Dustin


On Mon, 2020-11-23 at 15:29 -0500, Marcus D Leech wrote:
> Could you confirm which version of UHD you’re using?
> 
> There has historically been a problem using both TwinRx and UBX on the same 
> X310 due to clocking requirement
> conflicts. 
> 
> But that has been fixed in UHD4
> 
> Want to eliminate that as a possibility first. 
> 
> Sent from my iPhone
> 
> > On Nov 23, 2020, at 11:42 AM, Dustin Widmann  wrote:
> > 
> > Marcus,
> > 
> > I do have access to sig gens, but I would have to take everything into town 
> > to do that. (sanest thing to do during
> > covid
> > was to bring portable things home...)
> > 
> > What I do have handy though is a spectrum analyzer (albeit, not a 
> > particularly good one, but when working with a
> > narrow
> > span it should be able to give results that are good enough)
> > 
> > What I observed is this:
> > tx freq MHz meas freq [MHz] deviation [Hz] 60.050  
> > 60.048800    1200
> > 61.050  61.050100   -100
> > 62.050  62.051200   -1200
> > 63.050  63.052533   -2533
> > 64.050  64.053600   -3600
> > 65.050  65.054933   -4933
> > 66.050  66.044000    6000
> > 67.050  67.045067    4933
> > 68.050  68.. Missed this one
> > 69.050  69.047733    2267
> > 70.050  70.048800    1200
> > 
> > 
> > For reference, what I observed with the twinrx was as follows
> > freq    target bin/freq actual bin/freq diff bin/freq  dsp 
> > freq 
> > 60MHz   524.288 (50e3)  512 (48,828) 12.288 (1,172)  
> > 1160   
> > 61MHz   524.288 (50e3)  525 (50,068) -0.712 (-68) 
> > -61   
> > 62MHz   524.288 (50e3)  538 (51,308)    -13.712 (-1,308)    
> > -1282   
> > 63MHz   524.288 (50e3)  551 (52,547)    -26.712 (-2,547)    
> > -2503   
> > 64MHz   524.288 (50e3)  563 (53,692)    -38.712 (-3,692)    
> > -3724   
> > 65MHz   524.288 (50e3)  576 (54,932)    -51.712 (-4,932)    
> > -4945   
> > 66MHz   524.288 (50e3)  461 (43,964) 63.288 (6,036)  
> > 6044   
> > 
> > Having taken the TwinRX out of the loop, it seems I'm getting very similar 
> > results. 
> > 
> > Dustin
> > 
> > 
> > > On Sat, 2020-11-21 at 13:43 -0500, Marcus D. Leech wrote:
> > > > On 11/21/2020 08:28 AM, Dustin Widmann wrote:
> > > > Marcus,
> > > > 
> > > > I tried it without timed commands last night. It was landing on the
> > > > same frequencies as it did with timed commands i.e. didn't fix that
> > > > problem.
> > > > 
> > > > Dustin
> > > OK, thanks for doing the test.
> > > 
> > > I wonder if you have a precise signal generator so you can confirm
> > > that 
> > > the RX side is on-frequency?
> > > 
> > > 
> > > > 
> > > > On Wed, 2020-11-18 at 20:05 -0500, Marcus D. Leech wrote:
> > > > > On 11/18/2020 07:34 PM, Dustin Widmann wrote:
> > > > > > On Wed, 2020-11-18 at 18:27 -0500, Marcus D. Leech via USRP-
> > > > > > users
> > > > > > wrote:
> > > > > > Marcus,
> > > > > > 
> > > > > > Oh, sorry, I missed the first bit. I'm using the on-board
> > > > > > clock.
> > > > > > And
> > > > > > perhaps I should explain the table with a little bit more
> > > > > > detail:
> > > > > > * 1st col: The *target* frequency. The RX was tuned to this
> > > > > > frequency.
> > > > > > The TX was tuned to that frequency + an offset (in this case,
> > > > > > 50KHz
> > > > > > for
> > > > > > all datapoints).
> > > > > > * 2nd col: Where the tone is expected to land, both bin and
> > > > > > (baseband)
> > > > > > frequency; in this case, a 50KHz offset for all datapoints,
> > > > > > which
> > > > > > corresponded to bin 524 with a 2^20 FFT.
> > > > > > * 3rd col: where the tone was observed (both bin and
> > > > > > frequency).
> > > > > > * 4th col: difference between the target and expectation
> > > > > > * 5th col: dsp freq (from uhd::tune_result_t.actual_dsp_freq)
> > > > > > * 6th col: what the difference would be if I offset the
> > > > > > observed
> > > > > > frequency by the claimed dsp frequency
> > > > > > 
> > > > > > Dustin
> > > > > > 
> > > > > Right, I understand the chart now.
> > > > > 
> > > > > So, this is rather odd.
> > > > > 
> > > > > I assume this is under timed commands, yes?  What happens if you
> > > > > don't
> > > > > use timed commands--just to check to see
> > > > >     if the DSP frequency change is getting skipped under timed
> > > > > commands?
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> > 



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 UBX digital tune not occurring?

2020-11-23 Thread Marcus D Leech via USRP-users 
Could you confirm which version of UHD you’re using?

There has historically been a problem using both TwinRx and UBX on the same 
X310 due to clocking requirement conflicts. 

But that has been fixed in UHD4

Want to eliminate that as a possibility first. 

Sent from my iPhone

> On Nov 23, 2020, at 11:42 AM, Dustin Widmann  wrote:
> 
> Marcus,
> 
> I do have access to sig gens, but I would have to take everything into town 
> to do that. (sanest thing to do during covid
> was to bring portable things home...)
> 
> What I do have handy though is a spectrum analyzer (albeit, not a 
> particularly good one, but when working with a narrow
> span it should be able to give results that are good enough)
> 
> What I observed is this:
> tx freq MHz meas freq [MHz] deviation [Hz] 60.050  60.048800  
>   1200
> 61.050  61.050100   -100
> 62.050  62.051200   -1200
> 63.050  63.052533   -2533
> 64.050  64.053600   -3600
> 65.050  65.054933   -4933
> 66.050  66.0440006000
> 67.050  67.0450674933
> 68.050  68.. Missed this one
> 69.050  69.0477332267
> 70.050  70.0488001200
> 
> 
> For reference, what I observed with the twinrx was as follows
> freqtarget bin/freq actual bin/freq diff bin/freq  dsp 
> freq 
> 60MHz   524.288 (50e3)  512 (48,828) 12.288 (1,172)  1160 
>   
> 61MHz   524.288 (50e3)  525 (50,068) -0.712 (-68) -61 
>   
> 62MHz   524.288 (50e3)  538 (51,308)-13.712 (-1,308)-1282 
>   
> 63MHz   524.288 (50e3)  551 (52,547)-26.712 (-2,547)-2503 
>   
> 64MHz   524.288 (50e3)  563 (53,692)-38.712 (-3,692)-3724 
>   
> 65MHz   524.288 (50e3)  576 (54,932)-51.712 (-4,932)-4945 
>   
> 66MHz   524.288 (50e3)  461 (43,964) 63.288 (6,036)  6044 
>   
> 
> Having taken the TwinRX out of the loop, it seems I'm getting very similar 
> results. 
> 
> Dustin
> 
> 
>> On Sat, 2020-11-21 at 13:43 -0500, Marcus D. Leech wrote:
>>> On 11/21/2020 08:28 AM, Dustin Widmann wrote:
>>> Marcus,
>>> 
>>> I tried it without timed commands last night. It was landing on the
>>> same frequencies as it did with timed commands i.e. didn't fix that
>>> problem.
>>> 
>>> Dustin
>> OK, thanks for doing the test.
>> 
>> I wonder if you have a precise signal generator so you can confirm
>> that 
>> the RX side is on-frequency?
>> 
>> 
>>> 
>>> On Wed, 2020-11-18 at 20:05 -0500, Marcus D. Leech wrote:
 On 11/18/2020 07:34 PM, Dustin Widmann wrote:
> On Wed, 2020-11-18 at 18:27 -0500, Marcus D. Leech via USRP-
> users
> wrote:
> Marcus,
> 
> Oh, sorry, I missed the first bit. I'm using the on-board
> clock.
> And
> perhaps I should explain the table with a little bit more
> detail:
> * 1st col: The *target* frequency. The RX was tuned to this
> frequency.
> The TX was tuned to that frequency + an offset (in this case,
> 50KHz
> for
> all datapoints).
> * 2nd col: Where the tone is expected to land, both bin and
> (baseband)
> frequency; in this case, a 50KHz offset for all datapoints,
> which
> corresponded to bin 524 with a 2^20 FFT.
> * 3rd col: where the tone was observed (both bin and
> frequency).
> * 4th col: difference between the target and expectation
> * 5th col: dsp freq (from uhd::tune_result_t.actual_dsp_freq)
> * 6th col: what the difference would be if I offset the
> observed
> frequency by the claimed dsp frequency
> 
> Dustin
> 
 Right, I understand the chart now.
 
 So, this is rather odd.
 
 I assume this is under timed commands, yes?  What happens if you
 don't
 use timed commands--just to check to see
 if the DSP frequency change is getting skipped under timed
 commands?
 
 
 
>>> 
>> 
> 
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 UBX digital tune not occurring?

2020-11-23 Thread Dustin Widmann via USRP-users 
Marcus,

I do have access to sig gens, but I would have to take everything into town to 
do that. (sanest thing to do during covid
was to bring portable things home...)

What I do have handy though is a spectrum analyzer (albeit, not a particularly 
good one, but when working with a narrow
span it should be able to give results that are good enough)

What I observed is this:
tx freq MHz meas freq [MHz] deviation [Hz] 60.050  60.048800
1200
61.050  61.050100   -100
62.050  62.051200   -1200
63.050  63.052533   -2533
64.050  64.053600   -3600
65.050  65.054933   -4933
66.050  66.0440006000
67.050  67.0450674933
68.050  68.. Missed this one
69.050  69.0477332267
70.050  70.0488001200


For reference, what I observed with the twinrx was as follows
freqtarget bin/freq actual bin/freq diff bin/freq  dsp freq 
60MHz   524.288 (50e3)  512 (48,828) 12.288 (1,172)  1160   
61MHz   524.288 (50e3)  525 (50,068) -0.712 (-68) -61   
62MHz   524.288 (50e3)  538 (51,308)-13.712 (-1,308)-1282   
63MHz   524.288 (50e3)  551 (52,547)-26.712 (-2,547)-2503   
64MHz   524.288 (50e3)  563 (53,692)-38.712 (-3,692)-3724   
65MHz   524.288 (50e3)  576 (54,932)-51.712 (-4,932)-4945   
66MHz   524.288 (50e3)  461 (43,964) 63.288 (6,036)  6044   

Having taken the TwinRX out of the loop, it seems I'm getting very similar 
results. 

Dustin


On Sat, 2020-11-21 at 13:43 -0500, Marcus D. Leech wrote:
> On 11/21/2020 08:28 AM, Dustin Widmann wrote:
> > Marcus,
> > 
> > I tried it without timed commands last night. It was landing on the
> > same frequencies as it did with timed commands i.e. didn't fix that
> > problem.
> > 
> > Dustin
> OK, thanks for doing the test.
> 
> I wonder if you have a precise signal generator so you can confirm
> that 
> the RX side is on-frequency?
> 
> 
> > 
> > On Wed, 2020-11-18 at 20:05 -0500, Marcus D. Leech wrote:
> > > On 11/18/2020 07:34 PM, Dustin Widmann wrote:
> > > > On Wed, 2020-11-18 at 18:27 -0500, Marcus D. Leech via USRP-
> > > > users
> > > > wrote:
> > > > Marcus,
> > > > 
> > > > Oh, sorry, I missed the first bit. I'm using the on-board
> > > > clock.
> > > > And
> > > > perhaps I should explain the table with a little bit more
> > > > detail:
> > > > * 1st col: The *target* frequency. The RX was tuned to this
> > > > frequency.
> > > > The TX was tuned to that frequency + an offset (in this case,
> > > > 50KHz
> > > > for
> > > > all datapoints).
> > > > * 2nd col: Where the tone is expected to land, both bin and
> > > > (baseband)
> > > > frequency; in this case, a 50KHz offset for all datapoints,
> > > > which
> > > > corresponded to bin 524 with a 2^20 FFT.
> > > > * 3rd col: where the tone was observed (both bin and
> > > > frequency).
> > > > * 4th col: difference between the target and expectation
> > > > * 5th col: dsp freq (from uhd::tune_result_t.actual_dsp_freq)
> > > > * 6th col: what the difference would be if I offset the
> > > > observed
> > > > frequency by the claimed dsp frequency
> > > > 
> > > > Dustin
> > > > 
> > > Right, I understand the chart now.
> > > 
> > > So, this is rather odd.
> > > 
> > > I assume this is under timed commands, yes?  What happens if you
> > > don't
> > > use timed commands--just to check to see
> > >     if the DSP frequency change is getting skipped under timed
> > > commands?
> > > 
> > > 
> > > 
> > 
> 



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP E100/E110 linux update

2020-11-23 Thread Sébastien DI MERCURIO via USRP-users 

Hi Philips,

thank you for your answer. I will have a look to your git repository. 
I'm not very good with linux kernel intrinsics but I will try to have 
driver work with newer kernel.


If I succed, i will post my results.

Thank you !

Le 23/11/2020 à 14:10, Philip Balister a écrit :

On 11/23/20 7:09 AM, Sébastien DI MERCURIO via USRP-users wrote:

Hi,

I've got several USRP E100/E110 with outdated Linux and Gnuradio
software on it. So I decided to build a Yocto image, more up-to-date and
succeeded in after several tries.
The new image boots and run a reasonable updated version of Linux and
Gnuradio.

But, because of Ettus proprietary kernel driver, I cannot connect to
FPGA and so the board is useless.

It's an open driver, just non of us remember how it works. I did find
the code:

https://github.com/balister/linux-omap-philip

The linux DMA architecture has likely changed, so the driver will need
work, but the code is out there. Let me know if you have questions, it
would be great to see these running. I'll answer as best I can. It has
been like 6-7 years since I last looked at it though.

Using it like an N-series is likely not possible. The fpga is connected
to the Overo via the GPMC (General Purpose Memory Controller).

Philip


My questions are:

- Did someone achieve to get an updated Linux base and Gnuradio
software, with working FPGA communications (whatever the method)
   - Is it possible to get source code of Ettus kernel driver, as the
board is now End-of-life
   - Is it possible to enable Ethernet communication pass-throughto
FPGA, a bit like in N series, in order to use it over Ethernet(not
standalone)

Regards!

Sebastien









.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


--
INSA Toulouse

*Sébastien DI MERCURIO*
*Ingénieur d'étude Systèmes embarqués et IoT*
Département GEI
Tél. : 05 61 55 98 34
dimer...@insa-toulouse.fr 

INSA Toulouse
135 avenue de Rangueil
31077 Toulouse CEDEX 04
*www.insa-toulouse.fr *
**

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Poor Data Rates with the USRP E312

2020-11-23 Thread Philip Balister via USRP-users 
With the downloaded images for UHD-4.0 I saw a couple of things:

1) The CPU clock speed is set for speed grade 1 parts, not speed grade 3.
2) UHD-4.0 hangs after a while at higher data rates, I've also seen this
on a b200.

If there are fixes for these issues, you might get a bit more transfer
rate. Not sure it will get you the speed you need though.

Philip

On 11/22/20 9:20 PM, Joe Crossen wrote:
>  Hi all,
> 
> I'm attempting to use the USRP E312 as a wifi node using the gr-ieee802.11
> module...
> though for now I'm testing basic USRP functionality with a couple of simple
> GNU graphs.
> 
> Here's my setup:
> - the host is an Ubuntu 18.04 virtual machine with a bridged adaptor.
> Firewall disabled.
> - the USRP is the E312, connected via ethernet to the host network.
> - the host and USRP are both running GR3.8 and UHD4.0 (Zeus branch).
> - the host can see the USRP with uhd_usrp_probe.
> - the USRP is running the following GNU graph - UHD:USRP Source -> UDP Sink.
> - host is running the following GNU graph - UDP Source -> QT GUI Sink.
> - all block parameters are default.
> 
> I'm experiencing the following issues:
> 1. For sample rates > ~2Msps, the USRP spams overrun "O" and "D" characters
> (what does the "D" signify?) , regardless of whether the host graph is
> running or not.
> 2. At any sample rate the host graph spams the following message (when the
> USRP graph is running) - "gr::log :WARN: udp_source0 - Too much data;
> dropping packet."
> 
> And a question:
> 3. What sample rates are realistic for this setup, and what are the
> limitations? wifi channels span 20MHz, so I'm hoping to run at 20Msps
> 
> Thanks,
> Joe
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP E100/E110 linux update

2020-11-23 Thread Philip Balister via USRP-users 
On 11/23/20 7:09 AM, Sébastien DI MERCURIO via USRP-users wrote:
> Hi,
> 
> I've got several USRP E100/E110 with outdated Linux and Gnuradio
> software on it. So I decided to build a Yocto image, more up-to-date and
> succeeded in after several tries.
> The new image boots and run a reasonable updated version of Linux and
> Gnuradio.
> 
> But, because of Ettus proprietary kernel driver, I cannot connect to
> FPGA and so the board is useless.

It's an open driver, just non of us remember how it works. I did find
the code:

https://github.com/balister/linux-omap-philip

The linux DMA architecture has likely changed, so the driver will need
work, but the code is out there. Let me know if you have questions, it
would be great to see these running. I'll answer as best I can. It has
been like 6-7 years since I last looked at it though.

Using it like an N-series is likely not possible. The fpga is connected
to the Overo via the GPMC (General Purpose Memory Controller).

Philip

> 
> My questions are:
> 
> - Did someone achieve to get an updated Linux base and Gnuradio
> software, with working FPGA communications (whatever the method)
>   - Is it possible to get source code of Ettus kernel driver, as the
> board is now End-of-life
>   - Is it possible to enable Ethernet communication pass-throughto
> FPGA, a bit like in N series, in order to use it over Ethernet(not
> standalone)
> 
> Regards!
> 
> Sebastien
> 
> 
> 
> 
> 
> 
> 
> 
> 
> .
> 
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP E100/E110 linux update

2020-11-23 Thread Sébastien DI MERCURIO via USRP-users 

Hi,

I've got several USRP E100/E110 with outdated Linux and Gnuradio 
software on it. So I decided to build a Yocto image, more up-to-date and 
succeeded in after several tries.
The new image boots and run a reasonable updated version of Linux and 
Gnuradio.


But, because of Ettus proprietary kernel driver, I cannot connect to 
FPGA and so the board is useless.


My questions are:

- Did someone achieve to get an updated Linux base and Gnuradio 
software, with working FPGA communications (whatever the method)
  - Is it possible to get source code of Ettus kernel driver, as 
the board is now End-of-life
  - Is it possible to enable Ethernet communication pass-throughto 
FPGA, a bit like in N series, in order to use it over Ethernet(not 
standalone)


Regards!

Sebastien









.

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com