[USRP-users] configure usrp to communicate with external pll-gpsdo

2021-09-14 Thread msfu
hello,


i have got a usrp b210 and am trying to sync it with my external
pll-gpsdo 10MHz 1 pps.

i tried the commands in the ettus manual for Device Synchronization, but
no luck.

Can somebody help me out?

thanks in advance
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: configure usrp to communicate with external pll-gpsdo

2021-09-14 Thread Marcus D Leech
What exact commands what exact results?



Sent from my iPhone

> On Sep 14, 2021, at 7:14 AM, msfu  wrote:
> 
> hello,
> 
> 
> i have got a usrp b210 and am trying to sync it with my external
> pll-gpsdo 10MHz 1 pps.
> 
> i tried the commands in the ettus manual for Device Synchronization, but
> no luck.
> 
> Can somebody help me out?
> 
> thanks in advance
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: setting lenght of fft RFNoC UHD 4

2021-09-14 Thread Rob Kossler
Hi Ivan,
If your issues are still the following: streaming works fine for FFT length
256, but causes streaming errors at FFT lengths 512 and above, the issue is
very likely related to the packet length that the FFT block produces.

The stock RFNoC FFT block from Ettus asserts TLAST on the final FFT sample,
which makes the packet length equal to the FFT length.  For a 512 point
FFT, this means that the number of bytes in a packet is 2048+header_bytes.
This is a problem if the interface MTU is less than that (often at 1500).
So, the answer is to figure out how to get the interface MTU set to a
larger value.  If that is not possible, then the answer is to modify the
FFT block so that the packet length is not dependent on the FFT size. For
example, the FFT block could assert TLAST every 256 samples, independent of
the actual FFT length.  There are old posts about this if you search the
archive.
Rob


On Mon, Sep 13, 2021 at 5:30 PM Marcus D. Leech 
wrote:

> On 2021-09-13 2:29 p.m., Ivan Zahartchuk wrote:
>
> Tell me how to create a yaml file for such a graph correctly? I tried like 
> this but I get errors. I have not found such examples.
>
>
> Please copy user-users on these e-mails.  Others may have better insights
> than myself on these things, and bringing in the wider
>   community is always a good idea.
>
> The phrase "but I get errors" isn't terribly useful unless those errors
> are included in the problem report.  I MAY or MAY NOT be able
>   to help, since I'm not an RFNOC user or developer.  But without those
> errors available to the people you're asking for help,
>   it's pretty tough to do ANYTHING.
>
>
> ср, 8 сент. 2021 г. в 02:13, Marcus D. Leech :
>
>> On 2021-09-07 5:55 p.m., Ivan Zahartchuk wrote:
>>
>> I am setting 256 points FFT with the following parameters:fft_amplitude = 
>> uhd.libpyuhd.rfnoc.fft_magnitude.MAGNITUDE_SQUAREDfft_direction = 
>> uhd.libpyuhd.rfnoc.fft_direction.FORWARDfft_shift = 
>> uhd.libpyuhd.rfnoc.fft_shift.NORMALAfter that I do abs and display the data. 
>> Tell me how to do it better? And do I need to set a different type for the 
>> array which is passed to the recv function when setting Mag ** 2?
>>
>> Actually, there IS a logpwr block in RFNOC.   I don't know exactly what
>> scaling strategy it uses.
>>
>> If I wanted to get power estimates out of an RFNOC FFT, I'd have:
>>
>> FFT(with MAG2)--->MOVING_AVG--->KEEP-ONE-IN-N   all inside RFNOC, and
>> then scale to my hearts content at leisurely rates on the host.
>>
>>
>>
>> ср, 8 сент. 2021 г. в 00:43, Marcus D. Leech :
>>
>>> On 2021-09-07 4:17 p.m., Ivan Zahartchuk wrote:
>>>
>>> Hello. There is any information on my question. I also noticed that if you 
>>> take the data after the FFT, then the sensitivity drops very much. I see a 
>>> -30 dBm signal but -60 dBm is no longer displayed.
>>>
>>> How are you scaling and displaying your FFT output?  What options do you
>>> have set on your FFT?  DO you have it using Mag**2, how do you scale it
>>>   after that?
>>>
>>>
>>>
>>> сб, 4 сент. 2021 г. в 00:04, Ivan Zahartchuk :
>>>
 Here is my script. I am trying to read different amounts of data from DDC 
 and from FFT.Are there any new statements on my question?


 чт, 2 сент. 2021 г. в 10:06, Jonathon Pendlum <
 jonathon.pend...@ettus.com>:

