On 08/06/2012 02:15 PM, Michael Dickens wrote:
> Looking at the CMakeCache.txt file, I don't see CMAKE_C_COMPILER_ID. I do
> see:
>
> //CXX compiler.
> CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++
>
> //C compiler.
> CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc
>
> which result in:
>
> % /usr/bin/c++
I use the Benchmark OFDM instead fo RawOFDM, but I think the basic
synchronization algorithm is the same.
UT austin has a project Hydra which is using the OFDM modulation,
http://netlab.ece.utexas.edu/hydra/
but I did not see any record about the bitrate they achieved. Someone else
told me that Hyd
Hi Alex,
Thanks for sharing your experience. Are you using RawOFDM or Benchmark OFDM?
I agree with you that we need more powerful PCs because for large bandwidth
we have too much samples to process. Furthermore, the bottleneck is
definitely in the receiving part because in our system the transmit
Hey all,
As the ARRL Digital Communication's Conference (DCC) is being held in
the Sheraton just before or GNU Radio conference, John Ackermann of
TAPR asked me to post this here to make sure you were aware of all of
the opportunities in Atlanta this September!
Tom
--
Dear all
I am wondering if we can read the information from some special pins in
daughter board? Right now I can control some pins On/Off in daughter but I
don't how to read the information from those pins.
Can I just program the FPGA in the USRP to achieve some new functions
through xilinx and
Just state, I was using the tunnel.py instead of the rawOFDM to do the
test. Seems nobody declared good bitrate within this community, although I
have asked for many times.
On Mon, Aug 6, 2012 at 3:06 PM, Alex Zhang wrote:
> Hi Qing,
>
> Your experience is exactly what I have tested. The data ra
Hi Qing,
Your experience is exactly what I have tested. The data rate of OFDM based
on the current GNURadio never exceeds 1Mbps with acceptable PER.
I guess the only way to beat more bandwidth is to use very strong
computer...
On Mon, Aug 6, 2012 at 10:12 AM, Qing Yang wrote:
> Dear all,
>
> Re
Looking at the CMakeCache.txt file, I don't see CMAKE_C_COMPILER_ID. I do see:
//CXX compiler.
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++
//C compiler.
CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc
which result in:
% /usr/bin/c++ --version
Apple clang version 4.0
% /usr/bin/gcc --version
i686-apple-da
Thanks a lot, Sreeraj!! You are right. I made it work using
file_sink.close() and file_sink.open() command.
Best,
Nazmul
On Mon, Aug 6, 2012 at 12:39 PM, sreeraj r wrote:
> This might be happening because "gr.file_sink" is not closing the passed
> file handle until its destructed. I checke
This might be happening because "gr.file_sink" is not closing the passed file
handle until its destructed. I checked "gr_file_sink_base"'s source and various
functions like open, close and unbuffered writes are supported. Try playing
around with these(I haven't used these things yet).
http://ww
Hi,
I am trying to simplify my previous email for clarification. I am looking
to resolve the following issue:
I have two flowgraphs:
1. USRP Source --> File Sink # self.file_sink =
gr.file_sink(gr.sizeof_gr_complex*1, "Data.dat")
2. USRP Source --> Null Sink
I have defined both of them in
Dear all,
Recently we are building an OFDM communication system based on RawOFDM(
http://people.csail.mit.edu/szym/rawofdm/README.html). In the simplest
point-to-point
case, we use a pair of PC and USRP as the transmitter and use another pair
as the receiver.
To reduce the influence of CFO, we ne
On 08/06/2012 03:44 AM, Johannes Demel wrote:
> Hello List,
>
> I call the 'get_tags_in_range' function in 'work' in my sink block and
> get the following output:
> thread[thread-per-block[10]: ]:
> gr_block_detail::n_output_items
> all code after get_tags_in_range is never executed and the bloc
On 08/06/2012 09:43 AM, Michael Dickens wrote:
> I'm running OSX 10.8.0, Xcode 4.4, latest updates; all background
> dependencies are installed as both 32 and 64 bit, and includes "orc".
> Please let me know what tests I can run to get more/better info to
> help correct this issue. - MLD
>
I re
On 08/06/2012 09:44 AM, Alexander Olihovik wrote:
> Will the unconsumed items on ports with a larger number of samples sent to
> them be buffered up automatically, or do I need to do that myself?
> i.e. If port 0 has 100 items, and port 1 has 300 items, and I consume 100
> items from each port, w
Will the unconsumed items on ports with a larger number of samples sent to
them be buffered up automatically, or do I need to do that myself?
i.e. If port 0 has 100 items, and port 1 has 300 items, and I consume 100
items from each port, what happens to the remaining 200 items on port 1?
Are they b
I'm running OSX 10.8.0, Xcode 4.4, latest updates; all background dependencies
are installed as both 32 and 64 bit, and includes "orc". Please let me know
what tests I can run to get more/better info to help correct this issue. - MLD
% clang --version
Apple clang version 4.0 (tags/Apple/clang-4
Hello List,
I call the 'get_tags_in_range' function in 'work' in my sink block and
get the following output:
thread[thread-per-block[10]: ]:
gr_block_detail::n_output_items
all code after get_tags_in_range is never executed and the block is
never scheduled again. (Without the 'get_tags_in_rage
18 matches
Mail list logo
