Ah yes... I have become used to viewing them as one system.
Thank you for the link to the USRP mailing list, I will explore the issue
with them.
Alex
--
View this message in context:
http://gnuradio.4.n7.nabble.com/UHD-Daughter-Board-EEPROM-Format-calibration-data-tp44187p44202.html
Sent
On Wed, Oct 16, 2013 at 07:01:31PM -0300, Gui Ritter wrote:
Sorry, forgot the attachment.
GR 3.7 won't open this. Can you pastebin a screenshot?
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstraße 12
I'm new to Pastebin, and I couldn't find an option to upload images, so I used
ImageShack instead.
http://img844.imageshack.us/img844/5910/s2i3.png
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
On Thu, Oct 17, 2013 at 11:13:14AM -0300, Gui Ritter wrote:
I'm new to Pastebin, and I couldn't find an option to upload images, so I used
ImageShack instead.
That's fine :)
Have you tried a boxcar window?
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
http://img844.imageshack.us/img844/5910/s2i3.png
I'm not convinced by the way you handle the complex part of the FFT result ...
You can't just drop it, it's needed for the reconstruction ...
Cheers,
Sylvain
___
Discuss-gnuradio mailing list
On Thu, Oct 17, 2013 at 04:44:00PM +0200, Sylvain Munaut wrote:
http://img844.imageshack.us/img844/5910/s2i3.png
I'm not convinced by the way you handle the complex part of the FFT result ...
You can't just drop it, it's needed for the reconstruction ...
You're right, but in this case the
On 10/17/2013 10:52 AM, Martin Braun (CEL) wrote:
On Thu, Oct 17, 2013 at 04:44:00PM +0200, Sylvain Munaut wrote:
http://img844.imageshack.us/img844/5910/s2i3.png
I'm not convinced by the way you handle the complex part of the FFT result ...
You can't just drop it, it's needed for the
Hi,
You're right, but in this case the input was already real and the
channel doesn't modify the phase. So it's OK--the 'correct' thing
would be to do a real FFT.
Huh ?
To make sure I actually ran a quick python test before posting :
In [13]: ifft([x.real for x in fft([1,2,3,4])])
Out[13]:
On Thu, Oct 17, 2013 at 05:17:45PM +0200, Sylvain Munaut wrote:
Hi,
You're right, but in this case the input was already real and the
channel doesn't modify the phase. So it's OK--the 'correct' thing
would be to do a real FFT.
Huh ?
Erm, yep :) My apology.
I was assuming you meant the
Just a friendly reminder for those that attended GR Conf 2014 - here is a
survey link to provide some feedback:
http://www.surveymonkey.com/s/W679DNP
Will have a separate, but similar survey for those that could not attend
this year.
-John
___
The video is available at:
http://www.youtube.com/watch?v=rBXcqNg_xT8feature=share
Thanks everyone for attending!
Martin
On Wed, Oct 16, 2013 at 11:32:14PM +0200, Martin Braun (CEL) wrote:
On Wed, Oct 09, 2013 at 10:57:39AM +0200, Martin Braun (CEL) wrote:
As usual, we will be doing a
What I meant was, the survey on GR Conf 2013 that will help improve GR Conf
2014!
On Thu, Oct 17, 2013 at 10:41 AM, John Malsbury john.malsb...@ettus.comwrote:
Just a friendly reminder for those that attended GR Conf 2014 - here is a
survey link to provide some feedback:
Hello GR Forum,
I have to add some instructions for test purpose into some files of
/uhd/host/examples
Could you show me how to make the new files, or send me the link of How to
instructions.
BTW, I never used CMake before. If there is another tool for the purpose I
am ok too.
Regards,
Naceur
I am curious as to the purpose of the 0x55 that is used for padding digital
packets to the USRP (in addition to sticking one on the end of the packet
to begin with)? Are these ignored and dropped by the USRP, or do they
serve some other purpose? And if they are ignored and dropped by the USRP
is
During the monthly developer's call today it was decided that working
groups should communicate through the general GNU Radio mailing list. If
you do not already track that list, please see
http://gnuradio.org/redmine/projects/gnuradio/wiki/MailingLists for
guidance, subscription details, and a
this message show with lsusrp and usrp_fft.py and others script
javier@ubuntu:~$ lsusrp
Traceback (most recent call last):
File /usr/local/bin/lsusrp, line 25, in module
from gnuradio import usrp
File /usr/local/lib/python2.7/dist-packages/gnuradio/usrp/__init__.py,
line 25, in module
Hi Javier,
Python can't find the GNU Radio USRP module shared library, maybe because it's
not installed correctly.
Please note: The version of GNU Radio you are using is old. In fact, it's
ancient. Even if you get it to run without error, it makes a lot less fun to
work with that than with
The repository is here. I tried compiling but it is not ported to GR 3.7 yet.
Hopefully it will be updated.
https://github.com/balint256/gr-baz
On Oct 17, 2013, at 11:01 AM, discuss-gnuradio-requ...@gnu.org wrote:
Dear all,
ther is some block are not available in gnuradio
Greetings,
I have transcribed the discussion and progress of the VOLK working group
from GR Con on the wiki
http://gnuradio.org/redmine/projects/gnuradio/wiki/grcon13volk
The goal of this group is generally to identify areas (and work on them!)
that GNU Radio can change to improve performance on
Hello,
We have used Matlab to generate *.mat file, a file around 1966240 complex
number OFDM samples.
Thinking to (I) transmit between two USRPs, (II) let the receiver side
saving data into file, and later (III) putting the file on Matlab for
demodulation.
1. What is the best way to do it? like
Hello,
I used the File Sink block to save some data.
they are
Byte, pink color
and
complex, light blue color.
How can I get something, like *.m script, to open those types of files on
Matlab?
Thanks a lot.
___
Discuss-gnuradio
On Thu, Oct 17, 2013 at 11:14 PM, JPL jplscan...@gmail.com wrote:
Hello,
We have used Matlab to generate *.mat file, a file around 1966240 complex
number OFDM samples.
Thinking to (I) transmit between two USRPs, (II) let the receiver side
saving data into file, and later (III) putting the
22 matches
Mail list logo