> Great, thanks. Can you also share your latest python script?
>
> Jonathon
>
> On Wed, Sep 1, 2021 at 6:37 PM Ivan Zahartchuk 
> wrote:
>
>> Yes, I can try it but next week. But I still wanted to do FFT on FPGA. 
>> And one more question. Is it possible to create two streamers and read 
>> 256 samples one at a time and another 8192 for example? I want to do FFT 
>> on one channel and start a stream with DDC for demodulation on the 
>> other. What is possible?
>>
>>
>> ср, 1 сент. 2021 г. в 21:09, Jonathon Pendlum <
>> jonathon.pend...@ettus.com>:
>>
>>> Hi Ivan,
>>>
>>> Can you try running your script with the SPP set to 512 and without
>>> the FFT block, i.e. Radio -> Rx Streamer? This may be a general issue 
>>> with
>>> SPP unrelated to the FFT. I'm getting the same "Bad CHDR packet" error 
>>> on a
>>> different device with the FIR filter block, but it goes away when I 
>>> remove
>>> the block.
>>>
>>> Jonathon
>>>
>>> On Mon, Aug 30, 2021 at 3:46 PM Marcus D. Leech <
>>> patchvonbr...@gmail.com> wrote:
>>>
 On 2021-08-30 2:30 p.m., Ivan Zahartchuk wrote:




 Thanks. Still trying to work this out.  In UHD 4, the interface to
 the FPGA changed from a straightforward DMA implementation--done by 
 ADI for
   their IIO subsystem, to a driver that makes the FPGA/Radio "look"
 like a network device with an MTU of 9000.

 With an MTU that large, you should have no trouble with 512-bin
 FFTs.  But clearly, you are.

[USRP-users] Re: rfnoc 4.0 gain block tutorial --> register problem

2021-09-14 Thread Wade Fife
Hi Jeff,

I agree with Rob that "=" should be "<=" but I don't think that's causing
any harm here. I copied and pasted your code into the gain example and
tested it, and it seems to work as I expected. So there's probably
something wrong that's unrelated to that code snippet. Take a look at the
gain example to see what's different in yours. I would also suggest
simulating your code rather than resorting to chipscope. You can use the
example gain testbench as a starting point.

https://github.com/EttusResearch/uhd/blob/master/host/examples/rfnoc-example/fpga/rfnoc_block_gain/rfnoc_block_gain.v
https://github.com/EttusResearch/uhd/blob/master/host/examples/rfnoc-example/fpga/rfnoc_block_gain/rfnoc_block_gain_tb.sv

The reset should be asserted when the graph is first initialized, so you
should not be able to read the initial value of the register
(REG_USER_DEFAULT), only the reset value (REG_USER_DEFAULT2). If that reset
isn't happening then perhaps there's something wrong with the reset
connection or the clock connection. Also, it's usually good practice to
make the reset and initial value the same. Some FPGAs don't really support
them being different, although I think this is supported on Xilinx 7 Series.

Thanks,

Wade

On Mon, Sep 13, 2021 at 3:03 PM Rob Kossler  wrote:

