Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: ??? Problem using B210 with two different RX frequency
(Ian Buckley)
2. E310 temperature sensors (Jason Matusiak)
3. Re: Queueing Timed Commands (Jacob Gilbert)
4. Re: E310 temperature sensors (Martin Braun)
5. Re: A question about temperature sensor on USRP-B200mini
(Martin Braun)
6. Re: E310 temperature sensors (Jason Matusiak)
7. Re: RFNOC Error: Path not found in tree:
/mboards/0/dboards/B/rx_frontends/0/name (Martin Braun)
8. Re: temp sensors and PLL lock on E310 (Martin Braun)
9. Re: Building a custom RFNoC FPGA Image with the right compat
number (Martin Braun)
10. Re: E310 temperature sensors (Martin Braun)
11. Re: E310 temperature sensors (Jason Matusiak)
12. Re: E310 temperature sensors (Martin Braun)
13. Re: Format of complex data saved thru uhd_rx_cfile. Is it Q15
? (Martin Braun)
14. Re: USRP B210 - signals shifted when using both TX channels
and LO offsets (Chavez)
15. Re: ??: Re:usrp-n210:Expected FPGA compatibility number
10,but got 16 (Marcus M?ller)
16. (no subject) (Eugene Lee)
17. Re: USRP B210 - signals shifted when using both TX channels
and LO offsets (Chavez)
18. Re: ??? Problem using B210 with two different RX frequency
(Marcus M?ller)
19. Re: USRP B210 - signals shifted when using both TX channels
and LO offsets (Marcus M?ller)
20. Re: (no subject) (Marcus D. Leech)
21. Re: Waveform received from USRP2 freezes (Nik B.)
22. Re: Waveform received from USRP2 freezes (Marcus M?ller)
23. Re: How to add interrupts on E310's Linux system (Weidong Wang)
24. DELETE_DSP (Barker, Douglas W.)
25. Receiving garbage codes with official qpsk tx and rx model. (??)
----------------------------------------------------------------------
Message: 1
Date: Mon, 11 Jul 2016 09:03:19 -0700
From: Ian Buckley <i...@ionconcepts.com>
To: ?? <leon...@qq.com>
Cc: Marcus M?ller <marcus.muel...@ettus.com>, usrp-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] ??? Problem using B210 with two different RX
frequency
Message-ID:
<CAM_0ocHwEnCnD4Yz6cVGBuz4cjJS1XtMumvGX=50xouuhqc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Zhangmeng,
AD9361 when using CMOS interface mode has this limitation. In LVDS mode
this limitation does not exist. B2xxx products only support CMOS mode.
You'll want to refer to the "Digital Interface" Chapter (Table 48).
Marcus,
For GSM 850/900 you can suggest (to Zhang) a single channel B210 usage
model using the CORDIC as we have discussed earlier to place the UL/DL in
close adjacency around DC, and the DDC to reduce the data rate to the host,
it works well. Sadly for GSM 1800/1900 the channel spacing tends to be too
far.
-Ian
On Sat, Jul 9, 2016 at 4:21 AM, ?? via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Marcus!
>
> Thanks for your reply!
> The parameter "master_clock_rate" for B210 means the sampling rate
> of the ADC in AD9361, right? Do you means that the 2 RX channels share a
> total rate of 61.44Msps? I noticed that when using 2 channels the UHD set
> the highest master_clock_rate to 30.72MHz. I thought it's just a
> consideration for USB 3.0 transmission. So I simply disabled the
> "enforce_tick_rate_limits" function in b200_impl.cc in UHD source code and
> set the "tune" function in ad9361_ctrl.cpp to a constant (e.g 940MHz) and
> compiled the UHD again. Then I can set the master_clock_rate higher. For
> example, I set master_clock_rate to 40MHz and sampling rate to 4Msps. I can
> see messages printed by UHD said the LO, the master clock rate, the
> decimation rate and the sampling rate were set as I expected. When I
> changed the center frequency of 2 channels, I can also see the DSP DDC
> works well. Also the FFT results showed the GSM downlink signals correctly.
> This just didn't work when the master_clock_rate set higher than 45MHz. I
> noticed that the noise floor raised about 20dB. It seemed that the GSM
> signal is covered.
>
> I just took a simply look at the AD9361 datasheet and I didn't find
> the description for "2 channels share a total rate of 61.44Msps". Could you
> show me where the description is? If this is the reason I failed, what
> should I do?
>
> My application: uplink 885--890MHz & downlink 930 -- 935MHz.
>
> Thank you!
>
> Zhangmeng
>
>
> ------------------ ???? ------------------
> *???:* "Marcus M?ller via USRP-users";<usrp-users@lists.ettus.com>;
> *????:* 2016?7?9?(???) ??5:30
> *???:* "usrp-users"<usrp-users@lists.ettus.com>;
> *??:* Re: [USRP-users] Problem using B210 with two different RX frequency
>
> Hi Zhangmeng,
>
> I disabled the limit of sampling rate in UHD while using two RXs.
>
> What exactly did you change? As far as I know, there's only one limit in
> there ? and that's the hardware limitation of the AD9361 chip, which can't
> use full rates in dual channel configuration.
>
> Then I set the master_clock_rate to 32MHz - 44MHz and it works fine
>
> Last time I tried, the maximum master clock rate for two channels is 30.72
> MHz, as dictated by by the maximum data clock frequency of the AD9361,
> which is 61.44 MHz, and has to be shared between the two channels. So, in
> fact, I'm a little surprised you say it works fine!
>
> When I set master_clock_rate to 32MHz or higher, sampling rate of data
> processing on PC is set to 2M to 4Msps.
>
> Are you sure you've actually set a master clock rate of > 30.72 MHz? Is it
> possible that UHD automatically used a different rate?
>
> So, I'd like to fully understand the situation here:
> We're talking about E-GSM 900, with uplink at 880.0 ? 915.0 MHz and
> downlink at 925.0 ? 960.0, right?
>
> Best regards,
>
> Marcus
>
> On 08.07.2016 05:56, ?? via USRP-users wrote:
>
>
> Hi!
>
> Recently I tried to use B210 to receive both uplink and downlink
> channels of GSM 900. I noticed that the two RX channels in AD9361 share one
> LO. So I have to set a high sampling rate (at least 45Msps) and do DDC and
> decimation using FPGA. I disabled the limit of sampling rate in UHD while
> using two RXs. Then I set the master_clock_rate to 32MHz - 44MHz and it
> works fine. But when I set the master_clock_rate higher than 45MHz I got
> nothing but noise. It doesn't works when the rate is higher than 45MHz.
> What's wrong with that? Or is there other way to receive both up&downlink
> of GSM signals using B210?
>
> PS: When I set master_clock_rate to 32MHz or higher, sampling rate of
> data processing on PC is set to 2M to 4Msps.
>
> Best wishes!
>
> ------------------------------
> Zhangmeng
>
>
> _______________________________________________
> USRP-users mailing
> listUSRP-users@lists.ettus.comhttp://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160711/e1966681/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 11 Jul 2016 12:06:05 -0400
From: Jason Matusiak <ja...@gardettoengineering.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] E310 temperature sensors
Message-ID: <5783c3ed.2070...@gardettoengineering.com>
Content-Type: text/plain; charset=utf-8; format=flowed
From Python, I know how to pull in that the documentation refers to as
the processor's temperature sensor and that is working fine (using the
get_mboard_sensors approach).
My question is, is there a way to pull down the AD9361's temp sensor
from Python? I see that you can do it via C++ using the
ad9361_ctrl::get_temperature() function, but I don't see how to do that
from Python....
------------------------------
Message: 3
Date: Mon, 11 Jul 2016 10:20:35 -0600
From: Jacob Gilbert <mrjacobagilb...@gmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Queueing Timed Commands
Message-ID:
<CAC52AkAOOrbdXQdUrXL_r35Z5iw4TdFiA7Pka26WX=2wn+7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I tested this out on a B200 with the exact same results. Still looking for
any input on why timed commands are not working as expected on B2xx-series
USRPs.
I also ran this on an X310 w/ UBX and observed the following when
configured for 15 tunes.
TIME OPERATION RETUNE#
0.0112 set command time 0
0.0127 issued retune command 0
0.0127 cleared command time 0
0.0128 set command time 1
0.0133 issued retune command 1
0.0133 cleared command time 1
0.0134 set command time 2
0.0139 issued retune command 2
0.0139 cleared command time 2
0.014 set command time 3
0.0144 issued retune command 3
0.0145 cleared command time 3
0.0145 set command time 4
0.0151 issued retune command 4
0.0152 cleared command time 4
0.0152 set command time 5
0.0157 issued retune command 5
0.0158 cleared command time 5
0.0158 set command time 6
0.0163 issued retune command 6
0.0164 cleared command time 6
0.0165 set command time 7
1.1511 issued retune command 7
1.1514 cleared command time 7
1.1516 set command time 8
1.2013 issued retune command 8
1.2014 cleared command time 8
1.2016 set command time 9
1.2509 issued retune command 9
1.251 cleared command time 9
1.2512 set command time 10
1.3009 issued retune command 10
1.3011 cleared command time 10
1.3012 set command time 11
1.3509 issued retune command 11
1.3511 cleared command time 11
1.3512 set command time 12
1.4008 issued retune command 12
1.401 cleared command time 12
1.4011 set command time 13
1.451 issued retune command 13
1.4512 cleared command time 13
1.4514 set command time 14
1.5009 issued retune command 14
1.501 cleared command time 14
The first 7 queue up as expected, however the 8th command blocks until the
first is complete, etc. This is also unexpected based on the discussion
here (up to 16 commands should have queued).
Thanks,
Jacob
On Wed, Jul 6, 2016 at 7:43 AM, Jacob Gilbert <mrjacobagilb...@gmail.com>
wrote:
> Yes, output would certainly be more helpful!
>
> I have also attached a screenshot of what I see when the flowgraph
> actually does tuning - it is annotated with the expected behavior. There is
> 1/f noise and I move it around by CORDIC tuning in constant steps and at a
> constant time interval (I am traveling and the only RF gear I have is a
> B200mini...make do with what you have). Ideally all of the tuning commands
> would be issues back-to-back after the INITIAL_DELAY, and would take effect
> further down in the output at the time they are scheduled. What I am
> observing is the following:
>
> ----------- output with INITIAL_DELAY=0.01 -----------
>
> 0.0012 started FG at 1467810323.96 / 4.01173253125
>
> TIME OPERATION RETUNE#
> 0.0121 set command time 0
> 0.0125 issued retune command 0
> 0.0126 cleared command time 0
> 0.0127 set command time 1
> 0.013 issued retune command 1
> 0.0131 cleared command time 1
> 0.0132 set command time 2
> 0.2506 issued retune command 2
> 0.2508 cleared command time 2
> 0.2508 set command time 3
> 0.3005 issued retune command 3
> 0.3006 cleared command time 3
> 0.3006 set command time 4
> 0.3503 issued retune command 4
> 0.3504 cleared command time 4
> 0.3505 set command time 5
> 0.4005 issued retune command 5
> 0.4006 cleared command time 5
> 0.4007 set command time 6
> 0.4507 issued retune command 6
> 0.4508 cleared command time 6
> 0.4509 set command time 7
> 0.5007 issued retune command 7
> 0.5008 cleared command time 7
>
> ---------------------------------
>
> As can be observed from the timestamps on the left hand side, Timed Tune 0
> and 1 return almost immediately, while TT 2 blocks until the TT 0 command
> time (~0.25) has elapsed. Then TT 3 blocks until TT 1 has elapsed and so on.
>
>
> ----------- output with INITIAL_DELAY=0.001 -----------
>
> 0.0169 started FG at 1467810384.06 / 3.7929270625
>
> TIME OPERATION RETUNE#
> 0.0198 set command time 0
> 0.2508 issued retune command 0
> 0.2533 cleared command time 0
> 0.2534 set command time 1
> 0.2539 issued retune command 1
> 0.2539 cleared command time 1
> 0.254 set command time 2
> 0.2543 issued retune command 2
> 0.2544 cleared command time 2
> 0.2544 set command time 3
> 0.3007 issued retune command 3
> 0.3008 cleared command time 3
> 0.3009 set command time 4
> 0.3507 issued retune command 4
> 0.351 cleared command time 4
> 0.3513 set command time 5
> 0.4005 issued retune command 5
> 0.4006 cleared command time 5
> 0.4007 set command time 6
> 0.4502 issued retune command 6
> 0.4504 cleared command time 6
> 0.4505 set command time 7
> 0.5006 issued retune command 7
> 0.501 cleared command time 7
>
> ---------------------------------
>
> The behavior with a short/no delay is actually identical after TT 2, but
> for whatever reason, the first timed command blocks until it actually
> happens (~0.25s).
>
> So overall the behavior I am observing is that only two timed commands can
> be in the queue, which does not seem correct. There is also some strange
> behavior related to startup I don't quite understand but I'd be happy
> resolving just the blocking behavior.
>
> Regarding the pre-Queueing of timed commands: I tried replacing line 87
> with:
>
> u0 = tb.u.get_time_now() + uhd.time_spec_t(1.0)
> tb.u.set_start_time(u0)
>
> however this results in essentially the same output:
>
> ----------- output with INITIAL_DELAY=0.01 -----------
>
> 0.0009 started FG at 1467811187.8 / 5.05439371875
>
> TIME OPERATION RETUNE#
> 0.0116 set command time 0
> 0.0119 issued retune command 0
> 0.0119 cleared command time 0
> 0.012 set command time 1
> 0.0122 issued retune command 1
> 0.0122 cleared command time 1
> 0.0123 set command time 2
> 1.2501 issued retune command 2
> 1.2502 cleared command time 2
> 1.2503 set command time 3
> 1.3005 issued retune command 3
> 1.3006 cleared command time 3
> 1.3007 set command time 4
> 1.3505 issued retune command 4
> 1.3507 cleared command time 4
> 1.3508 set command time 5
> 1.4005 issued retune command 5
> 1.4007 cleared command time 5
> 1.4007 set command time 6
> 1.4504 issued retune command 6
> 1.4506 cleared command time 6
> 1.4507 set command time 7
> 1.5001 issued retune command 7
> 1.5003 cleared command time 7
>
> ---------------------------------
>
> So, everything so far does not really explain the issue I'm having. I
> believe from what I've seen and read that I should be able to both
> pre-queue up timed commands, and to issue up to 16 CORDIC tunes while the
> FG is operating. For what I need to do now, i will need to issue 5-8 future
> commands to handle latency with acceptable reliability but I'm thinking a
> little more generally.
>
> I'm not sure whether or not the command queue is getting 'clogged' with
> other commands or the process of issuing timed commands is not working as
> expected on some level. I sort of suspect there is something inside UHD
> that is blocking when it shouldn't but I don't know enough about it to say
> for sure. I appreciate the input.
>
> Jacob
>
>
> On Wed, Jul 6, 2016 at 1:22 AM, Marcus M?ller <usrp-users@lists.ettus.com>
> wrote:
>
>> Hi Jacob, Ian and Marcus,
>>
>> so, having had a look at your Python code (haven't yet executed it):
>>
>> this looks about right. There's a couple of things that would be worth
>> investigating:
>>
>> INITIAL_DELAY: This confuses me, but if set to a value larger than 0.01
>> seconds will allow two commands to queue up as expected. If it is very
>> small (eg: < 0.001 s) no commands queue as expected.
>>
>> this might actually be a hint. Knowing gr-uhd a bit, what happens in the
>> usrp_source::start() method is that an UHD rx_streamer object is created,
>> and a timed "start streaming" command is queued ? a "reasonable" delay in
>> the future (which happens to be 0.1s, determined by high-quality
>> eyeballing) to avoid overflows from happening before the flow graph is even
>> up and running. The start() method of all blocks in a flowgraph is called
>> (sequentially, btw) when you call tb.start().
>>
>> So, two cases:
>>
>> *1. PREQUEUE_TUNES is not set*
>> The first entry in the command queue is the start streaming command at
>> now+0.1s ? and all the commands will be queued behind that, so if their
>> execution time was before that, they will be executed but immediately after
>> the start of streaming
>>
>> *2. PREQUEUE_TUNES is not set*
>>
>> The commands _SHOULD_ get queued correctly; the fact that they "clog" the
>> command queue can lead to a situation where your tuning happens before you
>> get any samples ? making it rather pointless.
>>
>>
>> Based on these considerations, you should probably not set
>> PREQUEUE_TUNES, but should set_start_time() explicitely before calling
>> start() before issueing tune requests and base your time offsets on the
>> start time as reference.
>>
>> Still, I'm not 100% this explains that queuing doesn't work as you expect
>> it; would you be as nice as to share the output of running your flow graph
>> as it is (and maybe even with the changes I propose)?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 06.07.2016 01:02, Jacob Gilbert via USRP-users wrote:
>>
>> Ok, so I will take the info you and Marcus provided to mean that what I
>> am attempting to do (queue timed CORDIC tunes) _should_ work. The other
>> radio operations might explain why the behavior is different without any
>> delay after starting, but it still does not make sense to me that I cannot
>> queue up commands later. I'll wait for someone from Ettus to weigh in on
>> what might be going on here.
>>
>> Thanks again,
>> Jacob
>>
>> On Tue, Jul 5, 2016 at 12:30 PM, Ian Buckley <i...@ionconcepts.com>
>> wrote:
>>
>>> Jacob,
>>> A CORDIC retune is a single 32bit write transaction, so that would be
>>> efficient in terms of cmd-q usage. Other operations that change state in
>>> the radio would share this queue. Typically (after initial config) that
>>> would include operations such as starting and stopping RX/TX and RF switch
>>> configuration changes. The command queue is also probably 32 entries on any
>>> B2xx style device.
>>> I'll let one of the Ettus team respond to your more involved question in
>>> detail but generically, its the AD936x based products that lack timed
>>> operations related to (RF) radio interactions. Daughter board based USRP's
>>> should offer timed operations for pretty much all commands.
>>>
>>> -Ian
>>>
>>>
>>> On Tue, Jul 5, 2016 at 10:45 AM, Jacob Gilbert <
>>> <mrjacobagilb...@gmail.com>mrjacobagilb...@gmail.com> wrote:
>>>
>>>> Ian,
>>>>
>>>> Thanks for the reply - I should have mentioned that to get around the
>>>> 936x-based lack of timed commands, I am only CORDIC tuning (verified in
>>>> output) - do you happen to know many bus transactions would this be?
>>>>
>>>> Somewhat related, is there a list of commands that can be timed for
>>>> various USRP models?
>>>>
>>>> Jacob
>>>>
>>>> On Tue, Jul 5, 2016 at 11:29 AM, Ian Buckley < <i...@ionconcepts.com>
>>>> i...@ionconcepts.com> wrote:
>>>>
>>>>> Jacob, this is an off the cuff comment, I haven't the time to look at
>>>>> your example but one thing that might bring greater understanding.
>>>>> When we talk about command queue depth, it's in terms of a simple bus
>>>>> transaction=1 cmd-queue entry. Retuning some of the USRP front ends might
>>>>> well take a fair number of SPI transactions initiated with bus
>>>>> transactions.
>>>>> BTW when I say "bus transaction" I mean a simple "PEEK/POKE memory
>>>>> map" style operation.
>>>>>
>>>>> Now specific to B200mini, unless there has been a very recent FPGA
>>>>> change then retuning operations that reprogram the RF synthesizers are not
>>>>> available as timed commands, they always complete best effort
>>>>> asynchronously. If you supply a time then I suspect (knowning how the H/W
>>>>> is designed) that it is just ignored.
>>>>> -Ian
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 5, 2016 at 9:26 AM, Jacob Gilbert via USRP-users <
>>>>> <usrp-users@lists.ettus.com>usrp-users@lists.ettus.com> wrote:
>>>>>
>>>>>> I am having trouble queueing multiple timed commands up for a USRP
>>>>>> source, in this case the next several frequencies for a fast hopping FHSS
>>>>>> transmitter. I understand there is a 16 command deep queue on the USRP,
>>>>>> but something is causing an inability to queue up commands.
>>>>>>
>>>>>> Rather than attempt explain what I've tried, I attached an example
>>>>>> flowgraph of the behavior. Modifying the variables at the top gives a
>>>>>> better perspective of the issue:
>>>>>>
>>>>>> PREQUEUE_TUNES: Setting this will attempt to queue up the retunes
>>>>>> before starting the FG. No matter which way commands are tuned, the
>>>>>> behavior appears to be the same.
>>>>>> INITIAL_DELAY: This confuses me, but if set to a value larger than
>>>>>> 0.01 seconds will allow two commands to queue up as expected. If it is
>>>>>> very
>>>>>> small (eg: < 0.001 s) no commands queue as expected.
>>>>>> DELAY_BETWEEN_RETUNES: does not appear to have any effect but
>>>>>> included due to the oddness of the initial delay.
>>>>>>
>>>>>> I have also observed this blocking behavior with a C++ block that
>>>>>> works in a similar way. This behavior was observed with a B200 mini, and
>>>>>> I
>>>>>> can try to test other USRPs when I have access to them if this is
>>>>>> suspected
>>>>>> to be specific to the B200mini.
>>>>>>
>>>>>> My question then is: Is this the desired/expected behavior? If so
>>>>>> what is the point of the command queue. If not, am I doing something
>>>>>> wrong
>>>>>> and how can I achieve the same result in the correct way?
>>>>>>
>>>>>> Thanks,
>>>>>> Jacob
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users@lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> listUSRP-users@lists.ettus.comhttp://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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160711/816db6a1/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 11 Jul 2016 10:01:10 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E310 temperature sensors
Message-ID: <5783d0d6.4070...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Jason,
it's one of our sensors; it's called 'temp'.
Cheers,
M
On 07/11/2016 09:06 AM, Jason Matusiak via USRP-users wrote:
> From Python, I know how to pull in that the documentation refers to as
> the processor's temperature sensor and that is working fine (using the
> get_mboard_sensors approach).
>
> My question is, is there a way to pull down the AD9361's temp sensor
> from Python? I see that you can do it via C++ using the
> ad9361_ctrl::get_temperature() function, but I don't see how to do that
> from Python....
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 5
Date: Mon, 11 Jul 2016 10:06:18 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] A question about temperature sensor on
USRP-B200mini
Message-ID: <5783d20a.10...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Hi,
it's available through our sensor API. See here, for example:
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#acd37d327931cec64e3701eb2a5aa7bfb
This will return the rx sensors (we have mboard, rx and tx sensors).
The temperature sensor is called 'temp'.
M
On 07/07/2016 12:01 AM, Charlie Von via USRP-users wrote:
> Dear customer service of Eutts,
>
>
>
> I have a question for consultation about programming on USRP-B200mini.
>
> I program for USRP-B200mini on Microsoft Viusal Studio 2010 using UHD
> API which downloaded from Github.
>
>
>
> Is there any temperature sensor on USRP-B200mini board or AD9361/AD9364?
>
> How can I get the temperature by UHD API?
>
> Could you give me the program example code?
>
>
>
> I will be very grateful if you can give me a feedback.
>
>
>
> sincerely Charlie
>
> China National Institution of Radio and Spectrum Management
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Mon, 11 Jul 2016 13:11:40 -0400
From: Jason Matusiak <ja...@gardettoengineering.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E310 temperature sensors
Message-ID: <5783d34c.6080...@gardettoengineering.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Martin,
I thought that "temp" was the processor's temperature? Is that the only
thing we have access to from python? If you look through the device
tree, it appears that the RF sensors should have a temp, but I can't get
a response. If I type:
uhd_usrp_probe --string="/mboards/0/dboards/A/tx_frontends/A/sensors/temp"
I get the response:
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga_sg3.bit... done
-- Detecting internal GPSDO .... found
-- Initializing core control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting time source to internal
-- Asking for clock rate 16 MHz
-- Actually got clock rate 16 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
temp
-- Loading FPGA image:
/usr/share/uhd/images/usrp_e3xx_fpga_idle_sg3.bit... done
(With that word" temp" in the second to last line). If I use --int or
--double instead, the second to last line shows:
Segmentation fault
------------------------------------------------------------------------
Jason,
it's one of our sensors; it's called 'temp'.
Cheers,
M
On 07/11/2016 09:06 AM, Jason Matusiak via USRP-users wrote:
>/ From Python, I know how to pull in that the documentation refers to as
>/>/the processor's temperature sensor and that is working fine (using the
>/>/get_mboard_sensors approach). />//>/My question is, is there a way to pull
>down the AD9361's temp sensor />/from Python? I see that you can do it via C++
>using the />/ad9361_ctrl::get_temperature() function, but I don't see how to
>do that />/from Python..../
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160711/d243c573/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 11 Jul 2016 10:12:13 -0700
From: Martin Braun <martin.br...@ettus.com>
To: "'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNOC Error: Path not found in tree:
/mboards/0/dboards/B/rx_frontends/0/name
Message-ID: <5783d36d.9080...@ettus.com>
Content-Type: text/plain; charset=utf-8
Rebecca,
are you using the rfnoc-devel branch? If not, have you considered the
rfnoc-radio-redo branch?
Also, are you setting some explicit subdev spec? Like B:0?
Basic and LF boards are supported with RFNoC, but if you're seeing
problems I'd like to get to the bottom of that.
Cheers,
M
On 07/05/2016 05:54 AM, Rebecca Baldwin wrote:
>
> Hello,
>
> I took a break from working on this project, but I've recently restarted
> work with the x310 and x300, and I am still having this problem. The
> uhd (rfnoc) files are up-to-date.
>
> Basically, all the ettus provided "tests" work, but all the ettus
> examples (and gr-ettus examples) fail when the Basic RX daughterboard is
> in the x310. I don't believe it's a problem with the daughterboard
> because I had the same result when I tried using an LFRX daughterboard.
> Are there any issues when using gnuradio or the ettus examples with
> daughterboards at the lower frequencies? I need a solution that uses
> rfnoc as well as the lower frequency range.
>
> Any help is appreciated.
> Thanks!
> -Becca
>
>
>
> On Fri, Sep 11, 2015 at 1:29 PM, Rebecca Baldwin <rnbaldwi...@gmail.com
> <mailto:rnbaldwi...@gmail.com>> wrote:
>
> I only tried the ./gpio and ./rx_samples_to_file (with arguments).
> I ran the same two with BasicRX (failed) and the SBX (worked).
>
> On Fri, Sep 11, 2015 at 1:25 PM, Martin Braun
> <martin.br...@ettus.com <mailto:martin.br...@ettus.com>> wrote:
>
> On 11.09.2015 10:24, Rebecca Baldwin wrote:
> > I was actually able to get an SBX db (rev. 5). I tested the same
> apps,
> > and they seemed to work as well. Although I'm not sure why this
> would
> > interfere with the gpio code at all, the problem definitely seems
> to be
> > the BasicRX db.
> >
> > I'm using Ubuntu 14.04 and the connection to the x310 is through 1G
> > ethernet. If you need/want anymore info, please let me know!
>
> Which code were you running to make this fail?
>
> M
>
>
>
>
------------------------------
Message: 8
Date: Mon, 11 Jul 2016 10:14:24 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com, Philip Balister <phi...@opensdr.com>,
Moritz Fischer <moritz.fisc...@ettus.com>
Subject: Re: [USRP-users] temp sensors and PLL lock on E310
Message-ID: <5783d3f0.4080...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Jason,
I think I've answered how to read the AD9361 temp sensor in a separate
thread (sensor API, "temp" sensor). For the Zynq temp sensor, you can
use Linux tools to read that out; Phil or Moritz will know the correct
incantation.
Cheers,
M
On 07/01/2016 06:22 AM, Jason Matusiak via USRP-users wrote:
> Talking with Ben yesterday, we realized that we probably need to be
> monitoring the two temp sensors that UHD has access to on the E310 as
> well as the digital PLL lock to try to narrow down some inconsistencies
> we are seeing in our TDOA work that we can't figure out if it is on us
> or a potential bug in the E310.
>
> I've done a little research, but come up blank. What is the easiest way
> to query the two temp sensors on the E310?
>
> And is there a way to monitor the digital PLL to make sure it hasn't
> lost lock for some reason?
>
> TIA!!!
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 9
Date: Mon, 11 Jul 2016 10:15:16 -0700
From: Martin Braun <martin.br...@ettus.com>
To: devin kelly <dwwke...@gmail.com>, usrp-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Building a custom RFNoC FPGA Image with the
right compat number
Message-ID: <5783d424.7070...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Devin,
see this:
On 07/01/2016 06:22 AM, devin kelly via USRP-users wrote:
> OK, I've tried building some more FPGA images and I'm still having problems:
>
> root@ettus-e300:~# uhd_usrp_probe --args='fpga=usrp_e310_fpga_RFNOC.bit'
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-0-unknown
...doesn't tell us what branch you're working off of. Looks like this
was not built in a git repo? What's your UHD branch?
M
>
> -- Loading FPGA image: usrp_e310_fpga_RFNOC.bit... done
> -- Detecting internal GPSDO .... found
> -- Initializing core control...
> -- Performing register loopback test... pass
> -- Setting up dest map for ep 0 to be stream 1
> -- Performing register loopback test... fail
> -- [RFNOC] ------- Radio Setup -----------
> -- [RFNoC Factory] block_ctrl_base::make()
> -- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- base_path = "/usr/share/uhd/rfnoc"
> -- base_path = "/usr/share/uhd/rfnoc"
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/block.xml
> -- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type =
> '' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type
> = '' pkt_size = '0' vlen = '0'
> -- radio_ctrl::radio_ctrl() _rx_spp==364
> -- setting xbar/Radio_0/ports/out/0
> -- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
> -- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
> -- [0/Radio_0] radio_ctrl::_update_rx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- [0/Radio_0] radio_ctrl::_update_tx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- dboards/A/tx_frontends/A/connection == IQ
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- dboards/A/rx_frontends/A/connection == IQ
> -- Setting up dest map for ep 1 to be stream 4
> -- Performing register loopback test... fail
> -- [RFNOC] ------- Radio Setup -----------
> -- [RFNoC Factory] block_ctrl_base::make()
> -- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- base_path = "/usr/share/uhd/rfnoc"
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- Found valid blockdef
> -- NOC ID: 0xF1F0000000000000 Block ID: 0/Radio_1
> -- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/0: type =
> '' pkt_size = '0' vlen = '0'
> -- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/0: type
> = '' pkt_size = '0' vlen = '0'
> -- radio_ctrl::radio_ctrl() _rx_spp==364
> -- setting xbar/Radio_1/ports/out/0
> -- [0/Radio_1] radio_ctrl::_update_spp(): Requested spp: 364
> -- [0/Radio_1] radio_ctrl::_update_spp(): Setting spp to: 364
> -- [0/Radio_1] radio_ctrl::_update_rx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- [0/Radio_1] radio_ctrl::_update_tx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- dboards/A/tx_frontends/B/connection == IQ
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- dboards/A/rx_frontends/B/connection == IQ
> -- Performing CODEC loopback test... fail
> Error: RuntimeError: CODEC loopback test failed.
>
> root@ettus-e300:~# uhd_usrp_probe
> --args='fpga=e300.bit'
>
>
>
>
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-0-unknown
>
> -- Loading FPGA image: e300.bit... done
> Error: RuntimeError: [ad9361_device_t] BBPLL not locked
>
> I suspect these are both related to having my UHD library and FPGA image
> being out of sync. I noticed someone else having this issue (CODEC
> loopback test failed) with their E310 on the mailing list earlier but
> there wasn't a resolution.
>
> Devin
>
>
> On Fri, Jul 1, 2016 at 8:56 AM, devin kelly <dwwke...@gmail.com
> <mailto:dwwke...@gmail.com>> wrote:
>
> I made sure my submodules matched the branch of my main module repo
> and that worked ok. I also checked e310_core.v and the third item
> was "8'd255" which matches what I was looking for. However I now
> have a new problem
>
> uhd_usrp_probe --args='fpga=e300.bit'
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-0-unknown
>
> -- Loading FPGA image: e300.bit... done
> -- Detecting internal GPSDO .... found
> -- Initializing core control...
> -- Performing register loopback test... pass
> -- Setting up dest map for ep 0 to be stream 1
> -- Performing register loopback test... fail
> -- [RFNOC] ------- Radio Setup -----------
> -- [RFNoC Factory] block_ctrl_base::make()
> -- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- base_path = "/usr/share/uhd/rfnoc"
> -- base_path = "/usr/share/uhd/rfnoc"
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/block.xml
> -- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0:
> type = '' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0:
> type = '' pkt_size = '0' vlen = '0'
> -- radio_ctrl::radio_ctrl() _rx_spp==364
> -- setting xbar/Radio_0/ports/out/0
> -- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
> -- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
> -- [0/Radio_0] radio_ctrl::_update_rx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- [0/Radio_0] radio_ctrl::_update_tx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- dboards/A/tx_frontends/A/connection == IQ
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- dboards/A/rx_frontends/A/connection == IQ
> -- Setting up dest map for ep 1 to be stream 4
> -- Performing register loopback test... Error: EnvironmentError:
> IOError: Radio ctrl (1) no response packet - AssertionError: bool(buff)
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at
>
> /home/balister/fido-rfnoc-test/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.9.1.51-r0/git/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
>
> A co-worker tells me he's had this problem before and the cause was
> the FPGA code being further along than UHD C++ code. The FPGA code
> I'm building is the latest rfnoc-radio-redo (b62d96c) and the E310
> image I'm using is this one:
>
> # cat /etc/version-image
> Timestamp: 201511241931
> Release:
> Image: gnuradio-dev-image
>
>
> Which I'm pretty sure I got from here:
> http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/
>
> Do I need to use older FPGA sources? Is there any way of knowing
> how far back I have to go?
>
> Thanks again,
> Devin
>
>
> On Thu, Jun 30, 2016 at 5:08 PM, Martin Braun via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> On 06/30/2016 11:57 AM, devin kelly via USRP-users wrote:
> > Like the page below says to do (as an aside, why I am I using
> > uhd_usrp_probe on the E310 and uhd_image_loader on other USRPs?).
>
> Devin,
>
> the E310 auto-loads the FPGA image every time a UHD session is
> instantiated, so you don't need uhd_image_loader.
>
> >
> > http://files.ettus.com/manual/page_usrp_e3x0.html
> >
> > It seems the version of the FPGA image I've built doesn't match the
> > version of the UHD I have on my E310. I think this is because I
> did this:
> >
> > |$ git clone --recursive https:||//github.com/EttusResearch/uhd.git
> <http://github.com/EttusResearch/uhd.git>
> > <http://github.com/EttusResearch/uhd.git>
> > |
> > |$ cd uhd
> > |
> > |$ git checkout -b ||rfnoc-radio-redo origin/||rfnoc-radio-redo|
> >
> > instead of this:
> >
> > |git clone -b rfnoc-radio-redo --recursive
> > https:||//github.com/EttusResearch/uhd.git
> <http://github.com/EttusResearch/uhd.git>
> > <http://github.com/EttusResearch/uhd.git>
>
> If you're using the submodule, are you running 'git submodulate
> update'?
>
> Cheers,
> M
> >
> > |
> > So the version of my submodules didn't match the version of my main
> > module. I'm currently building the code from the second command.
> Since
> > building the FPGA image takes a while on my computer is there some
> way
> > to check what the compatibility number will be for my image before I
> > build it? The best I've been able to do is this:
> >
> > $ pwd
> > /home/devin/uhd/fpga-src/usrp3/top/e300
> > $ find . -name '*.v' -exec grep -Hi compat {} \;
> > ./e310_core.v: localparam RB32_CORE_COMPAT = 5'd2;
> > ./e310_core.v: RB32_CORE_COMPAT : rb_data <= {8'hAC, 8'h0,
> 8'd16,
> > 8'd0};
> >
> > It's not totally clear to me if the "8'd16" in rb_data corresponds
> to
> > the 16.0 compatibility number I get in my image. It seems that
> other
> > USRPs have clearer compatibility numbers, like the b200 at this
> link:
> >
> >
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/b200/b200_core.v#L81
> >
> > Thanks for the help,
> > Devin
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com <mailto: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 <mailto: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
>
------------------------------
Message: 10
Date: Mon, 11 Jul 2016 10:30:25 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E310 temperature sensors
Message-ID: <5783d7b1.2050...@ettus.com>
Content-Type: text/plain; charset=windows-1252
This property is sensor_value_t, so you can't read it out like that. But
you can use gr-uhd sensor API to get the sensor value and then do a
to_double().
M
On 07/11/2016 10:11 AM, Jason Matusiak via USRP-users wrote:
> Martin,
>
> I thought that "temp" was the processor's temperature? Is that the only
> thing we have access to from python? If you look through the device
> tree, it appears that the RF sensors should have a temp, but I can't get
> a response. If I type:
> uhd_usrp_probe --string="/mboards/0/dboards/A/tx_frontends/A/sensors/temp"
>
> I get the response:
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
>
> -- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga_sg3.bit... done
> -- Detecting internal GPSDO .... found
> -- Initializing core control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Setting time source to internal
> -- Asking for clock rate 16 MHz
> -- Actually got clock rate 16 MHz
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> temp
> -- Loading FPGA image:
> /usr/share/uhd/images/usrp_e3xx_fpga_idle_sg3.bit... done
>
> (With that word" temp" in the second to last line). If I use --int or
> --double instead, the second to last line shows:
> Segmentation fault
>
>
>
> ------------------------------------------------------------------------
>
> Jason,
>
> it's one of our sensors; it's called 'temp'.
>
> Cheers,
> M
>
> On 07/11/2016 09:06 AM, Jason Matusiak via USRP-users wrote:
>>/From Python, I know how to pull in that the documentation refers to as
>>/>/the processor's temperature sensor and that is working fine (using the
>>/>/get_mboard_sensors approach). />//>/My question is, is there a way to pull
>>down the AD9361's temp sensor />/from Python? I see that you can do it via
>>C++ using the />/ad9361_ctrl::get_temperature() function, but I don't see how
>>to do that />/from Python..../
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 11
Date: Mon, 11 Jul 2016 13:48:12 -0400
From: Jason Matusiak <ja...@gardettoengineering.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E310 temperature sensors
Message-ID: <5783dbdc.8080...@gardettoengineering.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Martin,
I assume that by sensor API you mean something like the:
get_mboard_sensor("temp") call? That is working fine (I actually don't have
the 100% accurate call in front of me right now, so that might be a bit off).
What doesn't seem to work is get_rx_sensor_names and get_tx_sensor_names, which
I think should work and allow me to probe that particular temp sensor.
As for your CPU linux temp comment, it looks like "cat
/sys/devices/virtual/thermal/thermal_zone0/temp" shows the CPU temperature
multiplied by 1000 (so it currently shows me 35000, which equates to 35C).
___________________________________________________________________
This property is sensor_value_t, so you can't read it out like that. But
you can use gr-uhd sensor API to get the sensor value and then do a
to_double().
M
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160711/a05d0b7e/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 11 Jul 2016 13:03:13 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E310 temperature sensors
Message-ID: <5783fb81.7090...@ettus.com>
Content-Type: text/plain; charset=windows-1252
get_mboard_sensor("temp") will return the Zynq temperature.
For the AD9361 temperature, this should work:
U = uhd.usrp_source(...)
U.get_sensor('temp').to_real()
M
On 07/11/2016 10:48 AM, Jason Matusiak via USRP-users wrote:
> Martin,
>
> I assume that by sensor API you mean something like the:
> get_mboard_sensor("temp") call? That is working fine (I actually don't have
> the 100% accurate call in front of me right now, so that might be a bit off).
>
> What doesn't seem to work is get_rx_sensor_names and get_tx_sensor_names,
> which I think should work and allow me to probe that particular temp sensor.
>
> As for your CPU linux temp comment, it looks like "cat
> /sys/devices/virtual/thermal/thermal_zone0/temp" shows the CPU temperature
> multiplied by 1000 (so it currently shows me 35000, which equates to 35C).
>
> ___________________________________________________________________
> This property is sensor_value_t, so you can't read it out like that. But
> you can use gr-uhd sensor API to get the sensor value and then do a
> to_double().
>
> M
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 13
Date: Mon, 11 Jul 2016 13:38:03 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Format of complex data saved thru
uhd_rx_cfile. Is it Q15 ?
Message-ID: <578403ab.7030...@ettus.com>
Content-Type: text/plain; charset=windows-1252
It supports different formats (fc32, sc16 and maybe more). fc32 ==
32-bit I, 32-bit Q (floating point), sc16 == 16-bit I, 16-bit Q (fixed
point).
M
On 07/11/2016 01:29 AM, Sumit Kumar via USRP-users wrote:
> Does the uhd_rx_cfile save the I and Q complex data in Q15 format. I
> recorded the Wifi data, converted to .mat file and I see that its a very
> small floating point value.
>
> --
> --
> Sumit kumar
> Doctoral Student, UPMC
> Eurecom, BIOT
> France
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 14
Date: Mon, 11 Jul 2016 19:21:59 +0000 (UTC)
From: Chavez, Christopher A. (Assoc) <christopher.cha...@nist.gov>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210 - signals shifted when using both
TX channels and LO offsets
Message-ID: <loom.20160711t212051-...@post.gmane.org>
Content-Type: text/plain; charset=utf-8
Hi Marcus,
Marcus M?ller via USRP-users <usrp-users@...> writes:
> I think it could be a UHD bug with an easy workaround: can you
> specify "type=b200,master_clock_rate=25e6" as the device string
> and see whether that solves your problem?
For what I was originally attempting (two adjacent channels), this does
work.
I'm guessing the issue has to do with how UHD is setting the master
clock rate,
where it might not use the same multiple of the sample rate, affecting
how large
of an LO offset can be used. For example, at 12.5MSa/s, it set to 50MHz
(allowing for LO offsets up to 12.5MHz), whereas when both TX channels
are used
it is set to 12.5MHz (no LO offset possible depending on how wide the
signal
spectrum is). This might be expected since certain multiples are beyond
the
30.72MHz limit when both channels are used.
Two remaining questions I have at the moment:
1. Why does UHD not use 25MHz instead of 12.5MHz for two transmitters?
(possibly the essence of this bug: 25MHz is below the 30.72MHz limit
when both
channels are used)
2. In general, would the maximum "safe" LO offset be
(master_clock_rate + samp_rate) / 2
unless limited by the filter?
For example, for samp_rate=12.5MHz and master_clock_rate=25MHz, the
maximum
LO offset appears to be 6.25MHz; and for samp_rate=12.5MHz and
master_clock_rate=50MHz, the maximum LO offset appears to be 18.75MHz.
Thanks,
Christopher A. Chavez
National Institute of Standards and Technology
------------------------------
Message: 15
Date: Mon, 11 Jul 2016 23:42:56 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] ??: Re:usrp-n210:Expected FPGA compatibility
number 10,but got 16
Message-ID: <a2ae244d-8a7d-9888-d4ad-aed4dde63...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Dear Wangerw,
you've found a bug within the updater code; we'll need to fix this as
fast as possible.
Can you locate the "usrp_n2xx_simple_net_burner" program on your
computer and use it instead?
usrp_n2xx_simple_net_burner --addr XXX.XXX.XXX.XXX
(replace XXX.... with the IP address of your USRP, please).
Best regards,
Marcus
On 10.07.2016 15:24, ??? via USRP-users wrote:
>
>
>
>
>
> *???:*???[mailto:wang...@outlook.com]
> *????:*2016?7?10?16:38
> *???:*marcus.muel...@ettus.com
> *??:*RE:Re:usrp-n210:Expected FPGA compatibility number 10,but got 16
>
>
>
> Dear marcus.mueler,
> I check my network card by use "lspci|grep -i ether", the
> network card message is presented in terminal as : Ethernet
> controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03).
>
> The network capture by wireshark is in attachment.
> In addition, I update my UHD and images to
> UHD_003.009.004-release. But the problem is still present.
> Thank you very very much for you to take time to help me
> resolute the problem!
>
>
> sincerely
>
>
> wangerw
>
>
>
> _______________________________________________
> USRP-users mailing list
> 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/20160711/16e6e573/attachment-0001.html>
------------------------------
Message: 16
Date: Mon, 11 Jul 2016 17:49:31 -0400
From: Eugene Lee <eugene....@syntonicscorp.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] (no subject)
Message-ID:
<CAPcMpt=j7CxmeTW=5d403yuovna7xnkvszhquh6-q_xbmlp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have an N210 revision 4 with Ubuntu. I had it working several years ago,
and am trying to get the system running again.
I can ping 192.168.10.2
I can also run uhd_find_devices with success
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: usrp2
addr: 192.168.10.2
name:
serial: E7R17S1UP
When I run uhd_usrp_probe, I get the following
linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.005.000-release
-- Opening a USRP2/N-Series device...
Error: RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 10, but got 16:
The FPGA build is not compatible with the host code build.
Please run:
sudo "/usr/share/uhd/utils/uhd_images_downloader.py"
"/usr/share/uhd/utils/usrp_n2xx_simple_net_burner" \
--addr="192.168.10.2"
I can download the uhd_images with success. The simple_net_burner doesn't
work, but I am able to use
./usrp_n2xx_net_burner.py --addr=192.168.10.2
--fpga="/usr/share/uhd/images/usrp_n210_r4_fpga.bin"
to write both the FPGA and firmware.
I can still ping and find the n210 but I still get the firmware issue. When
I power cycle the device then I cannot see the N210 at all. No ping, no
uhd_find_devices, no uhd_usrp_probe. I have to hit s2 and reboot the device
in order to recover. I have gone through the above process several times,
hoping that I initially got a bad image. Any suggestions?
Thanks,
Eugene
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160711/74b892af/attachment-0001.html>
------------------------------
Message: 17
Date: Mon, 11 Jul 2016 21:55:35 +0000 (UTC)
From: Chavez, Christopher A. (Assoc) <christopher.cha...@nist.gov>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210 - signals shifted when using both
TX channels and LO offsets
Message-ID: <loom.20160711t235407-...@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
Chavez, Christopher A. (Assoc) via USRP-users <usrp-users@...>
writes:
> 2. In general, would the maximum "safe" LO offset be
> (master_clock_rate + samp_rate) / 2
> unless limited by the filter?
The '+' sign should be a '-' sign:
lo_offset <= (master_clock_rate - samp_rate) / 2
Christopher A. Chavez
National Institute of Standards and Technology
------------------------------
Message: 18
Date: Tue, 12 Jul 2016 00:11:13 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: Ian Buckley <i...@ionconcepts.com>, ?? <leon...@qq.com>
Cc: usrp-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] ??? Problem using B210 with two different RX
frequency
Message-ID: <57a1dbc4-914f-b77b-317a-d428c72a0...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Found it!
Ian was referring to the attached email from 2016-05-05; The trick
applies to you, too!
Best regards,
Marcus
On 11.07.2016 18:03, Ian Buckley wrote:
> Zhangmeng,
> AD9361 when using CMOS interface mode has this limitation. In LVDS
> mode this limitation does not exist. B2xxx products only support CMOS
> mode. You'll want to refer to the "Digital Interface" Chapter (Table 48).
>
> Marcus,
> For GSM 850/900 you can suggest (to Zhang) a single channel B210 usage
> model using the CORDIC as we have discussed earlier to place the UL/DL
> in close adjacency around DC, and the DDC to reduce the data rate to
> the host, it works well. Sadly for GSM 1800/1900 the channel spacing
> tends to be too far.
>
> -Ian
>
>
> On Sat, Jul 9, 2016 at 4:21 AM, ?? via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi Marcus!
>
> Thanks for your reply!
> The parameter "master_clock_rate" for B210 means the
> sampling rate of the ADC in AD9361, right? Do you means that the 2
> RX channels share a total rate of 61.44Msps? I noticed that when
> using 2 channels the UHD set the highest master_clock_rate to
> 30.72MHz. I thought it's just a consideration for USB 3.0
> transmission. So I simply disabled the "enforce_tick_rate_limits"
> function in b200_impl.cc in UHD source code and set the "tune"
> function in ad9361_ctrl.cpp to a constant (e.g 940MHz) and
> compiled the UHD again. Then I can set the master_clock_rate
> higher. For example, I set master_clock_rate to 40MHz and sampling
> rate to 4Msps. I can see messages printed by UHD said the LO, the
> master clock rate, the decimation rate and the sampling rate were
> set as I expected. When I changed the center frequency of 2
> channels, I can also see the DSP DDC works well. Also the FFT
> results showed the GSM downlink signals correctly. This just
> didn't work when the master_clock_rate set higher than 45MHz. I
> noticed that the noise floor raised about 20dB. It seemed that the
> GSM signal is covered.
>
> I just took a simply look at the AD9361 datasheet and I
> didn't find the description for "2 channels share a total rate of
> 61.44Msps". Could you show me where the description is? If this
> is the reason I failed, what should I do?
>
> My application: uplink 885--890MHz & downlink 930 -- 935MHz.
>
> Thank you!
>
> Zhangmeng
>
>
> ------------------ ???? ------------------
> *???:* "Marcus M?ller via USRP-users";<usrp-users@lists.ettus.com
> <mailto:usrp-users@lists.ettus.com>>;
> *????:* 2016?7?9?(???) ??5:30
> *???:* "usrp-users"<usrp-users@lists.ettus.com
> <mailto:usrp-users@lists.ettus.com>>;
> *??:* Re: [USRP-users] Problem using B210 with two different RX
> frequency
>
> Hi Zhangmeng,
>
>> I disabled the limit of sampling rate in UHD while using two RXs.
> What exactly did you change? As far as I know, there's only one
> limit in there ? and that's the hardware limitation of the AD9361
> chip, which can't use full rates in dual channel configuration.
>> Then I set the master_clock_rate to 32MHz - 44MHz and it works fine
> Last time I tried, the maximum master clock rate for two channels
> is 30.72 MHz, as dictated by by the maximum data clock frequency
> of the AD9361, which is 61.44 MHz, and has to be shared between
> the two channels. So, in fact, I'm a little surprised you say it
> works fine!
>
>> When I set master_clock_rate to 32MHz or higher, sampling rate of
>> data processing on PC is set to 2M to 4Msps.
> Are you sure you've actually set a master clock rate of > 30.72
> MHz? Is it possible that UHD automatically used a different rate?
>
> So, I'd like to fully understand the situation here:
> We're talking about E-GSM 900, with uplink at 880.0 ? 915.0 MHz
> and downlink at 925.0 ? 960.0, right?
>
> Best regards,
>
> Marcus
>
>
> On 08.07.2016 05:56, ?? via USRP-users wrote:
>>
>> Hi!
>>
>> Recently I tried to use B210 to receive both uplink and
>> downlink channels of GSM 900. I noticed that the two RX channels
>> in AD9361 share one LO. So I have to set a high sampling rate (at
>> least 45Msps) and do DDC and decimation using FPGA. I disabled
>> the limit of sampling rate in UHD while using two RXs. Then I set
>> the master_clock_rate to 32MHz - 44MHz and it works fine. But
>> when I set the master_clock_rate higher than 45MHz I got nothing
>> but noise. It doesn't works when the rate is higher than 45MHz.
>> What's wrong with that? Or is there other way to receive both
>> up&downlink of GSM signals using B210?
>>
>> PS: When I set master_clock_rate to 32MHz or higher, sampling
>> rate of data processing on PC is set to 2M to 4Msps.
>>
>> Best wishes!
>>
>> ------------------------------------------------------------------------
>> Zhangmeng
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto: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 <mailto: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/20160712/f99ec11c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Re: [USRP-users] Customize FPGA on B2xx.eml
Type: application/x-extension-eml
Size: 96738 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/f99ec11c/attachment-0001.eml>
------------------------------
Message: 19
Date: Tue, 12 Jul 2016 00:25:07 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210 - signals shifted when using both
TX channels and LO offsets
Message-ID: <582fbf72-b3e9-3161-5161-03b74fd93...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Hi Christopher,
> I'm guessing the issue has to do with how UHD is setting the master
> clock rate,
Exactly. When not setting an MCR explicitly, UHD choses one autonomously
? and worse, this choice isn't inherently shared with all the involved
parties :( so digital offset tuning might behave *very* strange.
I think there's a bug fix for this in the pipeline.
> 1. Why does UHD not use 25MHz instead of 12.5MHz for two transmitters?
> (possibly the essence of this bug: 25MHz is below the 30.72MHz limit
> when both
> channels are used)
Good question; um. I think the formula is essentially, $r$ being the
minimum common multiple of all the rates you asked for (== sampling
rate, if all channels have the same rate):
$r \cdot 2^{\left\lfloor\log_2\frac{\text{MCR}_{max}}{r}\right\rfloor}$,
i.e. for your case, $r=12.5\,\frac{\text{MS}}{\text s}$
$12.5\,\frac{\text{MS}}{\text s} \cdot
2^{\left\lfloor\log_2\frac{30.72\,\frac{\text{MS}}{\text
s}}{12.5\,\frac{\text{MS}}{\text s}}\right\rfloor}$
which should be 25MS/s, indeed.
> 2. In general, would the maximum "safe" LO offset be
> (master_clock_rate *-* samp_rate) / 2
> unless limited by the filter?
Yes!
Best regards,
Marcus
On 11.07.2016 21:21, Chavez, Christopher A. (Assoc) via USRP-users wrote:
> Hi Marcus,
>
> Marcus M?ller via USRP-users <usrp-users@...> writes:
>> I think it could be a UHD bug with an easy workaround: can you
>> specify "type=b200,master_clock_rate=25e6" as the device string
>> and see whether that solves your problem?
> For what I was originally attempting (two adjacent channels), this does
> work.
> I'm guessing the issue has to do with how UHD is setting the master
> clock rate,
> where it might not use the same multiple of the sample rate, affecting
> how large
> of an LO offset can be used. For example, at 12.5MSa/s, it set to 50MHz
> (allowing for LO offsets up to 12.5MHz), whereas when both TX channels
> are used
> it is set to 12.5MHz (no LO offset possible depending on how wide the
> signal
> spectrum is). This might be expected since certain multiples are beyond
> the
> 30.72MHz limit when both channels are used.
>
> Two remaining questions I have at the moment:
>
> 1. Why does UHD not use 25MHz instead of 12.5MHz for two transmitters?
> (possibly the essence of this bug: 25MHz is below the 30.72MHz limit
> when both
> channels are used)
>
> 2. In general, would the maximum "safe" LO offset be
> (master_clock_rate + samp_rate) / 2
> unless limited by the filter?
>
> For example, for samp_rate=12.5MHz and master_clock_rate=25MHz, the
> maximum
> LO offset appears to be 6.25MHz; and for samp_rate=12.5MHz and
> master_clock_rate=50MHz, the maximum LO offset appears to be 18.75MHz.
>
>
> Thanks,
>
> Christopher A. Chavez
> National Institute of Standards and Technology
> _______________________________________________
> USRP-users mailing list
> 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/20160712/202ebd34/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-3.png
Type: image/png
Size: 552 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/202ebd34/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-7.png
Type: image/png
Size: 1391 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/202ebd34/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-5.png
Type: image/png
Size: 1186 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/202ebd34/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-6.png
Type: image/png
Size: 2206 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/202ebd34/attachment-0007.png>
------------------------------
Message: 20
Date: Mon, 11 Jul 2016 19:19:53 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] (no subject)
Message-ID: <57842999.20...@ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 07/11/2016 05:49 PM, Eugene Lee via USRP-users wrote:
> I have an N210 revision 4 with Ubuntu. I had it working several years
> ago, and am trying to get the system running again.
> I can ping 192.168.10.2
> I can also run uhd_find_devices with success
>
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: usrp2
> addr: 192.168.10.2
> name:
> serial: E7R17S1UP
>
> When I run uhd_usrp_probe, I get the following
>
> linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.005.000-release
>
> -- Opening a USRP2/N-Series device...
> Error: RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 10, but got 16:
> The FPGA build is not compatible with the host code build.
> Please run:
>
> sudo "/usr/share/uhd/utils/uhd_images_downloader.py"
> "/usr/share/uhd/utils/usrp_n2xx_simple_net_burner" \
> --addr="192.168.10.2"
>
> I can download the uhd_images with success. The simple_net_burner
> doesn't work, but I am able to use
> ./usrp_n2xx_net_burner.py --addr=192.168.10.2
> --fpga="/usr/share/uhd/images/usrp_n210_r4_fpga.bin"
> to write both the FPGA and firmware.
>
> I can still ping and find the n210 but I still get the firmware issue.
> When I power cycle the device then I cannot see the N210 at all. No
> ping, no uhd_find_devices, no uhd_usrp_probe. I have to hit s2 and
> reboot the device in order to recover. I have gone through the above
> process several times, hoping that I initially got a bad image. Any
> suggestions?
>
> Thanks,
> Eugene
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I would start out with a *MUCH* newer UHD release.
Once you have that, use "uhd_images_downloader" to download the latest
images, place the device in "safe mode" (with S2), use the
more-modern, uhd_image_loader tool and go from there.
It's conceivable that your device has had a different IP address
programmed into it.
In which case, you can use:
usrp2_recover.py Which is kind of a "hail mary". Requires that your
N2xx/USRP2 be locally-connected to your host, with nothing else on that
port.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160711/56cc0e5c/attachment-0001.html>
------------------------------
Message: 21
Date: Tue, 12 Jul 2016 05:51:51 +0000
From: Nik B. <nikke...@outlook.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Waveform received from USRP2 freezes
Message-ID:
<kl1pr02mb136895fd0b8051e83b3e093fd0...@kl1pr02mb1368.apcprd02.prod.outlook.com>
Content-Type: text/plain; charset="gb2312"
Hi Marcus,
Thank you for your comments.
Manual calling of the exe file still works.
I even managed to make it work with highly reduced sampling rate (10 MHz to
1KHz), so "communication" itself seems to be ok. I too suspect the USB-LAN
conversion.
Today, I tweaked some setting of the USB-LAN conversion adapter (turned all
"offloads" to OFF, from the device property menu) and now I can see the plots
"moving", even with higher rates. Still, first, I am seeing "got an overflow
indication" message, and second, the moving plots stop from time to time.
I am using the converter made by Logitec (model no: LAN- GT JU3)
http://www.logitec.co.jp/products/lan/langtju3/
Next, I am thinking to use Lenovo's own product (4X90F84315)- haven't bought it
yet.
Would it make any difference?
No idea.
Will share when I try.
Cheers,
N
________________________________
???: USRP-users <usrp-users-boun...@lists.ettus.com> ? Marcus M?ller via
USRP-users <usrp-users@lists.ettus.com> ??????
????: 2016?7?9? 18:36:50
??: usrp-users@lists.ettus.com
??: Re: [USRP-users] Waveform received from USRP2 freezes
Hi Nik,
I have been using Thinkpad X201, and the plot comes out alright, I mean it
shows *some* waveform.
Best notebook ever. Still using that, too. It's a little weak CPU-wise nowadays.
I have a C# program that calls the sample program (rx_sample_to_file.cpp) to
read data from the usrp, and using NPlot (a free cahrting library for .NET),
the C# program plots the waveform.
Does calling rx_samples_to_file.exe manually still work? Because:
The X1 Carbon does not have a wired lan ( how I wished that I knew it before I
bought it!) , so I am using USB to ethernet converter to connect to the usrp.
Could it be the cause?
Yes! We know that most USB3-to-Gigabit-Ethernet adapters don't live up to their
promises, and that the AX???? models tend to just shuffle the order at which
ethernet packets reach your Operating system ? which is fine for file transfers
and such, but UHD doesn't try to re-order packets, being a realtime protocol -
and hence, you get "S" errors (sequence errors) printed by UHD.
If that's not the cause, I'd suspect there's some software reason; I really
don't know your software nor NPlot, but that would be my primary suspect if
recording just goes smooth.
Haven't tried that on a Carbon, but maybe you could download the GNU Radio
LiveDVD [1], write it to a USB memory stick and boot and try if things work
there, e.g. with GQRX.
Best regards,
Marcus
[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
GNURadioLiveDVD - GNU Radio -
gnuradio.org<http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD>
gnuradio.org
Redmine
On 08.07.2016 14:07, Nik B. via USRP-users wrote:
My guess is it is about the graphics hardware or software of my laptop.
Working environment is windows 7.-64.
I have a C# program that calls the sample program (rx_sample_to_file.cpp) to
read data from the usrp, and using NPlot (a free cahrting library for .NET),
the C# program plots the waveform.
I have been using Thinkpad X201, and the plot comes out alright, I mean it
shows *some* waveform.
Today, I got a shiny new X1 Carbon.
I went through the same routine: installed UHD driver ( the latest) for
Windows, installed and configured boost (1.60). Installed Visual Studio 2015
(CE) and compiled and built the above program, just I had done with the X201
few months back.
Now when I click the exe file, I see a GUI and I see that the program starts
to fetch data, but within seconds, the GUI freezes.
The X1 Carbon has Intel HD graphics 520, built-into the CPU.
I don't have the graphics spec of the X201, right now.
I downloaded and installed X1 Carbon's graphics driver just to make sure that I
have the latest.
I visited this page:
https://www.youtube.com/watch?v=1-UdWS4RAA4
and I can see the movie/graphics all smooth and cool.
Yet, the waveform (just random noise from the usrp2, as there is no input to
the device and there is no antenna) freezes for this test.
And the old, old, X201 shows the same waveform smoothly.
Knowlege is power.
How sweet it is to have this knowlege why things don't work as expected.
The X1 Carbon does not have a wired lan ( how I wished that I knew it before I
bought it!) , so I am using USB to ethernet converter to connect to the usrp.
Could it be the cause?
Of course, the X201 does have a wired lan.
Video memory of the X1 was set at 256MB, I changed it to 512MB, but no
improvement.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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/20160712/8194d2e6/attachment-0001.html>
------------------------------
Message: 22
Date: Tue, 12 Jul 2016 12:15:27 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: "Nik B." <nikke...@outlook.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Waveform received from USRP2 freezes
Message-ID: <4673e24b-6acb-2de5-82a0-25cdf4b9c...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Dear Nik,
I got the driver for the LAN-GTJU3 and it's really built around the
AX88179 chip, which we know doesn't work with USRPs well.
Then I went to the Lenovo page and tried to find the driver for the
Lenovo USB Ethernet dongle ? But I only found this [1] page, which,
alarmingly, says:
> Lenovo USB 2.0 Ethernet Adapter
Since USB2.0 isn't fast enough for Gigabit Ethernet, this is not really
an option. In fact, the driver I got on [1] is for the AX88772, which is
not even Gigabit Ethernet, just Fast Ethernet, so it won't work with the
USRP at all! (If this is *really* the correct driver, at least.)
However, Jonathan Hedstrom has made positive experiences with other,
cheap Gigabit adapters. See his mail [2]! In particular, he seemed to be
fond of [3].
Best regards,
Marcus
[1]
http://support.lenovo.com/de/en/products/Laptops-and-netbooks/ThinkPad-X-Series-laptops/ThinkPad-X1-Carbon-Type-34xx/downloads/DS030606
[2]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-April/019548.html
[3]
http://www.amazon.co.jp/Anker-?????????????-LAN?????-RJ45-???????????????/dp/B013JDE2HG/
On 12.07.2016 07:51, Nik B. wrote:
>
> Hi Marcus,
>
> Thank you for your comments.
>
>
> Manual calling of the exe file still works.
>
>
> I even managed to make it work with highly reduced sampling rate (10
> MHz to 1KHz), so "communication" itself seems to be ok. I too suspect
> the USB-LAN conversion.
>
>
> Today, I tweaked some setting of the USB-LAN conversion adapter
> (turned all "offloads" to OFF, from the device property menu) and now
> I can see the plots "moving", even with higher rates. Still, first, I
> am seeing "got an overflow indication" message, and second, the moving
> plots stop from time to time.
>
>
> I am using the converter made by Logitec (model no: LAN- GT JU3)
> http://www.logitec.co.jp/products/lan/langtju3/
>
>
> Next, I am thinking to use Lenovo's own product (4X90F84315)- haven't
> bought it yet.
>
> Would it make any difference?
>
> No idea.
>
> Will share when I try.
>
>
> Cheers,
>
> N
>
>
>
>
> ------------------------------------------------------------------------
> *???:* USRP-users <usrp-users-boun...@lists.ettus.com> ? Marcus M?ller
> via USRP-users <usrp-users@lists.ettus.com> ??????
> *????:* 2016?7?9? 18:36:50
> *??:* usrp-users@lists.ettus.com
> *??:* Re: [USRP-users] Waveform received from USRP2 freezes
>
>
> Hi Nik,
>
>
>> I have been using Thinkpad X201, and the plot comes out alright, I
>> mean it shows *some* waveform.
> Best notebook ever. Still using that, too. It's a little weak CPU-wise
> nowadays.
>> I have a C# program that calls the sample program
>> (rx_sample_to_file.cpp) to read data from the usrp, and using NPlot
>> (a free cahrting library for .NET), the C# program plots the waveform.
> Does calling rx_samples_to_file.exe manually still work? Because:
>
>> The X1 Carbon does not have a wired lan ( how I wished that I knew it
>> before I bought it!) , so I am using USB to ethernet converter to
>> connect to the usrp. Could it be the cause?
> Yes! We know that most USB3-to-Gigabit-Ethernet adapters don't live up
> to their promises, and that the AX???? models tend to just shuffle the
> order at which ethernet packets reach your Operating system ? which is
> fine for file transfers and such, but UHD doesn't try to re-order
> packets, being a realtime protocol - and hence, you get "S" errors
> (sequence errors) printed by UHD.
>
> If that's not the cause, I'd suspect there's some software reason; I
> really don't know your software nor NPlot, but that would be my
> primary suspect if recording just goes smooth.
> Haven't tried that on a Carbon, but maybe you could download the GNU
> Radio LiveDVD [1], write it to a USB memory stick and boot and try if
> things work there, e.g. with GQRX.
>
> Best regards,
> Marcus
>
> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
> GNURadioLiveDVD - GNU Radio - gnuradio.org
> <http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD>
> gnuradio.org
> Redmine
>
>
>
>
> On 08.07.2016 14:07, Nik B. via USRP-users wrote:
>>
>> My guess is it is about the graphics hardware or software of my laptop.
>>
>>
>> Working environment is windows 7.-64.
>>
>> I have a C# program that calls the sample program
>> (rx_sample_to_file.cpp) to read data from the usrp, and using NPlot
>> (a free cahrting library for .NET), the C# program plots the waveform.
>>
>>
>> I have been using Thinkpad X201, and the plot comes out alright, I
>> mean it shows *some* waveform.
>>
>>
>> Today, I got a shiny new X1 Carbon.
>>
>> I went through the same routine: installed UHD driver ( the latest)
>> for Windows, installed and configured boost (1.60). Installed Visual
>> Studio 2015 (CE) and compiled and built the above program, just I had
>> done with the X201 few months back.
>>
>>
>> Now when I click the exe file, I see a GUI and I see that the
>> program starts to fetch data, but within seconds, the GUI freezes.
>>
>>
>> The X1 Carbon has Intel HD graphics 520, built-into the CPU.
>>
>> I don't have the graphics spec of the X201, right now.
>>
>>
>> I downloaded and installed X1 Carbon's graphics driver just to make
>> sure that I have the latest.
>>
>> I visited this page:
>>
>> https://www.youtube.com/watch?v=1-UdWS4RAA4
>>
>> and I can see the movie/graphics all smooth and cool.
>>
>>
>> Yet, the waveform (just random noise from the usrp2, as there is no
>> input to the device and there is no antenna) freezes for this test.
>>
>>
>> And the old, old, X201 shows the same waveform smoothly.
>>
>>
>> Knowlege is power.
>>
>> How sweet it is to have this knowlege why things don't work as expected.
>>
>>
>> The X1 Carbon does not have a wired lan ( how I wished that I knew it
>> before I bought it!) , so I am using USB to ethernet converter to
>> connect to the usrp. Could it be the cause?
>>
>> Of course, the X201 does have a wired lan.
>>
>>
>> Video memory of the X1 was set at 256MB, I changed it to 512MB, but
>> no improvement.
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> 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/20160712/341c78af/attachment-0001.html>
------------------------------
Message: 23
Date: Tue, 12 Jul 2016 14:19:00 +0000
From: Weidong Wang <wwd_u...@hotmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] How to add interrupts on E310's Linux system
Message-ID:
<bl2pr03mb46661fe3c69a105ecab8727f0...@bl2pr03mb466.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
Thanks again Marcus,
I think the interrupt is necessary for this application, because the tracing
processes of each channel could start and stop at any moment, so the CPU need
to feedback very quickly. And I will indeed add an bloc to organize all these
lines.
Any way, I think some new experiences of linux kernel dev are interests also.
Weidong WANG | ?tudiant ? la Ma?trise
Laboratoire LASSENA
?cole de technologie sup?rieure | 1100, rue Notre-Dame Ouest |
Montr?al (Qc) Canada | H3C 1K3
Tel.: 514 396-8800, poste 7930 | Bureau : A-2568 | <http://www.etsmtl.ca>
www.etsmtl.ca<http://www.etsmtl.ca>
Email : <mailto:weidong.w...@lassena.etsmtl.ca>
weidong.w...@lassena.etsmtl.ca<mailto:weidong.w...@lassena.etsmtl.ca>
LASSENA : lassena.etsmtl.ca<http://lassena.etsmtl.ca>
---------------------------------------------------------------------------------
L??TS est une constituante du r?seau de l?Universit? du Qu?bec
----------------------------------------------------------------------------------------------------------------------------
Avis: L'information contenue dans ce courriel est strictement confidentielle.
Toute utilisation par une personne autre que le destinataire est ill?gale.
Si vous recevez ce courriel par erreur, veuillez svp le d?truire et nous en
aviser.
----------------------------------------------------------------------------------------------------------------------------
Notice: The information contained in this message is strictly confidential. Any
use thereof by any person other than the named recipient(s) is illegal.
If you are not the intended recipient please advise sender and delete this
message.
On 16-07-11 11:34 AM, Marcus M?ller wrote:
Hi Weidong,
at these extremely low rates (a combined maximum of 12 kS/s), I'm not convinced
you'd need an interrupt for each of your channels. Personally, I'd try to stay
with the UHD architecture, and just modify the sample handling in the FPGA to
stream buffers that begin with some information on to which channel they belong.
If you really want to stay with a separate data handling routine, using a
single interrupt for all 12 channels does sound sufficient.
Best regards,
Marcus
On 07/11/2016 04:33 PM, Weidong Wang wrote:
Hi Marcus,
Thanks for your explanations.
We use these interrupts because we need compute through 1 kHz interrupt
sub-routine/channel. And GPS has 12 channels. All of our traces and
computations are in reel-time so I think the interrupts are necessary for this
project.
regards,
Weidong WANG | ?tudiant ? la Ma?trise
Laboratoire LASSENA
?cole de technologie sup?rieure | 1100, rue Notre-Dame Ouest |
Montr?al (Qc) Canada | H3C 1K3
Tel.: 514 396-8800, poste 7930 | Bureau : A-2568 | <http://www.etsmtl.ca>
www.etsmtl.ca<http://www.etsmtl.ca>
Email : <mailto:weidong.w...@lassena.etsmtl.ca>
weidong.w...@lassena.etsmtl.ca<mailto:weidong.w...@lassena.etsmtl.ca>
LASSENA : lassena.etsmtl.ca<http://lassena.etsmtl.ca>
---------------------------------------------------------------------------------
L??TS est une constituante du r?seau de l?Universit? du Qu?bec
----------------------------------------------------------------------------------------------------------------------------
Avis: L'information contenue dans ce courriel est strictement confidentielle.
Toute utilisation par une personne autre que le destinataire est ill?gale.
Si vous recevez ce courriel par erreur, veuillez svp le d?truire et nous en
aviser.
----------------------------------------------------------------------------------------------------------------------------
Notice: The information contained in this message is strictly confidential. Any
use thereof by any person other than the named recipient(s) is illegal.
If you are not the intended recipient please advise sender and delete this
message.
On 16-07-11 05:20 AM, Marcus M?ller via USRP-users wrote:
You should probably refer to
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_image_building to
understand how Ettus builds the filesystem images containing the kernel.
Basically, you want to add device tree files in layers, which influences the
build process.
You might want to look into the meta-ettus directory after building a stock
image, and understand where the .dts files are and how they play together with
the kernel build defined in meta-xilinx. These are the things that define what
version of the kernel is built, and what patches are applied.
So, yes, you should use yocto/openembedded. A bit of Linux kernel dev
experience will be necessary to realize what you're planning to do; I'm afraid
copy & pasting from a specific example won't do the trick here :/
You said you're porting an existing GNSS system to the E310; that's a cool
application! Are you sure you need 13 different interrupt lines, really? This
sounds like the state machine your system inherently becomes would be very hard
to manage. What exactly do you need interrupts for? Please excuse my curious
questions; I'm currently working very much with the mindset of someone who
considers signals a stream of samples, and thus, I don't often see the need for
hardware interrupts. Also, UHD has the capability to add timestamps and a bit
of user payload to sample packets, which might be a better choice for a system
running on a non-RT general purpose OS.
Best regards,
Marcus
On 11.07.2016 05:36, Weidong Wang via USRP-users wrote:
Hi Moritz,
Thanks again for your replies.
I am migrating an existed GNSS system into E310. So I need to add at least 13
interrupts into E310's RFNOC system.
I did some searches from Internet, and I fond this blog:
<http://svenand.blogdrive.com/archive/203.html#.V4MP0O1VK1E>
http://svenand.blogdrive.com/archive/203.html#.V4MP0O1VK1E
The author of this blog explained how to add uio into zynq linux system using
the petalinux, linux kernel and the device tree definition file system.dts.
I want to know if I can use the same procedures to add the interrupts? Should I
use yocto instead of petalinux, or together? And what's the linux kernel's
version of E310 and where I can find the device tree definition file of E310?
Best regards,
[cid:part10.02080005.05040704@hotmail.com]<http://etsmtl.ca>
[cid:part12.01050107.05010106@hotmail.com]<http://lassena.etsmtl.ca>
[cid:part14.04060701.07080808@hotmail.com]<http://twitter.com/lassenaets>
[cid:part16.05000505.09030106@hotmail.com]
<http://www.linkedin.com/company/laboratoire-de-recherche-lassena>
[cid:part18.02000506.01030204@hotmail.com]
<http://www.facebook.com/lassena.etsmtl.ca> Weidong WANG | ?tudiant ?
la Ma?trise
Laboratoire LASSENA
?cole de technologie sup?rieure | 1100, rue Notre-Dame Ouest |
Montr?al (Qc) Canada | H3C 1K3
Tel.: 514 396-8800, poste 7930 | Bureau : A-2568 | <http://www.etsmtl.ca>
www.etsmtl.ca<http://www.etsmtl.ca>
Email : <mailto:weidong.w...@lassena.etsmtl.ca>
weidong.w...@lassena.etsmtl.ca<mailto:weidong.w...@lassena.etsmtl.ca>
LASSENA : lassena.etsmtl.ca<http://lassena.etsmtl.ca>
---------------------------------------------------------------------------------
L??TS est une constituante du r?seau de l?Universit? du Qu?bec
----------------------------------------------------------------------------------------------------------------------------
Avis: L'information contenue dans ce courriel est strictement confidentielle.
Toute utilisation par une personne autre que le destinataire est ill?gale.
Si vous recevez ce courriel par erreur, veuillez svp le d?truire et nous en
aviser.
----------------------------------------------------------------------------------------------------------------------------
Notice: The information contained in this message is strictly confidential. Any
use thereof by any person other than the named recipient(s) is illegal.
If you are not the intended recipient please advise sender and delete this
message.
On 16-07-06 01:56 PM, Moritz Fischer wrote:
Hi Weidong,
On Tue, Jul 5, 2016 at 12:52 PM, Weidong Wang via USRP-users
<usrp-users@lists.ettus.com><mailto:usrp-users@lists.ettus.com> wrote:
Hi all,
I want to create a simple CE using RFNOC to generate an interrupt and send
it to the ARM cpu.
1. Could I add this interrupt signal directly to the signal "IRQ_F2P" in
e310.v?
In e310.v line 415, we have :
// Misc interrupts, GPIO, clk
.IRQ_F2P({12'h0, pmu_irq, button_release_irq, button_press_irq,
stream_irq}),
You can either use one of the remaining IRQ lines or turn a GPIO into
an IRQ source.
2. How could I add it in linux system? I fond some topics about it for the
regular linux systems, but it seems not useful for the system on E310.
At what level do you want to deal with the IRQ? Kernel? Userland? UHD
or RFNoC for that
matter currently doesn't have low level primitives do deal with
interrupts, nothing prevents you
from using techniques like UIO or writing a kernel module to receive
interrupts, though.
Moritz
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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/20160712/ceacaac7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT00001.jpg
Type: image/jpeg
Size: 3428 bytes
Desc: ATT00001.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/ceacaac7/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT00002.jpg
Type: image/jpeg
Size: 4984 bytes
Desc: ATT00002.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/ceacaac7/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT00003.png
Type: image/png
Size: 4236 bytes
Desc: ATT00003.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/ceacaac7/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT00004.png
Type: image/png
Size: 4130 bytes
Desc: ATT00004.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/ceacaac7/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT00005.jpg
Type: image/jpeg
Size: 2244 bytes
Desc: ATT00005.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/ceacaac7/attachment-0005.jpg>
------------------------------
Message: 24
Date: Tue, 12 Jul 2016 14:14:47 +0000
From: "Barker, Douglas W." <douglas.bar...@jhuapl.edu>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] DELETE_DSP
Message-ID: <242684e63a934202a0600705ab87f...@aplex06.dom1.jhuapl.edu>
Content-Type: text/plain; charset="us-ascii"
Hello,
I need to access the raw A/D samples from the X310 in an RFNoC implementation.
This can ostensibly be done by setting DELETE_DSP=1. However, the Verilog
implementation seems to remove the rx_frontend.v and ddc_chain_x300.v and does
not replace it with anything or bypass what was removed. Has anyone used
DELETE_DSP or sent the full rate A/D samples over the AXI crossbar?
Thanks
-Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/d092fa74/attachment-0001.html>
------------------------------
Message: 25
Date: Tue, 12 Jul 2016 21:27:17 +0800
From: ?? <franklinzhang1...@gmail.com>
To: Mike McLernon <mike.mcler...@mathworks.com>,
usrp-users@lists.ettus.com
Subject: [USRP-users] Receiving garbage codes with official qpsk tx
and rx model.
Message-ID:
<caeq2z2to7nterut5hlypjwfkbkppr3z047bdcxkbqifv-wn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I tried to hands on the official qpsk tx and rx simulink model as follow:
transmitter: sdruqpskrx.mdl <matlab:sdruqpskrx>.
receiver: sdruqpskrx.mdl <matlab:sdruqpskrx>.
OS ? Windows 7 64bit
USRP?N210 with wbx ?2
matlab?2015b
Carrier Freq?900M (900e6)
However I could only get garbage codes in the command windows of the
receiver as follows:
+1b0Qd6H4mh&Tr4
?&`Mm n x'gZ
H ] gU 2 F*-Dt
O`JYfIYTZZ H
t9dl pR8xZ L}
{D*) o s# *b}e
;O
Qgj,bbi+ Wr
s,9nJ# i5
-:u
~I& jbRjZ] .'Q
zQdvZ AV^x} M_
'P <QK
C3-^ y]l
Excepts adding some instruments I did not modified anything of the official
demo.
Another official demo looks work well.
The digiarm of this experiments are post in this email.
Could anyone give me some suggestions or give me another qpsk demo in the
simulink with usrp.
Thans
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: [RX]ConfigurationOftheReceiver.png
Type: image/png
Size: 148981 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: [RX]ConstellationAfterCoareFrequencyCompen.png
Type: image/png
Size: 170505 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: [RX]ConstellationAfterFineFrequencyCompen.png
Type: image/png
Size: 117135 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: [RX]ConstellationAfterRCFilter.png
Type: image/png
Size: 107783 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: [RX]ConstellationAfterTimingRecovery.png
Type: image/png
Size: 93056 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: [RX]SpectrumAfterAGC.png
Type: image/png
Size: 157578 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: [RX]SpectrumAfterRCFilter.png
Type: image/png
Size: 157643 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: [TX]ConfigurationOftheTransmitter.jpg
Type: image/jpeg
Size: 112089 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ConstellationAfterCoareFrequencyCompen.png
Type: image/png
Size: 154854 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QPSKReciverDigram.png
Type: image/png
Size: 87189 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160712/10e4b2ac/attachment-0017.png>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 71, Issue 10
******************************************
