Re: [Discuss-gnuradio] gr-ieee 802.11 and commercial AP (late ACK packets)

2017-04-03 Thread sumitstop
Hello Bastian, Yes I used PCIe(X300). I measured two things. One "rtt" with latency_test.cpp which gave 80 microsecs and another receiver latency where I set the GPIO HIGH as soon as the receive power exceeds a threshold. I made a custom C++ script for this. This gave 52 microsecs. Regards

Re: [Discuss-gnuradio] gr-ieee 802.11 and commercial AP (late ACK packets)

2017-04-03 Thread Bastian Bloessl
Hi, On 04/03/2017 09:44 PM, sumitstop wrote: > Hello Bastian, > > How much the delay between sensing the channel and sending the ACK should > be. With X300 I was able to achieve a minm of 80 microsecs round trip time. > Not less than that. Interesting. What exactly did you measure? I assume

Re: [Discuss-gnuradio] gr-ieee 802.11 and commercial AP (late ACK packets)

2017-04-03 Thread sumitstop
Hello Bastian, How much the delay between sensing the channel and sending the ACK should be. With X300 I was able to achieve a minm of 80 microsecs round trip time. Not less than that. I am now sure that it cant be done on GPP, just wondering how fast it should be. If you can direct me to some

Re: [Discuss-gnuradio] FG probe generation of thread.start() race conditions (python tutorials)

2017-04-03 Thread Martin Braun
James, thanks for pointing that out! On 03/29/2017 10:22 AM, James Shimer wrote: > Sorry if this is a duplicate/newbie question (didn't find anything > searching). When going thru the python examples. I came across a race > condition where the thread would start to run prior to object's >

Re: [Discuss-gnuradio] OS X Fuzzy Text in GRC

2017-04-03 Thread Dave NotTelling
Michael helped me out yesterday, but the fuzziness didn't go away by changing the Python info.plist file per https://trac.macports.org/ticket/36410. I'm just going to accept it as a slightly annoying 'feature' since it's not something that kills functionality. If anyone has success in making the

Re: [Discuss-gnuradio] gr-trellis test_cpm.py question

2017-04-03 Thread Andy Walls
Ah, OK. Thank you. I don't need anything that adaptive or automatic myself. I plan to play around with viterbi demodulation of GMSK and maybe SOQPSK this week. As I dig into the gr-trellis implementation I may have more questions. Regards, Andy On Mon, 2017-04-03 at 08:50 -0400, Achilleas

Re: [Discuss-gnuradio] gr-trellis test_cpm.py question

2017-04-03 Thread Achilleas Anastasopoulos
Here is what needs to be done (simple). N is the dimensionality of the signal space (found earlier in the code). Now we need to set up a filter bank to project the incoming signal to all its dimensions. These filters are held on the MF[] array. Now (due to laziness) i didn't write a for loop that

Re: [Discuss-gnuradio] log4cpp library not found

2017-04-03 Thread Marcus Müller
I really do believe it's something about GNU Radio's build system and your system not harmonizing very well, and we won't learn much about that, no matter whether something else builds or not. In any case, I'm a bit worried that on a fresh Suse system, ldconfig should be broken already, so

Re: [Discuss-gnuradio] log4cpp library not found

2017-04-03 Thread lists
Only /home was saved , but there was no code there. I kind of wished I had mirrored /usr/local because it was a lot of work to build some of the code again, but that wouldn't be a clean installation.   How is this for an idea? Log4cpp isn't unique to gnuradio. I will dig around for some

Re: [Discuss-gnuradio] log4cpp library not found

2017-04-03 Thread Marcus Müller
You said you didn't mirror /usr/local, does that imply you copied over other things? Best regards, Marcus On 03.04.2017 12:32, li...@lazygranch.com wrote: > Funny thing you mention a clean installation. I found btrfs to be a disaster > on opensuse. It turns out on some machines this is a known

Re: [Discuss-gnuradio] log4cpp library not found

2017-04-03 Thread lists
Funny thing you mention a clean installation. I found btrfs to be a disaster on opensuse. It turns out on some machines this is a known problem. It turned out the snapshots provided by btrfs were worthless, and it would lock up my machine. So I did a fresh install of opensuse on ext4 for the OS

Re: [Discuss-gnuradio] log4cpp library not found

2017-04-03 Thread Marcus Müller
No, you probably shouldn't fiddle manually. You should rather figure out what went wrong there. I'm getting the slight feeling that your system might be pretty special; can you try this whole dance on a clean Suse installation? Not quite sure we're not chasing ghosts here, due to something else on

Re: [Discuss-gnuradio] log4cpp library not found

2017-04-03 Thread lists
Yes to the dev install.  I'm not exactly sure what I can do about ldconfig.  Apologies in advance for an advert laden website link, but should I add /usr/local/lib64 as shown below: https://codeyarns.com/2014/01/14/how-to-add-library-directory-to-ldconfig-cache/ The odd thing is log4cpp is the

Re: [Discuss-gnuradio] log4cpp library not found

2017-04-03 Thread Marcus Müller
Hi, Ok, there's something wrong with your ldconfig. Since we're actively talking about linkage of stuff, you would probably do good if you fixed that. Anyway, did you also install log4cpp-devel? Best regards, Marcus On 03.04.2017 08:12, li...@lazygranch.com wrote: > sudo yum search all log4cpp

Re: [Discuss-gnuradio] File sink Recording Issue

2017-04-03 Thread Kyeong Su Shin
Hello Jahnavendra Mattipa: Unfortunately, I am having a trouble opening your GRC file. If you are reading it from GNU Radio, you can simply use a file source. If you are using Matlab/Octave, you can do something like this: read = fread(fopen('sam.dat'),2048,'single'); IQ = read(1:2:end) +

Re: [Discuss-gnuradio] log4cpp library not found

2017-04-03 Thread li...@lazygranch.com
sudo yum search all log4cpp == Matched: log4cpp == log4cpp-devel.x86_64 : Development tools for Log for C++ liblog4cpp5.x86_64 : Logging for C++ ldconfig -v | grep liblog4cpp ldconfig: Can't stat /usr/lib64/graphviz/sharp: No such