Re: [USRP-users] B210 -- AD9361 low-level access and changing filter configuration

[Rob Heig via USRP-users]

Hi,

I've figured out what I was doing wrong No set_filter() once the taps
are set (I mistakenly thought that this was implicitly done -- and checking
the source code of UHD confirmed that the sptr returned by get_filter() is
a sptr to a **copy** of the original filter, and not the actual one!)! :S
:S :S :S
Now it works like a charm Thanks again!!! :)
Rob

On 13 September 2017 at 07:11, Rob Heig  wrote:

> Hi,
> Thank you both for your help! :)
> I had started myself patching UHD for the job like Sylvain did, but that
> scared me a bit since I didn't want to stump on the feet of the library and
> risk having some strange behaviour, therefore I preferred to ask first ;)
> Have a nice day!
> Rob
>
> On 12 September 2017 at 22:15, Julian Arnold 
> wrote:
>
>> Hey,
>>
>> In case you haven't already adopted the straight forward approach
>> mentioned by
>> Sylvain I just dug out the tool I mentioned and moved
>> it to my github account [1].
>>
>> I quickly compiled and linked against a recent version of UHD (3.9.6) to
>> confirm that it still works.
>>
>> Build as usual:
>> mkdir build
>> cd build
>> cmake ..
>> make
>>
>> You can then run the "main" program as follows:
>>
>> ./main --list
>>
>> to see a list of all available filters with their corresponding paths.
>> Then, you can write new filter coefficients with:
>>
>> ./main --write_fir --path=
>> e.g.:
>> ./main --write_fir --path=/mboards/0/dboards/A/rx
>> _frontends/A/filters/FIR_1
>>
>> this will update the coefficients of FIR_1 and then read the filter again
>> to
>> check if the coefficients have been updated.
>> However, the tool is definitely not polished in any way and does not check
>> whether or not the new coefficients actually take effect.
>> If they still don't then let me know and I'll try to create a more
>> complete
>> example application.
>>
>> [1] https://github.com/jarn0ld/uhd-filter-tool
>>
>> Cheers,
>> Julian
>>
>> On Tuesday, September 12, 2017 5:16:56 PM CEST Sylvain Munaut wrote:
>> > Personally I'm using a patched UHD where I expose the SPI device :
>> >
>> >
>> > diff --git a/host/lib/usrp/b200/b200_impl.cpp
>> > b/host/lib/usrp/b200/b200_impl.cpp index a513e1336..01c1e3b51 100644
>> > --- a/host/lib/usrp/b200/b200_impl.cpp
>> > +++ b/host/lib/usrp/b200/b200_impl.cpp
>> > @@ -549,6 +549,8 @@ b200_impl::b200_impl(const uhd::device_addr_t&
>> > device_addr, usb_device_handle::s
>> >  _adf4001_iface = boost::make_shared> l_ctrl>(_spi_iface);
>> > }
>> >
>> > +_tree->create(mb_path / ("spi")).set(_spi_iface);
>> > +
>> >  
>> 
>> >  // Init codec - turns on clocks
>> >  
>> 
>> >
>> >
>> > Then in my code I can get the SPI object :
>> >
>> > uhd::spi_iface::sptr spi =
>> > usrp->get_device()->get_tree()->access
>> ("/mboards/0/spi
>> > ").get();
>> >
>> > and use read_spi / write_spi to control any register I want.
>> >
>> >
>> > Cheers,
>> >
>> > Sylvain
>>
>>
>> --
>> Julian Arnold, M.Sc.
>>
>> Institute for Networked Systems
>> RWTH Aachen University
>> Kackertstrasse 9
>> 52072 Aachen
>> Germany
>>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 -- AD9361 low-level access and changing filter configuration

[Rob Heig via USRP-users]

Hi,
Thank you both for your help! :)
I had started myself patching UHD for the job like Sylvain did, but that
scared me a bit since I didn't want to stump on the feet of the library and
risk having some strange behaviour, therefore I preferred to ask first ;)
Have a nice day!
Rob

