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: B205mini Frequency Accuracy (carry chen)
2. Re: B205mini Frequency Accuracy (Steven Knudsen)
3. Re: GRC + RFNoC + Radio Loopback (Nick Foster)
4. Re: RFNoC Custom Block Example (Muhammad, Siraj)
5. Connecting two USRP N210s with a cable (Qurat-Ul-Ann Akbar)
6. Re: Connecting two USRP N210s with a cable (Marcus D. Leech)
7. Repeat Function error - tx_samples_from_file program
(Cho, Daniel J (332C))
8. Re: RFNoC Custom Block Example (Nicolas Cuervo)
----------------------------------------------------------------------
Message: 1
Date: Fri, 2 Jun 2017 15:59:54 +0000
From: carry chen <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B205mini Frequency Accuracy
Message-ID:
<sixpr06mb0905fb913a3a40934d5def1add...@sixpr06mb0905.apcprd06.prod.outlook.com>
Content-Type: text/plain; charset="gb2312"
Hi,Marcus,
Now I check the problem in another way.
I receive the real bts signal with usrp, now it act with a receiver.
I explan in next picture:
[cid:8c8b711d-04a1-47fe-a94f-24fb34f1a72a]
When receive and track lte pss signal with usrp, I found that corr peak move
left fast, about 70ms one
sample,So I have some problem:
1.may be some freq offset in my receiver.
2.may be the clock is no good enough. I search in google, It may be a clock
sync problem or time sync problem because clock jitter ,it say need to control
VCXO with Digital Phase-Locked Loop(DPLL), so how can I do that in usrp? how to
control the clock sample speed?
Thank you very much!
Best regards,
Carry
________________________________
From: Marcus M?ller <[email protected]>
Sent: Sunday, May 28, 2017 1:46 PM
To: carry chen; [email protected]
Subject: Re: [USRP-users] B205mini Frequency Accuracy
Hi Carry,
I'd expect your USRP's oscillator to be measurably more physically stable than
the oscillator in your average LTE handset (but worse than your average eNB).
Could you define "very fast"? As said, any LTE receiver has frequency
correction and tracks the frequency offset. Have you tried one of the different
open source LTE implementations that are in existence currently? gr-lte would
give you an easy way to access the structure of your LTE frames, and srsLTE
tends to contain an extremely versatile baseband implementation.
Best regards,
Marcus
On 05/28/2017 10:17 AM, carry chen wrote:
Marcus,
Thanks for your tips!
I play with sdr lte tdd bts this days.
lte bts need sync with each other,its is say:the frames of each bts need align.
when I make my bts frame align with real lte tdd base station, I find that it
become unalign very quick! the start sample of my bts frame is drift from
start samples of real bts frame.
So I think the clock is not good enough for lte tdd bts.
Thank you very much!
Best regards,
Carry
???: Marcus M?ller via USRP-users
????: 5?25???? 04:12
??: Re: [USRP-users] B205mini Frequency Accuracy
???: [email protected]<mailto:[email protected]>
Hi Carry,
I'd still light to highlight the question the other Marcus asked:
It's not very usual that an application needs such a high-quality clock source.
Since no two oscillators in this universe are exactly the same, all practical
receivers have some way to account (and often: correct) a clock offset! So,
before you spend money, ask yourself if your application wouldn't need to
implement something like that, anyways!
So: what is the reason the on-board oscillator isn't good enough for you?
Best regards,
Marcus
On 24.05.2017 21:25, carry chen via USRP-users wrote:
Steven,
Very?appreciate?for you message!
I will try it!
???nks all!
Carry
From: Steven Knudsen <[email protected]><mailto:[email protected]>
Sent: Wednesday, May 24, 2017 11:46:05 AM
To: carry chen
Cc: [email protected]<mailto:[email protected]>; Jason Matusiak; USRP-users
Subject: Re: [USRP-users] B205mini Frequency Accuracy
There are many options for 1 PPS or 10 MHz clock sources, it all depends on
where you live and how you want to get one.
You can, for example, get a GPS module from ublox, AdaFruit, SparkFun, or
Amazon and make your own SMA terminated cable to connect to the REF input on
the mini. You need to be sure that the signal levels are within spec as show on
the B200mini schematic, for example. It may mean making a level translating
circuit. Normally you want to match the 50 Ohm impedance, but it?s not critical
it?s exact as long as the thresholds are met.
https://files.ettus.com/schematics/b200mini/
Personally, I love my Octoclock G :-)
There is support for external sources in the UHD and there are example programs
in the source to show you how..
Good luck,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca<http://techconficio.ca>
www.linkedin.com/in/knudstevenknudsen<http://www.linkedin.com/in/knudstevenknudsen>
Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt ist zu
erreichen. - Franz Kafka
On May 24, 2017, at 12:25, carry chen via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Thanks!
I see b205mini have three sma port, one ??X/RX , one RX2, and one REF, does
external clock source connect to REF sma port?
Can you give me some tips where to buy the external clock source ?
Does external clock source connect to port direct and the uhd is support direct?
Have some body do that ?
Thank you very much again!
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, May 24, 2017 8:33:18 AM
To: Jason Matusiak
Cc: carry chen; [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] Fw: B205mini Frequency Accuracy
Yes, sorry if I created any confusion.
The 'mini' series have no provision for an on-board GPSDO, like their big
brothers do. You'd need to use an external clock source, and use the sync
input on the 'mini' series.
On 2017-05-24 10:45, Jason Matusiak via USRP-users wrote:
Carry, What I think Marcus means, is that you could use the sync/clock port on
the mini to get better accuracy. There is no way to add on a GPSDO directly.
On 05/24/2017 01:08 AM, carry chen via USRP-users wrote:
Thanks, mleech,
But I check the ettus website, only B210/B200/E3xx have GPSDO interface,
Can B205mini do that?
Can some body recommend some GPSD or OCXO Product use for B205mini ?
Thank you very much!
Carry
From: [email protected]<mailto:[email protected]>
<[email protected]><mailto:[email protected]>
Sent: Tuesday, May 23, 2017 12:04 PM
To: carry chen
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] B205mini Frequency Accuracy
The usual way to do that is to use an external reference oscillator that is
better than the clock that is on-board.
For example a GPSDO, or an external 10MHz OCXO source, etc.
On 2017-05-23 14:58, carry chen via USRP-users wrote:
Hi,list
I check the b205mini datasheet and see the frequency accuracy is ?2.0 ppm,
Can I change the clock to get better frequency accuracy?
Thank you very much!
Carry
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ USRP-users mailing list
[email protected]<mailto:[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/20170602/8165e3a3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: peak_offset.jpg
Type: image/jpeg
Size: 44724 bytes
Desc: peak_offset.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170602/8165e3a3/attachment-0001.jpg>
------------------------------
Message: 2
Date: Fri, 2 Jun 2017 10:23:51 -0600
From: Steven Knudsen <[email protected]>
To: carry chen <[email protected]>
Cc: Marcus M?ller <[email protected]>, USRP-users
<[email protected]>
Subject: Re: [USRP-users] B205mini Frequency Accuracy
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
This may be an obvious comment, but since 70 ms is pretty big, what are the
clocks associated with the signal source and receiver?
For example, I run a custom TDMA scheme between two laptops via 2 B200minis.
Both laptops are synced to GPS time. As part of the radio boot, both laptops
ensure that their respective B200minis are sync?d with GPS time by executing a
set unknown pps command. Both B200minis have 1 pps references from an
Octoclock. I see absolutely no drift in time and very low jitter.
So, without knowing more about your setup I?d say that it?s most likely your
receiver is not properly sync?d and/or disciplined. I would doubt the base
station has any issue if it?s commercial.
I know this doesn?t answer the question, but maybe it will help you dig a
little deeper.
For example, one of the first things I got running was to periodically schedule
transmissions from one or my B200minis at a know offset from the 1 PPS edge,
then look a the transmitted signal on a scope triggered by 1 pps.
ta,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
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
> On Jun 2, 2017, at 09:59, carry chen via USRP-users
> <[email protected]> wrote:
>
> Hi,Marcus,
>
> Now I check the problem in another way.
> I receive the real bts signal with usrp, now it act with a receiver.
> I explan in next picture:
>
> <peak_offset.jpg>
>
> When receive and track lte pss signal with usrp, I found that corr peak move
> left fast, about 70ms one
> sample,So I have some problem:
>
> 1.may be some freq offset in my receiver.
> 2.may be the clock is no good enough. I search in google, It may be a clock
> sync problem or time sync problem because clock jitter ,it say need to
> control VCXO with Digital Phase-Locked Loop(DPLL), so how can I do that in
> usrp? how to control the clock sample speed?
>
> Thank you very much!
>
> Best regards,
> Carry
>
>
> From: Marcus M?ller <[email protected]
> <mailto:[email protected]>>
> Sent: Sunday, May 28, 2017 1:46 PM
> To: carry chen; [email protected] <mailto:[email protected]>
> Subject: Re: [USRP-users] B205mini Frequency Accuracy
>
> Hi Carry,
> I'd expect your USRP's oscillator to be measurably more physically stable
> than the oscillator in your average LTE handset (but worse than your average
> eNB). Could you define "very fast"? As said, any LTE receiver has frequency
> correction and tracks the frequency offset. Have you tried one of the
> different open source LTE implementations that are in existence currently?
> gr-lte would give you an easy way to access the structure of your LTE frames,
> and srsLTE tends to contain an extremely versatile baseband implementation.
> Best regards,
> Marcus
> On 05/28/2017 10:17 AM, carry chen wrote:
>> Marcus,
>>
>> Thanks for your tips!
>> I play with sdr lte tdd bts this days.
>> lte bts need sync with each other,its is say:the frames of each bts need
>> align.
>> when I make my bts frame align with real lte tdd base station, I find that
>> it become unalign very quick! the start sample of my bts frame is drift from
>> start samples of real bts frame.
>>
>> So I think the clock is not good enough for lte tdd bts.
>>
>> Thank you very much!
>>
>> Best regards,
>> Carry
>>
>>
>> ???: Marcus M?ller via USRP-users
>> ????: 5?25???? 04:12
>> ??: Re: [USRP-users] B205mini Frequency Accuracy
>> ???: [email protected] <mailto:[email protected]>
>>
>>
>> Hi Carry,
>>
>> I'd still light to highlight the question the other Marcus asked:
>>
>> It's not very usual that an application needs such a high-quality clock
>> source. Since no two oscillators in this universe are exactly the same, all
>> practical receivers have some way to account (and often: correct) a clock
>> offset! So, before you spend money, ask yourself if your application
>> wouldn't need to implement something like that, anyways!
>>
>>
>> So: what is the reason the on-board oscillator isn't good enough for you?
>>
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 24.05.2017 21:25, carry chen via USRP-users wrote:
>>
>>> Steven,
>>>
>>>
>>> Very?appreciate?for you message!
>>>
>>> I will try it!
>>>
>>>
>>> ???nks all!
>>>
>>>
>>> Carry
>>>
>>> From: Steven Knudsen <[email protected]> <mailto:[email protected]>
>>> Sent: Wednesday, May 24, 2017 11:46:05 AM
>>> To: carry chen
>>> Cc: [email protected] <mailto:[email protected]>; Jason Matusiak; USRP-users
>>> Subject: Re: [USRP-users] B205mini Frequency Accuracy
>>>
>>>
>>>
>>> There are many options for 1 PPS or 10 MHz clock sources, it all depends on
>>> where you live and how you want to get one.
>>>
>>>
>>> You can, for example, get a GPS module from ublox, AdaFruit, SparkFun, or
>>> Amazon and make your own SMA terminated cable to connect to the REF input
>>> on the mini. You need to be sure that the signal levels are within spec as
>>> show on the B200mini schematic, for example. It may mean making a level
>>> translating circuit. Normally you want to match the 50 Ohm impedance, but
>>> it?s not critical it?s exact as long as the thresholds are met.
>>>
>>>
>>> https://files.ettus.com/schematics/b200mini/
>>> <https://files.ettus.com/schematics/b200mini/>
>>>
>>>
>>> Personally, I love my Octoclock G :-)
>>>
>>>
>>> There is support for external sources in the UHD and there are example
>>> programs in the source to show you how..
>>>
>>>
>>> Good luck,
>>>
>>>
>>> steven
>>>
>>>
>>>
>>> Steven Knudsen, Ph.D., P.Eng.
>>>
>>> www. techconficio.ca <http://techconficio.ca/>
>>>
>>> www.linkedin.com/in/knudstevenknudsen
>>> <http://www.linkedin.com/in/knudstevenknudsen>
>>>
>>>
>>> Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt ist
>>> zu erreichen. - Franz Kafka
>>>
>>>
>>>> On May 24, 2017, at 12:25, carry chen via USRP-users
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> I see b205mini have three sma port, one ??X/RX , one RX2, and one REF,
>>>> does external clock source connect to REF sma port?
>>>>
>>>> Can you give me some tips where to buy the external clock source ?
>>>>
>>>> Does external clock source connect to port direct and the uhd is support
>>>> direct?
>>>>
>>>> Have some body do that ?
>>>>
>>>>
>>>> Thank you very much again!
>>>>
>>>> From: [email protected] <mailto:[email protected]> <[email protected]
>>>> <mailto:[email protected]>>
>>>> Sent: Wednesday, May 24, 2017 8:33:18 AM
>>>> To: Jason Matusiak
>>>> Cc: carry chen; [email protected]
>>>> <mailto:[email protected]>
>>>> Subject: Re: [USRP-users] Fw: B205mini Frequency Accuracy
>>>>
>>>>
>>>>
>>>> Yes, sorry if I created any confusion.
>>>>
>>>> The 'mini' series have no provision for an on-board GPSDO, like their big
>>>> brothers do. You'd need to use an external clock source, and use the sync
>>>> input on the 'mini' series.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 2017-05-24 10:45, Jason Matusiak via USRP-users wrote:
>>>>
>>>>> Carry, What I think Marcus means, is that you could use the sync/clock
>>>>> port on the mini to get better accuracy. There is no way to add on a
>>>>> GPSDO directly.
>>>>>
>>>>>
>>>>> On 05/24/2017 01:08 AM, carry chen via USRP-users wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks, mleech,
>>>>>>
>>>>>>
>>>>>>
>>>>>> But I check the ettus website, only B210/B200/E3xx have GPSDO interface,
>>>>>>
>>>>>> Can B205mini do that?
>>>>>>
>>>>>> Can some body recommend some GPSD or OCXO Product use for B205mini ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you very much!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Carry
>>>>>>
>>>>>>
>>>>>> From: [email protected] <mailto:[email protected]> <[email protected]>
>>>>>> <mailto:[email protected]>
>>>>>> Sent: Tuesday, May 23, 2017 12:04 PM
>>>>>> To: carry chen
>>>>>> Cc: [email protected] <mailto:[email protected]>
>>>>>> Subject: Re: [USRP-users] B205mini Frequency Accuracy
>>>>>>
>>>>>>
>>>>>>
>>>>>> The usual way to do that is to use an external reference oscillator that
>>>>>> is better than the clock that is on-board.
>>>>>>
>>>>>> For example a GPSDO, or an external 10MHz OCXO source, etc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2017-05-23 14:58, carry chen via USRP-users wrote:
>>>>>>
>>>>>>> Hi,list
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I check the b205mini datasheet and see the frequency accuracy is ?2.0
>>>>>>> ppm,
>>>>>>>
>>>>>>> Can I change the clock to get better frequency accuracy?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thank you very much!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Carry
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ 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>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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>
>>>>
>>>> _______________________________________________
>>>> 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>
>>>
>>>
>>>
>>>
>>> _______________________________________________ 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>
>>
>>
>>
>>
>
> _______________________________________________
> 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/20170602/27945c66/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 02 Jun 2017 17:11:45 +0000
From: Nick Foster <[email protected]>
To: Christophe ALEXANDRE <[email protected]>, Jonathon
Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GRC + RFNoC + Radio Loopback
Message-ID:
<ca+jmmq9dh35o8+chqh7dh+twdej_bynhjdporzqiahlz4hl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Issue the start stream command *after* the connect() call.
On Fri, Jun 2, 2017 at 8:58 AM Christophe ALEXANDRE <
[email protected]> wrote:
> i suppose you mean this setting :
>
> self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
> self.device3,
> uhd.stream_args( # Tx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="", # empty
> ),
> uhd.stream_args( # Rx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="spp=600",
> ),
> 1, -1
> )
>
>
> i get the same behavior.
>
>
> regards.
>
>
> Christophe ALEXANDRE
>
>
> Le 02/06/2017 ? 16:27, Nick Foster a ?crit :
>
> Looks ok at first glance. Try setting "spp=600" in the block args of the
> RX-side Radio block.
>
> --n
>
> On Fri, Jun 2, 2017, 4:19 AM Christophe ALEXANDRE <
> [email protected]> wrote:
>
>> here you are.
>>
>>
>> regards.
>>
>>
>> Christophe ALEXANDRE
>>
>>
>>
>> Le 01/06/2017 ? 22:33, Nick Foster a ?crit :
>>
>> Can you post your changes to UHD and gr-ettus?
>>
>> On Tue, May 30, 2017, 6:42 AM Christophe ALEXANDRE <
>> [email protected]> wrote:
>>
>>> Hi Nick,
>>>
>>> i have spent more time on your guide at :
>>>
>>> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>>>
>>> i have tried :
>>>
>>> step 1, approach 1, uhd solution
>>> step 2, with GnuRadio
>>> step 3, GRC + manual change in the flowgraph
>>>
>>> After all the modifications, i have run pybombs to recompile
>>> uhd and gr-ettus with the following command :
>>>
>>> pybombs -p rfnoc rebuild uhd gr-ettus
>>>
>>> i have made 2 tests (you will find attached 2 flowgraphs) :
>>>
>>> A) Radio Rx -> Radio Tx loopback
>>> B) Radio Rx -> DDC -> DUC -> Radio Tx loopback
>>>
>>> The A test runs, but with a strange behavior.
>>> 1) i power on the x310
>>> 2) i run loopback_radio_radio.py
>>> it starts with no errors, but doesn't work
>>> when i stop the flowgraph, an error messages occurs :
>>>
>>> fpga@elec58:~/Documents$ ./loopback_radio_radio.py
>>> [INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400;
>>> UHD_4.0.0.rfnoc-devel-316-g24b98579
>>> [INFO] [X300] X300 initialization sequence...
>>> [INFO] [X300] Determining maximum frame size...
>>> [INFO] [X300] Maximum frame size: 1472 bytes.
>>> [INFO] [X300] Setup basic communication...
>>> [INFO] [X300] Loading values from EEPROM...
>>> [INFO] [X300] Setup RF frontend clocking...
>>> [INFO] [X300] Radio 1x clock:200
>>> [INFO] [X300] Detecting internal GPSDO....
>>> [INFO] [GPS] No GPSDO found
>>> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
>>> [INFO] [RFNOC] pass (Throughput: 1304.9MB/s)
>>> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
>>> [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
>>> [WARNING] [RFNOC] [0/SplitStream_0] defines 2 input buffer sizes, but 1
>>> input ports
>>> [INFO] [CORES] Performing timer loopback test...
>>> [INFO] [CORES] Timer loopback test passed
>>> [INFO] [CORES] Performing timer loopback test...
>>> [INFO] [CORES] Timer loopback test passed
>>> [WARNING] [X300 RADIO] set_tx_gain: could not apply gain for this
>>> daughterboard.
>>> [WARNING] [X300 RADIO] set_rx_gain: could not apply gain for this
>>> daughterboard.
>>> [INFO] [RFNOC] Assuming max packet size for 0/Radio_1
>>> Press Enter to quit:
>>> [ERROR] [UHD] Exception caught in safe-call.
>>> in virtual ctrl_iface_impl::~ctrl_iface_impl()
>>> at /home/fpga/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
>>> this->peek32(0); -> EnvironmentError: IOError: Block ctrl
>>> (CE_00_Port_30) packet parse error - EnvironmentError: IOError: Expected
>>> SID: 02:30>00:00 Received SID: 02:50>00:00
>>>
>>> 3) i run loopback_radio_radio.py again
>>> it start with no errors, and it works. Rx signal is copied on Tx
>>> output, both leds are on
>>> when i stop the flowgraph, the same error messages occurs.
>>>
>>>
>>> Each time i want to run the flowgraph, i need to follow these steps.
>>>
>>>
>>> the B test doesn't work. When i run the flowgraph
>>> loopback_radio_ddc_duc_radio.py,
>>> it starts with no errors, but doesn't work. When i stop it, i get the
>>> same error than with the A test.
>>>
>>> Do you have any idea ?
>>>
>>> regards.
>>>
>>>
>>> Christophe ALEXANDRE
>>> Conservatoire National des Arts et M?tiers (CNAM)
>>> Laboratoire CEDRIC-LAETITIA
>>> EPN3 EEAM EASY
>>> Acc?s 11B niveau -1
>>> 292 rue Saint Martin
>>> 75141 PARIS CEDEX 03
>>> FRANCE
>>> email : [email protected]
>>> tel. 0140272699
>>> mob. 0651087311
>>> fax. 0140272994
>>>
>>>
>>> Le 23/05/2017 ? 21:08, Nick Foster a ?crit :
>>>
>>> Christophe,
>>>
>>> This might be a dumb question, but If you followed Step 2 in the guide I
>>> wrote, did you also follow steps 1 & 3?
>>>
>>> --n
>>>
>>> On Tue, May 23, 2017 at 7:43 AM Jonathon Pendlum via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi Christophe,
>>>>
>>>> Out of the box, all RFNoC flowgraphs require at least one connection
>>>> back to the host. This is a limitation of UHD that we plan on fixing. That
>>>> is also why your second flowgraph worked. We are having some discussions on
>>>> making a block to allow loopback, but I can't give you any dates when that
>>>> will be done. If you want to give it a try yourself, one possibility would
>>>> be to make a custom rfnoc block with 2 inputs / 1 output. One of the inputs
>>>> would be from the rx radio, the other a "dummy" connection from the host.
>>>> The output would connect to the tx radio. The block would also need to
>>>> adjust vita time or just strip it off the header.
>>>>
>>>>
>>>>
>>>> Jonathon
>>>>
>>>> On Tue, May 23, 2017 at 5:40 AM, Christophe ALEXANDRE via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> i'm using an X310 with 2 BasicRx and 2 BasicTx and a fresh install of
>>>>> RFNoC.
>>>>>
>>>>> i'm trying to understand how i can use RFNoC with gnuradio companion
>>>>> and how i can mix gnuradio software blocks and RFNoC blocks.
>>>>>
>>>>> With the help of Ettus documentations, i think i understand the idea
>>>>> except in one case, when i try to use both Rx and Tx radio blocks (and
>>>>> i can't
>>>>> see any examples in ~rfnoc/src/gr-ettus/examples/rfnoc).
>>>>>
>>>>> My first test is a simple loopback :
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> when i run this flowgraph, there is no errors, but nothing happens
>>>>> and the rf0 and rf1 leds are off. There is no signal copy
>>>>> from rf1:Rx2 to rf0:Tx.
>>>>>
>>>>> if i understand clearly the problem explained here :
>>>>>
>>>>> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>>>>>
>>>>> this is a timestamp problem on the Tx side. I've tried to follow the
>>>>> proposed solution
>>>>> (Step 2: Enable Streamer), but without success.
>>>>>
>>>>> But if the flowgraph go back to the host doing nothing (add a 0
>>>>> constant), it works
>>>>> (i suppose that gnuradio creates the necessary timestamps for the Tx
>>>>> side) :
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Leds are on and the input signal is going from rf1:Rx2 to rf0:Tx.
>>>>>
>>>>>
>>>>> Is there any better way to solve this problem ?
>>>>>
>>>>>
>>>>> regards.
>>>>>
>>>>>
>>>>> Christophe ALEXANDRE
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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/20170602/7f908d93/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 2 Jun 2017 19:22:54 +0000
From: "Muhammad, Siraj" <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Custom Block Example
Message-ID:
<by1pr03mb1338665a9680cf2e4422e10ccd...@by1pr03mb1338.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Thank you, Nicolas! It worked.
I have another question if you don?t mind.
When I built the OOT module, I got an error says -std=c++11 should be passed to
the compiler. I had to add this option to CMAKE_CXX_FLAGS in
rfnoc-tutorial/build/CMakeCache.txt
Is this normal? Or is there something wrong in my environment?
Thanks,
Siraj
From: Nicolas Cuervo [mailto:[email protected]]
Sent: Friday, June 2, 2017 5:55 AM
To: Muhammad, Siraj <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] RFNoC Custom Block Example
Hello Siraj,
there should be a small indentation mismatch in your
rfnoc-tutorial/grc/tutorial_gain.xml file. Please double-check it with the
files provided at [1] and, after correction, rebuild your oot module, reload
the flowgraph in GRC and try to run it again.
Regards,
- Nicolas
[1]
https://kb.ettus.com/Getting_Started_with_RFNoC_Development<https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.ettus.com_Getting-5FStarted-5Fwith-5FRFNoC-5FDevelopment&d=DwMFaQ&c=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk&r=ToS7EjuDGfB6A6qGHWQt9r8_NP34wBV_sAv_IzxySeI&m=7qq4Munx7-M6XzINFfe1Y3rA50w01oCYwPNPHNiXyHs&s=zVFjYf_qipBGpDFbd_E5sbubMRzNl3X1vjFkrEdcofA&e=>
On Fri, Jun 2, 2017 at 8:58 AM, Muhammad, Siraj via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello All,
I am trying to run the example of ?Gain? in the RFNoC tutorial. I compiled
everything and it seems fine.
Running the example in GNU Radio Companion throws an error:
File "/home/siraj/Downloads/gain_src/rfnoc_gain.py", line 183
self.gain_0.set_arg("gain", gain_digital)
^
IndentationError: unexpected indent
How is that possible?
Thanks,
Siraj
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk&r=ToS7EjuDGfB6A6qGHWQt9r8_NP34wBV_sAv_IzxySeI&m=7qq4Munx7-M6XzINFfe1Y3rA50w01oCYwPNPHNiXyHs&s=fVlSblu2KarhU7WuKY9NDvlq_G__a0yrhxYyrb-a06Q&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170602/b52907f4/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 2 Jun 2017 15:37:53 -0500
From: Qurat-Ul-Ann Akbar <[email protected]>
To: [email protected]
Subject: [USRP-users] Connecting two USRP N210s with a cable
Message-ID:
<CAJwfNj0No-U_NybeViXcrGmU-=8jyj9jk7yqrghk6lvs+vt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I am working with USRP N210 and I am not able to decode WiFi packets
correctly due to very low SNR. I want to connect the two USRPs with a cable
to see if thats really the problem and not a software issue. Is it safe to
connect the TX/RX of both the USRPs with a cable?
And I see SMA to SMB cable on the Ettus wesbite for USRP E310but is there
anything for USRP N210?
Best,
Annie
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170602/d8383291/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 02 Jun 2017 17:03:38 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Connecting two USRP N210s with a cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 06/02/2017 04:37 PM, Qurat-Ul-Ann Akbar via USRP-users wrote:
> Hello,
>
> I am working with USRP N210 and I am not able to decode WiFi packets
> correctly due to very low SNR. I want to connect the two USRPs with a
> cable to see if thats really the problem and not a software issue. Is
> it safe to connect the TX/RX of both the USRPs with a cable?
>
> And I see SMA to SMB cable on the Ettus wesbite for USRP E310but is
> there anything for USRP N210?
>
> Best,
> Annie
>
If you're cabling together, you'll need at least 30-40dB of attenuation
in-line.
There'a pre-made loopback kit here:
https://www.ettus.com/product/details/LPBK-KIT
------------------------------
Message: 7
Date: Fri, 2 Jun 2017 21:40:14 +0000
From: "Cho, Daniel J (332C)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Repeat Function error - tx_samples_from_file
program
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello -
I am trying to transmit samples from a file that was generated. There is no
issue with transmitting the file once but when I try and use the repeat
function to continuously loop the file in the tx_samples_from_file program, I
get the following error:
[cid:[email protected]]
Any help to allow continuous looping of transmitting a file will be greatly
appreciated! I am using all default configurations.
Thanks,
Daniel Cho
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170602/e7196151/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 5804 bytes
Desc: image001.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170602/e7196151/attachment-0001.jpg>
------------------------------
Message: 8
Date: Sat, 3 Jun 2017 10:59:12 +0200
From: Nicolas Cuervo <[email protected]>
To: "Muhammad, Siraj" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Custom Block Example
Message-ID:
<caoupcvg4rgtrhs9+j4klfb8thqb2ipxqmvglnwcnvjtdqk4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Siraj,
there is nothing wrong with your environment. UHD introduced C++11 rather
recently and this compiler error that you saw is a consequence of it.
However, we are already aware of this and we have fixed it. We are going to
push this fix into gr-ettus the following days.
Regards,
-N
On Fri, Jun 2, 2017 at 9:22 PM, Muhammad, Siraj <[email protected]>
wrote:
> Thank you, Nicolas! It worked.
>
> I have another question if you don?t mind.
>
> When I built the OOT module, I got an error says -std=c++11 should be
> passed to the compiler. I had to add this option to CMAKE_CXX_FLAGS in
> rfnoc-tutorial/build/CMakeCache.txt
>
> Is this normal? Or is there something wrong in my environment?
>
>
>
> Thanks,
>
> Siraj
>
>
>
> *From:* Nicolas Cuervo [mailto:[email protected]]
> *Sent:* Friday, June 2, 2017 5:55 AM
> *To:* Muhammad, Siraj <[email protected]>
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] RFNoC Custom Block Example
>
>
>
> Hello Siraj,
>
>
>
> there should be a small indentation mismatch in your
> rfnoc-tutorial/grc/tutorial_gain.xml file. Please double-check it with
> the files provided at [1] and, after correction, rebuild your oot module,
> reload the flowgraph in GRC and try to run it again.
>
>
>
> Regards,
>
> - Nicolas
>
>
>
> [1] https://kb.ettus.com/Getting_Started_with_RFNoC_Development
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.ettus.com_Getting-5FStarted-5Fwith-5FRFNoC-5FDevelopment&d=DwMFaQ&c=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk&r=ToS7EjuDGfB6A6qGHWQt9r8_NP34wBV_sAv_IzxySeI&m=7qq4Munx7-M6XzINFfe1Y3rA50w01oCYwPNPHNiXyHs&s=zVFjYf_qipBGpDFbd_E5sbubMRzNl3X1vjFkrEdcofA&e=>
>
>
>
> On Fri, Jun 2, 2017 at 8:58 AM, Muhammad, Siraj via USRP-users <
> [email protected]> wrote:
>
> Hello All,
>
>
>
> I am trying to run the example of ?Gain? in the RFNoC tutorial. I compiled
> everything and it seems fine.
>
> Running the example in GNU Radio Companion throws an error:
>
>
>
> File "/home/siraj/Downloads/gain_src/rfnoc_gain.py", line 183
>
> self.gain_0.set_arg("gain", gain_digital)
>
> ^
>
> IndentationError: unexpected indent
>
>
>
> How is that possible?
>
>
>
> Thanks,
>
> Siraj
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk&r=ToS7EjuDGfB6A6qGHWQt9r8_NP34wBV_sAv_IzxySeI&m=7qq4Munx7-M6XzINFfe1Y3rA50w01oCYwPNPHNiXyHs&s=fVlSblu2KarhU7WuKY9NDvlq_G__a0yrhxYyrb-a06Q&e=>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170603/fedb762b/attachment-0001.html>
------------------------------
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 82, Issue 3
*****************************************
