Please bear my short message below,
I am sorry Mr. Marcus, i know i asked some irrelevant and undefined
questions. But this question is not mine, my scientific professor aksed me
try to convert the FM wav file to I, Q values if possible. I also confused
with that question and searched some papers too but no information
regarding this.
Thank you Marcus.
Best Regards,
M. Jahnavendra
On Thu, Jun 29, 2017 at 9:30 PM, <discuss-gnuradio-requ...@gnu.org> wrote:
> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
> discuss-gnuradio-requ...@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
> 1. gr-eventstream, gr-mapper, gr-burst revisted (Cinaed Simson)
> 2. [UHD] Introducing the Python API (Martin Braun)
> 3. Convert recorded FM wav file to I,Q values (Jahnavendra Mattipa)
> 4. Re: Convert recorded FM wav file to I,Q values (Marcus M?ller)
> 5. query about fm example file in github tutorials repository
> (Jacqueline.Walker)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 28 Jun 2017 14:58:55 -0700
> From: Cinaed Simson <cinaed.sim...@gmail.com>
> To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
> Subject: [Discuss-gnuradio] gr-eventstream, gr-mapper, gr-burst
> revisted
> Message-ID: <f276b53f-1ddc-65b2-00e9-566a50070...@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> gr-eventstream:
> --------------
>
> In '_es_swig.so', instead of including the symbol 'init_es_swig' and
> linking to python2 libraries, it was including the symbol
> 'PyInit__es_swig' and linking to python3 libraries.
>
> See ./build/swig/es_swigPYTHON_wrap.cxx.
>
> Tried to modify the cmake file GrPython.cmake and GrSwig.cmake but
> couldn't stop '_es_swig.so' from including the symbol 'PyInit__es_swig'
> and linking to to python3 libraries.
>
> So I had to uninstalled libpython3-dev and it passed
>
> make test
>
> gr-mapper:
> ---------
>
> Test failed because the cart got in front of the horse.
>
> In 'qa_preamble.py' I had to replace 'import mapper' with
> 'import mapper_swig as mapper' and then it passed
>
> make test
>
> gr-burst:
> ---------
>
> Fails because 'qa_synchronizer_v3.py' because
>
> x = sio.loadmat('../../matlab/gr_impl_test.mat')
>
> can't find the file 'gr_impl_test.mat' - which is typically a show
> stopper - there could be other errors.
>
> Couldn't find the file on
>
> https://github.com/gr-vt/gr-burst/tree/master/matlab
>
> either - and yes, 'scipy' is installed on the system.
>
>
> -- Cinaed
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 28 Jun 2017 15:36:23 -0700
> From: Martin Braun <martin.br...@ettus.com>
> To: "'usrp-us...@lists.ettus.com'" <usrp-us...@lists.ettus.com>,
> "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
> Subject: [Discuss-gnuradio] [UHD] Introducing the Python API
> Message-ID: <954eb77d-f574-aea4-25a7-956076e07...@ettus.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi all,
>
> some people have already heard the rumour that we're working on a Python
> API for UHD that does not involve gr-uhd. And yes, it's true. A minute
> ago, I published our current development branch on github:
>
> https://github.com/EttusResearch/uhd/tree/python-api
>
> We'll be doing some more development on this branch before we're merging
> it, but most importantly, we'd like to get some feedback from the
> greater community.
>
> The biggest thing missing is more documentation, but it already includes
> some examples. It's definitely ready for testing!
> If you have feedback, post it either in this thread, or on github:
> https://github.com/EttusResearch/uhd/issues/105
>
> I've tried to preempt some questions:
>
> - Does it support Python 2 and 3? Yes.
> - Does it use SWIG? No, it uses Boost.Python. We didn't want to add
> another dependency to UHD (i.e., SWIG) and Boost was already a
> dependency of UHD. It also doesn't require the C API.
> - How does this relate to the Python API in gr-uhd? It serves an
> entirely different purpose. This Python API is for people writing
> standalone applications for USRPs that *don't* use GNU Radio. gr-uhd is
> staying the way it is, and is going nowhere. If you're using GNU Radio,
> you probably don't care about this.
> - Are the UHD Python API and the gr-uhd Python API compatible? Short
> answer: No. Long answer: There are very few cases where it makes sense
> to mix these APIs, so no. However, this means that a TimeSpec from the
> Boost.Python API is not convertible into a time_spec_t from the gr-uhd API.
> - When will it be released? TBD, but if we hear a lot of encouragement
> that'll drive things along faster. It'll go into master branch whenever
> it's considered stable enough, and then in the first major release after
> that merge.
> - Does it support RFNoC API? Not yet, but it's not hard to add. We
> wanted to get the basics (i.e. multi_usrp API) right first.
> - What's the streaming performance? Worse than straight C++. Better than
> I would have thought, thanks to numpy. We have no benchmarks yet.
> Overall, recv() calls are pretty efficient if you've preallocated a
> numpy array, because we can cast that to a straight pointer (and also
> skip any type checking!!!!!!) and then it's not that different from a
> recv() call in a C++ app. However, consuming the data is limited by how
> fast you can handle that in Python.
>
>
> We're really looking forward to feedback from the community.
>
> Cheers,
> Martin
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 29 Jun 2017 11:25:22 +0530
> From: Jahnavendra Mattipa <jahna.mattipa2...@gmail.com>
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Convert recorded FM wav file to I,Q values
> Message-ID:
> <CAH5NE-Z9CNphqc8h6FYiBSqWW2PvHh3xNs==
> jq0a3uv1rfo...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello all,
> Is there any possibility to convert the recorded FM 'wav' file to I,Q
> values, if possible please tell me how to do this?
>
>
> Best reagards,
> M. Jahnvendra
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/
> attachments/20170629/426d8f13/attachment.html>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 29 Jun 2017 11:04:23 +0200
> From: Marcus M?ller <marcus.muel...@ettus.com>
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Convert recorded FM wav file to I,Q
> values
> Message-ID: <f6f16e7f-4829-bf1c-7591-b437eeb22...@ettus.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Mattipa,
>
> uh, what? What files are you referring to? Please make sure that someone
> who's got no idea what you're working on can understand your question.
> We like to help, but our senses of clairvoyance are severely
> underdeveloped :)
>
> Best regards,
> Marcus
>
>
> On 29.06.2017 07:55, Jahnavendra Mattipa wrote:
> > Hello all,
> > Is there any possibility to convert the recorded FM 'wav' file to
> > I,Q values, if possible please tell me how to do this?
> >
> >
> > Best reagards,
> > M. Jahnvendra
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/
> attachments/20170629/12c1f886/attachment.html>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 29 Jun 2017 14:39:00 +0000
> From: Jacqueline.Walker <jacqueline.wal...@ul.ie>
> To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
> Subject: [Discuss-gnuradio] query about fm example file in github
> tutorials repository
> Message-ID:
> <29cc4baee76e33429fb7f05bdc99630267a9c...@exmbx3.ul.campus>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> I downloaded the file fm101.8MHz_1Msps.cfile (from
> gr-tutorials/examples/tutorial6/
> ) to use for trying out demodulation flowgraphs in gnuradio. It was
> recommended here: https://wiki.gnuradio.org/index.php/Guided_Tutorial_
> Hardware_Considerations
> But I can't find any details about the file - it says on the tutorial page
> - 'an actual recording from a radio (USRP I presume) with nothing done to
> the data, so I presume it is just a binary stream such as one would receive
> from a USRP and that the centre frequency is 101.8MHz. What is the sample
> rate output by the USRP that recorded the file - is it 250k as given on the
> tutorial page? What is the signal bandwidth expected? I ask this because I
> don't see that much on the FFT?
>
> Thanks
> Jacqueline
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/
> attachments/20170629/e7686796/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ------------------------------
>
> End of Discuss-gnuradio Digest, Vol 176, Issue 29
> *************************************************
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