On 12 September 2017 at 22:15, Julian Arnold  wrote:

> Hey,
>
> In case you haven't already adopted the straight forward approach
> mentioned by
> Sylvain I just dug out the tool I mentioned and moved
> it to my github account [1].
>
> I quickly compiled and linked against a recent version of UHD (3.9.6) to
> confirm that it still works.
>
> Build as usual:
> mkdir build
> cd build
> cmake ..
> make
>
> You can then run the "main" program as follows:
>
> ./main --list
>
> to see a list of all available filters with their corresponding paths.
> Then, you can write new filter coefficients with:
>
> ./main --write_fir --path=
> e.g.:
> ./main --write_fir --path=/mboards/0/dboards/A/
> rx_frontends/A/filters/FIR_1
>
> this will update the coefficients of FIR_1 and then read the filter again
> to
> check if the coefficients have been updated.
> However, the tool is definitely not polished in any way and does not check
> whether or not the new coefficients actually take effect.
> If they still don't then let me know and I'll try to create a more complete
> example application.
>
> [1] https://github.com/jarn0ld/uhd-filter-tool
>
> Cheers,
> Julian
>
> On Tuesday, September 12, 2017 5:16:56 PM CEST Sylvain Munaut wrote:
> > Personally I'm using a patched UHD where I expose the SPI device :
> >
> >
> > diff --git a/host/lib/usrp/b200/b200_impl.cpp
> > b/host/lib/usrp/b200/b200_impl.cpp index a513e1336..01c1e3b51 100644
> > --- a/host/lib/usrp/b200/b200_impl.cpp
> > +++ b/host/lib/usrp/b200/b200_impl.cpp
> > @@ -549,6 +549,8 @@ b200_impl::b200_impl(const uhd::device_addr_t&
> > device_addr, usb_device_handle::s
> >  _adf4001_iface = boost::make_shared pll_ctrl>(_spi_iface);
> > }
> >
> > +_tree->create(mb_path / ("spi")).set(_spi_iface);
> > +
> >  
> 
> >  // Init codec - turns on clocks
> >  
> 
> >
> >
> > Then in my code I can get the SPI object :
> >
> > uhd::spi_iface::sptr spi =
> > usrp->get_device()->get_tree()->access
> ("/mboards/0/spi
> > ").get();
> >
> > and use read_spi / write_spi to control any register I want.
> >
> >
> > Cheers,
> >
> > Sylvain
>
>
> --
> Julian Arnold, M.Sc.
>
> Institute for Networked Systems
> RWTH Aachen University
> Kackertstrasse 9
> 52072 Aachen
> Germany
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310 REF LED is blinking

[Jorge Chen via USRP-users]

Dear all

The LED of REF on the front panel of one of my X310 is blinking instead of
constantly lighting up while working,
that is, the reference clock is not able to be locked with other x310s (4x4
MIMO system).

I've checked the reference clock source is constantly output, and other
X310s works fine.
I also tried to re-load the image, but it didn't work.

Does anyone meet this situation before?
How can I solve/fix this?




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

Re: [USRP-users] How to Access a user register in fpga of X310 using UHD (3.10.2)

[Martin Braun via USRP-users]

multi_usrp has many APIs, not all apply for all devices.
enumerate_registers() is from USRP2-era.

I'm curious -- have you already done the FPGA work, or is this where
you're starting?

In general, registers are exposed via the RFNoC XML file (e.g.,
radio_x300.xml).

-- M


On 09/12/2017 02:04 PM, Taliver Heath via USRP-users wrote:
> And following up on this -- how do you enumerate the names of the
> registers?  They seem to be present in the code, but
> "enumerate_registers" doens't do anything:
> 
> void ListAllRegisters(uhd::usrp::multi_usrp::sptr usrp) {
>   auto list = usrp->enumerate_registers();
>   cout << "Register List (" << list.size() << "):\n";
>   for (auto register_name : usrp->enumerate_registers()) {
> cout << register_name
>  << " (field 0 value): " << usrp->read_register(register_name, 0)
>  << "\n";
>   }
> }
> 
> 
> ...
> [INFO] [RFNOC] pass (Throughput: 1304.5MB/s)
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [CORES] Performing timer loopback test... 
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test... 
> [INFO] [CORES] Timer loopback test passed
> Register List (0):
> 
> 
> On Tue, Sep 12, 2017 at 12:18 PM, Sugandha Gupta via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
> 
> Hi Karan
> 
> Take a look at the block_ctrl files
> here: https://github.com/EttusResearch/uhd/tree/maint/host/lib/rfnoc/ 
> .
> E.g. the ddc_block_ctrl_impl.cpp
> Use sr_write() to write to user implemented registers in the FPGA.
> 
> Hope this helps.
> 
> 
> On Thu, Aug 31, 2017 at 3:28 PM, Karan Suri via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
> 
> Hello Users
> I recently stumbled onto a problem. I need to implement a gain
> control mechanism by left shifting bits of the received data,
> when the rx power is considerably low. I need to define a
> settings register which controls the shift amount, but I need
> to  get access to this setting register using the C++ code.
> I am using the latest stable version of uhd and it seems that
> there is no proper documentation of the settings register for
> the X310. 
> It  barely talks about the peek and poke commands found in
> user_settings_core_3000.hpp. But i cant find any example which
> relates to this nor how to use it. Any help will be extremely
> appreciated.
> Thanks a ton
> Karan Suri
> University Of Michigan
> EECS - Masters
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> 
> 
> 
> -- 
> Sugandha Gupta
> Staff Software Engineer
> Ettus Research
> 
> ___
> 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] How to Access a user register in fpga of X310 using UHD (3.10.2)