> Hi Jeff,
> I am mostly a novice at FPGA development, but I have created a few blocks
> in rfnoc 4.0 with multiple registers and they seem to behave properly. One
> thing I noticed in your original post below is that when you assign the
> value REG_USER_DEFAULT2, you use "=" rather than "<=". It seems it should
> be the latter.  I don't really know what issues, if any, this would cause.
> Rob
>
> On Mon, Sep 13, 2021 at 1:07 PM Hodges, Jeff via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I'm now convinced there is something majorly wrong with UHD4.0
>> controlport.  Not only am I experiencing the issue I have described here
>> but if I create an image with two write registers (0x0 and 0x4) it works,
>> but if I create two write registers addresses of 0x4 and 0x8, it fails both
>> read and write.
>>
>>
>> Is anyone using this UHD4.0? I never had these problems with UHD3.15.  I'm
>> building for the X310.
>>
>>
>> I can try to debug with chipscope but that is a pain and would rather not
>> do waste time if someone else has already identified the source of this
>> problem.
>>
>>
>> Thanks,
>>
>>
>> Jeff
>> --
>> *From:* Hodges, Jeff via USRP-users 
>> *Sent:* Monday, September 13, 2021 11:48:06 AM
>> *To:* usrp-users@lists.ettus.com
>> *Subject:* [USRP-users] Re: rfnoc 4.0 gain block tutorial --> register
>> problem
>>
>>
>> I can read and write from register addr 0x0 but the default value read
>> from peek32(0x0) is 0 regardless of what I set the REG_USER_DEFAULT value
>> to.
>>
>>
>> This only occurs on register addr 0x0.
>>
>>
>> Jeff
>>
>>
>> --
>> *From:* Hodges, Jeff via USRP-users 
>> *Sent:* Saturday, September 11, 2021 5:02 PM
>> *To:* usrp-users@lists.ettus.com
>> *Subject:* [USRP-users] rfnoc 4.0 gain block tutorial --> register
>> problem
>>
>>
>> Following the gain block tutorial from GRCON20, when I read from the
>> registers using gain_block->regs().peek32(0x0), the default value that is
>> return is not the same as set during reset. The default value I read is
>> always 0 even when my verilog sets it to some other value after rebuilding
>> the image.
>>
>>
>> Has anyone seen this behavior?
>>
>>
>> Also i am having problems with other FPGA builds involving the registers
>> to please tell me if something is wrong with rfnoc 4.0 controlport.
>>
>> All i've done is taken the default gain block and added another default
>> value after reset:
>>
>>
>>
>>   localparam REG_USER_ADDR= 0; // Address for example user register
>>   localparam REG_USER_DEFAULT = 1; // Default value for user register
>>   localparam REG_USER_DEFAULT2 = 2; //Default value for user register
>> after reset
>>
>>   reg [31:0] reg_user = REG_USER_DEFAULT;
>>
>>   always @(posedge ctrlport_clk) begin
>> if (ctrlport_rst) begin
>>   reg_user = REG_USER_DEFAULT2;
>> end else begin
>>   // Default assignment
>>   m_ctrlport_resp_ack <= 0;
>>
>>   // Read user register
>>   if (m_ctrlport_req_rd) begin // Read request
>> case (m_ctrlport_req_addr)
>>   REG_USER_ADDR: begin
>> m_ctrlport_resp_ack  <= 1;
>> m_ctrlport_resp_data <= reg_user;
>>   end
>> endcase
>>   end
>>
>>   // Write user register
>>   if (m_ctrlport_req_wr) begin // Write requst
>> case (m_ctrlport_req_addr)
>>   REG_USER_ADDR: begin
>> m_ctrlport_resp_ack <= 1;
>> reg_user<= m_ctrlport_req_data[31:0];
>>   end
>> endcase
>>   end
>> end
>>   end
>>
>>
>> Jeff
>> ___
>> USRP-users mailing list -- usrp-users@lists.

[USRP-users] Re: setting lenght of fft RFNoC UHD 4

2021-09-14 Thread Marcus D. Leech

On 2021-09-14 10:24 a.m., Rob Kossler wrote:

Hi Ivan,
If your issues are still the following: streaming works fine for FFT 
length 256, but causes streaming errors at FFT lengths 512 and above, 
the issue is very likely related to the packet length that the FFT 
block produces.


