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. Re: recv packet demuxer unexpected sid 0x34343434 (Michael West)
2. Re: RFNOC: E310 RX Channel 2 out of Range (Neel Pandeya)
3. Re: AssertionError: block_def with X300 (Nicolas Cuervo)
4. Re: Long period, low-amplitude noise burst in receive during
active TDMA operation (B200mini) (Marcus D. Leech)
5. Re: Long period, low-amplitude noise burst in receive during
active TDMA operation (B200mini) (Steven Knudsen)
6. Re: About custom FPGA on X310 (liu Jong)
7. Re: About custom FPGA on X310 (liu Jong)
8. Re: About custom FPGA on X310 (Marcus M?ller)
9. Re: Cannot use UHD driver with RFNOC in Windows 10 (Pol Henarejos)
10. Re: AssertionError: block_def with X300 (Claudio Cicconetti)
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Oct 2016 09:52:59 -0700
From: Michael West <[email protected]>
To: Jackie Sun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] recv packet demuxer unexpected sid
0x34343434
Message-ID:
<cam4xkroqziqa3enlm++aa99dfqe3o5mvu640wx0zazpsrza...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jackie,
I was actually looking into this the other day. Setting the
recv_frame_size to 1024 on USB 3.0 (512 if using USB 2.0) seems to help. I
haven't fully root caused it, but I did find that I could use a larger
recv_frame_size if I used STREAM_MODE_NUM_SAMPS_AND_DONE instead of
STREAM_MODE_START_CONTINUOUS and aligned the number of samples with the
recv_frame_size. Try those workarounds and let me know if they work. I
will continue to work towards a full root cause and solution, but I am
juggling a few things right now so I am not sure how quick the solution
will come. If the workarounds don't work and you are blocked, let me know
and I will see about changing around priorities.
Best regards,
Michael
On Sun, Oct 9, 2016 at 11:42 PM, Jackie Sun via USRP-users <
[email protected]> wrote:
> Hi, I've got a shiny new USRP B200 r, factory provided USB 2 cable, and no
> GPSDO install. I just used PyBOMBS to build UHD 003.010.000 from git using
> the release tag. I remended the fpga code and extra some data to the fpga,I
> want to print the data in the terminal,I write a small demo,when i run the
> demo but then things stop working with a slew of messages emitted to the
> terminal window: ...
>
> UHD Error:
> recv packet demuxer unexpected sid 0x34343434
> D[recv] received 232 samples out of 1024
> [recv] received 0 samples out of 1024
> [recv] USRP RX OVERFLOW!
>
> UHD Error:
> recv packet demuxer unexpected sid 0x34343434
> D[recv] received 512 samples out of 1024
> [recv] received 0 samples out of 1024
> [recv] USRP RX OVERFLOW!
> How to solve the UHD Error,May someone help me.
> Thank you very much!
> Jackie.
>
>
>
>
>
>
>
> _______________________________________________
> 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/20161010/71ba562c/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 10 Oct 2016 10:08:27 -0700
From: Neel Pandeya <[email protected]>
To: Joshua Monson <[email protected]>
Cc: usrp-users <[email protected]>, Jonathon Pendlum
<[email protected]>
Subject: Re: [USRP-users] RFNOC: E310 RX Channel 2 out of Range
Message-ID:
<cacaxmv-t7q6uwdkepr3pwz9qiunaklfy6ey0hv3iavgp_0g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Josh:
Yes, this topology will work fine.
--Neel Pandeya
On 8 September 2016 at 12:52, Joshua Monson via USRP-users <
[email protected]> wrote:
> Hello,
>
>
>
> Is it possible to use usrp->get_tx/rx_stream() to create multiple stream
> objects that stream to different RFNOC blocks? For example, in the attached
> diagram I have three custom RFNOC blocks connected to the network (and the
> radio of course? which is not shown). The diagram show 4 stream objects (2
> tx, 2 rx). One tx/rx pair of these stream objects communicates with the a
> single RFNOC block (marked microblaze) in the diagram. The other tx stream
> allows the host to stream data to another RFNOC block (marked TX) which
> uses loops its data back to the host through another RNFOC block (marked
> RX) and accompanying rx stream.
>
>
>
> Does the UHD software allow this many streams to be setup on the E310 in
> such a configuration? If not, the exchanges between the host and the
> ?microblaze? block are small and intermittent. Is there another part of the
> uhd API that I could use to send small packages between the host and the
> register read and write interface?
>
>
>
> Thanks,
>
>
>
> Josh
>
> _______________________________________________
> 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/20161010/a63a45d5/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 10 Oct 2016 14:13:10 -0700
From: Nicolas Cuervo <[email protected]>
To: Claudio Cicconetti <[email protected]>
Cc: "[email protected]" <[email protected]>,
[email protected]
Subject: Re: [USRP-users] AssertionError: block_def with X300
Message-ID:
<caoupcvjhgxsmyl6jad83c15ri-vhaexkgjiddzqamgr9cta...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Claudio,
We recall having this issue with the installation from the packages, but
what is odd is that happening with the build from source.
Basically what is happening within the package installation is that some
*.xml files (if not all) were not being installed in the directories that
they were intended to. A TL;DR would be that packages installation is not
suited for 3.10 for now.
Would you please tell us what installation method are you using, and in
which OS? If this is stopping you from further advance in your application,
I would recommend you to make a clean install from the git sources
following this procedure:
https://kb.ettus.com/RFNoC_Getting_Started_Guides#Installing_UHD.2FRFNoC_Branch
And, if you do so and find the same issue still, please let us know. I ran
installation myself and couldn't reproduce your problem. The packages,
however, are showing this faulty behavior.
Cheers,
-N
On Sun, Oct 9, 2016 at 11:51 PM, Claudio Cicconetti <[email protected]
> wrote:
> Dear Nicolas,
> Yes, I ran the images downloader after building, then loaded the XG
> images (XG not present in < 3.10 releases), then power cycled the X300,
> then ran uhd_usrp_probe.
>
> I tried the XG images from the following sets:
>
> uhd-images_003.010.000.000-36-g967897e0
> uhd-images_003.010.000.000-release
>
> Btw, it seems I am not the only one to experience the same issue
> (http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2016-October/022160.html
> arrived half an hour later!).
>
> Best regards,
> Claudio
>
> On 10/07/2016 06:48 PM, Nicolas Cuervo wrote:
> > Hello Claudio,
> >
> > Just as a sanity check, did you run the images downloader after checking
> > out the release? If not, please check out to the branch that you want
> > (master or maint), then run the uhd_images_downloader, and then burn the
> > new image using jtag or the image loader (hd_images_downloader;
> > uhd_image_loader --args
> > type=x300,addr=[the IP addr of your device]
> >
> > You can differentiate the FPGA images from UHD 3.9.5 and 3.10 because
> from
> > the former they end in HGS.bit, while from the later they end in HG.bit.
> >
> > Please let us know if you still see this issue after that.
> >
> > Cheers,
> >
> > -Nicolas
> >
> > On Fri, Oct 7, 2016 at 3:45 AM, Claudio Cicconetti via USRP-users <
> > [email protected]> wrote:
> >
> >> Dear all,
> >> I am starting experimenting with RFNoC but I encountered the following
> >> blocking issue.
> >>
> >> As recommended in the "Testing the installation" section of the "RFNoC
> >> Getting Started Guides" I ran:
> >>
> >> $ uhd_usrp_probe --init-only
> >>
> >> but unfortunately I obtained the following error (full output at the
> >> bottom of this email):
> >>
> >> Error: AssertionError: block_def
> >> in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t,
> >> size_t, size_t, const uhd::sid_t&, uhd::device_addr_t,
> uhd::endianness_t)
> >> at /home/ccicconetti/uhd/host/lib/usrp/device3/device3_impl.cpp:148
> >>
> >> This happens both with 3.10.0.0-release (FW release 32), Ubuntu 16.04
> >> packages and compiled from source, and with the latest code from git
> >> rfnoc-devel branch (FW release 33).
> >>
> >> I have an X300 with a single WBX-120 and no GPSDO on board.
> >>
> >> The radio works perfectly fine with stable UHD versions until 3.9.5
> >> (both Ubuntu packages and compiled versions).
> >>
> >> Best regards,
> >> Claudio
> >>
> >> --
> >>
> >> Full output of 'uhd_usrp_probe --init-only':
> >>
> >> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> >> UHD_004.000.000.rfnoc-devel-641-g8773fb2c
> >>
> >> -- X300 initialization sequence...
> >> -- Determining maximum frame size... 8000 bytes.
> >> -- Setup basic communication...
> >> -- Loading values from EEPROM...
> >> -- Setup RF frontend clocking...
> >> -- Radio 1x clock:200
> >> -- [RFNOC] ------- Block Setup -----------
> >> -- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:30)...OK
> >> -- Port 48: Found NoC-Block with ID F1F0D00000000000.
> >> -- Using default block configuration.
> >> Error: AssertionError: block_def
> >> in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t,
> >> size_t, size_t, const uhd::sid_t&, uhd::device_addr_t,
> uhd::endianness_t)
> >> at /home/ccicconetti/uhd/host/lib/usrp/device3/device3_impl.cpp:148
> >>
> >> _______________________________________________
> >> 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/20161010/1c958689/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 10 Oct 2016 20:10:30 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Long period, low-amplitude noise burst in
receive during active TDMA operation (B200mini)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Steve:
Just saw this now. Have you been able to resolve this yourself, or is
this still a problem?
What if you put terminators on both TX/RX and RX2 ports, do you still
see these regular, low-amplitude "bursts" every few seconds?
On 09/29/2016 11:34 AM, Steven Knudsen via USRP-users wrote:
> Hi All,
>
> I have built a TDMA system that uses the B200mini. In doing a simple
> test to look at processing load for transceiver operation (B200mini
> transmits when it is told, otherwise is receiving), I noticed an
> interesting effect.
>
> When the transmit and receive carrier frequencies are the same (below,
> 100 MHz), every 5 seconds or so (but periodic) a slow-amplitude burst
> signal appears on the receive channel. The is no active transmission
> for that channel. Indeed, when contigured with transmit on TRX and
> receive on RX2, there isn?t even an antenna on the RX2.
>
> I first noticed the ?noise? on a time sink, but the waterfall makes it
> easy to see the periodicity.
>
> Packets are transmitted at 100 packets/second and are ~1300 us in
> duration (fixed).
>
> I include some images below for consideration. The ?Packets? display
> is the transmitted signal. The received noise burst amplitude is
> proportional to the transmit gain, and it quite low, but not
> insignificant.
>
> Anyone seen this?
>
> To anticipate one question, no, I have not used a different B200mini
> to see if it?s hardware, but the fact that I don?t see it at 900 MHz
> receive makes me think it is not.
>
> Figure 1 B200mini Tx and Rx using TRX port only, f_TX = f_RX = 100 MHz
>
> Figure 2 B200mini Tx using TRX port, Rx using Rx2 port, f_TX = f_RX
> = 100 MHz
>
> Figure 3 B200mini Tx using TRX port, Rx using Rx2 port, f_TX = 100
> MHz f_RX = 900 MHz
>
> Steven Knudsen, Ph.D., P.Eng.
> www.techconficio.ca <http://techconficio.ca>
> www.linkedin.com/in/knudstevenknudsen
> <http://www.linkedin.com/in/knudstevenknudsen>
>
> So fest wie die Hand den Stein h?lt. Sie h?lt ihn aber fest, nur um
> ihn desto weiter zu verwerfen. Aber auch in jene Weite f?hrt der
> Weg./- Franz Kafka/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161010/83b046be/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 64515 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161010/83b046be/attachment-0003.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 61553 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161010/83b046be/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 62521 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161010/83b046be/attachment-0005.jpe>
------------------------------
Message: 5
Date: Mon, 10 Oct 2016 21:53:12 -0600
From: Steven Knudsen <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Long period, low-amplitude noise burst in
receive during active TDMA operation (B200mini)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
No problem, Marcus.
I still see this effect, but your idea is a great one (I should have tried it),
so I will try and get back to you and the list.
However, I think you are wondering about cross-channel coupling, which is
always a possibility. The thing I don?t understand is the very long period. The
only thing I can think of is the 1 PPS counter cycle (the so-called sawtooth
effect) that is illustrated here [1]
<http://www.leapsecond.com/pages/vp/heater.htm>. That may have something to do
with it as the sawtooth period can sometimes be long (it all depends on the
receiver module implementation). However, I?m not too hopeful about that
theory? Obviously, I will disconnect the 1 PPS ref and see what happens.
[1] http://www.leapsecond.com/pages/vp/heater.htm
<http://www.leapsecond.com/pages/vp/heater.htm>
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend.
Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r
nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
> On Oct 10, 2016, at 18:10, Marcus D. Leech via USRP-users
> <[email protected]> wrote:
>
> Steve:
>
> Just saw this now. Have you been able to resolve this yourself, or is this
> still a problem?
>
> What if you put terminators on both TX/RX and RX2 ports, do you still see
> these regular, low-amplitude "bursts" every few seconds?
>
>
> On 09/29/2016 11:34 AM, Steven Knudsen via USRP-users wrote:
>> Hi All,
>>
>> I have built a TDMA system that uses the B200mini. In doing a simple test to
>> look at processing load for transceiver operation (B200mini transmits when
>> it is told, otherwise is receiving), I noticed an interesting effect.
>>
>> When the transmit and receive carrier frequencies are the same (below, 100
>> MHz), every 5 seconds or so (but periodic) a slow-amplitude burst signal
>> appears on the receive channel. The is no active transmission for that
>> channel. Indeed, when contigured with transmit on TRX and receive on RX2,
>> there isn?t even an antenna on the RX2.
>>
>> I first noticed the ?noise? on a time sink, but the waterfall makes it easy
>> to see the periodicity.
>>
>> Packets are transmitted at 100 packets/second and are ~1300 us in duration
>> (fixed).
>>
>> I include some images below for consideration. The ?Packets? display is the
>> transmitted signal. The received noise burst amplitude is proportional to
>> the transmit gain, and it quite low, but not insignificant.
>>
>> Anyone seen this?
>>
>> To anticipate one question, no, I have not used a different B200mini to see
>> if it?s hardware, but the fact that I don?t see it at 900 MHz receive makes
>> me think it is not.
>>
>> Figure 1 B200mini Tx and Rx using TRX port only, fTX = fRX = 100 MHz
>> <Mail Attachment.jpeg>
>>
>> Figure 2 B200mini Tx using TRX port, Rx using Rx2 port, fTX = fRX = 100 MHz
>> <Mail Attachment.jpeg>
>>
>> Figure 3 B200mini Tx using TRX port, Rx using Rx2 port, fTX = 100 MHz fRX =
>> 900 MHz
>> <Mail Attachment.jpeg>
>>
>> Steven Knudsen, Ph.D., P.Eng.
>> www. techconficio.ca <http://techconficio.ca/>
>> www.linkedin.com/in/knudstevenknudsen
>> <http://www.linkedin.com/in/knudstevenknudsen>
>>
>> So fest wie die Hand den Stein h?lt. Sie h?lt ihn aber fest, nur um ihn
>> desto weiter zu verwerfen. Aber auch in jene Weite f?hrt der Weg. - Franz
>> Kafka
>>
>>
>>
>
> _______________________________________________
> 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/20161010/dcfeb814/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 11 Oct 2016 11:54:01 +0800
From: liu Jong <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] About custom FPGA on X310
Message-ID:
<caeui2n2ffjbknbywjxwbhoqb1wn4lgn-0vcj10cnbmot9fb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Marcus,
thank you for your reply.
detailed info:
The final purpose?with the graph of host->our fpga CE->radio, the raw
data is sent from host to the fpga CE for processing and then the processed
data
could be sent through the radio.
The current goal?with the graph of host->our fpga CE->host, to verify
the correctness of our fpga CE's process, the processed data will return to
the host
instead of being sent through the radio.
Present situation?according to the default fifo module in the rfnoc
fpga code, we have already developed our own fpga CE and related C++ code
of the host.
The problem we encountered?the host can not recieve the processed date
from our CE but the CE in the fpga definitely have recieved the raw data
from the host and processed it already. And we replace our fpga CE with the
default fifo module of rfnoc then the host can recieve the returned data.
The help we want to seek?we will attach the codes of the host here.
Could you please help us review the codes to find out whether the use of
APIs is reasonable or not and is there any obvious errors that can cause
that problem described above? Thank you!
Jon
2016-09-29 13:43 GMT+08:00 Marcus M?ller via USRP-users <
[email protected]>:
> Hi,
>
> see my answers in-text below:
>
> On 09/27/2016 08:47 PM, liu Jong via USRP-users wrote:
>
> Dear all,
> We bought 2 X310,and we plan to develop rfnoc on x310.We saw the
>
> - RFNoC - Getting Started
> <https://github.com/EttusResearch/uhd/wiki/RFNoC%3A-Getting-Started>
> - RFNoC - Specification
> <https://github.com/EttusResearch/uhd/wiki/RFNoC%3A--Specification>
>
> but we still have some questions:
> 1. How to reflect online data format (OTW) in the implementation of the
> FPGA module?
>
> The "default" sample format for NoC blocks is S(C)16. It's pretty safe to
> assume you want to use that.
>
> Which module of FPGA or host is responsible for the data format
> conversion from otw to CPU?
>
> That's transparently done by the host side's converters
>
> What are the effects of different OTW formats for the implementation of
> FPGA CE?
>
> Well, different implementations? A 16 bit number needs different handling
> than 8 bit numbers.
>
> We now want to implement our own FPGA CE, then how to specify the OTW
> format supported by the custom module?
>
> You specify that in the block describing XML files, so that the host knows.
>
> 2.When you call the C++ library function to send or receive data, you need
> to use method of issue_stream_cmd () , then which FPGA module this method
> will eventually be applied to?
>
> That's a very complex question, but in essence, you'll deal with the host
> streamer and the crossbar, and with the command ports within affected NoC
> blocks.
>
> Is that OK if we use default control class instead of developing a new
> control one?
>
> Usually, yes!
>
> In what case can we use default class, and in what case must we
> implement our own control class?
>
> If your block behaves in a way that it has an input and an output with a
> fixed packet size, you're usually fine using the default class.
>
> For example, the CE we developed is similar to null_source module, it
> generates data cyclically, and these data will be received by the host.
> Is there any difference to other normal module(i.e. FIFO) when we write
> xml files?
>
> no, not that I can see so far. But of course, I don't know how your block
> works, or how the cyclical activation works ? that's basically a bit of an
> unsolved problem, because as long as no one's talking to your NoC block,
> there's nothing to "activate" that NoC block. You could currently use
> workarounds such as "manually" routing the radio clock into the block, and
> triggering on that.
>
> Does host need control class? Or we only need to use the basic class of
> block_ctrl_base?
>
> You shouldn't worry about that too much. Get started using the
> rfnoc_modtool, and you'll end up with a working host side C++
> infrastructure.
>
> Is it necessary to specifically implement the method
> issue_stream_cmd()?
>
> that is basically impossible, as far as I can tell. Or at least,
> architecturally very complex.
>
> Are there any other aspects that we need to be noticed?
> 3.Questions about sampling rate of the module Radio.
> We use the latest rfnoc branch,logic and software code, and when we use
> the following code:
> pt_custom_usrp = uhd::usrp::multi_usrp::make(device_addrs[0]);
> pt_custom_usrp->set_tx_rate(rate);
>
> Notice that you need a device3 somewhere here
>
> We encountered the following print when configuring tx_rate:
> Setting TX Rate: 10.000000 Msps...
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 10.000000 MSps
> Actual sample rate: 200.000000 MSps
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 10.000000 MSps
> Actual sample rate: 200.000000 MSps
>
> We want to know the reason. And how can we use API library function to
> achieve our goals?
>
> Did you perhaps remove the DUC/DDC? The radio block itself has a fixed
> rate...
>
>
> 4.Baseband IQ data interface and radio connection.
> We have implemented the CE module to generate the modulated IQ data,
> and we need to connect it to the radio, can it be directly connected?
>
> well, yes, that is the idea of RFNoC.
>
> Does the baseband need to follow a certain data format when the IQdata
> is sent to the radio, for example, I0Q0I1Q1?
>
> Yes, of course, the format is fixed. The radio takes the Ettus-typical
> SC16 in IQIQIQIQ... format.
>
>
> 5.Rationality of module connection mode.
> As shown below, it is directly connected through internal FPGA pins
> from CE A to CE B.
>
> That is a breach of RFNoC ideologies. CEs should only communicate through
> the crossbar, otherwise you get interesting causality problems. If that is
> impossible, your two CEs probably should be a single one.
>
> A has two outputs,one is hanging on the Xbar and the other is directly
> connected to the input of CE B.
> Similarly, CE B also has two ouputs, one is hanging on the Xbar and the
> other is directly connected to the output of CE A.
> The implementation of CE B function is similar to null source
> module.In the host side, we connect CE A to Radio through
> the method 'connect'. tx_streamer connects module CE A, while rx_streamer
> connects module CE B.
> Is this connection mode feasible in the framework of rfnoc?
>
> No, because it implies that the backpressure-capable AXI crossbar competes
> with your direct A->B connection, as far as I understand.
>
> If not, is there any problem the connection mode will lead to?
> Any more, what is your suggestion for the implementaion of this
> toplogy?
>
> I don't know what your application's purpose is, so this is a tiny bit
> hard to answer!
>
> Best regards,
> Marcus
>
> _______________________________________________
> 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/20161011/ee2e7e7e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source_code.zip
Type: application/zip
Size: 9214 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161011/ee2e7e7e/attachment-0001.zip>
------------------------------
Message: 7
Date: Tue, 11 Oct 2016 12:00:05 +0800
From: liu Jong <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] About custom FPGA on X310
Message-ID:
<CAEui2n2WjXmo=53abj8udm8dgmr_wr5auqb9ydzpixxtk1n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Marcus,
thank you for your reply.please ignore the before lettter.
The final purpose?with the graph of host->our fpga CE->radio, the raw
data is sent from host to the fpga CE for processing and then the processed
data
could be sent through the radio.
The current goal?with the graph of host->our fpga CE->host, to verify
the correctness of our fpga CE's process, the processed data will return to
the host
instead of being sent through the radio.
Present situation?according to the default fifo module in the rfnoc
fpga code, we have already developed our own fpga CE and related C++ code
of the host.
The problem we encountered?the host can not recieve the processed date
from our CE but the CE in the fpga definitely have recieved the raw data
from the host and processed it already. And we replace our fpga CE with the
default fifo module of rfnoc then the host can recieve the returned data.
The help we want to seek?we will attach the codes of the host here.
Could you please help us review the codes to find out whether the use of
APIs is reasonable or not and is there any obvious errors that can cause
that problem described above? Thank you!
2016-10-11 11:54 GMT+08:00 liu Jong <[email protected]>:
> Dear Marcus,
> thank you for your reply.
> detailed info:
> The final purpose?with the graph of host->our fpga CE->radio, the raw
> data is sent from host to the fpga CE for processing and then the processed
> data
> could be sent through the radio.
> The current goal?with the graph of host->our fpga CE->host, to verify
> the correctness of our fpga CE's process, the processed data will return to
> the host
> instead of being sent through the radio.
> Present situation?according to the default fifo module in the rfnoc
> fpga code, we have already developed our own fpga CE and related C++ code
> of the host.
> The problem we encountered?the host can not recieve the processed date
> from our CE but the CE in the fpga definitely have recieved the raw data
> from the host and processed it already. And we replace our fpga CE with
> the default fifo module of rfnoc then the host can recieve the returned
> data.
> The help we want to seek?we will attach the codes of the host here.
> Could you please help us review the codes to find out whether the use of
> APIs is reasonable or not and is there any obvious errors that can cause
> that problem described above? Thank you!
> Jon
>
> 2016-09-29 13:43 GMT+08:00 Marcus M?ller via USRP-users <
> [email protected]>:
>
>> Hi,
>>
>> see my answers in-text below:
>>
>> On 09/27/2016 08:47 PM, liu Jong via USRP-users wrote:
>>
>> Dear all,
>> We bought 2 X310,and we plan to develop rfnoc on x310.We saw the
>>
>> - RFNoC - Getting Started
>> <https://github.com/EttusResearch/uhd/wiki/RFNoC%3A-Getting-Started>
>> - RFNoC - Specification
>> <https://github.com/EttusResearch/uhd/wiki/RFNoC%3A--Specification>
>>
>> but we still have some questions:
>> 1. How to reflect online data format (OTW) in the implementation of the
>> FPGA module?
>>
>> The "default" sample format for NoC blocks is S(C)16. It's pretty safe to
>> assume you want to use that.
>>
>> Which module of FPGA or host is responsible for the data format
>> conversion from otw to CPU?
>>
>> That's transparently done by the host side's converters
>>
>> What are the effects of different OTW formats for the implementation of
>> FPGA CE?
>>
>> Well, different implementations? A 16 bit number needs different handling
>> than 8 bit numbers.
>>
>> We now want to implement our own FPGA CE, then how to specify the OTW
>> format supported by the custom module?
>>
>> You specify that in the block describing XML files, so that the host
>> knows.
>>
>> 2.When you call the C++ library function to send or receive data, you
>> need to use method of issue_stream_cmd () , then which FPGA module this
>> method will eventually be applied to?
>>
>> That's a very complex question, but in essence, you'll deal with the host
>> streamer and the crossbar, and with the command ports within affected NoC
>> blocks.
>>
>> Is that OK if we use default control class instead of developing a new
>> control one?
>>
>> Usually, yes!
>>
>> In what case can we use default class, and in what case must we
>> implement our own control class?
>>
>> If your block behaves in a way that it has an input and an output with a
>> fixed packet size, you're usually fine using the default class.
>>
>> For example, the CE we developed is similar to null_source module, it
>> generates data cyclically, and these data will be received by the host.
>> Is there any difference to other normal module(i.e. FIFO) when we write
>> xml files?
>>
>> no, not that I can see so far. But of course, I don't know how your block
>> works, or how the cyclical activation works ? that's basically a bit of an
>> unsolved problem, because as long as no one's talking to your NoC block,
>> there's nothing to "activate" that NoC block. You could currently use
>> workarounds such as "manually" routing the radio clock into the block, and
>> triggering on that.
>>
>> Does host need control class? Or we only need to use the basic class
>> of block_ctrl_base?
>>
>> You shouldn't worry about that too much. Get started using the
>> rfnoc_modtool, and you'll end up with a working host side C++
>> infrastructure.
>>
>> Is it necessary to specifically implement the method
>> issue_stream_cmd()?
>>
>> that is basically impossible, as far as I can tell. Or at least,
>> architecturally very complex.
>>
>> Are there any other aspects that we need to be noticed?
>> 3.Questions about sampling rate of the module Radio.
>> We use the latest rfnoc branch,logic and software code, and when we
>> use the following code:
>> pt_custom_usrp = uhd::usrp::multi_usrp::make(device_addrs[0]);
>> pt_custom_usrp->set_tx_rate(rate);
>>
>> Notice that you need a device3 somewhere here
>>
>> We encountered the following print when configuring tx_rate:
>> Setting TX Rate: 10.000000 Msps...
>> UHD Warning:
>> The hardware does not support the requested TX sample rate:
>> Target sample rate: 10.000000 MSps
>> Actual sample rate: 200.000000 MSps
>> UHD Warning:
>> The hardware does not support the requested TX sample rate:
>> Target sample rate: 10.000000 MSps
>> Actual sample rate: 200.000000 MSps
>>
>> We want to know the reason. And how can we use API library function
>> to achieve our goals?
>>
>> Did you perhaps remove the DUC/DDC? The radio block itself has a fixed
>> rate...
>>
>>
>> 4.Baseband IQ data interface and radio connection.
>> We have implemented the CE module to generate the modulated IQ data,
>> and we need to connect it to the radio, can it be directly connected?
>>
>> well, yes, that is the idea of RFNoC.
>>
>> Does the baseband need to follow a certain data format when the
>> IQdata is sent to the radio, for example, I0Q0I1Q1?
>>
>> Yes, of course, the format is fixed. The radio takes the Ettus-typical
>> SC16 in IQIQIQIQ... format.
>>
>>
>> 5.Rationality of module connection mode.
>> As shown below, it is directly connected through internal FPGA pins
>> from CE A to CE B.
>>
>> That is a breach of RFNoC ideologies. CEs should only communicate through
>> the crossbar, otherwise you get interesting causality problems. If that is
>> impossible, your two CEs probably should be a single one.
>>
>> A has two outputs,one is hanging on the Xbar and the other is
>> directly connected to the input of CE B.
>> Similarly, CE B also has two ouputs, one is hanging on the Xbar and the
>> other is directly connected to the output of CE A.
>> The implementation of CE B function is similar to null source
>> module.In the host side, we connect CE A to Radio through
>> the method 'connect'. tx_streamer connects module CE A, while
>> rx_streamer connects module CE B.
>> Is this connection mode feasible in the framework of rfnoc?
>>
>> No, because it implies that the backpressure-capable AXI crossbar
>> competes with your direct A->B connection, as far as I understand.
>>
>> If not, is there any problem the connection mode will lead to?
>> Any more, what is your suggestion for the implementaion of this
>> toplogy?
>>
>> I don't know what your application's purpose is, so this is a tiny bit
>> hard to answer!
>>
>> Best regards,
>> Marcus
>>
>> _______________________________________________
>> 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/20161011/95e928bb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source_code.zip
Type: application/zip
Size: 9214 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161011/95e928bb/attachment-0001.zip>
------------------------------
Message: 8
Date: Tue, 11 Oct 2016 08:41:42 +0200
From: Marcus M?ller <[email protected]>
To: liu Jong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] About custom FPGA on X310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Jon,
I've looked through your code and can't find something immediately wrong.
However: from what you described, the TX streaming seems to work. I
think this might be a loopback issue.
can you do the following RFNoC Connections:
host -> DRAM FIFO -> your CE -> host
instead of
host -> your CE -> host
please?
Best regards,
Marcus
On 11.10.2016 06:00, liu Jong wrote:
> Dear Marcus,
> thank you for your reply.please ignore the before lettter.
> The final purpose?with thegraph of host->our fpga CE->radio, the
> raw data is sent from host to the fpga CE for processing and then the
> processed data
> could be sent through the radio.
> The current goal?with the graph of host->our fpga CE->host, to
> verify the correctness of our fpga CE's process, the processed data
> will return to the host
> instead of being sent through the radio.
> Present situation?according to the default fifo module in the
> rfnoc fpga code, we have already developed our own fpga CE and related
> C++ code of the host.
> The problem we encountered?the host can not recieve the processed
> date from our CE but the CE in the fpga definitely have recieved the
> raw data from the host and processed it already. And we replace our
> fpga CE with the default fifo module of rfnoc then the host can
> recieve the returned data.
> The help we want to seek?we will attach the codes of the host
> here. Could you please help us review the codes to find out whether
> the use of APIs is reasonable or not and is there any obvious errors
> that can cause that problem described above? Thank you!
>
> 2016-10-11 11:54 GMT+08:00 liu Jong <[email protected]
> <mailto:[email protected]>>:
>
> Dear Marcus,
> thank you for your reply.
> detailed info:
> The final purpose?with thegraph of host->our fpga CE->radio,
> the raw data is sent from host to the fpga CE for processing and
> then the processed data
> could be sent through the radio.
> The current goal?with the graph of host->our fpga CE->host, to
> verify the correctness of our fpga CE's process, the processed
> data will return to the host
> instead of being sent through the radio.
> Present situation?according to the default fifo module in the
> rfnoc fpga code, we have already developed our own fpga CE and
> related C++ code of the host.
> The problem we encountered?the host can not recieve the
> processed date from our CE but the CE in the fpga definitely have
> recieved the raw data from the host and processed it already. And
> we replace our fpga CE with the default fifo module of rfnoc then
> the host can recieve the returned data.
> The help we want to seek?we will attach the codes of the host
> here. Could you please help us review the codes to find out
> whether the use of APIs is reasonable or not and is there any
> obvious errors that can cause that problem described above? Thank you!
> Jon
>
> 2016-09-29 13:43 GMT+08:00 Marcus M?ller via USRP-users
> <[email protected] <mailto:[email protected]>>:
>
> Hi,
>
> see my answers in-text below:
>
>
> On 09/27/2016 08:47 PM, liu Jong via USRP-users wrote:
>> Dear all,
>> We bought 2 X310,and we plan to develop rfnoc on x310.We saw the
>>
>> * RFNoC - Getting Started
>>
>> <https://github.com/EttusResearch/uhd/wiki/RFNoC%3A-Getting-Started>
>> * RFNoC - Specification
>>
>> <https://github.com/EttusResearch/uhd/wiki/RFNoC%3A--Specification>
>>
>> but we still have some questions:
>> 1. How to reflect online data format (OTW) in the
>> implementation of the FPGA module?
> The "default" sample format for NoC blocks is S(C)16. It's
> pretty safe to assume you want to use that.
>> Which module of FPGA or host is responsible for the data
>> format conversion from otw to CPU?
> That's transparently done by the host side's converters
>> What are the effects of different OTW formats for the
>> implementation of FPGA CE?
> Well, different implementations? A 16 bit number needs
> different handling than 8 bit numbers.
>> We now want to implement our own FPGA CE, then how to
>> specify the OTW format supported by the custom module?
> You specify that in the block describing XML files, so that
> the host knows.
>> 2.When you call the C++ library function to send or receive
>> data, you need to use method of issue_stream_cmd () , then
>> which FPGA module this method will eventually be applied to?
> That's a very complex question, but in essence, you'll deal
> with the host streamer and the crossbar, and with the command
> ports within affected NoC blocks.
>> Is that OK if we use default control class instead of
>> developing a new control one?
> Usually, yes!
>> In what case can we use default class, and in what case
>> must we implement our own control class?
> If your block behaves in a way that it has an input and an
> output with a fixed packet size, you're usually fine using the
> default class.
>> For example, the CE we developed is similar to null_source
>> module, it generates data cyclically, and these data will be
>> received by the host.
>> Is there any difference to other normal module(i.e. FIFO)
>> when we write xml files?
> no, not that I can see so far. But of course, I don't know how
> your block works, or how the cyclical activation works ?
> that's basically a bit of an unsolved problem, because as long
> as no one's talking to your NoC block, there's nothing to
> "activate" that NoC block. You could currently use workarounds
> such as "manually" routing the radio clock into the block, and
> triggering on that.
>> Does host need control class? Or we only need to use the
>> basic class of block_ctrl_base?
> You shouldn't worry about that too much. Get started using the
> rfnoc_modtool, and you'll end up with a working host side C++
> infrastructure.
>> Is it necessary to specifically implement the method
>> issue_stream_cmd()?
> that is basically impossible, as far as I can tell. Or at
> least, architecturally very complex.
>> Are there any other aspects that we need to be noticed?
>> 3.Questions about sampling rate of the module Radio.
>> We use the latest rfnoc branch,logic and software code,
>> and when we use the following code:
>> pt_custom_usrp =
>> uhd::usrp::multi_usrp::make(device_addrs[0]);
>> pt_custom_usrp->set_tx_rate(rate);
> Notice that you need a device3 somewhere here
>> We encountered the following print when configuring tx_rate:
>> Setting TX Rate: 10.000000 Msps...
>> UHD Warning:
>> The hardware does not support the requested TX sample rate:
>> Target sample rate: 10.000000 MSps
>> Actual sample rate: 200.000000 MSps
>> UHD Warning:
>> The hardware does not support the requested TX sample rate:
>> Target sample rate: 10.000000 MSps
>> Actual sample rate: 200.000000 MSps
>>
>> We want to know the reason. And how can we use API
>> library function to achieve our goals?
> Did you perhaps remove the DUC/DDC? The radio block itself has
> a fixed rate...
>>
>> 4.Baseband IQ data interface and radio connection.
>> We have implemented the CE module to generate the
>> modulated IQ data, and we need to connect it to the radio,
>> can it be directly connected?
> well, yes, that is the idea of RFNoC.
>> Does the baseband need to follow a certain data format
>> when the IQdata is sent to the radio, for example, I0Q0I1Q1?
> Yes, of course, the format is fixed. The radio takes the
> Ettus-typical SC16 in IQIQIQIQ... format.
>>
>> 5.Rationality of module connection mode.
>> As shown below, it is directly connected through internal
>> FPGA pins from CE A to CE B.
> That is a breach of RFNoC ideologies. CEs should only
> communicate through the crossbar, otherwise you get
> interesting causality problems. If that is impossible, your
> two CEs probably should be a single one.
>> A has two outputs,one is hanging on the Xbar and the
>> other is directly connected to the input of CE B.
>> Similarly, CE B also has two ouputs, one is hanging on the
>> Xbar and the other is directly connected to the output of CE A.
>> The implementation of CE B function is similar to null
>> source module.In the host side, we connect CE A to Radio through
>> the method 'connect'. tx_streamer connects module CE A,
>> while rx_streamer connects module CE B.
>> Is this connection mode feasible in the framework of rfnoc?
> No, because it implies that the backpressure-capable AXI
> crossbar competes with your direct A->B connection, as far as
> I understand.
>> If not, is there any problem the connection mode will lead to?
>> Any more, what is your suggestion for the implementaion
>> of this toplogy?
> I don't know what your application's purpose is, so this is a
> tiny bit hard to answer!
>
> Best regards,
> Marcus
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_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/20161011/19ec2053/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 11 Oct 2016 09:09:41 +0200
From: Pol Henarejos <[email protected]>
To: "[email protected]" <[email protected]>,
[email protected]
Subject: Re: [USRP-users] Cannot use UHD driver with RFNOC in Windows
10
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Dear Marcus,
Thanks for your approach. I previoulsy updated the image of FPGA. The
UHD driver does not complain about mismatch of versions, so I guess the
image is correct.
I have tested it on Linux and no problem was given. It only fails on
Windows. Additionally, I recompiled the UHD driver with the flag
ENABLE_RFNOC disabled but the error still appears on Windows.
Regards.
Pol Henarejos
Researcher, MSc
[email protected]
Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 645 29 00 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
El 7/10/2016 a les 14:48, Marcus M?ller ha escrit:
Dear Pol Henarejos,
my first approach here: Are you using the FPGA image that belongs to
that release? We'd generally recommend using the uhd_images_downloader
tool; since you've built UHD yourself, you probably have a working
python installation, so that should just work fine. If for some reason
it doesn't you can find the exact file name you should download from [1]
in uhd/host/CMakeLists.txt as the variable UHD_IMAGES_DOWNLOAD_SRC.
Best regards,
Marcus
El 7/10/2016 a les 14:48, Pol Henarejos ha escrit:
> Dear all,
>
> I compiled the UHD driver for Windows 10 using MSVC 2015 with RNOC
> enabled but I cannot set up the usrp object due to the following assertion:
>
> -- Creating WSA UDP transport for 10.1.10.2:49153
> [2016-10-07 14:44:45.771 ERROR] Exception thrown: AssertionError: block_def
> in void __cdecl
> uhd::usrp::device3_impl::enumerate_rfnoc_blocks(unsigned
> __int64,unsigned __int64,unsigned __int64,const class uhd::sid_t &,class
> uhd::device_addr_t,enum uhd::endianness_t)
> at C:\CTTC\UHD\host\lib\usrp\device3\device3_impl.cpp:148
>
> The source code is from the maint branch and corresponds to the version
> UHD_003.010.000.000-79-ON
>
> Any clue?
>
> Thank you so much.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3741 bytes
Desc: Signatura criptogr??fica S/MIME
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161011/9151539a/attachment-0001.p7s>
------------------------------
Message: 10
Date: Tue, 11 Oct 2016 09:51:23 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] AssertionError: block_def with X300
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear Nicolas,
I was not aware that installation is required to run the UHD utilities
(this was not the case until 3.9.x).
Thus, after building from source I ran the uhd_usrp_probe from the
build/utils/ directory without installing. That's why the command failed!
After doing a 'make install' the command works just fine.
Thank you for pointing me towards the right direction.
For the benefit of future users, I suggest to mention that installation
is compulsory in the RFNoC getting started guide.
Best regards,
Claudio
On 10/10/2016 11:13 PM, Nicolas Cuervo wrote:
> Hello Claudio,
>
> We recall having this issue with the installation from the packages, but
> what is odd is that happening with the build from source.
>
> Basically what is happening within the package installation is that some
> *.xml files (if not all) were not being installed in the directories that
> they were intended to. A TL;DR would be that packages installation is not
> suited for 3.10 for now.
>
> Would you please tell us what installation method are you using, and in
> which OS? If this is stopping you from further advance in your application,
> I would recommend you to make a clean install from the git sources
> following this procedure:
> https://kb.ettus.com/RFNoC_Getting_Started_Guides#Installing_UHD.2FRFNoC_Branch
>
> And, if you do so and find the same issue still, please let us know. I ran
> installation myself and couldn't reproduce your problem. The packages,
> however, are showing this faulty behavior.
>
> Cheers,
> -N
>
>
>
> On Sun, Oct 9, 2016 at 11:51 PM, Claudio Cicconetti <[email protected]
>> wrote:
>
>> Dear Nicolas,
>> Yes, I ran the images downloader after building, then loaded the XG
>> images (XG not present in < 3.10 releases), then power cycled the X300,
>> then ran uhd_usrp_probe.
>>
>> I tried the XG images from the following sets:
>>
>> uhd-images_003.010.000.000-36-g967897e0
>> uhd-images_003.010.000.000-release
>>
>> Btw, it seems I am not the only one to experience the same issue
>> (http://lists.ettus.com/pipermail/usrp-users_lists.
>> ettus.com/2016-October/022160.html
>> arrived half an hour later!).
>>
>> Best regards,
>> Claudio
>>
>> On 10/07/2016 06:48 PM, Nicolas Cuervo wrote:
>>> Hello Claudio,
>>>
>>> Just as a sanity check, did you run the images downloader after checking
>>> out the release? If not, please check out to the branch that you want
>>> (master or maint), then run the uhd_images_downloader, and then burn the
>>> new image using jtag or the image loader (hd_images_downloader;
>>> uhd_image_loader --args
>>> type=x300,addr=[the IP addr of your device]
>>>
>>> You can differentiate the FPGA images from UHD 3.9.5 and 3.10 because
>> from
>>> the former they end in HGS.bit, while from the later they end in HG.bit.
>>>
>>> Please let us know if you still see this issue after that.
>>>
>>> Cheers,
>>>
>>> -Nicolas
>>>
>>> On Fri, Oct 7, 2016 at 3:45 AM, Claudio Cicconetti via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Dear all,
>>>> I am starting experimenting with RFNoC but I encountered the following
>>>> blocking issue.
>>>>
>>>> As recommended in the "Testing the installation" section of the "RFNoC
>>>> Getting Started Guides" I ran:
>>>>
>>>> $ uhd_usrp_probe --init-only
>>>>
>>>> but unfortunately I obtained the following error (full output at the
>>>> bottom of this email):
>>>>
>>>> Error: AssertionError: block_def
>>>> in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t,
>>>> size_t, size_t, const uhd::sid_t&, uhd::device_addr_t,
>> uhd::endianness_t)
>>>> at /home/ccicconetti/uhd/host/lib/usrp/device3/device3_impl.cpp:148
>>>>
>>>> This happens both with 3.10.0.0-release (FW release 32), Ubuntu 16.04
>>>> packages and compiled from source, and with the latest code from git
>>>> rfnoc-devel branch (FW release 33).
>>>>
>>>> I have an X300 with a single WBX-120 and no GPSDO on board.
>>>>
>>>> The radio works perfectly fine with stable UHD versions until 3.9.5
>>>> (both Ubuntu packages and compiled versions).
>>>>
>>>> Best regards,
>>>> Claudio
>>>>
>>>> --
>>>>
>>>> Full output of 'uhd_usrp_probe --init-only':
>>>>
>>>> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>>> UHD_004.000.000.rfnoc-devel-641-g8773fb2c
>>>>
>>>> -- X300 initialization sequence...
>>>> -- Determining maximum frame size... 8000 bytes.
>>>> -- Setup basic communication...
>>>> -- Loading values from EEPROM...
>>>> -- Setup RF frontend clocking...
>>>> -- Radio 1x clock:200
>>>> -- [RFNOC] ------- Block Setup -----------
>>>> -- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:30)...OK
>>>> -- Port 48: Found NoC-Block with ID F1F0D00000000000.
>>>> -- Using default block configuration.
>>>> Error: AssertionError: block_def
>>>> in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t,
>>>> size_t, size_t, const uhd::sid_t&, uhd::device_addr_t,
>> uhd::endianness_t)
>>>> at /home/ccicconetti/uhd/host/lib/usrp/device3/device3_impl.cpp:148
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>
>>
>
------------------------------
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 74, Issue 11
******************************************