[Taliver Heath via USRP-users]

And following up on this -- how do you enumerate the names of the
registers?  They seem to be present in the code, but "enumerate_registers"
doens't do anything:

void ListAllRegisters(uhd::usrp::multi_usrp::sptr usrp) {
  auto list = usrp->enumerate_registers();
  cout << "Register List (" << list.size() << "):\n";
  for (auto register_name : usrp->enumerate_registers()) {
cout << register_name
 << " (field 0 value): " << usrp->read_register(register_name, 0)
 << "\n";
  }
}


...
[INFO] [RFNOC] pass (Throughput: 1304.5MB/s)
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
Register List (0):


On Tue, Sep 12, 2017 at 12:18 PM, Sugandha Gupta via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Karan
>
> Take a look at the block_ctrl files here: https://github.com/
> EttusResearch/uhd/tree/maint/host/lib/rfnoc/. E.g. the
> ddc_block_ctrl_impl.cpp
> Use sr_write() to write to user implemented registers in the FPGA.
>
> Hope this helps.
>
>
> On Thu, Aug 31, 2017 at 3:28 PM, Karan Suri via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello Users
>> I recently stumbled onto a problem. I need to implement a gain control
>> mechanism by left shifting bits of the received data, when the rx power is
>> considerably low. I need to define a settings register which controls the
>> shift amount, but I need to  get access to this setting register using the
>> C++ code.
>> I am using the latest stable version of uhd and it seems that there is no
>> proper documentation of the settings register for the X310.
>> It  barely talks about the peek and poke commands found in
>> user_settings_core_3000.hpp. But i cant find any example which relates to
>> this nor how to use it. Any help will be extremely appreciated.
>> Thanks a ton
>> Karan Suri
>> University Of Michigan
>> EECS - Masters
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
> Sugandha Gupta
> Staff Software Engineer
> Ettus Research
>
> ___
> 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] B210 -- AD9361 low-level access and changing filter configuration

[Julian Arnold via USRP-users]

Hey,

In case you haven't already adopted the straight forward approach mentioned by
Sylvain I just dug out the tool I mentioned and moved
it to my github account [1].

I quickly compiled and linked against a recent version of UHD (3.9.6) to 
confirm that it still works.

