[Discuss-gnuradio] pybombs error
Hello guys,
I still trying to install GNURadio on debian 7.6 i86, but there is a
problem with installing 'pyqwt5' package with pybombs! The following error
is appeared:
packages to install: ['pyqwt5', 'mcpp', 'db48', 'ice', 'gnuradio']
install called (pyqwt5)
install type priority: ['deb', 'src']
install deb called (pyqwt5)
deb is not available locally
check remote repositories...
install src called (pyqwt5)
state = configure
Current step: (pyqwt5 :: make)
make
('\nmake -j4\n', '\nmake -j$makewidth\n')
('\nmake -j4\n', '\nmake -j4\n')
bash exec (/home/alizadeh/gnuradio_src/pybombs/src/pyqwt5/configure)::
make -j4
make: *** No targets specified and no makefile found. Stop.
ERROR:root:PyBOMBS Make step failed for package (pyqwt5) please see bash
output above for a reason (hint: look for the word Error)
What I should do? Please help me :(
Best,
Mostafa
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
John, I use the BE FLL for auto-doppler correction in the rare case where I am not actively correcting for doppler. But, the correction is *really* slow. I'm probably not using it correctly, but it works OK in that rare case when it's all I've got. Very Respectfully, Dan CaJacob On Fri, Oct 17, 2014 at 2:28 AM, John Malsbury jmalsbury.perso...@gmail.com wrote: Luke, I researched this for a bit (OK, maybe it was more like staring blankly)... unfortunately on a windows machine w/out git. Nothing stands out at the momentt. I'll give it another try tomorrow! =) Also, I've never used the PLL blocks for freq demod before. Can you set something up with a graphical sink and send some snapshots showing what the output of that looks like? Also also, is the Band-Edge FLL ideal for GMSK? My possibly, incorrect understanding of that block is that it was more ideal for PAM with common RRC. -John On Thu, Oct 16, 2014 at 7:19 AM, Luke Berndt l...@robotastic.com wrote: I just tried doing a complete PyBombs reinstall and that didn't seem the help. I checked and simple GRC files run fine. I can also see the signal where I expect it to be in GQRX, so I think my tuning parameters are correct. Are there some other things I should try? Sent from my iPhone On Oct 13, 2014, at 1:38 PM, Luke Berndt l...@robotastic.com wrote: I have a GnuRadio C++ program that decodes and records a SmartNet Trunked radio system. It is running great under GnuRadio 3.6.5.1, but it doesn’t seem to be working under 3.7.6. 3.6 is installed in /usr/local and 3.7.6 was installed in my home directory using PyBombs. My updated program compiles against 3.7 with no problem and runs. It will pick up a few of the trunking commands, so it is working, but the ratios is about 1 to 100 compared to 3.6. I also tried running it in a Ubuntu VM with 3.7 installed at /usr/local and had the same results. I corrected for the change with XlatingFirFilter in 3.7, so it is the opposite offset of 3.6. It looks like it could be a tuning error though, the flow graph seems to be failing mostly at the CRC check. Did anything else change with Blocks in 3.7? I looked at gr-osmosdr but I didn’t notice huge discrepancies between the 3.6 and 3.7 branches. Are there some obvious things I could be missing? I feel like this is something small and stupid that I missing. The diff between the two versions is here, smartness.cc is the main file that decodes the control channel. As you can see, there is not that much different: https://github.com/robotastic/smartnet-recorder/compare/master...3.7-Update#diff-73510702485a7dd2f7000285cbd5e557R40 Here is the central code block that does it. Anything obviously dumb here? * float samples_per_second = samp_rate;* * float syms_per_sec = 3600;* * float gain_mu = 0.01;* * float mu=0.5;* * float omega_relative_limit = 0.3;* * float offset = chan_freq - center_freq; // have to reverse it for 3.7 because it swapped in the switch.* * float clockrec_oversample = 3;* * int decim = int(samples_per_second / (syms_per_sec * clockrec_oversample));* * float sps = samples_per_second/decim/syms_per_sec;* * const double pi = boost::math::constants::pidouble();* * cout Control channel offset: offset endl;* * cout Decim: decim endl;* * cout Samples per symbol: sps endl;* * std::vectorfloat lpf_taps;* * init_loggers(max_loggers, center_freq, samp_rate);* * gr::msg_queue::sptr queue = gr::msg_queue::make();* * lpf_taps = gr::filter::firdes::low_pass(1, samp_rate, 1, 12000);* * gr::filter::freq_xlating_fir_filter_ccf::sptr prefilter = gr::filter::freq_xlating_fir_filter_ccf::make(decim,* * lpf_taps,* * offset,* * samp_rate);* * gr::digital::fll_band_edge_cc::sptr carriertrack = gr::digital::fll_band_edge_cc::make(sps, 0.6, 64, 0.35);* * gr::analog::pll_freqdet_cf::sptr pll_demod = gr::analog::pll_freqdet_cf::make(2.0 / clockrec_oversample, 2*pi/clockrec_oversample, -2*pi/clockrec_oversample);* * gr::digital::clock_recovery_mm_ff::sptr softbits = gr::digital::clock_recovery_mm_ff::make(sps, 0.25 * gain_mu * gain_mu, mu, gain_mu, omega_relative_limit);* * gr::digital::binary_slicer_fb::sptr slicer = gr::digital::binary_slicer_fb::make();* * gr::digital::correlate_access_code_tag_bb::sptr start_correlator = gr::digital::correlate_access_code_tag_bb::make(10101100,0,smartnet_preamble);* * smartnet_deinterleave_sptr deinterleave = smartnet_make_deinterleave();* * smartnet_crc_sptr crc = smartnet_make_crc(queue);* * tb-connect(src,0,prefilter,0);* * tb-connect(prefilter,0,carriertrack,0);* * tb-connect(carriertrack, 0, pll_demod, 0);* * tb-connect(pll_demod, 0, softbits, 0);* * tb-connect(softbits, 0, slicer, 0);* * tb-connect(slicer, 0, start_correlator, 0);* * tb-connect(start_correlator, 0, deinterleave, 0);* * tb-connect(deinterleave, 0, crc, 0);* * tb-start();*
Re: [Discuss-gnuradio] Gettin data out from GRC to C++ or java?
So i if would like to create a simple flow graph, with USRP source and file sink only, is there any way to control file buffer size (i.e i want that any file consist of 3k 32complex samples every write)? Any 3.7 compatibile pipe pack? tried gr-pipe but typical gnuradio-core error :( -- View this message in context: http://gnuradio.4.n7.nabble.com/Gettin-data-out-from-GRC-to-C-or-java-tp50824p50875.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
On 10/17/2014 08:28 AM, John Malsbury wrote: Also also, is the Band-Edge FLL ideal for GMSK? My possibly, incorrect understanding of that block is that it was more ideal for PAM with common RRC. For the record: It might work coincidentally because of the rolloff-y shape of GMSK, but it's derived for and designed for common PAM/RRC, as John says and I wouldn't recommend it for anything else. To look up the math, I suggest Harris' works. Cheers, M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] TX/RX with USRPN200 and GNURadio
Hello, I want to transmit and receive at the same time with WBX board and USRPN200. I have this flowgraph. I connected the input and output with a RF cable (a loop). Is it possible? Is there any problem? Thank you. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TX/RX with USRPN200 and GNURadio
Make sure you put an attenuator before going back into the N200 so that you do not damage the RF input. Ruben From: discuss-gnuradio-bounces+ruben.merz=swisscom@gnu.org [mailto:discuss-gnuradio-bounces+ruben.merz=swisscom@gnu.org] On Behalf Of Carlos Alberto Ruiz Naranjo Sent: Friday, October 17, 2014 3:35 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] TX/RX with USRPN200 and GNURadio [cid:image001.png@01CFEA20.8ED2B3A0] Hello, I want to transmit and receive at the same time with WBX board and USRPN200. I have this flowgraph. I connected the input and output with a RF cable (a loop). Is it possible? Is there any problem? Thank you. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
It doesn't have frequency correction - I can probably follow up with some ideas on how to implement that part. But the GMSK demod might do OK for you initially. It doesn't do anything intelligent to deal with the data shaping - its just a non-coherent slicer. If you want to design in GRC but keep your top-level application as is, you can use a hier block. You can also use a command line parameter or other mechanism to select your demodulator at start-time for easy comparisons. [typed one handed.. my daughter has my other and] -John On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt l...@robotastic.com wrote: Thanks for looking into it! To be honest, I am not really good at RF. I based my code off the python code in gr-smartnet. The fsk-demod python file is here: https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py It is quite possible that it just happened to work because of an error that got patched in Gr 3.7. Are there some good examples for GMSK/FSK demodulation that I could borrow from instead? Recreating this in GRC sounds like a great idea so I can scope along the way. I will give that a try next. Thanks again for the pointers, fresh eyes are really helpful when you have been staring at it for so long. - Luke On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun martin.br...@ettus.com wrote: On 10/17/2014 08:28 AM, John Malsbury wrote: Also also, is the Band-Edge FLL ideal for GMSK? My possibly, incorrect understanding of that block is that it was more ideal for PAM with common RRC. For the record: It might work coincidentally because of the rolloff-y shape of GMSK, but it's derived for and designed for common PAM/RRC, as John says and I wouldn't recommend it for anything else. To look up the math, I suggest Harris' works. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
Also, my understanding for the PLL blocks were that they were ideal for strong carrier signals like AM. When I say strong carrier i mean a signal that has an obvious carrier which isn't hidden under modulation.. Anyway, the GMSK block might be a good place to start. -John On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury jmalsbury.perso...@gmail.com wrote: It doesn't have frequency correction - I can probably follow up with some ideas on how to implement that part. But the GMSK demod might do OK for you initially. It doesn't do anything intelligent to deal with the data shaping - its just a non-coherent slicer. If you want to design in GRC but keep your top-level application as is, you can use a hier block. You can also use a command line parameter or other mechanism to select your demodulator at start-time for easy comparisons. [typed one handed.. my daughter has my other and] -John On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt l...@robotastic.com wrote: Thanks for looking into it! To be honest, I am not really good at RF. I based my code off the python code in gr-smartnet. The fsk-demod python file is here: https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py It is quite possible that it just happened to work because of an error that got patched in Gr 3.7. Are there some good examples for GMSK/FSK demodulation that I could borrow from instead? Recreating this in GRC sounds like a great idea so I can scope along the way. I will give that a try next. Thanks again for the pointers, fresh eyes are really helpful when you have been staring at it for so long. - Luke On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun martin.br...@ettus.com wrote: On 10/17/2014 08:28 AM, John Malsbury wrote: Also also, is the Band-Edge FLL ideal for GMSK? My possibly, incorrect understanding of that block is that it was more ideal for PAM with common RRC. For the record: It might work coincidentally because of the rolloff-y shape of GMSK, but it's derived for and designed for common PAM/RRC, as John says and I wouldn't recommend it for anything else. To look up the math, I suggest Harris' works. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gettin data out from GRC to C++ or java?
Ernest - here's an example of how to connect other stuff to GNU Radio via pipes - granted at much lower sample rates. Higher sample rates shouldn't effect the pipe, but Matlab may not keep up with a typical 802.11 sample rate. http://youtu.be/GBmli8Vflig?t=2m33s If you *could* get this 3k sample snapshot, how do you make sure a useful signal will be present? If you're doing processing in another framework, why don't you just use UHD directly w/out GNU Radio? There are finite acquisition calls in UHD IIRC... -John On Fri, Oct 17, 2014 at 5:15 AM, Martin Braun martin.br...@ettus.com wrote: On 10/17/2014 12:40 PM, Ernest Szczepaniak wrote: So i if would like to create a simple flow graph, with USRP source and file sink only, is there any way to control file buffer size (i.e i want that any file consist of 3k 32complex samples every write)? You can't control how many samples the USRP source will produce per run. And I'm not sure that's really what you want. Any 3.7 compatibile pipe pack? tried gr-pipe but typical gnuradio-core error :( I was suggesting you create a named pipe instead of a regular file. If you don't know what that means, I suggest looking it up, it's a basic concept of most OSes, and Google will have all the info you need. You don't need any addons for that. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help accessing fft bins in python script
This sounds interesting - do you have any sample code? Can anybody explain the concept of size of an fft (Arg 1 of fft . fft_vcc ) comes into play if the output of that FFT generates as many samples as it receives? - Original Message - From: John Malsbury jmalsbury.perso...@gmail.com To: Brad Hein k1...@comcast.net Cc: Martin Braun martin.br...@ettus.com, discuss-gnuradio@gnu.org Sent: Friday, October 17, 2014 1:50:31 AM Subject: Re: [Discuss-gnuradio] help accessing fft bins in python script Sometimes when I want to grab samples and perform some periodic operation like CNR estimation, or fine-frequency estimation I sometimes use a vector_sink, and then two function probe blocks - one to read the data and one to reset it (yes I call the reset function from the function probe). This seems to work wonderfully for certain corner cases where a vector sink doesn't work well. And I mostly use this technique when I want to prototyping something quickly before writing a block. But am I asking for trouble with memory allocation issues??? Also, I was thinking, it would be good to have the option, either a block parameter or an overloaded function) to reset the vector_sink, each time .data() is called... I can code this up unless anyone thinks this functionality would lead to regressions. But I agree the vector sink block is much more convenient for FFTs... -John On Thu, Oct 16, 2014 at 5:37 PM, Brad Hein k1...@comcast.net wrote: Is there any way to access the fft bins from python without writing a custom block? From: Martin Braun martin.br...@ettus.com To: discuss-gnuradio@gnu.org Sent: Thursday, October 16, 2014 2:02:03 PM Subject: Re: [Discuss-gnuradio] help accessing fft bins in python script A very simple way would just be to write your block downstream of the FFT in Python. You can then operate on the vectors in the work function. M On 10/16/2014 07:44 PM, mle...@ripnet.com wrote: The vector sink is for debugging only. Don't use it in production code, because there's no convenient way to vacuum it out, so it grows without bound. When I've had this problem, I use a vector-probe block, and have a function probe running at a couple of Hz, and then leverage the dependency-tree evaluator to have my own function called with the result of the function probe. There are other ways, that's the one I personally find most convenient. But there are message queues and sundry other methods as well. On 2014-10-16 13:36, Brad Hein wrote: Using qa_fft.py for inspiration[1], I'm trying to feed a raw capture file into an fft of size 32 and then review the 32 fft bins at an instantaneous point in time[2]. I must be doing something wrong however because when I review the vector sink's data() method, it returns a rather large array (compared to the 32-element array I am expecting). data() seems to return an array with the same number of elements as samples fed into the fft. I just want an array of the 32 fft bins so I can calculate the relative power in the given band. Any help/pointers appreciated! Thanks [1] http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-fft/python/fft/qa_fft.py [2] https://github.com/regulatre/grfun/blob/9dbbf676d2fea013787720273af0b419699c75a4/hello-fft/decodeDump162.py [Brad Hein] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help accessing fft bins in python script
Again, if one uses the vector-probe block, one can call the appropriate function from a function-probe, at that point, you have a variable with the contents of the FFT output vector in it, which can be used in a call to your own Python code. On 2014-10-17 12:01, Brad Hein wrote: This sounds interesting - do you have any sample code? Can anybody explain the concept of size of an fft (Arg 1 of fft.fft_vcc) comes into play if the output of that FFT generates as many samples as it receives? - FROM: John Malsbury jmalsbury.perso...@gmail.com TO: Brad Hein k1...@comcast.net CC: Martin Braun martin.br...@ettus.com, discuss-gnuradio@gnu.org SENT: Friday, October 17, 2014 1:50:31 AM SUBJECT: Re: [Discuss-gnuradio] help accessing fft bins in python script Sometimes when I want to grab samples and perform some periodic operation like CNR estimation, or fine-frequency estimation I sometimes use a vector_sink, and then two function probe blocks - one to read the data and one to reset it (yes I call the reset function from the function probe). This seems to work wonderfully for certain corner cases where a vector sink doesn't work well. And I mostly use this technique when I want to prototyping something quickly before writing a block. But am I asking for trouble with memory allocation issues??? ALSO, I WAS THINKING, IT WOULD BE GOOD TO HAVE THE OPTION, EITHER A BLOCK PARAMETER OR AN OVERLOADED FUNCTION) TO RESET THE VECTOR_SINK, EACH TIME .DATA() IS CALLED... I CAN CODE THIS UP UNLESS ANYONE THINKS THIS FUNCTIONALITY WOULD LEAD TO REGRESSIONS. But I agree the vector sink block is much more convenient for FFTs... -John On Thu, Oct 16, 2014 at 5:37 PM, Brad Hein k1...@comcast.net wrote: Is there any way to access the fft bins from python without writing a custom block? - FROM: Martin Braun martin.br...@ettus.com TO: discuss-gnuradio@gnu.org SENT: Thursday, October 16, 2014 2:02:03 PM SUBJECT: Re: [Discuss-gnuradio] help accessing fft bins in python script A very simple way would just be to write your block downstream of the FFT in Python. You can then operate on the vectors in the work function. M On 10/16/2014 07:44 PM, mle...@ripnet.com wrote: The vector sink is for debugging only. Don't use it in production code, because there's no convenient way to vacuum it out, so it grows without bound. When I've had this problem, I use a vector-probe block, and have a function probe running at a couple of Hz, and then leverage the dependency-tree evaluator to have my own function called with the result of the function probe. There are other ways, that's the one I personally find most convenient. But there are message queues and sundry other methods as well. On 2014-10-16 13:36, Brad Hein wrote: Using qa_fft.py for inspiration[1], I'm trying to feed a raw capture file into an fft of size 32 and then review the 32 fft bins at an instantaneous point in time[2]. I must be doing something wrong however because when I review the vector sink's data() method, it returns a rather large array (compared to the 32-element array I am expecting). data() seems to return an array with the same number of elements as samples fed into the fft. I just want an array of the 32 fft bins so I can calculate the relative power in the given band. Any help/pointers appreciated! Thanks [1] http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-fft/python/fft/qa_fft.py [1] [2] https://github.com/regulatre/grfun/blob/9dbbf676d2fea013787720273af0b419699c75a4/hello-fft/decodeDump162.py [2] [Brad Hein] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3] Links: -- [1] http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-fft/python/fft/qa_fft.py [2] https://github.com/regulatre/grfun/blob/9dbbf676d2fea013787720273af0b419699c75a4/hello-fft/decodeDump162.py [3] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___
Re: [Discuss-gnuradio] pybombs error
I'm not sure what's wrong here, but it should be trying to install a
deb called python-qwt5-qt4, not pyqwt5. Perhaps run an apt-get update
and try again. The optimal solution is to find out if this is a bug in
pybombs or your setup and send a patch if it applies to others.
Otherwise you can get around this by installing python-qwt5-qt4
yourself and then use pybombs config to tell pybombs you already have
pyqwt5 installed.
On Fri, Oct 17, 2014 at 1:37 AM, Mostafa Alizadeh
m.alizade...@gmail.com wrote:
Hello guys,
I still trying to install GNURadio on debian 7.6 i86, but there is a problem
with installing 'pyqwt5' package with pybombs! The following error is
appeared:
packages to install: ['pyqwt5', 'mcpp', 'db48', 'ice', 'gnuradio']
install called (pyqwt5)
install type priority: ['deb', 'src']
install deb called (pyqwt5)
deb is not available locally
check remote repositories...
install src called (pyqwt5)
state = configure
Current step: (pyqwt5 :: make)
make
('\nmake -j4\n', '\nmake -j$makewidth\n')
('\nmake -j4\n', '\nmake -j4\n')
bash exec (/home/alizadeh/gnuradio_src/pybombs/src/pyqwt5/configure)::
make -j4
make: *** No targets specified and no makefile found. Stop.
ERROR:root:PyBOMBS Make step failed for package (pyqwt5) please see bash
output above for a reason (hint: look for the word Error)
What I should do? Please help me :(
Best,
Mostafa
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1
So... there were actually several contributors to this long latency. Some of it was related to GNU Radio's inner workings, some were external. With all of the external things removed, there was still 1+ minute of latency at low bitrates. I thought I would share my findings, for the sake of getting this experience publicly archived. (and maybe someone can build on these insights?) First, a little background on the application. The use case-here is that there is some moderately complex that isn't data-specific per-se. But the quality of the demodulated data is evaluated on a periodic basis to determine alignment through multiple, parallel FEC decoding chains. After alignment is detected, an appropriate chain is selected, and downstream delays are adjusted. Here are specific things that were observed: 1. We gave up on the stock selector block early on. It was misaligning samples, which effected a down-stream interleaving process. What are the general thoughts/feelings on how the selector block is currently implmeneted. 2. We tried several clever (ha) methods to select the desired stream. Most of them revolved around the concept of summering/xoring streams after multiplying or and'ing the streams according to which stream we wanted (operand = 1 if we wanted the stream, 0 if not). Through various methods we found that anything with a constant source, and const, etc, create this very long latencies. The behavior was this: After the streams were selected and the long latency expired the data would be valid, and latency would be quite good for such a low data rate. This seemed to indicate that somehting in the blocks used to select the stream was causing a delay - ie. inserting a lot of samples with the previous evaluated results where things would be misaligned. Either that, or the callbacks to set the new operands for stream selection were not executing right away. The specific offenders seem to be 1) constant source 2) and constant 3) mult_const. I haven't figured out why yet... The end solution was to do a dumb selector block that just copied the specified input to the output. Derp... -John On Fri, Oct 10, 2014 at 7:09 PM, John Malsbury jmalsbury.perso...@gmail.com wrote: Is there something i can force on a per block basis in 3.6? Is there some trickery in the forecast function I might use? On Oct 10, 2014 6:40 PM, Ed Criscuolo edward.l.criscu...@nasa.gov wrote: On 10/10/14 9:15 PM, John Malsbury wrote: Sounds dangerous if you also happen to have very high throughput applications to run? Am I wrong? Yes, it was a fine line between getting it small enough for acceptable latency while still maintaining enough throughput to not overrun. Fortunately for our application we were able to strike that balance. Your mileage may vary. @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help accessing fft bins in python script
k1gto wrote Is there any way to access the fft bins from python without writing a custom block? See this: http://ha5kfu.sch.bme.hu/fft_test Lou KD4HSO -- View this message in context: http://gnuradio.4.n7.nabble.com/help-accessing-fft-bins-in-python-script-tp50854p50891.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1
We see this issue a lot with applications that only transmit, and which transmit continuously. The problem is that you end up generating samples far in advance of when you really know what you want to transmit, because there is no rate-limiting on the production side. Some general principles -- Large buffers *allow* you to deal with high latency. Large buffers do not *create* high latency unless the application is not designed properly. A properly designed application will work with infinitely large buffers as well as it does with minimally sized ones. Shrinking buffers may allow your application to work, but that isn't really the best way to solve this problem. The best way to solve the problem is to modify your head-end source block to understand wall-clock time. The easiest way to do that if you are using a USRP is to instantiate a UHD source (i.e. a receiver) at a relatively low sample rate and feed it into the source you have created. Your source block should then look at timestamps on the incoming samples (it can throw the samples themselves away). It should generate only enough samples to cover the maximum latency you want, and it should timestamp those transmit samples. For example, if it receives samples timestamped with T1, it should generate samples with timestamps from T1+L1 to T1+L1+L2, where L1 is the worst-case flowgraph and device latency, and L2 is the worst case reaction time you are looking for. Thus, if you suddenly get a message from your operator to send a message, you know that you will never need to wait for more than L2 seconds. Thus, you can bound your worst case reaction time. It should be noted that in two-way application like GSM or LTE, you would never run into these problems and they are naturally avoided because you won't generate samples until you've seen what you receive. It only is an issue in TX-only apps. I think we should generate an example app to do this, because the issue comes up periodically, especially among the space communications crowd. It is a design pattern we really should document. Matt On Fri, Oct 10, 2014 at 5:20 PM, Vanush Vaswani van...@gmail.com wrote: I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in flat_flowgraph.cc. This is regarded as a dodgy hack by all the GR developers here, but it worked for me (and I read the article on latency). I believe the guy who wrote GMSKSpacecraftGroundstation had the same problem, and found it in one of his old threads. On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob dan.caja...@gmail.com wrote: Hey John, I am way out of my depth here, but while working on a custom python block the other day, I saw some weird behavior in 3.7.5 that was similar. Setting the global max output had no effect, but setting the just-upstream block(s) min/max output buffer size(s) low fixed my apparent slowliness. Very Respectfully, Dan CaJacob On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury jmalsbury.perso...@gmail.com wrote: Default scheduler. tb.start(1024), with different values, etc, etc. Most of the downstream blocks are stock GNU Radio blocks - a delay block (max delay is 1 sample), logical operators, etc. I guess I'll add some printf debugging? -John On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller marcus.muel...@ettus.com wrote: Hi John, On 10.10.2014 19:33, John Malsbury wrote: Toward the end of the receive chain, there are a multitude of blocks that are used for Viterbi node synchronization. I've found that the number of blocks in series (3-5), combined with the low datarates at this point in the flowgraph, lead to latencies on the order of 1-2 minutes. That is to say, once the node synchronization is accomplished, it takes 1-2 minutes to flush these blocks and get the fresh, good data through. This is measured with function probes on the state of the sync process, and BERT analysis of the demodulator output [through TCP/IP socket]. I see you found the hidden interplanetary signal delay simulator. Congrats! Watch out for the red shift in downstream samples. No, seriously, that sounds like a lot. You are using 3.6.4.1 with the default scheduler, tpb? - I've tried messing around with the output buffer size option in the flowgraph, but this seems l to have a negligible impact. That surprises me. How did you mess around? top_block-run(1024)? Do your blocks really get called with smaller input item sizes? (do a little printf-debugging) - I can write some custom blocks to reduce the overall block count, but I have demonstrated that this provides a linear improvement, rather than the two-order-magnitude improvement I need. Any general advice anyone can offer? It feels like the right solution is to force small buffer sizes on the relevant blocks... agreed. But
Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1
Matt, BTW - in this particular case, this was *all* in the receive direction - its a lowrate demodulator. So I was a bit surprised to see the issue at all - 'cause I've never seen such high latency on a receive flowgraph. We have a closed loop approach to managing transmit latency through the USRP without timestamps or relying on a source stream for throttling. But I do think the advice you provide is useful for other's who are trying to solve *transmitter latency by shrinking buffers.* Per the email above - it turned out that buffer sizes were not an issue. Something else was weird was happening - see (2) on my prev email if you're interested. Thanks for following up on this thread. -John On Fri, Oct 17, 2014 at 10:16 AM, Matt Ettus m...@ettus.com wrote: We see this issue a lot with applications that only transmit, and which transmit continuously. The problem is that you end up generating samples far in advance of when you really know what you want to transmit, because there is no rate-limiting on the production side. Some general principles -- Large buffers *allow* you to deal with high latency. Large buffers do not *create* high latency unless the application is not designed properly. A properly designed application will work with infinitely large buffers as well as it does with minimally sized ones. Shrinking buffers may allow your application to work, but that isn't really the best way to solve this problem. The best way to solve the problem is to modify your head-end source block to understand wall-clock time. The easiest way to do that if you are using a USRP is to instantiate a UHD source (i.e. a receiver) at a relatively low sample rate and feed it into the source you have created. Your source block should then look at timestamps on the incoming samples (it can throw the samples themselves away). It should generate only enough samples to cover the maximum latency you want, and it should timestamp those transmit samples. For example, if it receives samples timestamped with T1, it should generate samples with timestamps from T1+L1 to T1+L1+L2, where L1 is the worst-case flowgraph and device latency, and L2 is the worst case reaction time you are looking for. Thus, if you suddenly get a message from your operator to send a message, you know that you will never need to wait for more than L2 seconds. Thus, you can bound your worst case reaction time. It should be noted that in two-way application like GSM or LTE, you would never run into these problems and they are naturally avoided because you won't generate samples until you've seen what you receive. It only is an issue in TX-only apps. I think we should generate an example app to do this, because the issue comes up periodically, especially among the space communications crowd. It is a design pattern we really should document. Matt On Fri, Oct 10, 2014 at 5:20 PM, Vanush Vaswani van...@gmail.com wrote: I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in flat_flowgraph.cc. This is regarded as a dodgy hack by all the GR developers here, but it worked for me (and I read the article on latency). I believe the guy who wrote GMSKSpacecraftGroundstation had the same problem, and found it in one of his old threads. On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob dan.caja...@gmail.com wrote: Hey John, I am way out of my depth here, but while working on a custom python block the other day, I saw some weird behavior in 3.7.5 that was similar. Setting the global max output had no effect, but setting the just-upstream block(s) min/max output buffer size(s) low fixed my apparent slowliness. Very Respectfully, Dan CaJacob On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury jmalsbury.perso...@gmail.com wrote: Default scheduler. tb.start(1024), with different values, etc, etc. Most of the downstream blocks are stock GNU Radio blocks - a delay block (max delay is 1 sample), logical operators, etc. I guess I'll add some printf debugging? -John On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller marcus.muel...@ettus.com wrote: Hi John, On 10.10.2014 19:33, John Malsbury wrote: Toward the end of the receive chain, there are a multitude of blocks that are used for Viterbi node synchronization. I've found that the number of blocks in series (3-5), combined with the low datarates at this point in the flowgraph, lead to latencies on the order of 1-2 minutes. That is to say, once the node synchronization is accomplished, it takes 1-2 minutes to flush these blocks and get the fresh, good data through. This is measured with function probes on the state of the sync process, and BERT analysis of the demodulator output [through TCP/IP socket]. I see you found the hidden interplanetary signal delay simulator. Congrats! Watch out
Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1
Yes, there were multiple issues in the thread, and what I said only applies to TX. Certainly on the receive side there should be no latency issues, as every block should do all computations they can on whatever data they receive, since that is exactly what is tripping up the TX guys :) Matt On Fri, Oct 17, 2014 at 10:25 AM, John Malsbury jmalsbury.perso...@gmail.com wrote: Matt, BTW - in this particular case, this was *all* in the receive direction - its a lowrate demodulator. So I was a bit surprised to see the issue at all - 'cause I've never seen such high latency on a receive flowgraph. We have a closed loop approach to managing transmit latency through the USRP without timestamps or relying on a source stream for throttling. But I do think the advice you provide is useful for other's who are trying to solve *transmitter latency by shrinking buffers.* Per the email above - it turned out that buffer sizes were not an issue. Something else was weird was happening - see (2) on my prev email if you're interested. Thanks for following up on this thread. -John On Fri, Oct 17, 2014 at 10:16 AM, Matt Ettus m...@ettus.com wrote: We see this issue a lot with applications that only transmit, and which transmit continuously. The problem is that you end up generating samples far in advance of when you really know what you want to transmit, because there is no rate-limiting on the production side. Some general principles -- Large buffers *allow* you to deal with high latency. Large buffers do not *create* high latency unless the application is not designed properly. A properly designed application will work with infinitely large buffers as well as it does with minimally sized ones. Shrinking buffers may allow your application to work, but that isn't really the best way to solve this problem. The best way to solve the problem is to modify your head-end source block to understand wall-clock time. The easiest way to do that if you are using a USRP is to instantiate a UHD source (i.e. a receiver) at a relatively low sample rate and feed it into the source you have created. Your source block should then look at timestamps on the incoming samples (it can throw the samples themselves away). It should generate only enough samples to cover the maximum latency you want, and it should timestamp those transmit samples. For example, if it receives samples timestamped with T1, it should generate samples with timestamps from T1+L1 to T1+L1+L2, where L1 is the worst-case flowgraph and device latency, and L2 is the worst case reaction time you are looking for. Thus, if you suddenly get a message from your operator to send a message, you know that you will never need to wait for more than L2 seconds. Thus, you can bound your worst case reaction time. It should be noted that in two-way application like GSM or LTE, you would never run into these problems and they are naturally avoided because you won't generate samples until you've seen what you receive. It only is an issue in TX-only apps. I think we should generate an example app to do this, because the issue comes up periodically, especially among the space communications crowd. It is a design pattern we really should document. Matt On Fri, Oct 10, 2014 at 5:20 PM, Vanush Vaswani van...@gmail.com wrote: I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in flat_flowgraph.cc. This is regarded as a dodgy hack by all the GR developers here, but it worked for me (and I read the article on latency). I believe the guy who wrote GMSKSpacecraftGroundstation had the same problem, and found it in one of his old threads. On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob dan.caja...@gmail.com wrote: Hey John, I am way out of my depth here, but while working on a custom python block the other day, I saw some weird behavior in 3.7.5 that was similar. Setting the global max output had no effect, but setting the just-upstream block(s) min/max output buffer size(s) low fixed my apparent slowliness. Very Respectfully, Dan CaJacob On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury jmalsbury.perso...@gmail.com wrote: Default scheduler. tb.start(1024), with different values, etc, etc. Most of the downstream blocks are stock GNU Radio blocks - a delay block (max delay is 1 sample), logical operators, etc. I guess I'll add some printf debugging? -John On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller marcus.muel...@ettus.com wrote: Hi John, On 10.10.2014 19:33, John Malsbury wrote: Toward the end of the receive chain, there are a multitude of blocks that are used for Viterbi node synchronization. I've found that the number of blocks in series (3-5), combined with the low datarates at this point in the flowgraph, lead to latencies on the order of 1-2
[Discuss-gnuradio] NC-OFDM and Cross sub-carrier Interference
Hi, I'm currently developing a testbed for spectrum aggregation and fragmentation using GNURadio and USRPs (B200s and B210s). My approach is to emulate aggregation and fragmentation using Non-Contiguous OFDM: Theoretically, each node should be able to transmit in any subset of the sub-carriers available. Everything seems to be fine when tested in a loop back(the GRC OFDM Tx example in gr_digital was used). And connected to USRPs, a single pair transmission and reception is fine while transmitting in any subset of subcarriers. The problem arises when I have more than one node transmitting in the same OFDM configuration. No matter how wide the OFDM span is (I began from 64 and increased it to 1024), and no matter how far apart the two transmitting channels are, the cross-interference is enough to corrupt both transmissions. I have played with the transmission power of both transmitters to see if lowering it makes any difference, to no avail. I have also thought of applying a bandpass filter before feeding OFDM signals to USRPs to limit their out of band emissions, but as the system is supposed to handle fragmentation and requires complete spectrum agility, a single filter would not solve the problem. I would greatly appreciate any advice on the matter. Many Thanks, Vahid ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Source Block - Flow Control
You'll probably want to make a block to do the padding, or mux in zeros. Matt On Thu, Oct 16, 2014 at 3:00 PM, David Halls david.ha...@toshiba-trel.com wrote: Thanks Matt. is this likely to be the cause of the Us at the beginning? How can I pad simply in GNU radio? can i add padding to every burst? if so that seems straightforward. I can just mux some zeros in. Also should the padding be included in the burst length? Original message From: Matt Ettus Date:2014/10/16 22:54 (GMT+00:00) To: David Halls Cc: John Malsbury ,GNURadio Subject: Re: [Discuss-gnuradio] Source Block - Flow Control On TX, if you need your first sample to be valid and everything settled in the radio, you should zero pad ahead of it. If you need your last sample to go out clean, you should zero pad after it. In both cases, a few microseconds worth is usually fine. This flushes buffers and filters, but also gives physical devices like antenna switches to settle. Matt On Thu, Oct 16, 2014 at 2:46 PM, David Halls david.ha...@toshiba-trel.com wrote: Original message From: Matt Ettus Date:2014/10/16 22:42 (GMT+00:00) To: John Malsbury Cc: David Halls ,GNURadio Subject: Re: [Discuss-gnuradio] Source Block - Flow Control On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury jmalsbury.perso...@gmail.com wrote: I'm happy this is working for you, David. So do I understand correctly, that the adding tx_time finally made the MIMO case work? I'd never done burst transmission with multiple USRP outputs. I'm not totally surprised but I wasn't sure what would happen. Maybe someone from Ettus can comment on this? Since UHD is trying to do time alignment in the multi_usrp class, what happens to time alignemt in the non-continuous-streaming case if you *don't* include a tx_time tag? Noncontinuous streaming means there is some amount of down time. If you don't include tx_time tags, the device doesn't know when to start back up again, so each antenna is going to start at a different time. Matt That seemed exactly the kind of behaviour I saw where sync between the two streams was lost. Matt, can you comment on whether I need to put dummy padding items before the first burst? to flush buffers and is there a delicate way to do this? -- NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl -- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com -- -- NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl -- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
It actually looks like the control channel for Motorola SmartNet is FSK: On the control (data) channel the base station transmits 84 bits frames at 3600 bit/s with direct frequency modulation of the carrier using Frequency Shift Keying (FSK). I will at least see if I can get something that looks right out the other side. Would it be best to use one of the GFSK examples in gr-digital? On Fri, Oct 17, 2014 at 10:37 AM, John Malsbury jmalsbury.perso...@gmail.com wrote: Also, my understanding for the PLL blocks were that they were ideal for strong carrier signals like AM. When I say strong carrier i mean a signal that has an obvious carrier which isn't hidden under modulation.. Anyway, the GMSK block might be a good place to start. -John On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury jmalsbury.perso...@gmail.com wrote: It doesn't have frequency correction - I can probably follow up with some ideas on how to implement that part. But the GMSK demod might do OK for you initially. It doesn't do anything intelligent to deal with the data shaping - its just a non-coherent slicer. If you want to design in GRC but keep your top-level application as is, you can use a hier block. You can also use a command line parameter or other mechanism to select your demodulator at start-time for easy comparisons. [typed one handed.. my daughter has my other and] -John On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt l...@robotastic.com wrote: Thanks for looking into it! To be honest, I am not really good at RF. I based my code off the python code in gr-smartnet. The fsk-demod python file is here: https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py It is quite possible that it just happened to work because of an error that got patched in Gr 3.7. Are there some good examples for GMSK/FSK demodulation that I could borrow from instead? Recreating this in GRC sounds like a great idea so I can scope along the way. I will give that a try next. Thanks again for the pointers, fresh eyes are really helpful when you have been staring at it for so long. - Luke On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun martin.br...@ettus.com wrote: On 10/17/2014 08:28 AM, John Malsbury wrote: Also also, is the Band-Edge FLL ideal for GMSK? My possibly, incorrect understanding of that block is that it was more ideal for PAM with common RRC. For the record: It might work coincidentally because of the rolloff-y shape of GMSK, but it's derived for and designed for common PAM/RRC, as John says and I wouldn't recommend it for anything else. To look up the math, I suggest Harris' works. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
The good news is. the GFSK block doesn't do anything specific to Gaussian FSK. So I guess tha tall works out =) You're outputs might be more illustrative if you rebuild it in from the blocks actually inside the GFSK demod block: quad demod clock recovery - slicer On Fri, Oct 17, 2014 at 12:33 PM, Luke Berndt l...@robotastic.com wrote: It actually looks like the control channel for Motorola SmartNet is FSK: On the control (data) channel the base station transmits 84 bits frames at 3600 bit/s with direct frequency modulation of the carrier using Frequency Shift Keying (FSK). I will at least see if I can get something that looks right out the other side. Would it be best to use one of the GFSK examples in gr-digital? On Fri, Oct 17, 2014 at 10:37 AM, John Malsbury jmalsbury.perso...@gmail.com wrote: Also, my understanding for the PLL blocks were that they were ideal for strong carrier signals like AM. When I say strong carrier i mean a signal that has an obvious carrier which isn't hidden under modulation.. Anyway, the GMSK block might be a good place to start. -John On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury jmalsbury.perso...@gmail.com wrote: It doesn't have frequency correction - I can probably follow up with some ideas on how to implement that part. But the GMSK demod might do OK for you initially. It doesn't do anything intelligent to deal with the data shaping - its just a non-coherent slicer. If you want to design in GRC but keep your top-level application as is, you can use a hier block. You can also use a command line parameter or other mechanism to select your demodulator at start-time for easy comparisons. [typed one handed.. my daughter has my other and] -John On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt l...@robotastic.com wrote: Thanks for looking into it! To be honest, I am not really good at RF. I based my code off the python code in gr-smartnet. The fsk-demod python file is here: https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py It is quite possible that it just happened to work because of an error that got patched in Gr 3.7. Are there some good examples for GMSK/FSK demodulation that I could borrow from instead? Recreating this in GRC sounds like a great idea so I can scope along the way. I will give that a try next. Thanks again for the pointers, fresh eyes are really helpful when you have been staring at it for so long. - Luke On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun martin.br...@ettus.com wrote: On 10/17/2014 08:28 AM, John Malsbury wrote: Also also, is the Band-Edge FLL ideal for GMSK? My possibly, incorrect understanding of that block is that it was more ideal for PAM with common RRC. For the record: It might work coincidentally because of the rolloff-y shape of GMSK, but it's derived for and designed for common PAM/RRC, as John says and I wouldn't recommend it for anything else. To look up the math, I suggest Harris' works. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gettin data out from GRC to C++ or java?
Thanks for those tips. Matlab can handle 20M samples due to receiver object, which is buffering data, and than sending it to Matlab. My receiver is able to demodulate around 5x802.11 frames per second but i want something more faster. So i can use UHD driver in C++ enviroment directly right? Sorry for newbie question, but im quite new to sdr platform :D Best -- View this message in context: http://gnuradio.4.n7.nabble.com/Gettin-data-out-from-GRC-to-C-or-java-tp50824p50898.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [coproc] Next WG Call Time
I'd like to setup another Co-Processors WG call in the next couple of weeks - any one interested in attending should vote on the date/time at: http://whenisgood.net/pinanwe Somewhere in the Oct. 27 - 31 date range will work best for me. Note that you need to select your local timezone (e.g. I'll be in the US Eastern TZ). Also - if there are items you'd like to discuss during the call please drop me a note. Doug -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
