On Tue, Dec 14, 2010 at 4:50 AM, Michael Dickens m...@alum.mit.edu wrote:
On Dec 13, 2010, at 7:33 PM, Tom Rondeau wrote:
The biggest problem that I see with cmake is that the burden of proof
lies with cmake.
I'm 100% confident that CMake, or QMake for that matter (and, I'm sure, BJam
and
On Fri, Dec 23, 2011 at 5:17 PM, Marcus D. Leech mle...@ripnet.com wrote:
Please do not get me wrong. I believe that the work from Ettus and the
contributors to GNU-Radio are revolutionary! The equipment with the
interface to GNU-Radio is not only priced at a level that is affordable to
many
On Tue, Nov 8, 2011 at 5:11 AM, Josh Blum j...@ettus.com wrote:
Hello list,
A bunch of great work has been merged into the master.
---
-- Hooks for IQ balance and DC offset correction
find anything
suggesting this.
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, Jul 28, 2011 at 6:02 PM, Matt Ettus m...@ettus.com wrote:
On 07/28/2011 02:58 AM, Gaetano Mendola wrote:
Hi all,
I'm transmitting my signal with 5Mhz bandwidth with a carrier of 70Mhz,
analyzing output spectrum I see some replicas outside the bandwidth
(see attached image).
I'm using
, you can always
recover it with a JTAG programmer (if you have one).
Unfortunately I don't have it.
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo
Hi all,
I was setting one of our N210 we got last week, while flushing the firmware
the procedure (normaly it takes one second) stopped this way:
USRP-N2XX found.
Flash size: 4194304
Sector size: 65536
Begin firmware write: this should take about 1 second...
Erasing 31744 bytes at 3145728
I have sent this to usrp-us...@lists.ettus.com but somehow it doesn't
work. Anyway here the email.
Hi all,
after a week of tests I can conclude that (streaming a big file for
example) if the server has the disk cache full then the uhd::device::send
method last longer than expected (see picture
On Fri, Jun 24, 2011 at 5:29 AM, Philip Balister phi...@balister.org wrote:
On 06/23/2011 02:48 PM, Gaetano Mendola wrote:
Hi all,
running my application with valgrind it complained about some
uninitialized values.
Patch attached.
Is it possible these are false positives from Valgrind
Hi all,
running my application with valgrind it complained about some
uninitialized values.
Patch attached.
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
diff --git a/host/lib/transport/super_send_packet_handler.hpp
b/host/lib/transport/super_send_packet_handler.hpp
index 8ebc264..2aedd75
you access to our server if you want instrument somehow the
UHD to see what is going
on.
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
attachment: send_response_time.gifattachment: corrupted_tx.gif___
Discuss-gnuradio mailing list
Discuss-gnuradio
I believe there is a typo in that file (last git version), patch inline.
--- a/host/lib/usrp/usrp2/usrp2_impl.cpp
+++ b/host/lib/usrp/usrp2/usrp2_impl.cpp
@@ -249,7 +249,7 @@ usrp2_impl::usrp2_impl(const device_addr_t _device_addr){
//extract the user's requested MTU size or default
Hi all,
I got last version from git compiled and installed, installed the
images UHD-images-003.001.002.tar.gz
as well. The device is a USRP N210 with a WBX.
It seems now the device is unable to receive any data, the
benchmark_rate example gives
./benchmark_rate
linux; GNU C++ version 4.4.3;
On Sun, Jun 19, 2011 at 8:44 PM, Gaetano Mendola mend...@gmail.com wrote:
I have 12 cores on my server, and I fear the kernel is juggling that thread
around.
I have solved the issue but still I'm not happy at all with what is going on.
The samples I'm feeding with the USRP N210 are stored
with io_type equal to COMPLEX_FLOAT32 and send mode
equal to SEND_MODE_FULL_BUFF.
Is there a way to optimize the send execution time (not giving float32
but int16 for
example) ?
And why sometime the send lasts all that time ?
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
attachment
On Sun, Jun 19, 2011 at 8:01 PM, Josh Blum j...@ettus.com wrote:
On 06/19/2011 02:55 AM, Gaetano Mendola wrote:
Hi all,
I'm observing strange execution times calling the method uhd::device::send.
The tx rate I'm using is 12.5 Mega samples per seconds and the method send
is called with 45000
Hi all,
in my application for each transmission I have to feed the USRP2 with
a vector long 3 milions complex
samples and the sample rate is 12.5 Megasamples/second (I'm using a
decimation = 8).
The machine connected with the USRP2 is an atom based architecture and
that sample rate is very
for not primitive types (think about the
position of virtual table
pointer) it is not defined but just compiler dependend.
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org
?
Even setting ADC-digital = 6.0, ADC-digital-fine = 0.5 and setting the
WBX-PGA0 to same value used with libusrp2
the result is not the same as in I'm losing something like 20 dB.
Is this expected ?
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
the set_rx_antenna to
TX/RX I'm getting now the expected powers.
If I have to use the device as receive only do you suggest to use the RX2
connection ?
Regards
Gaetano mendola
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http
Tom,
let me know when you have applied it.
On Thu, Mar 10, 2011 at 2:07 PM, Tom Rondeau trondeau1...@gmail.com wrote:
Thanks, Gaetano,
I haven't looked at the code yet, but the patch looks right. Hopefully, I'll
get it in tonight.
Tom
On Thu, Mar 10, 2011 at 6:15 AM, Gaetano Mendola mend
d_buf)
+if (!d_using_tpring d_buf) {
free(d_buf);
+}
+else {
+if(d_buf) {
+munmap(d_buf, d_buflen);
+}
+}
return d_ethernet-close();
}
On Wed, Mar 9, 2011 at 7:35 PM, Gaetano Mendola mend...@gmail.com wrote:
Hi
call
indeed freeing a pointer to 0 is perfect valid code, the standard
say that in case of free(NULL) no action is taken, to the other side
munmap a NULL pointer is not permitted (hence the test).
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
On Fri, Feb 18, 2011 at 6:25 PM, Josh Blum j...@ettus.com wrote:
On 02/17/2011 11:49 PM, Pol Henarejos wrote:
Oh, I see. I was surprised of increasing the API's major version to 3,
but images are in 2.
Yes, on the next branch the number is bumped up to 3. Numerous changes
are
Is there a list of options can be passed to uhd::device::make ?
So far I have found: addr, recv_buff_size (is this in samples or bytes?).
Regards
Gaetano
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
On Wed, Feb 16, 2011 at 9:29 PM, Josh Blum j...@ettus.com wrote:
On 02/16/2011 12:24 PM, Gaetano Mendola wrote:
Is there a list of options can be passed to uhd::device::make ?
http://www.ettus.com/uhd_docs/manual/html/identification.html
So far I have found: addr, recv_buff_size
Hi,
in libusrp2 samples are sent to device in packets of 370 samples,
while in UHD now the max is 362,
is there any way to have 370 in UHD as well ?
Regards
Gaetano
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
On Wed, Feb 16, 2011 at 10:22 PM, Josh Blum j...@ettus.com wrote:
On 02/16/2011 01:02 PM, Gaetano Mendola wrote:
Hi,
in libusrp2 samples are sent to device in packets of 370 samples,
while in UHD now the max is 362,
is there any way to have 370 in UHD as well ?
Yes and maybe: The default
to detect an internal buffer
overflow is cheking the
uhd::rx_metadata_t::error_code for each recv.
Is there a way to know how many samples were lost ?
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio
On Thu, Feb 10, 2011 at 6:40 PM, Josh Blum j...@ettus.com wrote:
On 02/10/2011 07:47 AM, Gaetano Mendola wrote:
Hi,
I'm porting my application to use the new UHD interface due the fact
I'm going to use
the new USRP devices. With the old usrp2 interface I was able to
retrieve the samples
Hi,
is the combo RFX400 with UHD supposed to work ?
I tried the example ./tx_waveforms and it doesn't seems to work, even
if the device is recognized.
Using a WBX I get the expected result.
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
On Fri, Nov 26, 2010 at 3:11 PM, Gaetano Mendola mend...@gmail.com wrote:
Hi all,
I'm doing some recovery tests in case the USRP is disconnected while
my software is using it.
What I'm observing is the fact that using an instance of usrp2::usrp2 with
decimation = 8 the calls to usrp2::usrp2
if the thread_group::join all inside the usrp2::impl::stop_bg() doesn't
terminate quick enough (or may be never).
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo
this was done to reliefe the user to
perform an
explicit delete, however due this bug the user is forced to do:
usrp2::usrp2::sptr myDevice = usrp2::usrp2::make(eth1, , 1024*1024)
...
try {
myDevice.reset();
}
catch(...) {
}
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
tecnique does more than apply the
old but still good
principles (used since decads in the software industry) such:
1) Divide et impera
2) Look up table.
The results you obtained are encouraging, in the sense that still in
2010 such old principles
are still of valid use.
Regards
Gaetano Mendola
on the user to behave nicely.
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Fri, Sep 17, 2010 at 9:14 PM, Gaetano Mendola mend...@gmail.com wrote:
Hi all,
I'm observing that rx handlers are called when 371 samples are ready,
I thought (I don't remember why
I have 370 hard coded in my code) the chunks where 370 samples. Has
this changed lately or it has been
On Sat, Sep 18, 2010 at 12:25 AM, Gaetano Mendola mend...@gmail.com wrote:
On Fri, Sep 17, 2010 at 9:14 PM, Gaetano Mendola mend...@gmail.com wrote:
Hi all,
I'm observing that rx handlers are called when 371 samples are ready,
I thought (I don't remember why
I have 370 hard coded in my code
Hi all,
in order to use the new WBX daughterboards, do I have to get the new
libusrp2 from git ?
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo
On Thu, May 6, 2010 at 8:15 PM, Josh Blum j...@joshknows.com wrote:
On 05/06/2010 07:17 AM, Gaetano Mendola wrote:
Hi all,
in order to use the new WBX daughterboards, do I have to get the new
libusrp2 from git ?
To actually answer your question, if you dont want to experiment with the
uhd
Gaetano Mendola
(gdb) thread 1
[Switching to thread 1 (Thread 0x2b5969a573b0 (LWP 10370))]#0
0x003334607955 in pthread_join ()
from /lib64/libpthread.so.0
(gdb) bt
#0 0x003334607955 in pthread_join () from /lib64/libpthread.so.0
#1 0x003f42204177 in omni_thread::join () from
/usr
to use
also a PPS source. Can you suggest any out of shelf device able to
give use both 10MHz and the PPS needed ?
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman
it, and
successfully compiled the firmware, I found that at the link:
http://gnuradio.org/releases/usrp2-bin/trunk/
is already compiled and ready to be installed :(
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss
Hi all,
at the moment I'm following a project in where we use as
development technique the test driven development.
We are using the libusrp2 as only component from gnuradio,
and what we are missing is a sort of Usrp2 simulator in
order to test our rx handlers. Does exist such component in
On Tue, Dec 15, 2009 at 8:51 PM, Eric Blossom e...@comsec.com wrote:
On Tue, Dec 15, 2009 at 01:01:22AM +0100, Gaetano Mendola wrote:
Hi all,
I think I'm experiencing some buffer underrun using an instance of
usrp2, to transmit my
samples I'm using the method usrp2::tx_16sc.
I have
Hi all,
I think I'm experiencing some buffer underrun using an instance of
usrp2, to transmit my
samples I'm using the method usrp2::tx_16sc.
I have the usrp2 equipped with a rfx400 and using as interpolation a value of 8.
I found out that 192 calls to usrp2::tx_16sc last 0.56 seconds passing
to
46 matches
Mail list logo
