This topic of hardware efficient designs vs general purpose processor (GPP)
efficient is very interesting. I assumed the most efficient hardware designs
would tend to translate well into a GPP, because most good hardware designs are
good because they parallelize things like crazy. You would thin
Hi Jeon,
> In the figure above, I've marked a timing difference between them with
> arrows.
that's only natural. There's filtering involved, hence you get a delay.
> Although I adjust a timing difference between them, a waveform after
> the resampler seems ugly.
I still beg to differ :) It looks li
Thanks you Tom and Marcus.
Yes, well... I meant that I've also checked FFT but a picture of it was in
another PC so I couldn't attach it when I was writing the previous post.
Sorry about that. And I am currently using N210.
Today, carrying on from the yesterday, I've replaced a square wave signal
> 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 performa
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:
http://gnuradio.4.n7.nab
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 5
On Jul 24, 2015, at 14:47, Anderson, Douglas J.
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 block into a "Decimat
On Fri, Jul 24, 2015 at 3:24 PM, Martin Braun
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 one
> > [...]
>
> T
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 w
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 t
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
[discuss-gnuradio-bounces+danderson=its.bldrdoc...
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
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 t
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.4
On Fri, Jul 24, 2015 at 11:44 AM, Johannes Demel
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 8bit packing an
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 activ
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 plan
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) t
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 t
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 = 100MHz
On Fri, Jul 24, 2015 at 8:23 AM, Jeon 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 of all, I've tested a
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, 400k
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 a
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 differen
24 matches
Mail list logo