Build as usual:
mkdir build
cd build
cmake ..
make

You can then run the "main" program as follows:

./main --list

to see a list of all available filters with their corresponding paths.
Then, you can write new filter coefficients with:

./main --write_fir --path=
e.g.:
./main --write_fir --path=/mboards/0/dboards/A/rx_frontends/A/filters/FIR_1

this will update the coefficients of FIR_1 and then read the filter again to 
check if the coefficients have been updated.
However, the tool is definitely not polished in any way and does not check 
whether or not the new coefficients actually take effect. 
If they still don't then let me know and I'll try to create a more complete 
example application.

[1] https://github.com/jarn0ld/uhd-filter-tool

Cheers,
Julian

On Tuesday, September 12, 2017 5:16:56 PM CEST Sylvain Munaut wrote:
> Personally I'm using a patched UHD where I expose the SPI device :
> 
> 
> diff --git a/host/lib/usrp/b200/b200_impl.cpp
> b/host/lib/usrp/b200/b200_impl.cpp index a513e1336..01c1e3b51 100644
> --- a/host/lib/usrp/b200/b200_impl.cpp
> +++ b/host/lib/usrp/b200/b200_impl.cpp
> @@ -549,6 +549,8 @@ b200_impl::b200_impl(const uhd::device_addr_t&
> device_addr, usb_device_handle::s
>  _adf4001_iface = boost::make_shared(_spi_iface);
> }
> 
> +_tree->create(mb_path / ("spi")).set(_spi_iface);
> +
>  
>  // Init codec - turns on clocks
>  
> 
> 
> Then in my code I can get the SPI object :
> 
> uhd::spi_iface::sptr spi =
> usrp->get_device()->get_tree()->access("/mboards/0/spi
> ").get();
> 
> and use read_spi / write_spi to control any register I want.
> 
> 
> Cheers,
> 
> Sylvain


-- 
Julian Arnold, M.Sc.

Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany

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

Re: [USRP-users] problem with RFNoC block not outputting

[Jason Matusiak via USRP-users]

OK, I think that I have solved it. A vector size of 2048 seems to not 
work in RFNoC, no matter who wrote the block.  When I dial back to 256 
that seems to work.  I changed my block to output a tlast every 256 
samples, and data passes through fine now.


Is there a way to make 2048 work in RFNoC?  Is it an Ethernet frame 
issue?  I feel like somewhere back in the day I heard that all the data 
needs to fit into a frame size, so maybe 1024 is a max frame size in 
this case...



On 09/11/2017 03:06 PM, Jason wrote:
One other piece of information.  It seems like I always get hung up on 
the same output sample, 6905860.  I noticed that that is almost 
exactly 3372 packets of 2048 sample vectors.  Is there a set number of 
samples that can be buffered before the system stops?  I set the MTU 
to be 11 in the axi_wrapper parameter list, but no dice.


When I get stuck in this state (and it is always is the same way), 
i_tvalid is high, and i_tready is low (because I am stalled waiting on 
my output to catch up).  o_tvalid is high and o_tready is low. For 
some reason o_tready never goes high at this point.



On 09/11/2017 02:05 PM, Jason wrote:
I have a block that I've been working on and it seems like I am 
missing something vital to get it to work properly.  My block takes 
in a vector of 2048 samples and outputs 2048 samples as well.  I 
simulated it and it passes simulation fine.


But, if I look at the output as it goes to a file, nothing goes 
through.  I opened up wireshark and I see 11-12 packets comes from my 
PC to RFNoC, and then 1 60B packet going RFNoC to host, 1 58B from 
host to RFNoC, and then another 60B from RFNoC to host 
(wash-rinse-repeat).


The packets to the host seem to be incrementing as they should, but 
are obviously not full packets.  An example of two packets from RFNoC 
to host are:

00:00:00:05:00:00:04:dd:00:00:60:18:59:b6:cb:0b
00:00:00:05:00:00:04:de:00:00:60:1c:ca:77:b6:11

I have noticed that if I don't use my block and just have data pass 
through the FIFO, I still don't see data pass through, so I am 
wondering if the crossbar is getting screwed up somehow.





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

Re: [USRP-users] How to Access a user register in fpga of X310 using UHD (3.10.2)

[Sugandha Gupta via USRP-users]

Hi Karan

Take a look at the block_ctrl files here:
https://github.com/EttusResearch/uhd/tree/maint/host/lib/rfnoc/. E.g. the
ddc_block_ctrl_impl.cpp
Use sr_write() to write to user implemented registers in the FPGA.

Hope this helps.


On Thu, Aug 31, 2017 at 3:28 PM, Karan Suri via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Users
> I recently stumbled onto a problem. I need to implement a gain control
> mechanism by left shifting bits of the received data, when the rx power is
> considerably low. I need to define a settings register which controls the
> shift amount, but I need to  get access to this setting register using the
> C++ code.
> I am using the latest stable version of uhd and it seems that there is no
> proper documentation of the settings register for the X310.
> It  barely talks about the peek and poke commands found in
> user_settings_core_3000.hpp. But i cant find any example which relates to
> this nor how to use it. Any help will be extremely appreciated.
> Thanks a ton
> Karan Suri
> University Of Michigan
> EECS - Masters
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


-- 
Sugandha Gupta
Staff Software Engineer
Ettus Research
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] 4 Rx channels from an X310

