Re: [Discuss-gnuradio] Volk branch on github
On Tue, 2012-02-14 at 22:56 -0500, Tom Rondeau wrote: There's been a ton of work going on in getting us ready to really start using Volk in GNU Radio blocks. Instead of repeating myself, here, you can see more about the who/what/when/why/how of the changes here: http://www.trondeau.com/blog/2012/2/13/gnu-radio-is-crap-and-other-such-insights.html I think you copied the wrong link. You probably meant: http://www.trondeau.com/blog/2012/2/13/volk-integration-to-gnu-radio.html Martin The basic summary is that I'm seeing amazing performance results and I'm very excited to get this into our project. I'm really hoping that people can check out the branch and test it out against their applications. A number of changes were made inside GNU Radio and a handful of blocks have been converted to using Volk, and I'd like to see how the performance compares. My own tests show great results, but I have a pretty heterogeneous setup (Linux/Ubuntu and Intel processors). I should have another post on my website later this week discussing my benchmark results for the Volk blocks, but anyone interested in testing it out on their own should check out gnuradio-examples/python/volk_benchmark. The README in that directory should help you understand what to do and how to do it. We would like to get this merged into GNU Radio master (and therefore version 3.5.2) as soon as possible, so I would really appreciate feedback and bug reports as soon as possible. Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk branch on github
I think it would make sense to change the volk interface by adding
kernel calls which can handle the two alignment cases (aligned,
unaligned).
We would have to add a is_unaligned parameter to the volk kernel calls.
The gnuradio blocks would then change in the following way:
So in stead of:
if(is_unaligned()) {
for(size_t i = 1; i input_items.size(); i++){
volk_32fc_x2_multiply_32fc_u(out, out, (gr_complex*)input_items[i],
noi);
}
} else {
for(size_t i = 1; i input_items.size(); i++){
volk_32fc_x2_multiply_32fc_a(out, out, (gr_complex*)input_items[i],
noi);
}
}
You would have:
for(size_t i = 1; i input_items.size(); i++)
volk_32fc_x2_multiply_32fc(is_unaligned(), out, out,
(gr_complex*)input_items[i], noi);
You halve the amount of code in gnuradio blocks which to my opinion
makes it much more maintainable.
Martin
On Wed, 2012-02-15 at 12:06 +0100, Martin DvH wrote:
On Tue, 2012-02-14 at 22:56 -0500, Tom Rondeau wrote:
There's been a ton of work going on in getting us ready to really
start using Volk in GNU Radio blocks. Instead of repeating myself,
here, you can see more about the who/what/when/why/how of the changes
here:
http://www.trondeau.com/blog/2012/2/13/gnu-radio-is-crap-and-other-such-insights.html
I think you copied the wrong link.
You probably meant:
http://www.trondeau.com/blog/2012/2/13/volk-integration-to-gnu-radio.html
Martin
The basic summary is that I'm seeing amazing performance results and
I'm very excited to get this into our project.
I'm really hoping that people can check out the branch and test it out
against their applications. A number of changes were made inside GNU
Radio and a handful of blocks have been converted to using Volk, and
I'd like to see how the performance compares. My own tests show great
results, but I have a pretty heterogeneous setup (Linux/Ubuntu and
Intel processors).
I should have another post on my website later this week discussing my
benchmark results for the Volk blocks, but anyone interested in
testing it out on their own should check out
gnuradio-examples/python/volk_benchmark. The README in that directory
should help you understand what to do and how to do it.
We would like to get this merged into GNU Radio master (and therefore
version 3.5.2) as soon as possible, so I would really appreciate
feedback and bug reports as soon as possible.
Thanks!
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio at Chaos Communication Camp 2011
Hi, I will be going and probably take a few others from The Netherlands with me. I organized a gnuradio workshop on HAR2009 together with Pascal Schiks. Maybe we will do that again on CCC. I will be taking about a dozen USRPs, daughterboards, clocktamers, antennas and OpenBTS desktop kits with me. They can be used for workshops and I also sell them. Maybe we should start a gnuradio village. Regards, Martin Dudok van Heel Olifantasia On Thu, 2011-07-07 at 10:01 +0200, Patrick Strasser wrote: Hello! I'll be attending the Chaos Communication Camp 2011 near Berlin in August[1]. I hope to see some GNU Radio people there. Someone else who intends to be there too? Is there a village where the probability for meeting GNU Radio people is extraordinary high? Regards Patrick [1] http://events.ccc.de/camp/2011/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio.org seems to be down
gnuradio.org seems to be down Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large FFTs
Dear Carles, On Mon, 2010-08-23 at 21:37 +0200, Carles Fernandez wrote: Dear Thomas, we have found some problems when using USRP2+DBSRX for GPS due to phase noise. See details in http://www.ruby-forum.com/topic/213845 I have experimented with using the clock from the usrp to a modified TVRX (disabling the internal TVRX clock, using a 4 Mhz clock from the usrp). One of my findings was that if you use a low resistor from the usrp clock output to a daughterboard, followed by a relatively large capacitor to ground (for lowpass filtering) you can get a lot of spurious. The usrp can generate quite some power on this clockline. When you load the clockline to heavy, it wil start generating RF power. The load being a low resistor and big capacitor. The antenna being the track from the usrp to the lowpass filter. In the worst case you can be generating several milliwatts. This can definitely have an effect on the performance. Especially if you happen to be on a multiple of the daughterboard clock. My advise would be to experiment with a higher impedance lowpass filter which does not put a heavy load on the clockline. You could also experiment with a buffer amplifier. Good luck, Martin Dudok van Heel Olifantasia.com If someone have succeded on this, we would appreciate some hints to make it work. Our software GPS receiver was not able to track signals, while it run smoothly when using USRP1 + DBSRX without modification. Best regards, Carles Fernandez On Mon, Aug 23, 2010 at 10:00 AM, Thomas Hobiger hobi...@nict.go.jp wrote: We are considering to purchase a USRP2 + a DBSRX board in order to utilize it for some GPS stuff. Thus it would be interesting to know what's the maximum supported (implemented) FFTs size. I have checked the old discussions, but there's nothing really conclusive. What we are looking for is something larger than 16K FFT points. Maybe someone has experiences with such large FFTs and how they perform (Flops or FFTs per second)? Best regards, Thomas Hobiger -- ** Dr. Thomas Hobiger Space-Time Measurement Project Space-Time Standards Group New Generation Network Research Center National Institute of Information and Communications Technology -- 4-2-1 Nukui-Kitamachi, Koganei 184-8795 Tokyo Japan -- email: hobi...@nict.go.jp -- homepage (priv.): http://www.hobiger.org ** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Patch to increasy dynamic range of usrp2 by adding shift_iq setting
Hi All,
I created a patch which adds a shift_iq setting to the usrp2.
This can shift the output of dsp_core_rx by 0 to 3 bits.
(= Multiply by 1, 2, 4 or 8)
It does proper rounding and clipping.
With the shift_iq setting in combination with the already existing
scale_iq you can optimize the dynamic range so that the samples going to
the PC always use the full 16 bit [-32768 to + 32767]
In practice this means a dynamic range increase of 6 dB or more.
Of course, if you set the shift to high you will get clipping.
The patch changes the fpga verilog, fpga firmware, usrp2, and gr-usrp
sources.
I did several icarus verilog simulations which came out OK.
I also created a python testscript which uses the actual usrp2. It
generates a 200 kHz signal on TX and receives it with RX.
(you need to loopback TX to RX using basicRX/TX or LFTX/RX boards.)
With the GUI you can set scale_iq and shift_iq.
I generated a new u2_rev3.bin and txrx.bin which seem to work fine.
Note that this firmware is based on my current git checkout.
So if you want to have this feature with the lastest code, you have to
apply my patch to the latest tree and generate new firmware yourself.
I created this patch on request, so it would be great if it were added
to the official tree. (So the default firmware can be used in the future
to have this function)
Patch and a testscript at:
http://www.olifantasia.com/projects/gnuradio/mdvh/usrp2_add_shift_iq/
Martin Dudok van Heel
diff --git a/gr-usrp2/src/usrp2.i b/gr-usrp2/src/usrp2.i
index 3197402..e960372 100644
--- a/gr-usrp2/src/usrp2.i
+++ b/gr-usrp2/src/usrp2.i
@@ -72,6 +72,7 @@ public:
bool set_center_freq(double frequency, usrp2::tune_result *r);
bool set_decim(int decimation_factor);
bool set_scale_iq(int scale_i, int scale_q);
+ bool set_shift_iq(int shift_q, int shift_i);
int decim();
%rename(_real_adc_rate) adc_rate;
bool adc_rate(long *rate);
diff --git a/gr-usrp2/src/usrp2_source_base.cc b/gr-usrp2/src/usrp2_source_base.cc
index 0ad7008..12fcd88 100644
--- a/gr-usrp2/src/usrp2_source_base.cc
+++ b/gr-usrp2/src/usrp2_source_base.cc
@@ -76,6 +76,12 @@ usrp2_source_base::set_scale_iq(int scale_i, int scale_q)
return d_u2-set_rx_scale_iq(scale_i, scale_q);
}
+bool
+usrp2_source_base::set_shift_iq(int shift_q, int shift_i)
+{
+ return d_u2-set_rx_shift_iq(shift_q, shift_i);
+}
+
int
usrp2_source_base::decim()
{
diff --git a/gr-usrp2/src/usrp2_source_base.h b/gr-usrp2/src/usrp2_source_base.h
index 2e2d51f..d318ad9 100644
--- a/gr-usrp2/src/usrp2_source_base.h
+++ b/gr-usrp2/src/usrp2_source_base.h
@@ -61,11 +61,24 @@ public:
bool set_decim(int decimation_factor);
/*!
- * \brief Set receive IQ scale factors
+ * \brief Set receive IQ input scale factors
*/
bool set_scale_iq(int scale_i, int scale_q);
/*!
+ * \brief Set receive IQ output shift
+ * shift 0 (default) scales by 1
+ * shift 1 scales by 2
+ * shift 2 scales by 4
+ * shift 3 scales by 8
+ * Note that with a shift 0 overflow and clipping can occur.
+ * This can be resolved by reducing scale_iq to below the default 1024.
+ * By using a shift of 1 or 2 and reducing scale_iq,
+ * the full 16 bit output range (-32768 to +32767) can be used
+ */
+ bool set_shift_iq(int shift_q, int shift_i);
+
+ /*!
* \brief Get receive decimation rate
*/
int decim();
diff --git a/usrp2/firmware/apps/app_common_v2.c b/usrp2/firmware/apps/app_common_v2.c
index 036d0ba..54bef3f 100644
--- a/usrp2/firmware/apps/app_common_v2.c
+++ b/usrp2/firmware/apps/app_common_v2.c
@@ -272,6 +272,9 @@ config_rx_v2_cmd(const op_config_rx_v2_t *p,
if (p-valid CFGV_SCALE_IQ){
dsp_rx_regs-scale_iq = p-scale_iq;
}
+ if (p-valid CFGV_SHIFT_IQ){
+dsp_rx_regs-shift_iq = p-shift_iq;
+ }
// Build reply subpacket
diff --git a/usrp2/firmware/include/usrp2_eth_packet.h b/usrp2/firmware/include/usrp2_eth_packet.h
index 63d4b3a..b1db5ac 100644
--- a/usrp2/firmware/include/usrp2_eth_packet.h
+++ b/usrp2/firmware/include/usrp2_eth_packet.h
@@ -283,6 +283,7 @@ typedef struct {
uint32_t freq_lo; // low 32-bits of 64-bit fxpt_freq (Q44.20)
uint32_t decim; // desired decimation factor (NOT -1)
uint32_t scale_iq; // (scale_i 16) | scale_q [16.0 format]
+ uint32_t shift_iq; // (shift_i 4) | shift_q [0, 1, 2 or 3]
} _AL4 op_config_rx_v2_t;
// bitmask for valid field. If the bit is set, there's
@@ -292,7 +293,7 @@ typedef struct {
#define CFGV_FREQ 0x0002 // target_freq field is valid
#define CFGV_INTERP_DECIM 0x0004 // interp or decim is valid
#define CFGV_SCALE_IQ 0x0008 // scale_iq is valid
-
+#define CFGV_SHIFT_IQ 0x0010 // shift_iq is valid
/*!
* \brief Reply to receiver configuration
*/
diff --git a/usrp2/firmware/lib/memory_map.h b/usrp2/firmware/lib/memory_map.h
index 0d0cf04..14b5f7b 100644
--- a/usrp2/firmware/lib/memory_map.h
+++ b/usrp2/firmware/lib/memory_map.h
@@ -500,6 +500,32 @@ typedef struct {
*/
volatile uint32_t
[Discuss-gnuradio] gnuradio.org seems to be down
The gnuradio.org server seems to be down. (9 Jun 2010) Even a ping times out. Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr.prefs
On Wed, 2010-04-28 at 15:28 -0400, Marcus D. Leech wrote:
Is there any kind of guide as to how gr.prefs is supposed to be used?
Is this functionality going
to be deprecated at any point, is there any kind of plan as to how it
will be used?
There is not much documentation but I found out the hard way a few
thinks you should know.
The format of the prefs configartion files:
-Never ever put a comment on the same line as a setting.
For example:
GOOD:
# default fft_rate=15
fft_rate=8
BAD
fft_rate=8 # default fft_rate=15
This results in a parse error for the line, and consequently the default
being used (in this case 15) in stead of your value (in this case 8).
Comments should be on their own line, starting with a # with no
whitespace in front of the #.
-Don't have backups of conf files (or other files) laying around in
(/usr/local)/etc/gnuradio/conf.d
All files in (/usr/local)/etc/gnuradio/conf.d will be parsed.
If you have gr-wxgui.conf and gr-wxgui.conf~ and gr-wxgui.conf.bak and
README.txt then all will be parsed in unknown order.
The last value parsed will be used.
The best way I found to find out which values are used from the prefs is
doing a grep on the whole gnuradio tree.
First find the files which use prefs
For C++ files:
grep -R gr_prefs::singleton *
For python files:
grep -R gr\.prefs *
Then look in those files for get_string, get_long, get_
Maybe it is also possible to tweak doxygen to show all uses of gr_prefs,
I haven't tried.
To find out how to use it, just look at the current uses.
In short:
instantiate a gr_prefs singleton
in C++ gr_prefs::singleton()
in pythongr.prefs()
And use one of the following methods to get your value:
get_('section_name', 'option_name', default_value_if_not_found)
Where get_ is get_bool, get_double, get_long,get_string or
get_long
Martin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Spread Spectrum question in gnuradio
On Wed, 2010-04-28 at 11:23 -0700, Johnathan Corgan wrote: On Tue, Apr 27, 2010 at 21:19, John Andrews gnu.f...@gmail.com wrote: If I want to transmit a signal which is DSSS spread using BPSK. Is it correct for me to first digitally spread the incoming data bits and then apply BPSK before sending it to the USRP or should I first convert the signal to BPSK and then multiply the output of the BPSK modulator with the PN sequence although I don't know how to do it. Technically, these are equivalent. However, it is easier and uses less CPU to XOR your data sequence with your PN code, then send it to the modulator. I think there is a difference, if you use a root raised cosine filter, set for your datarate and roll-off factor. I think the correct version should then be: BPSKmod - RRCfilter - DSSS Martin Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 Inband rework, request for features and comments
On Tue, 2010-02-16 at 15:43 -0700, Eric Schneider wrote: Hi George, no worries, I know perfectly well how it is to have too many ambitions and too little time... :-) I can confirm that the timestamps are correct. I have been using it for some time. The compiled RBF is not in my developer branch. I haven't even moved my recent work to git... :-/ I am trying to find a working version of the inband code. Where can we find your work. The last I could find is at: http://nyquist.gnuradio.org/svn/gnuradio/branches/developers/ets/inband/ But that shows no activity for a long long time. I also tried to checkout your personal git and get the inband branch: git clone http://gnuradio.org/git/ets.git git checkout --track -b inband origin/inband git fetch But that has the inband example C++ apps and libs code moved to usrp/limbo (in other words, disabled, nonfunctional) There are some older (but should be functional) versions at: http://www.schneider-group.com/gnuradio/ Those are only the rbfs Thanks, Martin The only recent changes I have made were related to debugging dropped/late tx packets due to host latency (I echo the tag fields from tx to rx). I have had some inquiries regarding the ability of the tx chain to use lower clock rates ( 48M, the xfer rate to the FX2). Apparently others have had problems with that setup. I will investigate this sometime in the near future. I will also try to put together some tests to fully exercise the inband functionality. Please recommend any tests you would like to see. --Eric On Tue, 2010-02-16 at 14:42 -0500, George Nychis wrote: Hi Eric, Sorry for the late response here, I've been wrapped up in so many things. Is your latest compiled RBF in your developer branch? There are several people I know (some that I CC'ed) that are interested in using the inband code. Last I checked, the timestamp had an issue of jumping which I know you tried to fix. Last time I tried your branch, I'm not sure it was working yet. Have you confirmed that timestamps to the host are not jumping in any manner when there is no overrun, and have you confirmed that timestamps are being treated properly when trying to transmit? Thanks a bunch for updating this code. - George On Tue, Jan 26, 2010 at 5:32 AM, Per Zetterberg per.zetterb...@ee.kth.se wrote: Eric Schneider wrote: Hi all, I'm looking to be doing some more rework of the USRP1 inband code, specifically to align with the USRP2 VRT work. For those not familiar, USRP1 inband allows for timestamped rx/tx samples (and commands), which is very useful for TDMA type systems. It is a separate FPGA configuration and host side interface. Has anyone besides me used the current inband FPGA? I'm not sure who on this list is interested in such a thing, but if you have specific needs you want addressed, speak up now! A few notes on my current thinking: 1. I do not intent to implement VRT over USB. Only to implement a VRT compatible interface on the host. The USB inband protocol will simply serve to make that possible in the most efficient way possible. 2. I don't intend to keep the existing inband packet structure. This is one area where interested parties really need to provide feedback as to supported (or supportable) feature sets. It is my hope that the new inband Verilog modules can be used by other custom FPGA builds as a standard host interface. For example, it has just recently occurred to me that the FPGA side could be made more efficient by the use of trailer metadata rather than headers. Since the USB packets are fixed size, I don't really see a downside. There are also fields in the current inband packet that are either obsolete, or should be optional fields, IMO. RSSI, for example. Do timestamps really need to be 32 bits? That allows scheduling transmission 33 seconds in advance on a 64MHz clock, which seems excessive to me. Is there
[Discuss-gnuradio] removal of mblock and inband code
I noticed this in a recent commit: commit ac2b84b93cad94f9a8830eeb5e62dace997c9a47 Author: Johnathan Corgan jcor...@corganenterprises.com Date: Mon Apr 26 22:41:19 2010 -0700 Remove mblock library. We hardly knew 'ye. This commit removes all mblock and inband code. Is a new message passing interface usable with usrp-1 in place yet? I was just working on getting the inband code working again to be able to do timestamped rx and tx on usrp-1? Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with new install
On Tue, 2010-04-27 at 08:57 -0700, William Pretty Security Inc wrote: Hi All; Well I picked up my new system at Best Buy. (details later) I installed Ubuntu 9.10 and Gnuradio from the git. I must have made a typo somewhere because I get the following error when I probe the USRP1: - will...@usrp:/usr/local/bin$ usrp_probe usrp_open_interface:usb_claim_interface: failed interface 0 could not claim interface 0: Operation not permitted open_nth_cmd_interface: open_cmd_interface failed usrp: failed to load firmware /usr/local/share/usrp/rev4/std.ihx. Sounds like you forgot to logout and login or reboot. Martin --- Could it be a typo when I was adding the “usrp” group ?? Bill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fix for usrp2 overruns when stopping and restarting rx streaming
Hi All,
When you use an USRP2 for capturing and you call
u2-stop_rx_streaming()
and later
u2-start_rx_streaming(0)
You always get a single overrun.
-a single 'S' is output on the console
-u2-rx_overruns() returns 1 (in stead of 0)
I am developing a usrp2 application which does not permit any overrun
conditions, so this needed fixing.
It turns out that the expected sequence number of received samples is
not reset when stopping the stream.
This single line patch fixes this.
Best Regards,
Martin
diff --git a/usrp2/host/lib/usrp2_impl.cc b/usrp2/host/lib/usrp2_impl.cc
index b19c6ec..92d52db 100644
--- a/usrp2/host/lib/usrp2_impl.cc
+++ b/usrp2/host/lib/usrp2_impl.cc
@@ -814,6 +814,7 @@ namespace usrp2 {
success = transmit_cmd_and_wait(cmd, sizeof(cmd), p,
DEF_CMD_TIMEOUT);
success = success (ntohx(reply.ok) == 1);
d_channel_rings[channel].reset();
+ d_rx_seqno=-1;
//fprintf(stderr, usrp2::stop_rx_streaming: success = %d\n,
success);
return success;
}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AFC (Automatic Frequency Control) FM demo python and GRC scripts
Hi all, I wrote two gnuradio AFC (Automatic Frequency Control) demos This AFC technique can come in handy when your tuning is critical and there is a frequency offset or doppler shift to be expected. (Like when trying to receive NOAA weather satelites which can have a substancial doppler shift. I am also working on an updated gr-noaa receive script which uses this AFC. ) There is a broadcast FM demo and a NOAA weathersatellite narrowband FM simulation demo. You can discuss and give feedback on the gnuradio AFC demo's here: http://www.gnuradio.eu/cms/nl/node/203 (But feedback on the gnuradio mailinglist is also OK of course) You can read about and download the gnuradio AFC demo's here: http://www.olifantasia.com/projects/gnuradio/mdvh/AFC Here follows the README: Gnuradio AFC demo's This directory contains gnuradio GRC and python example scripts for using AFC in an FM receiver. There is not (yet) a AFC gnuradio block. So these examples implement the AFC by lowpass filtering the FM demodulator output and putting the result in a variable sink. The variable sink then sets the center frequency of the frequency translating channel filter. This compensates any frequency offset or doppler drift. To limit the performance penalty of calling python code from the samplestream, the code is only called once a second. The critical settings of this feedback loop are: AFC_gain (float) AFC_IIR_alpha (float) AFC_update_rate (float value: seconds between updates) If you want to use this for a different FM signal type also make sure you set the right channel_bandwidth and max_dev (=Maximum FM frequency deviation in Hertz) Have fun 17 Mar 2010 Martin Dudok van Heel Olifantasia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LFRX boards at low-VHF frequencies
On Fri, 2010-03-12 at 14:12 -0500, Marcus D. Leech wrote: Has anybody on-list had experience using the BASIC_RX or LFRX boards at low-vhf frequencies (30-50MHz)?? BasicRX works when you add a corresponding bandfilter and a LNA. Note however that the first niquist frequency is at 32 Mhz with a default USRP1 with a 64 MHz ADC clock. So signals above 32 Mhz will fold around to stations below 32 Mhz. You can remove this effect with a bandfilter, but you need some cutting space to do this. With a very tight filter you can do about 98-126 Mhz or 66-94 Mhz or 34 - 62 Mhz or 0 - 30 Mhz. But around the niquist freqs itsself +/- 32 Mhz +/64 MHz, +/- 96 Mhz is not possible. If you use a different clockfreq for the ADC you can change the niquist freq. The USRP2 for example uses a 100 MHz ADC clock. With this you can do about 0 - 48 Mhz wit a tight lowpass filter. Running the USRP1 at 56 MHz will give you around 30 - 54 Mhz or 0 - 26 Mhz with the right bandfilters. You can easily check this by running usrp_WFM_rcv.py on the commercial FM band with a basicRX daughterboard. Note that there is a niquist freq at 96 Mhz with the default clock ( 64 Mhz). So if you leave out the bandfilter the stations above 96 Mhz fill fold around on top of the stations below 96 Mhz. I use a programmable clockgenerator with a USRP1 for experiments like this. I haven't tried with LFRX. These use diffential amplifiers which have a limited bandwidth. They will probably work up to 50 Mhz but not much above that. BasicRX works up to around 200 MHz. But also note that the higher the frequency, the lower the sensitivity and the higher the phasenoise. I have a potential science project that could usefully be implemented in that frequency range. Cheers, Martin Cheers ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] simultanuous receive and transmit on USRP2 in C++, maybe use threads
Hi All, I am building an application where I simultanuously want to receive and transmit using the USRP2. Since I also need the timestamps, I implement this using C++. (Building my own filewriter class which extends usrp2::rx_nop_handler, like in rx_streaming_samples.cc) Should I use threads to keep TX and RX from interfering with each other. With threads I could just start the RX thread and TX thread. If I don't use threads I have to interleave sending and receiving packets. Is there an example I could look at. I now based my code on : usrp2/host/apps/rx_streaming_samples.cc and usrp2/host/apps/tx_samples.cc I know gnuradio has its own support code for threads, but I couldn't find an easy example on how to use it. Best Regards, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Altera Quartus II for linux free web edition finally available
With the release of Quartus II 9.1 on 2 november 2009 Altera has finally decided to make a free Linux Web edition available. https://www.altera.com/support/software/download/altera_design/quartus_we/dnl-quartus_we.jsp http://www.altera.com/corporate/news_room/releases/2009/products/nr-quartus-ii-v91.html?f=hpk=wn2 This means it is finally possible to synthesize the FPGA firmware for the USRP on Linux without having to use a windows emulator. Best Regards, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] HAR2009 SDR:Village
Hi All, There will be a Software Defined Radio Village (Village:SDR) at the HAR2009 event (13 to 16 august, Netherlands). Pascal and Martin will bring a couple of USRPs and other equipment. We will be giving Gnuradio workshops (in several languages, if needed) and do Gnuradio demonstrations. That is, if we can find a spot to do so, because we don't have a big tent ourselfs. We hope that more Gnuradio and SDR enthousiasts wil join us there. We especially hope, someone brings a big tent so we can do our workshops and demonstrations there. For more information see the links and info below. Greetings, Martin Dvh https://wiki.har2009.org/page/Village:SDR Village:SDR Village for those that are interested in Software Defined Radio Morely for those that are interested in the OpenSource SDR platform GNU-Radio We'll bring a couple of USRP's and other devices to demonstrate some of the capabilities of GNU-Radio, Like running our own 70cm HAM-band Repeater (although 10M, 2M or 23cm can be done as wel) Also intending to give some workshops for those that like to do experiment with SDR. Joining this village User:Coolepascal Martin DVH VillageSDR Short Description: Software Defined Radio Contact User:CoolePascal Workshops Yes, were planning is we find a good spot as wel as a beamer Activities We'll mainly demonstrate and promote GNU-Radio soft and hardware using some nice and hopefully impressive demo's The where-abouts Hacking at Random 2009 is an international technology security conference. Four days of technology, ideological debates and hands-on tinkering. On August 13-16, 2009 the 20th anniversary edition of the four-yearly Dutch outdoor technology-conference will take place at de Paasheuvel near Vierhouten in The Netherlands, Europe. https://www.har2009.org/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Programming USRP as a relay node
On Sat, 2009-07-04 at 14:15 +0300, Tasos Kyrillidis wrote: Hello everyone, I am a postgraduate student at Technical University of Crete, Chania and i am currently working on a project with USRPs. Part of our project is to communicate with a relay node. But this relay node is a little bit slow, because there is data transfer from USRP to PC and then from PC to USRP. So, there is an idea to program the FPGA of USRP as a relay without any communication between PC and USRP - the relay node just detects packets and retransmit them without any further processing. 1. One idea is to program the FPGA to include a packet detector and a raised cosine filter. But I read somewhere that the default FPGA has only 5% available resources and i am wondering if these resources are enough for a packet detector and a raised cosine filter? You can free up resources by reducing the number of channels. In your case, only one RX and one TX channel in stead of two. You can also replace the halfband filter with a raised cosine filter. (Note, you can only use a limited number of taps, depending on the decimation factor) A simple signal level detector should be doable. For a packet detector and best S/N ratio you should completely demodulate the packets and remodulate them (regenerate the signal) This will be quite complicated though and possibly not fit in the FPGA. When you use a USRP2 you have much more room in the FPGA. Implementing a complete receiver, packet detector and transmitter will certainly fit, but it will still be a complicated design. Greetings, Martin 2. In case there are enough resources (in some way), could anyone estimate how difficult would be to implement it? Has the current configuration to be changed a lot or including the appropriate modules is enough? I know that my questions are kind of abstract but i couldnt express them differently Thanks anyway Tasos Kyrillidis __ What can you do with the new Windows Live? Find out ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CUDA-Enabled GNURadio gr_benchmark10 possible improvements
On Wed, 2009-07-01 at 05:27 -0400, Yu-Hua Yang wrote:
Thank you very much for your reply. I have some more questions. I
understand you wont be looking/updating this branch anymore due to the
release of OpenCL, but thanks for helping right now!
Before you dive in, one thing I am having concerns is this output that
happens every time I run CUDA-enable code:
gr_vmcircbuf_cuda::copy_buf_to_buf() error cudaMemcpy() returned 0x3 =
3 initialization error
gr_vmcircbuf_cuda::copy_buf_to_buf recreating buffer d_base=0x382
size=32768 *2
If I remember well, this error is not a problem if you get it once per
instantiated CUDA block.
It is a problem if you get it multiple times for the same block.
If I remember well, this has to do with CUDA not being happy with
multithreaded applications and access to the same device buffer from
different host-threads.
Gnuradio using cuda should always use the single-threaded scheduler.
(This is not the default)
I don't remember if my code does this automatically or if you have to
force it using an environment variable.
( you can select the
scheduler used at runtime by setting the GR_SCHEDULER environment
variable. E.g.,
multithreaded Thread-Per-Block scheduler
$ GR_SCHEDULER=TPB ./my-gnuradio-application.py ...
or
Single-Threaded-Scheduler
$ GR_SCHEDULER=STS ./my-gnuradio-application.py ...
)
If you have to use the environment variable, then this should go into
the gnuradio-CUDA docs (if it is not already there).
Greeting,
Martin
Are these 2 outputs normal? Are they suppose to happen? If not, how do
I fix this?
2009/6/30 Martin DvH gnuradiom...@olifantasia.com
On Tue, 2009-06-30 at 02:52 -0400, Yu-Hua Yang wrote:
Upon a closer look into cuda_muiltiply_const_ff_kernel.cu,
there
exists 5 different kernel functions to do the
multiplication, where
the default one,
__global__ void
cuda_multiply_const_ff_kernel(const float* g_idata,
float*
g_odata,const int noutput_items,const float konst)
is completely blank. But regardless, nobody calls these
kernel
functions.
cuda_multiply_const_ff was never finished or I accidently
removed some
code here.
Either way, this is clearly a bug.
The empty kernel should call one of the implemented kernels.
Then, in the same file, which is called by
cuda_multiply_const_ff.cc,
in this function
int
get_cuda_multiply_const_ff_kernel_params
( cuda_multiply_const_ff_kernel_params *params )
{
int result=0;
//const unsigned int max_num_threads_per_block =
MAX_NUM_THREADS_ALL; //can use the maximum number
of threads
if wanted
//unsigned int max_num_blocks =
MAX_NUM_BLOCKS_ALL;
unsigned int num_blocks=4096 ;// =
gridDim.x;
//NUM_CUDABLOCKS
unsigned int num_threads_per_block=512;// =
blockDim.x; //NUM_THREADS;
unsigned int
num_outputs_per_block=num_threads_per_block;
const unsigned int num_outputs_per_grid=
num_outputs_per_block*num_blocks;
//(blockDim.x)*gridDim.x
size_t dynamic_shared_mem_size =
0;//256*sizeof(float);//0;//num_threads_per_block*sizeof(gr_complex);
dim3 griddim( num_blocks, 1, 1);
dim3 threaddim( num_threads_per_block, 1, 1);
params-griddim=griddim;
params-threaddim=threaddim;
params-dynamic_shared_mem_size=dynamic_shared_mem_size;
params-num_outputs_padded=num_outputs_per_grid;
params-num_inputs_padded=num_outputs_per_grid;
params-num_inputs=0;//num_outputs_per_grid;//num_outputs;
params-num_outputs=0;//num_outputs_per_grid;//num_outputs;
//Now you can do the kernel invocation like this:
//cuda_multiply_const_ff_filter_kernel
params-griddim,
params-threaddim, params-dynamic_shared_mem_size
(g_idata, g_odata,
params-num_outputs_padded*X,konst);
return result;
}
The kernel invocation is completely commented out! The
result is
initialized as 0 at the top and returns it. All the work in
between to
specify and allocate thread, block sizes does not seem to
matter. Not
sure why
Re: [Discuss-gnuradio] CUDA-Enabled GNURadio gr_benchmark10 possible improvements
On Tue, 2009-06-30 at 02:52 -0400, Yu-Hua Yang wrote:
Upon a closer look into cuda_muiltiply_const_ff_kernel.cu, there
exists 5 different kernel functions to do the multiplication, where
the default one,
__global__ void
cuda_multiply_const_ff_kernel(const float* g_idata, float*
g_odata,const int noutput_items,const float konst)
is completely blank. But regardless, nobody calls these kernel
functions.
cuda_multiply_const_ff was never finished or I accidently removed some
code here.
Either way, this is clearly a bug.
The empty kernel should call one of the implemented kernels.
Then, in the same file, which is called by cuda_multiply_const_ff.cc,
in this function
int
get_cuda_multiply_const_ff_kernel_params
( cuda_multiply_const_ff_kernel_params *params )
{
int result=0;
//const unsigned int max_num_threads_per_block =
MAX_NUM_THREADS_ALL; //can use the maximum number of threads
if wanted
//unsigned int max_num_blocks = MAX_NUM_BLOCKS_ALL;
unsigned int num_blocks=4096 ;// =
gridDim.x; //NUM_CUDABLOCKS
unsigned int num_threads_per_block=512;// =
blockDim.x; //NUM_THREADS;
unsigned int num_outputs_per_block=num_threads_per_block;
const unsigned int num_outputs_per_grid=
num_outputs_per_block*num_blocks; //(blockDim.x)*gridDim.x
size_t dynamic_shared_mem_size =
0;//256*sizeof(float);//0;//num_threads_per_block*sizeof(gr_complex);
dim3 griddim( num_blocks, 1, 1);
dim3 threaddim( num_threads_per_block, 1, 1);
params-griddim=griddim;
params-threaddim=threaddim;
params-dynamic_shared_mem_size=dynamic_shared_mem_size;
params-num_outputs_padded=num_outputs_per_grid;
params-num_inputs_padded=num_outputs_per_grid;
params-num_inputs=0;//num_outputs_per_grid;//num_outputs;
params-num_outputs=0;//num_outputs_per_grid;//num_outputs;
//Now you can do the kernel invocation like this:
//cuda_multiply_const_ff_filter_kernel params-griddim,
params-threaddim, params-dynamic_shared_mem_size
(g_idata, g_odata, params-num_outputs_padded*X,konst);
return result;
}
The kernel invocation is completely commented out! The result is
initialized as 0 at the top and returns it. All the work in between to
specify and allocate thread, block sizes does not seem to matter. Not
sure why this code exists this way, did someone make an edit or did
Martin specifically commented out the kernel invocation?
Yes the kernel invocation is specifically commented out.
The commented out kernel invocation is only here as documentation on
how to do the actual kernel invocation.
There is still a small typo.
It should refer to cuda_multiply_const_ff_kernel and not
cuda_multiply_const_ff_filter_kernel
This methods name is get_cuda_multiply_const_ff_kernel_params
It does just that, determine the needed params for the kernel
invocation.
The actual kernel invocation is done in:
cuda_multiply_const_ff_work_device
Both get_cuda_multiply_const_ff_kernel_params and
cuda_multiply_const_ff_work_device are called from normal C++ code in
cuda_multiply_const_ff_kernel.cu
Better examples to look at and benchmark would be
cuda_quadrature_demod_cuda_cf
cuda_fir_filter_fff
These are both used in
testbed/wfm/cuda_wfm_rcv.py
Which calls the complete cuda implementation of a WFM receiver in
cuda_wfm_rcv_cuda.py
You will notice a cuda_multiply_const_ff block is instantiated as
volume_control but not used in the final connect because it didn't work.
Now I know this is because of the bug you found.
Is this suppose to be this way? I don't see how this can be a proper
benchmarking if it seems that we just test about allocating threads
and blocks on the device and memory access times, but really don't do
any computation.
That is not a good benchmark indeed.
cuda_multiply_const_ff should be fixed first.
The fir-filter is however the thing you really want to benchmark.
(Which is also in there)
The more taps the fir-filter has, the more computations it will have to
make.
Note that the cuda implementation is at the moment limited in the number
of taps it can support at a certain decimation factor.
If I remember well decimationfactor*numberoftaps should stay below 2048
(or was it 512)
Ways of improving the resuls include having gnuradio do calculations in
bigger chunks.
This can be done in several ways.
One way is to have a block at the end of the processing chain which has
a large output_multiple requirement which needs 1 input for every
output.
In other words. Connect a block to the end of the processing chain which
has set_output_multiple(large_number) in
Re: [Discuss-gnuradio] TVRX question
On Sun, 2009-06-21 at 15:15 +0200, Sebastiaan Heunis wrote: Hi all For some reason I always thought that the TVRX daughterboards support IQ sampling. Turns out I was wrong. You are only partly wrong. The TVRX is only sampled in I. But the usrp firmware transforms this into IQ samples at the stage which converts the signal from the IF to baseband. The samples you get in the PC are IQ samples. You don't have to modify your processing chain in your application. You only have to take care of the I sampling at the place where you set the ADC mux (only sample the I part of the IF using only one ADC). Greetings, Martin How do I modify my applications for I sampling? Can I just wire up a whole IQ chain, save files in IQ format, use read_complex_binary.m to read it in and discard the Q part? How do I setup the USRP to only have an I path on the inside? Do I just use usrp_source_s and then read saved files using read_float_binary.m? Thanks in advance. Sebastiaan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio and CUDA
On Fri, 2009-06-19 at 03:28 -0400, Yu-Hua Yang wrote: Continuing from this thread http://lists.gnu.org/archive/html/discuss-gnuradio/2008-11/msg00293.html Has there been any progress made since 2008? No, not much. I am waiting for the OpenCL implementations from nvidia and ATI to become available to the general public. Then I plan on rewriting the code from CUDA to OpenCL. This way we only have to support one codebase for a multitude of hardware platforms. (nvidia GPU, ATI GPU, cell processor, multicore-CPU) The current codebase in my development brache is usable though. Anybody is welcome to work further on this. I myself are not planning on working on it untill openCL becomes available. I registered for early developer access to the nvidia OpenCL implementation but I never heard from then since. Greetings, Martin Dudok van Heel Thank you ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBS-RX satellite connection
On Sat, 2009-06-06 at 21:57 -0700, Eric Blossom wrote: On Sat, Jun 06, 2009 at 02:30:05AM -0400, davek wrote: I would like to get my usrp conneced to my TVRO satellite dish. I am wondering... Is the DBSRX daughter card suitable for direct connection to a satellite LNB? Yes. I am thinking it will be easier to let the sat receiver do the lnb power and polarization control Is it be safe to connect to the lnb loop-through connection on standard satellite receivers? I don't know. I have done that in the past and it worked fine. (I did analog satelite TV reception which is FM modulated. I just switched the AM-demod block in usrp_tv_receive.py for a quadrature-demod block (=FM demodulator) and reduced decimation and got an image. You get some distortion because you can't get the complete bandwidth of a sattelite channel usring a USRP-1. (Best I got was 16 MHz using 8 bits/sample and decimation 4 ) Using the sat-receiver for power and polarisation is very conveniant. You can use the remote to switch polarisation. Greetings, Martin Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Upcoming changes in the development trunk
On Wed, 2009-05-27 at 06:44 -0700, Johnathan Corgan wrote: In no particular order of time or importance, these are among some of the changes planned for the development trunk and 3.3 release that may affect you: ... * Elimination of the single-threaded flowgraph scheduler. The thread-per-block scheduler is already the default in 3.2. While this won't require any code changes, if you've been manually selecting the STS via the environment, you won't be able to do this anymore. Is it really neccesary to remove this? I need the single-threaded-scheduler for my GPGPU code. (Running gnuradio on a videocard) When doing doing calculations on en external device, you really need to be in control of on which CPU/thread which block is running. In practice you need to run everything that runs on the external device from a single host thread. The external device is running hundreds of threads and gnuradio only needs a single thread to control the external device and move data between the host and external device. I have been waited with developing the GPGPU code further until the changes in the scheduling code stabelizes. (At the moment the gpgpu branche is incompatible with the most recent trunk) My version of the scheduler is a modified single-threaded scheduler. So I don't neccesaraly need to keep the current single-threaded scheduler, but I do need the possibility to choose which scheduler to use. * Migration of blks2 into C++. This has been a place to hold hierarchical blocks constructed in Python. Many of these blocks will be reimplemented as C++ API hierarchical blocks, and re-exported into Python as part of the core 'gr' namespace. This will done where possible without syntax changes needed in your Python code other than the namespace to import from. Will it be still possible to build your own python hierarchical blocks and install them somewhere.? Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Upcoming changes in the development trunk
On Wed, 2009-05-27 at 08:12 -0700, Johnathan Corgan wrote: On Wed, May 27, 2009 at 7:35 AM, Martin DvH gnuradiom...@olifantasia.com wrote: * Elimination of the single-threaded flowgraph scheduler. The thread-per-block scheduler is already the default in 3.2. While this won't require any code changes, if you've been manually selecting the STS via the environment, you won't be able to do this anymore. Is it really neccesary to remove this? Not strictly necessary, no. A lot of the new features in 3.3 will impact the scheduler, especially the new message passing between blocks. It will be extra work to modify both schedulers. This is Eric's area, however, so I'll let him comment further. OK, I get the picture. Since my single-threaded gpgpu-scheduler needs modifications as it is. Maybe you should implement the multi-threaded-scheduler and leave the scheduler choosing mechanism in place, and only leave stubs for the single-threaded case. I then could have a go at (trying to) implementing it for the single-threaded (gpgpu ) case. Eric, what's your view on this? Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recommended PC Hardware for Performance
On Tue, 2009-05-19 at 08:26 -0400, Tom Lutz wrote: This may be a somewhat banal question, but what would be the optimal hardware/software configuration needed to leverage the power of gnuradio? Core i7 versus Core2 Duo versus Other (maybe cell)? gnuradio depends heavily on floating point performance and memory bandwidth. It makes good use of multiple cores. So if you can afford it use a quad-core processor with a high memory bandwidth. ( i7 quad or a quad core AMD phenom II ) 64-bit Linux versus 32? Definitively 64 bit. I haven't measured it recently but I have seen people report that going from 32 to 64 bit linux gave a very significant performance boost with gnuradio. Any hardware acceleration/DSP cards? Work is being done on a Cell and a GPGPU port (run processing on videocard) of gnuradio. I myself am working on the gpgpu port. At the moment this is done using CUDA which is a nvidia-only technology. As soon as OpenCL is available this will be rewritten in OpenCL. OpenCL is a cross-platform technology for doing massive parallel calculations on different hardware on different OSes (Windows, Linux, MacosX). Nvidia has a beta version for Nvidia cards for linux, windows. ATI is working on a version for their cards. There will be a IBM Cell version. The next release of MacosX will have support for it (And will also make use of it within the OS) When running on the videocard the memory bandwidth of the videocard is the main performance differentiator between cards. (The biggest bottleneck is the transfer of the data over the PCI-express bus and the call-overhead but this is about the same for all PCI-express videocards) Don't expect the GPGPU port to be production ready within the next year or two though. So unless you want to want to help with this port you don't have to be picky which videocard to choose. If you do want to help with the GPGPU port I would suggest a nvidia GTX 200 series card for best performance (Nvidia GTX 285 if you can affort the financial and power budget) I myself use a nvidia 9600 GT which is not that fast, but gives a good impression if rewriting gnuradio for running on the GPU will give a speed improvement on average machines. Amount/type of RAM? Fast, faster fastest. Amount is not that critical. 2 GB or more should do for most Gnuradio work on Linux. While running some flow graphs on an older machine, I found that I had designed one of my low pass filters too tightly. The large number of taps in the FIR consumed all the processing power available, and starved the USRP for data. This is exactly why I started the GPGPU port. You can sometimes have better results when you use the gr_fft filter in stead of the gr_fir filter. It depends on your decimation factor if this has better or worse performance. low decimation factor: use FFT high decimation factor: use FIR If in doubt: benchmark Is there a way to notify the user when a flow graph begins to fail or fails intermittently? I don't know any. Anybody else knows a trick for this? Greetings, Martin Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio.org seems to be down
gnuradio.org seems to be down Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] schematic for lf-rx
On Wed, 2009-04-29 at 11:43 +0200, Markus Feldmann wrote: Hi All, is there a schematic for the LF-RX ? I need only a pdf file not really schematic file. gschem schema, pcb pcb-layout. There are also postscript and pdf versions in the same dir. http://gnuradio.org/trac/browser/usrp-hw/trunk/basic-lf You can check everything out at once with svn Martin Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FIR filter , Clock recovery and Quadrature demodulation
On Sun, 2009-04-26 at 22:30 +0500, M. Awais Arshad wrote: Hi, The following are some code segments of gsm-scan.py basically used for gsm data reception. I have a few questions about the difference between input_rate and sps, clock_rate = 64e6 #set the default input rate, we will check with the USRP if it is being used input_rate = clock_rate / options.decim gsm_symb_rate = 1625000.0 / 6.0 sps = input_rate/gsm_symb_rate # configure the processing blocks # configure channel filter filter_cutoff = 145e3 #135,417Hz is GSM bandwidth filter_t_width = 10e3 #Only DSP adjust for offset on datafile, adjust tuner for USRP #TODO: see if we can change this offset at runtime based on freq detection if options.inputfile: offset = self.offset else: offset = 0.0 filter_taps = gr.firdes.low_pass(1.0, input_rate, filter_cutoff, filter_t_width, gr.firdes.WIN_HAMMING) self.filter = gr.freq_xlating_fir_filter_ccf(1, filter_taps, offset, input_rate) # configure demodulator # adjust the phase gain for sampling rate self.demod = gr.quadrature_demod_cf(sps); #configure clock recovery gain_mu = 0.01 gain_omega = .25 * gain_mu * gain_mu # critically damped self.clocker = gr.clock_recovery_mm_ff( sps, gain_omega, 0.5, #mu gain_mu, 0.3) #omega_relative_limit, self.burst = gsm.burst_ff() self.connect(self.filter, self.demod, self.clocker, self.burst) . Can anyone please give me an idea why gr.freq_xlating_fir_filter_ccf is used here and 'input_rate' is used as an argument in stead of 'sps'. Well, because a freq_translating_fir_filter needs the input rate. It knows nothing about symbols so sps (samples per symbol) makes no sense here. Whereas, in quadrature demod and Clock_recovery_mm 'sps' is used for sampling rate sps is not used for samplingrate. Did you even bother looking up what the parameters mean. In quadrature_demod the parameter means gain (not sampling rate) See: http://gnuradio.org/doc/doxygen/classgr__quadrature__demod__cf.html In clock_recovery_mm_ff the first parameter means omega (not sampling rate) http://gnuradio.org/doc/doxygen/classgr__clock__recovery__mm__ff.html and why clock recovery is used after demodulation block ? Because you want to recover the symbol clock. As long as the samples are not demodulated there exists no symbols. Are I and Q samples are flowing out of clocker block or are they the encoded bits ? Mueller and Moeller (MM) based clock recovery block with float input, float output. This implements the Mueller and Moeller (MM) discrete-time error-tracking synchronizer. See Digital Communication Receivers: Synchronization, Channel Estimation and Signal Processing by Heinrich Meyr, Marc Moeneclaey, Stefan Fechtel. ISBN 0-471-50275-8. Thanks, M.Awais ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is it possible to buy a RFX900 without the filter?
On Thu, 2009-04-23 at 23:07 -0400, davek wrote: what capacitor does rfx1800 use in C204? If I recall well it is a 100 pF 603 capacitor. Martin On Thu, Apr 23, 2009 at 7:10 PM, Martin DvH gnuradiom...@olifantasia.com wrote: Hi Jhon, On Wed, 2009-04-22 at 22:03 -0700, Jhon Lee wrote: I read the discuss-gnuradio list and know that I need to bypass the filter with a capacitor and cut away the filter. I would like to know if it is possible to get a RFX900 which has removed the filter when I order it. You could always buy an RFX1800 and reprogram it as a RFX900. to turn your RFX1800 into a RFX900, you can run the command: ./burn-db-eeprom -A --force -t rfx900_mimo_b This way you don't have to solder anything. Also see the WIKI: What is involved in changing an RFX900 to an RFX1800? on: http://gnuradio.org/trac/wiki/UsrpFAQ/DBoards Greetings, Martin Thank you, Jhon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Standalone USRP1 Operation
On Thu, 2009-04-23 at 23:43 -0700, Firas A. wrote: Hi, Has anyone tried to run USRP1 without PC? I have an application where a friend supported me with a standalone USRP FPGA image. I used the PC only to load this image to the USRP using gnuradio blocks/tools. After that I can plug-off (disconnect) the USB cable from the PC and USRP continue to operate standalone. My question is, has anyone tried to load USRP FPGA image without a PC? For example using a micro-controller (Like Microchip PIC 18F4550 which has USB 2.0 port) with SD memory holding the image? What it takes/need to do so? What should be possible is to load the FPGA image and/or the FX2 image using JTAG. I think I remember that the JTAG lines are accessible on the USRP1. It might also be possible to use a dedicated serial FPGA eeprom and connect it directly to the FPGA. This would require hardware modification of the USRP board. Just look at the cyclone datasheet and application notes on the altera site. I don't know if all the required pins for setting the FPGA load operation are physically reachable on the USRP1 board. If you don't want to solder on your board, your only option is using a USB2 host in some kind of form. Martin Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is it possible to buy a RFX900 without the filter?
Hi Jhon, On Wed, 2009-04-22 at 22:03 -0700, Jhon Lee wrote: I read the discuss-gnuradio list and know that I need to bypass the filter with a capacitor and cut away the filter. I would like to know if it is possible to get a RFX900 which has removed the filter when I order it. You could always buy an RFX1800 and reprogram it as a RFX900. to turn your RFX1800 into a RFX900, you can run the command: ./burn-db-eeprom -A --force -t rfx900_mimo_b This way you don't have to solder anything. Also see the WIKI: What is involved in changing an RFX900 to an RFX1800? on: http://gnuradio.org/trac/wiki/UsrpFAQ/DBoards Greetings, Martin Thank you, Jhon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] KD7LMO Killed while bicycling
I am sorry to bring you this sad news. I found this information on: http://groups.yahoo.com/group/Ballooning/message/2810 KD7LMO Killed while bicycling We have received word that Michael Gray, KD7LMO, was killed Sunday, April 12, while bicycling to visit his parents. This occurred about 3:30 P.M. on Maricopa Road near the Maricopa Fire Department. Initial information was that he was bicyling with two friends, when he was struck from behind by a drunk driver . Many Gnuradio users used his OTA (of-the-air) capture files on http://www.kd7lmo.net/ground_gnuradio_ota.html This allowed them to start playing with Gnuradio without the need of an USRP. The website seems to be down now. Michael Gray was active with ballooning with ANSR (Arizona Near Space Research) He will be missed. Martin Dudok van Heel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Resource busy error:
On Wed, 2009-04-22 at 18:47 -0500, kollimarla bhargav wrote: Thanks a lot Martin, that solved our problem, now we are able to call another reciever code in benchmark_rx.py .One last question we tried to call benchmark_rx.py from usrp_spectrum_sense.py, but still we get the same error Resource busy It seems that another top block other than tb is running in usrp_spectrum_sense.py This might have to do with: self._tune_callback = tune(self)# hang on to this to keep it from being GC'd GCing (Garbage collecting) is exactly what we want here. There is a kind of circular reference here so the tb keeps existing I would try: tb._tune_callback.tb=None tb._tune_callback=None tb.u=None tb=None Good luck, Martin thanks bhargav On Wed, Apr 22, 2009 at 5:54 PM, Martin DvH gnuradiom...@olifantasia.com wrote: On Wed, 2009-04-22 at 17:41 -0500, kollimarla bhargav wrote: Hi all, We are trying to run a simple receiver program using benchmark_rx.py. The problem we are facing is when we try to run another receiver program like usrp_spectrum_sense.py inside the benchmark_rx.py using os.system() command , the error is Device or Resource busy. We get a feeling that the thread from benchmark_rx.py is still running. We even used thread.stop before calling usrp_spectrum_sense.py, but this did not work, the same error message popped up. Is there any other way of exclusively kill the thread and call another receiver program.??? We are able to call a benchmark_tx.py transmitter code in benchmark_rx.py receiver code, This is logical. The TX part of the USRP can be used seperately from the RX part. The RX part is still in use so it can't be used for a new receiver. but the combination of calling any program with a reciever block from benchmark_rx.py was not successful and we got a error message Resource busy . Is this a thread issue?? Appreciate any help!! Your receiver chain still exists, even if it is not running. This keeps the RX part of the USRP in use. Did you instruct the topblock to stop and wait for it to finish. If you did, you could try after stopping the topblock. tb.rxpath=None or even tb = None This throws away the reference to the receive_path (which keeps the RX part of the USRP in use and thus 'Resource Busy'.) Martin Thanking you bhargav ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hacking at Random: Dutch outdoor technology-conference
Eric Blossom wrote: FYI, These outdoor European hacker get-togethers are a fabulous time! I highly recommend them! August 13-16, near Vierhouten, NL. https://har2009.org https://wiki.har2009.org/page/Main_Page Eric I can also highly recommend it. HAR2009 is the followup on What-The-Hack 2005 which was a great success. If you get your tickets now, you can still get a big early-order discount. I will be there, together with Pascal Schiks, a new Dutch GnuRadio contributor. Maybe we can setup a GnuRadio village. Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: OpenBTS compilation error
Jane Chen wrote: Hi, I also encountered the same errors. USRPDevice.h:42: error: ‘usrp_standard_rx_sptr’ does not name a type USRPDevice.h:43: error: ‘usrp_standard_tx_sptr’ does not name a type Where can I get the attached patch??? It was in my original reply: Here you have the complete patch inline: cut from here Index: Transceiver/USRPDevice.h === --- Transceiver/USRPDevice.h(revision 10235) +++ Transceiver/USRPDevice.h(working copy) @@ -19,8 +19,8 @@ */ +#define HAVE_BYTESWAP_H - #include usrp_standard.h #include usrp_bytesex.h #include usrp_prims.h to here Greetings, Martin Thank you, Jane Martin Dvh wrote: T. W. wrote: Windows XP machine. .deps/radioInterface.Tpo -c .libs/radioInterface.o In file included from USRPDevice.h:25, from radioInterface.h:25, from radioInterface.cpp:23: /usr/local/include/usrp_bytesex.h:37:2: warning: #warning Using non-portable cod e (likely wrong other than ILP32). This is a known bug. A temporary workaround can be done by using attached patch. See description below. Martin DvH wrote: I haven't gotten to implementing the configure stuff yet. This patch should be changed to use configure stuff to check for byteswap.h. But for people wanting a quick-and-dirty hack it can be used. Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OpenBTS compilation error
T. W. wrote: First I got the openBTS code from gnuradio site (svn co http://gnuradio.org/svn/openbts/trunk/ openbts). Then I run the ./bootstrap and ./configure commands succesfully. But the following errors occurred when I run make. ( was used to mask out my username on the machine.) Can anyone shed some light on this? I was using a 32-bit Ubuntu 8.10 desktop virtual machine on a 64-bit Windows XP machine. Thanks! make[2]: Entering directory `/home//openbts/openbts/Transceiver' if /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I. . -I../CommonLibs -I../Control -I../GSM -I../SIP -I../TRXManager -I/usr/local/i nclude -g -O2 -MT radioInterface.lo -MD -MP -MF .deps/radioInterface.Tpo -c -o radioInterface.lo radioInterface.cpp; \ then mv -f .deps/radioInterface.Tpo .deps/radioInterface.Plo; else r m -f .deps/radioInterface.Tpo; exit 1; fi libtool: compile: g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../CommonLibs -I../Control -I../GSM -I../SIP -I../TRXManager -I/usr/local/include -g -O2 -MT radioInterfac e.lo -MD -MP -MF .deps/radioInterface.Tpo -c radioInterface.cpp -fPIC -DPIC -o .libs/radioInterface.o In file included from USRPDevice.h:25, from radioInterface.h:25, from radioInterface.cpp:23: /usr/local/include/usrp_bytesex.h:37:2: warning: #warning Using non-portable cod e (likely wrong other than ILP32). This is a known bug. A temporary workaround can be done by using attached patch. See description below. Martin DvH wrote: HAVE_BYTESWAP_H is not defined in Transceiver/USRPDevice.h This forces usrp_bytesex.h in using its own byteswap code which does NOT work on 64 bit systems. The disadvantage of putting #define HAVE_BYTESWAP_H in USRPDevice.h is that it should be checked first that you actually have byteswap.h. This should be done by the configure script and put into config.h. USRPDevice.h then should include config.h I haven't gotten to implementing the configure stuff yet. This patch should be changed to use configure stuff to check for byteswap.h. But for people wanting a quick-and-dirty hack it can be used. Greetings, Martin In file included from radioInterface.h:24, from radioInterface.cpp:23: sigProcLib.h:35: warning: ‘typedef’ was ignored in this declaration sigProcLib.h:45: warning: ‘typedef’ was ignored in this declaration In file included from radioInterface.h:25, from radioInterface.cpp:23: USRPDevice.h:42: error: ‘usrp_standard_rx_sptr’ does not name a type USRPDevice.h:43: error: ‘usrp_standard_tx_sptr’ does not name a type make[2]: *** [radioInterface.lo] Error 1 make[2]: Leaving directory `/home//openbts/openbts/Transceiver' -- Index: Transceiver/USRPDevice.h === --- Transceiver/USRPDevice.h (revision 10235) +++ Transceiver/USRPDevice.h (working copy) @@ -19,8 +19,8 @@ */ +#define HAVE_BYTESWAP_H - #include usrp_standard.h #include usrp_bytesex.h #include usrp_prims.h ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Pulse-doppler RADAR wind profiler project and how to bypass interpolation, DAC filtering, etc.
On Mon, 2009-02-23 at 19:43 +1100, Nick Withers wrote:
Just resending as this didn't seem to get through to the list...
Presumably I must be subscribed to post?
On Tue, 2009-02-17 at 20:37 +1100, Nick Withers wrote:
Hi all,
I'm new to GNURadio / the USRP, but am working on a project, as part of
my honours for a Bachelor of Engineering degree, to implement a
pulse-doppler RADAR wind profiler (some information at
http://nickwithers.com/usrp-wind-profiler).
If anyone's interested, perhaps doing something similar, or with tips
they can offer off the top of their noggin I'd love to hear from you :-)
I'm basing my work off Johnathan Corgan's radar-mono code (thanks
Johnathan!) and have a couple of questions I was hoping someone could
point me in the right direction with (dare say I'll be getting referred
straight to the FAQ, it's all a bit overwhelming!).
I want, if possible, to bypass the DAC's interpolation, filtering etc.
(the chief reason being to avoid the 44 MHz upper-bound on signals I can
output from it (I'm using the Basic{T|R}X boards and aiming to work
around 70 MHz), see http://www.gnuradio.org/trac/wiki/UsrpFAQ/DUC
You could also use the first mirror frequency
When the DUC is set to 44 MHz you get a signal at 44 Mhz and a mirror at
128-44=84 Mhz. (second niquist zone)
84 Mhz is as low as you can go with this setup, but maybe 84 MHz is
close enough to 70 for you to use.
(You would need a bandfilter to only keep this mirror)
Success,
Martin
(incidentally, I've done a crap job of finding supporting information in
the AD9862 data sheet)). Do I need to rewrite the C++ code (e.g.,
usrp/host/lib/legacy/usrp_standard.cc) if I want to continue to use
usrp_source_?() / usrp_sink_?() and such from Python? Any tips on how I
go about doing it? Can / should I just rewrite the DAC configuration
from within the FPGA when it's initialised?
Any tips appreciated!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re[Discuss-gnuradio] quire USRP1 / USRP2 ASAP
Martin DvH wrote: On Tue, 2009-02-03 at 10:38 -0800, chitlas wrote: Hi, Please let me know from where I can purchase USRP1 / USRP2 as I see that USRP2 is due for release (beta is no longer available) and USRP1 is out of stock till Feb end or so from ETTUS's site. Thanks in advance. Regds/Sudhir. My company Olifantasia is the European USRP distributor. I made a small but important typo here. Olifantasia is an European USRP reseller. Being the European USRP distributor would mean something quite different. I hope this clears things up, Regards, Martin You can buy USRPs at my website: English site: http://www.olifantasia.com/cms/en#USRP Dutch site: http://www.olifantasia.com/cms/nl#USRP Olifantasia has still several USRPs and daughterboards in stock. Regards, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple Broadcast FM Receiver
Muhammad Abrar wrote:
Now I run this program n my Laptop on whicg gnuradi 3.0.4-2ubuntu2 is
installed and i get following message.
muhammadab...@ubuntu:~/Documents/usrp$ python usrp_wfm_rcv_pll.py
gr_fir_ccf: using SSE
gr_fir_fff: using SSE
gr_fir_fcc: using SSE
audio_alsa_sink[hw:0,0]: unable to support sampling rate 32000
card requested 44100 instead.
FYI: This implementation of the stereo_carrier_pll_recovery has no
squelch implementation yet
FYI: No Powermate or Contour Knob found
FYI: This implementation of the stereo_carrier_pll_recovery has no
squelch implementation yet
auauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauauaumuhammadab...@ubuntu:~/Documents/usrp$
audio_alsa_sink[hw:0,0]: unable to support sampling rate 32000
card requested 44100 instead.
This means the your audio_card does not support 32000 Hz samplerate.
So you get Audio Underruns (aU)
This can be solved by using the commandline parameter
-O plughw:0,0
This will use the alsa software resampler to resample the 32000 to 44100
Please use reply-to-all when using the mailinglist.
Now I was the only one who got your reply, and not the mailinglist.
Greetings,
Martin
2009/1/27 Martin DvH gnuradiom...@olifantasia.com
mailto:gnuradiom...@olifantasia.com
On Mon, 2009-01-26 at 17:04 +1300, Muhammad Abrar wrote:
when i run this program ithe following ewrror appears, how can i
resolve this.
Nameerror: microtune_eval_board is not defined at line 70:
#!/usr/bin/env python
# simple broadcast FM receiver
from GnuRadio import *
#
# return a gr_FlowGraph
#
def build_graph (IF_freq):
input_rate = 20e6
CFIR_decimate = 125
RFIR_decimate = 5
fm_demod_gain = 2200
quad_rate = input_rate / CFIR_decimate
audio_rate = quad_rate / RFIR_decimate
volume = 1.0
src = GrHighSpeedADCSourceS (input_rate)
# compute FIR filter taps for channel selection
channel_coeffs = \
gr_firdes.low_pass (
1.0, # gain
input_rate, # sampling rate
250e3,# low pass cutoff freq
8*100e3, # width of trans. band
gr_firdes.WIN_HAMMING)
# input: short; output: complex
chan_filter = \
GrFreqXlatingFIRfilterSCF (CFIR_decimate,
channel_coeffs,
IF_freq)
# input: complex; output: float
fm_demod = \
GrQuadratureDemodCF (volume * fm_demod_gain)
# compute FIR filter taps for audio filter
width_of_transition_band = audio_rate / 32
audio_coeffs = \
gr_firdes.low_pass (
1.0,# gain
quad_rate, # sampling rate
audio_rate/2 - width_of_transition_band,
width_of_transition_band,
gr_firdes.WIN_HAMMING)
# input: float; output: short
audio_filter = \
GrFIRfilterFSF (RFIR_decimate, audio_coeffs)
final_sink = GrAudioSinkS ()
fg = gr_FlowGraph ()
fg.connect (src, chan_filter)
fg.connect (chan_filter, fm_demod)
fg.connect (fm_demod, audio_filter)
fg.connect (audio_filter, final_sink)
return fg
if __name__ == '__main__':
# connect to RF front end
rf_front_end = microtune_eval_board ()
if not rf_front_end.board_present_p ():
raise IOError, 'RF front end not found'
# set gain and radio station frequency
rf_front_end.set_AGC (300)
rf_front_end.set_RF_freq (100.1e6)
IF_freq = rf_front_end.get_output_freq ()
fg = build_graph (IF_freq)
fg.start ()# fork thread(s) and return
raw_input ('Press Enter to quit: ')
fg.stop ()
You are using a very very old version of gnuradio.
Please update to the current tarball or svn code:
http://gnuradio.org/trac/wiki/Download
http://gnuradio.org/trac/wiki/GettingStarted
Greetings,
Martin
--
Engr. Muhammad Abrar
NewZealand
Mob: 0064211204202
Res: 006463586340
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Engr. Muhammad Abrar
Massey University Palmerston North
NewZealand
Mob: 0064211204202
Res: 006463586340
Re: [Discuss-gnuradio] GNU Radio server broken?
Johnathan Corgan wrote: The gnuradio.org site is back up, though we will require another period of downtime in the next day or so. Please let us know if you find anything out of the ordinary. We are now running Apache 2.2, Trac 0.10.4, and Subversion 1.4.6, and planning a further upgrade to Trac 0.11 and Subversion 1.5 soon. Johnathan Corgan Corgan Enterprises LLC http://gnuradio.org/trac gives me Trac detected an internal error: If you think this really should work and you can reproduce it, you should consider reporting this problem to the Trac team. Go to http://trac.edgewall.org/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the Python traceback found below. TracGuide — The Trac User and Administration Guide Python Traceback Traceback (most recent call last): File /var/lib/python-support/python2.5/trac/web/main.py, line 406, in dispatch_request dispatcher.dispatch(req) File /var/lib/python-support/python2.5/trac/web/main.py, line 243, in dispatch req.session.save() File /var/lib/python-support/python2.5/trac/web/session.py, line 210, in save db.commit() OperationalError: database is locked ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re[Discuss-gnuradio] quire USRP1 / USRP2 ASAP
On Tue, 2009-02-03 at 10:38 -0800, chitlas wrote: Hi, Please let me know from where I can purchase USRP1 / USRP2 as I see that USRP2 is due for release (beta is no longer available) and USRP1 is out of stock till Feb end or so from ETTUS's site. Thanks in advance. Regds/Sudhir. My company Olifantasia is the European USRP distributor. You can buy USRPs at my website: English site: http://www.olifantasia.com/cms/en#USRP Dutch site: http://www.olifantasia.com/cms/nl#USRP Olifantasia has still several USRPs and daughterboards in stock. Regards, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: SVN Revisions and GSSM-
On Wed, 2009-01-28 at 11:26 +0100, José Carlos Reyes wrote: OK. I have just installed that recommended revision. But when I am installing GSSM in the step 5, I type sudo /usr/local/bin/mktun gsm. It gives me the following error: w...@wsn-desktop:~$ sudo /usr/local/bin/mktun gsm /usr/local/bin/mktun: error while loading shared libraries: libgruel.so.0: cannot open shared object file: No such file or directory This looks like mktun is compiled/linked to the latest version of gnuradio in stead of the recommended version. Make sure only the recommended version of gnuradio is installed. That means, uninstalling all previous versions you have installed cleaning your gnuradio buildtree configuring and building the gnuradio buildtree installing the gnuradio buildtree example: cd gnuradio-recommendedversion sudo make uninstall make clean make distclean ./bootstrap ./configure make sudo make install After that uninstall the gssm buildtree clean the gssm buildtree build the gssm buildtree install the gssm buildtree example: cd gssm make uninstall make clean ./configure make sudo make install Is there any solution? Can help me anyone that have installed GSSM? I would like to test GSSM. I haven't installed GSSM, but following standard procedures should work. Greetings, Martin Thanks ever so much. Jose Carlos 2009/1/28 José Carlos Reyes jcreyesguerr...@gmail.com Hi all, I would like to test GSSM, so I want to download the revision 5220 of GNU Radio. Is it possible? How? Thanks in advance. Sicerely, Jose Carlos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple Broadcast FM Receiver
On Mon, 2009-01-26 at 17:04 +1300, Muhammad Abrar wrote:
when i run this program ithe following ewrror appears, how can i resolve this.
Nameerror: microtune_eval_board is not defined at line 70:
#!/usr/bin/env python
# simple broadcast FM receiver
from GnuRadio import *
#
# return a gr_FlowGraph
#
def build_graph (IF_freq):
input_rate = 20e6
CFIR_decimate = 125
RFIR_decimate = 5
fm_demod_gain = 2200
quad_rate = input_rate / CFIR_decimate
audio_rate = quad_rate / RFIR_decimate
volume = 1.0
src = GrHighSpeedADCSourceS (input_rate)
# compute FIR filter taps for channel selection
channel_coeffs = \
gr_firdes.low_pass (
1.0, # gain
input_rate, # sampling rate
250e3,# low pass cutoff freq
8*100e3, # width of trans. band
gr_firdes.WIN_HAMMING)
# input: short; output: complex
chan_filter = \
GrFreqXlatingFIRfilterSCF (CFIR_decimate,
channel_coeffs,
IF_freq)
# input: complex; output: float
fm_demod = \
GrQuadratureDemodCF (volume * fm_demod_gain)
# compute FIR filter taps for audio filter
width_of_transition_band = audio_rate / 32
audio_coeffs = \
gr_firdes.low_pass (
1.0,# gain
quad_rate, # sampling rate
audio_rate/2 - width_of_transition_band,
width_of_transition_band,
gr_firdes.WIN_HAMMING)
# input: float; output: short
audio_filter = \
GrFIRfilterFSF (RFIR_decimate, audio_coeffs)
final_sink = GrAudioSinkS ()
fg = gr_FlowGraph ()
fg.connect (src, chan_filter)
fg.connect (chan_filter, fm_demod)
fg.connect (fm_demod, audio_filter)
fg.connect (audio_filter, final_sink)
return fg
if __name__ == '__main__':
# connect to RF front end
rf_front_end = microtune_eval_board ()
if not rf_front_end.board_present_p ():
raise IOError, 'RF front end not found'
# set gain and radio station frequency
rf_front_end.set_AGC (300)
rf_front_end.set_RF_freq (100.1e6)
IF_freq = rf_front_end.get_output_freq ()
fg = build_graph (IF_freq)
fg.start ()# fork thread(s) and return
raw_input ('Press Enter to quit: ')
fg.stop ()
You are using a very very old version of gnuradio.
Please update to the current tarball or svn code:
http://gnuradio.org/trac/wiki/Download
http://gnuradio.org/trac/wiki/GettingStarted
Greetings,
Martin
--
Engr. Muhammad Abrar
NewZealand
Mob: 0064211204202
Res: 006463586340
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: GNU-Radio GUI applications freeze
On Mon, 2009-01-26 at 10:56 +, feldmaus wrote: Raul Siles raul.siles at gmail.com writes: Hello, I'm running GNU-Radio 3.1.3 under Fedora 8 (fully updated) with USRP and all the USRP graphical (GUI) applications freeze, such as usrp_oscope.py or usrp_fft.py. The application, eg. usrp_oscope.py, main window is displayed but only the signal diagram is visible and changes. All the controls and buttons are not available. Sporadically the whole window, signal diagram plus controls, is displayed but it is not possible to interact with or adjust any control. Hi, i have the same Problems on Suse 11.1 and gnuradio 3.1svn. I solved it by executing grc with: $nice -n 19 grc Regards Markus The fft and/or scopedisplay is needing more processing power then your CPU has (your computer is too slow for the settings you are using) A better solution is to restrict the maximum processing power the scope and/or fft uses. You can change the defaults in /usr/local/etc/gnuradio/conf.d/gr-wxgui.conf Change: # fftsink and waterfallsink fft_rate = 15 # scopesink frame_decim = 1 into something like: # fftsink and waterfallsink fft_rate = 5 # scopesink frame_decim = 10 Important: don't put any comments after the numbers. Greetings, Martin Dudok van Heel Olifantasia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: GNU Radio GPGPU WIP Branch Status?
/runtime
(mainly gr_vmcircbuf.cc, but also see gr_flat_flowgraph,
gr_single_threaded_scheduler)
All gr-cuda blocks would then inherit form gr-block-cuda.
One of the things I thought of, but is not implemented but in the code
is the use of GR_BUFFER_EXTERNAL_BLOCK_HAS_ITS_OWN_FACTORY
(see gr_flat_flowgraph.cc)
There are few things that would really make the cuda code faster
1. increase computational intensity (discussed above)
This will definitely give a major performance boost
2. tune the instantiation of the kernels. (number of kernels run in
parallel, calculation of num_blocks, num_iterations,
num_threads_per_block)
Also check the memory accesses and local memory use (read CUDA
documentation, this is a complex subject)
2. eliminate the circular buffer emulation entirely.
This way each cuda block has to make sure it reads and writes to the
right memory location.
If the size of the buffer is a power of two this could be done by
masking the indexes like this.
pseudocode:
unsigned mask=bufsize-1;//bufsize needs to be power of two.
for (unsigned int i = thread_id; i size; i += num_threads)
{
outbuf[i mask] = inbuf[i mask]
}
Note that this adds computations and eliminates copying.
Benchmarking should be done to see what is faster in which
circumstances.
3. improve the FIR filter block, it is not optimal (especially when
using decimation) and it can't run with large numbers of taps or large
decimation factor.
4. automatically or manually combine the code of several sequential
blocks in a flow-graph so they end up in a single kernel.
This is no easy task but would eliminate a lot of the call overhead.
5. totally different approach. Run several flowgraphs in parallel in
stead of trying to parallellise the code inside a block.
For example, run 32 FM receivers, by giving every block 32 inputs and 32
outputs in stead of one.
A similar approuch could be used when a generic block is used multiple
times in the same flowgraph.
(a flowgraph usually has several multiply blocks and FIR filters)
example kernel code which does not need a circular buffer:
__global__ void cudai_multiply_cc_kernel(gr_complex* g_odata, const
gr_complex* g_idata_a, const gr_complex* g_idata_b, const unsigned int
size, const unsigned bufsize)
{
const unsigned int num_threads = blockDim.x * gridDim.x;
const unsigned int thread_id = blockIdx.x * blockDim.x +
threadIdx.x;
gr_complex product;
unsigned it memmask = bufsize-1;//bufsize must be power of two
for (unsigned int i = thread_id; i size; i += num_threads)
{
//complex multiply
//(a.x+ja.y)(b.x+jb.y)=(a.x*b.x-a.y*b.y) +j(a.x*b.y +a.y*b.x)
product.x = g_idata_a[i memmask].x * g_idata_b[i memmask].x -
g_idata_a[i memmask].y * g_idata_b[i memmask].y;
product.y = g_idata_a[i memmask].x * g_idata_b[i memmask].y +
g_idata_a[i memmask].y * g_idata_b[i memmask].x;
g_odata[i memmask]=product;
}
}
void
cudai_multiply_cc (gr_complex *device_output, const gr_complex *
device_input_a, const gr_complex * device_input_b,unsigned int n,
cudai_general_kernel_params *params)
{
cudai_general_kernel_params tmp_params;
if(NULL==params)
{
params=tmp_params;
cudai_get_general_kernel_params ( params, n);
}
LOCAL_CUDA_SYNC( cudai_multiply_cc );
cudai_multiply_cc_kernel params-griddim, params-threaddim,
params-dynamic_shared_mem_size
(device_output,device_input_a,device_input_b,
n);
}
I'm wondering if you can elaborate on (A) and (C) above [(B) I
understand]. Do you anticipate these changes to be simple / straight
forward? What specific changes do you believe would increase this
branch's performance?
Success,
Martin
Discussion about getting CUDA code in gnuradio-core between my and Eric
Blossom.
Forwarded Message
From: Martin DvH gnuradiom...@olifantasia.com
To: Eric Blossom e...@comsec.com
Cc: Johnathan Corgan jcor...@corganenterprises.com
Subject: Re: [Commit-gnuradio] r9522 - in
gnuradio/branches/developers/nldudok1/gpgpu-wip: .
gnuradio-core/src/lib/runtime testbed
Date: Thu, 20 Nov 2008 01:17:22 +0100
On Sun, 2008-09-07 at 13:08 -0700, Eric Blossom wrote:
On Sun, Sep 07, 2008 at 01:41:44PM -0600, nldud...@gnuradio.org wrote:
Author: nldudok1
Date: 2008-09-07 13:41:42 -0600 (Sun, 07 Sep 2008)
New Revision: 9522
Added:
gnuradio/branches/developers/nldudok1/gpgpu-wip/testbed/
gnuradio/branches/developers/nldudok1/gpgpu-wip/testbed/cuda_test_dial_tone.py
gnuradio/branches/developers/nldudok1/gpgpu-wip/testbed/cuda_test_dial_tone_wav.py
gnuradio/branches/developers/nldudok1/gpgpu-wip/testbed/cuda_test_vector.py
gnuradio/branches/developers/nldudok1/gpgpu-wip/testbed
[Discuss-gnuradio] Re: Openbts patches
On Mon, 2009-01-19 at 22:37 -0800, Johnathan Corgan wrote: On Mon, Jan 19, 2009 at 2:22 PM, Martin DvH gnuradiom...@olifantasia.com wrote: The first bug prevents the OpenBTS tranceiver from starting with the error make failed on Rx The check on line 173 in USRPDevice should be for !m_uRx in stead of ! m_uTx Thanks for catching this, this was a bug I introduced when changing the code to work with the new daughterboard API. I get it. I checked the new daughterboard API changes and it looks good to me. So in theory it should be possible to setup an OpenBts system with the current code. I am at the moment still struggling to get the IMSI code out of my phone/SIM. I have several old nokia phones (5110, 6150, 3410) , but so far I haven't been able to get one of them to into field mode. Using either keycode (*3001#12345#) or serial data-cable + gnokii. I've checked it in. patch2 should be changed to use configure stuff to check for byteswap.h. But for people wanting a quick-and-dirty hack it can be used. Let me know if you do a configure update for this, but I'd like to look at it before it is committed. I will have a look at it. Further development/testing from me on this will stall for a short time until my new stock of RFX1800 USRP daughterboards arrive. (I am totally sold-out on these) Martin -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Extracting intermediate data
On Tue, 2009-01-20 at 15:33 -0500, Catalin Lacatus wrote: Hello, I am working with usrp_spectrum_sense.py and I am trying to analyze the intermediate data from different DSP blocks. After I passed the input stream to a vector I tried to save this information on a file like this: /s2v = gr.stream_to_vector(gr.sizeof_gr_complex, self.fft_size) output2=gr.file_sink(gr.sizeof_gr_complex,file2.txt) self.connect(self.u, s2v, output2)/ You should have written output2=gr.file_sink(gr.sizeof_gr_complex*self.fft_size,file2.txt) You are now getting vectors of 128 complex values as one item. Success, Martin and I received the following error: /node1-2:~/gnuradio/gnuradio-examples/python/usrp# ./usrp_spectrum_sense.py -F 16 4.5M 7.5M Using RX d'board A: Basic Rx Traceback (most recent call last): File ./usrp_spectrum_sense.py, line 305, in module tb = my_top_block() File ./usrp_spectrum_sense.py, line 179, in __init__ self.connect(self.u, s2v, output2) File /usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py, line 70, in connect self._connect(points[i-1], points[i]) File /usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py, line 76, in _connect dst_block.basic_block(), dst_port) File /usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1469, in connect return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(*args) ValueError: itemsize mismatch: stream_to_vector(4):0 using 128, file_sink(5):0 using 8/ / / It seems to be a format mismatch. Please any advice how to write the output of s2v to a file. Thank you, Catalin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Openbts patches
Hi,
I have been working with OpenBTS in trying to get it to compile and
found two bugs and solved them.
The first bug prevents the OpenBTS tranceiver from starting with the
error make failed on Rx
The check on line 173 in USRPDevice should be for !m_uRx in stead of !
m_uTx
The second is that HAVE_BYTESWAP_H is not defined in
Transceiver/USRPDevice.h
This forces usrp_bytesex.h in using its own byteswap code which does NOT
work on 64 bit systems.
The disadvantage of putting #define HAVE_BYTESWAP_H in USRPDevice.h is
that it should be checked first that you actually have byteswap.h.
This should be done by the configure script and put into config.h.
USRPDevice.h then should include config.h
I haven't gotten to implementing the configure stuff yet.
Attached are two mini-patches which implement the changes.
I think patch1 can be submitted to svn right away (Jonathan, I could do
that, should I ?)
patch2 should be changed to use configure stuff to check for byteswap.h.
But for people wanting a quick-and-dirty hack it can be used.
I am not sure if there are more bugs in openbts in gnuradio.
I still get a lot of messages when I start it all up.
1232403472.992511 1085643088: RadioResource.cpp:347 Pager blocking for
signal
1232403472.992521 1085643088: RadioResource.cpp:347 Pager blocking for
signal
1232403472.992530 1085643088: RadioResource.cpp:347 Pager blocking for
signal
Repeats until infinity
I am not sure if this is an error or normal behaviour.
As it is in gnuradio svn, it could not have worked.
Did anyone try/test and got the gnuradio version to work.
Greetings,
Martin
Index: Transceiver/USRPDevice.cpp
===
--- Transceiver/USRPDevice.cpp (revision 10235)
+++ Transceiver/USRPDevice.cpp (working copy)
@@ -170,7 +170,7 @@
}
}
- if (!m_uTx) {
+ if (!m_uRx) {
COUT(make failed on Rx);
return false;
}
Index: Transceiver/USRPDevice.h
===
--- Transceiver/USRPDevice.h (revision 10235)
+++ Transceiver/USRPDevice.h (working copy)
@@ -19,8 +19,8 @@
*/
+#define HAVE_BYTESWAP_H
-
#include usrp_standard.h
#include usrp_bytesex.h
#include usrp_prims.h
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] preferences in conf.d issues
Hi All, I have been struggling with the strange behaviour of the configuration files in /usr/local/etc/gnuradio/conf.d This is the place where the following files with gnuradio user preferences live: gnuradio-core.conf gr-audio-jack.conf gr-wxgui.conf gr-audio-alsa.conf gr-audio-oss.conf WHen trying some settings out, I backuped the original file gr-wxgui.conf to gr-wxgui.conf.orig and changed settings in gr-wxgui.conf Whatever I filled in, the old values where still used. It took me a while to find out that the filenames aren't even looked at. They are all read in by gnuradio/gr/prefs.py with the following code: def _sys_prefs_filenames(self): dir = _sys_prefs_dirname() try: fnames = os.listdir(dir) except (IOError, OSError): return [] fnames.sort() return [os.path.join(dir, f) for f in fnames] def _read_files(self): filenames = self._sys_prefs_filenames() filenames.append(_user_prefs_filename()) #print filenames: , filenames self.cp.read(filenames) What this comes down to that ALL files in conf.d are read in in alphabetical order. The last file read in overrides all values from the previous files. I don't know if this is documented somewhere, but it is something to be aware about. Don't make backup copies in conf.d But that is not all. I had already found out previously that the inline comments in the pref files prevent the settings from being read. For example in gr-wxgui.conf is: [wxgui] style = auto # 'gl', 'nongl', or 'auto' fft_rate = 10 # fftsink and waterfallsink frame_decim = 1 # scopesink The value the code gets for fft_rate is then: 10 # fftsink and waterfallsink This gives an error because the code expects only a number. 10 Because of the error the build-in default of 15 will still be used. What would work is the following: #style = auto #'gl', 'nongl', or 'auto' #fft_rate = 15#fftsink and waterfallsink #frame_decim = 1 # scopesink [wxgui] style = auto fft_rate = 10 frame_decim = 1 The uncommented lines before [wxgui] function only as documentation The lines after [wxgui] are the actual settings, no #comments allowed. The same problems are in gr-audio-alsa.conf and maybe others Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-howto-write-a-block seems broken, anybody working on it.
Hi, gr-howto-write-a-block seems broken. When I try to bootstrap ./configure make Making all in lib make[3]: Entering directory `/pub/projects/gnuradio/svn/trunk/gr-howto-write-a-block/src/lib' /usr/bin/swig -c++ -fvirtual -python -modern -I/usr/local/include/gnuradio/swig -I/usr/local/include/gnuradio -module howto -o howto.cc ../../src/lib/howto.i /usr/local/include/gnuradio/swig/gr_realtime.i:3: Error: Unable to find 'gruel/realtime.h' make[3]: *** [howto.cc] Error 1 This seems to be due to gr-howto-write-a-block/Makefile.common: SWIGGRFLAGS = -I$(GNURADIO_CORE_INCLUDEDIR)/swig -I $(GNURADIO_CORE_INCLUDEDIR) When you add $(GNURADIO_CORE_CPPFLAGS) to it, it builds. SWIGGRFLAGS = -I$(GNURADIO_CORE_INCLUDEDIR)/swig -I $(GNURADIO_CORE_INCLUDEDIR) $(GNURADIO_CORE_CPPFLAGS) So I could commit this and everything seems OK again. But the build infrastructure gr-howto-write-a-block drifts more and more apart from the main buildtree. For example, the main gnuradio tree doesn't seem to use SWIGGRFLAGS anymore (It is not in Makefile.common of the top sourcetree) It might be a good idea to get things like Makefile.common, config/*.m4 and configure.ac updated and more in sync with the main tree. gr-howto-write-a-block is not a main priority for me, but it might be confusing for new users if it works very different from the rest. Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: gr-howto-write-a-block seems broken, anybody working on it.
On Mon, 2008-12-08 at 14:51 -0800, Johnathan Corgan wrote: On Mon, Dec 8, 2008 at 2:34 PM, Johnathan Corgan [EMAIL PROTECTED] wrote: /usr/local/include/gnuradio/swig/gr_realtime.i:3: Error: Unable to find 'gruel/realtime.h' This should have been fixed in a fairly recent version of the trunk, without needing any change to the gr-howto code, but I'll go check it out. Thanks for bringing attention to it. This was fixed in r9920 back on November 3. The current svn gr-howto-write-a-block compiles fine. I did a svn diff -r HEAD But didn't see it. Must have looked with my eyes closed. (It is there) Thanks, Martin -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio and CUDA
cuda_block.cubin #$ fatbin --key=6b4cfc7a7afd183d --source-name=cuda_block.cu --usage-mode= --embedded-fatbin=cuda_block.fatbin.c --image=profile=sm_10,file=cuda_block.cubin #$ cudafe++ --m32 --gnu_version=40102 --diag_error=host_device_limited_call --dep_name --gen_c_file_name cuda_block.cudafe1.cpp --stub_file_name cuda_block.cudafe1.stub.c --stub_header_file_name cuda_block.cudafe1.stub.h cuda_block.cpp1.ii #$ gcc -D__CUDA_ARCH__=100 -E -x c++ -DCUDA_NO_SM_13_DOUBLE_INTRINSICS -DCUDA_NO_SM_12_ATOMIC_INTRINSICS -DCUDA_NO_SM_11_ATOMIC_INTRINSICS -DCUDA_FLOAT_MATH_FUNCTIONS -I/usr/local/cuda/bin/../include -I/usr/local/cuda/bin/../include/cudart -I. -fPIC -I. -IUDASDK/common/inc -D_DEBUG -m32 -malign-double -g -o cuda_block.cu.cpp cuda_block.cudafe1.cpp #$ gcc -D__CUDA_ARCH__=100 -c -x c++ -DCUDA_NO_SM_13_DOUBLE_INTRINSICS -DCUDA_NO_SM_12_ATOMIC_INTRINSICS -DCUDA_NO_SM_11_ATOMIC_INTRINSICS -DCUDA_FLOAT_MATH_FUNCTIONS -I/usr/local/cuda/bin/../include -I/usr/local/cuda/bin/../include/cudart -I. -fPIC -I. -IUDASDK/common/inc -D_DEBUG -m32 -malign-double -g -o .libs/cuda_block.o cuda_block.cu.cpp /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverloaded-virtual -pthread -module -avoid-version -o _howto.la -rpath /usr/local/lib/python2.5/site-packages/gnuradio howto.lo howto_square_ff.lo howto_square2_ff.lo cuda_block.lo -lstdc++ -L/usr/local/lib -lgnuradio-core -lgromnithread -lfftw3f -lm libtool: link: rm -fr .libs/_howto.la .libs/_howto.lai .libs/_howto.so libtool: link: g++ -shared -nostdlib /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crti.o /usr/lib/gcc/i386-redhat-linux/4.1.2/crtbeginS.o .libs/howto.o .libs/howto_square_ff.o .libs/howto_square2_ff.o .libs/cuda_block.o -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib -L/usr/local/lib /usr/local/lib/libgnuradio-core.so /usr/local/lib/libgromnithread.so -lrt /usr/local/lib/libfftw3f.so -L/usr/lib/gcc/i386-redhat-linux/4.1.2 -L/usr/lib/gcc/i386-redhat-linux/4.1.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i386-redhat-linux/4.1.2/crtendS.o /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crtn.o -pthread -pthread -Wl,-soname -Wl,_howto.so -o .libs/_howto.so libtool: link: ( cd .libs rm -f _howto.la ln -s ../_howto.la _howto.la ) make[4]: Leaving directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src/lib' make[3]: Leaving directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src/lib' Making all in python make[3]: Entering directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src/python' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src/python' make[3]: Entering directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src' make[2]: Leaving directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src' make[2]: Entering directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3' make[2]: Leaving directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3' make[1]: Leaving directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3' On Sun, Nov 16, 2008 at 2:46 PM, Martin DvH [EMAIL PROTECTED] wrote: On Fri, 2008-11-14 at 16:42 -0800, Bob Keyes wrote: I've just been given a Nvidia Quadro 5600 and I am thinking of using it for DSP. Has anyone experimented with USRP gnuradio cuda? I have been working on this for quite some time now. I did a glsl implementation a few years back but it didn't perform that well and had some severe limitations. So I started over this year and have reimplemented major part of GnuRadio using CUDA. It is a one to one implementation. (every gr_something block is replaced with a cuda_something block) My work-in-progress code is at: http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1/gpgpu-wip Make sure you read http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1/gpgpu-wip/README.cuda Caleb Phillips made a wiki about my code, you can find it at: http://www.smallwhitecube.com/php/dokuwiki/doku.php?id=howto:gnuradio-with-cuda The majority of the gnuradio-core code is a unmodified gnuradio checkout of a few moths back. There are some important changes in gnuradio_core/src/lib/runtime to support CUDA device memory as an emulated circular buffer. I also implemented a gr.check_compare block which expects two input streams and checks if they are outputting the same data. I use this to check if my cuda blocks do exactly the same as the gr blocks. All the rest of the CUDA code is in gr_cuda. gr_cuda has to be configured and build seperately. gr_cuda is where the cuda reimplementations of some gnuradio blocks
Re: [Discuss-gnuradio] GPU progress?
On Sat, 2008-11-15 at 10:30 -0500, Marcus D. Leech wrote: What is the current status of GPU support in Gnu Radio? In particular, a GPUed FFT implementation would be peachy keen. I have been working on this for quite some time now. I did a glsl implementation a few years back but it didn't perform that well and had some severe limitations. So I started over this year and have reimplemented major part of GnuRadio using CUDA. It is a one to one implementation. (every gr_something block is replaced with a cuda_something block) My work-in-progress code is at: http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1/gpgpu-wip Make sure you read http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1/gpgpu-wip/README.cuda Caleb Phillips made a wiki about my code, you can find it at: http://www.smallwhitecube.com/php/dokuwiki/doku.php?id=howto:gnuradio-with-cuda The majority of the gnuradio-core code is a unmodified gnuradio checkout of a few moths back. There are some important changes in gnuradio_core/src/lib/runtime to support CUDA device memory as an emulated circular buffer. I also implemented a gr.check_compare block which expects two input streams and checks if they are outputting the same data. I use this to check if my cuda blocks do exactly the same as the gr blocks. All the rest of the CUDA code is in gr_cuda. gr_cuda has to be configured and build seperately. gr_cuda is where the cuda reimplementations of some gnuradio blocks are. Then there are also a few new blocks cuda_to_host and host_to_cuda which copy memory from and to the GPU device memory. All python scripts to test and use the code are in /testbed. The code in testbed is changing on a day-by-day basis. There are several issues to be well aware of when doing SDR on a GPU. -overhead -call overhead -copying data from and to the GPU You need to do a lot of work on the GPU in one call to have any benefit. -circular buffers -GPU memory cant't be mmapped into a circular buffer -solution 1: use copying to emulate a circular buffer -solution 2: keep track of all the processing and make your own intelligent scheduler which does not need a circular buffer. -threads: with CUDA you can't access GPU device memory from different host-threads. So make sure you create use and destroy all device memory from the same thread. (The standard GnuRadio scheduler does not do it like this) -debugging: Debugging is hard and works quite different from normal debugging. -parallel: The GPU is good in doing calculations in parallel which are not dependant on each other. For this reason a FIR will perform well, while an IIR will perform bad. An IIR can only use one processing block of the GPU, in stead of 128. It can still be benificial to do the IIR on the GPU when all your other blocks are running on the GPU because you don't have to copy all samples to the CPU, do the IIR on the CPU and copy everything back to the GPU. All that said. I do have a complete WFM receiver which is running completely on the GPU. (using FIR and/or FFT filters, quadrature_demod, fm-deemph) The FFT filters use the cuda provided FFT. It shouldn't be too hard to use the FFT for other things (just look at the code of gr_cuda/src/lib/cuda_fft_*) At the moment the complete wfm receiver is not running faster then on the CPU with my 9600GT card, mainly because of the call overhead. (too little work items done per call) And the extra copying done to emulate circular buffers. I can increase the amount of work done per call by using output_multiple. But with the current scheduling code the flow-graph can hang. This needs work. So the performance will change in the future. First I want to make sure everything is working as expected. If I benchmark a single block with a big output_multiple then I do see performance increases. Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter
On Tue, 2008-11-11 at 08:26 +0100, Vincenzo Pellegrini wrote: Martin , sorry for the delay. My exams seem to have gone well even if it's not official yet. Great I also had to do a demo for a company I have a temporary contract with for developing some gnuradio based gsm-r security sentinels. Also the demo was smooth. (i already listed the project on the gnuradio wiki) Good work. so i really hope i'll be able to prepare the 8Mhz stream for you within the next 2/3 days. Would this still be useful? Yes it really would. I am also really looking forward for the sources. One of the things I am planning to do is use the structure of your code as a basis for a DVB-T receiver. It is always easier debugging a receiver when you can make a full loop. (transmitter and receiver back-to-back) Greetings, Martin 2008/11/3, Martin DvH [EMAIL PROTECTED]: On Mon, 2008-11-03 at 14:13 +0100, Martin DvH wrote: Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Vincenzo Pellegrini Verzonden: maandag 3 november 2008 0:16 Aan: Martin DvH CC: discuss-gnuradio Onderwerp: [Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter This is Great... :) Yup, the playback cannot be smooth because of the wrong throughput, definitely. Did you use the USRP1 with interpolation factor = 16 ? Yes I did. I can prepare a modulated signal with the correct throughput for you.. this is not a problem... :) Please do, this would be great. what hard disc are you playing your signal back from? Internal 2.5 harddisk of my acer 6930 notebook (Aspire 6930G-734G32BN LX.AVB0X.135) 2.5 320GB HDD 5400rpm, SATA I checked now. It is a: Western digital Scorpio 320 GB SATA (WDC WD3200BEVT-22ZCT0) 2.5-inch SATA Hard Drive 320 GB, 3 Gb/s, 8 MB Cache, 5400 RPM Benchmark from tomshardware (h2benchw 3.6): http://www.tomshardware.com/charts/2-5-hard-drive-charts/Minimum-Read-Transfer-Performance,687.html minimum read transfer rate 33.5 MB/sec average read transfer rate 52.2 MB/sec maximum read transfer rate 68.2 MB/sec I am not at home right now So I can't check the exact brand and model of the harddisk. It can do around 38 MB/sec so this is just enough (required 32 MB/sec) I also have 4GB of memory in this notebook, so I think it will buffer the complete file. I had to use my notebook because with my desktop PC (ASrock 939-DUAL-SATA2) The USB TX bandwidth is less then 32 MB/sec. (Which is strange because I CAN receive 32 MB/sec) I get UuUuUu on this machine when useing interpolation 16, so unusable. Regards, Martin regards vincenzo 2008/11/3 Martin DvH [EMAIL PROTECTED] Hi, In fact: 8 complex Msps implement a 7 MHz channel while 9.142857143 complex Msps implement an 8 MHz channel. Just try to go as close as possible to such sampling frequency by using USRP2 and let me know what happens... it could turn out that we need a resampler block. So if I use a fractional rate resampler with interpolation factor 10/8=1.25 I get a 7 Mhz channel with 10 Msps samplerate. If I use a fractional rate resampler with interpolation factor 10/9.142857143=1.09375 I get a 8 Mhz channel with 10 Msps samplerate If I use a fractional rate resampler with DECIMATION factor 9.142857143/8=8/7=1.142857143 I get a 8 Mhz channel with 8 Msps samplerate with the out-of-band skirts folded back at the sides. Would be interesting to see if this last one works with a USRP1. I'll let you know how the experiments go. I resampled and scaled your ofdm_40.dump file so it now will use 8 Mhz bandwidth with a 8 Msps samplerate. The reception never can be perfect this way but it seems good enough for tests. My USB DVB-T receiver receives the transport stream without problems. Mplayer playes the stream without problem for two loops and then crashes with a broken frame. My standalone settopbox DVB-T receiver now also receives the stream. (8 MHz channel on UHF) It has big problems displaying it. Sound is only a chop of sound now and then and video stops, then runs for a second, then stops again. I think this is because the timestamps and framerate (playout speed) don't match the data throughput of the MPEG stream anymore. (It is getting the stream too fast) I put my resampled RF file at: http://www.olifantasia.com/projects/gnuradio/mdvh
Re: [Discuss-gnuradio] Any tutorials (documentation) about gr-radar-mono
On Mon, 2008-11-10 at 20:14 +0100, Bruhtesfa Ebrahim wrote: Hi Johnathan, Thank you so much for the advise that you gave me ! ! ! Could you also look at the following description and give me your comment.? - Thanks Ya! I am looking to detect human motion at a distance of minimum 1 meter and maximum 10 meter. I have one USRP and two XCVR2450 Trancievers(operating freq. 2.45GHz), which I will be using one of them as transmitter and the other as reciever. So, I have two possible ways of implemetation. 1) As pulse doppler radar = here to get a minimum distance of 1 meter, the usrp should transmit a pulse of width 5 nanosec, then should stop and the reciever should start to recieve, then to measure a velocity as high as 3m/sec, I can use PRF of 100. Here the problem is as you said the USRP can not generate such a short pulse of 5 nanosec, plus it can not switch between transmitter and reciever so fast. 2) As CW radar = here my idea is to transmit a CW from one shell script and recieve the reflected data at the same time in another shell script. Here the problem is the isolation between the transmit and recieve paths. The data I recieve will not be just a reflected data but also signal from the transmitter. This means both of the implementation ways have problem. So, what do you suggest? Just my 2 cents. I would suggest using sound in stead of radio waves. The lower speed of soundwaves (around 300 m/sec) means the timings go down with a factor 100 and you could do very precise short-range radar (actually sonar). You could still use the USRP. Just use amplifiers and ultrasonic transducers in stead of antenna's. Good luck, Martin And which one do you recommend me from your previous experience on the USRP? Also Mr. Lee Pathon, the Author of GNU based Software Defined Radar , I know you worked on such stuff , could you give me some comment based on your work? - Thanks Bruhtesfa On Mon, Nov 10, 2008 at 4:45 PM, Johnathan Corgan [EMAIL PROTECTED] wrote: On Mon, 2008-11-10 at 16:39 +0100, Bruhtesfa Ebrahim wrote: Is there any tutorial (documentation) that explains in detail gr_radar_mono and other gnu radio packages? I look on GNU radio 3.0svn documentation but it has no details. is there any other that has more details? There is a README inside the directory that explains the command-line parameters. But I'll warn you ahead of time that, based on a prior email where you said you were looking at targets 10 meters away, that this software won't work for you. Without going in to detail, the minimum range is about 200m, based on transmitting a long enough chirp and the time it takes to switch from TX to RX. Just FYI, however, this software was able to image targets 1.5 km away, using an RFX2400, a 3W PA, and a horn antenna. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter
Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Vincenzo Pellegrini Verzonden: maandag 3 november 2008 0:16 Aan: Martin DvH CC: discuss-gnuradio Onderwerp: [Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter This is Great... :) Yup, the playback cannot be smooth because of the wrong throughput, definitely. Did you use the USRP1 with interpolation factor = 16 ? Yes I did. I can prepare a modulated signal with the correct throughput for you.. this is not a problem... :) Please do, this would be great. what hard disc are you playing your signal back from? Internal 2.5 harddisk of my acer 6930 notebook (Aspire 6930G-734G32BN LX.AVB0X.135) 2.5 320GB HDD 5400rpm, SATA I am not at home right now So I can't check the exact brand and model of the harddisk. It can do around 38 MB/sec so this is just enough (required 32 MB/sec) I also have 4GB of memory in this notebook, so I think it will buffer the complete file. I had to use my notebook because with my desktop PC (ASrock 939-DUAL-SATA2) The USB TX bandwidth is less then 32 MB/sec. (Which is strange because I CAN receive 32 MB/sec) I get UuUuUu on this machine when useing interpolation 16, so unusable. Regards, Martin regards vincenzo 2008/11/3 Martin DvH [EMAIL PROTECTED] Hi, In fact: 8 complex Msps implement a 7 MHz channel while 9.142857143 complex Msps implement an 8 MHz channel. Just try to go as close as possible to such sampling frequency by using USRP2 and let me know what happens... it could turn out that we need a resampler block. So if I use a fractional rate resampler with interpolation factor 10/8=1.25 I get a 7 Mhz channel with 10 Msps samplerate. If I use a fractional rate resampler with interpolation factor 10/9.142857143=1.09375 I get a 8 Mhz channel with 10 Msps samplerate If I use a fractional rate resampler with DECIMATION factor 9.142857143/8=8/7=1.142857143 I get a 8 Mhz channel with 8 Msps samplerate with the out-of-band skirts folded back at the sides. Would be interesting to see if this last one works with a USRP1. I'll let you know how the experiments go. I resampled and scaled your ofdm_40.dump file so it now will use 8 Mhz bandwidth with a 8 Msps samplerate. The reception never can be perfect this way but it seems good enough for tests. My USB DVB-T receiver receives the transport stream without problems. Mplayer playes the stream without problem for two loops and then crashes with a broken frame. My standalone settopbox DVB-T receiver now also receives the stream. (8 MHz channel on UHF) It has big problems displaying it. Sound is only a chop of sound now and then and video stops, then runs for a second, then stops again. I think this is because the timestamps and framerate (playout speed) don't match the data throughput of the MPEG stream anymore. (It is getting the stream too fast) I put my resampled RF file at: http://www.olifantasia.com/projects/gnuradio/mdvh/OTA/DVB-T/ofdm_40_bw8Mhz_s amplerate_8Msps_cshort.raw format is complex signed short integers (I 16 bit, Q 16 bit) at 8 Msamples/sec. Greetings, Martin more details will follow as soon as I find some time... Thanks and success with your second group of tests. Martin best regards and greetings to all fellow GNURadioers vincenzo PS Rafael, just have a look back a this thread and you'll find all the info you need to do your test broadcast. Thanks for your interest 2008/10/31 Martin Dudok van Heel [EMAIL PROTECTED] Hi Vincenzo. How are things going with your exams. I hope well. Thanks for your help so far
RE: [Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter
On Mon, 2008-11-03 at 14:13 +0100, Martin DvH wrote: Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Vincenzo Pellegrini Verzonden: maandag 3 november 2008 0:16 Aan: Martin DvH CC: discuss-gnuradio Onderwerp: [Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter This is Great... :) Yup, the playback cannot be smooth because of the wrong throughput, definitely. Did you use the USRP1 with interpolation factor = 16 ? Yes I did. I can prepare a modulated signal with the correct throughput for you.. this is not a problem... :) Please do, this would be great. what hard disc are you playing your signal back from? Internal 2.5 harddisk of my acer 6930 notebook (Aspire 6930G-734G32BN LX.AVB0X.135) 2.5 320GB HDD 5400rpm, SATA I checked now. It is a: Western digital Scorpio 320 GB SATA (WDC WD3200BEVT-22ZCT0) 2.5-inch SATA Hard Drive 320 GB, 3 Gb/s, 8 MB Cache, 5400 RPM Benchmark from tomshardware (h2benchw 3.6): http://www.tomshardware.com/charts/2-5-hard-drive-charts/Minimum-Read-Transfer-Performance,687.html minimum read transfer rate 33.5 MB/sec average read transfer rate 52.2 MB/sec maximum read transfer rate 68.2 MB/sec I am not at home right now So I can't check the exact brand and model of the harddisk. It can do around 38 MB/sec so this is just enough (required 32 MB/sec) I also have 4GB of memory in this notebook, so I think it will buffer the complete file. I had to use my notebook because with my desktop PC (ASrock 939-DUAL-SATA2) The USB TX bandwidth is less then 32 MB/sec. (Which is strange because I CAN receive 32 MB/sec) I get UuUuUu on this machine when useing interpolation 16, so unusable. Regards, Martin regards vincenzo 2008/11/3 Martin DvH [EMAIL PROTECTED] Hi, In fact: 8 complex Msps implement a 7 MHz channel while 9.142857143 complex Msps implement an 8 MHz channel. Just try to go as close as possible to such sampling frequency by using USRP2 and let me know what happens... it could turn out that we need a resampler block. So if I use a fractional rate resampler with interpolation factor 10/8=1.25 I get a 7 Mhz channel with 10 Msps samplerate. If I use a fractional rate resampler with interpolation factor 10/9.142857143=1.09375 I get a 8 Mhz channel with 10 Msps samplerate If I use a fractional rate resampler with DECIMATION factor 9.142857143/8=8/7=1.142857143 I get a 8 Mhz channel with 8 Msps samplerate with the out-of-band skirts folded back at the sides. Would be interesting to see if this last one works with a USRP1. I'll let you know how the experiments go. I resampled and scaled your ofdm_40.dump file so it now will use 8 Mhz bandwidth with a 8 Msps samplerate. The reception never can be perfect this way but it seems good enough for tests. My USB DVB-T receiver receives the transport stream without problems. Mplayer playes the stream without problem for two loops and then crashes with a broken frame. My standalone settopbox DVB-T receiver now also receives the stream. (8 MHz channel on UHF) It has big problems displaying it. Sound is only a chop of sound now and then and video stops, then runs for a second, then stops again. I think this is because the timestamps and framerate (playout speed) don't match the data throughput of the MPEG stream anymore. (It is getting the stream too fast) I put my resampled RF file at: http://www.olifantasia.com/projects/gnuradio/mdvh/OTA/DVB-T/ofdm_40_bw8Mhz_s amplerate_8Msps_cshort.raw format is complex signed short integers (I 16 bit, Q 16 bit) at 8 Msamples/sec. Greetings, Martin more details will follow as soon as I find some time... Thanks and success with your second group of tests. Martin best regards and greetings to all fellow GNURadioers vincenzo PS Rafael, just have a look back a this thread and you'll find all the info you need to do your test broadcast. Thanks for your interest
[Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter
Hi Vincenzo, On Sun, 2008-11-02 at 01:28 +0100, Vincenzo Pellegrini wrote: Hi Martin, sorry for the delayed replies but now I've passed my first cluster of PhD tests (went well) Congratulations. and I've got to carry out some work + preparing the second group of tests. Success. Well, really glad to know that you managed to receive my signals. Yup dvb-t sticks can actually receive 7 MHz channels everywhere, I found that some of them need special australian 7MHz at UHF firmware to get this to work. Luckily my DVB-T usb stick doesn't need this trick. Well, actually any DVB-T chipset can but typically manufacturers impose strange limitations on set-top-boxes such as 7 MHz chanels accepted only in VHF I don't really know why. The signal I provided you with is suitable for both 7 and 8 MHz channels without any modification needed. The only thing you have to do is to set your sampling frequency a bit higher. this should be possible with USRP2. The receiver might still have a problem that it is getting in the MPEG streams at a higher rate then realtime. In fact: 8 complex Msps implement a 7 MHz channel while 9.142857143 complex Msps implement an 8 MHz channel. Just try to go as close as possible to such sampling frequency by using USRP2 and let me know what happens... it could turn out that we need a resampler block. So if I use a fractional rate resampler with interpolation factor 10/8=1.25 I get a 7 Mhz channel with 10 Msps samplerate. If I use a fractional rate resampler with interpolation factor 10/9.142857143=1.09375 I get a 8 Mhz channel with 10 Msps samplerate If I use a fractional rate resampler with DECIMATION factor 9.142857143/8=8/7=1.142857143 I get a 8 Mhz channel with 8 Msps samplerate with the out-of-band skirts folded back at the sides. Would be interesting to see if this last one works with a USRP1. I'll let you know how the experiments go. more details will follow as soon as I find some time... Thanks and success with your second group of tests. Martin best regards and greetings to all fellow GNURadioers vincenzo PS Rafael, just have a look back a this thread and you'll find all the info you need to do your test broadcast. Thanks for your interest 2008/10/31 Martin Dudok van Heel [EMAIL PROTECTED] Hi Vincenzo. How are things going with your exams. I hope well. Thanks for your help so far. I finally got your DVB-T dump streams working. I first tried using an undersampled basicTX but never got it to work. (use a niquist mirror in the VHF range on channel 11 or 12 (219.5 Mhz or 226.5 Mhz)) I now use a RFX900 and that works with a pinnacle PCTV-Solo 72e usb DVB-T receiver card plugged into my PC. I use 858.0 Mhz (channel 69) I used a 10 dB attenuator on the antenna output to limit output power. I also modified the RFX900 to enable transmitting outside of the ISM band. (disable saw-filter. add 220 pF capacitor) Apparantly the pinnacle 72e can receive 7 Mhz channels on the UHF channels. My standalone settopbox DVB-T receiver can't handle it. I noticed you don't use the full possible range in your 16 bit streams. (only goes from -80 to +80 while you could use -8192 to 8192) Is this on purpose? I can multiply samples by 64 and get a cleaner signal. (But also more output power) I do have a request, I hope it is not too much work. Could you make a stream with 10 Msamples/sec samplerate and 8 Mhz wide channel. This way I can use standard standalone DVB-T receivers and don't have the 7Mhz bandwith on UHF problem. For the 10 Msps stream I would have to use my USRP2 to output it. It has a 100 Mhz DAC (in stead of 64 Msps in the USRP1) It has a gbit ethernet connection for the samples, so I can go up to 25 Msps. It can only do fixed interpolation rates so I have to choose from the table below. (8 Msamples/sec is not supported on the USRP2) USRP2 dac_rateinterp ethernet_sample_rate 100 4 25 100 5 20 100 6 16.67 100 7 14.29 100 8 12.5 100 9 11.11 100 10 10 I think 10 Msamples/sec should be optimal 100 11 9.09 100 12 8.33 100 13 7.69 100 14 7.14 I think 10 Msamples/sec would be a good candidate. Have you also tried using 8
[Discuss-gnuradio] Re: Soft-DVB DVB-T transmitter
Hi, In fact: 8 complex Msps implement a 7 MHz channel while 9.142857143 complex Msps implement an 8 MHz channel. Just try to go as close as possible to such sampling frequency by using USRP2 and let me know what happens... it could turn out that we need a resampler block. So if I use a fractional rate resampler with interpolation factor 10/8=1.25 I get a 7 Mhz channel with 10 Msps samplerate. If I use a fractional rate resampler with interpolation factor 10/9.142857143=1.09375 I get a 8 Mhz channel with 10 Msps samplerate If I use a fractional rate resampler with DECIMATION factor 9.142857143/8=8/7=1.142857143 I get a 8 Mhz channel with 8 Msps samplerate with the out-of-band skirts folded back at the sides. Would be interesting to see if this last one works with a USRP1. I'll let you know how the experiments go. I resampled and scaled your ofdm_40.dump file so it now will use 8 Mhz bandwidth with a 8 Msps samplerate. The reception never can be perfect this way but it seems good enough for tests. My USB DVB-T receiver receives the transport stream without problems. Mplayer playes the stream without problem for two loops and then crashes with a broken frame. My standalone settopbox DVB-T receiver now also receives the stream. (8 MHz channel on UHF) It has big problems displaying it. Sound is only a chop of sound now and then and video stops, then runs for a second, then stops again. I think this is because the timestamps and framerate (playout speed) don't match the data throughput of the MPEG stream anymore. (It is getting the stream too fast) I put my resampled RF file at: http://www.olifantasia.com/projects/gnuradio/mdvh/OTA/DVB-T/ofdm_40_bw8Mhz_samplerate_8Msps_cshort.raw format is complex signed short integers (I 16 bit, Q 16 bit) at 8 Msamples/sec. Greetings, Martin more details will follow as soon as I find some time... Thanks and success with your second group of tests. Martin best regards and greetings to all fellow GNURadioers vincenzo PS Rafael, just have a look back a this thread and you'll find all the info you need to do your test broadcast. Thanks for your interest 2008/10/31 Martin Dudok van Heel [EMAIL PROTECTED] Hi Vincenzo. How are things going with your exams. I hope well. Thanks for your help so far. I finally got your DVB-T dump streams working. I first tried using an undersampled basicTX but never got it to work. (use a niquist mirror in the VHF range on channel 11 or 12 (219.5 Mhz or 226.5 Mhz)) I now use a RFX900 and that works with a pinnacle PCTV-Solo 72e usb DVB-T receiver card plugged into my PC. I use 858.0 Mhz (channel 69) I used a 10 dB attenuator on the antenna output to limit output power. I also modified the RFX900 to enable transmitting outside of the ISM band. (disable saw-filter. add 220 pF capacitor) Apparantly the pinnacle 72e can receive 7 Mhz channels on the UHF channels. My standalone settopbox DVB-T receiver can't handle it. I noticed you don't use the full possible range in your 16 bit streams. (only goes from -80 to +80 while you could use -8192 to 8192) Is this on purpose? I can multiply samples by 64 and get a cleaner signal. (But also more output power) I do have a request, I hope it is not too much work. Could you make a stream with 10 Msamples/sec samplerate and 8 Mhz wide channel. This way I can use standard standalone DVB-T receivers and don't have the 7Mhz bandwith on UHF problem. For the 10 Msps stream I would have to use my USRP2 to output it. It has a 100 Mhz DAC (in stead of 64 Msps in the USRP1) It has a gbit ethernet connection for the samples, so I can go up to 25 Msps. It can only do fixed interpolation rates so I have to choose from the table below. (8 Msamples/sec is not supported on the USRP2) USRP2 dac_rateinterp ethernet_sample_rate 100 4 25 100 5 20 100 6 16.67 100 7 14.29 100 8 12.5 100 9 11.11 100 10 10 I think 10 Msamples/sec should be optimal 100 11 9.09 100 12 8.33 100 13 7.69 100 14 7.14 I think 10 Msamples/sec would be a good candidate. Have you also tried using 8
Re: [Discuss-gnuradio] Anyone using GNU Radio for doppler radar application
On Tue, 2008-10-28 at 20:15 +0100, Bruhtesfa Ebrahim wrote: Thank you Micheal ! I have installed the doxygen now using macports. By the way I am using USRP+Tx and RX daughterboards on OS X 10.5 for doppler radar application. Anyone, having experience on using GNU radio for doppler radar? or anyone who has tried it,? -Tks I have tried it a while ago for doing passive radar. This was inspired by the work done by Eric Blossom. See this abandoned code: http://gnuradio.org/trac/browser/gnuradio/limbo/gr-radar There is also a video online of a presentation by Eric Blossom about doing passive radar with gnuradio on a conference a few years back. I think it was at what-the-hack in 2005 or CCC in 2007. Greetings, Martin Bruhtesfa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 current svn code not working. Is the svn code still in flux?
Hi, The current svn code does not seem to produce correct results for me when using usrp2_fft.py I know there has been going on a lot of usrp2 work this weekend. Is the svn code still in a state of flux or should it work by now and should I check my setup. If I don't set the frequency I get a noise signal -85 dB. Setting the gain from the commandline does not seem to have any effect. usrp2_fft.py or usrp2_fftp.y -g 80 or usrp2_fft.py -g 0 I I do set the frequency using the commandline I get a nonsense signal at -120 to -180 dB. usrp2_fft.py -f 107.9e6 or usrp2_fft.py -f 107.9e6 -g 40 Until recently (before the needed firmware updates) everything worked fine. usrp2_fft.py -f 107.9e6 -g 40 used to show the spectrum of a local FM station. I use a USRP2 with a TVRX daughterboard. I do get the 2 green leds. I don't know if the problem is from (my build of) the new software firmware txrx.bin. I build on ubuntu 7.10 64 bit. Or maybe there are some changes in setting gain/frequency API which require changes in the usrp2_fft.py python script. Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: USRP2 current svn code not working. Is the svn code still in flux?
On Sun, 2008-10-26 at 07:44 -0700, Johnathan Corgan wrote: On Sun, 2008-10-26 at 15:37 +0100, Martin DvH wrote: The current svn code does not seem to produce correct results for me when using usrp2_fft.py Could you please try usrp2_rx_cfile.py and see if the results are the same? Results are the same. If I look at the capture with a hex editor I see a few non-zero numbers at the start and then only zero's I attached a bzip2-ed version of the result of usrp2_rx_cfile.py -f 107.9e6 -g 40 -N 1000 -v tmp_cfloat.raw As the compressed file is only 30 kB (uncompressed 10 MB) you can see there is definitely something wrong. Note that this is from trunk from today. I checked out your development branch too. branches/developers/jcorgan/u2-wip Should I build that and see what it does? Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio tmp_cfloat.raw.bz2 Description: application/bzip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: USRP2 current svn code not working. Is the svn code still in flux?
On Sun, 2008-10-26 at 08:33 -0700, Johnathan Corgan wrote: On Sun, 2008-10-26 at 16:27 +0100, Martin DvH wrote: I checked out your development branch too. branches/developers/jcorgan/u2-wip Should I build that and see what it does? I'm about to merge this into the trunk, so don't bother building it. But I don't expect what I've done so far to address this. Ok Can you check if varying the decimation rate (try 4, 5, 100, and 200) impacts what you are seeing? 4 noise -90 dB 5 noise -93 dB 6 noise -90 dB 7 noise -98 dB 8 noise -100 dB 9 noise -92 dB 10 noise -98 dB with small peak at -93 dB center freq (possibly my radio station) 11 noise -93 dB 12 flat -380 dB (essentially all zero's) 13 noise -95 dB 14 -105 dB erratic changing noise with sometimes a sinc curve (noise intermittand with zero's) 15 noise -100 dB zomewhat erratic 16 very irratic between -100 and -180 dB (noise intermittand with zero's) 17 same as 16 18 noise -100 dB 19 noise -98 dB 20 flatline -380 dB 21 same as 16 22 noise at -100 with small peak at center freq -93 dB same as 10 23 flatline -380 dB 24 flatline -380 dB 25 same as 16 26 same as 10 27 flatline -380 dB 28 flatline -380 dB 29 irractic flatline (flatline at different dB levels 30 same as 16 31 same as 16 32 flatline -380 dB 100 flatline -380 dB 200 flatline -380 dB This is with the old fpga firmware I am nowgoing to try the new one. Martin Also, I suspect that there might be a compatibility issue between the version of the FPGA code that was shipped on the SD card and the current trunk firmware/host code. In a separate email I will send to you another FPGA bin file to try to see if it makes a difference. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: USRP2 current svn code not working. Is the svn code still in flux?
On Sun, 2008-10-26 at 10:09 -0700, Johnathan Corgan wrote: On Sun, Oct 26, 2008 at 8:33 AM, Johnathan Corgan [EMAIL PROTECTED] wrote: Also, I suspect that there might be a compatibility issue between the version of the FPGA code that was shipped on the SD card and the current trunk firmware/host code. This has been confirmed (thanks Martin). The new fpga image in combination with the latest svn code also makes it possible to set the gain from the gui of usrp2_fft.py without crashing the app. (And the gain actually changes as can be seen by the change in signal level) Trying to set the frequency this way is not fixed. This still hangs the whole app. Greetings, Martin What this means is that people who are using already shipped USRP2s will need to update their SD card with the latest FPGA bitstream binary image in order to use the latest GNU Radio trunk code. Since creating the image requires using the commercial Xilinx ISE toolchain, we will supply the latest binary on the GNU Radio website, along with upgrade instructions. Eric and I have discussed how to address this in general terms, and once I have a chance to talk to Matt to confirm, we'll make a list posting and update the USRP2 wiki page. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: USRP2 current svn code not working. Is the svn code still in flux?
On Sun, 2008-10-26 at 14:03 -0700, Johnathan Corgan wrote: On Sun, 2008-10-26 at 21:49 +0100, Martin DvH wrote: The new fpga image in combination with the latest svn code also makes it possible to set the gain from the gui of usrp2_fft.py without crashing the app. (And the gain actually changes as can be seen by the change in signal level) Trying to set the frequency this way is not fixed. This still hangs the whole app. I've updated usrp2_fft.py on the trunk to use the latest gr-usrp2. It is working normally now with setting the USRP2 parameters via the command line, however, as you note, changing frequency doesn't work. This has been isolated to some problem in either libusrp2 or in the USRP2 firmware. Eric and I are working on this. Other commands that operate in batch mode, where you set the USRP2 parameters from the command line, are working normally now as well. When you set the decimation above 19 then you CAN set gain in the GUI. With decimation below 19, setting gain in the GUI hangs the app. Setting the freq only works from commandline. The gainrange for TVRX rev 3 comes out as 0 , 0 This triggers a python error min max ==False and the gain slider cannot be used. I saw you have a workaround for the gainrange for TVRX, probably this should also apply for TVRX rev 2 and TVRX rev 3. (Or there is something else wrong in the backend code) Following patch adds the workaround for alls TVRXs. --- usrp2_fft.py2008-10-26 22:36:36.0 +0100 +++ mdvh_usrp2_fft.py 2008-10-26 22:35:56.0 +0100 @@ -133,9 +133,10 @@ hbox.Add((5,0), 0, 0) g = self.u.gain_range() - if self.u.daughterboard_id() == 0x0003: # FIXME: get range right in firmware for TVRX +dbid=self.u.daughterboard_id() + if dbid == 0x0003 or dbid==0x0040 or dbid == 0x0040: # FIXME: get range right in firmware for TV Rx, TV Rx Rev 2 and TV Rx Rev 3 g[1] = 104 - + myform['gain'] = form.slider_field(parent=self.panel, sizer=hbox, label=Gain, weight=3, min=int(g[0]), max=int(g[1]), Thanks again for your testing. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [cell] videocard with onboard cell processor announced
http://www.tcmagazine.com/comments.php?id=21673catid=2 Th Leadtek PxVC1100 card features a PCI-Express x1 interface, active cooling, it boasts a SE1000 SpursEngine chip which integrates four Synergistic Processing Element (SPE) cores, at a currently unknown frequency and has 128MB of XDR memory clocked at 1.6 GHz. Leadtek has yet to announce the card's price or release date. This would be a nice GnuRadio coprocessor, if the specs and api's are open. Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio.org seems to be down
Hi, gnuradio.org seems to be down (including svn and trac) Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make check failure and solution patch (faulty gr_basic_block sort in gr_flow_graph)
Hi All,
This patch makes the sort of basic_blocks reliable in gr_flowgraph.cc
Without it make check can fail in qa_gr_flowgraph.cc:240
background:
While working with new buffer code I found that make check can fail in
qa_gr_flowgraph.cc
240: CPPUNIT_ASSERT(graphs[0].size() == 4);
The cause of this is that the subgraphs are not in the order as expected.
The code expects
graphs.size()==3
graphs[0].size()==4
graphs[1].size()==3
graphs[2].size()==2
But it gets
graphs.size()==3
graphs[0].size()==3
graphs[1].size()==2
graphs[2].size()==4
This only happens if there are a lot of big malloc /frees in code before it.
The probable cause is that a plain std::sort is used for sorting vectors of
gr_basic_block
But for gr_basic_block the operator is not defined.
I changed the code to use basic_block-unique_id() for sorting.
This should be more robust.
(I got rid of the make check failure)
This problem might be in more parts of the code
Greetings,
Martin
Index: gr_flowgraph.cc
===
--- gr_flowgraph.cc (revision 9229)
+++ gr_flowgraph.cc (working copy)
@@ -30,6 +30,11 @@
#include sstream
#define GR_FLOWGRAPH_DEBUG 0
+bool
+basic_block_sort_predicate(const gr_basic_block_sptr lhs, const
gr_basic_block_sptr rhs)
+{
+ return lhs-unique_id() rhs-unique_id();
+}
gr_edge::~gr_edge()
{
@@ -173,7 +178,8 @@
}
// Return vector of unique blocks
- sort(tmp.begin(), tmp.end());
+ //sort(tmp.begin(), tmp.end());
+ sort(tmp.begin(), tmp.end(),basic_block_sort_predicate);
unique_copy(tmp.begin(), tmp.end(), inserter);
return result;
}
@@ -272,7 +278,7 @@
tmp.push_back(p-dst().block());
// Remove duplicates
- sort(tmp.begin(), tmp.end());
+ sort(tmp.begin(), tmp.end(),basic_block_sort_predicate);
unique_copy(tmp.begin(), tmp.end(), inserter);
return result;
}
@@ -288,7 +294,7 @@
tmp.push_back(p-dst().block());
// Remove duplicates
- sort(tmp.begin(), tmp.end());
+ sort(tmp.begin(), tmp.end(),basic_block_sort_predicate);
unique_copy(tmp.begin(), tmp.end(), inserter);
return result;
}
@@ -399,7 +405,7 @@
}
// Remove duplicates
- sort(tmp.begin(), tmp.end());
+ sort(tmp.begin(), tmp.end(),basic_block_sort_predicate);
unique_copy(tmp.begin(), tmp.end(), inserter);
return result;
}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What's wrong with this constellation?
Peter Monta wrote: Hi Mason, ... The amplitude of the receiver output seems to spray out pretty widely from the constellation point intended. It could be an AGC issue---is the AGC time constant long compared with a symbol? Is the distribution of constellation points uniform (each is picked with equal probability)? One thing you could try, if the channel permits, is to temporarily hold the AGC fixed to see if that gives a better constellation (perhaps at the wrong size; You should indeed try this. Do you sent (short) bursts of QAM or is it a continuous stream? If they are bursts then all loops (carrier recovery, AGC, clock-recovery) can behave strangely. If it is a continuous stream you could also try a feedback-AGC in stead of a forward AGC which should give much less gain noise (after it has settled) It is also possible that the amplitude noise comes from the analoge components in your TX-path or your RX-path. If you have noise or hum on the supply voltage of any gain or mixer stage then this will result in amplitude noise. You could figure this out by sending out a single carrier (no modulation, use ) and receive it with an SSB-receiver script or just usrp_fft.py. generate carrier: usrp_siggen.py -R B --const -i 128 -f rffreq -a amplitude -g rfgain look at spectrum: usrp_fft.py -R A -d 64 -f rffreq -g rfgain look at oscope: usrp_fft.py -R A -d 64 -f rffreq -g rfgain -S (Use the same analog signal path as you use for QAM) Now you can look at the spectrum, listen to it and look at it with an oscope. If the signal is clean, your QAM-TX script or QAM-RX script is to blame. Make sure you also look at LF noise or hum, like 50 Hz or even lower. If you see noise, then there is something wrong with your setup. greetings, Martin or if you're using decision feedback, try to get it to the right size :-) ). Cheers, Peter Monta ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Multiple USRP's debugging
Douglas Geiger wrote: On Mon, Jul 21, 2008 at 9:46 AM, Douglas Geiger [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I am having trouble getting two USRP's synchronized using the multiple USRP setup described at http://www.gnuradio.org/trac/wiki/MultiUsrp and http://www.gnuradio.org/trac/wiki/USRPClockingNotes. I am able to open/get data from both USRP's independently, and have even crafted a program to setup simultaneous flowgraphs collecting data from both and feeding them into BBN's 80211b demodulator. However, I would like to be able to synchronize the clock on both USRP's (I'm interested in looking at TDOA between packets). I have not had any luck getting the multi_usrp_oscope.py program displaying any data - and my attempts at using usrp_multi.multi_source_align as a source in e.g. the usrp_fft program have not been successful. Are there any suggestions on where I should be looking to debug this? I am using the multi_2rxhb_2tx.rbf fpga code, and using gnuradio-3.1.2 on a laptop running ubuntu hardy heron. mailto:[EMAIL PROTECTED] I found my problem - I was not properly connecting the j24 jumper (io15,gnd) between the master and slave, so the sync signal was not getting received properly. I still get errors occasionally: Error: counter not continuous. ucounter_begin[1]=200768 +1 != ucounter_begin[2]200828 I assume this is because the master and slave have falling out of sync? Most common source for this problem is a buffer overrun (a whole USB packet was missed) You can try to minimize this by increasing the process priority of both the TX and the RX script. lowering the datarate also should help. Are there any recommendations on how often the master/slave sync should get sent? For low datarates a single sync should work for a long time. To be sure, you could do it once a minute or something like that. Also - if I were to add a third USRP, I assume I'd just have to chain the j24 jumper from either the master or slave - and change the enable_master_and_slave() function in usrp_multi.py to enable both slaves? If I recall well, this should work indeed. My next goal is to forward-port the multi_usrp code to the development trunk (e.g. using hier_block2, etc.), as my eventual goal is to include the in-band signaling code to get accurate time-stamps from the RF front-end. I assume the current in-band .rbf files are not being built to support the multi-usrp code, correct? I am starting to familiarize myself with the Quartus software and the organization of the usrp verilog code. With the new inband signaling timestamps you should not need the counter anymore which is used in the current multi_usrp code. You should only need to sync the starttime (used for the timestamps) once using the J24 cable. Then the align block should be rewritten to align on timestamps in stead of samplenumbers. With the new inband signaling it should also be feasabale to build a multi-usrp setup for sending signals (TX). (I stopped working on this when work was started on the inband signaling) Greetings, Martin Doug -- Doug Geiger [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help with safe and clean band
Mihail L. Sichitiu wrote: Hi there, I'm brand new at this GNU Radio thing, so please forgive me if my question has a well-known answer. I'd like to try out some performance tests on a few modulation schemes, so I need a clean band for these tests. Obviously the 2.4GHz ISM band is full of interference, and I assume that this goes for all the other ISM bands, right? If this is the case, is there a well-known relatively quiet band where I can run these tests without interfering with anything important, without being interfered with, and without getting in trouble with FCC? The easiest thing to do would be not doing your tests wireless. Connect TX twith coax to an attenuator and connect that to the RX side with coax. That is about as clean as you can get, and you won't interfere with anyone on any band. Make sure you use enough attenuation. The RFX2400 TX side has much more power at its output then the RX side can handle. You will blow up your daughterboards if you don't have at least 30 dB attenuation. The best attenuators I found for high frequencies are the SMA inline types You can mount them directly at the TX output and connect a SMA-SMA coax to the RX side of a second RFX2400. Things are much more relaxed with basicRX and basicTX. basicRX can be connected directly to basicTX without any chance of damage. I do a lot of my testing with basicRX and basicTX. The output of basicTX is also very low which is an advantage in this case. Greetings, Martin I imagine that if I'd have all the daughter boards I could do a long-term (1-2 days) scan and find a quiet band and play in there (the tests are likely short and low powered). The problem is that I only have the 2.4GHz daughter-boards and I'd like to buy only the right daughter-boards (as opposed to all of them to find an empty band). Thanks for the help, Mihai ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DAB with GNU Radio
Christoph Fischer wrote: Hello Andreas, thank you for your very interesting reply. we would like to implement a DAB receiver with GNU radio. On the hardware side we have a USRP with the TVRX daughterboard. Jens Elsner, who worked on DAB some time ago, found out that the TVRX actually disturbs the OFDM signal very much, making it rather hard to receive DAB, so I would strongly discourage its use (I'm not able to get any information out of TVRX samples currently). That is bad news... So perhaps at first we should do some analysis if DAB is really impossible with the TVRX or if we only have severe degradation of SNR. We have a DAB transmitter just some km away from the university so perhaps it could somehow work at least for this one... Does anyone already have some data about the phase stability of the TVRX? Unfortunately the L-Band is no option here. You could try undersampling with basicRX. Frequency stability wouldn't be an issue. But the sensitivity is very very low and you get interference from all bands above 32 Mhz folded over each other. This could be improved by using a bandfilter and an amplifier in front of the basicRX. Just use a bandfilter which only passes the part of band III which you are interested in. The bandfilter should have a bandwidth of 30 Mhz or less. For example 170 - 200 Mhz. For amplification best would be a dedicated amplifier for this freq-band with 20 to 50 dB gain. But to keep things simple you could use an off-the-shelf amplifier for TV-signals which have usually 10 to 15 dB gain. As an antenna you could use a home-made vertical dipole or J-antenna for exactly the right freq. This also improves selectivity. greetings, Martin Is there any initial advice or pointers to existing implementations you could give us? Do we need the checkout the svn version or even some branch or is the 'latest stable' enough? I have uploaded my current code to [2]. It requires GNU Radio from the trunk and some small patches (mainly for the peak detector). If you are interested, I can also send you my mostly-finished semester thesis off-list. Thank you very much for all that. We also would be very interested in your thesis. Regards, Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GnuRadio code and documents at Olifantasia.com down, but back up
Hi All. All Olifantasia.com servers have been offline for several weeks, but they are back up again. I send this to the GnuRadio mailing list since I have several GnuRadio examples, presentations and code-snippets hosted at the Olifantasia webserver and have got some questions where they went and why all email bounced and my domain vanished. Well, they finally are back where they were. Also if you have been trying to reach me by mail the past weeks (between 14 may 2008 and 9 june 2008) you probably got undeliverable messages. Please resent your mail now. The mailserver is back up too. Sorry for the inconveniance. I don't know if this also means my gnuradio mailinglist subscription was automatically stopped. If so, how do I re-enable it? Background. My provider (xs4all.nl) has been having major technical and organisational problems the past weeks which resulted in intermittant internet access and a wrong IP number for my nameservers in the root-dns. Since they haven't been able to correct this, I switched to a different domain registrar. Greetings, Martin Dudok van Heel http://www.olifantasia.com/projects/gnuradio/mdvh/ http://www.olifantasia.com http://www.olifantasia.com/gnuradio/ (Dutch) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio on embedded systems
Philip Balister wrote: Has anyone looked at GNU Radio on an embedded system seriously? I've built it for an ARM processor and heard that the dial tone example will work. I'm particularly interested in using the python-less method of connecting blocks. I understand that many of the GNU radio blocks are written using floating point, Yes, allmost all of them depend heavely on floating point performance. Floating point performance, memory speed and USB-throughput are the main bottlenecks for gnuradio. You could rewite some of the blocks in fixed-point, but then you loose much dynamic range and need very high fixed-point performance. I know of good performing Software Defined Radio platforms using an ARM processor but they all have a high-performance DSP processor attached to or integrated into the ARM processor. but does the core gnu radio code depend on good floating point performance? Depends on what you consider the core gnu radio code. The flowgraph and flowgraph-scheduler do not depend on floating point performance. But things like the spectrum display (fft-sink), all modulation/demodulation and all the filter blocks do, Martin Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DAB receiver
Jens Elsner wrote: Hallo Andreas, with the current status of OFDM PHY code in GNU Radio I think it is definately worth a try. The work I did on DAB was basically OFDM synchronization in one GNU Radio block. The code was more or less a hack, but it deepened my understanding of digital signal processing. Jens, I have downloaded your gr-dab code in 2007. Is it OK if I put up a mirror of it on my website. Maybe it could deepen the understanding of others about OFDM too. Greetings, Martin Not as easy as in text books. :) I'll email the report to you separately. I wouldn't underestimate the complexities of the higher DAB layers, it has quite a protocol stack. But you should give it a try. If you need captured Mode I/II samples I can make them available for download. Gruesse, Jens On Wed, Feb 20, 2008 at 07:14:24PM +0100, Andreas Müller wrote: Hello, I am an electrical engineering student, and I would like to implement a DAB receiver as a semester thesis (about 1/3 the size of a Master thesis). I intend to implement each part first in Matlab and then in GNU Radio. Ideally, I hope to use the existing OFDM code in gnuradio-core and some external MP2 library for the audio decoding. However, I am wondering if this is feasible as a semester thesis. Any comment about the rough amount of work that would be needed would be greatly appreciated. In the mailing lists, there are some references to an existing DAB implementation from ([1],[2]). Can anyone tell me how far this got? The referenced website (http://www.1c3.de/gr-dab.tar.bz2) is empty. Regards, Andreas [1] http://lists.gnu.org/archive/html/discuss-gnuradio/2006-08/msg00205.html [2] http://lists.gnu.org/archive/html/discuss-gnuradio/2006-03/msg00397.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] minimizing interference with usrp
Matt Ettus wrote: Juha Vierinen wrote: Hi, I have been doing some radio astronomy experiments with USRP using a 30 MHz dipole antenna (actually it is more of a riometer experiment). I am running into various interference issues. E.g., at one point I noticed that if my laptop power supply is too close to my USRP I get switching power supply harmonics in my signal. At other times I have been pretty sure that the inteference comes through my antenna. I have found huge differences between laptop power supplies from the manufacturer of the laptop (like Lenovo, HP, etc.), and cheap replacement supplies made to look like the originals. Once I was testing something on the USRP while the computer was attached to one of these supplies and I saw a huge mess on the spectrum analyzer. I spent an hour trying to figure out what was happening, only to find that it was there even if there was no USRP hooked up at all -- it was all radiating from the power supply. If you really need low noise, run the laptop off of its internal battery only. What also works is running everything (laptop and USRP) from external batterypacks. The USRP needs 6V, which can be provided by 5 standard NiMH batteries in series (use large D-size cells or put several penlites in parallel) Alternatively you can use non-switching powersupplies. (Just use a LAB power-supply or build your own with a transformer, rectifier, big capacitor and linear regulator) More tips to get rid of RF spuriuos: Put ferrite beads around any power or digital cable. (mains power, DC power, USB, ethernet) Put everything in fully closed metal cases (powersupply, laptop, USRP) Make sure you don't run into heat problems this way. If you do run into heat problems, only use small round holes in the metal casings. 1000 small holes is much better then 10 big holes from a RF point of view. What also helps for laptops is to attach coppertape to the inside or outside of the full casing of the laptop. (We used this to get flatscreen TV's we developed CE complient) Take care this tape doesn't cause any shortcircuits. A low-budget solution is to use aluminium foil. Make sure you use high-quality coax cables for the RF-connections. Make sure to use high-quality USB cables with good shielding. Use a mains filter. Run the USRP powersupply from a different mains group as the laptop. Make sure your antenna is above a big metal plate (several wavelengths big) which is very well grounded. Make sure that your grounding is several meters into the ground well into the groundwaterlevel. Make sure that all digital equipment is below this metal plate If you are really desperate: Add extra 100 nF SMD capacitors between all powersuppply pins of every chip and ground (both USRP and laptop) Make a metal casing for the daughterboards. I hope this helps, Martin Dudok van Heel Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Filter FIR on FPGA
[EMAIL PROTECTED] wrote: Hi, I'm designing a pass band filter FIR on FPGA. This filter has 64MHz of sample rate and as window type HAMMING. I'm using MegaCore® IP Library for design of the filter. Is correct to use this software for design of the filter? Could you suggest me other software for design of filter? Design it by hand. I allways do it like that, you have better control of what resources are used for the filter. (Especially when using an FPGA without multipliers like the Cyclone) And you can use the filter on any FPGA and share the code with people who do not have access to MegaCore® IP Library. If you only need the filter-taps, you can use the firdes or optfir (part of gnuradio, see gnuradio-examples on how to use) Greetings, Martin Thank you very much. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interest in beamforming and GNSS receivers
Pavol Ďuriš wrote: Hi all, I have an interest in radioastronomy. I plan to make simple beamforming phase array (primary with 4 and later with 8 antennas) with USRP (later with 2) and GNU Radio. I am inspired by LOFAR radiotelescope. Now I collect all available information about using GNU Radio and USRP for it. Martin, could you send more information about your solution, project (url etc.) ? Info about connecting murli-USRPs: http://gnuradio.org/trac/wiki/MultiUsrp http://gnuradio.org/trac/wiki/USRPClockingNotes http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-examples/python/multi_usrp This last one is also in your gnuradio source directory: gnuradio-examples/python/multi-usrp It has been a while since I last used this setup, so there might be some bitrot. (incompatibilities between the multi-usrp fpga firmware (rbf-file) and the latest gnuradio code and support for the latest daughterboards.) But if this is the case then it should be solvable by implementing the latest changes to the standard USRP firmware to the multi-USRP firmware. There is not much info about my phase-array experiments online. I know, I should update my website more often, but I am better at writing code then at writing human-readable text. I do haver a snapshot of my CMA (Constant Modulus Algorithm) adaptive phase-array code. This code automatically adapts to multiple FM, GMSK, QPSK or M-PSK sources. It should be able to extract multiple sources on the same frequency by automatically nulling the other sources out when extracting one. (max number of sources == number of antenna's used) Note that this code only works with phase-coherent daughterboards (boards which use the USRP-clock as refclock) This means allmost all daughterboards except TVRX. (Which is too bad since I want to extract multiple broadband FM stations, for now I use undersampled basicRX) The code is at: http://www.olifantasia.com/projects/gnuradio/mdvh/CMA_phase_array/ Other code of mine can be found at: http://www.olifantasia.com/projects/gnuradio/mdvh/ or http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1 or (when it has stabalized) in GnuRadio trunk Greetings, Martin Thanks, Pavol PS: I haven't USRP yet. However, I am buying my first USRP, right now :) Martin Dvh wrote: Carles Fernandez wrote: How well are they synchronized? They run off the same 64 MHz clock, so are synchronised. I have even used two connected USRPs running of the same clock (one is master and exports its clock to the slave USRP) (You use an additional flatcable between the USRPS and an align software block in gnuradio which aligns the samples) This gives you 8 ADCs. This means 8 real channels or 4 complex channels. I used this setup for a phase array with 4 DBSRX daughterboards. (DBSX daughterboards use complex sampling so they need two ADCs) DBSRX boards also support the GPS frequencies and are a lot cheaper, so you might want to consider them. But they are receive only. You can even go higher and connect 4, 8 or 16 USRPS. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interest in beamforming and GNSS receivers
Carles Fernandez wrote: Hi everybody, I discovered GNU Radio few months ago, in a before-go-to-bed surfing. I found it very interesting, but complicated because of my poor skills in programming Python or C++. I'm doing research on Global Navigation Satellite Systems (GNSS) receivers, and I'm used to code everything in Matlab. Night after night, I've been browsing the documentation and making humble steps: I installed Ubuntu on my laptop, followed the -excellent, also for dummies like me- guide for installing all the software, read diagonally the documentation and played with sample codes. Some Hello Worlds, some problems with the audio module, getting used to read the mailing list, feeling astonished by the intense activity of this community... nothing new, I guess. Now I want to take it more seriously. I've seen that both python and c++ have very well done matrix algebra libraries, and that's exactly what I need for my research (you can call me naive). I would like to implement a GNSS receiver (in the wide sense) based on an antenna array and play with beamforming algorithms and weird RF front-end architectures (direct RF, IF sampling, etc). My main concern is synchronization, concretely I want to implement some signal processing algorithms in a real receiver in order to assess their impact in the whole system, testing them with real data. I've been working in the development of some algorithms that -theoretically- performs better in multipath environments, but I want to see if this is true beyond classical academic benchmarks. What is the state of GNSS receivers development in GNU Radio? I have found some expressions of interest in the Internet, but nothing concrete. I'm willing to start it from the scratch, but it is nonsense to reinvent the wheel. I would like to put in contact with other people interested on these topics. Taking advantage of your patience, I have some other questions (and you will see my newbie approach): - I've seen some statements about beamforming is possible. To what extend? I'm trying to understand the multi-antenna code example, but it is possible to use the four ADC at the same time? Yes. How well are they synchronized? They run off the same 64 MHz clock, so are synchronised. I have even used two connected USRPs running of the same clock (one is master and exports its clock to the slave USRP) (You use an additional flatcable between the USRPS and an align software block in gnuradio which aligns the samples) This gives you 8 ADCs. This means 8 real channels or 4 complex channels. I used this setup for a phase array with 4 DBSRX daughterboards. (DBSX daughterboards use complex sampling so they need two ADCs) DBSRX boards also support the GPS frequencies and are a lot cheaper, so you might want to consider them. But they are receive only. You can even go higher and connect 4, 8 or 16 USRPS. it is possible to compute the weight values in software and perform the multiplication in the FPGA at real time? You could do that, but that means extra multipliers in the FPGA, which take up resources. You could also do the multiplication in software, but then you have several datastreams from the USRP (which could saturate the USB connection when using a high datarate). (You can do maximal 4 receive streams from the USRP) There is any other major bottleneck than algebraic weight computation time? You have to make sure the LO's from the frontends are synchronised. This is the case with the RFX1200. It uses the USRP clock as reference. You also might need a more stable and/or precise (external) clock. the current clock is 15 ppm (from the top of my head). I don't know the exact phase-noise figures. You also might need to put good low-noise LNAs in front of the RFX1200 or the DBSRX. - My first target is a traditional L1 C/A code GPS receiver. I guess that I can choose between RFX1200 and a BasicRx with an external front-end. Have someone worked in the connection of GNU Radio with gpstk? - It is 32 MHz the maximum bandwidth available? In theory you could have 64 Mhz bandwidth when using complex sampling (the RFX1200 does this). This uses two ADCs for one frontend (one for the I and one for the Q channel) Your frontend must support this analog bandwidth of course. The RFX1200 has filtering which limits the bandwidth to about 25 MHz. You could change the filtering to widen it. This is a bit dangerous however because any remaining signals outside the 64 MHz band will fold around the niquist freq. This 64 MHz bandwidth is not transportable to the host PC with the current supported resolutions (8 bit and 16 bit) You have a maximum USB throughput of 32 MByte/sec. Which means 8 Mhz bandwidth with 16 bit resolution and 16 MHz bandwidth with 8 bit resolution. When you implement verilog code to reduce the resolution to 4 or 2 bit you would have 32 or 64 MHz bandwidth, but only for a single channel. When you implement the despreading in
Re: [Discuss-gnuradio] Shielding on 2.4GHz
DiX wrote: Hi everyone, I am using FLEX2400 d'boards to transmit and receive 802.11b packets with codes from bbn and gnuradio_example/python/digital. The problem is the d'board is always interferenced by some CISCO access points and other wireless cards located right outside of my lab. I connect the usrp to my pc with a cable (-30db attenuator applied). I hope it receives nothing but packets from my pc. But the d'board can still get packets from other wireless card. Then I put the m'b and d'b into the black enclosure. Packets still come in. And finally, I put everything (m'b, d'b, black box, attenuator) in my metal drower. Most packets are shielded out. Some still can be caputured and demodulated.%-| why is the d'b able to hear others even when I connect attenuators and cable to its antenna? -DX It might pick it up on the 6V power cable. You could try putting ferrite beads around the power cable to reduce this. greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-sounder tx and rx results
Johnathan Corgan wrote: On 1/24/08, Dev Ramudit [EMAIL PROTECTED] wrote: I've been trying out the gr-sounder code to see if I can use it for some research. I modified it slightly and graphed the output in realtime. Let me work with you offline on this. The code does work over the air, but it is probably not giving you what you expect. Unfortunately, I'm tied up for a day or two. I have been working with the sounder-code too. WHat I found is that since the clocks of the USRP boards are not synchronised you have two problems. The LO's of the RFX boards are not phase-coherent so you have an RF frequency offset between the boards of a few kHz. This results in not getting a spike but a kind of smeared out LF-modulated wave. This problem should be much less with basicRX/TX or LFRX/TX boards The other problem is that the 64 MHz clocks are not synchronised. This produces a little smearing of your results but is much less a problem. Both problems get bigger as you lengthen the peudo-random codelength. You could solve this by using very precise (GPS-tamed) external 64 MHz clocks on both sides. You can also solve it by giving one USRP a clock-out and the other a clock-in and connecting them together (so they run of the same 64 MHz clock) This requires a clock-cable between the two USRPs so this is only feasable for short distances. An other solution I see is to extend the code with some PLL which recovers the symbol clock and uses that to compensate for both problems. I don't know what solutions Jonathan has, but I would like to know them too. Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
WSR08 Software Radio Conference in Karlsruhe, Germany March 5/6, 2008 (was Re: [Discuss-gnuradio] Pentium IV computing power in FLOPS)
Vincenzo Pellegrini wrote: Thanks Eric. very precious info.. just by the way.. on March 6th, the Soft-DVB work will be presented in Karlsruhe at the WSR08 software defined radio conference. I didn't know of WSR08. Seems like a very nice conference about Software Radio. There are three GnuRadio presentations: Session 6: GNU Radio 14:00 h GNU Radio Based Cognitive Signal Identification and Classification Platform W. M. Brown (Metric Systems Corporation, California, USA), J. E. Clark III 14:25 h Implementation of OFDM Power Allocation Strategy in GNU Radio Framework M. Zivkovic (RWTH Aachen University, Germany), C. Liu, R. Mathar 14:50 h Soft-DVB: A Fully-Software Gnuradio-based ETSI DVB-T Modulator V. Pelegrini (University of Pisa, Italy), G. Bacci, M. Luise Too bad I heard about it this late, otherwise I would have applied for doing a GnuRadio presentation too. (It looks like the submission has been closed since nov 30 2007) I found info about the conference at: http://www-int.etec.uni-karlsruhe.de/seiten/conferences/wsr08/ Greetings Martin greetings Vincenzo On Sun, 2008-01-20 at 20:19 -0800, Eric Blossom wrote: On Mon, Jan 21, 2008 at 01:10:47AM +0100, Vincenzo Pellegrini wrote: Hi everybody, could anybody help me in figuring out what is (even a rough estimate is OK) the raw computing power of a 3.0GHz Pentium IV CPU? really thanks for help -- Vincenzo Pellegrini Assuming you're coding in assembler using SSE* instructions, you can get a sustained throughput of about 1 FLOP / clock cycle. Since you're not really doing that, I'd call the 3GHz P4 about 0.5 to 1.0 GFLOP. YMMV. Widely ;) On the netburst microarchitecture used in the P4 it's really hard to get good floating point performance because of the very deep pipeline, scarcity of registers, and so-so FPU. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: WSR08 Software Radio Conference in Karlsruhe, Germany March 5/6, 2008 (was Re: [Discuss-gnuradio] Pentium IV computing power in FLOPS)
John Clark wrote: Martin Dvh schrieb: Vincenzo Pellegrini wrote: Thanks Eric. very precious info.. just by the way.. on March 6th, the Soft-DVB work will be presented in Karlsruhe at the WSR08 software defined radio conference. I didn't know of WSR08. Seems like a very nice conference about Software Radio. There are three GnuRadio presentations: Session 6: GNU Radio 14:00 hGNU Radio Based Cognitive Signal Identification and Classification Platform W. M. Brown (Metric Systems Corporation, California, USA), J. E. Clark III 14:25 hImplementation of OFDM Power Allocation Strategy in GNU Radio Framework M. Zivkovic (RWTH Aachen University, Germany), C. Liu, R. Mathar 14:50 hSoft-DVB: A Fully-Software Gnuradio-based ETSI DVB-T Modulator V. Pelegrini (University of Pisa, Italy), G. Bacci, M. Luise Too bad I heard about it this late, otherwise I would have applied for doing a GnuRadio presentation too. (It looks like the submission has been closed since nov 30 2007) I found info about the conference at: http://www-int.etec.uni-karlsruhe.de/seiten/conferences/wsr08/ I checked, and how I found out about was on a post 8/20/07 to this list from a poster named, '[EMAIL PROTECTED]' who posted one notice. I must have missed that one. Since we had been looking for a forum to make a more public presentation of what we've been doing, I jumped on it... Very Good. I am looking forward for your presentation (and the others of course) Greetings, Martin John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Need info for paper.
John Clark wrote: I'm co-writing a paper on the use of GNU Radio. Because I'm inclined to use 'Open Source' solutions, GNU Radio and the attendant DSP library, was for me about the only choice I would have made... However, in the paper I'd like to at least make some attempt at indicating any 'alternatives', if there are any in the Open Source arena, or parish the thought, cost-money type packages. High Performance Software Defined Radio (opensource) An Open Source Design The HPSDR is an open source (GNU type) hardware and software project intended as a next generation Software Defined Radio (SDR) for use by Radio Amateurs (hams) and Short Wave Listeners (SWLs). http://hpsdr.org http://pcovington.blogspot.com/ There are GnuRadio developers which are in contact with or collaborate with people of HPSDR. They use some of the verilog sourcecode of the USRP for their FPGA in their boards. Gstreamer Quadrature library (opensource): libgstiq is a library with Gstreamer plugins for use in software defined radios. http://sharon.esrac.ele.tue.nl/users/pe1rxq/libgstiq/index.html libDSP (opensource) libDSP is a C/C++ library of digital signal processing routines, including standard vector operations, digital filtering, and transforms. http://sourceforge.net/projects/libdsp/ flex-radio (commercial) Company building software defined radio frontends (SDR-1000) for use through the soundcard of a PC for the IF. Aimed at Radio-amateurs http://www.flex-radio.com/ Comblock (commercial) Hardware oriented commercial company delivering blocks to build SDR systems ComBlock modules are small commercial off-the-shelf modules which are pre-programmed with essential communication processing functions, including modulation, demodulation, error correction encoding and decoding, digital to analog/RF, RF/analog to digital, formatting, data storage and baseband interfaces. http://www.comblock.com ARRL page about software defined Radio projects: http://www.arrl.org/tis/info/sdr.html If anyone has done a more detailed evaluation and perhaps has a chart depicting features, that would be good. Also, a while ago, I saw someone who had put together a 'graphical' interface, where one could construct a DSP processor using graphical means, and setting various parameters using a GUI. I have not had the time to really keep up on that sort of thing, but if there is someone who has something that works, I'd also like to know about that. Thu GnuRadio GUI you are referring to is called GRC, written by Josh Blum Download: http://www.joshknows.com/download/grc/ Wiki: http://gnuradio.org/trac/wiki/GNURadioCompanion For those who have information, and send me a release, credit will be made in the paper for their contribution. If you need any other kind of info, please let me know. I have done some presentations on GnuRadio and Software Defined Radio and I am preparing for some GnuRadio courses that I will be giving. It would be appreciated if you made the paper public and available somewhere on the web. Greetings, Martin Thanks, John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with symmetric behavior
Robert Miller wrote: Hello, I created a flowgraph based upon the usrp_nbfm_ptt.py example. I am witnessing some weird, asymmetric behavior when running the graph. The code generates a tone from the user specified daughterboard and then plots the spectrum via an fft from another user specified daughterboard. I am using 2 RFX-1800 daughterboards with a single USRP to run the graph, however I imagine it should work the same for any RFX board. Here is the main issue: Everything works fine when using Side B as the transmitter and Side A as the Receiver. When running with Side A as the transmitter and Side B as the receiver, however, the fft display is really just noise (once in a while there exist some spectral lines at odd frequencies). As a note, I am fairly certain that the mux's are being set correctly and that the boards are tuning correctly. To verify that the issue is not the hardware, I am capable of running usrp_siggen.py and usrp_fft.py in both configurations successfully. (TXR A -- RXR B, TXR B -- RXR A). Also, I have done the tests in completely wired (with 60 dB of attenuation) and unwired environments, with both yielding the same results. Attached is the code that I am running, can anyone point out something silly that I am doing that is causing this problem? http://www.nabble.com/file/p14642329/DualChannel.py DualChannel.py As an added note, I am getting a segmentation fault when I close the graph by any means other than Ctrl-C from the command line. I don't think this is related to the above issue, and I don't get the seg fault when running the original usrp_nbfm_ptt.py code. Thanks! Rob Your problem is in the tuning I think: class receive_path(gr.hier_block): def set_freq(self, target_freq): r = self.u.tune(self.subdev._which, self.subdev, target_freq) # -- look here Which should be: class receive_path(gr.hier_block): def set_freq(self, target_freq): r = self.u.tune(0, self.subdev, target_freq) # -- look here The first parameter is the channel you are tuning, which is always channel 0 if you only receive one stream. It is NOT subdev._which, which indicates on which side the daughterboard is. I hope this helps, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PSK31 with GNU Radio
Dan MD1CLV wrote: Hi all, Is anyone using GNURadio to modulate or demodulate PSK31? According to the archives, Chuck Swiger did have this working, but the page with his code on is gone and it isn't archived on the wayback machine. Chuck has put up a new webpage at http://www.swigerco.com/ The GnuRadio stuff is under http://www.swigerco.com/gnuradio/index.html But I can't find the PSK31 stuff. On his old page it was at: http://webpages.charter.net/cswiger/psk_experiment.html (I am very happy though that his GnuRadio vector analyzer info is back online) I have successfully decoded PSK31 in the past using the following. Capture using Gnuradio to file. convert the file to a wav file using sox decode the file using some other opensource PSK31 program. You can do all this in realtime if you use Pipes in stead of files. in pseudocode it would look something like this: mkfifo psk.raw mkfifo psk.wav usrp_rx_cfile.py [commandline options here] -s psk.raw sox [commandline options here] psk.raw -o psk.wav pskprogram psk.wav It's a while ago, so I don't remember all settings I used. I think I captured to file in the short format (not in the float format) Of course, much better is to implement PSK31 in the gnuradio framework. Greetings, Martin Thanks, Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re-writing blocks using intel libraries
Tom Rondeau wrote:
Martin Dvh wrote:
Eric Blossom wrote:
On Tue, Dec 11, 2007 at 03:41:46PM -0800, Eugene Grayver wrote:
Please see answers in-line.
Thanks!
General curiosity questions:
Are you using oprofile to measure performance?
I am a bit of a maverick, and for various reasons am using a pure
C++ environment. I hacked my own 'connect_block' function (can;t
wait for v3.2, where these will be part of native gr).
The trunk contains C++ code for connect, hier_block2, etc. Some of
the pieces that are still missing include C++ support for the USRP
daughterboards, but Johnathan Corgan is working on that now.
I am measuring the performance using a custom block (gr_throughput)
that simply reports the average number of samples processed per
second.
What h/w platform are you running on / tuning for?
The platform is currently Intel Xeon or Core2 Duo.
You're not trying to run your app on a cache-crippled machine like a
Celeron, are you? ;)
No, very high end.
Which blocks are causing you the biggest problem?
I got a 2x improvement on all the filtering blocks.
If these are FIR filters, were you using gr_fft_filter_{fff,ccc}
or the gr_fir_filter* blocks? The FFT one's are _much_ faster with a
break-even point around 16 taps IIRC.
About a 40% improvement for sine/cosine generation blocks. This
includes gr_expj, gr_rotate.
No surprise there, and that's a great example of SIMD code that should
be in GNU Radio.
Are your problems caused primarily by lack of CPU cycles, cache
misses or mis-predicted branches?
I am not sure, since I am not at all a software expect (mostly
dsp/comm). My guess is that the SSE instructions are not being used
(or not used to a full extent). Even the 'multiply' block is VERY
slow compared to a vector x vector multiplication in the Intel library.
OK.
Some of the gr_blocks process each sample using a separate function
call (e.g. for (n=0; nnoutput_samples; n++)
scale(in[n])
Replacing this with a single vectorized function call is much faster.
OK.
We would not accept the changes.
That's what I expected. We'll try to contribute the more
dsp-centric blocks such as demodulators.
That would be great! Or if you want to code up an SSE Taylor series
expansion for sine/cosine good to 23-bits or so, we'd love that too ;)
I am working on this in the little spare time I have.
I already got a SSE taylor series for atan2, working in gnuradio.
The atan2 needs some code cleanup and wrapper code to switch
implementations (if (processor=X86, processor
supports_SSE2)=optimized else generic)
The sin/cos is far from ready.
Greetings,
Martin
Martin,
Bob put in a fast atan function (general/gr_fast_atan2f.cc) about a year
ago. Have you looked in this, and is the Taylor performance better?
The taylor performance is much better when you get (a multiple of) 4 atan2s at
a time.
(because the SSE taylor series works with SIMD in blocks of 4)
When you only get one at a time, the performance is still better but not by
much.
The taylor series also is more precise then gr_fast_atan2f.cc
I don't have the numbers at hand, but I also wrote qa and benchmark code so
exact numbers on precision and speed can be determined.
As a side note:
I have also been working on a new version off the FFT FIR filter.
This one is more efficient when decimating.
inverse_FFT_size=forward_FFT_size/decimation
This works very well when decimation is 2^n, it also works well for most other
decimation factors EXCEPT when decimation is a big prime.
This means the theoretical maximum speed improvement is a factor two (when
decimation is infinite)
But when you want multiple parts of the spectrum then the speed improvement is
much better then using a FIR filter per spectrum part.
Then you can use a single forward FFT with multiple inverse FFTs.
Greetings,
Martin
We really need a faster sin/cos. Glad to hear you're working on it.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Ideas for improved FM reception
Patrick Strasser wrote: Martin Dvh schrieb am 2007-12-07 18:28: The second thing I want to do is detecting if multiple transmitters (at different locations and frequencies) transmit the same radiostation. With a single tuner I can capture all these signals at the same time. Provided they are within 8 or 16MHz. Then do a correlation to get there phase and time relationship. And then smartly combine them to get better signal quality. Clever boy! Do you have in mind that RD(B)S transmits alternative frequencies? This is a feature to enable seamless frequency switch for mobile users (cars). Never thought of it to use it simultaneously. This would spare you a lot of correlation. Yes, that is exactly how I got the idea. So I intend to use RDS. I already have an RDS decoder in place. You still need a correlation for the phase/time relationship but you don't have to correlate every frequency to determine if it is a mirror of your current station. Greetings, Martin Do you have some code already? Patrick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re-writing blocks using intel libraries
Eric Blossom wrote:
On Tue, Dec 11, 2007 at 03:41:46PM -0800, Eugene Grayver wrote:
Please see answers in-line.
Thanks!
General curiosity questions:
Are you using oprofile to measure performance?
I am a bit of a maverick, and for various reasons am using a pure C++
environment. I hacked my own 'connect_block' function (can;t wait for
v3.2, where these will be part of native gr).
The trunk contains C++ code for connect, hier_block2, etc. Some of
the pieces that are still missing include C++ support for the USRP
daughterboards, but Johnathan Corgan is working on that now.
I am measuring the performance using a custom block (gr_throughput)
that simply reports the average number of samples processed per
second.
What h/w platform are you running on / tuning for?
The platform is currently Intel Xeon or Core2 Duo.
You're not trying to run your app on a cache-crippled machine like a
Celeron, are you? ;)
No, very high end.
Which blocks are causing you the biggest problem?
I got a 2x improvement on all the filtering blocks.
If these are FIR filters, were you using gr_fft_filter_{fff,ccc}
or the gr_fir_filter* blocks? The FFT one's are _much_ faster with a
break-even point around 16 taps IIRC.
About a 40% improvement for sine/cosine generation blocks. This
includes gr_expj, gr_rotate.
No surprise there, and that's a great example of SIMD code that should
be in GNU Radio.
Are your problems caused primarily by lack of CPU cycles, cache
misses or mis-predicted branches?
I am not sure, since I am not at all a software expect (mostly dsp/comm).
My guess is that the SSE instructions are not being used (or not used to a
full extent). Even the 'multiply' block is VERY slow compared to a vector
x vector multiplication in the Intel library.
OK.
Some of the gr_blocks
process each sample using a separate function call (e.g.
for (n=0; nnoutput_samples; n++)
scale(in[n])
Replacing this with a single vectorized function call is much faster.
OK.
We would not accept the changes.
That's what I expected. We'll try to contribute the more dsp-centric
blocks such as demodulators.
That would be great! Or if you want to code up an SSE Taylor series
expansion for sine/cosine good to 23-bits or so, we'd love that too ;)
I am working on this in the little spare time I have.
I already got a SSE taylor series for atan2, working in gnuradio.
The atan2 needs some code cleanup and wrapper code to switch implementations
(if (processor=X86, processor supports_SSE2)=optimized else generic)
The sin/cos is far from ready.
Greetings,
Martin
Thanks for telling us about your experience.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ideas for improved FM reception
Daniel Povey wrote: Guys [+girls?], I'm new to the list. I joined because I do research in signal processing (speech recognition) and I have the idea that it ought to be possible to use statistical signal processing to get much better FM radio reception than a normal tuner. I basically want to process the quadrature output (the 2 signals that you get out after multiplying by sin + cos and lopass filtering) in a different way, not just doing atan but doing a bunch of predictive modeling at that stage, assuming the signal is a mix of multiple stations + noise, and trying to separate the signals out. I want to ask this list two things: (1) is anyone aware of anyone having tried something like this in the past (or know what search terms I might use to find this out), and I am working on an optimized FM receiver for gnuradio. At the moment my main concern is getting the processing load down. But I am also going to implement improvements in quality. The first thing I am going to implement is implementing MIMO. That is, using multiple tuners to get signals from multiple antennas and combine these signals to get a better signal quality. (Phase array) The second thing I want to do is detecting if multiple transmitters (at different locations and frequencies) transmit the same radiostation. With a single tuner I can capture all these signals at the same time. Then do a correlation to get there phase and time relationship. And then smartly combine them to get better signal quality. The simplest thing to do is lineup the signals (phase and time shift) and add them up. A better approuch would be to do some statistical analisis like you described. This can be done both before and after frequency demodulation. I don't know yet which one will give better results. Your approuch sounds interesting. Unfortunately I am not a statisticus aor signal modeling expert, but I am very handy with GnuRadio and FFT processing. So maybe we could combine forces. (2) Could anyone give me to work with, the sampled output at the quadrature stage (I assume this would be something like 2 synchronized .wav or a stereo .wav file (does it support stereo?), sampled at quite a high frequency). Dan Walker, Robert CIV NSWC Crane, WC NAE Staff wrote: Daniel - There are a bunch of different types of captured samples at http://www.kd7lmo.net/ground_gnuradio_ota.html. The output isn't .wav, but you can find a format description at the gnuradio website or the tutorial at http://sdr.nd.edu/docs/. Daniel, did this work out for you? If you need more captured signals, I can capture some for you. I can even capture using two tuners / two antenna's or capture two frequencies which transmit the same radio station at the same time. What samplerate do you need/want. The USRP can produce the following samplerates (Samples/second): 800, 533.33, 400, 320, 266.67, 2285714.29, 200, 177.78, 160, 1454545.45, 133.33, 1230769.23, 1142857.14, 106.67, 100, 941176.47, 88.89, 842105.26, 80, 761904.76, 727272.73, 695652.17, 66.67, 64, 615384.62, 592592.59, 571428.57, 551724.14, 53.33, 516129.03, 50, 484848.48, 470588.24, 457142.86, 44.44, 432432.43, 421052.63, 410256.41, 40, 390243.9, 380952.38, 372093.02, 363636.36, 35.56, 347826.09, 340425.53, 33.33, 326530.61, 32, 313725.49, 307692.31, 301886.79, 296296.3, 290909.09, 285714.29, 280701.75, 275862.07, 271186.44, 26.67, 262295.08, 258064.52, 253968.25, 25, for wideband FM usually 32 samples/second is used This is handy because after processing you can decimate by 10 to get a nice 32000 samples/second audiorate Possible output formats: raw complex shorts or raw complex floats the gnuradio raw complex format is just all Real and Imaginary samples interleaved. Re0 Im0 Re1 Im1 Re3 Im3 for complex shorts this mean 16 bit signed short int Real0, 16 bit signed short int Imag0, for complex floats this mans 32 bit float Real0, 32 bit float Imag0, . It is also possible to output the Real and Imaginary samples in separate files file one: Re0 Re1 Re2 ... file two: Im0 Im1 Im2 ... You can convert the complex captured signals into (stereo) wav files with sox - Sound eXchange : universal sound sample translator Sox is available in all linux distributions, and also available for windows. http://sox.sourceforge.net/ I hope this helps, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ambiguity measurements.
Aadil Volkwin wrote: Hi, I intend using the USRP and the TVRX module to recieve FM transmissions, and at this stage digitise the recieved signal and perform the ambiguity measurement on the digitised data in order to produce, doppler, range and amplitude maps. Does GnuRadio have modules that will perform these functions for me? Has anyone attempted this or part of this and related measurements? If So I would greatly appreciate your advice and assistance in this regard. You could have a look at the old gr-radar code. It is meant as a starting port for doing passive radar with gnuradio. http://gnuradio.org/trac/browser/gnuradio/limbo/gr-radar Note that this code was moved out of trunk because it needs some protability fixes. Greetings, Martin Regards, Aadil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] patch to extended oscope to enable dualchan and complex mode on basicRX and basicTX
Eric Blossom wrote: On Fri, Oct 26, 2007 at 07:14:48PM +0200, Martin Dvh wrote: Hi all, inspired by the question of George Nychis I extended the usrp_oscope.py script to enable dualchannel and complex mode for basicRX and LFRX. You can find a patch and the complete modified script at: http://www.olifantasia.com/projects/gnuradio/mdvh/oscope_basicrx_dualchan/ You can copy the new script or apply the patch to your current gr-utils/src/usrp_oscope.py. The patch should apply cleanly if you have version 3.1 of gnuradio. There are two new commandline options: -C, --basic-complex Use both inputs of a basicRX or LFRX as a single Complex input channel -D, --basic-dualchan Use both inputs of a basicRX or LFRX as seperate Real input channels With --basic-complex both inputs of a basicRX or LFRX are enabled to form a single complex channel (I=input A, Q=input B) With --basic-dualchan both inputs are treated seperately and so you get two input real channels. (I1=input A, Q1=0, I2=input B, Q2=0) The difference between the two options becomes clear when you set a nonzero frequency. With the dualchannel option you can set the frequence for each channel seperately. With the complex option you can set only one frequency. If you set this to nonzero, this is only usefull if you actually have an I and Q signal connected to both inputs. Greetings, Martin Thanks Martin! Can you please go ahead and commit your patch? Done, I think this is an improvement but maybe it can still be improved further. The disadvantage of my current patch is that knowledge about daughterboards and muxvalues is in the oscope script. It is always better to have this info/knowledge in one place, and one place only. This would mean we would have to extend the code in gr-usrp. What do you think about the following possble setup: for basicRX and LFRX the subdev code could be extended the following way. subdevspec A:0 use input A of daughteboard A as a real input iscomplex() should return False subdevspec A:1 use input B of daughteboard A as a real input iscomplex() should return False subdevspec A use input A and B of daughteboard A as a complex input iscomplex() should return True (Note however this would change the API. At the moment you actually get A:0 when you specify A. We could also do something like A:real (which would be an alias for A:0) and A:complex which would give a complex input using both inputs. It gets more complicated when you want to use multiple inputs as multiple channels. You would want to be able to call usrp.determine_rx_mux_value() with multiple subdev specs for example: usrp.determine_rx_mux_value(self.u, (options.rx_subdev_spec0,options.rx_subdev_spec1)) What do you think? Martin Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Encoder Integration
S Mande wrote: Hi, I have implemented a convolutional encoder and a viterbi decoder in Verilog and am trying to integrate it with the existing GNU Radio software and make it available to everyone, once I integrate it. My encoder takes in the input binary bits and generates encoded binary bits, based on defined parameters. I am first focusing on integrating the encoder with the GNU Radio software. My understanding from the code is that the following steps are performed while transmitting ( i.e. benchmark_tx.py, transmit_path.py, pkt_py, modulation_utils.py ) : 1)Generate random bits. 2)Map bits to symbols (gmsk or any other modulation ) 3)Convolve the symbols with a wave and taking discrete samples (Sampling) 4)Combine the step (3) samples with header information and make a packet. 5)Pass it on to the FPGA. Generating bits and sending it to FPGA for encoding using my encoder module and sending the encoded bits back to follow the above chain will possibly not make sense as I am overusing the bus resources, which would defeat the purpose of encoding in Verilog/FPGA . (bus usage should decrease by transmitting raw bits across the bus). So, should I pass all the above (steps 1 to 5) functionalities into the FPGA i.e. generate, encode, map, convolve inside the FPGA and then pass it on to the existing functionalities in the FPGA ? Or is there a more optimum way to do this ? Well you could still generate the random bits on the host. You should however implement the other steps on the FPGA. There are ways to implement optimized root-raised cosine filters and (fractional) resampler filters in the FPGA if you do BPSK or QPSK. (because you only have +1.0 and -1.0 values) (I have some code for that if you need it) You said you already had implemented a convolutional encoder and a viterbi decoder in Verilog. So it seems like combining all the parts is what has to be done. Where exactly are you stuck. Any inputs on the above would help me. I am stuck with this problem for quite some time now. Maybe it would help if you published what you got now somewhere, so people can help by looking at your code. Please correct me if I am going wrong somewhere. Thanks. Best Regards, S. Mande. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] patch to extended oscope to enable dualchan and complex mode on basicRX and basicTX
Hi all, inspired by the question of George Nychis I extended the usrp_oscope.py script to enable dualchannel and complex mode for basicRX and LFRX. You can find a patch and the complete modified script at: http://www.olifantasia.com/projects/gnuradio/mdvh/oscope_basicrx_dualchan/ You can copy the new script or apply the patch to your current gr-utils/src/usrp_oscope.py. The patch should apply cleanly if you have version 3.1 of gnuradio. There are two new commandline options: -C, --basic-complex Use both inputs of a basicRX or LFRX as a single Complex input channel -D, --basic-dualchan Use both inputs of a basicRX or LFRX as seperate Real input channels With --basic-complex both inputs of a basicRX or LFRX are enabled to form a single complex channel (I=input A, Q=input B) With --basic-dualchan both inputs are treated seperately and so you get two input real channels. (I1=input A, Q1=0, I2=input B, Q2=0) The difference between the two options becomes clear when you set a nonzero frequency. With the dualchannel option you can set the frequence for each channel seperately. With the complex option you can set only one frequency. If you set this to nonzero, this is only usefull if you actually have an I and Q signal connected to both inputs. Greetings, Martin Below is the original question which inspired m to write this modification. George Nychis wrote: Hey all, On the basic daughterboards, if I connect two coax cables to TX-A and TX-B on a single daughterboard and transmit, I can view the transmission using an oscope on both connectors. In other words, it doesn't matter which of the two ports I connect to. However, if I fire up the GNU Radio oscope with a BasicRX, I must connect either TX-A or TX-B to RX-A. Is RX-B disabled by default? Is it possible to enable RX-A and RX-B? Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] found problem with std_4rx_0tx.rbf and unrelated bugs in rx_chain.v
Hans Glitsch wrote: Ok, I found that the bug was introduced into std_4rx_0tx.rbf at version 4848. Version 4287 does not have the problem. The changes in changeset 4713 looked suspicious. Refactored FPGA *.vh files. Moved common pieces to toplevel/include. But I couldn't find any obvisous mistakes there. Then I generated a complete diff between r 4287 and 4848 the following way: $ cd usrp $ svn diff -r 4287:4848 But I didn't find any mistakes there even. It is also possible that something went wrong when generating std_4rx_0tx.rbf. Has anybody tried rebuilding it (with Quartus II) with the current trunk code (r 4848 or later) When looking further into the code for the RX_chain I did find a few (unrelated) bugs in usrp/fpga/sdr_lib/rx_chain.v When the NCO is turned off (RX_NCO_ON is not defined) then sample_strobe is assigned to 1 However sample_strobe is an input, so this will fail. The same mistake is made for decimator_strobe when the CIC is turned off. It can be solved by adding wires for sample_strobe_internal and decimator_strobe_internal and assigning to that in stead. This probably hasn't surfaced because at the moment NCO and CIC are always enabled. see lines 31,32, 64 and 74 below. usrp/fpga/sdr_lib/rx_chain.v 31 input sample_strobe, 32 input decimator_strobe, ... 51 `ifdef RX_NCO_ON 52 phase_acc #(FREQADDR,PHASEADDR,32) rx_phase_acc 53 (.clk(clock),.reset(reset),.enable(enable), 54 .serial_addr(serial_addr),.serial_data(serial_data),.serial_strobe(serial_strobe), 55.strobe(sample_strobe),.phase(phase) ); 56 57 cordic rx_cordic 58 ( .clock(clock),.reset(reset),.enable(enable), 59 .xi(i_in),.yi(q_in),.zi(phase[31:16]), 60 .xo(bb_i),.yo(bb_q),.zo() ); 61 `else 62 assign bb_i = i_in; 63 assign bb_q = q_in; 64 assign sample_strobe = 1; 65 `endif // !`ifdef RX_NCO_ON 66 67 `ifdef RX_CIC_ON 68 cic_decim cic_decim_i_0 69 ( .clock(clock),.reset(reset),.enable(enable), 70 .rate(decim_rate),.strobe_in(sample_strobe),.strobe_out(decimator_strobe), 71 .signal_in(bb_i),.signal_out(hb_in_i) ); 72 `else 73 assign hb_in_i = bb_i; 74 assign decimator_strobe = sample_strobe; 75 `endif Greetings, Martin Hans - Original Message - From: Johnathan Corgan [EMAIL PROTECTED] To: Eric Blossom [EMAIL PROTECTED] Cc: Hans Glitsch [EMAIL PROTECTED]; discuss-gnuradio@gnu.org Sent: Wednesday, October 24, 2007 10:57 AM Subject: Re: [Discuss-gnuradio] found problem with std_4rx_0tx.rbf Eric Blossom wrote: I can reproduce it. There's definitely something off with std_4rx_0tx.rbf. I've opened ticket:195 http://gnuradio.org/trac/ticket/195 [This is all I'm going to do about this right now.] Since that RBF has only been re-synthesized a couple of times in the last year or so, it would be straightforward to manually replace the file with the versions from 3.0 series, and see where the problem started. I think there will be at most 4 versions to test. You wouldn't need to change the host code any, just get the proper RBF from the repository and manually install into $prefix/share/usrp/rev2 and 4. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.9/1090 - Release Date: 10/24/2007 8:48 AM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strategy advice
Steven Clark wrote: All- I was hoping I could get some advice on what is a good block-design strategy for the following problem. I have two streams of complex samples coming in. I want a block or sequence of blocks which outputs the cosine of the phase difference between the two input streams. If we could assert that both input streams are unit length, then one way to do it would be to conjugate one stream, then complex multiply the two together, then take the real part of the output. But if the input streams are NOT normalized, then the product will likely not be unit length either, and this won't work. We could try and normalize the complex product, but the universe explodes if it has length 0 (divide by 0). Also, this would require a slow sqrt (?) If your input streams have a rather stable amplitude you could put a slow AGC in front of them to normalize. You shoudl make sure that the vectors are length 1.0. I remember using this trick and that I had to set the reflevel of the agc to 1/srt(2) (in stead of 1.0) or something like that to get it to output vectors of length 1.0. This will however not be as accurate as actually doing the slow sqrt() for every sample. Is the best approach to just get the phase of the complex product via fast_atan2f, then take the cos of that? I am working on an SSE optimized version of atan2. It is not fully checked and so not ready for primetime but maybe this would work for you. How much in a hurry are you? Do any basic math/trig functions (cos, atan2, sqrt, etc) exist at the python block level, or do I have to delve into C to use them? Makefiles are scary :( No they are not ;-) Get them to know better and they will be your friends. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximal signal bandwith for the usrp
JALLON Pierre 201932 wrote: Dear all, According the USRP v4 description: http://www.ettus.com/downloads/usrp_v4.pdf http://www.ettus.com/downloads/usrp_v4.pdf the usrp is able to process signals up to 16MHz. As the USB port is limited to 60MB/s, and if the samples are coded on 32 bits (16 for Q and 16 for I), the maximal bandwidth equals 15MHz. The USRP can code signals as 32 bits (16 for Q and 16 for I) In this case the usrp is able to process signals up to 8 MHz. The USRP can also code signals as 16 bits (8 for Q and 8 for I) In that case the usrp is able to process signals up to 16 MHz. Which version is correct? Furthermore, considering that the first ADC works at 64Ms/s, the available rate for the USB equals: 32/2 (is it available ?) 32/3 32/4 32/5 ... 32/256 Am I right ? the first ADC works at 64Ms/s, the available rate for the USB equals: 64/4(64/4 is only available with halfband filter disabled) 64/8 64/12 64/16 64/20 ... 64/256 The halfband filter in the usrp firmware has a minimal decimation rate of 8. That is why 64/4 is only available with halfband disabled. Martin Thank you for your answers, Pierre Jallon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] build system, generate_all.py doesn't work when building out-of-sourcedir
Hi all, I allways build in a subdir of the sourcedir. svn checkout cd trunk ./bootstrap mkdir build cd build ../configure make Usually this works well, but I found out that this doesn't work if you change something in the generate*.py scripts. /gnuradio-core/src/lib/filter/generate_all.py Is the script run by the makefile in build/gnuradio-core/src/lib/filter to generate build/gnuradio-core/src/lib/filter/makefile.gen (amongst other things) But the makefile.gen which is included is in gnuradio-core/src/lib/filter (note this is in the sourcedir, not the builddir) So the old makefile.gen is included. I am not an automake wizard but I wondered if this is solvable. The only workaround I have is. first configure and build in the sourcedir. Do a make distclean and then configure and build in the builddir. cd trunk ./configure make make clean make distclean cd build (this is my builddir) ../configure make Here follows a snippet from gnuradio-core/src/lib/filter/Makefile.am where some of this magic happens. # include $(srcdir)/Makefile.gen include Makefile.gen $(GENERATED_H) $(GENERATED_I) $(GENERATED_CC): $(CODE_GENERATOR) PYTHONPATH=$(top_srcdir)/gnuradio-core/src/python srcdir=$(srcdir) $(PYTHON) $(srcdir)/generate_all.py BUILT_SOURCES = $(GENERATED_H) $(GENERATED_I) $(GENERATED_CC) Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
