Re: [Discuss-gnuradio] anyone implement the Raleigh fadingmodel/multi-path?

[Richard Clarke]

I've established a temporary (60 day) FTP user account on our company 
FTP server to host the GNU Radio Rayleigh Fading code as it currently 
stands. I've placed the raw code that's relevant to this module there. 
It's not immediately ready to build however that won't take long for 
anyone familiar with integrating user modules into GNU Radio. There is 
some other code relevant to the way we were intending to use the fading 
simulator (i.e in a client/server model across a network) that may be of 
interest to some but is not particularly relevant to the actual fading 
module itself so you can ignore that if you wish.

FTP details: ftp://ftp.tait.co.nz
user: gnuradio
password: gnuradio01


The top level python files 'filesrc_fade_transmit.py' and 
'nbfm_tx_rx.py' are examples of how the fading module might be used. 
The  file 'multipath_rayleigh_channel_cc.py' is the python level module 
I mentioned earlier that handles doing multiple delayed paths, hopefully 
independently faded, but thats something that can be double checked.

Anyway, feel free to grab the code and have a rummage through to 
familiarise yourself. If you have any questions or problems accessing 
the files let me know. I'll do my best to help however bear in mind I 
haven't worked on this directly myself. It was done as part of a summer 
internship a year or so ago and I'm only now getting around to trying to 
use it. I can however get in touch with the student (Jonas Hodel) if 
required.

I will be on leave for a week from this Friday (NZ time) but will be 
back online Monday 11th Feb.

Good luck!

Cheers
Richard

George Nychis wrote:
> Hi Richard,
>
> This would be great!  I have great use for this, and I'm sure many 
> others would too.  Did he generate any documentation showing his 
> evaluation of his implementation, and any details of it?  (like a 
> final research paper).
>
> Could you make this code publicly available to the list so that we can 
> review its implementation and discuss integrating it in to the code 
> base?  We could work on integrating the multiple paths in to the C++ 
> block and making it flexible.
>
> If you host it for us, it won't undergo just one set of eyes, but many 
> sets of eyes on the list :)  But make sure to link to it, rather than 
> send an attachment because of list restrictions.  Then we can put it 
> in a features branch within the SVN repository to work on it if needed.
>
> Thank you!
> George
>
>
> Richard Clarke wrote:
> > Hi George,
> >
> > I have had a Summer student doing some work on this (a year ago now). 
> > He implemented a GNU Radio module that can do Rayleigh channel 
> > simulation. He based it on a particular paper (I'd have to look it 
> > up) for the implementation. He verified the statistical performance 
> > of his implementation against the Matlab Rayleigh channel model and 
> > against theory and found it to be a close match. I'm not entirely 
> > convinced of the delayed multiple path aspects of the 
> > design/implementation but haven't had time to look into it further. 
> > In fact as it stands I believe the GNU Radio module (at C++ level) 
> > only handles a single flat fading path and doing multiple delayed 
> > paths is done at the python module level and which invokes multiple 
> > instances of the Flat fading Rayleigh C++ GNU Radio module.
> >
> > I'd welcome another set of eyes and someone more experienced than I 
> > am with GNU Radio to help finish off this potentially very useful 
> > addition to the GNU Radio code base.
> >
> > Cheers
> > Richard
> >
> >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > =======================================================================
> > This email, including any attachments, is only for the intended
> > addressee.  It is subject to copyright, is confidential and may be
> > the subject of legal or other privilege, none of which is waived or
> > lost by reason of this transmission.
> > If the receiver is not the intended addressee, please accept our
> > apologies, notify us by return, delete all copies and perform no
> > other act on the email.
> > Unfortunately, we cannot warrant that the email has not been
> > altered or corrupted during transmission.
> > =======================================================================

=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================