Re: [Discuss-gnuradio] multi-machine sweeper
Tue, Mar 27, 2007 at 11:32:38AM +0200, Trond Danielsen skribis: > 2007/3/26, Brett L. Trotter <[EMAIL PROTECTED]>: > >In the long run- perhaps a python app that sits on a socket and changes > >the frequency at the command of the other side of the link, which is doing > >a loop through the daughtercard frequencies and then keeps track of the > >SNR or the db above baseline or something. The quick and dirty way would > >be to have the RX hop to the frequency, listen to baseline with > >transmitter not going, record level, ask TX side to go to same frequency, > >measure again- record the result and then move to the next frequency. > > It should be possible to run a SOAP server as a thread in a GNU Radio > application. The simplest possible soap server looks like this: Why not something even simpler like RPyC ? http://rpyc.wikispaces.com -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The coming deluge of CPU cycles
On Wed, 26 Jul 2006, Marcus Leech wrote: [...] > o Is it time to think about moving away from USB for USRP? Perhaps to >PCI-X 2.0, or PCI-Express? http://comsec.com/wiki?USRPnotUSB -- Stephane PS: I would cast my vote for GigE. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
On Mon, Mar 13, 2006 at 03:52:25PM +0100, Martin Dvh wrote: [..] > > The code should be portable. I was missing the native Win32 call for > > mutex_trylock, so someone will have to find it, and define > > OMNI_MUTEX_TRYLOCK_IMPLEMENTATION in src/lib/omnithread/ot_nt.h, > > with appropriate semantic (return value). > I think you can do this with TryEnterCriticalSection It does fit indeed. It has just been checked in. Bob, Thomas, please cvs update gnuradio-core AND gr-audio-portaudio at same time since I changed the logic of omni_mutex::trylock (returns true if it grabbed the lock), in order to comply with comment in omnithread.h. > You could also use the omni_semaphore class defined in > gnuradio-core/src/lib/omnithread/nt.cc > This latter one uses CreateSemaphore and WaitForSingleObject with some > wrapper code. > (you probably have to change all defines if you change to using > omni_semaphore) The gr-audio-portaudio code is using omni::mutex and omni::cond calls. Actually, they are not used for mutual exclusion, but simply as a notification mean (there's more room/there's more data in the ringbuffer). Good Lu*k Martin for your presentation. We can wait next week to see whether James Brown sounds even better with gr-audio-portaudio under Windows ;-) -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Simple example gr-audio-portaudio
On Mon, Mar 13, 2006 at 02:36:24AM -0500, Robert McGwier wrote: > Stephane: > > Can you give a modification of audio_copy.py and audio_play.py that use > jack and portaudio? I do not seem to get the required syntax. Here we go. Cc'd to the list since this is going to be a FAQ :-) Index: mono_tone.py === RCS file: /sources/gnuradio/gnuradio-examples/python/audio/mono_tone.py,v retrieving revision 1.4 diff -u -b -B -w -p -r1.4 mono_tone.py --- mono_tone.py3 Mar 2006 01:26:52 - 1.4 +++ mono_tone.py13 Mar 2006 07:49:56 - @@ -21,7 +21,7 @@ # from gnuradio import gr -from gnuradio import audio +from gnuradio import audio_portaudio from gnuradio.eng_option import eng_option from optparse import OptionParser @@ -44,7 +44,7 @@ class my_graph(gr.flow_graph): ampl = 0.1 src0 = gr.sig_source_f (sample_rate, gr.GR_SIN_WAVE, 650, ampl) -dst = audio.sink (sample_rate, options.audio_output) +dst = audio_portaudio.sink (sample_rate, 1, options.audio_output) self.connect (src0, (dst, 0)) Index: multi_tone.py === RCS file: /sources/gnuradio/gnuradio-examples/python/audio/multi_tone.py,v retrieving revision 1.3 diff -u -b -B -w -p -r1.3 multi_tone.py --- multi_tone.py 10 Oct 2005 23:17:52 - 1.3 +++ multi_tone.py 13 Mar 2006 07:49:56 - @@ -21,7 +21,7 @@ # from gnuradio import gr -from gnuradio import audio +from gnuradio import audio_portaudio from gnuradio.eng_option import eng_option from optparse import OptionParser @@ -63,7 +63,7 @@ class my_graph(gr.flow_graph): # progression = (7, 11, 1, 5) progression = (7, 11, 1, 5, 9) -dst = audio.sink (sample_rate, options.audio_output) +dst = audio_portaudio.sink (sample_rate, 1, options.audio_output) max_chan = dst.input_signature().max_streams() if (max_chan == -1) or (max_chan > limit_channels): -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
On Sun, Mar 12, 2006 at 07:14:15PM -0800, Thomas Schmid wrote: > I tried your code on Mac OS X 10.4 and I get pretty far (everything > compiles and isntalls after some hacking), but when I execute an audio > example, I get this error: > > 19:04 [EMAIL PROTECTED]:~/gnuradio/gr-build/gnuradio-examples/python/audio$ > ./dial_tone.py > Traceback (most recent call last): > File "./dial_tone.py", line 55, in ? > my_graph().run() > File "./dial_tone.py", line 48, in __init__ > dst = audio.sink (sample_rate, options.audio_output) > File > "/Users/thomas/gnuradio/gr/lib/python2.4/site-packages/gnuradio/audio_portaudio.py", > line 235, in sink > return _audio_portaudio.sink(*args) > NotImplementedError: No matching function for overloaded 'sink' > > Now I am stuck. Any idea why this happens or what could be wrong? Most likely the arguments are not what is expected. Looking at gr-audio-portaudio/src/audio_portaudio.i, they should be: audio_portaudio_sink (int sampling_freq, int ok_to_block, const std::string device_name ) device_name defaults to "", and ok_to_block defaults to 1. Eric, the argument order may be tweaked. > Here is what I did, if anyone wants to repeat it: > > - install xcode 2.2 > - install coreaudio sdk 1.4.3 > - downloaded portaudio V19 and applied patch > - fixed small -framework error on line 144 of configure.in (remove > double -framework) > - fixed also -framework error in Makefile.in We should definitely add automake/libtool support to portaudio. > - removed the portaudio.pc directives which were added from the patch > (no portaudio.pc target in the makefile, will do it manually later on. > i think it is missing.) Look at my other mail. This should not be necessary if built from scratch. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
Hi Thomas, On Sun, Mar 12, 2006 at 06:30:19PM -0800, Thomas Schmid wrote: > Hi Stephane, > > Is it possible that the portaudio patch of yours is missing the > portauido.pc target? I get errors if I want to install it, i.e., it > tells me that there is no portaudio.pc target. Have you run "aclocal ; autoconf" before running again the configure script of portaudio? This should take care of making to appear the portaudio.pc file. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gri_ringbuffer.{h,cc}
On Sun, Mar 12, 2006 at 06:03:39PM -0800, Eric Blossom wrote:
> On Sun, Mar 12, 2006 at 10:20:16PM +0100, Stephane Fillod wrote:
> >
> > - against gnuradio-core: ot_gri_ringbuffer.patch
> > * src/lib/general/gri_ringbuffer.{cc,h},
> > src/lib/general/Makefile.am: new lockless ringbuffer (single
> > reader/single writer) taken from JACK software (GPL).
>
> Bob and Frank,
>
> Didn't the JACK ringbuffer code cause you problems when pushing "part
> of a float" into it. I.e., there was room for 3 bytes, but not all
> four. If this is true, how did you fix it? Specialize for only
> floats? "Yet another ringbuffer implementation" that doesn't have
> the problem? I can't see an occasion when we'd need anything other
> than floats.
>Answering my own question, I guess as long as you use write_space and
>round down prior to writing, everything should work fine.
Yes, this is exactly what is done in gr-audio-{jack,portaudio}.
Look at the lines like this:
write_space -= write_space%buffer_size_bytes;
write_size = std::min(write_space, (unsigned int)work_size);
The ringbuffer max usable size is an exponent of two, minus one. Hence you
end up pushing partial objects into it if no care is taken when the
ringbuffer is full.
In the end, no need to specialize it.
--
Stephane
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
On Sun, Mar 12, 2006 at 02:36:21PM -0500, Robert McGwier wrote:
> That is why I put the message out. It will be good to have a working
> starting point.
Okay, there it is. Just checked in to gr-audio-portaudio repository.
It's somewhat working, but there's still some static in the audio
output (tested with ALSA playback, mono and stereo). Some more work
is needed.
You will need the attached patchs:
- against gnuradio-core: ot_gri_ringbuffer.patch
* src/lib/omnithread/omnithread.h: add omni_mutex::trylock
* src/lib/general/gri_ringbuffer.{cc,h},
src/lib/general/Makefile.am: new lockless ringbuffer (single
reader/single writer) taken from JACK software (GPL).
- against portaudio-V19(CVS): portaudio-pkg-config.patch
* pkg-config .pc file with proper THREAD_FLAGS
The code should be portable. I was missing the native Win32 call for
mutex_trylock, so someone will have to find it, and define
OMNI_MUTEX_TRYLOCK_IMPLEMENTATION in src/lib/omnithread/ot_nt.h,
with appropriate semantic (return value).
The gri_pa_find_device_by_name() function will have to be made more
smart, like accepting which HostApi (ALSA, JACK, ..) is to be chosen,
and which device from this API. A syntax will have to be agreed upon,
like "ALSA:hw:0" or "OSS:/dev/dsp1".
Have fun,
--
Stephane
Index: src/lib/general/Makefile.am
===
RCS file: /sources/gnuradio/gnuradio-core/src/lib/general/Makefile.am,v
retrieving revision 1.83
diff -u -b -B -w -p -r1.83 Makefile.am
--- src/lib/general/Makefile.am 23 Feb 2006 21:26:29 - 1.83
+++ src/lib/general/Makefile.am 12 Mar 2006 20:55:14 -
@@ -187,6 +187,7 @@ libgeneral_la_SOURCES = \
gri_char_to_float.cc\
gri_uchar_to_float.cc \
gri_interleaved_short_to_complex.cc \
+ gri_ringbuffer.cc \
malloc16.c
libgeneral_qa_la_SOURCES = \
@@ -302,6 +303,7 @@ grinclude_HEADERS = \
gri_lfsr_32k.h \
gri_short_to_float.h\
gri_char_to_float.h \
+ gri_ringbuffer.h\
gri_uchar_to_float.h\
random.h
Index: src/lib/omnithread/omnithread.h
===
RCS file: /sources/gnuradio/gnuradio-core/src/lib/omnithread/omnithread.h,v
retrieving revision 1.1.1.1
diff -u -b -B -w -p -r1.1.1.1 omnithread.h
--- src/lib/omnithread/omnithread.h 10 Apr 2004 18:00:52 - 1.1.1.1
+++ src/lib/omnithread/omnithread.h 12 Mar 2006 20:55:19 -
@@ -145,6 +145,7 @@ class omni_thread;
#if (!defined(OMNI_MUTEX_IMPLEMENTATION)|| \
!defined(OMNI_MUTEX_LOCK_IMPLEMENTATION) || \
+ !defined(OMNI_MUTEX_TRYLOCK_IMPLEMENTATION)|| \
!defined(OMNI_MUTEX_UNLOCK_IMPLEMENTATION) || \
!defined(OMNI_CONDITION_IMPLEMENTATION)|| \
!defined(OMNI_SEMAPHORE_IMPLEMENTATION)|| \
@@ -186,6 +187,10 @@ public:
inline void lock(void){ OMNI_MUTEX_LOCK_IMPLEMENTATION }
inline void unlock(void) { OMNI_MUTEX_UNLOCK_IMPLEMENTATION }
+inline int trylock(void) { return OMNI_MUTEX_TRYLOCK_IMPLEMENTATION }
+ // if mutex is unlocked, lock it and return 1 (true).
+ // If it's already locked then return 0 (false).
+
inline void acquire(void) { lock(); }
inline void release(void) { unlock(); }
// the names lock and unlock are preferred over acquire and release
Index: src/lib/omnithread/ot_posix.h
===
RCS file: /sources/gnuradio/gnuradio-core/src/lib/omnithread/ot_posix.h,v
retrieving revision 1.1.1.1
diff -u -b -B -w -p -r1.1.1.1 ot_posix.h
--- src/lib/omnithread/ot_posix.h 10 Apr 2004 18:00:52 - 1.1.1.1
+++ src/lib/omnithread/ot_posix.h 12 Mar 2006 20:55:19 -
@@ -57,6 +57,9 @@ extern "C" void* omni_thread_wrapper(voi
#define OMNI_MUTEX_LOCK_IMPLEMENTATION \
pthread_mutex_lock(&posix_mutex);
+#define OMNI_MUTEX_TRYLOCK_IMPLEMENTATION \
+pthread_mutex_trylock(&posix_mutex);
+
#define OMNI_MUTEX_UNLOCK_IMPLEMENTATION\
pthread_mutex_unlock(&posix_mutex);
--- /dev/null 2006-03-10 00:02:48.821312048 +0100
+++ src/lib/general/gri_ringbuffer.h2006-03-12 20:05:46.0 +0100
@@ -0,0 +1,203 @@
+/* -*- c++ -*- */
+/*
+ * Copyright 2006 Free Software Foundation, Inc.
+ *
+ * This file is part of GNU Radio
+ *
+ * GNU Radio is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * GNU Radio is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the
Re: [Discuss-gnuradio] FFTW 3.1/ PortAudio
On Sun, Mar 12, 2006 at 01:29:55PM -0500, Robert McGwier wrote: [..] > I am looking for a bug in my callback under portaudio on DttSP. This > will enable us to cross platform DttSP on linux, bsd, mac, and wintel. > I have built gr-audio-portaudio but I want to make sure that it supports gr-audio-portaudio ? I am on it. Have you done something more than what is in the current CVS repository? I rewrote something, and it's almost done (it would have been if there was no rugby game this afternoon :). In a way, the API is similar to JACK. The first samples are coming out. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
On Wed, Mar 08, 2006 at 12:26:07AM -0800, Eric Blossom wrote: > On Wed, Mar 08, 2006 at 02:18:35AM -0500, Frank Brickle wrote: > > Eric Blossom wrote: > > > > >Using LD_ASSUME_KERNEL=2.4.19 effectively forces the old (pre-NPTL) > > >behavior, which means that acquiring an uncontested mutex requires a > > >trip to the kernel. I believe it also means that mutexes won't work > > >in shared memory across process boundaries. Those seem like total > > >losers to me... Who has measured the cost of pre-NPTL(aka LinuxThread) mutexes in a typical GNU Radio application ? Right now, do we need mutexes across process boundaries (mutexes across thread are fine) ? > > This adds up to: futexes don't work (yet). Is that right? > > I guess that's the real question. > > My understanding is that they work, it's just a question of how they > work vis-a-vis real time. In our case I'm not worried about issues > such as priority inversion on mutexes. I assume all our signal > processing threads will be running at the same pri and waking up > anybody who's waiting will be fine. I just want to ensure that I run > before the X-server. SCHED_FIFO is necessary but not enough for stuff like X-server. Indeed, some badly written video drivers can call cli/sti directly from user-space on x86 systems (provided iopl succeeded). Binary-only drivers can hurt the same way. Unfortunately, hard-RT solutions like Xenomai can't do much in that case, because they can't virtualize the masking. Otherwise Xenomai is doing great, even with loaded X-server and knee-bending activity. cli/sti pairs are not the only latency killers. This page[3] tries to list them for hard-RT systems. One big culprit encountered by hard-RT developers on common PCs is the SMI subsystem. The interrupt handler for a System Management Interrupt (SMI) runs from a protected memory space (SMRAM), so the OS has no access to this handler code. SMI is primarily used for ACPI and APM support. It can be used for USB legacy support (USB keyboard, disk, etc.). It has been seen SMI eating up several *hundred* of *milliseconds* ! [3] http://rtai.dk/cgi-bin/gratiswiki.pl?Latency_Killer > > > I'm still confused about a couple of things. On one hand the holy grail > > appears to be getting the number of frames in a jack buffer down to 64 > > so as to minimize the roundtrip latency. On the other hand you want to > > eliminate xruns. They aren't the same by any means. > > Definitely. In a hard-real-time world, this problem is solvable. Indeed. > At this point, I've got my eye more on minimizing the USRP latency > since it determines the tightest MAC loop we can build on the host. > Basically, I want to make sure that I'm running at a better pri than > the X-server and friends. (This all assumes that I've got sufficient > cycles to actually get the work done in real time.) > > The smallest chunk of work we can conveniently get across the USB is > 128 complex samples (512 bytes). Assuming we're running at 4MS/s > that's 32uS of samples. If we're able to get N uS of CPU every > 32uS, then solving the audio problem shouldn't be a problem ;) I assume you meant 'us' (micro-second), and not micro sample or micro Siemens :-) Talking about getting to the 32us area, this is what the Xenomai/RTAI guys are doing, turning Linux+average PCs into convenient DSP. On non- flawed hardware, one can get better than 10us latency. However, taking only 50% of a 32us period is not going to lead to linear consumption (think context switch, and not only register file). Besides, the bigger the chuncks of data, the more efficient the optimization of data crunching loops, let alone the depth (history necessary for feedback) required by some filtering algorithms. But you know the drill already ;) > (I'm also reviewing chapter 5 of the USB 2.0 spec to see how often > the h/w arbitrates for access to the USB.) Oh btw, the regular Linux USB stack probably won't be able to guarantee 32us latencies. The best bet here, is the usb4rt[3] project for Xenomai, a rewrite of USB stack with hard-RT in mind. [4] http://developer.berlios.de/projects/usb4rt > > It's not clear that minimizing roundtrip latency means much when you're > > using DSP buffers of 512 frames or more. By the same token, in what I've > > observed, the chief culprit for the xruns is the X window system. There > > is a very delicate balancing act going on in the process priorities > > between the audio subsystem and the video subsystem. I'm not convinced > > that running SCHED_FIFO is going to routinely enable the audio subsystem > > to slide in under the video action under all circumstances. > > Taking a look at the output of > > $ ps -eo pid,tid,class,rtprio,ni,pri,comm > > on my system indicates that the X-server is not running with real time > scheduling. Only the migration tasks are. I assume these migrate > tasks across CPUs (this output is from a dual core machine). The > stuff with negative niceness (
Re: [Discuss-gnuradio] Re: USRP Update -- Daughterboard News March 2006!
On Mon, Mar 06, 2006 at 03:53:55PM -0800, Matt Ettus wrote: > > > Why would somebody buy an LFRX or LFTX instead of a BasicRX or > > BasicTX? Do they have an extra gain stage or other feature? > > Reasons you would want the LF boards: > - The Basic boards don't work below about 1 MHz, and you have signals > down to DC. One use would be for LF and VLF radio. Also, if you have > an external RF section which uses direct conversion, you need the LF boards. > > - The LF boards have some of their own antialias filtering. > > - The LFTX will put out more power than the BasicTX. > > Reason you would want the Basic boards: > - You need to deal with signals over 30 MHz. Out of curiosity, will we be able to have a peek at the schematics of the LFRX&LFTX boards like it is possible for the Basic RX&TX boards at http://www.ettus.com/Download.html ? Also, there's no pressure intended, but what is coming up next? FLEX1200 ? Thanks -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gr-audio-jack - mono only?
Hi Ramakrishnan,
I hope you won't mind if I Cc:'d this message to the discuss-gnuradio
list.
On Sun, Mar 05, 2006, Ramakrishnan Muthukrishnan wrote:
> Sorry for more emails..
No problem on that :-)
> I could create a gr_source jack source. But it was only one channel so I
> looked
> at the code and found this:
>
> ...
> ...
>
>d_jack_input_port = jack_port_register (d_jack_client, "in",
> JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput, 0);
> ...
> ...
>
> Can we make this general enough by passing the number of channels while
> creation,
> like
>
> audio_jack.source (sampling_rate, num_channels)
That'd nice. I was just lazy when I wrote the first version of
audio_jack, and I thought the following would do:
from gnuradio import audio_jack
...
# JACK audio as final sink
audio_sink_i = audio_jack.sink (jack_rate, "gr_sink_I")
audio_sink_q = audio_jack.sink (jack_rate, "gr_sink_Q")
# split IQ because JACK audio is only mono
split_IQ = gr.complex_to_float ()
# now wire it all together
..
self.connect (someblock, split_IQ)
self.connect ((split_IQ, 0), audio_sink_i)
self.connect ((split_IQ, 1), audio_sink_q)
It works, but is kind of bad-looking in qjackctl and cumbersome in GR
scripts because of the need to gr.complex_to_float. This could be fixed
in gr-audio-jack with an array of jack descriptors.
Now I'm wondering whether gr-audio-jack has its place, because I realized
gr-audio-alsa can interface with jack through the use of the package
libasound2-plugins (ALSA library additional plugins "jack") as long as
the file ~/.asoundrc contains something like this:
pcm.myjack {
type jack
playback_ports {
0 alsa_pcm:playback_1
1 alsa_pcm:playback_1
}
capture_ports {
0 alsa_pcm:capture_1
1 alsa_pcm:capture_1
#0 gr_sink_I:out
#1 gr_sink_Q:out
}
}
# Usage: aplay -Dplug:myjack foo.wav
The fact the port names of the jackified alsa application (ie. the GR app)
are not known before runtime is one drawback. The name is derived from
application name, PID, whatnot. Maybe I haven't found yet the option to
specify it through alsa manipulators.
Rem: I have no idea of the quality of the libasound jack plugin, esp. with
respect to the distortion of signal in case of resampling, latency, load,
overrun/underun handling, ...
The nice thing about the package libasound2-plugins is that we are able
to interface any legacy digital application (gmfsk, dream, soundmodem,
aptdec, *psk, linrad, acarsd, etc.) with GNU Radio as long as the legacy
application is using ALSA. Some of those app still need to be converted
from OSS to ALSA though.
73
--
Stephane, F8CFE
PS: thanks for the gr-audio-jack package in debian unstable!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Queries regarding FPGA
On Mon, Feb 27, 2006 at 08:28:56AM -0800, Thomas Schmid wrote: > Isn't one of the problems that Linux is not a real time os, i.e., > exact time scheduling is impossible? As far as I know, linux timers > have an accuracy of 1ms (i.e. 1 jiffie in the kernel). If you want to > have shorter delays, you use the udelay function and do a busy wait. > Or is there something that I am missing? nanosleep(2) used to have that wanted passive/active sleep, but it isn't the case anymore with Linux 2.6 kernels. Most of the time, with an appropriate design, you just don't need a real time OS. However, if you are in tight feedback business or alike, and haven't found out a another way, Xenomai[1] under a patched Linux is the solution, with hard accuracy in the order of <10us, task run from user-space, with a POSIX skin API. [1] http://xenomai.org > On 2/26/06, Eric Blossom <[EMAIL PROTECTED]> wrote: > > There is some fairly straight-forward work that can be done to reduce > > the latency of the user mode code, and that's probably a good first > > step. This would also including enabling real-time scheduling for the > > signal processing threads (SCHED_FIFO), reducing the amount of user > > space buffering for the USRP (no need to mess with the generic > > buffering in GNU Radio, it's not the problem), and transfering smaller > > chunks of data across the user/kernel boundary (that that won't help > > throughput!). This step would be very good! If we go the SCHED_FIFO way, it would be neat to be able to enable it on a thread by thread basis. Actually, the Omnithread library has already support for SCHED_FIFO policy for POSIX systems. Since running applications as root is no good, what we're missing here is a wrapping of POSIX libcap in Omnithread/POSIX to gain secheduling priviledges, pretty much the same way JACK is doing it, as explained here[2]. Then, thanks to the realtime-lsm kernel module, regular users of a group can gain access to the SCHED_FIFO policy. The audio guys went before us, the libcap and realtime-lsm package can be found on most moderns distros. The day we leave the SCHED_OTHER safe world, GNU Radio will need to have implemented in its flowgraph scheduler a watchdog to spare at least 1% when choking 100% of the CPU time... [2] http://jackit.sourceforge.net/docs/faq.php#a5 -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Updated code for FT990
Hi Berndt, Thanks for code checked-in about the FT990 and sorry for the mispelling. This is right in time for the Hamlib 1.2.5 release. BTW, you made the same mistake I made couple of month ago, to post on discuss-gnuradio instead of hamlib-developer mailing list :-) No trouble on that, the Reply-To: has been set appropriately. All the best to you "down under". 73 -- Stephane - F8CFE PS: For the GNU Radio gang who may not know Hamlib, this is a radio control library abstracting underlying remote protocol of rigs. More info at http://hamlib.org On Sun, Feb 26, 2006 at 06:09:29PM +1030, Berndt Josef Wulf wrote: > G'day, > > I've updated code supporting the FT990 rig. > > It fixes a bug that caused set_mode() to interchange the RTTY and RTTYR modes. > > It fixes several bugs in get_channel(). in particular the reporting of > transmitter parameters in split modes. Valid values for the channel parameter > are channel number in the range from 0 - 90 or the desired VFO (VFOA, VFOB, > currVFO, MEM) to be queried. A special case is the passing of channel number > 0, which will return the values for the current or last memory channel used. > See source code, ft990.c, for detailed information. > > Enjoy, > > 73 Berndt > VK5ABN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uint64
On Thu, Feb 16, 2006 at 07:17:08PM -0800, Eric Blossom wrote: > On Wed, Feb 15, 2006 at 04:28:48AM +0100, Martin Dvh wrote: > > I am creating a block which needs an unsigned 64 bit int (uint64) in a > > struct > > I want to do this in a cross-platform way but there is no gr_uint64 yet. > > I can just use unsigned long long int, but I am not sure this is save > > (allways 64 bit) > > I can include stdint.h and use uint64_t, but I don't know if this is > > available on every system > > > > The existing gr_types.h file does the following for the current types: > > typedef short gr_int16; > > typedef int gr_int32; > > typedef unsigned short gr_uint16; > > typedef unsigned intgr_uint32; > > > > I am not sure this is save too. > > > > So how to proceed? > > > > Greetings, > > Martin > > Hi Martin, > > I added gr_int64 and gr_uint64 to gr_types.h. > I continued the "unsafe practice" pending a proper config fix. Tedious is the word for the pending fix :-) Please find a patch attached. It has autoconf detection of stdint.h, definitions of types accordingly in gr_types.h and a bunch of #include in the C++ sources files since config.h can not easily be included from header files (multiple inclusion not handled properly). This was the opportunity to shoot couple of mistakes in the form #ifndef HAVE_CONFIG_H #include #endif -- Stephane diff -u -b -B -w -p -r1.41 configure.ac --- configure.ac10 Dec 2005 02:03:54 - 1.41 +++ configure.ac17 Feb 2006 10:18:23 - @@ -81,7 +81,7 @@ AC_HEADER_STDC AC_HEADER_SYS_WAIT AC_CHECK_HEADERS(fcntl.h limits.h strings.h time.h sys/ioctl.h sys/time.h unistd.h) AC_CHECK_HEADERS(linux/ppdev.h sys/mman.h sys/select.h sys/types.h) -AC_CHECK_HEADERS(sys/resource.h) +AC_CHECK_HEADERS(sys/resource.h stdint.h) dnl Checks for typedefs, structures, and compiler characteristics. AC_C_CONST Index: src/lib/runtime/gr_types.h === RCS file: /sources/gnuradio/gnuradio-core/src/lib/runtime/gr_types.h,v retrieving revision 1.4 diff -u -b -B -w -p -r1.4 gr_types.h --- src/lib/runtime/gr_types.h 17 Feb 2006 03:14:11 - 1.4 +++ src/lib/runtime/gr_types.h 17 Feb 2006 10:25:49 - @@ -35,11 +35,29 @@ typedef std::vector gr_vector_ typedef std::vectorgr_vector_void_star; typedef std::vector gr_vector_const_void_star; +/* + * #include must be placed beforehand + * in the source file including gr_types.h for + * the following to work correctly + */ +#ifdef HAVE_STDINT_H +#include +typedef int16_tgr_int16; +typedef int32_tgr_int32; +typedef int64_tgr_int64; +typedef uint16_t gr_uint16; +typedef uint32_t gr_uint32; +typedef uint64_t gr_uint64; +#else +/* + * Note: these defaults may be wrong on 64-bit systems + */ typedef short gr_int16; typedef intgr_int32; typedef long long gr_int64; typedef unsigned short gr_uint16; typedef unsigned int gr_uint32; typedef unsigned long long gr_uint64; +#endif /* HAVE_STDINT_H */ #endif /* INCLUDED_GR_TYPES_H */ diff -u -b -B -w -p -r1.1 ccomplex_dotprod_generic.cc --- src/lib/filter/ccomplex_dotprod_generic.cc 9 Nov 2004 00:29:51 - 1.1 +++ src/lib/filter/ccomplex_dotprod_generic.cc 17 Feb 2006 10:18:25 - @@ -20,6 +20,9 @@ * Boston, MA 02111-1307, USA. */ +#ifdef HAVE_CONFIG_H +#include +#endif #include #include "gr_fir_ccc_simd.h" #include "ccomplex_dotprod_generic.h" diff -u -b -B -w -p -r1.2 complex_dotprod_generic.cc --- src/lib/filter/complex_dotprod_generic.cc 9 Nov 2004 00:29:51 - 1.2 +++ src/lib/filter/complex_dotprod_generic.cc 17 Feb 2006 10:18:25 - @@ -20,6 +20,9 @@ * Boston, MA 02111-1307, USA. */ +#ifdef HAVE_CONFIG_H +#include +#endif #include #include "gr_fir_scc_simd.h" #include "complex_dotprod_generic.h" Index: src/lib/filter/generate_gr_fir_sysconfig.py === RCS file: /sources/gnuradio/gnuradio-core/src/lib/filter/generate_gr_fir_sysconfig.py,v retrieving revision 1.1.1.1 diff -u -b -B -w -p -r1.1.1.1 generate_gr_fir_sysconfig.py --- src/lib/filter/generate_gr_fir_sysconfig.py 10 Apr 2004 18:00:17 - 1.1.1.1 +++ src/lib/filter/generate_gr_fir_sysconfig.py 17 Feb 2006 10:18:26 - @@ -105,6 +105,9 @@ def make_gr_fir_sysconfig_cc (): * Any changes made to this file will be overwritten. */ +#ifdef HAVE_CONFIG_H +#include +#endif #include gr_fir_sysconfig::~gr_fir_sysconfig () Index: src/lib/filter/generate_gr_fir_sysconfig_generic.py === RCS file: /sources/gnuradio/gnuradio-core/src/lib/filter/generate_gr_fir_sysconfig_gene
Re: [Discuss-gnuradio] GNURadio on Windows
Hi Chris, On Sat, Feb 04, 2006 at 03:26:29PM -0500, Robert Roberts wrote: > Is there anyone out there working with GNURadio on Windows with the USRP? Disclaimer: I'm not using the USRP on Windows, just lending a hand in porting the code. Among the lurker on the list, are there any Windows gurus who can help better, starting with, for example, beta-testing the Windows Installer Martin kindly released? Rem: no need to own an USRP to try out GNU Radio on Windows. > The current install files from Martin have one issue with the way that I > install them. When I attempt to run any of the USRP code it looks for > the usrp_prims.dll in the C:\Python24\site-packages directory. The > installer places that file in C:\Program Files\USRP\bin Copying the > file fixes this. Was the C:\Program Files\USRP\bin directory in your PATH? > The audio is very choppy with the WFM_RCV example. I found that going > into the Task Manager and setting Pythons priority to "real time" fixes > this better. Are there any other tweaks out there? Perhaps not enough buffering? Having source/sink in threads helps sometimes. Martin will have better insight on the topic. Cheers, -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Windows Port Error
Hi Joshua, Thanks for the reply. Unfortunately, the code already takes care of using a 64k granularity. Could it be some bigger granularity is needed? -- Stephane On Thu, Jan 12, 2006 at 05:05:50PM -0800, Joshua Lackey wrote: > I don't have the GNU Radio code in front of me, so I'm not sure if this > is the problem, but MSDN says that the lpBaseAddress (the last argument) > is rounded down to a multiple of the system's memory allocation > granularity. (Which is most likely 64k.) > > Is vmcircbuf using at least 64k buffers? Actually, it would have to be > exactly 64k (or a multiple of 64k anyway) for this to work at all. If > the buffer is less, then the address would be rounded down to the same > address you got before. Try setting the buffer size to 64k and > recompile. > > > Quoting Stephane Fillod ([EMAIL PROTECTED]): > > Hi Chris, > > > > > > On Thu, Jan 12, 2006 at 11:18:30AM -0500, Robert Roberts wrote: > > > I ran test_vmcircbuf.exe several times and each time I get the same > > > results, shown below. > > > > > > Testing gr_vmcircbuf_createfilemapping_factory... > > > gr_vmcircbuf_mmap_createfilemapping: non contiguous mmap 003F > > > 003F 0001 0040 > > > > Ah! looking at > > gnuradio-core/src/lib/runtime/gr_vmcircbuf_createfilemapping.cc > > one can see your Windows XP is trying to outsmart us! > > How can it be? Well, the code trys to make 2 (different) mappings of > > the same offset inside paging file. It looks like the OS ignores > > the last argument of MapViewOfFileEx, which is the desired virtual > > address of the mapping. Instead of giving a brand new address (which > > could have been non-contiguous when last argument of MapViewOfFileEx > > is ignored), the OS returns the very same virtual address of the > > first mapping, which has same offset. That's smart, but that's not > > what we want! > > > > So, to sumarise, the machine has a 64-bit CPU (Opteron) with a bunch of > > RAM (>2GB), and a 32-bit OS, Windows XP SP2. Does anyone else on the list > > encountered the same problem under Windows? More important, does anyone > > with a similar machine (Opteron+Windows XP SP2) managed to get GNU Radio > > to work? > > > > I have no clue on how to fix this. Can somebody help? Would someone > > familiar with Windows support forums be keen to ask why MapViewOfFileEx > > does not work as expected, and what alternative we have? > > > > -- > > Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Windows Port Error
Hi Chris, On Thu, Jan 12, 2006 at 11:18:30AM -0500, Robert Roberts wrote: > I ran test_vmcircbuf.exe several times and each time I get the same > results, shown below. > > Testing gr_vmcircbuf_createfilemapping_factory... > gr_vmcircbuf_mmap_createfilemapping: non contiguous mmap 003F > 003F 0001 0040 Ah! looking at gnuradio-core/src/lib/runtime/gr_vmcircbuf_createfilemapping.cc one can see your Windows XP is trying to outsmart us! How can it be? Well, the code trys to make 2 (different) mappings of the same offset inside paging file. It looks like the OS ignores the last argument of MapViewOfFileEx, which is the desired virtual address of the mapping. Instead of giving a brand new address (which could have been non-contiguous when last argument of MapViewOfFileEx is ignored), the OS returns the very same virtual address of the first mapping, which has same offset. That's smart, but that's not what we want! So, to sumarise, the machine has a 64-bit CPU (Opteron) with a bunch of RAM (>2GB), and a 32-bit OS, Windows XP SP2. Does anyone else on the list encountered the same problem under Windows? More important, does anyone with a similar machine (Opteron+Windows XP SP2) managed to get GNU Radio to work? I have no clue on how to fix this. Can somebody help? Would someone familiar with Windows support forums be keen to ask why MapViewOfFileEx does not work as expected, and what alternative we have? -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Windows Port Error
Hi Chris, On Fri, Jan 06, 2006 at 01:48:49PM -0500, Robert Roberts wrote: > I have tried installing your GNURadio for Windows binaries following > the instructions posted on Martins website. BTW, Martin, do you have any plan in packaging a GNU Radio 2.6 release for Windows on CDROM ? I can help you if need be. Are there any other volunteers for this task lurking on the list? Any beta-testers? What about the Knoppix CDROM and GNU Radio 2.6 ? > When I go to run dial_tone.py I get the following error: Actually, you should have run the "make check" first, which should have caught the problem. Maybe you did already? > C:\gnuradio-examples-0.4\python\audio>dial_tone.py > gr_vmcircbuf_mmap_createfilemapping: non contiguous mmap 0133 > 0133 0001 0134 > gr_vmcircbuf_sysv_shm: sysv shared memory is not available > gr_vmcircbuf_mmap_mkstemp: mmap or shm_open is not available > gr_vmcircbuf_mmap_tmpfile: mmap or mkstemp is not available > gr_vmcircbuf_sysconfig: unable to find a working factory! The fact under Windows is the virtual memory circular buffer (vmcircbuf) is not as reliable as under Linux and other *nix-like systems. The gr_vmcircbuf_mmap_createfilemapping method heuristically trys to map a file area twice, hopping both mapping will be contiguous. The few retrys may not get through sometimes. It's nasty. Can you please try to run several times the test_vmcircbuf.exe program and see if it always fails? > Any ideas as to what I may have done wrong? I am going to try to > install it on another machine here in a little while also. What version of Windows are you running ? What CPU ? How much memory? Cheers, -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB2.0 card question
On Thu, Jan 05, 2006 at 03:37:10PM -0500, Philip Balister wrote: > We have a guy trying get his computer to talk to a USRP. Unfortunately > his computer only has USB 1.1 ports. Does anyone have any experience > using a cheap USB2.0 card in such a PC? We are thinking of running out > and grabbing a card and trying it. http://comsec.com/wiki?UsbHostController -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sparc <--> x86 data exchange
On Fri, Dec 16, 2005 at 03:04:01PM -0800, Matt Ettus wrote: [..] > This would actually be a good place to make use of liboil, the library > of optimized inner loops. They have code for all sorts of conversions, > and they pick up MMX and SSE-type optimizations automatically. Indeed. liboil is really promising. I was waiting for GNU Radio 2.6 to be released, and provided you and Eric agree, IMHO it would be a smart move to "outsource" the SIMD speedups to liboil for the next GNU Radio release. It's way easier to develop speedups in liboil, introduce new archs, have them improved by people other than the GNU Radio gang (IOW share efforts and benefits), etc. Right now, I'm creating the missing liboil API entries along with reference implementations. Reference implementations are plain C code which implements the algorithm in a clear, readable, high- precision and always right way. Most of the time, reference implementations are horribly slow. But it's not a problem. Based on the reference prototype, you may write as many optimized implementations as you want. The liboil framework makes it easy to automate testing against the reference implementation and corner cases (spill, alignment, ..). Always wondered whether SSE or 3DNow! is faster on some new AMD chip? Don't care about that, liboil benchmarks at run time your breed(1) of optimized implementations and selects the one which has the best rating. (1) not *genetically* engineered so far, sorry Eric ;-) Expect liboil to gain more momentum, and pass the word among the other SDR projects you may be involved in. One thing I will need quickly is the list of inner loops in the need of optimization (OProfile reports anyone?). This is to begin with creating the API entries and the reference implementations. Then, making it familiar to some ears, liboil is "The library that just keeps getting optimized better". > See http://liboil.freedesktop.org/wiki/FrontPage Definitely worth mentioning! -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] linux dsp development environments
On Thu, Dec 15, 2005 at 04:11:31PM -0500, Darrell Harmon wrote: [..] > I am using the Analog Devices Blackfin with GCC. The blackfin is fairly > high end. My board has a single core at 390MHz, and there is a dual > core part that can run 750MHz. I am not using Linux on it, but an > developing my own RTOS which should be ready within the next month. > The SDR board using this is still a work in progress. I should be > building a prototype soon. Xenomai[1], a free hard real-time OS fused with Linux is being ported to Blackfin. It brings best of both worlds in user-space, yet let you choose whatever skin API you like (RTAI, Posix, VxWorks, pSos, etc. ). Xenomai used to be known as RTAI/Fusion. Xenomai rocks! [1] http://xenomai.org -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help using simple_framer and simple_correlator
> > Nor can I make out how this code counts bits?
> >
> > // return number of set bits in the low 32 bits of x
> > int
> > gr_count_bits32 (int x)
> > {
> > int count = 0;
> >
> > for (int i = 0; i < 32; i++)
> > if (x & (1 << i))
> > count++;
> >
> > return count;
> > }
This is also known as the hamming weight (i.e. the number
of bits set) of a 32-bit word. Here is a faster algorithm:
unsigned int
gr_count_bits32 (unsigned int x)
{
unsigned res = (x & 0x) + ((x >> 1) & 0x);
res = (res & 0x) + ((res >> 2) & 0x);
res = (res & 0x0F0F0F0F) + ((res >> 4) & 0x0F0F0F0F);
res = (res & 0x00FF00FF) + ((res >> 8) & 0x00FF00FF);
return (res & 0x) + ((res >> 16) & 0x);
}
--
Stephane
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [Hamlib-developer] re: Building CVS Version
Oops, sorry, wrong mailing-list :-( PIBKAC On Sat, Nov 19, 2005 at 03:43:50PM +0100, Stephane Fillod wrote: > On Sat, Nov 19, 2005 at 01:31:50PM +0100, Luc Langehegermann wrote: > [..] > > That's what I use now, but it is 'only' a workaround. > > The workaround is not really acceptable. > I've fixed the problem for good in CVS, and tested ok on my system. > Can you please have a try? > > 73 > -- > Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Hamlib-developer] [Patch] Proposed patch for easycom.c
Hi Luc, Your patch has been commited thanks. Would you like to be the maintainer of the easycomm backend? Please use unified (diff -u) patch format next time, it is much more readable. 73 -- Stephane On Sat, Nov 19, 2005 at 01:38:55PM +0100, Luc Langehegermann wrote: > Hi There, > > I did a small modification to the easycom driver. > > Changed the limits to 0..360 fir Azimuth and 0..180 for Elevation. That was > -180.0..180.0 and 0..90. The devices I know about don't have negative azimuth > values. > > 2. In rot_set_position, do not wait for a reply from the controller, as there > will not be one, according to the specifications I found at > http://www.amsat.org/amsat/ftp/software/win32/wisp/easycomm.txt > > Index: easycomm.c > === > RCS file: /cvsroot/hamlib/hamlib/easycomm/easycomm.c,v > retrieving revision 1.6 > diff -r1.6 easycomm.c > 83c83 > < unsigned char cmdstr[64], ackstr[64]; > --- > > unsigned char cmdstr[64]; > 88c88 > < retval = easycomm_transaction(rot, cmdstr, ackstr, sizeof(ackstr)); > --- > > retval = easycomm_transaction(rot, cmdstr, NULL, 0); > 262,263c262,263 > < .min_az = -180.0, > < .max_az = 180.0, > --- > > .min_az = -0.0, > > .max_az = 360.0, > 265c265 > < .max_el = 90.0, > --- > > .max_el = 180.0, > 296,297c296,297 > < .min_az = -180.0, > < .max_az = 180.0, > --- > > .min_az = 0.0, > > .max_az = 360.0, > 299c299 > < .max_el = 90.0, > --- > > .max_el = 180.0, > > > > 73, Luc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Hamlib-developer] re: Building CVS Version
On Sat, Nov 19, 2005 at 01:31:50PM +0100, Luc Langehegermann wrote: [..] > That's what I use now, but it is 'only' a workaround. The workaround is not really acceptable. I've fixed the problem for good in CVS, and tested ok on my system. Can you please have a try? 73 -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AM receiver
Hi, On Mon, Oct 31, 2005 at 10:22:43PM +0300, Gituma Nturibi wrote: [..] > The problem is that I'm on a tight time schedule and require to get the > project up and running soon. So I would like to know what is the best I can > achieve using a PC sound card or some other cheap ADC board. I've updated the http://comsec.com/wiki?GnuRadioHardware page. Please add missing links as they go. > I would also like to know where I can find the code for AM reception > particularly the MW band. Code for the demodulator can be found in gnuradio-examples/python/usrp/am_rcv.py or from applications like Chuck Swiger's HF Explorer[1]. The RfFrontEnd will have to be changed accordingly to what you have. [1] http://webpages.charter.net/cswiger/hfx/index.html Cheers -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] qa_rational_resampler.py fails on Linux/Alpha
Hi, Before diving into the code, does the following "make check" error messages ring a bell to someone? This is CVS current code, compilation went fine (rem: it took ~24 hours because of gnuradio_swig_python.cc with only 128MiB of RAM). All the other checks are ok. The system is GNU/Debian/Linux 2.6 (sid) Alpha EV56. EException exceptions.AssertionError: in > ignored EException exceptions.AssertionError: in > ignored EException exceptions.AssertionError: in > ignored EException exceptions.AssertionError: in > ignored == ERROR: test_004_decim_random_vals (__main__.test_rational_resampler) -- Traceback (most recent call last): File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/qa_rational_resampler.py", line 177, in test_004_decim_random_vals expected_result = reference_dec_filter(src_data, decim, taps) File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/qa_rational_resampler.py", line 42, in reference_dec_filter fg.run() File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", line 113, in run self.start () File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", line 94, in start self.scheduler.start () File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/scheduler.py", line 57, in start thread.start() File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/gr_threading_23.py", line 414, in start _start_new_thread(self.__bootstrap, ()) error: can't start new thread == ERROR: test_005_interp_random_vals (__main__.test_rational_resampler) -- Traceback (most recent call last): File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/qa_rational_resampler.py", line 209, in test_005_interp_random_vals expected_result = reference_interp_filter(src_data, interp, taps) File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/qa_rational_resampler.py", line 53, in reference_interp_filter fg.run() File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", line 113, in run self.start () File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", line 94, in start self.scheduler.start () File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/scheduler.py", line 57, in start thread.start() File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/gr_threading_23.py", line 414, in start _start_new_thread(self.__bootstrap, ()) error: can't start new thread == ERROR: test_006_interp_decim (__main__.test_rational_resampler) -- Traceback (most recent call last): File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/qa_rational_resampler.py", line 236, in test_006_interp_decim expected_result = reference_interp_dec_filter(src_data, interp, decimation, taps) File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/qa_rational_resampler.py", line 65, in reference_interp_dec_filter fg.run() File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", line 113, in run self.start () File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", line 94, in start self.scheduler.start () File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/scheduler.py", line 57, in start thread.start() File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/gr_threading_23.py", line 414, in start _start_new_thread(self.__bootstrap, ()) error: can't start new thread == ERROR: test_101_interp (__main__.test_rational_resampler) -- Traceback (most recent call last): File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/qa_rational_resampler.py", line 272, in test_101_interp self.fg.run() File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", line 113, in run self.start () File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", line 94, in start self.scheduler.start () File "/home/fillods/RA/rigctrl/gnuradio/gnuradio-core/src/python/gnuradio/gr/scheduler.py", line 57, in start
Re: [Discuss-gnuradio] Problem in CVS download
On Sat, Oct 29, 2005 at 09:37:49AM -0700, sudhakar kanuri wrote: > Hi, > I am unable to download usrp code from CVS.I am > seeing the following problem. > Press Enter at the Password prompt. > Logging in to > :pserver:[EMAIL PROTECTED]:2401/cvsroot/opensdr > CVS password: > cvs [checkout aborted]: end of file from server > (consult above messages if any) > FAILED: cvs -z3 > -d:pserver:[EMAIL PROTECTED]:/cvsroot/opensdr > co -P usrp > Traceback (most recent call last): > File "./checkout", line 117, in ? > main () > File "./checkout", line 113, in main > checkout (options.anon, options.user, > options.exclude, options.include, options.options) > File "./checkout", line 78, in checkout > doit (cmd) > File "./checkout", line 50, in doit > raise RuntimeError > RuntimeError Anonymous CVS servers can be very loaded at time. Try again the CVS command. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "Failed to set initial frequency" and SDCC 2.5.0
On Thu, Oct 27, 2005 at 04:34:04PM -0700, Eric Blossom wrote: [...] > > 2) Can SDCC 2.5.0 be used, or is 2.4.0 an absolute must? > > I haven't tested with SDCC 2.5.0. SDCC 2.5.0 seems to be fine here (Debian/unstable). Talking about usrp_oscope.py, I get also this message when doing File->Exit, but never minded since it's on exit. Glibc is version 2.3.5. *** glibc detected *** double free or corruption (!prev): 0x08813870 *** -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] support for comedi? (yes, ->new module!)
Gang, You will find at savannah a new GNU Radio module: gr-comedi. This is both source and sink blocks for COMEDI http://www.comedi.org To initally check it out: $ cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/gnuradio co -P gr-comedi It has been tested with comedilib-0.7.22 under Debian, with a dummy driver "comedi_test" version 0.7.70. The dummy driver was generating a continuous sawtooth wave, which was displayed by a hacked comedi_oscope.py. Only one channel was tested, but the source can support more. The comedi_sink hasn't been tested since I don't own the appropriate hardware. I'm not sure about the mmap for the write method too. So feedback and patches are welcome! Have fun, -- Stephane PS: here's a suggested project for a hungry student: develop a COMEDI (kernel) driver for the USRP. A USB 2.0 driver example exists already, see http://www.linux-usb-daq.co.uk ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] resampler block (DRM ok!)
Howdy Berndt, Berndt Josef Wulf wrote: > quick question: I'm trying to build Dream DRM but it appears to need a > different version of fftw as it can't detect fftw_create_plan in fftw3. Which > version are you using? Dream DRM is based on fftw2. I'm using version 2.1.3-16 under GNU/Debian. What version of Dream DRM are you building ? I worked with 1.2.5cvs. Are you building under NetBSD? I've heard Dream DRM has been ported already to FreeBSD. Cheers, -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] resampler block (DRM ok!)
On Tue, Oct 04, 2005 at 04:58:01PM -0700, Eric Blossom wrote: [..] > The _fff case mostly works. Look for FIXME's in > qa_rational_rasampler.py. However, the automatic filter design > feature is not written. Without that, you'll need to design the > appropriate filter. Someone needs to finish sorting out the > filter. For some reason it's failing in the 10,000 element test case. > There is currently qa code for the _fff case. When it works for all > cases, the _ccc qa code should be written too. Thanks Matt, Eric and Bob for the reply. I took a snippet from ayfabtu.py, and wrote something like this: adc_rate = 64e6 usrp_decim = 125 if_rate = adc_rate / usrp_decim# 512 kS/s if_decim = 8 demod_rate = if_rate / if_decim# 64 kS/s # usrp is data source src = usrp.source_c (0, usrp_decim) src.set_rx_freq (0, IF_freq) actual_IF_freq = src.rx_freq(0) actual_offset = actual_IF_freq + station src.set_pga(0,30) channel_coeffs = \ gr.firdes.low_pass (1.0, # gain if_rate, # sampling rate 64e3, # low pass cutoff freq 72e3, # width of trans. band gr.firdes.WIN_HANN) ddc = gr.freq_xlating_fir_filter_ccf (if_decim,channel_coeffs,-actual_offset,if_rate) volumecontrol = gr.multiply_const_cc(.0031) print len(channel_coeffs) ifrtaps = gr.firdes.low_pass(1, 2, # Fs .75/3, # freq1 .25/3, # trans width gr.firdes.WIN_HANN) print "len(ifrtaps) =", len(ifrtaps) jack_resampler = blks.rational_resampler_ccf(self, 3, 4, ifrtaps) # split IQ because JACK audio is only mono split_IQ = gr.complex_to_float () # JACK audio as final sink jack_rate = 48e3 demod_sink_i = audio_jack.sink (int (jack_rate), "gr_sink_I") demod_sink_q = audio_jack.sink (int (jack_rate), "gr_sink_Q") # now wire it all together self.connect (src, ddc) self.connect (ddc, volumecontrol) self.connect (volumecontrol, jack_resampler) self.connect (jack_resampler, split_IQ) self.connect ((split_IQ, 0), demod_sink_i) self.connect ((split_IQ, 1), demod_sink_q) After some hacking, and a yet-to-release patch against Dream DRM receiver (jack I/O sound), I was able to receive a local DRM station: http://f8cfe.free.fr/ham/gnuradio/drm40_4.png Rem: Dream DRM receiver has some interesting frequency and samplerate history tracking.. Here was the chain: Wire antenna in attic -> automatic tuner (AH4) tuned to 12m --+ | RG213 | v USRP/BasicRX tuned to 25.775 decim to 512kS/s | v freq_xlating_fir_filter_ccf 64 kS/s | v rational_resampler_ccf 48 kS/s | v audio_jack | v Dream DRM rx (I/Q) | v headphones <- soundcard <- jackd Altough it worked, I still don't understand why the value passed to multiply_const_cc (.0031) is so low. Would someone be kind to explain me how to choose it? What are the pro/con of using a _ccf vs. _ccc (float vs. complex) filter? And honestly, the parameters of the gr.firdes.low_pass ifrtaps coeffs are pure magic to me. Maybe I should read more books on signal processing :-) Rem
[Discuss-gnuradio] resampler block
Gang, I think this question went unoticed in my audio-jack announce. Is there a resampler block somewhere? Last time I heard of a resampler was this summer: http://lists.gnu.org/archive/html/discuss-gnuradio/2005-07/msg3.html but some parts are missing from the gr_rational_resampler block, with comments like: # FIXME Bob, please do your magic filter design here return (1.0,) # FIXME One of my goal behind the gr-audio-jack module, is to be able to feed legacy non-GNU Radio applications like gmfsk, Dream DRM receiver, DttSP, etc., with signals from GNU Radio USRP. For that matter, I need a resampler block. Can anyone recommand me a gr block to resample, say, from 64kS/s to 48kS/s or directly the usrp source at 512kS/s to 48kS/s ? Is the gr_rational_resampler finished? In the case of the 512kS/s to 48kS/s ddc, would the gr_rational_resampler be able to replace gr_freq_xlating_fir_filter ? Cheers -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New gr-audio-jack module
Gang, You will find at savannah a new GNU Radio module: gr-audio-jack. This is both source and sink modules for JACK http://jackit.sourceforge.net. The JACK Audio Connection Kit is a low-latency sound server. JACK allows the connection of multiple applications to an audio device, as well as allowing them to share audio between themselves. It shows handy when you were connecting previously an external patch cord between the line-out and line-in of your sound card. With JACK, this is all done by software. To initally check it out: $ cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/gnuradio co -P gr-audio-jack It has been tested with libjack-0.100 under Debian, with a USRP/TVRX. There's a screenshot here http://f8cfe.free.fr/ham/gnuradio/jack_wfm.png Here was the plumbing: tvrx_wfm_rcv_gui.py (tuned to Canal B FM 94.0MHz) gr_sink | v copy_in audio_copy.py -i copy_in -o copy_out copy_out /\ | | v v alsa_pcm:playback_1 alsa_pcm:playback_2 jackd jackd tvrx_wfm_rcv_gui.py was modified to use the audio_jack sink. audio_copy.py was modified to use an audio_jack sink/source. audio_copy.py was inserted just to exercice the audio_jack source. The copy_out(mono) is connected to both playback_1&playback_2, because alsa_pcm is a stereo device. Just for the fun of it, I've added a Digital peak/Vu meter with the following commands: "meterbridge -t dpm gr_sink:out" and "meterbridge -t vu gr_sink:out" (from the meterbridge package http://plugin.org.uk/meterbridge/). So this adds gr_sink:out->meterbridge-13207 and ->meterbridge-13723. JACK design is really nice. I recommand you to have a peek at it. In the previous example, the patch bay is provided by qjackctl. The only big drawback of JACK is that the sampling freq is fixed within its domain (32kHz here, can be anything else). It is possible to have more than one jackd running in parallel though. One of my goal behind this gr-audio-jack module, is to be able to feed legacy non-GNU Radio applications like gmfsk, Dream DRM receiver, DttSP, etc., with signals from GNU Radio USRP. For that matter, I will need a resampler. Can anyone recommand me a gr block to resample, say, from 64kS/s to 48kS/s or directly the usrp source at 512kS/s to 48kS/s ? Is the gr_rational_resampler finished? IMHO, JACK enables interesting features, like being able to put a patch cord somewhere in the flow graph for running a scope, without having to change the source code of the running application. I'd love to see that in GNU Radio. To be able to do that, we would need the Python flowgraph to export its interface to other processes through RPC (SUN's, IPC, sockets, pipes, etc.). To begin with, returning the current flowgraph hierarchy and being able to make connections would be nice. With proprer dressing, this would enable interface GNU Radio API from Python/C++/etc.. Cheers -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TVRX data interface to USRP board (VINN_A, VINP_A; VINN_B, VINP_B)
On Mon, Sep 26, 2005 at 02:56:18PM +0800, [EMAIL PROTECTED] wrote: > In the module interface, there are two RF data differential pairs > from > RF board to the USRP board: VINN_A, VINP_A; VINN_B, VINP_B. > If there are two individual RF tuners on the RX board, I think they each use > one different pair, like the picture below for basic RX board. > http://www-personal.engin.umich.edu/~anastas/gnuradio/usrp_gen.eps > But how about the TVRX board? From what I see from the python code, > only one ADC is used. Is one of the differential pairs left open > or both of them connect from the same RF tuner output? If the answer is 2), > under what condition would this be used (I/Q sampling) for this tuner? IANAEE, but reading the schematics[1], it looks like only VINP_A/VINN_A are connected (to out+/out-). So I would say answer 1). [1] http://www.ettus.com/Download.html Now this makes me think, why the left unused pair VINN_B/VINP_B has not been used as an extra single basic RX on the TVRX board? Matt, Eric, can the TVRX still be moded? -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3DNow fir test failing under debian with latest unstable updates
On Mon, Aug 22, 2005 at 12:44:58AM -0400, Krzysztof Kamieniecki wrote: [..] > model name: AMD Athlon(tm) 64 Processor 3700+ > stepping : 10 > cpu MHz : 797.986 Krzysztof, I haven't seen your reply about the cpu speed. Is the cpu MHz output right? 800MHz? Or is it automatic PowerNow? What is the max cpu speed? > ***gnuradio-core/src/test/benchmakr_dotprod output: >generic: taps: 256 input: 4e+07 cpu: 11.330 taps/sec: 9.038e+08 > 3DNow!: taps: 256 input: 4e+07 cpu: 5.095 taps/sec: 2.01e+09 >SSE: taps: 256 input: 4e+07 cpu: 4.506 taps/sec: 2.272e+09 Have you tried out the latest CVS code with 64bit x86-64 speedup? I'm curious what's the difference between 32bit and 64bit speedups. Note: gcc-4.x still does a good job at optimizing the generic loop. -- Stéphane - F8CFE ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cypress/USRP/USB query (quick one!)
Hi, On Tue, Aug 30, 2005 at 10:15:07AM +0200, Kalen Watermeyer wrote: > Hello all, > > I'm a master's student finishing up a hardware project. It is a SDR > platform, and I am using the EZ-FX2 microcontroller. Can you talk a bit more about your SDR platform? Any plan on integrating with GNU Radio ? > > I know that GNURadio is intended for Linux, but I'm testing out my FX2 Nope, GNU Radio is not intended for Linux only. Besides Linux, it is intended for and run under *BSD, MacOSX, Windows (MinGW and Cygwin), Solaris, etc. > under Windows XP (for now). Although the OS registers that a 'USB > Device' is present when I connect it to the PC, and it retrieves the VID > and PID from the FX2 (correctly I am presuming), it fails to find an > appropriate/plug-n-play driver for it. > > I have since downloaded the USB mass storage drivers from Cypress for > various IC families including the FX2, and followed their instructions > regarding editting the .inf string values etc to match those of my app. > After telling XP to search for the driver in the folder containing the > Cypress files it still does not 'find' the driver. I strongly recommand you libusb-win32[1]. Why? because its API is the same for other OSes like Linux, *BSD, Darwin, .. cf. libusb[2]. So this is the choice for portability of your code and high performance. The project is open source (GPL/LGPL), and there's excellent support on their mailing list project. GNU Radio is using libusb-win32 under Windows, and this is a success! Latest libusb-win32 version 0.1.10.1 has a wizard which helps you create the appropriate .inf file for the filter driver. The device driver is then developped comfortably in your user program. [1] http://libusb-win32.sourceforge.net [2] http://libusb.sourceforge.net > Has anybody had any experience with using the FX2 under Windows? More > specifically, has anybody used the Cypress drivers for Windows? It may > well be that my hardware is faulty, but I am unsure how 'automatic' the > initialising process is with regards the FX2 so am at a dead end. Problems with Cypress software? Ask Cypress? Problems with Windows software? Ask Microsoft? GNU Radio definitely choosed free open source :-) Cheers! -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Distclean problem in usrp/doc
G'day Berndt, On Wed, Aug 17, 2005 at 02:39:23PM +0930, Berndt Josef Wulf wrote: > On Wed, 17 Aug 2005 12:55 pm, Berndt Josef Wulf wrote: > G'day, > > same as in my previous email about gnuradio-core, the distclean process fails > for the same reasons in usrp/doc. Find appended fix below: > > cheerio Berndt > > --- doc/Makefile.in.orig2005-08-17 14:33:12.0 +0930 > +++ doc/Makefile.in 2005-08-17 14:33:02.0 +0930 ^^ Don't hack the .in file, since it is auto-generated. The .am file are the one to be modified. So here's the patch for gnuradio-core: Index: doc/Makefile.am === RCS file: /cvsroot/gnuradio/gnuradio-core/doc/Makefile.am,v retrieving revision 1.4 diff -u -b -B -w -p -r1.4 Makefile.am --- doc/Makefile.am 31 Jan 2005 00:07:19 - 1.4 +++ doc/Makefile.am 19 Aug 2005 13:05:48 - @@ -71,6 +71,5 @@ uninstall-local: $(RM) -fr $(DESTDIR)$(docdir)/html clean-local: - $(RM) -r latex - $(RM) -r html man + $(RM) -fr latex html man And here's the patch for usrp: Index: doc/Makefile.am === RCS file: /cvsroot/opensdr/usrp/doc/Makefile.am,v retrieving revision 1.5 diff -u -b -B -w -p -r1.5 Makefile.am --- doc/Makefile.am 11 Feb 2005 22:08:14 - 1.5 +++ doc/Makefile.am 19 Aug 2005 13:06:52 - @@ -76,6 +76,4 @@ uninstall-local: $(RM) -fr $(DESTDIR)$(docdir)/html clean-local: - $(RM) -r latex - $(RM) -r html man xml - $(RM) $(DOCBOOK_HTML_FILES) + $(RM) -fr latex html man xml $(DOCBOOK_HTML_FILES) And to get it into CVS, let's Cc [EMAIL PROTECTED] Cheers! -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] latest version of gr_python.m4
On Sat, Jul 30, 2005 at 11:21:43AM +0930, Beck, Andrew Thomas - BECAT001 wrote:
> I've worked out how to post patches properly now, so I
> will submit it shortly. Do you know anything about the
> vmcirbuff stuff? I've been trying to sort through the
> recent changes, but don't really understand what is going
> on.
>From the latest patches, it appears you got it working in the end!
> cheers,
> andrew
>
> ps incidently, what timezone are you in? I'm in Hong Kong.
I'm from CEST (France). But during the What-The-Hack festival
http://wiki.whatthehack.org/ in NL, we were out of a timezone ;-)
Glad to hear GNU Radio is alive and strong in HK.
All the best!
--
Stéphane - F8CFE
> -Original Message-
> From: Stephane Fillod [mailto:[EMAIL PROTECTED]
> Sent: Sat 30/07/2005 5:57 AM
> To: Beck, Andrew Thomas - BECAT001
> Cc: discuss-gnuradio@gnu.org
> Subject: RE: [Discuss-gnuradio] latest version of gr_python.m4
>
> Selon "Beck, Andrew Thomas - BECAT001" <[EMAIL PROTECTED]>:
>
> > I modified gr_python.m4 as follows so it now works under
> > cygwin & mingw
> >
> > python_cmd='
> > import distutils.sysconfig
> > import os
> > path = distutils.sysconfig.get_config_var("LIBPL")
> > if path == None:
> > path = distutils.sysconfig.PREFIX + "/libs"
> > if os.sep == "\\":
> > path = path.replace("\\", "/")
> > print path
> > '
>
> Great job Anrew. I don't know how I got it working one week ago,
> maybe with an extended PATH pointing to the .dll file. Anyway,
> your solution of pointing to the import library is much cleaner.
>
> Eric, can you commit that new version into gr_python.m4 ?
> We tested it with Martin, and it also works fine for us
> under MinGW and Cygwin. That should not break other systems
> because that python script is only run for *mingw*|*cygwin* hosts.
> Oh yes, the new gr_python.m4 file will need to be copied over
> all the other gr modules..
>
>
> Cheers
> --
> Stephane
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] latest version of gr_python.m4
Selon "Beck, Andrew Thomas - BECAT001" <[EMAIL PROTECTED]>:
> I modified gr_python.m4 as follows so it now works under
> cygwin & mingw
>
> python_cmd='
> import distutils.sysconfig
> import os
> path = distutils.sysconfig.get_config_var("LIBPL")
> if path == None:
> path = distutils.sysconfig.PREFIX + "/libs"
> if os.sep == "\\":
> path = path.replace("\\", "/")
> print path
> '
Great job Anrew. I don't know how I got it working one week ago,
maybe with an extended PATH pointing to the .dll file. Anyway,
your solution of pointing to the import library is much cleaner.
Eric, can you commit that new version into gr_python.m4 ?
We tested it with Martin, and it also works fine for us
under MinGW and Cygwin. That should not break other systems
because that python script is only run for *mingw*|*cygwin* hosts.
Oh yes, the new gr_python.m4 file will need to be copied over
all the other gr modules..
Cheers
--
Stephane
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] latest version of gr_python.m4
Selon "Beck, Andrew Thomas - BECAT001" <[EMAIL PROTECTED]>: [..] > Like I said, I don't get auto stuff yet, but will try to see what is > happening in the new > gr_python.m4 file. Youŕ new gr_python.m4 file will need to be copied over to each gr modules. >Incidently, isn't there a standard macro file that sorts > out the python > stuff? While I've been trying to understand it, I've come accross several > repositries of macros. Unfortunately, there's no such thing so far. If anybody find one that works on Linux (w/ and w/o dynamic export, non standard install), MacOSX, MinGW, Cygwin, *BSD, cross-compiling, etc. we would be very happy. > cheers, > andrew > > ps Can you recommend an "auto-tools for dummies" tutorial? I would recommand the "GNU Autoconf, Automake, and Libtool" book found here http://sources.redhat.com/autobook/ . There's a paper version I have, I like it. You have to know this book covers only autoconf v2.13, which is a bit different than autoconf 2.50+ we're using. Anyway, it's a good introduction. Other people on the list may recommand better tutorial if they have. I cannot access the wiki from WTH (is the server too suspicious with hackers or maybe simply because of the reverse DNS?), but any recommendation of auto-tools tutorial should find its way in there: http://comsec.com/wiki?SuggestedReading -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] binary installer gnuradio-2.5cvs.win32.exe for windows
Hi Mike, Selon mjam01 <[EMAIL PROTECTED]>: > thanks eric, that solved that bit... now here's the next one. i've > tried running various sample codes and this error happens everytime. > > [...] > src = usrp.source_c (0, decim, 1, gru.hexint(0xf0f0f0f2), 0) > File "C:\Python24\lib\site-packages\gnuradio\usrp.py", line 86, in source_c > return ((usrp0.source_c, > usrp1.source_c)[look_for_usrp(which)])(which, *args, **kwargs) > File "C:\Python24\lib\site-packages\gnuradio\usrp1.py", line 1263, in > source_c > return _usrp1.source_c(*args) > RuntimeError: std::runtime_error > -- Are you using the snapshot from Martin? This binary installer needs an update (gnuradio-core/usrp/gr-usrp) to work with the examples. If thing goes well, we might generate a new one soon.. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] latest version of gr_python.m4
Hi Andrew, You're pretty lucky :-) Beck, Andrew Thomas - BECAT001" <[EMAIL PROTECTED]>: > Firstly, I don't understand auto* stuff. > I was wondering if gr_python.m4 is actually broken under cygwin > or if I'm doing something wrong. Basically, I'm failing to link > the python library & it seems to be because PYTHON_LDFLAGS is null. > I'm still confirming it works fully, but I ended up hacking the m4 file > to remove the check for mingw & took some of the body from an earlier > version. It's ugly, but it seems to link now. > Is this a known issue? Looking at the file, it seems that several > people have hacked it about to make it work on their platform. The windows platform code is hot right now. We try to make it to work for MinGW and Cygwin, but without breaking other arch's. The good news is Eric just commited today some patches I sent him for Cygwin, which I made (again) working this week. So, a clean check out with a bootstrap, make, lot of coffee, .. should bring you now to a successful make check under Cygwin. Thanks for the report. We're at your service during the week-end :-) Cheerio -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] working version of gnuradio for windows (mingw) available including audio-sink and wxgui
On Thu, Jul 14, 2005 at 05:54:09AM +0200, Martin Dvh wrote: > >>This work is under way. We still need to fix libpython linking under > >>MinGW before 2.6. This shouldn't be a big issue, Martin may have > >>it already working. > I do have the complete build working under windows (I am already using it) > What libpython linking problem do you have? > (Maybe you told me before, but I don't remember in which mail) Don't you have to explicitly link DLL's against libpython under Windows because of -no-undefined ? Anyway, Martin, you can go ahead with feeding patch-gnuradio with your patches. Cheers -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: gr_python.m4
On Wed, Jul 13, 2005 at 05:30:02PM -0700, Eric Blossom wrote: > On Thu, Jul 14, 2005 at 01:04:55AM +0200, Stephane Fillod wrote: > > On Sun, Jul 10, 2005 at 05:24:59PM -0700, Eric Blossom wrote: > > > > > So, then the question becomes, "what's the easiest way to build GNU > > > Radio for a windows target?" > > > > I would say natively. Since I'm a developer and not a Windows final > > user, I'll be the only one doing cross-development. > > > > > I thought that most people ran MinGW under windows. I take it that > > > you are running it under linux and generating windows binaries. > > > Perhaps a quicker path is just to make GNU Radio build under MinGW > > > running under windows? Then the cross development issues go away. > > > > I'd like, if possible, to keep the ability to cross-build MinGW under > > Linux. This is very handy to check the portabilty, from the same source > > tree (VPATH), without having to reboot. > > OK. Can we have these goals: > > * builds natively under MinGW > * builds cross-compiled from x86 GNU/Linux > * doesn't break anything else Ok. > > I think this is possible cheaply thanks to the autoconf cache and > > some ac_cv_* variable overload from the configure line. I'll come up > > with a config/gr_python.m4. > > Thanks. > > You may want to consider the distutils fragment with the replace > operation that floated across the list a couple of days ago. > I haven't applied it to gr_python.m4 and will hold off pending your patch. Don't hold off. I'm off for the week-end, so you can go ahead with it. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gr_python.m4
On Sun, Jul 10, 2005 at 05:24:59PM -0700, Eric Blossom wrote: > On Mon, Jul 11, 2005 at 01:38:43AM +0200, Stephane Fillod wrote: > > > I checked in a new version of gr_python.m4 that uses distutils to > > > determine the include path for Python.h. I tested it on GNU/Linx and > > > OS/X and it works there. > > > > It's not going to work for any cross-dev setup (eg. mingw under Linux) > > because it's trying to run the xdev python: > > > > # ask distutils which include path we should use > > python_path=`$PYTHON -c "import distutils.sysconfig; \ > > print > > distutils.sysconfig.get_python_inc(plat_specific=False)"` > > Good point. > > Cross development pretty much screws autoconf unless there's a way of > getting answers for the target environment. autoconf can work cross development, but extra care has to be taken :( > So, then the question becomes, "what's the easiest way to build GNU > Radio for a windows target?" I would say natively. Since I'm a developer and not a Windows final user, I'll be the only one doing cross-development. > I thought that most people ran MinGW under windows. I take it that > you are running it under linux and generating windows binaries. > Perhaps a quicker path is just to make GNU Radio build under MinGW > running under windows? Then the cross development issues go away. I'd like, if possible, to keep the ability to cross-build MinGW under Linux. This is very handy to check the portabilty, from the same source tree (VPATH), without having to reboot. I think this is possible cheaply thanks to the autoconf cache and some ac_cv_* variable overload from the configure line. I'll come up with a config/gr_python.m4. Thanks -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] working version of gnuradio for windows (mingw) available including audio-sink and wxgui
On Wed, Jun 29, 2005 at 05:38:28AM -0700, Eric Blossom wrote: > In the bigger picture, we need to revisit the strategy for > searching for libpython. This is currently breaking the build on > x86-64 and OS/X. My biggest complaint is that we have introduced a > mostly-unneeded dependency that has made our build environment > brittle. > > Stephane, what I like to see is that the check for libpython and the > corresponding -no-undefined flag only happen on platforms that are > building windows DLLs. This work is under way. We still need to fix libpython linking under MinGW before 2.6. This shouldn't be a big issue, Martin may have it already working. > > > ./configure --enable-shared --disable-static --with-md-cpu=generic > > ^ > > I've managed once to have the SIMD speedup working under Cygwin. > > To get them into the CVS, I would need to rename all the files with > > the .s (lowercase) extension to .S (uppercase). This way, I could use > > the preprocessor to morph the .type statements to the appropriate > > forms under Windows. Eric, would that be okay with you to delete/add > > the .s/.S files ? > > Is there another way to make this work? OS/X is case preserving but > case-insensitive. How does gcc work if there's no difference between upper and lower case? As stated in the manuel, an upper case extension .S will call the preprocessor while the lower case extension .s doesn't. Can some under OS/X make a quick test? >I think OS/X users will be screwed by this > change -- basically they won't see it. Do you mean the preprocessor won't be called, or the dependency system won't rebuild the objects? If it's the latter case, then a "make clean" can get away with it. BTW, the Windows platform suffers the same "issue" with case-sensitiveness as OS/X do. If someone know how to turn on the preprocessor for the assembly files under Windows and OS/X, please stand up :-) -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] working version of gnuradio for windows (mingw) available including audio-sink and wxgui
Hi Mike, On Fri, Jul 08, 2005 at 02:48:11PM +0100, mjam01 wrote: > Are there any plans of using the nullsoft installer for gnuradio > windows installation? What about Inno Setup[1]? [1] http://www.jrsoftware.org/isdl.php > Even with the instructions I must admit i'm struggling to understand > how to get my usrp to work on this xp machine. Doesn't the link[2] from the Wiki[3] work for you? The gr-usrp module is not included in it, but the Inno Setup .iss file in the CVS module of USRP can serve as an example. [2] http://f8cfe.free.fr/ham/gnuradio/setup.exe [3] http://comsec.com/wiki?UsrpMinGW A full Windows distribution may come out once all the Windows patches get into the CVS repository. We're working on it, help is most welcome. Cheers, -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] working version of gnuradio for windows (mingw) available including audio-sink and wxgui
Hi Martin, Sorry for replying late on your exciting mail. Did you get other feedback privately about it or about the Windows port? I haven't seen much on my side. On Fri, May 20, 2005 at 12:18:55AM +0200, Martin Dvh wrote: > I made gnuradio compile on windows using mingw (no cygwin needed) No Cygwin? Good! > It works with the standard win32 binary distributions of python24-win32 > python-numeric-win32, swig-win32, wxpython-win32 and python win32api > I still needed to build cppunit,fftw and boost myself (I added the built > cppunit and fftw dlls to my binary gnuradio-core, see links at end of mail) FYI, my cppunit windows patch has been accepted by the maintainers, I hope it will show up in the next official release. I tried to convince the fftw maintainers about the patch, I'm not sure I succeeded in. Besides, their release cycle is pretty long. Now when boost will recognize gcc-4.x ? > I implemented a new gr_vmcircbuf_createfilemapping factory > I added O_BINARY flags to all file-operations > I hacked the m4 macros > I added a sed script (in Makefile.am) to replace all backslashes with > forward slashes in src/lib/swig/gnuradio_swig_python.d > Some more hacking. > My patched version should still build ok on other platforms but this needs > to be tested. > > For source, binary,readmes and the patch: > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/ > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source/gnuradio-core-2.5cvsmingw-clean-3.patch Have you already submitted your patch to patch-gnuradio at gnu.org ? Do you have any plan about it? I've tested some bits of the patch, and IMHO, various parts need tweaks. For example the LIBGNURADIO_CORE_EXTRA_LDFLAGS is missing in the src/lib/Makefile.am, the new m4 are missing in config/Makefile.am, gr_libgnuradio_core_extra_ldflags.m4 should check the compiler supports the option. To me, the createfilemapping factory should check the second mapping is contiguous to the first one, pretty much the same way the Cygwin patch to the mmap_tmpfile factory does. I have fixes in my tree for all the listed issues, and I can check regression for Linux. Do you want me to submit them with you as credit, or do you prefer that I send them directly to you? That would be great to get all this stuff in the GNU Radio 2.6 release, so it gets a better chance to be more widely tested. Rem: so far, I only tested the MinGW cross-compilation, no run yet. > I updated the wiki with links to my new files: > http://comsec.com/wiki?MinGW Thanks! > You still need to give a whole lot of options (pathnames) to configure to > work around backslash forward slash problems and libtool absolute pathname > problems. > Configure will find python if its on your path but then it uses c:/Python24 > as prefix. It just doesn't work if something starts with c:\\somepath or > c:/somepath, it needs to be /c/somepath so you have to override at the > configure commandline. > > ./configure --enable-shared --disable-static --with-md-cpu=generic ^ I've managed once to have the SIMD speedup working under Cygwin. To get them into the CVS, I would need to rename all the files with the .s (lowercase) extension to .S (uppercase). This way, I could use the preprocessor to morph the .type statements to the appropriate forms under Windows. Eric, would that be okay with you to delete/add the .s/.S files ? > --with-cppunit-prefix=/mingw/cppunit > --with-boost-include-dir=/d/boost_1_32_0/include/boost-1_32 > PKG_CONFIG_PATH=/mingw/fftw/lib/pkgconfig PYTHON=/d/Python24/python > am_cv_python_pythondir=/d/Python24/Lib/site-packages > am_cv_python_pyexecdir=/d/Python24/Lib/site-packages 2>&1 | tee > configure.log Having them in the wiki and a README allow easy copy/paste 8-) > I also implemented a gr-audio-windows audio-sink (audio-source to be done, > is now an empty stub) > This needs some work (synchronisation, it crackles) > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source/gr-audio-windows-0.1.tar.gz Any plan on submitting it to patch-gnuradio at gnu.org ? Eric, what's your position on this? > I also implemented a hacked gr-wxgui fftsink and scopesink which works with > standard wxpython for windows. > (also needs python win32api) > This uses win32 named pipes in stead of anonymous os.pipe() because the cpp > code doesn't understand the filedescriptor python gives when using > os.pipe() (It says bad filedescriptor) > This works ok for fftsink but the scopesink needs win32 named pipe support > in the gnuradio-core code (or a solution to the filedescriptor problem). I > worked around this by using a standard file-sink in stead of scopesink. > This means no triggers or whatsoever. > > > http://comsec.com/wiki?MinGW > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/ > > source, readmes and the patch: > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source > http
Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
On Fri, Jun 24, 2005 at 02:31:41PM +0200, Harald Welte wrote: > On Thu, Jun 23, 2005 at 08:52:33PM -0700, Eric Blossom wrote: > > On Wed, Jun 22, 2005 at 12:40:06PM +0200, Harald Welte wrote: > > > On Tue, Jun 21, 2005 at 04:10:35PM -0700, John Gilmore wrote: > > > > > > But at what expense? you copy data back and forth between different > > > address spaces (kernel/user), you have lots of complex code that deals > > > with retransmissions, protocol demultiplex, ... that is totally > > > unneccessarry for the gnuradio/USRP kind of application. > > > > Actually, you do need flow control. And to do this with any kind of > > throughput, you start needing sliding windows. At this point, you are > > pretty close to TCP territory. The question becomes do I want to > > build something custom, or do I want to use a standard solution that > > might be overkill. > > I don't really understand why you would want flow control. I was about to ask the same question. > You sample from the ADC with a certain bandwith. If either your > communications link or your host computer cannot cope with the amount of > data, frames will be lost. There is nothing you can do about that, > unless you reduce the sampling rate or bits-per-sample depth. > > You can introduce sender-side buffering at the expense of increased > latency and do retransmissions of lost frames. But that's not flow > control, but delivery guarantee ;) I fully agree. Maybe Eric was thinking flow control is needed for the presentation time of the samples with a continuous scale on the arrival endpoint. Eric, can you elaborate on the need for flow control? > You can detect frame loss by using a simple frame number that gets > incremented with every frame sent from the SDR. The host PC then > detects frame loss by gaps in the frame number sequence. The frame number can be the Sequence Number(SN) in the RTP header, c.f. RFC 1889, "RTP: A Transport Protocol for Real-Time Applications". The SN helps detecting frame loss (after a certain timeout), and reorder frames if need be. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
On Wed, Jun 22, 2005 at 12:40:06PM +0200, Harald Welte wrote: > On Tue, Jun 21, 2005 at 04:10:35PM -0700, John Gilmore wrote: > > I'm picking up the Gigabit Ethernet conversation from a few weeks ago. > Me too. Please, add your inputs to the following page: http://comsec.com/wiki?USRPnotUSB > > > I'm by no means arguing that the linux network stack is slow. It's just > > > not intended for an application which just wants to get big data streams > > > with low latency and little overhead into userspace. > > > > I'm surprised to hear you suggest this (though I note you didn't give > > numbers, just generalizations like "enormous"). > > I didn't state (or at leat want to state) that it was impossible to > achieve multiple-gigabit data rates with the Linux network (or even > TCP/IP) stack. > > I just think that it is a horrible waste of cpu cycles and memory > bandwidth, when all you want is to get large amounts of data from a > local (cloe to the computer) device into an userspace application. This > is especially true if your userspace application is a cpu hog like > digital signal processing algorithms ;) This is were everybody does not agree. Several of us (most likely hams) want to get large amounts of data from a *distant* (away from the computer) device. IOW, I don't want to get my SHF signal through a long, expensive and lossy cable, while I could have it sampled right at the antenna on top of the pole, and data transported through Ethernet on a cheap CAT 5+ cable. > > What thruput do YOU see using a good GigE card under Linux? Can you move > > 100 Mbytes/sec from user process to user process with TCP, across two GigE > > interfaces and a GigE switch? If so, it's doing much better than USB2 > > ever will, and much better than any version of FireWire. > > I'm usually not doing client-to-server TCP benchmarks over my test > networks, since I'm more interested in small-packet forwarding > performance. I'm sure with the right tuning (and probably some of the > recent work on TCP BIC etc.) you can saturate a 1000-base-tx link with a > single tcp flow, no question on that. First of all, we have to forget about TCP. If you have to resend, it'll be too late. Besides, implementing TCP in a FPGA or anything that must sustain 1Gbps is no piece of cake. I would rather argue in favor of either raw Ethernet frames or more likely, UDP+RTP. UDP/RTP is easy to handle in a FPGA (almost dumb header), can be routed by IP routers if need be, and RTP has interesting timestamp support plus re-odering if need be. Now talking about small-packet forwarding, this is not going to be the case with a NetSRP, unless you want really low latency. Small-packets are really knee-bending, and people achieving good performance with them deserve respect. However, if we're going to fill up a 1Gbps pipe, there's no point in having small packets. The bigger the packet, the better. For those affraid by the latency, just think of what the OS will add up. USB too already suffers from it, and from the kernel/user fence. Of course, we would not be the first ones to do that, professional video is already streamed like that, from what I can see every day. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Demo
On Mon, Jun 20, 2005 at 11:47:25PM -0700, Prateek Dayal wrote: > Thanks a lot ... I am trying to get some webspace somewhere where > there is a larger bandwidth allocated ... In particular I am trying > hostingzero.com which gives space out for free if you have more > traffic > > I think we can have some gnuradio space where whoever contributing > tothe project can put up some files even if moderated by an > administrator ... What about hosting contributions at sourceforge or savannah ? Some modules (CVS/web/files) may be protected by ACL to the Mighty committer team (Eric, Matt, ..), and other modules may have relaxed rights, with everybody's-welcome-on-the-roll approach. This is all about community after all, and a repository for the numerous gr blocks to be contributed would be nice. What do you think? -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] static libpython3.2.a issue while building gnuradio-core from CVS
On Tue, Jun 21, 2005 at 07:08:06AM -0700, Mark S Petrovic wrote: > I've deduced that there are things known about this issue, or a related > issue, as I saw similar discussion here > > http://lists.gnu.org/archive/html/discuss-gnuradio/2005-05/msg00148.html This thread was more a libtool issue specific to MacOS X, where libtool dropped the dependency against libpython when linking _gnuradio_swig_python.so. [...] > 2. Python 2.3.5 built from source with --enable-shared and linked with > -export-dynamic produces the following libraries > > $ find /usr/lib -name libpython\* |xargs ls -l > lrwxrwxrwx 1 root root 19 Jun 20 13:06 /usr/lib/libpython2.3.so -> > libpython2.3.so.1.0 > -r-xr-xr-x 1 root root 944568 Jun 20 13:06 /usr/lib/libpython2.3.so.1.0 > -rw-r--r-- 1 root root 1479196 Jun 20 13:06 > /usr/lib/python2.3/config/libpython2.3.a what outputs "ldd /usr/lib/libpython2.3.so.1.0" ? > 3. via the invocation of "buildit" on gnuradio-core/, we get > > ./bootstrap && ./configure --enable-maintainer-mode > > which drives the execution of gr-build/gnuradio-core/config/gr_python.m4. > > gr_python.m4 has in its PYTHON_DEVEL macro (see in gr_python.m4 "# Check for > Python > headers usability") a loop that searches for libpython$PYTHON_VERSION.*. The > loop list > > for i in "$python_path/lib/python$PYTHON_VERSION/" > "$python_path/lib/python$PYTHON_VERSION/config/" "$python_pat > h/lib/python/config/" "$python_path/lib/python/" "$python_path/" > "$python_path/libs" > > is ordered in such a way that /usr/lib/python2.3/config/libpython2.3.a > is found before /usr/lib/libpython2.3.so. > > As a result, the python dev lib test program as seen in > gnuradio-core/config.log > > gcc -o conftest -g -O2 -Wall -I/usr/include/python2.3 conftest.c > -L/usr/lib/python2.3/config -lpython2 > .3 -lpthread -ldl -lutil >&5 So the loop list has to be tweaked. Then someone else stands up, the new order breaks things on his system, and we're caught in a loop hole :-) Maybe a configure option could solve this? > does not succeed in linking because libpython2.3.a has unresolved math > symbols. For example, from config.log > > /usr/lib/python2.3/config/libpython2.3.a(complexobject.o)(.text+0x2fe): In > function `_Py_c_pow': > : undefined reference to `hypot' Static library(archive) don't have dependency against libm. Anyway, it's not going to work. In order to build the swig wrappers, all the dependent libraries must be shared objects. > > where > > $ nm /usr/lib/python2.3/config/libpython2.3.a |grep hypot > U hypot > > 4. From my narrow perspective, I can "fix" this problem by moving > "$python_path/" to the front of the "for" loop in gr_python.m4, such > that /usr/lib/libpython2.3.so is found before the static lib version > /usr/lib/python2.3/config/libpython2.3.a. Doing so allows the test > program to link to the .so version of the library, which results in a > successful linking of the test program. > > Or, one can fix by linking the test program to libm, but that doesn't > sound right. Fix the root cause (actually, the one I messed up :*). -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NCO accuracy
Fellow hackers,
Everybody can make copy/paste bugs, like the one fixed by the piece of
patch (against current CVS) hereafter:
RCS file: /cvsroot/gnuradio/gnuradio-core/src/lib/general/qa_gr_fxpt_nco.cc,v
retrieving revision 1.1
diff -u -r1.1 qa_gr_fxpt_nco.cc
--- src/lib/general/qa_gr_fxpt_nco.cc 19 Dec 2004 05:48:39 - 1.1
+++ src/lib/general/qa_gr_fxpt_nco.cc 15 Jun 2005 21:45:03 -
@@ -42,11 +42,11 @@
for (int i = 0; i < 10; i++){
float ref_sin = ref_nco.sin ();
-float new_sin = ref_nco.sin ();
+float new_sin = new_nco.sin ();
CPPUNIT_ASSERT_DOUBLES_EQUAL (ref_sin, new_sin, SIN_COS_TOLERANCE);
float ref_cos = ref_nco.cos ();
-float new_cos = ref_nco.cos ();
+float new_cos = new_nco.cos ();
CPPUNIT_ASSERT_DOUBLES_EQUAL (ref_cos, new_cos, SIN_COS_TOLERANCE);
ref_nco.step ();
Brown-bag thing, isn't it?
In fact, this is an interesting bug, worth it because it allows some
hacking fun and get to understand new stuff in the end of the day (well,
several days in my case :-).
After fixing it, I reran the test_general, and this time it failed
in qa_gr_fxpt_nco::t0. So what, the fxpt code is not accurate?
Wrong! the fxpt code is accurate (to some degree). This is what
I found after some investigation. The equality assertion actually
failed because of a float type. Indeed, the phase type in gr_nco.h
is a float, and after several additions, rounding errors drove
the supposed linear phase out of its way (as seen with Gnuplot).
So it looks like gr_nco.h does need to have its phase and phase_inc
variables of double type. The output types of sin/cos stays float.
Of course, the move from float to double does not slow down benchmark_nco
on systems with single&double FPU (x87 and alike).
CVS commiters will find a patch attached which addresses this (gr_nco.patch).
Pulling the magnifying glasses, the following patch is to be prefered
over the previous on qa_gr_fxpt_nco.cc.
Index: qa_gr_fxpt_nco.cc
===
RCS file: /cvsroot/gnuradio/gnuradio-core/src/lib/general/qa_gr_fxpt_nco.cc,v
retrieving revision 1.1
diff -u -r1.1 qa_gr_fxpt_nco.cc
--- src/lib/qa_gr_fxpt_nco.cc 19 Dec 2004 05:48:39 - 1.1
+++ src/lib/qa_gr_fxpt_nco.cc 15 Jun 2005 22:28:02 -
@@ -31,27 +31,45 @@
static const float SIN_COS_TOLERANCE = 1e-5;
+static double max_d(double a, double b)
+{
+ return fabs(a) > fabs(b) ? a : b;
+}
+
void
qa_gr_fxpt_nco::t0 ()
{
gr_nco ref_nco;
gr_fxpt_nco new_nco;
+ double max_error = 0, max_phase_error = 0;
ref_nco.set_freq (2 * M_PI / 5003);
new_nco.set_freq (2 * M_PI / 5003);
+ CPPUNIT_ASSERT_DOUBLES_EQUAL (ref_nco.get_freq(), new_nco.get_freq(),
SIN_COS_TOLERANCE);
+
for (int i = 0; i < 10; i++){
float ref_sin = ref_nco.sin ();
-float new_sin = ref_nco.sin ();
+float new_sin = new_nco.sin ();
CPPUNIT_ASSERT_DOUBLES_EQUAL (ref_sin, new_sin, SIN_COS_TOLERANCE);
+max_error = max_d (max_error, ref_sin-new_sin);
+
float ref_cos = ref_nco.cos ();
-float new_cos = ref_nco.cos ();
+float new_cos = new_nco.cos ();
CPPUNIT_ASSERT_DOUBLES_EQUAL (ref_cos, new_cos, SIN_COS_TOLERANCE);
+max_error = max_d (max_error, ref_cos-new_cos);
+
ref_nco.step ();
new_nco.step ();
+
+CPPUNIT_ASSERT_DOUBLES_EQUAL (ref_nco.get_phase(), new_nco.get_phase(),
SIN_COS_TOLERANCE);
+
+max_phase_error = max_d (max_phase_error,
ref_nco.get_phase()-new_nco.get_phase());
}
+
+ printf ("Fxpt max error %.9f, max phase error %.9f\n", max_error,
max_phase_error);
}
void
With the new patch on qa_gr_fxpt_nco.cc and the a good ref (gr_nco with
phase on double), it appears fxpt_nco now has room for improvement.
What if fxpt suffers the same problems gr_nco did?
Indeed, not only fxpt has a bit of jitter due to linear approx which we
could live with it, fxpt_nco can seriously drift from the expected
frequency due to the fixed point phase. Aha! again the phase! I told you
it was an interesting bug "thread" :-)
Again with fxpt_nco, the error add up over step(), and little by
little, it's not so little. I haven't computed the ppm instability,
but IMHO, the float_nco and fxpt_nco without a fix should not be used
as stable Numerically Controlled Oscillators in GNU Radio.
The float nco seems to have its fix (phase of double type).
I've tried to find something for fxpt_nco along a step counter,
with cheap fixup and a return back to the phase origin every period.
This is in the attached file gr_fxpt_nco.patch. The angle_rate
and friends should be double instead of float to stand the comparison
with float_nco. Rem: angle_rate's not rounding well give interesting
cases. The qa_gr_fxpt_nco.cc should probably also test over
longer times (more periods).
Please comment on it, I am no expert. New ideas are also welcome (I did
not bother googling or read specific books). BTW, is this nco quest worth
it? A
Re: [Discuss-gnuradio] Mirror for USRP-KNOPPIX
On Fri, May 06, 2005 at 12:31:14AM +0100, mjam01 wrote: > hey guys, > > i've set up a torrent tracker. > > never sone this before so lets see if it holds up :) > > http://m0mik.org/gnuradio/torrents/knop-usrp-20050504.iso.torrent Thanks Mike! I have already 323MiB to share. For those that are not used to it, don't forget to leave your bittorrent client running once the download completed. I am using the simple client under GNU/Debian (apt-get install bittorrent, and then "btdownloadcurses http://.../knop-usrp-20050504.iso.torrent";). Other clients are available at http://www.bittorrent.com -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build gnuradio on windows with cygwin mingw msvc
On Thu, May 05, 2005 at 08:55:48PM +0200, Ulf Soderberg wrote: > >BTW, what transfert rate do you get in TX and RX? > >With what kind of USB bridge? > > I get 19 MBytes/s RX and 17MBytes/s TX on a Compaq Evo N800w running > Windows XP SP2 at 2.2 GHz. It says it has a NEC PCI to USB EHCI > controller. Don't know which chip exactly. 17~19MB/s, not bad, esp. with a NEC bridge, which is told to be limited. Do you have some overruns/underruns? What is the lowest rate (decim/interp) without overruns/underruns? Out of curiosity, how does it compare under Linux with same machine? Thanks for the quick feedback. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build gnuradio on windows with cygwin mingw msvc
On Thu, May 05, 2005 at 07:14:41AM -0700, Angilberto Muniz Sb wrote: > Now it works -- I had to create the directories: > c:\usr\local\share\usrp\rev2 and put the .ihx and .rbf > files in there... Good to know. Thanks! BTW, what transfert rate do you get in TX and RX? With what kind of USB bridge? -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mirror for USRP-KNOPPIX
On Thu, May 05, 2005 at 09:57:29AM -0700, Matt Ettus wrote: > A number of people have had trouble downloading from the main site, so > here is a mirror of the USRP-KNOPPIX ISO file. It is approx. 600M. > > http://www.toad.com/knop-usrp-20050504.iso Thanks. My "wget -c " is getting bored, is there a torrent of the image somewhere? I can already share the first 100MiB. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build gnuradio on windows with cygwin mingw msvc
Hi Martin! I'm cc'ing some other people interested in a Windows port. On Wed, May 04, 2005 at 04:12:49AM +0200, Martin Dvh wrote: > Hi, > Has anybody succeeded in building gnuradio 2.x on windows. Yes, I did. > I am trying to build using cygwin (clean cygwin install) > but haven't succeeded yet. You need some patches I sent to Eric yesterday, but hasn't showed up in CVS yet :) > I had to add HAVE_SLEEP to config.h and use the right configure options. The HAVE_SLEEP issue is fixed in the patches. > I tried: > $ ../configure --with-boost-include-dir=/usr/local/include/boost-1_32 > --with-md-cpu=generic Please refer to (and update) the following page http://comsec.com/wiki?Cygwin > But then still make check gives an error in vmcircbuf Yes, it needs a workaround for mmap on Cygwin/Windows. It's in the patches. > Also there is something wrong with _gnuradio_swig_python > It should have build a shared library (dll) but didn't Usual Windows portability pitfall. It requires -no-undefined flag and explicit linking of dependant library (ie. python). It's in the patches, along fixes for all the other gr-* modules. > I do have an > D:\cygwin\usr\local\lib\python2.4\site-packages\gnuradio\gr\_gnuradio_swig_python.a > but it only contains > ! This is a static only archive, which libtool generate as a fallback. > there is no _gnuradio_swig_python.dll > I do have D:\cygwin\usr\local\bin\cyggnuradio-core-0.dll > so my setup is able to build shared libraries Yes, libgnuradio-core.la target had the -no-undefined flag. > I am now trying with > ./bootstrap > ../configure --enable-maintainer-mode --disable-static > --with-md-cpu=generic PKG_CONFIG_PATH=/usr/local/lib/pkgconfig > --with-boost-include-dir=/usr/local/include/boost-1_32 > > The cygwin wiki seems out of date (talks about gnuradio-0.9) Which cygwin wiki? The afore-mentioned? I've updated it 2 days ago. > the mingw wiki says: > Tricks > > make cppunit and fftw3 compile as shared cppunit and fftw3 patches have been submitted upstream. Hopefully they will be in next release. I have patched versions on my site though: http://f8cfe.free.fr/ham/gnuradio/ > hack the m4 macros to tell non standard Python install directory > need some vmcircbuf patches not yet in CVS > > Are these vmcircbuf patches already in gnuradio (cvs) I hope they will be soon :-) > Anybody who has some experience with this please tell me. I have no particular interest in Windows platforms, but I'm doing the port because it's necessary for the project. Since I don't spend much time under Windows, the port definitely needs testers! For your information, "make check" passes completely for gnuradio-core under Cygwin, and the usrp module appears to work (with fast USB) under Windows (with rev0 board). I'm taking the opportunity to call for volunteers for testing the low-level USRP under Windows. So anyone with a USRP board and Windows >= 98 + latest ServicePack can help. All you need to do is to download the wizard linked from http://comsec.com/wiki?UsrpMinGW, install the USRP filter, and check the various test_usrp_standard_*.exe The setup.exe file contains the libusb-win32 filter and DLL, automatic driver(.inf) installation, latest .ihx and .rbf, and couple of test programs. Let me know how it works for you. There's also a fresh tar.bz2 containing cygwin binaries at http://f8cfe.free.fr/ham/gnuradio/gnuradio-core-2.5cvs-cygwin.tar.bz2 You will need the "Exp" version of Cygwin installed, plus Python Numeric. Don't forget to point PATH and PYTHONPATH accordingly. Feedback welcome. > As a sidenote, I was able to compile a part of gnuradio with microsoft > visual C++.net 2003 > Just made a project and added all relevant cpp and .h files This is promising! We should be very close to it, as gnuradio-core compiles with MinGW (until the link stage which fails for obscure reason). If you plan to use GNU Radio with Visual C++, you have to know that you won't be able to link against MinGW or Cygwin generated libraries, because the C++ ABI differs. > I had to leave out all vmcircbuf and swig parts so it is not a complete > gnuradio. The swig module building works (with appropriate patches) with MinGW. For VC++, the vmcircbuf will need a new factory based on MapViewOfFileEx. > I was able to play a little with fir filters directly in cpp with my own > buffers. Chances are the only doprod available was the generic one. I managed to compile the x86 speedups under Cygwin, but they require a small rewrite of assembly files because COFF differs slightly from ELF (no .type/.size -> .def ... .endef). I have to check with Eric how this can be done nicely with the preprocessor, but that would need to renamed files from .s to .S and some hacking. Best Regards, -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using USRP from multiple applications simultaneously
On Sun, May 01, 2005 at 08:27:34PM +0200, Harald Welte wrote:
> AFAICT, at the moment there is no way to use a single USRP from multiple
> application programs at the same time. This is quite unfortunate, since
> you might want to run a transmit and a receive program that are totally
> independent (or even two tx and two rx programs).
[...]
I agree, this is a legitimate need, to allow more modular software
architecture.
> I was also thinking of speeding up the USB data transfers by using a
> better kernel/userspace interface than libusb (which does
> copy_{from,to}_user for every URB). Something like a mmap()ed
> ringbuffer comes to mind, much like the mmap() feature of AF_PACKET or
> the PF_RING socket. But that's probably one of the things that would
> be nice and I never find the time to implement...
"Premature optimization is the root of all evil", Donald Knuth.
Before implementing, verify that this is the biggest spot of
optimization. You can use great tools like OProfile for that purpose.
Now, I have the same intuition as you. Copying and copying over
several times data that comes at 32MB/s must have a significative
impact on CPU cache, totally washing it up.
The insidious side-effects may not even show the cache misses on
this code, but on following code down the pipe..
Do you(or somebody else) know a more clever kernel/user interface
with zero-copy for the USB subsystem?
Besides the copy_{from,to}_user, GNU Radio does couple of unnecessary
copy. Those spot will get care when entering optimization round.
I guess now we're more in functional development, but it's always
open on who has spare time ;-)
Cheers,
--
Stephane
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP icon?
Hi fellows, GNU Radio project has its logo, as well as Ettus Research. What about the USRP? I'm looking for an USRP icon. Is there an official one, or can some artist on the list share one with us? Thanks in advance -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Introduction.
On Fri, Apr 08, 2005 at 09:46:02AM -0400, Lamar Owen wrote: [...] > We plan on developing full-bore spectroscopy frontends, both local GUI and > Web > GUI, as well as RPC-type remote spectrometers (like, putting a USRP and a > small low-power PC in the feedbox of one of our 26m telescopes and sending > the data down GigE over fiber). Haha, sending data using Giga Ethernet, nice idea! What about cutting down the small low-power PC, and have the USRP talk directly GigE ? Cheap interferometer anyone? There's a page at http://comsec.com/wiki?USRPnotUSB discussing about that. So far, there's no design, only ideas. Matt, do you think there's enough spare I/O in the FPGA for 24 signals at 125MHz ? RGMII can cut half, but signals have to be DDR which may be a problem. How many gates are left? Enough for a stripped down MAC? Disclaimer: I'm no hardware guy :-) All the best with your exciting project, -- Stephane - F8CFE ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using FreeBSD
On Thu, Mar 31, 2005 at 09:26:42AM -0600, LRK wrote: > I can get the CVS files but bootstrap does not find the autotools executables > because they are installed with the version number, i.e. > /usr/local/bin/automake19 > > I made links by hand but there appears to be some mechanism that should allow > the versions to be specified in the .m4 files so different versions could be > used when several versions are available. > [..] > While I can "workaround" these, is there a "right" way to fix them? What is the Right Thing(tm) to do? Dunno. On my GNU/Debian system, I simply modified my boostrap file thusly: aclocal-1.7 -I config autoconf2.50 autoheader2.50 libtoolize --automake automake-1.7 --add-missing according to the README directions: Ensure that you've got THESE VERSIONS of the following tools: autoconf 2.57or later automake 1.7.4 or later libtool 1.5 or later swig 1.3.23 or later I'm not sure though if swig 1.3.24 wouldn't be better. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FSK now (really) working at 100kbit/sec
On Mon, Feb 28, 2005 at 03:59:00AM -0800, Eric Blossom wrote: > Matt and I spent some time looking at the FSK code over the weekend. [...] nice! > The primary bottleneck is in the rx path and is in the generic (C++) > implemenation of gr_fir_ccf. We could use a SIMD version > of this filter primitive (and/or a smarter demod implementation). gr_fir_ccf with SIMD is an easy one. Basically, it's like a FCC but with input and taps swapped at the dotprod level. IOW, the SIMD assembly is written already, and we just need the API glue and qa stuff. If nobody does it, I'll look at it once I get the usrp going on win32.. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What is a ppio_ppdev?
On Sun, Feb 20, 2005 at 11:54:44AM +1030, Berndt Josef Wulf wrote: > On Sun, 20 Feb 2005 12:46 am, Stephane Fillod wrote: > > On Sat, Feb 12, 2005 at 09:30:33AM -0800, Eric Blossom wrote: > > > On Sun, Feb 13, 2005 at 01:46:22AM +1030, Berndt Josef Wulf wrote: > > > > ppio_ppdev: Not implemented on this platform > > > > > > > > Running NetBSD, I suspect this to be a Linux specific device. > > > > Is there some arch portable way of controlling the parallel port (like > > Linux ppdev) under NetBSD? > > According to the ppbus(4) documentation,there appears to be support for such > device - ppi(4) - see below: > >o a user interface named ppi(4) that allows parallel port access >from outside the kernel without conflicting with kernel-in >drivers. OK, it's commited to the Hamlib CVS. If you want to give it a try, I cannot test that #ifdef'ed code under a non-BSD system :-) > > > In general we should abstract the interface to the RF front end. > > > The the user would specify -- perhaps through some kind of preference > > > file -- which specific RF front end to use. > > > > Ah, you mean some kind of abstraction library, that is consistent and > > portable, has python binding, yet with a *GPL license? We have it, > > it's called Hamlib[1] :-) There's already support for microtune 4937 and > > 4702 (I haven't tested though), a bunch a various transceivers (incl. > > SDR1000), receivers, kits, etc. > > > > Would that make it? > > > > > > [1] http://hamlib.org > > I have a Microtune 4707 tuner and would be interested in supporting this in > hamlib if it is of any interest. I haven't compared the docs for 4702 and > 4707 but suspect that it should be relatively easy to support both. I was > planing to build a daughter board connecting the tuner to the USRP. Feel free to commit support for the 4707, there's a microtune backend ready for that. Probably some other fine folks have such tuner. Cheers, Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] interface levels
On Fri, Feb 18, 2005 at 01:43:46PM -0500, Ralph Hyre wrote: > What you describe sounds a little bit like what concepts like RDL > (Radio Description Language) are for. > > I agree that there need to be multiple levels of accessibility: > > 1) one level for the application builder building a consumer friendly > front-end based on existing blocks of functionality (think of LEGO > mindstorms and their RCX 'brick' and you are on the right track.) > > 2) a lower-level set of interfaces, designed to support standard radio > modulation and demodulation (FM detection, mixing, AGC, and so forth) > > 3) the physical interfaces to the specific RF platform. > (This is where you are concerned about whether you are talking to a > USRP, SSRP, or SDR1000) Interfaces are good, and I had this in mind[1] to integrate GnuRadio 0.9 within Hamlib. That'd be nice to have an abstraction interface for D/A, A/D so the modulation/demodulation blocks can remain generic. Much more work on the road.. [1] http://hamlib.sourceforge.net/gnuradio.html -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What is a ppio_ppdev?
On Sat, Feb 12, 2005 at 09:30:33AM -0800, Eric Blossom wrote: > On Sun, Feb 13, 2005 at 01:46:22AM +1030, Berndt Josef Wulf wrote: > > ppio_ppdev: Not implemented on this platform > > > > Running NetBSD, I suspect this to be a Linux specific device. Is there some arch portable way of controlling the parallel port (like Linux ppdev) under NetBSD? > In general we should abstract the interface to the RF front end. > The the user would specify -- perhaps through some kind of preference > file -- which specific RF front end to use. Ah, you mean some kind of abstraction library, that is consistent and portable, has python binding, yet with a *GPL license? We have it, it's called Hamlib[1] :-) There's already support for microtune 4937 and 4702 (I haven't tested though), a bunch a various transceivers (incl. SDR1000), receivers, kits, etc. Would that make it? [1] http://hamlib.org -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