The stock RFNoC FFT block from Ettus asserts TLAST on the final FFT 
sample, which makes the packet length equal to the FFT length.  For a 
512 point FFT, this means that the number of bytes in a packet is 
2048+header_bytes.  This is a problem if the interface MTU is less 
than that (often at 1500).  So, the answer is to figure out how to get 
the interface MTU set to a larger value.  If that is not possible, 
then the answer is to modify the FFT block so that the packet length 
is not dependent on the FFT size. For example, the FFT block could 
assert TLAST every 256 samples, independent of the actual FFT length.  
There are old posts about this if you search the archive.

Rob


Thanks, Rob.

But we've already covered that territory--turns out there IS a bug in 
recent UHD with FFT and FIR (and other vector functions I think) lengths 
> 256, and a bug

  has been raised.




On Mon, Sep 13, 2021 at 5:30 PM Marcus D. Leech 
mailto:patchvonbr...@gmail.com>> wrote:


On 2021-09-13 2:29 p.m., Ivan Zahartchuk wrote:

Tell me how to create a yaml file for such a graph correctly? I
tried like this but I get errors. I have not found such examples.


Please copy user-users on these e-mails.  Others may have better
insights than myself on these things, and bringing in the wider
  community is always a good idea.

The phrase "but I get errors" isn't terribly useful unless those
errors are included in the problem report.  I MAY or MAY NOT be able
  to help, since I'm not an RFNOC user or developer.  But without
those errors available to the people you're asking for help,
  it's pretty tough to do ANYTHING.



ср, 8 сент. 2021 г. в 02:13, Marcus D. Leech
mailto:patchvonbr...@gmail.com>>:

On 2021-09-07 5:55 p.m., Ivan Zahartchuk wrote:

I am setting 256 points FFT with the following parameters:
fft_amplitude =
uhd.libpyuhd.rfnoc.fft_magnitude.MAGNITUDE_SQUARED
fft_direction = uhd.libpyuhd.rfnoc.fft_direction.FORWARD
fft_shift = uhd.libpyuhd.rfnoc.fft_shift.NORMAL After that I
do abs and display the data. Tell me how to do it better?
And do I need to set a different type for the array which is
passed to the recv function when setting Mag ** 2?

Actually, there IS a logpwr block in RFNOC.   I don't know
exactly what scaling strategy it uses.

If I wanted to get power estimates out of an RFNOC FFT, I'd have:

FFT(with MAG2)--->MOVING_AVG--->KEEP-ONE-IN-N   all inside
RFNOC, and then scale to my hearts content at leisurely rates
on the host.




ср, 8 сент. 2021 г. в 00:43, Marcus D. Leech
mailto:patchvonbr...@gmail.com>>:

On 2021-09-07 4:17 p.m., Ivan Zahartchuk wrote:

Hello. There is any information on my question. I also
noticed that if you take the data after the FFT, then
the sensitivity drops very much. I see a -30 dBm signal
but -60 dBm is no longer displayed.

How are you scaling and displaying your FFT output? 
What options do you have set on your FFT?  DO you have
it using Mag**2, how do you scale it
  after that?




сб, 4 сент. 2021 г. в 00:04, Ivan Zahartchuk
mailto:adray0...@gmail.com>>:

Here is my script. I am trying to read different
amounts of data from DDC and from FFT. Are there
any new statements on my question?


чт, 2 сент. 2021 г. в 10:06, Jonathon Pendlum
mailto:jonathon.pend...@ettus.com>>:

Great, thanks. Can you also share your latest
python script?

Jonathon

On Wed, Sep 1, 2021 at 6:37 PM Ivan Zahartchuk
mailto:adray0...@gmail.com>> wrote:

Yes, I can try it but next week. But I
still wanted to do FFT on FPGA. And one
more question. Is it possible to create two
streamers and read 256 samples one at a
time and another 8192 for example? I want
to do FFT on one channel and start a stream
with DDC for demodulation on the other.
What is possible?


ср, 1 сент. 2021 г. в 21:09, Jonathon
Pendlum mailto:jonathon.pend...@ettus.com>>:

Hi Ivan,

Can you try running your script with
the SPP set to 512 and without t

[USRP-users] Re: E320 Auto-Booting function not working?

2021-09-14 Thread thebouleoffools
Has this bug been addressed? My E320 also does not autoboot by setting this 
flag.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com