[Derek Kozel via USRP-users]

Hello Joshua,

The default FPGA image now has two DDCs which each have two DSP chains. The
message you link to is from 2014 and we've substantially updated the
contents of the FPGA since then. Currently the TwinRX is the primary
daughtercard making use of these additional DDC chains as the others are
1RX per daughtercard.

Regards,
Derek

On Tue, Sep 12, 2017 at 3:15 AM, Josh Sendall via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I have been looking through some previous posts on the mailing list, for
> example [USRP-users] subdev spec for two channels with USRP X310
> 
> which suggests that it should not be possible to receive 4 channels (with
> the standard FPGA image and UHD) on an X300/X310, due to them only having 2
> DDC blocks.
>
> However I then saw this project 
> (gr-doa),
> which seems to suggest that, using the standard FPGA image, one can run 4
> channels using 2 TwinRx daughter boards. Would that not still require 4 DDC
> blocks, or can a DDC block be configured to process 2 real streams?
>
> Kind regards,
> Joshua Sendall
>
>
> *Joshua Sendall*
> *Radar Signal Analyst*
> Defense, Peace, Safety and Security (DPSS)
> Council for Scientific and Industrial Research (CSIR)
> Building 44 - Room C 433
> CSIR, Meiring Naude Road, Pretoria
> Tel: *012 841 3575*
>
>
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at http://www.csir.co.za/
> disclaimer.html.
>
> Please consider the environment before printing this email.
>
> ___
> 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] B210 -- AD9361 low-level access and changing filter configuration

[Sylvain Munaut via USRP-users]

Personally I'm using a patched UHD where I expose the SPI device :


diff --git a/host/lib/usrp/b200/b200_impl.cpp b/host/lib/usrp/b200/b200_impl.cpp
index a513e1336..01c1e3b51 100644
--- a/host/lib/usrp/b200/b200_impl.cpp
+++ b/host/lib/usrp/b200/b200_impl.cpp
@@ -549,6 +549,8 @@ b200_impl::b200_impl(const uhd::device_addr_t&
device_addr, usb_device_handle::s
 _adf4001_iface = boost::make_shared(_spi_iface);
 }

+_tree->create(mb_path / ("spi")).set(_spi_iface);
+
 
 // Init codec - turns on clocks
 


Then in my code I can get the SPI object :

uhd::spi_iface::sptr spi =
usrp->get_device()->get_tree()->access("/mboards/0/spi").get();

and use read_spi / write_spi to control any register I want.


Cheers,

Sylvain

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

[USRP-users] 4 Rx channels from an X310

[Josh Sendall via USRP-users]

Hi all,

