Hi,
Am 2015-07-23 18:16, schrieb Bastian Bloessl:
you don't need the import blocks.
I already thought so, I added the import just to be sure it does not
see that it
needs to import the package for some reason.
The rest is pretty strange. First I thought that you PYTHONPATH in
GRC is
Hi,
Am 2015-07-24 10:53, schrieb Bernhard Dick:
Is a script generated? If so, did you try to execute it from the
command line?
I cannot build the grc due to the errors inside the diagram.
Just a short update on this. By using the hotkey (F5) to build the
diagram it did
build and now I'm also
On Fri, Jul 24, 2015 at 11:44 AM, Johannes Demel uf...@student.kit.edu
wrote:
Hey community,
after last weeks success with channel construction, this week is
calmer. It involves a steep learning curve for SIMD.
So I was able to create my first VOLK kernels [3]. There are two new
kernels for
Dennis,
This is great. I'd like to see how to get some of this wrapped back as a
patch for GNU Radio. However, a few things. We can't (yet) support C++11
standards. In 3.7, we allow older versions of compilers and dependencies
that don't have to support that, so neither can we enforce it. I'm
On 24.07.2015 10:58, Jason Matusiak wrote:
I am not sure what I am reading here. Is this just saying that it
cannot decode the packet properly? Or is there some sort of error in my
setup that I am missing?
That's it -- the detection is working, but the demod is not.
Currently I have 2.4GHz
Hi,
On 07/24/2015 12:05 PM, Bernhard Dick wrote:
Hi,
Am 2015-07-24 10:53, schrieb Bernhard Dick:
Is a script generated? If so, did you try to execute it from the
command line?
I cannot build the grc due to the errors inside the diagram.
Just a short update on this. By using the hotkey (F5)
Hey community,
after last weeks success with channel construction, this week is
calmer. It involves a steep learning curve for SIMD.
So I was able to create my first VOLK kernels [3]. There are two new
kernels for 8bit packing and unpacking. In case someone wants to pack
8 bytes with the LSB
Hi all,
I'm taking a read through Kristian Maier's thesis document on the gr-lte repo
(and by read I mean looking at the pictures because I don't know German).
Looks like he was piping his Coarse PSS Sync block into a Decimating FIR
Filter block, but I can't seem to find that (I don't use GRC
Hi everyone,
After spending a lot of time trying to make a packet based radio for bit
error rate testing, making a lot of posts about it on the mailing list, and
ultimately not succeeding, I wanted to share some of the things I've
learned. While the radio worked over the air for short periods of
On Fri, Jul 24, 2015 at 3:24 PM, Martin Braun martin.br...@ettus.com
wrote:
I hope this is useful information for people starting up on something
like this. Though I failed with the packet based approach, I was able to
make a streaming based approach work. I detect the start of a stream
On Jul 24, 2015, at 14:47, Anderson, Douglas J. dander...@its.bldrdoc.gov
wrote:
Hi all,
I'm taking a read through Kristian Maier's thesis document on the gr-lte repo
(and by read I mean looking at the pictures because I don't know German).
Looks like he was piping his Coarse PSS Sync
Thanks Kevin, I did try to fft_filter and it's working great.
I should have thought to grep through the grc source. Thanks...
-Doug
From: Kevin Reid [kpreid.switchb@gmail.com] on behalf of Kevin Reid
[kpr...@switchb.org]
Sent: Friday, July 24, 2015
Richard,
thanks for the summary. Much appreciated. Some comments:
On 24.07.2015 15:03, Richard Bell wrote:
3) The correlation estimator block will double tag peaks from time to
time. This is due to block boundaries that are imposed by the GNU Radio
scheduler. If a peak happens to coincide
Hi Jeon,
what USRP are you using?
You're right: The point is that only integer factor of the USRP's master
clock rate can be used.
So for example, if you're using the USRP2 or N210, the master clock rate
would be fixed at 100MHz.
That would explain the rates you're seeing. (3.703..MS/s =
Release v1.0.2 (This is a very small release). Release notes are available
on http://libvolk.org/news_raw/ and in the commit notes of the v1.0.2 tag
via git.
This is a relatively minor maintenance release with bug fixes since v1.0.1.
Contributors
===
The following have contributed code
On Fri, 2015-07-24 at 10:51 -0400, Tom Rondeau wrote:
Dennis,
This is great. I'd like to see how to get some of this wrapped back as
a patch for GNU Radio. However, a few things. We can't (yet) support C
++11 standards. In 3.7, we allow older versions of compilers and
dependencies that
I should mentioned that I am referring to page 30 and 31 in this pdf.
https://github.com/kit-cel/gr-lte/blob/master/LTE_Thesis_Kristian_Maier.pdf
From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org
If you can put together a patch that gives us a bit of a boost here,
that'd be great. But as you say, it doesn't look like this algorithm
as it is will ever be fantastically fast. It was definitely meant more
for hardware than this case.
My first attempt at integration sees a performance
On Fri, Jul 24, 2015 at 8:23 AM, Jeon sjeon87+gnura...@gmail.com wrote:
I am building a certain system whose clock rates can be 200k, 400k, 3.75M,
7.5M, 15M, 30M, 60M and 120 MHz.(It's not an RF communication system, but a
wired communication system using a square wave on-off keying.)
First
Anybody know what happended to http://op25.osmocom.org/ ? It's down and so
is the repository at git://op25.osmocom.org/op25.git Looks to have been
down for at least 3 weeks. Is there a backup of the repository somewhere?
Thanks,
Lou
--
View this message in context:
I am building a certain system whose clock rates can be 200k, 400k, 3.75M,
7.5M, 15M, 30M, 60M and 120 MHz.(It's not an RF communication system, but a
wired communication system using a square wave on-off keying.)
First of all, I've tested a USRP with only available rates for USRP (i.e.
200k,
21 matches
Mail list logo
