[Discuss-gnuradio] FHSS
Hi. First time caller. Are any FHSS (frequency hopping spread spectrum) options avail in software for gnuradio/USRP? Or do I need to create one by hand? If someone else has implemented this, can someone provide a pointer to code, so that I can use their ideas? Joshua Davis Transient Infrastructure Security Solutions /"\ \ /ASCII Ribbon Campaign X against HTML email & vCards / \ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build fails on make check - finally got it all working
On Mon, Jul 04, 2005 at 08:40:12PM -0700, Ges wrote: > > I am sorry. I didnt realise the paths were absolute. No problem. Normally it "just works", so I'm a bit puzzled. That's why I suggested the --srcdir=DIR option. Did --srcdir solve your problem? I'm curious about what part of your configuration was triggering this behavior, so that perhaps we can work around it, or at least recognize it in the future. > I am not sure if it is related to my use of AFS...it > doesnt look like it, because I dont work off AFS, I > just have some of the executables in /usr/local/.. > symbolically linked to some AFS files. But then again, > I shall check up on this sometime. If you ever get around to tracking it down, I'd love to hear what you find. > Thank you for the quick note on the gnuradio-examples. You're welcome! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FHSS
On Tue, Jul 05, 2005 at 04:45:06AM -0400, Joshua Davis wrote: > > Hi. First time caller. Welcome! > Are any FHSS (frequency hopping spread > spectrum) options avail in software for gnuradio/USRP? Or do I need to > create one by hand? If someone else has implemented this, can someone > provide a pointer to code, so that I can use their ideas? We haven't implemented anything at this point, but we've given it quite a bit of thought. One of the questions that needs be answered depending on your application/hardware, is would you be hopping by controlling the RF front end, or are you hopping over a narrow enough range of frequencies that we could do it all in software/FPGA? There are of course the normal wide band / dynamic range issues if you try to do the hopping all in software/FPGA, but it would be pretty straight-forward. You could also hop at a ridiculously high rate since you don't have to wait for an analog PLL to settle. It might we worth taking a look at the FM3TR spec for a starting point. http://mccoy.ucsf.edu/emondi/Public/FM3TR/FM3TR_Summary.html http://www.computing.surrey.ac.uk/personal/pg/E.Willink/wdl/Fm3tr.html http://www.sdrforum.org/MTGS/mtg_25_sep01/01_i_0056_v0_00_fm3tr_97_09_10_01.pdf Eric > >Joshua Davis >Transient Infrastructure Security Solutions > Nice sig ;) > /"\ > \ /ASCII Ribbon Campaign >X against HTML email & vCards > / \ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FFT of FFTs
OK, I'm just getting around to trying these suggestions... First, re Eric's suggestions below. A few quick questions about this. I'm interested in tuning to a frequency (with usrp/frontend) then examining a single stream for periodic content. I've tried this but not exactly sure what I'm seeing. The questions are, have I set this up properly? I have intended to grab whatever signal is at 50kHz (arbitrary) above what we're tuned to and analyze that. How do I best select the feed forward and feed back filter coefficients? (I ended up using the tool as written in the comments). Also, any suggestions on things to look at within the TVRX range that should definitely test this out? (I think that GSM (TDMA) bands are a bit out of range... up around 900MHz). I wondered if I could pick out the periodicity of NTSC scans perhaps (maybe I'd need like a test pattern, eh? to guarantee that the scan is periodic and non changing long enough for me to try it). # xlating filter adnl_decim = 1 taps = [1.0] shift = -50e3 capture_rate = usrp_rate channel_coeffs = gr.firdes.low_pass (1.0, # gain capture_rate, # sampling rate 200e3, # low pass cutoff freq 200e3, # width of trans. band gr.firdes.WIN_HAMMING) xlate_filt = gr.freq_xlating_fir_filter_ccf(adnl_decim, channel_coeffs, shift, capture_rate) # complex to magnitude cplx_to_mag = gr.complex_to_mag() # # Filter Coeffs correspond to butterworth iir low pass filter # passband 0 - 1000 Hz # Order 1 # # http://www.dsptutor.freeuk.com/IIRFilterDesign/IIRFilterDesign.html # fbtaps = [0.29289326, 0.29289326] fftaps = [1.0, -0.41421357] iir_low_pass = gr.iir_filter_ffd(fftaps, fbtaps) # fft occ_fft = fftsink.fft_sink_f (self, panel, title="Occupancy FFT", fft_size = 512, sample_rate=usrp_rate, baseband_freq=0) self.connect (src, cplx_to_mag, iir_low_pass, occ_fft) Eric Blossom wrote: On Sat, Jun 18, 2005 at 08:18:38PM -0400, James Cooley wrote: Hi all, I'm trying to take an FFT of an FFT Basically, I want to tune to a signal, and for a given RF frequency, try to spot periodic usage of that frequency. Is this possible? What I have now is hopelessly slow, so I'm not really sure if I've got it right. Hi Jamie, Here are a couple of suggestions. If there are relatively few frequencies that you want to observe for periodic occupancy, I would suggest extracting the frequency bands of interest using a gr.freq_xlating_fir_filter for each one. If there are lots of them, and they are evenly spaced, then the dft filterbank is what you want to split them out (blksimpl/filterbank.py). Once you've got your individual streams of signals, for each one I would compute an estimate of whether it is occupied. You could do this by computing the magnitude of the stream (gr.complex_to_mag) and then low pass filtering that with a gr.iir_filter, possibly followed by a limiter (which would need to be written). At this point, for each of your input streams, you have an output stream that is effectively a stream of 1's and 0's, where 1 means "is occupied". Then run each of those streams into it's own FFT. Point this whole pipeline at some kind of TDMA input (GSM basestation?) and you ought to see the slots (assuming the basestation isn't driving all the slots all the time). Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] subscribe to patch-gnuradio doesn't work
I tried to subscribe to the patch-gnuradio list but it didn't work. This is what I got back. Greetings, Martin Original Message Subject: Returned mail: see transcript for details Date: Tue, 5 Jul 2005 23:12:16 +0200 (CEST) From: Mail Delivery Subsystem <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> The original message was received at Tue, 5 Jul 2005 23:12:14 +0200 (CEST) from a213-84-8-196.adsl.xs4all.nl [213.84.8.196] - The following addresses had permanent fatal errors - <[EMAIL PROTECTED]> (reason: 550 unknown user) - Transcript of session follows - ... while talking to mx10.gnu.org.: DATA <<< 550 unknown user 550 5.1.1 <[EMAIL PROTECTED]>... User unknown <<< 503 valid RCPT command must precede DATA Reporting-MTA: dns; smtp-vbr14.xs4all.nl Received-From-MTA: DNS; a213-84-8-196.adsl.xs4all.nl Arrival-Date: Tue, 5 Jul 2005 23:12:14 +0200 (CEST) Final-Recipient: RFC822; patch-gnuradio-request@gnu.org Action: failed Status: 5.1.1 Remote-MTA: DNS; mx10.gnu.org Diagnostic-Code: SMTP; 550 unknown user Last-Attempt-Date: Tue, 5 Jul 2005 23:12:16 +0200 (CEST) --- Begin Message --- --- End Message --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] subscribe to patch-gnuradio doesn't work
On Tue, Jul 05, 2005 at 11:19:46PM +0200, Martin Dvh wrote: > I tried to subscribe to the patch-gnuradio list but it didn't work. > This is what I got back. > Greetings, > Martin Fixed. You are subscribed. Eric ___ 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
Stephane Fillod wrote: 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. No feedback at all. I thought I was doing many people a favor but the total lack of response dissapointed me a bit. So I am glad somebody noticed. 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? No, not yet. I didn't know what the prefered way was to contribute patches so I just sent it to the list. After I received your mail I tried to subscribe to patch-gnuradio but got the following back: - The following addresses had permanent fatal errors - <[EMAIL PROTECTED]> (reason: 550 unknown user) 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, Yes, I found out myself that I did write the new macros but forgot to put them in the Makefile.am files. gr_libgnuradio_core_extra_ldflags.m4 should check the compiler supports the option. Did't know (yet) how to do that. > 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. Is this needed? I did look at the cygwin code but didn't really like the code. I seems you try to just allocate the memomry and hope it is continuous, if it is not try again and again. In the end, if you stop trying after several attempts this could fail. While the gnuradio code does not depend on the memory being continuous. I searched for the places where the mapped memory is used. I found that all core gnuradio code only uses the first copy. The only code which uses the second copy is the code which tests the mapped memory and this code does not depend on the memory being continuous. So I thought, why bother. 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? I don't really mind which way the patch is sent. But I would like to submit the patch myself to see if the patch submitting works (since subscribing to patch-gnuradio failed for me) This will give me some experience in the contribution process. (I am working on some more nice new features) If you sent me the modified patch I can also do some regression tests myself (on, linux and windows). Could you also make a diff between my original patch and your modified patch. This way I can learn and it is easier for me to integrate with my latest gnuradio code which has a whole load of additional changes. "Coming soon to a gnuradio near you, gnuradioGPU" (This is gnuradio on the GPU, on windows and linux. For now just FIR filter and some basic blocks, my goal is a complete receiver on the GPU) 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 command
Re: [Discuss-gnuradio] working version of gnuradio for windows (mingw) available including audio-sink and wxgui
> >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, > Yes, I found out myself that I did write the new macros but forgot to put > them in the Makefile.am files. > > >gr_libgnuradio_core_extra_ldflags.m4 should check the compiler supports > >the option. > Did't know (yet) how to do that. > > 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. > Is this needed? > I did look at the cygwin code but didn't really like the code. > I seems you try to just allocate the memomry and hope it is continuous, if > it is not try again and again. >From my brief look at the MSDN docs, CreateFileMapping with an hFile of INVALID_HANDLE_VALUE looked like the way to go. > In the end, if you stop trying after several attempts this could fail. > While the gnuradio code does not depend on the memory being continuous. > I searched for the places where the mapped memory is used. > I found that all core gnuradio code only uses the first copy. Not true. In fact, *every* block uses both the first and second copy, they just don't know they're doing it ;-) The second copy is implicitly used when writing, say an array that is 3/4 of the length of the buffer, but which starts 1/2 way into the buffer. The copy operation starts at the 1/2 way point in the first copy, and ends at the 1/4 point in the second copy, without any code having to check for the wrap in the loop. > But I would like to submit the patch myself to see if the patch submitting > works (since subscribing to patch-gnuradio failed for me) > This will give me some experience in the contribution process. > (I am working on some more nice new features) Fire away when you are ready! > If you sent me the modified patch I can also do some regression tests myself > (on, linux and windows). > Could you also make a diff between my original patch and your modified > patch. > This way I can learn and it is easier for me to integrate with my latest > gnuradio code which has a whole load of additional changes. > "Coming soon to a gnuradio near you, gnuradioGPU" > (This is gnuradio on the GPU, on windows and linux. For now just FIR filter > and some basic blocks, my goal is a complete receiver on the GPU) Sounds great. Eric ___ 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
Martin, we'll need a copyright assignment to FSF to pick up the bulk of the patch. I'll send more info off-list in a bit. I filled in and sent the form >>But I would like to submit the patch myself to see if the patch submitting >>works (since subscribing to patch-gnuradio failed for me) >>This will give me some experience in the contribution process. >>(I am working on some more nice new features) > > > Fire away when you are ready! Just have to wait for Stephane to send me the modified patch. Greetings, Martin ___ 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, Jul 06, 2005 at 01:47:28AM +0200, Martin Dvh wrote: > > >Martin, we'll need a copyright assignment to FSF to pick up the bulk > >of the patch. I'll send more info off-list in a bit. > I filled in and sent the form Thanks! I'll get the windows audio stuff checked in later today. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