I have been looking through some previous posts on the mailing list, for 
example [USRP-users] subdev spec for two channels with USRP X310
( 
http://http//lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-July/010010.html)
  which suggests that it should not be possible to receive 4 channels (with the 
standard FPGA image and UHD) on an X300/X310, due to them only having 2 DDC 
blocks.

However I then saw this project 
( https://github.com/EttusResearch/gr-doa) (gr-doa), which seems to suggest 
that, using the standard FPGA image, one can run 4 channels using 2 TwinRx 
daughter boards. Would that not still require 4 DDC blocks, or can a DDC block 
be configured to process 2 real streams?

Kind regards,
Joshua Sendall 


Joshua Sendall
Radar Signal Analyst
Defense, Peace, Safety and Security (DPSS)
Council for Scientific and Industrial Research (CSIR) 
Building 44 - Room C 433
CSIR, Meiring Naude Road, Pretoria 
Tel: 012 841 3575




--

This message is subject to the CSIR's copyright terms and conditions, e-mail 
legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at 
http://www.csir.co.za/disclaimer.html. 

Please consider the environment before printing this email. <>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] the transmitter cannot receive the acknowledgement from the receiver

[Mike McLernon via USRP-users]

Hi Seah,


Based on the error you're getting below, the coarse frequency offset (CFO) 
estimator is receiving a real signal when it will accept only a complex signal. 
 Cast that signal to be complex before it enters the CFO estimator, and you 
should eliminate that error.


Best,

Mike




From: USRP-users  on behalf of seah chong 
via USRP-users 
Sent: Tuesday, September 12, 2017 12:12 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] the transmitter cannot receive the acknowledgement from 
the receiver

Hi all,

Currently i'm doing a project to prove that the concurrent short signalling in 
real environment.

i am using MATLAB R2016A OS Ubuntu 14.04. USRP N210 using CBX daughterboards. i 
have succesfully generate MEX function by following R. Subramanian paper 
(https://github.com/80211bSDR/LinkLayer-MATLAB).

[https://avatars2.githubusercontent.com/u/17501905?v=4&s=400]

GitHub - 80211bSDR/LinkLayer-MATLAB: This work is 
...
github.com
LinkLayer-MATLAB - This work is supported by MathWorks under the 
Development-Collaboration Research Grant. We would appreciate a citation to our 
paper when this code ...




now, i'm try to run 1DTx (dtxPHYLayerVisual.m) and  1Rx(drxPHYLayerVisual.m). 
before running the 1DTx and 1DRx,we need to run the command below

i ) at the DTx

DTxInitParameters
swapFreqFlag = 0; %same channel operation
codegen transceiveXXX -args 
{complex(zeros(1408,1)),true,txGain,rxGain,centerFreqTx,centerFreqRx,decFactor, 
intFactor,swapFreqFlag}


ii) at the DRx

DRxInitParameters
codegen transceiveXXX -args 
{complex(zeros(1408,1)),true,txGain,rxGain,centerFreqTx,centerFreqRx,decFactor, 
intFactor}


after complete the step above,we found errors when running the 
1DTx(dtxPHYLayerVisual.m) and 1DRx (drxPHYLayerVisual.m). The error come out 
from DTxPHYlayerVisual.m as below:

@ 3.06: 802.11b DATA Packet #1 Transmitted.
xxx
Error using coder.internal.errorIf (line 8)
The input signal must be complex.

Error in comm.internal.CoarseFrequencyEstimatorBase/validateInputsImpl (line 70)
  coder.internal.errorIf(isreal(x), ...

Error in rffe (line 66)
ofs = step(he,ddf);

Error in dtxPHYLayerVisual>dtx_3ReceiveACK (line 453)
 dfr (1:halfUsrpFrameLength)= rffe(df,ft,cas,cau,cef);

Error in dtxPHYLayerVisual (line 81)
[faf,dfl,flg,nrb,rbs,st] = dtx_3ReceiveACK(df,ft,st);


>From these errors, we know that the transmitter cannot receive the 
>acknowledgement from the receiver. I've suspected these errors are due to 
>wrong declaration of IPaddress. Currently, I've setup the IP Address DTx is 
>192.168.10.2 and DRx is 192.168.10.20.is our 
>declaration is correct or not?


I hope someone can enlighten me either it is due to the IPaddress or other 
issues and can give me the solutions.


Regards,

ChongSeah


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

Re: [USRP-users] B210 -- AD9361 low-level access and changing filter configuration

[Rob Heig via USRP-users]

Hi Julian,

Sure, no hurry, thanks a lot!!! :)
Best,
RH

