Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Rx/Tx Loopback (Ian Buckley)
2. Conformation Of Maximum Ratings N200, LFRX And Full Scale
Deflection ADC (Michael Scott)
3. Re: Cloning E310 Firmware (Moritz Fischer)
4. Re: Conformation Of Maximum Ratings N200, LFRX And Full Scale
Deflection ADC ([email protected])
5. Re: Conformation Of Maximum Ratings N200, LFRX And Full Scale
Deflection ADC (Michael Scott)
6. Re: Conformation Of Maximum Ratings N200, LFRX And Full Scale
Deflection ADC ([email protected])
7. Re: Conformation Of Maximum Ratings N200, LFRX And Full Scale
Deflection ADC (Matt Ettus)
8. Re: Conformation Of Maximum Ratings N200, LFRX And Full Scale
Deflection ADC (Michael Scott)
9. Re: Rx/Tx Loopback (Rob Kossler)
10. Re: DVB-x (was: Again performance issues B210, while BladeRF
performs fine) (Ralph A. Schmid, dk5ras)
11. Re: Tx2Rx-Sine (Marcus M?ller)
12. E310 demo image (Long, Jeffrey P.)
13. Re: problem with MISO signal receiving (Martin Braun)
14. Re: ??? Could this be Ettus X310 self jamming problem?
(Martin Braun)
15. Re: E310 demo image (Philip Balister)
16. Re: ??? Could this be Ettus X310 self jamming problem?
(Ian Buckley)
17. Re: Could this be Ettus X310 self jamming problem?
(=?gb18030?B?VHJlaw==?=)
18. RuntimeError: LookupError: KeyError: No devices found for
----->, Empty Device Address (numeric)
19. Re: RuntimeError: LookupError: KeyError: No devices found for
----->, Empty Device Address (Richard Bell)
20. Re: RuntimeError: LookupError: KeyError: No devices found for
----->, Empty Device Address (Richard Bell)
21. Re: Could this be Ettus X310 self jamming problem? (Ian Buckley)
22. Re: Could this be Ettus X310 self jamming problem?
(=?gb18030?B?VHJlaw==?=)
23. Re: Could this be Ettus X310 self jamming problem? (Marcus M?ller)
24. Re: RuntimeError: LookupError: KeyError: No devices found for
----->, Empty Device Address (Marcus D. Leech)
25. Re: Question: new (green) USRP B210 and Takachi enclosure
(Patrick Sathyanathan)
26. Re: Cloning E310 Firmware (Amber and Sarosh)
27. Re: Question: new (green) USRP B210 and Takachi enclosure
(Piotr Krysik)
----------------------------------------------------------------------
Message: 1
Date: Thu, 2 Apr 2015 09:31:48 -0700
From: Ian Buckley <[email protected]>
To: [email protected]
Cc: [email protected], Rob Kossler <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
So this is an interesting one, and a little unexpected for me, but I think I
know whats happening.
First off I reproduced this exactly as Rob described using B210, so it's
symptomatic of UHD in general rather than X310 specific.
When data is RX'ed on a USRP every UHD packet contains vita time metadata in
the header that identifies the timestamp with which the first sample in the
packet was received.
Now note that the TX returns "L" as the error, not "U"?so it's not underflowing
whilst TX streaming, its rejecting TX UHD packets as having a timestamp thats
in the past w.r.t the current vita time.
(Note TX and RX within a USRP channel are sharing the same H/W vita time
counter.)
I believe that this flow graph causes the RX time stamps to be placed into the
TX data stream as timestamps that are targets for transmission, and of course
by definition they will always be in the past when they arrive at the TX DSP.
Someone who is better at GR than me will probably know what block to pass this
through to strip the metadata. So saying that I think that this style of
simplistic flow graph is still doomed to not run reliably because being fed
from a sample source thats forced to run in lockstep with the sample sink means
that an adequate buffer of samples will never accumulate in the TX buffering of
the USRP to absorb the inevitable jitter in data delivery from the host.
Perhaps the way to do this is to add a constant time offset to all the RX
timestamps that will force some buffering in H/W(If Robs goal is minimal
latency this might be less than useful for him?)
-Ian
On Apr 2, 2015, at 7:51 AM, Marcus D. Leech via USRP-users
<[email protected]> wrote:
> Well, I wonder if our gr-uhd maintainer has a comment.
>
> This seems very odd to me, and perhaps there's a subtlety in the way gr-uhd
> tries to be helpful and setup a bunch of stuff involving sample timing
> automatically.
>
>
>
>
> On 2015-04-02 10:28, Rob Kossler wrote:
>
>> On Wed, Apr 1, 2015 at 11:45 PM, Marcus D. Leech <[email protected]> wrote:
>> On 04/01/2015 11:41 PM, Rob Kossler wrote:
>>>
>>>
>>>
>>> Yes, those are the sync options. Since there is only one device, I only
>>> selected "unknown PPS" for one of the two streamers. Is that correct?
>>> Rob
>> That would be correct for a device that had 1PPS. I don't recall whether
>> X3xx has a "fake" internal 1PPS signal or not. Since this is a single device
>> at this point, just choose "don't sync" for both of them.
>>
>>
>> I tried "don't sync" for both as well as putting constant multiply blocks in
>> between the source / sink. Neither seems to fix my "Late" issue. However,
>> if I exit GRC and simply run benchmark_rate in full duplex, it has no issues
>> even at higher sample rates.
>>
>> Attached are 3 files: the modified GRC flowgraph as well as two text files
>> showing the results obtained when running this flowgraph from GRC as
>> compared to running benchmark_rate. The flowgraph sample rate is 1 MS/s
>> while the benchmark_rate is running at 10 MS/s (BTW, it also runs fine at
>> 1MS/s).
>>
>> Rob
>>
>>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/c3d1471a/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 2 Apr 2015 14:23:07 -0230
From: "Michael Scott" <[email protected]>
To: "Neel Pandeya" <[email protected]>
Cc: Ettus Mailing List <[email protected]>
Subject: [USRP-users] Conformation Of Maximum Ratings N200, LFRX And
Full Scale Deflection ADC
Message-ID: <4387BF6D1F024F0E847DF92EE0A16293@Bagginsis>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
We are looking at the some of the absolute maximums for the Ettus N200. I have
done some reading and the maximum power for the LFRX is 10 dBm this is 2 V P-P.
I believe it can handle 3.3 V P-P. But they use this spec because the most the
ADC can handle without damage 2 V P-P. We are using the LFRX D'Card this has no
gain on the frontend. Can you confirm this is true?
The other main question that I have is that we are trying to figure out how
much power we can put into are transmitter. So we are wondering what voltage on
the ADC gives all bits set to a digital ' 1'? In other words what gives full
scale deflection of the ADC.
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/6b745507/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 2 Apr 2015 09:56:26 -0700
From: Moritz Fischer <[email protected]>
To: Amber and Sarosh <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cloning E310 Firmware
Message-ID:
<CAAtXAHeL8Gymo=j1+-RDs4v=xgvpqs9e6d8+omnm4h-xotx...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Amber, Sarosh & Naheed,
please take a look at our manual [1] section on that subject. I don't
understand what you mean by 'on an other device'. Another E310?
Moritz
[1] http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_image_building
On Thu, Apr 2, 2015 at 12:17 AM, Amber and Sarosh via USRP-users
<[email protected]> wrote:
> Hi
> Can anyone please help us making an image of the E310 firmware with our
> custom installations such that it can be burned as it is on an other device?
>
> Regards,
> Amber, Sarosh & Naheed
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Thu, 02 Apr 2015 13:02:55 -0400
From: [email protected]
To: Michael Scott <[email protected]>
Cc: Ettus Mailing List <[email protected]>
Subject: Re: [USRP-users] Conformation Of Maximum Ratings N200, LFRX
And Full Scale Deflection ADC
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I think both the ADC and DAC use a roughly 1.2V reference, so that's
roughly where the peak voltage would be.
On 2015-04-02 12:53, Michael Scott via USRP-users wrote:
> Hi All,
>
> We are looking at the some of the absolute maximums for the Ettus N200. I
> have done some reading and the maximum power for the LFRX is 10 dBm this is 2
> V P-P. I believe it can handle 3.3 V P-P. But they use this spec because the
> most the ADC can handle without damage 2 V P-P. We are using the LFRX D'Card
> this has no gain on the frontend. Can you confirm this is true?
>
> The other main question that I have is that we are trying to figure out how
> much power we can put into are transmitter. So we are wondering what voltage
> on the ADC gives all bits set to a digital ' 1'? In other words what gives
> full scale deflection of the ADC.
>
> Mike
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20150402/07654676/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 2 Apr 2015 14:35:16 -0230
From: "Michael Scott" <[email protected]>
To: <[email protected]>
Cc: Ettus Mailing List <[email protected]>
Subject: Re: [USRP-users] Conformation Of Maximum Ratings N200, LFRX
And Full Scale Deflection ADC
Message-ID: <B0E7231D458D461A92CCC758EC1B270D@Bagginsis>
Content-Type: text/plain; charset="utf-8"
So just to clarify it would be 2.4 V P-P or 1.2 V P.
Thank You,
Mike
From: [email protected]
Sent: Thursday, April 02, 2015 2:32 PM
To: Michael Scott
Cc: Neel Pandeya ; Ettus Mailing List
Subject: Re: [USRP-users] Conformation Of Maximum Ratings N200, LFRX And Full
Scale Deflection ADC
I think both the ADC and DAC use a roughly 1.2V reference, so that's roughly
where the peak voltage would be.
On 2015-04-02 12:53, Michael Scott via USRP-users wrote:
Hi All,
We are looking at the some of the absolute maximums for the Ettus N200. I
have done some reading and the maximum power for the LFRX is 10 dBm this is 2 V
P-P. I believe it can handle 3.3 V P-P. But they use this spec because the most
the ADC can handle without damage 2 V P-P. We are using the LFRX D'Card this
has no gain on the frontend. Can you confirm this is true?
The other main question that I have is that we are trying to figure out how
much power we can put into are transmitter. So we are wondering what voltage on
the ADC gives all bits set to a digital ' 1'? In other words what gives full
scale deflection of the ADC.
Mike
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/11121c96/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 02 Apr 2015 13:08:36 -0400
From: [email protected]
To: Michael Scott <[email protected]>
Cc: Ettus Mailing List <[email protected]>
Subject: Re: [USRP-users] Conformation Of Maximum Ratings N200, LFRX
And Full Scale Deflection ADC
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
1.2V P, or 2.4V P-P, as far as I know.
That's about 11dBm, and I normally think of these as putting out "about
10Bm max" with about 3dB back-off to keep from clipping.
There'll be some variability.
I'd take measurements, if you have your N2xx already with LFRX/LFTX.
On 2015-04-02 13:05, Michael Scott wrote:
> So just to clarify it would be 2.4 V P-P or 1.2 V P.
>
> Thank You,
>
> Mike
>
> FROM: [email protected]
> SENT: Thursday, April 02, 2015 2:32 PM
> TO: Michael Scott
> CC: Neel Pandeya ; Ettus Mailing List
> SUBJECT: Re: [USRP-users] Conformation Of Maximum Ratings N200, LFRX And Full
> Scale Deflection ADC
>
> I think both the ADC and DAC use a roughly 1.2V reference, so that's roughly
> where the peak voltage would be.
>
> On 2015-04-02 12:53, Michael Scott via USRP-users wrote:
>
>> Hi All,
>>
>> We are looking at the some of the absolute maximums for the Ettus N200. I
>> have done some reading and the maximum power for the LFRX is 10 dBm this is
>> 2 V P-P. I believe it can handle 3.3 V P-P. But they use this spec because
>> the most the ADC can handle without damage 2 V P-P. We are using the LFRX
>> D'Card this has no gain on the frontend. Can you confirm this is true?
>>
>> The other main question that I have is that we are trying to figure out how
>> much power we can put into are transmitter. So we are wondering what voltage
>> on the ADC gives all bits set to a digital ' 1'? In other words what gives
>> full scale deflection of the ADC.
>>
>> Mike
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20150402/c34d12c5/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 2 Apr 2015 10:09:12 -0700
From: Matt Ettus <[email protected]>
To: Michael Scott <[email protected]>
Cc: Ettus Mailing List <[email protected]>
Subject: Re: [USRP-users] Conformation Of Maximum Ratings N200, LFRX
And Full Scale Deflection ADC
Message-ID:
<CAN=1kn_oknupOc=VGESyshWefpa81rp43Ciouy5A7pW4Lu=a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Full scale on the LFRX is +10dBm if the ADC gain is turned down. You can
turn up the ADC gain, which would reduce the full scale accordingly. You
won't do damage until about +20dBm, but to be safe you should stay below
+15dBm.
Matt
On Thu, Apr 2, 2015 at 9:53 AM, Michael Scott via USRP-users <
[email protected]> wrote:
> Hi All,
>
>
>
> We are looking at the some of the absolute maximums for the Ettus N200. I
> have done some reading and the maximum power for the LFRX is 10 dBm this is
> 2 V P-P. I believe it can handle 3.3 V P-P. But they use this spec because
> the most the ADC can handle without damage 2 V P-P. We are using the LFRX
> D'Card this has no gain on the frontend. Can you confirm this is true?
>
>
>
> The other main question that I have is that we are trying to figure out
> how much power we can put into are transmitter. So we are wondering what
> voltage on the ADC gives all bits set to a digital ' 1'? In other words
> what gives full scale deflection of the ADC.
>
>
>
> Mike
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/49ce08ac/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 2 Apr 2015 14:50:32 -0230
From: "Michael Scott" <[email protected]>
To: "Matt Ettus" <[email protected]>
Cc: Ettus Mailing List <[email protected]>
Subject: Re: [USRP-users] Conformation Of Maximum Ratings N200, LFRX
And Full Scale Deflection ADC
Message-ID: <854FBE690F004015B918730A8C8DCD23@Bagginsis>
Content-Type: text/plain; charset="utf-8"
Thank You All. It?s not just coming LFTX were trying to figure out about
forward power from our PA we are going to need to achieve the strongest signal
and maximum SNR.
Mike
From: Matt Ettus
Sent: Thursday, April 02, 2015 2:39 PM
To: Michael Scott
Cc: Neel Pandeya ; Ettus Mailing List
Subject: Re: [USRP-users] Conformation Of Maximum Ratings N200, LFRX And Full
Scale Deflection ADC
Full scale on the LFRX is +10dBm if the ADC gain is turned down. You can turn
up the ADC gain, which would reduce the full scale accordingly. You won't do
damage until about +20dBm, but to be safe you should stay below +15dBm.
Matt
On Thu, Apr 2, 2015 at 9:53 AM, Michael Scott via USRP-users
<[email protected]> wrote:
Hi All,
We are looking at the some of the absolute maximums for the Ettus N200. I
have done some reading and the maximum power for the LFRX is 10 dBm this is 2 V
P-P. I believe it can handle 3.3 V P-P. But they use this spec because the most
the ADC can handle without damage 2 V P-P. We are using the LFRX D'Card this
has no gain on the frontend. Can you confirm this is true?
The other main question that I have is that we are trying to figure out how
much power we can put into are transmitter. So we are wondering what voltage on
the ADC gives all bits set to a digital ' 1'? In other words what gives full
scale deflection of the ADC.
Mike
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/b9e4ce31/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 2 Apr 2015 13:37:48 -0400
From: Rob Kossler <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID:
<cab__htq9rp3qzm4s8etzecdovrsa-ojp8pn2is-rdvm7yfg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm not much concerned with latency. My original goal with this flowgraph
was to demonstrate RF channel modeling using multiple signal fading blocks
in between the UHD source and sink. So, essentially there is some DSP to
be applied to the data prior to retransmission. I figured that as long as
the CPU DSP processing was fast enough at the given data rate, it would be
able to supply samples to the sink as fast as needed. When this didn't
work as expected, I simplified things to remove the fading blocks and just
have the source and sink (which is the GRC file I previously attached).
So, I think I can tolerate latency just fine. Perhaps I need to add a time
constant to the metadata as Ian suggested and/or implement some type of
buffering block in GRC to avoid Underruns. Let me know if anyone has ideas
on this. My initial goal is to get this simple flowgraph working before
reverting back to adding fading blocks or other processing.
Rob
On Thu, Apr 2, 2015 at 12:31 PM, Ian Buckley <[email protected]> wrote:
> So this is an interesting one, and a little unexpected for me, but I think
> I know whats happening.
> First off I reproduced this exactly as Rob described using B210, so it's
> symptomatic of UHD in general rather than X310 specific.
> When data is RX'ed on a USRP every UHD packet contains vita time metadata
> in the header that identifies the timestamp with which the first sample in
> the packet was received.
> Now note that the TX returns "L" as the error, not "U"?so it's not
> underflowing whilst TX streaming, its rejecting TX UHD packets as having a
> timestamp thats in the past w.r.t the current vita time.
> (Note TX and RX within a USRP channel are sharing the same H/W vita time
> counter.)
>
> I believe that this flow graph causes the RX time stamps to be placed into
> the TX data stream as timestamps that are targets for transmission, and of
> course by definition they will always be in the past when they arrive at
> the TX DSP.
>
> Someone who is better at GR than me will probably know what block to pass
> this through to strip the metadata. So saying that I think that this style
> of simplistic flow graph is still doomed to not run reliably because being
> fed from a sample source thats forced to run in lockstep with the sample
> sink means that an adequate buffer of samples will never accumulate in the
> TX buffering of the USRP to absorb the inevitable jitter in data delivery
> from the host. Perhaps the way to do this is to add a constant time offset
> to all the RX timestamps that will force some buffering in H/W(If Robs goal
> is minimal latency this might be less than useful for him?)
>
> -Ian
>
> On Apr 2, 2015, at 7:51 AM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
> Well, I wonder if our gr-uhd maintainer has a comment.
>
> This seems very odd to me, and perhaps there's a subtlety in the way
> gr-uhd tries to be helpful and setup a bunch of stuff involving sample
> timing automatically.
>
>
>
>
> On 2015-04-02 10:28, Rob Kossler wrote:
>
> On Wed, Apr 1, 2015 at 11:45 PM, Marcus D. Leech <[email protected]>
> wrote:
>
>> On 04/01/2015 11:41 PM, Rob Kossler wrote:
>>
>>
>>
>>>
>>> Yes, those are the sync options. Since there is only one device, I
>> only selected "unknown PPS" for one of the two streamers. Is that correct?
>> Rob
>>
>> That would be correct for a device that had 1PPS. I don't recall whether
>> X3xx has a "fake" internal 1PPS signal or not. Since this is a single
>> device
>> at this point, just choose "don't sync" for both of them.
>>
>>
>> I tried "don't sync" for both as well as putting constant multiply
> blocks in between the source / sink. Neither seems to fix my "Late"
> issue. However, if I exit GRC and simply run benchmark_rate in full
> duplex, it has no issues even at higher sample rates.
>
> Attached are 3 files: the modified GRC flowgraph as well as two text files
> showing the results obtained when running this flowgraph from GRC as
> compared to running benchmark_rate. The flowgraph sample rate is 1 MS/s
> while the benchmark_rate is running at 10 MS/s (BTW, it also runs fine at
> 1MS/s).
>
> Rob
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/ee001fe9/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 2 Apr 2015 21:29:41 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Ron Economos'" <[email protected]>, <[email protected]>
Subject: Re: [USRP-users] DVB-x (was: Again performance issues B210,
while BladeRF performs fine)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
You're a champ! Video is 1a, in 8 MHz 7/8 QAM64 on 474 MHz, just no audio,
but this was a quick and dirty test while I am doing some other stuff...
Great!
Ralph.
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
Ron Economos via USRP-users
Sent: Thursday, April 2, 2015 10:17
To: 'usrp-users'
Subject: Re: [USRP-users] DVB-x (was: Again performance issues B210, while
BladeRF performs fine)
Sorry for the late reply. Comcast blocks certain addresses on re-mailers,
and I missed your e-mail.
I have a bunch of DVB-T test streams on my website. They are listed in this
post on the Nuand forum.
http://nuand.com/forums/viewtopic.php?f=8&t=3499#p5124
Ron
Hi,
I adjusted the subject...
The issue with DVB-T were the 10 threads in FFT settings; reducing this to
one thread gives a stable and spectrum-wise OK looking signal, around 40dB
above noise when transmitted over a distance of one or two meters. So I took
my old laptop, went through the hassle installing a completely new Windows 7
and the DVB-T receiver stuff (DVBViewer and a RTL2832 based RX), and I was
able to find "something" on the chosen channel, with 55% signal strength, a
garbled channel name showed up, but no picture. At least somehow it looks
like a DVB-T signal, when I find some time I will try tweaking the settings
if I can get real reception. Oh, the receiver is OK, I can watch normal TV
with it, using just 15cm of wire as antenna. Next week I should have access
to a DVB-x antenna tester, maybe this beast can tell me more about the
signal.
What example with the supplied test.ts is recommended for being received
with a normal receiver?
Ralph.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 11
Date: Thu, 02 Apr 2015 21:35:48 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Tx2Rx-Sine
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Siva,
would you have a little surrounding source code?
for example, what is the exact type of "data"? Is it something like
std::vector<std::complex<float>>, or just std::complex<float>[], or is
it actually the first element in such a vector/array?
How does the loop with which you stream the stringified complexes to
output_file1 look like?
Is there a particular reason you take this detour? Assuming your .dat is
coming from something like UHD's rx_samples_to_file, octaves fread
functionality should directly be able to read these files into arrays of
real numbers, and you can then just slice them and use them as real and
imaginary part. GNU Radio has octave tools for that [1].
Also: is this data from the very beginning of a reception? There might
be residual values in the integrated DSP chain. Which version of UHD are
you using, and which USRP?
Greetings,
Marcus
[1] https://github.com/gnuradio/gnuradio/tree/master/gr-utils/octave ;
use read_complex_binary.m for complexes consisting of float32,
read_cshort_binary.m for complexes of shorts (int16).
On 03/31/2015 02:29 PM, siva sankar via USRP-users wrote:
> Hello all,
> We are trying to transmit a sine wave and receive at both the
> receivers simultaneously which is then written into a .dat file. We
> then plotted the imaginary part, which matches the transmitted sine
> wave and the real part doesn't look like a sine wave.
> This is how we are writing the imag/real part to a .txt file, reading
> it from .dat file and then plotting the same using octave.
>
> input_file1.read((char*)&data, sizeof(data));
> output_file1<<data.real()<<"\n";
> or
> input_file1.read((char*)&data, sizeof(data));
> output_file1<<data.imag()<<"\n";
>
> Below I am attaching the pictures of the output of the real and
> imaginary part. I am also attaching the .dat file generated after
> executing the program.
>
> Can someone please explain this behavior?
>
> Thanks
> Siva
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/16a28c5e/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 2 Apr 2015 20:12:56 +0000
From: "Long, Jeffrey P." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 demo image
Message-ID: <d1431b06.5a81%[email protected]>
Content-Type: text/plain; charset="us-ascii"
Philip-
I built a SD card using the demo image you posted awhile back. Just wondering
what kind of goodies are on there? I also connected it to a MIMO USB touch
screen which works great as a display but touch does not work. Should that work
or is the driver for that not installed?
Thanks
Jeff Long
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/d8a401a2/attachment-0001.html>
------------------------------
Message: 13
Date: Thu, 02 Apr 2015 13:40:50 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] problem with MISO signal receiving
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Which daughterboards are you using?
Also, which signals are you transmitting? Is it some kind of orthogonal
code (zadoff-chu or something like that?). Or are you relying on some
fixed phase relation?
M
On 02.04.2015 02:12, scott tiger via USRP-users wrote:
> Hello all,
> I am trying to send two orthogonal sequences from different antennas and
> receive them in one (2 by 1) . I am using two USRP for transmitting
> purpose synchronized using MIMO cable (with two antennas) and receive
> one signal but when I check it it seems that all the orthogonality
> disappears. While when I use SISO transmission I can receive a good
> signal. Can you please help me in this problem? Can be this problem
> caused because of unsynchronized receiver with the transmission part ?
------------------------------
Message: 14
Date: Thu, 02 Apr 2015 13:42:26 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] ??? Could this be Ettus X310 self jamming
problem?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 02.04.2015 07:16, Trek via USRP-users wrote:
> I already did it at 1.602GHz instead of 1.6GHz, same thing except now
> the large spike is -2MHz from 0.
This could be a clock harmonic. At 1650 MHz, do you still see something?
M
------------------------------
Message: 15
Date: Thu, 02 Apr 2015 13:49:34 -0700
From: Philip Balister <[email protected]>
To: "Long, Jeffrey P." <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 demo image
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/02/2015 01:12 PM, Long, Jeffrey P. via USRP-users wrote:
> Philip-
>
> I built a SD card using the demo image you posted awhile back. Just wondering
> what kind of goodies are on there? I also connected it to a MIMO USB touch
> screen which works great as a display but touch does not work. Should that
> work or is the driver for that not installed?
>
The image definition is:
https://github.com/balister/meta-sdr/blob/master/recipes-images/images/gnuradio-demo-image.bb
gnuradio-dev-image is the standard image that ships with the unit.
Basically, the x server is added and some stuff for using a usb wifi
dongle, web stuff, and some extra gnuradio OOT's. Ignore the pyqt line,
that will get pulled in from gnuradio-dev-image these days.
The touchscreen should work. That said, mine was having issues last week
at ELC. I wonder if I broke something. It isn't obvious what I would
have broken. What is the problem you see when you try to run the calibrator.
Philip
> Thanks
> Jeff Long
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 16
Date: Thu, 2 Apr 2015 13:59:59 -0700
From: Ian Buckley <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] ??? Could this be Ettus X310 self jamming
problem?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Try repeating your test with a master_clock_rate of 120MHz rather than 200MHz.
This should change the frequencies of harmonics related to the default radio
clock.
-Ian
On Apr 2, 2015, at 1:42 PM, Martin Braun via USRP-users
<[email protected]> wrote:
> On 02.04.2015 07:16, Trek via USRP-users wrote:
>> I already did it at 1.602GHz instead of 1.6GHz, same thing except now
>> the large spike is -2MHz from 0.
>
> This could be a clock harmonic. At 1650 MHz, do you still see something?
>
> M
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 17
Date: Fri, 3 Apr 2015 05:13:40 +0800
From: "=?gb18030?B?VHJlaw==?=" <[email protected]>
To: "=?gb18030?B?TWFyY3VzIE2ouWxsZXIgdmlhIFVTUlAtdXNlcnM=?="
<[email protected]>,
"=?gb18030?B?TWFyY3VzIE2ouWxsZXIgdmlhIFVTUlAtdXNlcnM=?="
<[email protected]>
Cc: Marcus M?ller via USRP-users <[email protected]>
Subject: Re: [USRP-users] Could this be Ettus X310 self jamming
problem?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gb18030"
In terms of GRC, how could I adjust master_clock_rate to 120MHz? Is there a
setting in the USRP source properties?
thanks,
------------------ Original ------------------
From: "Marcus M?ller via USRP-users";<[email protected]>;
Date: Apr 3, 2015
To: "Martin Braun"<[email protected]>;
Cc: "usrp-users"<[email protected]>;
Subject: Re: [USRP-users]??? Could this be Ettus X310 self jamming problem?
Try repeating your test with a master_clock_rate of 120MHz rather than 200MHz.
This should change the frequencies of harmonics related to the default radio
clock.
-Ian
On Apr 2, 2015, at 1:42 PM, Martin Braun via USRP-users
<[email protected]> wrote:
> On 02.04.2015 07:16, Trek via USRP-users wrote:
>> I already did it at 1.602GHz instead of 1.6GHz, same thing except now
>> the large spike is -2MHz from 0.
>
> This could be a clock harmonic. At 1650 MHz, do you still see something?
>
> M
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150403/16523a93/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 02 Apr 2015 17:16:20 -0500
From: numeric <[email protected]>
To: [email protected]
Subject: [USRP-users] RuntimeError: LookupError: KeyError: No devices
found for ----->, Empty Device Address
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi,
I installed gnuradio GRC 3.7.6.1 from source. Used the
"|build-gnuradio"| <http://www.sbrac.org/files/build-gnuradio> script to
build gnuradio. Many prerequisites were missing, starting with "git". I
am still not sure if all the prerequisites have been installed. I found
QT missing and installed the latest version from
https://www.qt.io/download-open-source/. It seems like it solved the
QT5.Qt4 as QT (something like that). Finally a successful build; or so
I thought. Now I get the error "RuntimeError: LookupError: KeyError: No
devices found for ----->,Empty Device Address".
I am using:
1. the b200 usrp pcb
2. Ubuntu 14.04.2 LTE 64 bit
3. GRC 3.7.6.1
4. Dell Inspiron 13 7000 series with the Intel 5th generation i7 CPU.
5. BIOS set for secure boot and UEFI
6. An external drive for Linux OS
6.1 64 GB SanDisk Extreme USB 3.0 Flash Drive 245 MB/s Read 190
MB/s write.
Help is greatly appreciated
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/5cd6467b/attachment-0001.html>
------------------------------
Message: 19
Date: Thu, 2 Apr 2015 14:19:27 -0700
From: Richard Bell <[email protected]>
To: numeric <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RuntimeError: LookupError: KeyError: No
devices found for ----->, Empty Device Address
Message-ID:
<CAMMoi3tZpW+RKazk6R=2nuemjm3xryip8-grxjj_zgnppj-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I don't know anything about the build-gnuradio script. Some recent threads
mentioned it was broken on Ubuntu. I'm not sure what OS you're using.
I always use pybombs to install gnuradio and uhd. It's very easy and only a
few steps of code. Details in the link.
http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
v/r,
Rich
On Thu, Apr 2, 2015 at 3:16 PM, numeric via USRP-users <
[email protected]> wrote:
> Hi,
>
> I installed gnuradio GRC 3.7.6.1 from source. Used the "build-gnuradio"
> <http://www.sbrac.org/files/build-gnuradio> script to build gnuradio.
> Many prerequisites were missing, starting with "git". I am still not sure
> if all the prerequisites have been installed. I found QT missing and
> installed the latest version from https://www.qt.io/download-open-source/.
> It seems like it solved the QT5.Qt4 as QT (something like that). Finally a
> successful build; or so I thought. Now I get the error "RuntimeError:
> LookupError: KeyError: No devices found for ----->,Empty Device Address".
>
> I am using:
> 1. the b200 usrp pcb
> 2. Ubuntu 14.04.2 LTE 64 bit
> 3. GRC 3.7.6.1
> 4. Dell Inspiron 13 7000 series with the Intel 5th generation i7 CPU.
> 5. BIOS set for secure boot and UEFI
> 6. An external drive for Linux OS
> 6.1 64 GB SanDisk Extreme USB 3.0 Flash Drive 245 MB/s Read 190 MB/s
> write.
>
> Help is greatly appreciated
> Rob
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/e057ad3b/attachment-0001.html>
------------------------------
Message: 20
Date: Thu, 2 Apr 2015 14:20:44 -0700
From: Richard Bell <[email protected]>
To: numeric <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RuntimeError: LookupError: KeyError: No
devices found for ----->, Empty Device Address
Message-ID:
<CAMMoi3sYjkToBP3_L=pekp6e3c_2xxsrztvp7pa_dvk+874...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Oh, since you've partially installed gnuradio now, make sure you completely
remove the partial install and the qt you installed manually. Then use
pybombs.
v/r,
Rich
On Thu, Apr 2, 2015 at 2:19 PM, Richard Bell <[email protected]>
wrote:
> I don't know anything about the build-gnuradio script. Some recent threads
> mentioned it was broken on Ubuntu. I'm not sure what OS you're using.
>
> I always use pybombs to install gnuradio and uhd. It's very easy and only
> a few steps of code. Details in the link.
>
> http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
>
> v/r,
> Rich
>
> On Thu, Apr 2, 2015 at 3:16 PM, numeric via USRP-users <
> [email protected]> wrote:
>
>> Hi,
>>
>> I installed gnuradio GRC 3.7.6.1 from source. Used the "build-gnuradio"
>> <http://www.sbrac.org/files/build-gnuradio> script to build gnuradio.
>> Many prerequisites were missing, starting with "git". I am still not sure
>> if all the prerequisites have been installed. I found QT missing and
>> installed the latest version from https://www.qt.io/download-open-source/.
>> It seems like it solved the QT5.Qt4 as QT (something like that). Finally a
>> successful build; or so I thought. Now I get the error "RuntimeError:
>> LookupError: KeyError: No devices found for ----->,Empty Device Address".
>>
>> I am using:
>> 1. the b200 usrp pcb
>> 2. Ubuntu 14.04.2 LTE 64 bit
>> 3. GRC 3.7.6.1
>> 4. Dell Inspiron 13 7000 series with the Intel 5th generation i7 CPU.
>> 5. BIOS set for secure boot and UEFI
>> 6. An external drive for Linux OS
>> 6.1 64 GB SanDisk Extreme USB 3.0 Flash Drive 245 MB/s Read 190 MB/s
>> write.
>>
>> Help is greatly appreciated
>> Rob
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/7222e7e9/attachment-0001.html>
------------------------------
Message: 21
Date: Thu, 2 Apr 2015 14:22:52 -0700
From: Ian Buckley <[email protected]>
To: Trek <[email protected]>
Cc: "Marcus M?ller via USRP-users" <[email protected]>
Subject: Re: [USRP-users] Could this be Ettus X310 self jamming
problem?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gb18030"
Try adding "master_clock_rate=120e6" (including quotes) to the Device
Arguments field in the UHD Sink.
-Ian
On Apr 2, 2015, at 2:13 PM, Trek <[email protected]> wrote:
> In terms of GRC, how could I adjust master_clock_rate to 120MHz? Is there a
> setting in the USRP source properties?
> thanks,
>
>
> ------------------ Original ------------------
> From: "Marcus M?ller via USRP-users";<[email protected]>;
> Date: Apr 3, 2015
> To: "Martin Braun"<[email protected]>;
> Cc: "usrp-users"<[email protected]>;
> Subject: Re: [USRP-users]??? Could this be Ettus X310 self jamming problem?
>
> Try repeating your test with a master_clock_rate of 120MHz rather than
> 200MHz. This should change the frequencies of harmonics related to the
> default radio clock.
> -Ian
>
> On Apr 2, 2015, at 1:42 PM, Martin Braun via USRP-users
> <[email protected]> wrote:
>
> > On 02.04.2015 07:16, Trek via USRP-users wrote:
> >> I already did it at 1.602GHz instead of 1.6GHz, same thing except now
> >> the large spike is -2MHz from 0.
> >
> > This could be a clock harmonic. At 1650 MHz, do you still see something?
> >
> > M
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/bd581211/attachment-0001.html>
------------------------------
Message: 22
Date: Fri, 3 Apr 2015 05:44:11 +0800
From: "=?gb18030?B?VHJlaw==?=" <[email protected]>
To: "=?gb18030?B?TWFyY3VzIE2ouWxsZXIgdmlhIFVTUlAtdXNlcnM=?="
<[email protected]>
Cc: Marcus M?ller via USRP-users <[email protected]>
Subject: Re: [USRP-users] Could this be Ettus X310 self jamming
problem?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gb18030"
cool, setting this to 120MHz indeed solved my problem at 1600MHz, however it
created another clock harmonic at 1560MHz (1560=120*13), which is also my point
of interest on the spectrum, is there another odd clock frequency you guys
could recommend for me to work with?
thanks,
------------------ Original ------------------
From: "Marcus M?ller via USRP-users";<[email protected]>;
Date: Apr 3, 2015
To: "Trek"<[email protected]>;
Cc: ""Marcus M?ller via USRP-users"<[email protected]>; ""Marcus M?ller
via USRP-users"<[email protected]>;
Subject: Re: Could this be Ettus X310 self jamming problem?
Try adding "master_clock_rate=120e6" (including quotes) to the Device
Arguments field in the UHD Sink.-Ian
On Apr 2, 2015, at 2:13 PM, Trek <[email protected]> wrote:
In terms of GRC, how could I adjust master_clock_rate to 120MHz? Is there a
setting in the USRP source properties?
thanks,
------------------ Original ------------------
From: "Marcus M?ller via USRP-users";<[email protected]>;
Date: Apr 3, 2015
To: "Martin Braun"<[email protected]>;
Cc: "usrp-users"<[email protected]>;
Subject: Re: [USRP-users]??? Could this be Ettus X310 self jamming problem?
Try repeating your test with a master_clock_rate of 120MHz rather than 200MHz.
This should change the frequencies of harmonics related to the default radio
clock.
-Ian
On Apr 2, 2015, at 1:42 PM, Martin Braun via USRP-users
<[email protected]> wrote:
> On 02.04.2015 07:16, Trek via USRP-users wrote:
>> I already did it at 1.602GHz instead of 1.6GHz, same thing except now
>> the large spike is -2MHz from 0.
>
> This could be a clock harmonic. At 1650 MHz, do you still see something?
>
> M
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150403/4bb6cae4/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 02 Apr 2015 23:51:07 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Could this be Ettus X310 self jamming
problem?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
If that solves your problem: 184.32MHz is the third legal master clock rate.
On 04/02/2015 11:44 PM, Trek via USRP-users wrote:
> cool, setting this to 120MHz indeed solved my problem at 1600MHz,
> however it created another clock harmonic at 1560MHz (1560=120*13),
> which is also my point of interest on the spectrum, is there another
> odd clock frequency you guys could recommend for me to work with?
>
> thanks,
>
>
> ------------------ Original ------------------
> *From: * "Marcus M?ller via USRP-users";<[email protected]>;
> *Date: * Apr 3, 2015
> *To: * "Trek"<[email protected]>;
> *Cc: * ""Marcus M?ller via USRP-users"<[email protected]>;
> ""Marcus M?ller via USRP-users"<[email protected]>;
> *Subject: * Re: Could this be Ettus X310 self jamming problem?
>
> Try adding "master_clock_rate=120e6" (including quotes) to the
> Device Arguments field in the UHD Sink.
> -Ian
> On Apr 2, 2015, at 2:13 PM, Trek <[email protected]
> <mailto:[email protected]>> wrote:
>
>> In terms of GRC, how could I adjust master_clock_rate to 120MHz? Is
>> there a setting in the USRP source properties?
>> thanks,
>>
>>
>> ------------------ Original ------------------
>> *From: * "Marcus M?ller via USRP-users";<[email protected]
>> <mailto:[email protected]>>;
>> *Date: * Apr 3, 2015
>> *To: * "Martin Braun"<[email protected]
>> <mailto:[email protected]>>;
>> *Cc: * "usrp-users"<[email protected]
>> <mailto:[email protected]>>;
>> *Subject: * Re: [USRP-users]??? Could this be Ettus X310 self
>> jamming problem?
>>
>> Try repeating your test with a master_clock_rate of 120MHz rather
>> than 200MHz. This should change the frequencies of harmonics related
>> to the default radio clock.
>> -Ian
>>
>> On Apr 2, 2015, at 1:42 PM, Martin Braun via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> > On 02.04.2015 07:16, Trek via USRP-users wrote:
>> >> I already did it at 1.602GHz instead of 1.6GHz, same thing except now
>> >> the large spike is -2MHz from 0.
>> >
>> > This could be a clock harmonic. At 1650 MHz, do you still see
>> something?
>> >
>> > M
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected] <mailto:[email protected]>
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20150402/fa0b7f09/attachment-0001.html>
------------------------------
Message: 24
Date: Thu, 02 Apr 2015 18:36:17 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RuntimeError: LookupError: KeyError: No
devices found for ----->, Empty Device Address
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/02/2015 06:16 PM, numeric via USRP-users wrote:
> Hi,
>
> I installed gnuradio GRC 3.7.6.1 from source. Used the
> "|build-gnuradio"| <http://www.sbrac.org/files/build-gnuradio> script
> to build gnuradio. Many prerequisites were missing, starting with
> "git". I am still not sure if all the prerequisites have been
> installed. I found QT missing and installed the latest version from
> https://www.qt.io/download-open-source/. It seems like it solved the
> QT5.Qt4 as QT (something like that). Finally a successful build; or so
> I thought. Now I get the error "RuntimeError: LookupError: KeyError:
> No devices found for ----->,Empty Device Address".
>
> I am using:
> 1. the b200 usrp pcb
> 2. Ubuntu 14.04.2 LTE 64 bit
> 3. GRC 3.7.6.1
> 4. Dell Inspiron 13 7000 series with the Intel 5th generation i7 CPU.
> 5. BIOS set for secure boot and UEFI
> 6. An external drive for Linux OS
> 6.1 64 GB SanDisk Extreme USB 3.0 Flash Drive 245 MB/s Read 190
> MB/s write.
>
> Help is greatly appreciated
> Rob
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
There was a horrible botch in Ubuntu recently--they *renamed existing
packages in an existing release*, which means that as build-gnuradio
asks for packages, it fails to find them. WORSE, apt-get, even with
--ignore-missing, considers that asking for a package that isn't in the
repo to be a fatal error, so, it tends to abort the entire lots of
installs even if ONE of them is mis-named, which, up until Ubuntu
totally screwed the pooch, there wouldn't have been any.
I updated build-gnuradio late yesterday to properly name the mis-named
package, so, depending on when you grabbed build-gnuradio that fix may
not have been in place. Also, you can get more details about what
it's doing under the covers using the -v option.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/0429afe6/attachment-0001.html>
------------------------------
Message: 25
Date: Thu, 2 Apr 2015 15:54:48 -0700
From: Patrick Sathyanathan <[email protected]>
To: Piotr Krysik <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Question: new (green) USRP B210 and Takachi
enclosure
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Correction: "SMA connector/USB/power jack holes"
--Patrick
From: [email protected]
To: [email protected]
Subject: RE: [USRP-users] Question: new (green) USRP B210 and Takachi enclosure
Date: Thu, 2 Apr 2015 15:43:17 -0700
I recently purchased a B210 enclosure from Takachi and the model I ordered was
MXA3-11-16SSH (though the label on the packing said something like
FXA3-11-16SSH, can't confirm right now). It fits my revision 6 B210 perfectly.
It comes with printing of the front and back panels, which have all SMA
connector/UDB/power jack holes, as well as two screw holes in each plate
(screws included). You should tell them that it's for the rev 6 and they have
all the drawings for it. Here is a snippet from their invoice: Customization :
Ettus B210 ver.6
Enclosure : USD17.93 /unit
All Alu. Mobile Enclosure, Torx-screws
Silver Anodized Frames / Silver Anodized End-panels
Milling : USD62.89 /unit
DRW#B2Xx_PLATE_R2_111814 (Updated Nov.20,2014)
Note: All inner-side corners of rectangular cutouts are R0.5 (Radius
0.5mm).
Note: Base material (color) is visible after machined.
Inkjet-printing : USD26.55 /unit
ART#B2Xx_PLATE_R2_111814 (Updated Nov.20,2014)
2-side, 1-color (Black)
--Patrick
> Date: Thu, 2 Apr 2015 15:42:42 +0200
> To: [email protected]
> Subject: Re: [USRP-users] Question: new (green) USRP B210 and Takachi
> enclosure
> From: [email protected]
>
> W dniu 02.04.2015 o 15:19, David via USRP-users pisze:
> > On 2015-04-02 14:14, Piotr Krysik via USRP-users wrote:
> >> Hi all,
> >>
> >> I wonder if Takachi enclosure MXA3-11-16 is suitable for USRP B210
> >> revision 6?
> >> If yes - is there design for drilling holes in the front and back of the
> >> enclosure available?
> >
> > It doesn't directly answer your question, but an old reply of mine
> > might help you:
> > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-February/012608.html
> >
> > David
> >
> I've seen that post but I have following situation:
> I'm in advanced talks with a company based in Poland regarding purchase
> of 4 Takachi enclosures (with drilled holes and with printing) for B210
> devices that we are going to buy. But I just figured out that Takachi
> enclosures were advised for white USRPs B210 and there is no information
> if the revision 6 devices will fit in it. I cannot find any drawing with
> dimensions for drilling holes in the enclosure for revision 6 B210.
>
> There is this file:
> http://files.ettus.com/b2x0_enclosure/B210_PLATE_REV1.2_070913_FINAL2.pdf
> but there are no dimensions.
>
> Piotr
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/2bbfa46e/attachment-0001.html>
------------------------------
Message: 26
Date: Fri, 3 Apr 2015 09:32:42 +0500
From: Amber and Sarosh <[email protected]>
To: Moritz Fischer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cloning E310 Firmware
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
OK Thanks. Yes on another E310 device.
Regards,
Amber, Sarosh & Naheed
> Date: Thu, 2 Apr 2015 09:56:26 -0700
> Subject: Re: [USRP-users] Cloning E310 Firmware
> From: [email protected]
> To: [email protected]
> CC: [email protected]
>
> Hi Amber, Sarosh & Naheed,
>
> please take a look at our manual [1] section on that subject. I don't
> understand what you mean by 'on an other device'. Another E310?
>
> Moritz
>
>
> [1] http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_image_building
>
> On Thu, Apr 2, 2015 at 12:17 AM, Amber and Sarosh via USRP-users
> <[email protected]> wrote:
> > Hi
> > Can anyone please help us making an image of the E310 firmware with our
> > custom installations such that it can be burned as it is on an other device?
> >
> > Regards,
> > Amber, Sarosh & Naheed
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150403/fde9c0d6/attachment-0001.html>
------------------------------
Message: 27
Date: Fri, 03 Apr 2015 10:14:17 +0200
From: Piotr Krysik <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Question: new (green) USRP B210 and Takachi
enclosure
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Many thanks Patrick!
Your answer is exactly what I needed to know.
Best Regards,
Piotr Krysik
W dniu 03.04.2015 o 00:54, Patrick Sathyanathan pisze:
> Correction: "SMA connector/USB/power jack holes"
>
> --Patrick
>
> ------------------------------------------------------------------------
> From: [email protected]
> To: [email protected]
> Subject: RE: [USRP-users] Question: new (green) USRP B210 and Takachi
> enclosure
> Date: Thu, 2 Apr 2015 15:43:17 -0700
>
> I recently purchased a B210 enclosure from Takachi and the model I
> ordered was MXA3-11-16SSH (though the label on the packing said
> something like FXA3-11-16SSH, can't confirm right now). It fits my
> revision 6 B210 perfectly. It comes with printing of the front and
> back panels, which have all SMA connector/UDB/power jack holes, as
> well as two screw holes in each plate (screws included). You should
> tell them that it's for the rev 6 and they have all the drawings for it.
>
> Here is a snippet from their invoice:
>
> *
>
> Customization : Ettus B210 ver.6
>
> */
>
> Enclosure : USD17.93 /unit
>
> /
>
> All Alu. Mobile Enclosure, Torx-screws
>
> Silver Anodized Frames / Silver Anodized End-panels
>
> /
>
> Milling : USD62.89 /unit
>
> /
>
> DRW#B2Xx_PLATE_R2_111814 (Updated Nov.20,2014)
>
> Note: All inner-side corners of rectangular cutouts are R0.5 (Radius
>
> 0.5mm).
>
> Note: Base material (color) is visible after machined.
>
> /
>
> Inkjet-printing : USD26.55 /unit
>
> /
>
> ART#B2Xx_PLATE_R2_111814 (Updated Nov.20,2014)
>
> 2-side, 1-color (Black)
>
> --Patrick
> > Date: Thu, 2 Apr 2015 15:42:42 +0200
> > To: [email protected]
> > Subject: Re: [USRP-users] Question: new (green) USRP B210 and
> Takachi enclosure
> > From: [email protected]
> >
> > W dniu 02.04.2015 o 15:19, David via USRP-users pisze:
> > > On 2015-04-02 14:14, Piotr Krysik via USRP-users wrote:
> > >> Hi all,
> > >>
> > >> I wonder if Takachi enclosure MXA3-11-16 is suitable for USRP B210
> > >> revision 6?
> > >> If yes - is there design for drilling holes in the front and back
> of the
> > >> enclosure available?
> > >
> > > It doesn't directly answer your question, but an old reply of mine
> > > might help you:
> > >
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-February/012608.html
> > >
> > > David
> > >
> > I've seen that post but I have following situation:
> > I'm in advanced talks with a company based in Poland regarding purchase
> > of 4 Takachi enclosures (with drilled holes and with printing) for B210
> > devices that we are going to buy. But I just figured out that Takachi
> > enclosures were advised for white USRPs B210 and there is no information
> > if the revision 6 devices will fit in it. I cannot find any drawing with
> > dimensions for drilling holes in the enclosure for revision 6 B210.
> >
> > There is this file:
> >
> http://files.ettus.com/b2x0_enclosure/B210_PLATE_REV1.2_070913_FINAL2.pdf
> > but there are no dimensions.
> >
> > Piotr
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 56, Issue 3
*****************************************
