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: Thread AssertionError and Libc++abi.dylib on Mac
Transmissions (Michael Dickens)
2. Re: tune time for N210 (Josh Blum)
3. Re: tune time for N210 (gang li)
4. synchronization method "mimo" (Usrp IITM)
5. Re: synchronization method "mimo" (Josh Blum)
6. Re: UHD device in Windows (Josh Blum)
7. BasicRX 50 Msps mode (David Campbell)
8. UHD and set_tx_rate (Gaetano Mendola)
9. Re: UHD and set_tx_rate ([email protected])
10. Usage of setting_reg and readback_mux (Tim Schuschies)
----------------------------------------------------------------------
Message: 1
Date: Wed, 16 Jan 2013 12:37:19 -0500
From: Michael Dickens <[email protected]>
To: "[email protected] list" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Thread AssertionError and Libc++abi.dylib on
Mac Transmissions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
I've updated the MacPorts ports for uhd (release) and uhd-devel with this patch
< https://trac.macports.org/changeset/101668 >. It will be live around 1
PM/ET/US. - MLD
> Success!
>
> I removed the MacPorts install, grabbed the latest version from the
> repository and made your suggested changes. Everything is running great now,
> as it seems my previous "Ulibc++abi.dylib: terminate called without an active
> exception" was also related to this.
>> So here is my updated patch. I am going to test that this hasn't broke
>> anything under linux, and then I can get it into mainline and a patch
>> release.
>>
>> http://pastebin.com/YtMu0xj5
------------------------------
Message: 2
Date: Wed, 16 Jan 2013 12:08:15 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] tune time for N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 01/16/2013 09:39 AM, gang li wrote:
> Hi, all,
>
> Does someone know how long it takes to tune the frequency and lock the
> LO in N210 with SBX? I saw some discussions here but i couldnt find
> them. Thanks.
The worst case lock time according to the synthesizer docs is 300us. So
if you issue the tune command at time t (while you are receiving
samples): assume samples in the window t + 300us are not valid.
This code snippet is also an example of using timed commands:
http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-others
-josh
>
> Best,
> Gang
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Wed, 16 Jan 2013 16:10:54 -0500
From: gang li <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] tune time for N210
Message-ID:
<CAKro2L23zVKA+ZMGZCbDUFW7bq7TOwnWesrTPLZ=ka+9qxr...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thank you, Josh !
Best,
Gang
On Wed, Jan 16, 2013 at 1:08 PM, Josh Blum <[email protected]> wrote:
>
>
> On 01/16/2013 09:39 AM, gang li wrote:
>> Hi, all,
>>
>> Does someone know how long it takes to tune the frequency and lock the
>> LO in N210 with SBX? I saw some discussions here but i couldnt find
>> them. Thanks.
>
> The worst case lock time according to the synthesizer docs is 300us. So
> if you issue the tune command at time t (while you are receiving
> samples): assume samples in the window t + 300us are not valid.
>
> This code snippet is also an example of using timed commands:
> http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-others
>
> -josh
>
>>
>> Best,
>> Gang
>>
>> _______________________________________________
>> 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
------------------------------
Message: 4
Date: Thu, 17 Jan 2013 09:53:28 +0530
From: Usrp IITM <[email protected]>
To: [email protected]
Subject: [USRP-users] synchronization method "mimo"
Message-ID:
<CAPkh=_9D53MXr5===11aq+ykw_cf-tpsecy+n27oq1h0vpv...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi
Iam trying to setup 2x1 MISO.The two USRPs in the transmitter are
synchronised using only the MIMO cable.
>From the example program rx_multi_samples.cpp,I understand that I have to
set the slave using these two functions.
usrp->set_clock_source("mimo", 1);
usrp->set_time_source("mimo", 1);
My doubt is should I configure anything for the master?In the example
program there is no configuration set for the master motherboard.So is it
internal by default?
What happens if we do not provide an external clock to master, and set its
configuration to external in the code(May be stupid but it seemingly gives
a better result in my application)?
Regards
Varsha
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130117/9687b964/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 16 Jan 2013 22:59:12 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] synchronization method "mimo"
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 01/16/2013 10:23 PM, Usrp IITM wrote:
> Hi
> Iam trying to setup 2x1 MISO.The two USRPs in the transmitter are
> synchronised using only the MIMO cable.
>
> From the example program rx_multi_samples.cpp,I understand that I have to
> set the slave using these two functions.
> usrp->set_clock_source("mimo", 1);
> usrp->set_time_source("mimo", 1);
>
> My doubt is should I configure anything for the master?In the example
> program there is no configuration set for the master motherboard.So is it
> internal by default?
The configuration uses internal reference by default.
>
> What happens if we do not provide an external clock to master, and set its
> configuration to external in the code(May be stupid but it seemingly gives
> a better result in my application)?
>
If default, the master uses internal TCXO for reference. If you set
external, but do not provide an external, the clock is undisciplined
(free running) it will drift more over time.
-josh
> Regards
> Varsha
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Wed, 16 Jan 2013 23:05:18 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD device in Windows
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 01/16/2013 07:54 AM, Luong Tan Phong wrote:
> Hi,
>
> I installed UHD and Gnuradio latest version (binaries download from
> http://files.ettus.com/, 09-Jan-2013) in Windows. My application base on
> C++, boost 1.47 (flow graph: uhd source -> Fft) is OK when I call
> gr_top_block->start(); stop(), wait(). The error "thread[thread-per-block[0]:
> <gr_block gr uhd usrp source (1)>]: ValueError: bad vrt header or packet
> fragment" show on console when I call gr_top_block->start() (after stop(),
> wait() functions). The application is OK on Ubuntu.
>
> Could you help me to solve the issue, please?
> Thank you.
> Best regrads,
>
> LTP
I think what happens is that while the stream is shutdown and restarted,
a packet may get caught in the middle. When this packet gets parsed an
error is thrown and it makes it way into the uhd_usrp_source block in
gnuradio.
Unfortunately this error tells the worker thread to exit. If the thread
ignore the error and continue, then this might actually be a recoverable
error.
1) A longer term suggestion, is to patch the gr-uhd source code to
continue rather than exit. I can give you a patch to test, but since you
have prebuilt binaries, that isnt much help.
2) Can you cause the application to recover by calling
usrp_source_block->stop() + calling again
gr_top_block->start()/gr_top_block->stop?
-josh
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 7
Date: Thu, 17 Jan 2013 07:21:02 -0800 (PST)
From: David Campbell <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] BasicRX 50 Msps mode
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
All,
?? Here's my config for the n210 with BasicRX
????? Freq (tone) in: 20 MHz
????? n210 decimation: 2
????? n210 tune freq:? 25 MHz
????? n210 bits/sample: 8
????? (therefore, data is 50 Msps 8-bit complex)
???? With this config, my tones appear at +5 and -5 MHz (equal levels) out.? I
would expect a tone just at -5 MHz.
? ?? If I just change the n210 decimation to 4, then I just get the strong tone
at -5 MHz, as I would expect.
????
Thanks,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130117/ab1fcdc9/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 17 Jan 2013 17:12:39 +0100
From: Gaetano Mendola <[email protected]>
To: [email protected]
Subject: [USRP-users] UHD and set_tx_rate
Message-ID:
<CAJycT5rwrQjaK+X_cDnjFmo3+LwqCbbNY5Avt=m3pxuk-c3...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
I would like to understand better the usage of the method
uhd::usrp::multi_usrp::set_tx_rate.
In the past using the libusrp the tx rate was set using the concept of
a decimation value considering a base of 100 Msps.
Now with the adoption of the UHD interface we are using the method
in the following way:
set_tx_rate(100e6 / decimation);
emulating then the "interface" of the old libusrp.
Is the FPGA now able to interpolate an "arbitrary" sample rate to
match the hardware one instead of only the submultiples of 100 Msps?
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
------------------------------
Message: 9
Date: Thu, 17 Jan 2013 11:17:42 -0500
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] UHD and set_tx_rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 17 Jan 2013 11:12, Gaetano Mendola wrote:
> Hi all,
> I would
like to understand better the usage of the method
>
uhd::usrp::multi_usrp::set_tx_rate.
>
> In the past using the libusrp
the tx rate was set using the concept of
> a decimation value
considering a base of 100 Msps.
> Now with the adoption of the UHD
interface we are using the method
> in the following way:
>
>
set_tx_rate(100e6 / decimation);
>
> emulating then the "interface" of
the old libusrp.
>
> Is the FPGA now able to interpolate an "arbitrary"
sample rate to
> match the hardware one instead of only the submultiples
of 100 Msps?
>
> Regards
> Gaetano Mendola
No, the hardware only
handles integer fractions of the basic sampling rate, it's just the UHD
API presents it as a sample-rate request, rather than a decimation-value
request.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130117/94a3e385/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 17 Jan 2013 17:45:26 +0100
From: Tim Schuschies <[email protected]>
To: [email protected]
Subject: [USRP-users] Usage of setting_reg and readback_mux
Message-ID:
<caov+zhsypz0fojqzsnmm-cszbuo4g_fgb0ga8-aqreltep9...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
I'm trying to add a register to the FPGA Firmware of the USRP2. I simply
want to write the register value to the readback mux and read with the ZPU.
I am sending an UDP message to the ZPU witch contains the value I want to
write to my register. Afterward I'm sending another UDP message back to the
Host-PC. This message should contain the same value back red from the
readback mux.
Actually I did the following:
I added a localparameter to u2_core.v beyond the other address definitions:
line 175 "localparam SR_DUMMY_REG= 250;" I want to set the address of my
dummy register to 250.
I defined a new 32 bit wide wire: "wire [31:0] dummy" My signal from the
output to the readback mux is called "dummy".
I added this wire in the wb_readback_mux definition: "wb_readback_mux
buff_pool_status(.wb_clk[...] ,.word01(dummy),.word02(32'hffff ffff),
[...]);" word01 was before also set to 32'hffff ffff. I set my dummy
register output to Word 1 of the readback mux.
I added a new register: "setting_reg #(.my_addr(SR_DUMMY_REG)) dummy_reg //
the standard width of these registers is 32bit so I don't have declare it
explicit, do I?
(.clk(wb_clk),.rst(wb_rst),.strobe(set_stb_dsp),.addr(set_addr),.in(set_data),.out(dummy),.changed());"
// I don't know if "set_strobe_dsp" is the right strobe for my reg, is it?
Thats all I changed in the FPGA firmware. Afterwards I did some changes in
the ZPU firmware.
In memory_map.h I added my register and the readback mux field as the
following:
// Changes of Readback Mux definition
typedef struct {
volatile uint32_t spi;
volatile uint32_t dummy; // My dummy reg is connected to word 1, so I
have to write it as the second field in this struct, don't I?
volatile uint32_t _padding[6]; // I have to decrease the size of this
field to 6.
[...]
} router_status_t;
// Adding my register to memory map
#define DUMMY 250
#define dummy_reg ((uint32_t*) _SR_ADDR(DUMMY)) // with this line I should
have defined my new register.
// routines to read and write register:
Write:
I get my UDP packet to a new registered UDP handler (this is working well)
in its payload I get my 32bit value. I copy it to my register using its
address:
"memcpy(dummy_reg,payload,sizeof(uint32_t));" // I think this should work
to write the value of the first 32bit of the UDP payload to my register. Am
I right ?
To read my register I'm doing the following:
"uint32_t val = readpack_mux->dummy;"
"send_udp_pkt(MYPORT,HOST_PC_ADR, &val, sizeof(uint32_t));" // I receive
this message on my Host-PC, but the value it contains is 0 and not the
value I think I wrote to my register.
Does anyone know what I'm doing wrong ?
I also cannot read my register directly with "uint32_t val = dummy_reg".
Value is also 0. But I think this case is OK, because the setting_reg
description does not contain any readback functionality.
How could it work ?
Does anyone has an idea ?
Thanks to all.
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130117/eae1e721/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 29, Issue 17
******************************************
