Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha beta ??
On Fri, Mar 17, 2006 at 10:48:24AM -0800, Matt Ettus wrote: It just seeemd strange to me that a very large number, d_freq, which is bounds limited to between d_min_freq and d_max_freq, is inside a function trying to limit it's output to between +PI and -PI. if(100e3 M_PI) return(100e3-M_TWOPI) or 3.7168... error can get close to zero, but frequency will never be less than d_freq_min. d_freq is not in Hz. It needs to be in radians per sample, which should always be less than PI. That clears it up. Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] jackit cvs rep not accessible
On Mon, Mar 20, 2006 at 12:28:28PM +0100, Matteo Campanella wrote: Hello, the cvs repository for jackit seem not accessible from here at least from Sunday morning... it just hangs at login time. Alot of other projects, always located on sf are perfectly accessible instead... is any of you experiencing the same thing? regards Matteo On the source forge site status page, the indicate that projects with names beginning with some subset of A-Z are hosed. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha beta ??
On Fri, Mar 17, 2006 at 11:06:00AM -0500, Charles Swiger wrote: On Thu, 2006-03-16 at 19:55 -0500, Robert McGwier wrote: phase is ALWAYS computed in an NCO by phase = phase + freq so this says that phase_new = (phase_old + GAIN_FOR_PHASE*measured-phase-err) + NewFrequency. SO Something is amiss. You just turned your second order phase locked loop into a first order loop. It is NOT a typo. It's way over my head but is d_freq supposed to be in the d_phase calculation, 2nd line? phase is mod_2pi but freq can be a very big number, like mod_2pi(10 + 1.572849). That is I'm USING very big numbers for max_freq and min_freq - don't suppose they're normalized somehow. OK. I can see why that would be a problem. mod_2pi is optimized for the expected close in case (symmetric around zero), thus the phase isn't *really* getting folded down to [-pi,pi]. Try changing mod_2pi to make the bounds check and then compute the modulus if it needs to using division, floor, multiplication and subtraction. It's not cheap, but it'll probably compute the right answer. Ok, I start to see - d_phase is an accumulator in (supposedly) mod_2pi bounds - so d_freq would indeed be the derivitive of phase (the steeper the phase, the greater the frequency) - and a 2nd order control loop has a proportional and a derivitive component. Then d_phase is converted to sin/cos for output. It just seeemd strange to me that a very large number, d_freq, which is bounds limited to between d_min_freq and d_max_freq, is inside a function trying to limit it's output to between +PI and -PI. Chuck, let me try again. The function has the right name, mod_2pi, but the wrong implementation ;) These are commonly called bugs ;) Hence my comments above about doing the mod the right way. if(100e3 M_PI) return(100e3-M_TWOPI) or 3.7168... error can get close to zero, but frequency will never be less than d_freq_min. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't find fgpa bitstream
On Sun, Mar 19, 2006 at 12:48:21PM +1030, Berndt Josef Wulf wrote:
On Sunday 19 March 2006 11:00, Vincenzo Pellegrini wrote:
I'd be really thankful if somebody could shade light on this error.when
I get to this point the green led on usrp has already slowed down to 1
Hz.but it seems I can't go further for the moment
thanks
vincenzo
You have to copy the firmware files manually to usr/local/share/usrp/rev{2,4}
cd your_path_to_gnuradio_source_code/usrp/fpga/rbf/rev2
cp *rbf /usr/local/share/usrp/rev2
cd your_path_to_gnuradio_source_code/usrp/fpga/rbf/rev4
cp *rbf /usr/local/share/usrp/rev4
The firmware was installed automatically in previous revisions but for some
reason nolonger is.
Hmmm, if so, this got accidentally broken.
I'll check and fix if necessary.
Thanks for letting me know.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] jackit cvs rep not accessible
It really is a shame to see this once spectacular resource go straight across the River Styx into the fire. Do we have any idea what the overall problem is? Bob Eric Blossom wrote: On Mon, Mar 20, 2006 at 12:28:28PM +0100, Matteo Campanella wrote: Hello, the cvs repository for jackit seem not accessible from here at least from Sunday morning... it just hangs at login time. Alot of other projects, always located on sf are perfectly accessible instead... is any of you experiencing the same thing? regards Matteo On the source forge site status page, the indicate that projects with names beginning with some subset of A-Z are hosed. Eric -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] jackit cvs rep not accessible
Hello, the cvs repository for jackit seem not accessible from here at least from Sunday morning... it just hangs at login time. Alot of other projects, always located on sf are perfectly accessible instead... is any of you experiencing the same thing? regards Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Firmware files not installed in current version of usrp
G'day, usrp-cvs doesn't install firmware files. std_Files had to be copied manually. cheerio Berndt pgpVMbbeo1G3j.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] headsup: gr-audio-portaudio on NetBSD
G'day, I've built and installed gr-audio-portaudio on NetBSD-i386-current and ran mono_tone_portaudio and multi_tone_portaudio without problems. I plan to create a pkgsrc package once portaudio implemented the pkg-config code changes. I've noted that I was unable to specifiy the audio device using -O and -d command options returning a device not found message for /dev/audio and /dev/sound. gr-audio-portaudio insists of using /dev/dsp which is a softlink to /dev/audio on my system. barossa: (209) ./mono_tone_portaudio.py -O /dev/audio -d /dev/audio Number of devices found = 1 --- device #0 [ Default Input, Default Output ] Name= /dev/dsp Host API= OSS Max inputs = 2, Max outputs = 2 Default low input latency =0.012 Default low output latency =0.012 Default high input latency =0.046 Default high output latency =0.046 Testing device name: /dev/dsp audio_portaudio_sink[/dev/audio]: Failed to find specified device name: Success Traceback (most recent call last): File ./mono_tone_portaudio.py, line 56, in ? my_graph().run() File ./mono_tone_portaudio.py, line 49, in __init__ dst = audio_portaudio.sink (sample_rate, options.audio_output) File /usr/pkg/lib/python2.4/site-packages/gnuradio/audio_portaudio.py, line 234, in sink return _audio_portaudio.sink(*args) RuntimeError: std::runtime_error cheerio Berndt pgpfFlP5wJZQV.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] jackit cvs rep not accessible
On Mon, Mar 20, 2006 at 01:08:19PM -0500, Robert McGwier wrote: It really is a shame to see this once spectacular resource go straight across the River Styx into the fire. Do we have any idea what the overall problem is? Bob My guess is that they have insufficient revenue to support the infrastructure and staffing requirements. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Modifying vectors
Eric Blossom wrote: On Fri, Mar 17, 2006 at 10:27:45AM +0100, Patrick Strasser wrote: Hello! fft = gr.fft_vfc(fft_size, True, window.hanning(fft_size)) ifft = gr.fft_vcc(fft_size, False, window.hanning(fft_size)) self.connect(s2p, fft ) self.connect(fft, ifft ) self.connect(ifft, p2s ) now I want to modify data between fft and ifft. Do I have to make a custom block in python (I'd like to do this anyway...)? Depends on what you want to do. A few of the blocks support an optional vlen constructor argument. These will apply the given operation to a vector of items. If for example you want to independently filter the bins, you could use gr.stream_to_streams, a bunch of filter blocks, then gr.streams_to_stream. See gnuradio-core/src/python/gnuradio/blksimpl/filterbank.py So you can use these blocks with vectors of that type too. Clever shortcut! No, I want to interpolate between the bins. I want to modify the spextrum. I know there is at least one other way (resampling), but this is the most straight forward way for me. This isn't completely sorted out. Besides adding the vlen attribute to many blocks, we've also considered using a Numeric / NumPy / SciPy ufunc (universal function) mechanism and then a small number of GNU Radio blocks that know how to apply ufuncs across streams. ufuncs would probably be easier to write in the common cases than full GNU Radio blocks. And a ufunc would be able to modify the stream on the fly? Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser patrick dot strasser at tugraz dot at Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] jackit cvs rep not accessible
On Mon, Mar 20, 2006 at 07:44:41PM +0100, Matteo Campanella wrote: Well, in the meanwhile, as jackaudio seems the only way to use a soundcard based decoding software as gmfsk or drm with usrp, is there anyone with a quite recent cva checkout willing to tarball it and send down here? gr-audio-alsa and gr-audio-oss both work. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble running test programs
Just to clarify because I'm guessing this will be the first guessI already have LD_LIBRARY_PATH set to /home/jjw27370/gr/lib -- View this message in context: http://www.nabble.com/Trouble-running-test-programs-t1313375.html#a3501148 Sent from the GnuRadio forum at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble running test programs
I've determined that there are two possible solutions to my problem. The first problem I do not have proper permissions on my user name in order to access the USB? I've looked at a couple different methods for giving myself permissions (I have access to root) and nothing seems to work. The other issue...If I run sudo (to get around the USB permissions issues), it seems to ignore the environment variable for LD_LIBRARY_PATH I created for my user name. Does anybody know a way to give myself permissions for the USB (ideal) and/or to make sure the environment variables stay in place when I run sudo (less preferable but still good to know). Thanks -- View this message in context: http://www.nabble.com/Trouble-running-test-programs-t1313375.html#a3503327 Sent from the GnuRadio forum at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sourceforge CVS up again?
It seems as of 18:11 EST Sourceforge CVS is back up; I was able to get a checkout of usrp. Yep, got a fresh checkout twice. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using gr.vector_source_f()
Hello All!
I am a new gnu radio user and am stuck with an elementary problem...
I am trying to generate a data-driven source using gr.vector_source_f()
with the following code:
#!/usr/bin/env python
from gnuradio import gr
from gnuradio import usrp
def build_graph ():
fg = gr.flow_graph ()
data = (-5000,5000)
src0 = gr.vector_source_f ( data, 1 )
dst = usrp.sink_c (0,64)
f2c = gr.float_to_complex()
fg.connect ( src0, f2c, dst )
return fg
if __name__ == '__main__':
fg = build_graph ()
fg.start ()
raw_input ('Press Enter to quit: ')
fg.stop ()
I have a few questions and would really appreciate if someone could help:
1) Is it possible to generate square waves using this function? Or any
function? I just get different sinusoids for different vector inputs. For
example the above code gives me a perfect sine wave (which I did not
expect). And for vectors with length 2, it is some other form of
sinusoid.
2) What is the quantitative relationship between the vector and the
waveform for this function? I see some trend but I am unable to quantify
it perfectly.
3) As of now, I am controlling the frequency of the waveform by varying
the interpolation rate as follows:
output frequency = 64M/interpolation rate
Is there another way?
Pardon me if my queries are inane...
Thanks in advance for the help!
Regards,
Suhrid
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] portaudio sink, partial succes on windows
This is excellent news. I can't believe we have only been attempting this for a little over a week. It will improve. Please change the 10.66 ms interval in check_topology UPWARDS until the crackling stops. I am sure you are not able to handle 11 msec latency with wmme. You will be lucky if it will sustain 100msec latency. wmd_ks is MUCH better and that driver does work. Stephane submitted to portaudio an official patch that will allow pa19 to be developed under mingw, linux, osx, etc. They have agreed to adopt it after review. Congratulations. Bob Martin Dvh wrote: Robert McGwier wrote: Thanks to tons of grunt work by Eric, we have used the highly tuned ring buffers in the audio_portaudio_sink code and it functions nicely with a little bit of operator help.I can now get solid performance on all Linux hosts with the example code mono_tone_portaudio.py and multi_tone_portaudio.py. All worked on oss, alsa, and jack. Eric got similar performance. Thomas Schmid ran mono_tone_portaudio.py successfully on his mac with coreaudio automatically identified as the host. We had to modify the buffer size calculation (by forcing it). This will improve over the next few days as the audio_portaudio_source gets built and these very large portaudio messages which are delivered in device and stream info structs are parsed more carefully. It is not clear to me that we want to prefer portaudio talking to jack over directly talking to jack. This might change if we (Stephane, me, others) improve the portaudio jack handler. For now, my thinking is we are probably better off and we will be more versatile talking directly to jack without portaudio but we can do this kind of thinking after we get this portaudio stuff fully stabilized. I am hoping the Windows folks can bring their code up now as well. Portaudio is really solid on Windows as I have been using it there for ASIO, MME, and DirectX for two years and after I helped Eric Wachsman get a leg up (by leaning on my friends for help) he got WDM-KS running. WDM-KS is the single lowest latency sound host I have seen in ANY personal computer but let me say that I have never used a Mac. If anyone working on the windows code needs a dll, export library, Microsoft .NET 2003 project for v-19 devel, please let me know. We should be able to build the dll under mingw but I have not tried yet. That said, all of this portaudio stuff about latency this and that make very little sense for what we are doing. What we need is not necessarily very low latency but rock solid performance using buffer sizes that make sense for our applications. A partial success on windows. I have portaudio running on windows (just the wmme driver) and for the first time I hear sounds without too much crackles here. I needed only a few tweaks. Most important, don't use standard cvs HEAD of portaudio but the special cvs v19-devel version I missed the following comment in one of the portaudio mails It will be important to stay current: cvs -d:pserver:[EMAIL PROTECTED]:/home/cvs co -r v19-devel portaudio I had done a normal cvs HEAD checkout and got loads of problems first. You really need the -r v19-devel options. Once that was sorted out I did the following. This is all using mingw: Update/build/install gnuradio-core do a configure/build/install for portaudio-v19-devel (only default configure options, so it is using the wmme driver) Then I had to make the following symbolic link: /usr/local/lib/pkgconfig/portaudio-2.0.pc - /usr/local/lib/pkgconfig/portaudio.pc then checkout gr-audio-portaudio do a bootstrap Check that the latest libtool version is used do a configure/build/install update gnuradio-examples run: dial_tone_portaudio.py mono_tone_portaudio.py multi_tone_portaudio.py All run fine ;-) modify usrp/usrp_wfm_rcv.py to use portaudio run it listen to my favourite FM station without too much crackles. (The audio is not completely clean yet, but probably the ks driver will help here) now run usrp/usrp_wfm_pll_PA.py runtime error popup immediately change from non-blocking to blocking portaudio runtime error popup immediately disable fft displays runs ok for 5 to 20 seconds after that a runtime error popup enable non-blocking again runtime error popup immediately The runtime error I get is a popup: (also see attached image runtime_error.gif) Microsoft Visual C++ Runtime Library Runtime Error! Program: d:\Python24\python.exe abnormal program termination So it only works with blocking enabled and no ffts, and only for a few seconds. I think it has to do with something not keeping up. I can force this error by clicking on any other open program window or moving another window. I then tried opening/moving windows while running multi_tone.py and this causes multi_tone.py to stop too with the same runtime error. Running a high computational load in the background doesn't seem to hurt