On 12 September 2017 at 12:12, Julian Arnold  wrote:

> Hey Rob,
>
> I remember creating a small example tool to use the filter API and to
> write to the RX FIR.
> If you can wait till the evening I'll dig it out at home and share it with
> you.
>
> Cheers,
> Julian
>
> Julian Arnold, M.Sc
> Institute for Networked Systems
> RWTH-Aachen University
> Kackertstrasse 9
> 52072 Aachen
> Germany
>
> > On 12. Sep 2017, at 07:01, Rob Heig via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >
> > Hi,
> >
> > I have been playing a bit with the API of UHD and I wonder if it is
> possible to have a low-level access to the underlying, low-level AD9361
> API. In effect, what I would love to do is to play with the filters (the RX
> FIR filter in particular), but so far I haven't been that lucky (all I've
> managed to do is to make the software crash badly).
> > In particular, I have experimented a bit with the set_taps() function
> call (after some very ugly casts), but either the system ignores it
> (re-reading the coefficients shows me that they're all zeros), or it makes
> the application crash (memory corruption).
> > Can anyone point me to a good direction (besides the UHD manual), please?
> > Thanks a lot in advance!
> > RH
> > ___
> > 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] B210 -- AD9361 low-level access and changing filter configuration

[Julian Arnold via USRP-users]

Hey Rob,

I remember creating a small example tool to use the filter API and to write to 
the RX FIR. 
If you can wait till the evening I'll dig it out at home and share it with you.

Cheers,
Julian

Julian Arnold, M.Sc
Institute for Networked Systems 
RWTH-Aachen University
Kackertstrasse 9
52072 Aachen
Germany

> On 12. Sep 2017, at 07:01, Rob Heig via USRP-users 
>  wrote:
> 
> Hi,
> 
> I have been playing a bit with the API of UHD and I wonder if it is possible 
> to have a low-level access to the underlying, low-level AD9361 API. In 
> effect, what I would love to do is to play with the filters (the RX FIR 
> filter in particular), but so far I haven't been that lucky (all I've managed 
> to do is to make the software crash badly).
> In particular, I have experimented a bit with the set_taps() function call 
> (after some very ugly casts), but either the system ignores it (re-reading 
> the coefficients shows me that they're all zeros), or it makes the 
> application crash (memory corruption).
> Can anyone point me to a good direction (besides the UHD manual), please?
> Thanks a lot in advance!
> RH
> ___
> 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] B210 -- AD9361 low-level access and changing filter configuration

[Rob Heig via USRP-users]

Hi again,

Some more info that I've gathered in the meantime on the issue:
- the crashes seem more related to the fact that I've been dumping the
retrieved I/Q pairs on file, so we could leave it out for the moment;
- what I did to test whether the FIR is working as expected or not, is to
retrieve its coefficients via the get_filter() function, cast the
filter_info_base pointer to a digital_filter_fir pointer using a
dynamic_pointer_cast, and then invoke the set_taps() function setting all
coefficients to zero. If I re-read immediately the coefficients, they're
all zeros as expected. However, reading them later shows that they're not
zeros anymore. Indeed, given this configuration I should receive an
identically null signal, but the signal seems to be untouched with respect
to the "standard FIR setting".

I could alter the UHD library (or the AD9361 driver) at "low level" to make
it behave as I expect, but I would rather stick with a more gentle approach.
Any idea?
Thanks again!
RH
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com